[Dr.WoW]Q&A: Why Does the Traffic Not Match Policy-based Route?

A: Policy-based routes do not support policy re-check. When the first packet is used to query routes, the application is not identified. Policy-based routes are queried not based on the application information. The found route is used to forward the current traffic. Policy-based routes are not re-checked for subsequent traffic (the route is not refreshed again because any route change will interrupt TCP traffic). Therefore, the correct policy-based route may not be matched even if the application has been identified.

Symptom

In the scenario where traffic is distributed based on PBR, the QQLive traffic is expected to pass through GigabitEthernet1/0/0, and other traffic is transmitted through GigabitEthernet1/0/1. In this example, there are two policies: policy 1 and policy 2. The policies are configured with the same matching conditions but different applications. Policy 1 is configured with the QQLive application, while policy 2 is not configured with any applications. The traffic matching policy 1 is forwarded through GigabitEthernet1/0/0, and the traffic matching policy 2 is forwarded through GigabitEthernet1/0/1. Query the FWNIPSVN's session information. It is found that some sessions are identified as QQLive, but traffic matches policy 2 and is transmitted through GigabitEthernet1/0/1.
In the command output, QQLive is the traffic application, Interface is the traffic outbound interface, 111.161.57.25:8000 is the destination address and destination port, and obv_pbr is the policy-based route rule matched by the traffic.

[sysname-policy-pbr] display this
#
policy-based-route
 rule name 1
  source-zone trust
  application app QQLive
  action pbr egress-interface GigabitEthernet1/0/0 next-hop 1.1.1.1
 rule name 2
  source-zone trust
  action pbr egress-interface GigabitEthernet1/0/1 next-hop 2.2.2.2
#
return
[sysname-diagnose] display firewall session table detail
QQLive  VPN: public --> public  ID: a68f54f806aa063fbde59b7fd9c022
Create Time :2017-09-12 07:30
Zone: trust --> untrust TTL: 00:10:00  Left: 00:09:52
Recv Interface: GigabitEthernet1/0/2
Interface: GigabitEthernet1/0/1  NextHop: 2.2.2.2
<--packets: 33 bytes: 4,234 --> packets: 34 bytes: 3,378
192.168.150.2:22108[124.93.119.8:56037] --> 111.161.57.25:8000 PolicyName: trust_untrust_outbound01
fwd_type: forward <--> forward, Rev Interface: GigabitEthernet1/0/2, Rev NextHop: 192.168.150.2
obv_hash: 5, obv_cpu: 11, rev_hash: 5, rev_cpu: 11, flag: 00000003:80100184
nge_cpu: 11:0, nge_chn: 0:0, proc_mask: 0, nge_flag: 0:0:0:0:0, decode_id: 0, app_id: 9, obv_pbr: 2, rev_pbr: default

In the command output, QQLive is the traffic application, Interface is the traffic outbound interface, 111.161.57.25:8000 is the destination address and destination port, and obv_pbr is the policy-based route rule matched by the traffic.

Possible Causes

Policy-based routes do not support policy re-check. When the first packet is used to query routes, the application is not identified. Policy-based routes are queried not based on the application information. The found route is used to forward the current traffic. Policy-based routes are not re-checked for subsequent traffic (the route is not refreshed again because any route change will interrupt TCP traffic). Therefore, the correct policy-based route may not be matched even if the application has been identified.

Procedure

   Check whether the PBR application association table is generated.
After the application is identified for the first flow, the application association table (source or destination triplet) of the corresponding policy-based route is delivered. Subsequently, the traffic matching the association table can obtain the application identification result before policy-based routes are queried and match the desired policy-based route.
Run the display policy-based-route app-cache udp 111.161.57.25 8000 command to check whether the application association table is generated.

[sysname-diagnose] display  policy-based-route app-cache  udp 111.161.57.25 8000
Flag  Protocol Address                       Port  Vsys  App                      TTL HITTED
-------------------------------------------------------------------------------------------------
DST   UDP      111.161.57.25                8000  0     QQLive                   508   450
------------------------------------------------------------------------------------------------

   In the command output, 111.161.57.25 is the destination address, 8000 is the destination port, and QQLive is the application of the traffic.
If the entry has been generated and matched, there is traffic matching the association table. Check the traffic matching the association table. If only a few packets do not match the application-based policy-based route, it is normal, and no action is required.

----End