>
    Flow Sequence in a Prisma SD-WAN Branch Site
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma SD-WAN
    3. Prisma SD-WAN Sites and Devices
    4. Set Up Sites
    5. View Flows Tab
    6. Flow Sequence in a Prisma SD-WAN Branch Site
    Download PDF
    Prisma SD-WAN

    Flow Sequence in a Prisma SD-WAN Branch Site

    Table of Contents

    Flow Sequence in a Prisma SD-WAN Branch Site

    Learn how a network flow is managed by a Prisma SD-WAN ION device, from its entry to its exit.
    Where Can I Use This?What Do I Need?
    • Prisma SD-WAN
    • Prisma SD-WAN license

    Overview

    This technical paper details the life of a flow through a Prisma SD-WAN ION device. The packet's journey is divided into several stages, each involving specific decisions and actions to ensure efficient and secure packet forwarding. The stages are:
    1. Ingress Processing
    2. Application Determination
    3. QOS Policy Determination
    4. Path Policy Determination
    5. Security Policy Determination
    6. Performance Policy
    7. Path Selection
    8. Egress Processing

    Ingress Processing

    Packets can enter the Prisma SD-WAN ION device via multiple paths:
    • Direct Internet
    • Secure Fabric Tunnel
    • Standard VPN
    • L3 LAN Interface
    • L3 WAN Interface
    Upon entering the ION device, a packet undergoes several initial checks and parsing steps:
    Encryption Check
    The device first determines whether the received packet is encrypted. If encryption is detected, the device attempts to decrypt the packet to proceed with further processing.
    L2/L3/L4 Packet Parsing
    The packet is parsed at multiple layers to extract necessary information:
    • Layer 2 (Ethernet): The packet is parsed to extract Ethernet frame details.
    • Layer 3 (IP): The packet is parsed to obtain IP header information.
    • Layer 4 (Transport Layer, such as TCP/UDP): The packet is parsed to extract transport layer information, such as port numbers and protocol type.
    L3 Prefix Reachability
    The device verifies the reachability of the packet's destination using Layer 3 prefix information. This step ensures that the destination is reachable within the network topology.
    Flow Check
    The device checks whether a flow already exists for this packet. This involves looking up the flow table to determine if the packet is part of an existing flow.

    Application Detection Stage

    Continuing from the Ingress Processing Stage, the Application Detection Stage determines the type of application associated with flow. This stage handles both new flows and ongoing flows to ensure accurate application identification.
    Flow Detection
    If the flow is not detected during the initial checks, it is directly fed into the application detection module. If the flow is detected, the device checks if the flow is part of continuous application detection. During the initial few packets, continuous application detection is performed to identify any new applications based on the packet data.
    Continuous Application Detection
    If the flow is eligible for continuous application detection, it is fed into the application detection module. If the flow is not part of continuous application detection, the device checks whether the new packet that it received is on the same path as the previous packet.
    • Same Path: If the new packet is on the same path, the flow is directly fed into the Performance Policy Stage.
    • Path Asymmetry: If the new packet is on a different path, the device detects path asymmetry, updates the flow record with the new path information, and then feeds the flow into the Zone Based Firewall Stage.
    Application Detection Module
    For new flows and flows eligible for continuous application detection, the packets are fed into the application detection module. The order of precedence for application determination is as follows:
    • L3 + L4 Custom Apps: Custom applications defined using Layer 3 and Layer 4 information.
    • L7 Custom Apps: Custom applications defined using Layer 7 information.
    • L7 System Apps: System-defined applications using Layer 7 information.
    • L3 + L4 System Apps: System-defined applications using Layer 3 and Layer 4 information.
    • L4 System Apps: System-defined applications using Layer 4 information.
    Once the application is identified, this information is fed into the QoS Policy Stage.

    QoS Policy Stage

    After the Application Detection Stage, the process moves to the QoS Policy Stage. At this stage, the detected application information, along with the source prefix, destination prefix, network context, user ID and group ID information, is utilized to determine the appropriate QoS policy.
    QoS Policy Rule Matching
    For each incoming flow, once the ION device classifies it as a specific application, it searches for a matching QoS policy rule:
    • Matching QoS Policy: If a specific QoS rule matches the identified application, that rule is applied to queue and prioritize the flow.
    • No Matching QoS Policy: If no specific QoS rule matches the application, the Default QoS rule is used to queue and prioritize the flow.
    Default Application Handling
    For new incoming flow, when the first packet is received, if the ION device is unable to classify it as a particular application, it is initially classified as the default application. The Default QoS rule is then applied to this flow.
    Re-queuing based on Application Classification
    As subsequent packets of the flow are received, the ION device continues to analyze them. Once the flow is accurately classified as a particular application, the flow is re-queued based on the matching QoS policy rule for that application.
    By performing these steps, the Prisma SD-WAN ION device ensures that each flow is queued and prioritized according to the appropriate QoS policies, optimizing network performance and resource allocation.

    Path Policy Stage

    In the Path Policy Stage, the ION device determines the optimal path for the flow using the stacked network policy. This decision is based on the application identified in the previous stage and other fields such as network context, source IP, destination IP, and user/group ID.
    Path Policy Determination
    The ION device performs an ascending order longest match to determine the Path Policy, using the following criteria:
    • Application identified
    • Network context
    • Source Prefix
    • Destination Prefix
    • User/group ID
    Path Filtering based on status
    An additional module evaluates the status of all available paths on the device. This module checks:
    • Physical Status: Whether the underlay and overlay paths are up or down.
    • Layer 3 Reachability: L3 reachability on both underlay and overlay paths.
    Unavailable paths are pruned based on their status, and the available path information is sent to the Path Policy module.
    Path filtering based on path policy
    In the Path Policy module:
    • The policy rule is determined based on the application and other relevant fields.
    • The paths specified in that policy rule are further pruned based on the available paths information received from the Path Status module (Path Filtering based on status).
    • The filtered list of paths is then sent to the next stage in the process.

    Security Policy Stage

    In the Security Policy Stage, the ION device applies security policies to the filtered paths from the previous step. This ensures that only secure paths are considered for further processing.
    Security Policy Evaluation
    The filtered paths are fed into the Zone-Based Firewall module, where the security policies are evaluated for all possible paths. The ION device performs an ascending order longest match to determine the Security Policy Rule, using the following criteria
    • Application identified
    • Network context
    • Source Prefix
    • Destination Prefix
    • User/group ID
    The process involves:
    • Policy Rule Matching: The device checks if any of the rules, in ascending order, match the ALLOW policy. If a match is found, the flow proceeds to the next stage. If no match is found, the flow is either denied or rejected based on the rule matched.
    • Path Pruning: Paths not allowed by the security policy are pruned
    Handling Path Asymmetry
    For existing flows, if security policies are configured and if a packet from the WAN to LAN direction arrives on a different path than the original path due to asymmetry, the flow is re-evaluated using the Zone-Based Firewall policies. The appropriate action is then taken based on the matched security rule.

    Path Selection Stage

    In the Path Selection Stage, all filtered paths from the previous stage are further refined to select the optimal path for the flow. This stage involves multiple filtering steps, applied in a specific order:
    Performance Policy
    For an Application, if there is a specific performance policy rule configured, then the paths are filtered based on the following criteria in the same order as below:
    • Path filtering based on Synthetic Health Probes: Synthetic Health Probes can be configured to measure latency loss and jitter to configured destinations.
    • Path filtering based on Link Quality Monitoring: LQM data can be used to measure latency loss jitter and link MOS on Direct,SD-WAN VPN and Standard VPN paths
    If a performance policy rule has not been explicitly configured for an application, then default LQM SLAs will be used from the default performance policy rules. Paths that do not meet SLAs are excluded.
    Application Reachability
    Next, the paths are filtered based on application reachability. Any path where the application is not reachable is discarded.
    Specific Destination Prefix Route
    The paths are then evaluated for the most specific destination prefix route. Paths with more specific destination prefixes are selected, and those with less specific prefixes are filtered out.
    Application Session Path Affinity
    The remaining paths are checked for application session path affinity. If an app has strict path affinity, then that path is selected.
    If path affinity is not enabled for the application, Path filtering based on Application SLAs :
    Paths are filtered based on App SLAs defined in performance policy rules matching the application.App SLAs can be defined for Init Failure Rate, Application RTT, UDP-TRT and Link MOS. Paths that do not meet the configured SLAs are excluded.
    Bandwidth-Based Path Selection
    Finally, if more than one path remains, the selection is made based on available bandwidth. The path with the best available bandwidth at that moment is chosen as the single best path.
    Under the Path Policy, there is an option to select L3 failure paths. If the active and backup paths encounter L3 reachability issues, the device will choose paths defined under L3 failure paths. If L3 failure paths are unavailable or not defined, as a last resort, one of the active paths will be selected.
    By following these steps, the Prisma SD-WAN ION device ensures that the most optimal path is selected for each flow, considering various performance and policy criteria to achieve the best possible network performance and reliability.

    Egress Processing Stage

    The final stage in the journey of a packet through the Prisma SD-WAN ION device is the Egress Processing Stage. This stage ensures the packet is properly prepared and transmitted to its next destination. The steps involved are:
    Required Rewrite
    In this step, the device performs any necessary rewrites to the packet headers. This includes:
    • Egress QoS Enqueue (LAN to WAN flow): Determining whether to enqueue the packet to the Egress QoS queue for prioritization and rate limiting.
    • If there is a performance policy rule that has action configured to enable FEC & Packet Duplication, when there is an SLA violation on the SD WAN VPN path , then FEC TLVs need to be added to the Geneve header
    • IP Fragmentation: If applicable, the packet is fragmented to fit the MTU of the egress path.
    Transmit Setup
    The packet is prepared for transmission. This involves:
    • Encryption: If the packet needs to be sent through a tunnel, the device encrypts the packet to ensure secure transmission.
    Forwarding
    The packet is then forwarded to the next hop, completing its journey through the ION device. This involves:
    • Next Hop Forwarding: The packet is transmitted to the next network device or destination along the determined path.
    By following these steps, the Prisma SD-WAN device ensures that each packet is processed, prioritized, secured, and transmitted efficiently, maintaining optimal network performance and reliability.

    © 2025 Palo Alto Networks, Inc. All rights reserved.