Problem: Traffic Takes a Different Interface from What Shows in Routing Table-Cause: Next Hop of the Route Is Reachable Through Another Path

Problem: Traffic Takes a Different Interface from What Shows in Routing Table ‚ Cause: Next Hop of the Route Is Reachable Through Another Path

In some scenarios, BGP and the routing table path to a certain destination prefix show Exit A, but actual traffic leaves through Exit B. Packet forwarding to a destination takes place from the routing table, and network operators do expect to see this behavior. However, in most cases, the next hops of prefixes in the routing table are not directly connected and packet forwarding eventually takes place based on the next-hop path. Figure 15-36 tries to explain one such simple case.

Figure 15-36. Packet Might Take a Different Physical Path Than What the IP Routing Table Shows

Figure 15-36 shows that R1 and R2 are two route reflectors, with R6 and R8 as their clients . R6 is advertising 100.100.100.0/24 to R2 and R1, and both reflect this advertisement to R8 with a next hop of 172.16.126.6. Now, assume that R8 has a BGP policy that chooses the path for 100.100.100.0/24 from R2 (the upper path) as the best path that it will install in its routing table. However, in the same router, R8, the best IGP path to reach 172.16.126.6 (next hop of 100.100.100.0/24) is through R1 (the bottom path).

All traffic destined from or through R8 to 100.100.100.0/24 will take the bottom path; even though the best BGP-selected path in the routing table is the upper path, it will not be used.

Therefore, forwarding of IP packets in a router eventually happens by looking at the path for the next hop (172.16.126.6) of the actual path (100.100.100.0/24). In Cisco IOS Software, recursive lookup is the term used for finding out the path based on the next hop and the actual prefix. In some cases, more than one recursive lookup must be done to figure out the actual physical path that packets take to reach the destination.

Figure 15-37 shows the flowchart to follow to resolve this problem.

Figure 15-37. Problem-Resolution Flowchart

Debugs and Verification

Example 15-72 shows the output of 100.100.100.0/24 in R8. The next hop is 172.16.126.6. When traffic is sent to 100.100.100.0/24, it actually is sent to the interface that provides a better route for 172.16.126.6.

Example 15-72 BGP and Routing Table Output for 100.100.100.0/24 Shows Best Path Through R2

 R8#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 5870 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Not advertised to any peer   Local  172.16.126.6  (metric 20) from 172.16.126.2 (172.16.126.2)       Origin IGP, metric 0, localpref 100, valid, internal, best 

In R8, 172.16.126.6 is the next hop for 100.100.100.0/24 advertised by R2 and is considered the best route; therefore, it will be installed in the IP routing table.

Example 15-73 shows that the best way to reach 172.16.126.6, the next hop of 100.100.100.0/24, is through R1, not through R2.

Example 15-73 show ip route Command Output Shows the Best Route to Reach 172.16.126.6

 R8#  show ip route 172.16.126.6  Routing entry for 172.16.126.0/24   Known via "static", distance 1, metric 0   Routing Descriptor Blocks:   *  172.16.18.1  Route metric is 0, traffic share count is 1 

The highlighted 172.16.18.1 is the next hop for 172.16.126.6 (next hop of 100.100.100.0/24).

Therefore, all traffic from or through R8 destined for 100.100.100.0/24 will go through 172.16.18.1 (R1).

Example 15-74 shows the output of a traceroute done from R8 to 100.100.100.1. The traffic flows through 172.16.18.1, which is R1.

Example 15-74 traceroute Command Output Shows Traffic Going from R1 Instead of R2

 R8#  traceroute 100.100.100.1  Type escape sequence to abort. Tracing the route to 100.100.100.1   1 172.16.18.1 4 msec 4 msec 4 msec   2 172.16.126.6 4 msec 8 msec 8 msec   3 172.16.126.6 4 msec 8 msec 8 msec 

Solution

A router might provide a route to BGP neighbor but might never be in a forwarding path to reach that route. This is because packets are forwarded to the next-hop address of the actual route, which might not be the same router that gave the route in the first place.

If routing and forwarding paths need to match, care must be taken in how next-hop addresses are learned through IGP. To fix the problem in Figure 15-36, R8 should have an IGP path for 172.16.126.6 (next hop of 100.100.100.0/24) through R2.