Session Distribution Policy Descriptions
Table of Contents
Expand all | Collapse all
-
- Tap Interfaces
-
- Layer 2 and Layer 3 Packets over a Virtual Wire
- Port Speeds of Virtual Wire Interfaces
- LLDP over a Virtual Wire
- Aggregated Interfaces for a Virtual Wire
- Virtual Wire Support of High Availability
- Zone Protection for a Virtual Wire Interface
- VLAN-Tagged Traffic
- Virtual Wire Subinterfaces
- Configure Virtual Wires
- Configure an Aggregate Interface Group
- Configure Bonjour Reflector for Network Segmentation
- Use Interface Management Profiles to Restrict Access
-
- DNS Overview
- DNS Proxy Object
- DNS Server Profile
- Multi-Tenant DNS Deployments
- Configure a DNS Proxy Object
- Configure a DNS Server Profile
- Use Case 1: Firewall Requires DNS Resolution
- Use Case 2: ISP Tenant Uses DNS Proxy to Handle DNS Resolution for Security Policies, Reporting, and Services within its Virtual System
- Use Case 3: Firewall Acts as DNS Proxy Between Client and Server
- DNS Proxy Rule and FQDN Matching
-
- NAT Rule Capacities
- Dynamic IP and Port NAT Oversubscription
- Dataplane NAT Memory Statistics
-
- Translate Internal Client IP Addresses to Your Public IP Address (Source DIPP NAT)
- Enable Clients on the Internal Network to Access your Public Servers (Destination U-Turn NAT)
- Enable Bi-Directional Address Translation for Your Public-Facing Servers (Static Source NAT)
- Configure Destination NAT with DNS Rewrite
- Configure Destination NAT Using Dynamic IP Addresses
- Modify the Oversubscription Rate for DIPP NAT
- Reserve Dynamic IP NAT Addresses
- Disable NAT for a Specific Host or Interface
-
- Network Packet Broker Overview
- How Network Packet Broker Works
- Prepare to Deploy Network Packet Broker
- Configure Transparent Bridge Security Chains
- Configure Routed Layer 3 Security Chains
- Network Packet Broker HA Support
- User Interface Changes for Network Packet Broker
- Limitations of Network Packet Broker
- Troubleshoot Network Packet Broker
-
- Enable Advanced Routing
- Logical Router Overview
- Configure a Logical Router
- Create a Static Route
- Configure BGP on an Advanced Routing Engine
- Create BGP Routing Profiles
- Create Filters for the Advanced Routing Engine
- Configure OSPFv2 on an Advanced Routing Engine
- Create OSPF Routing Profiles
- Configure OSPFv3 on an Advanced Routing Engine
- Create OSPFv3 Routing Profiles
- Configure RIPv2 on an Advanced Routing Engine
- Create RIPv2 Routing Profiles
- Create BFD Profiles
- Configure IPv4 Multicast
- Create Multicast Routing Profiles
- Create an IPv4 MRoute
Session Distribution Policy Descriptions
The following table provides information about Session
Distribution Policies to help you decide which policy best
fits your environment and firewall configuration.
Session Distribution Policy | Description |
---|---|
Fixed | Allows you to specify the dataplane
processor (DP) that the firewall will use for security processing. Use
this policy for debugging purposes. |
Hash | The firewall distributes sessions
based on a hash of the source address or destination address. Hash
based distribution improves the efficiency of NAT address resource
management and reduces latency for NAT session setup by avoiding
potential IP address or port conflicts. Use this policy in
environments that use large scale source NAT with dynamic IP translation
or Dynamic IP and Port translation or both. When using dynamic IP translation,
select the source address option. When using
dynamic IP and port translation, select the destination address
option. |
Ingress-slot ( default
on PA-7000 Series firewalls ) | ( PA-7000 Series firewalls
only ) New sessions are assigned to a DP on the same NPC on which
the first packet of the session arrived. The selection of the DP
is based on the session-load algorithm but, in this case, sessions
are limited to the DPs on the ingress NPC.Depending on the
traffic and network topology, this policy generally decreases the
odds that traffic will need to traverse the switch fabric. Use
this policy to reduce latency if both ingress and egress are on
the same NPC. If the firewall has a mix of NPCs (PA-7000 20G and
PA-7000 20GXM for example), this policy can isolate the increased
capacity to the corresponding NPCs and help to isolate the impact
of NPC failures. |
Random | The firewall randomly selects
a DP for session processing. |
Round-robin ( default
on PA-5200 Series firewalls ) | The firewall selects the dataplane
processor based on a round-robin algorithm between active dataplanes
so that input, output, and security processing functions are shared
among all dataplanes. Use this policy in low to medium demand environments
where a simple and predictable load balancing algorithm will suffice. In
high demand environments, we recommend that you use the session-load
algorithm. |
Session-load | This policy is similar to the
round-robin policy but uses a weight-based algorithm to determine
how to distribute sessions to achieve balance among the DPs. Because
of the variability in the lifetime of a session, the DPs may not
always experience an equal load. For example, if the firewall has
three DPs and DP0 is at 25% of capacity, DP1 is at 25%, and DP2
is at 50%, new session assignment will be weighted towards the DP with
the lower capacities. This helps improve load balancing over time. Use
this policy in environments where sessions are distributed across
multiple NPC slots, such as in an inter-slot aggregate interface
group or environments with asymmetric forwarding. You can also use
this policy or the ingress-slot policy if the firewall has a combination
of NPCs with different session capacities (such as a combination
of PA-7000 20G and PA-7000 20GXM NPCs). |
Symmetric-hash | ( PA-5200 Series and PA-7000 Series firewalls
running PAN-OS 8.0 or later ) The firewall selects the DP by
a hash of sorted source and destination IP addresses. This policy
provides the same results for server-to-client (s2c) and client-to-server
(c2s) traffic (assuming the firewall does not use NAT).Use
this policy in high-demand IPSec or GTP deployments. With
these protocols, each direction is treated as a unidirectional flow
where the flow tuples cannot be derived from each other. This policy
improves performance and reduces latency by ensuring that both directions
are assigned to the same DP, which removes the need for inter-DP
communication. |