Test Case: Layer 3 BFD Based CN-GW Failure Handling
Table of Contents
11.0
Expand all | Collapse all
-
- CN-Series Key Concepts
- CN-Series Core Building Blocks
- Components Required to Secure Kubernetes Clusters with CN-Series Firewall
- CN-Series Deployment—Supported Environments
- CN-Series System Requirements
- Quickstart- CN-Series Firewall Deployment
- CN-Series Performance and Scaling
- Additional CN-Series Resources
-
- CN-Series Deployment Checklist
- CN-Series Prerequisites
- Install a Device Certificate on the CN-Series Firewall
- Create Service Accounts for Cluster Authentication
- Install the Kubernetes Plugin and Set up Panorama for CN-Series
- Get the Images and Files for the CN-Series Deployment
- Editable Parameters in CN-Series Deployment YAML Files
- Enable Horizontal Pod Autoscaling on the CN-Series
- Secure 5G With the CN-Series Firewall
- Enable Inspection of Tagged VLAN Traffic
- Enable IPVLAN
- Uninstall the Kubernetes Plugin on Panorama
- Features Not Supported on the CN-Series
-
- CN-Series HSF System Requirements
- Configure Traffic Flow Towards CN-Series HSF
- Test Case: Layer 3 BFD Based CN-GW Failure Handling
- View CN-Series HSF Summary and Monitoring
- Validating the CN-Series HSF Deployment
- Custom Metric Based HPA Using KEDA in EKS Environments
- Features Not Supported on the CN-Series
Test Case: Layer 3 BFD Based CN-GW Failure Handling
This test evaluates the BFD configuration required to handle CN-GW failures. A BFD
profile handles CN-GW failures on the Upstream/Downstream routers.

Symmetric Traffic Flow
- If the ingress traffic interface is CN-GW 1, the route lookup to find the egress interface is on LR1.
- Route 1: Destination: Client subnet; Next-hop: R1
- Route 2: Destination: Server subnet; Next-hop: LR2
- If the ingress traffic interface is CN-GW 2, the route lookup to find the egress interface is on LR2.
- Route 1: Destination: Client subnet; Next-hop: R1
- Route 2: Destination: Server subnet; Next-hop: R2
Asymmetric Traffic Flow
CN-Series HSF supports asymmetric traffic flow too. For example, Client to Server
traffic matching session 1 flowing through CN-GW 1 and Server to Client traffic
matching session 1 flowing through CN-GW 2. For asymmetric traffic flow, all
interfaces facing R1 must be in the same zone. Similarly, all interfaces facing R2
must be in the same zone.
Inter LR Routing
For example, if the ingress traffic interface is CN-GW 1, route lookup to find the
egress interface is on LR1. If there is a route to reach Server with the next-hop as
LR2, then CN-NGFW will send the traffic to LR2. Based on CN-GW 2 LR2 route lookup,
packet will be sent to the Server.
- Go to, then select the variable template from theNetworkRoutingRouting ProfilesBFDTemplatedrop-down.You must enable BFD on external routers and logical routers.
- ClickAddto add for the BFD profile.
- Enter aName.
- Select theModein which BFD operates:
- Active—BFD initiates sending control packets to peer (default). At least one of the BFD peers must be Active; both can be Active.
- Passive—BFD waits for peer to send control packets and responds as required.
- Enter theDesired Minimum Tx Interval (ms). This is the minimum interval, in milliseconds, at which you want the BFD protocol (referred to as BFD) to send BFD control packets; you are thus negotiating the transmit interval with the peer.
- Enter theDetection Time Multiplier. The local system calculates the detection time as theDetection Time Multiplierreceived from the remote system multiplied by the agreed transmit interval of the remote system (the greater of theRequired Minimum Rx Intervaland the last receivedDesired Minimum Tx Interval). If BFD does not receive a BFD control packet from its peer before the detection time expires, a failure has occurred. Range is 2 to 50; default is 3.
- Enter theHold Time (ms). This is the delay, in milliseconds, after a link comes up before BFD transmits BFD control packets.Hold Timeapplies to BFD Active mode only. If BFD receives BFD control packets during theHold Time, it ignores them. Range is 0-120000, default is 0.
- SelectMultihopto enable BFD over BGP multihop. Enter theMinimum Rx TTL.This is the minimum Time-to-Live value (number of hops) BFD will accept (receive) in a BFD control packet when BGP supports multihop BFD. (Range is 1-254; there is no default).
- ClickOKto save the BFD profile.
- Configure static routes for the logical router.
- Go to, then select the variable template from theNetworkRoutingLogical RouterTemplatedrop-down.
- Select thetab and clickStaticIPv4Add.
- Enter aNamefor the static route.
- Enter theDestinationroute and netmask. For example, 192.168.200.0/24.
- Select the outgoing interface for packets to use to go to the next hop.
- ForNext Hop, selectip-addressand enter the IP address of your internal gateway. For example, 192.168.100.2.
- Enter anAdmin Distancefor the route to override the default administrative distance set for static routes for this logical router (range is 10 to 240; default is 10).
- Enter aMetricfor the route (range is 1 to 65,535).
- Apply theBFD Profilecreated in previous steps to the static route so that if the static route fails, the firewall removes the route and uses an alternative route.
- ClickOK.
The BFD configuration takes care of CN-GW and path failures. In the following traffic
flow diagram, consider two SSH sessions between Client and Server. Session 1 is
flowing through path 1and Session 2 is flowing through path 2. If the CN-GW 1 or
path 1 is down, the BFD configuration between R1 and CN-GW 1, R2 and CN-GW 1 helps
R1identify the path failure and sends the traffic through path 2. The interfaces
facing R1 must be in the same zone. Similarly, interfaces facing R2 must be in the
same zone.
Route 1: Destination: Client subnet; Next-hop is R1, Metric 10
Route 2: Destination: Server subnet; Next-hop is LR2, Metric 11
