‚ < ‚ Free Open Study ‚ > ‚ |
Problem: Asymmetrical Routing Occurs and Causes a Problem Especially When NAT and Time-Sensitive Applications Are Used ‚ Cause: Outbound and Inbound AdvertisementAsymmetric 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 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:
Debugs and VerificationBecause 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. SolutionThe 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:
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:
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 LongerR2# 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 R4R4# 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 ‚ > ‚ |