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

‚  < ‚  Free Open Study ‚  > ‚  

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

graphics/15fig40.gif

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 AS 109 must figure out a way to determine if asymmetrical routing is occurring. A simple ping from R1 to Prefix P in AS 110 will not help because reply packets will never arrive back at R1; instead, they will be coming back at R2. Administrators either would have to sniff the packets at R1 using sniffers or would run the debug ip packet command to observe whether the packets are going through R1 to reach Prefix P in AS 110 but are not coming back. Any debugs in Cisco IOS Software must be run with extreme caution because too much output can disturb the performance of the router. If such packet sniffing is done at R2 in AS 109, administrators can observe that packets are returning from Prefix P and are destined to addresses in AS 109. This can assure them that IP traffic is asymmetrical.

Another approach is to use traceroute; however, the problem with traceroute is that it provides the traffic path only in one direction ‚ from source to destination (AS 109 to AS 110). In asymmetrical routing, administrators are more interested in the direction of traffic from destination to source (AS 110 to AS 109). This can be achieved only if AS 110 issues a traceroute to the destination in AS 109 and AS 109 administrators observe the output.

Solution

The asymmetrical routing issue is a fairly difficult problem to tackle and sometimes is un-avoidable. Asymmetrical routing might be an issue in cases of NAT when only one device maintains the NAT table; therefore, packets must come in and out of the same device. Time-sensitive applications also might face problems when the exit path offers good throughput but the entry path is sluggish, making the overall round-trip time (RTT) bad.

Asymmetrical routing is easy to tackle in small networks, such as the one shown in Figure 15-40. To illustrate how AS 109 can avoid asymmetrical routing when peering only with AS 110, the following condition must be met:

If a packet leaves from R1 to outside AS 109, it must come back into AS 109 at R1.

How can AS 109 achieve this? AS 110 must know that to reach destinations (131.108.1.0/24) in AS 109, it must use the R3 ‚ R1 peering link. The following are viable solutions:

  • In the BGP configuration of AS 109, only R1 advertises 131.108.1.0/24 to R3 in AS 110. AS 110 will have only one way to reach 131.108.1.0/24, and that is through the R3 ‚ R1 link, ensuring symmetrical routing.

  • Both R1 and R2 are running EBGP with R3 and R4, respectively. From R1, adver-tise 131.108.1.0/24 to R3 with a MED of 1; from R2, advertise 131.108.1.0/24 to R4 with a MED of 20. AS 110 will have two advertisements, but the path from the lower MED (R1) will win and, in case the R1 ‚ R3 BGP connection fails, the path from R2 to R4 will be used. The use of the MED is discussed in detail in previous sections.

  • Using the as-path prepend option in Cisco IOS Software, R2 advertises 131.108.1.0/24 with the AS_PATH list containing AS 109 several times.

Example 15-77 shows the configuration of R2 to advertise 131.108.1.0/24 with a prepended AS.

Example 15-77 Prepending AS Number to Make an AS_PATH Longer
  R2# router bgp 109   network 131.108.1.0 mask 255.255.255.0   neighbor 4.4.4.4 remote-as 110   neighbor 4.4.4.4 route-map SYMMETRICAL out   route-map SYMMETRICAL permit 10   match ip address 1   set as-path prepend    109 109 109    route-map SYMMETRICAL permit 20  access-list 1 permit 131.108.1.0 

In R2 using the route map SYMMETRICAL for neighbor R4, R2 is advertising 131.108.1.0/24 through access list 1 and adds in the AS_PATH AS 109 three additional times. When the advertisement goes to R4, the output of BGP is highlighted in Example 15-78.

Example 15-78 BGP Routing Table for R4
 R4#  show ip bgp 131.108.1.0  BGP routing table entry for 131.108.1.0/24, version 19 Paths: (2 available, best #1, table Default-IP-Routing-Table)  109  3.3.3.3 from 3.3.3.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best  109 109 109 109  2.2.2.2 from 2.2.2.2 (2.2.2.2)       Origin IGP, metric 0, localpref 100, valid, external 

The second path AS_PATH list contains AS 109 listed four times. One time is for the regular EBGP advertisement from R2, and the three additional paths to AS 109 are because of the AS_PATH prepend done in R2.

The best path is the first path, which came from R3 to R4. It is best because it has a shorter AS_PATH length.

R3 will have the regular single EBGP advertisement from R1, as shown in Example 15-79.

Example 15-79 EBGP Advertisement from R1 to R3
 R3#  show ip bgp 131.108.1.0  BGP routing table entry for 131.108.1.0/24, version 19 Paths: (1 available, best #1, table Default-IP-Routing-Table)  Advertised to non peer-group peers:   4.4.4.4 109 1.1.1.1 from 1.1.1.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, external,best This best path is advertise to R4(4.4.4.4) by R3. 

In short, proper BGP announcements must be made at exit points and routes must be learned at the right place of the AS. Smaller enterprise networks can achieve this rather easily with the prepended AS path solution, but larger enterprise and ISP networks face a bigger challenge to ensure symmetrical routing. This is because ISPs have a larger number of prefixes to advertise, a larger number of exit points, and a larger number of BGP peering relationships. Unless symmetrical routing is not a must, especially in the case of NAT, most networks today run fine with asymmetrical routing.

‚  < ‚  Free Open Study ‚  > ‚  


Troubleshooting IP Routing Protocols
Troubleshooting IP Routing Protocols (CCIE Professional Development Series)
ISBN: 1587050196
EAN: 2147483647
Year: 2002
Pages: 260

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net