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. 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

Figure 15-37. Problem-Resolution Flowchart

4 PREVIOUS

< Free Open Study >

BSD

Problem: Multiple BGP Connections to the Same BGP Neighbor AS, but Traffic Goes Out Through Only One Connection?Cause: BGP Neighbor Is Influencing Outbound Traffic by Sending MED or Prepended AS_PATH

Typically, BGP networks are multihomed to different ISPs or the same ISP to provide redundancy or to load-share traffic. In some scenarios, the BGP network might be dual homed to the same ISP and might be running BGP with that ISP. Instead of load sharing traffic to the ISP over multiple connections, traffic might exit only from one connection.

These connections might be of equal bandwidth or might be different.

If the multiple EBGP connection links are of equal bandwidth and traffic exits from only one of those EBGP connections, this is not desirable and can lead to severe performance degradation because of packet loss and round-trip delays over the congested link. If the EBGP connections are of different bandwidth? say, T3 (45 Mbps) and T1 (1.5 Mbps)? it might be desirable for all traffic to go out through the T3 exit point. This section discusses the issue in which all EBGP connections going to the same iSp are of equal bandwidth but traffic goes out from only one of those links.

In the network illustrated in Figure 15-38, AS 109 has three EBGP peerings with AS 110, and AS 110 is advertising the same prefixes, P1, P2, P3, and so forth, at all peering points. However, all traffic from AS 109 destined for these prefixes uses a single exit point, X, with AS 110. This results in congestion at X and unnecessary usage of the AS 109 backbone.

Figure 15-38. BGP Network in Which Traffic Is Routed Inefficiently

Figure 15-38. BGP Network in Which Traffic Is Routed Inefficiently

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

Figure 15-39. Problem-Resolution Flowchart

Figure 15-39. Problem-Resolution Flowchart

4 PREVIOUS

< Free Open Study >

BSD

Problem: Asymmetrical Routing Occurs and Causes a Problem Especially When NAT and Time-Sensitive Applications Are Used?Cause: Outbound and Inbound Advertisement

Asymmetric routing means that packets flowing to a given destination don't use the same exit point as the packets coming back from that same destination. This is not a problem in itself, but it can cause some issues when Network Address Translation (NAT) or a time-sensitive application is involved.

Symmetrical routing is probably one of hardest network policies to achieve. Figure 15-40 shows a network in which asymmetrical routing occurs.

Figure 15-40. Network Vulnerable to Asymmetrical Routing

Figure 15-40. Network Vulnerable to Asymmetrical Routing

Figure 15-40 shows a network setup composed of AS 109 and AS 110, and AS 110 has private IP addressing in the 10.0.0.0 network. AS 110 has two exit points, R1 and R2; however, R1 is the only router performing NAT for any packets sourcing from inside AS 110. In Figure 15-40, the 10.1.1.1 private IP address is translated to 131.108.1.1 at R1 when 10.1.1.1 is sending IP traffic to prefix P in AS 109. From the figure, it is obvious that this packet will enter AS 109 at Interface X of Router R3 and that this packet might exit from Interface Y of R4.

This might happen for multiple reasons and its results could be severe, the most common of which are listed here:

• AS 109 BGP policy might dictate that all AS 110 traffic should exit from Y.

• AS 110 might influence AS 109 by using MED or AS_PATH prepend to receive all traffic from AS 109 at Exit Y.

• AS 109 BGP policy might govern the closest exit policy for all AS 110 traffic. For Router R3 in AS 109, the closest exit is Y, regardless of where the destination, 131.108.1.1, is.

• When R2 receives the returned packet destined for 131.108.1.1, it has no NAT entry to translate back to 10.1.1.1 and it simply drops this packet.

• The link between R1 and R3 is of bigger bandwidth but the link between R2 and R4 has small bandwidth. The return traffic from R2 to R4 could add significant delays in the overall round-trip time of the packet from AS 109 to AS 110.

Debugs and Verification

Because packet drops and sluggish round-trip times are observed in AS 109, administrators in

AC 1 HQ mi icf fini iro ai if a \Ai2\/ fr\ Hoi-orminQ if 3c\/rr>rr>af ri^a I rr\ i ifinn ic r\/~r-t i rri nn A e i m n la ninn

4 PREVIOUS

< Free Open Study >

BSD

Troubleshooting Load-Balancing Scenarios in Small BGP Networks

Problem: Load Balancing and Managing Outbound Traffic from a Single Router When Dual Homed to Same ISP?Cause: BGP Installs Only One Best Path in the Routing Table

In multihomed scenarios, a common concern that enterprise network operators face is improperly utilizing the external links going to the ISP. Typically, enterprise customers dual-home to either the same or different ISPs to load-share outgoing and incoming traffic.

Figure 15-41 shows a simple setup of R1 of AS 109 dual homed to same ISP AS 110 at R2 and R3. Both R2 and R3 are advertising prefix 100.100.100.0/24 to R1. Ideally, R1 should load-share traffic destined for prefix 100.100.100.0/24, but, by default, this does not happen and only one of the many paths available is used.

Figure 15-41. 1AS Dual Homed to Same ISP AS

Figure 15-41. 1AS Dual Homed to Same ISP AS

100,100 100 IY24 across both EBGP connections,

BGP selects only a single best route for a prefix out of many alternate paths. This is the default behavior governed by RFC 1771. R1 will have two paths for prefix 100.100.100.0/24? one from R2 and the other from R3. R1 will go through its BGP best-path calculation and will pick and install one route in the routing table.

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

Figure 15-42. Problem-Resolution Flowchart

Mulliple eiiite! BCP palhs exist k* Ihe Mme- pnefiK, tmt only ere path gels

¡neFallarl in iha mi rlinn dahlia

Figure 15-42. Problem-Resolution Flowchart

Mulliple eiiite! BCP palhs exist k* Ihe Mme- pnefiK, tmt only ere path gels

¡neFallarl in iha mi rlinn dahlia

Debugs Verification

Page 463

* PREVIOUS

< Free Open Study >

BSD

Problem: Load Balancing and Managing Outbound Traffic in an IBGP Network?Cause: By Default, IBGP in Cisco IOS Software Allows Only a Single Path to Get Installed in the Routing Table Even Though Multiple Equal BGP Paths Exist

If multiple paths are received from different IBGP neighbors for the same prefix, only one best path will be selected and installed in the routing table. This results in other alternate paths being unused.

Figure 15-43 shows a simple IBGP network in which R1 has an IBGP peering with R2 and R3. Both R2 and R3 are advertising 100.100.100.0/24 with next hops of 2.2.2.2 and 3.3.3.3, respectively, to R1. By default, R1 goes through its BGP best-path calculation and installs a single route for 100.100.100.0/24. Two paths exist, but only one sends traffic to 100.100.100.0/24.

Figure 15-43. IBGP Network with IBGP Peering to Two Routers

Figure 15-43. IBGP Network with IBGP Peering to Two Routers

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

Figure 15-44. Problem-Resolution Flowchart

4 PREVIOUS

< Free Open Study >

BSD

Was this article helpful?

0 0

Post a comment