Global Counters Show Flow_fwd_zonechange" Packets Incrementing"

Issue

A vpn tunnel goes down and comes back up. A look at the global counters show that the flow_fwd_zonechange counter is incrementing.

> show counter global

Cause

The flow_fwd_zonechange counter indicates that the egress zone of a packet does not match the egress zone of the matching session. For this reason, the packet is dropped and the flow_fwd_zonechange counter is incremented.

Scenario

Packets are dropped due to a route change. The flow_fwd_zonechange counter increments when a packet is to be forwarded, but the zone of egress interface does not match the egress zone in the session due to a route change because the tunnel is not up. To verify global counter increments please refer to to the following knowledge base How to Check Global Counters for Specific Source and Destination IP Address

In this scenario, the initial routing table is as follows:

• 0.0.0.0/0 metric 10 untrust zone.
• A tunnel route to 10.10.10.10/24 through 1.1.1.1 metric 5 tunnelzone.
• When the tunnel goes down, the tunnel route is removed from the table and the default route is used for the 10.10.10.10 network in the untrust zone.
• When the tunnel comes back up, it considers this a zone change and drops the packts incrementing the flow_fwd_zonechange counter.

Resolution

All sessions destined to the untrust zone when going to 10.10.10.10/24 need to be cleared and re-initiated.

To avoid this zone change, create a dummy IP address (ex: loopback interface IP address 5.5.5.5) in the tunnel zone to make the routing table look like this:

• 0.0.0.0/0 metric 10 untrust zone.
• A tunnel route to 10.10.10.10/24 through 1.1.1.1 metric 5 tunnelzone.
• Another tunnel route to 10.10.10.10/24 through 5.5.5.5 metric 10 tunnelzone.
• This forces the traffic to use the route with metric 10 in the same tunnel zone when the primary tunnel route fails, and there is no zone change that occurs when the tunnel comes back up.

owner: pvemuri