Knowledge Search


×
 

[ScreenOS] Packet taking the wrong route due to the route-cache feature

  [KB21011] Show Article Properties


Summary:
  • Applicable to ScreenOS 6.3 firmware.
  • In ScreenOS 6.3, a new feature has been added called 'cached route.'
  • Whenever a packet arrives on the firewall, the firewall does a route lookup and caches the route.
Symptoms:
  • Traffic is taking a wrong cached route.
  • Traffic is passing through another nonpreferred route even though the preferred route is active.
  • In debug flow basic, you see that traffic is taking a wrong cached route.
  • Destination NAT could fail because route lookup is taking a cached route instead of a more specific route specified when configuring destination NAT.  The result is that the wrong policy table is looked up, and destination NAT does not take place.
  • Need to disable the route-cache feature.
Cause:

Solution:

This only applies to ScreenOS 6.3.0 and above.

You could verify if the traffic is taking a wrong route from the debug flow basic output:

252173.0: <Untrust/ethernet0/2> packet received [128]
ipid = 63447(f7d7), @028c68f4
self:172.27.201.131/5400->4.5.6.3/1024,1(8/0)<Root>
flow_decap_vector IPv4 process
ethernet0/2:172.27.201.131/5400->4.5.6.3/1024,1(8/0)<Root>
no session found
flow_first_sanity_check: in <ethernet0/2>, out <loopback.1>
chose interface ethernet0/2 as incoming nat if.
flow_first_routing: in <ethernet0/2>, out <loopback.1>
search route to (ethernet0/2, 172.27.201.131->4.5.6.3) in vr trust-vr for vsd-
0/flag-0/ifp-null
cached route 30 for 4.5.6.3
[ Dest] 30.route 4.5.6.3->4.5.6.3, to loopback.1

routed (x_dst_ip 4.5.6.3) from ethernet0/2 (ethernet0/2 in 0) to loopback.1
policy search from zone 1-> zone 2

As in the above output, you can see that the traffic is coming on ethernet0/2 from source IP 172.27.201.131 to the destination IP 4.5.6.3. Now for this traffic, the firewall is caching the route ID 30.

SSG520-> get route id 30
route in trust-vr:
------------------------------------------------
id: 30
IP address/mask: 4.5.6.3/24
next hop (gateway): 0.0.0.0
preference: 0
metric: 0
description:
outgoing interface: loopback.1
vsys name/id: Root/0
tag: 0
flag: 24000200/00100000
type: connected
Redistributed to:
status: active (for 7 hours 36 minutes 9 seconds)

So it's taking the connected route to loopback.1 interface, which is correct.

In some scenarios, when you give the command get route id x, you will see that the firewall is taking a wrong cached route, due to which the traffic is being affected. Generally this happens when you have a dynamic routing involved or your route flaps very often.

If this feature is impacting the network, you can disable this route-cache feature by issuing the following command:

unset flow route-cache

The firewall will not cache the route, and in the debug flow basic you will see the following output:

254337.0: <Untrust/ethernet0/2> packet received [128]
ipid = 33538(8302), @028c6ec4
self:172.27.201.131/6900->4.5.6.3/1024,1(8/0)<Root>
flow_decap_vector IPv4 process
ethernet0/2:172.27.201.131/6900->4.5.6.3/1024,1(8/0)<Root>
no session found
flow_first_sanity_check: in <ethernet0/2>, out <loopback.1>
chose interface ethernet0/2 as incoming nat if.
flow_first_routing: in <ethernet0/2>, out <loopback.1>
search route to (ethernet0/2, 172.27.201.131->4.5.6.3) in vr trust-vr for vsd-
0/flag-0/ifp-null
[ Dest] 30.route 4.5.6.3->4.5.6.3, to loopback.1

routed (x_dst_ip 4.5.6.3) from ethernet0/2 (ethernet0/2 in 0) to loopback.1
policy search from zone 1-> zone 2

As in the above output, you can see that the firewall is not caching any route.

Route cache is enabled by default in ScreenOS 6.3.

Related Links: