Internet Routing Architectures (CISCO):Configurinbg Effective Internet Routing Policies Previous Table of Contents Next In the same manner, RTF will be configured to announce the SF prefixes on the NY link with an extra path length. This would make inbound traffic toward these networks preferred via the SF link. RTF configuration: router bgp 3 no synchronization network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0 neighbor 172.16.2.254 remote-as 3 neighbor 172.16.2.254 next-hop-self neighbor 192.68.5.2 remote-as 2 neighbor 192.68.5.2 route-map PREPEND_PATH out no auto-summary ip as-path access-list 2 permit ^$ access-list 1 permit 172.16.220.0 0.0.0.255 route-map PREPEND_PATH permit 10 match ip address 1 set as-path prepend 3 route-map PREPEND_PATH permit 20 match as-path 2 Note that RTF is accepting all routes from AS2 and is advertising only the local routes ^$ with an extra path length added for the SF route 172.16.220.0/24. The following is a snapshot of some of the BGP routing tables. RTA#sh ip bgp BGP table version is 13, local router ID is 172.16.2.254 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0 172.16.20.1 0 1 i *> 172.16.1.0/24 0.0.0.0 0 32768 i * i 172.16.1.2 0 100 0 i *> 172.16.10.0/24 172.16.1.2 20 32768 i * i 172.16.1.2 0 100 0 i *> 172.16.65.0/26 172.16.1.2 20 32768 i * i 172.16.1.2 0 100 0 i *> 172.16.220.0/24 0.0.0.0 0 32768 i * i 172.16.1.2 20 100 0 i *>i192.68.6.0 172.16.1.2 0 100 0 2 i *> 192.68.11.0 172.16.20.1 0 0 1 i *>i193.78.0.0/16 172.16.1.2 100 0 2 7 8 i Note how RTA is learning a default 0/0 from RTC. RTA is also learning AS1's local routes (such as 192.68.11.0/24) and can reach those directly via the SF link. For all other routes, RTA will go via the NY link. On the other hand, inbound traffic will follow the shortest path. The following table shows how an outside AS that falls behind the NAP, such as AS6, can reach AS3's networks. RTG#sh ip bgp BGP table version is 9, local router ID is 192.68.40.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.1.0/24 192.68.10.1 0 7 2 3 i *> 172.16.10.0/24 192.68.10.1 0 7 2 3 i *> 172.16.65.0/26 192.68.10.1 0 7 2 3 i *> 172.16.220.0/24 192.68.10.3 0 7 1 3 i *> 192.68.6.0 192.68.10.1 0 7 2 i *> 192.68.11.0 192.68.10.3 0 7 1 i *> 192.68.40.0 0.0.0.0 0 32768 i *> 193.78.0.0/16 192.68.10.2 0 7 8 i Note that the NY prefixes 172.16.10.0/24 and 172.16.65.0/26 are reachable via the NY link (path 7 2 3). The SF prefix 172.16.220.0/24 is reachable via the SF link (path 7 1 3). Customers of the Same Provider with a Backup Link Customers of the same provider can, by mutual agreement, interconnect via a private link. The private link will serve as a backup in case the Internet connectivity of any of the customers is broken. The following scenario discusses a case where the private link is used as the primary link between the two ASs and as a backup in case of Internet connectivity failures. In this example, we will switch roles a bit. In figure 11-8, AS3 is the provider offering services to two of its customers, AS1 and AS2. AS1 and AS2 agree to use each other as backup in case their links to AS3 fail. In normal conditions, AS1 and AS2 will use the private link only for traffic between AS1 and AS2; for all other Internet traffic, the direct link to the provider AS3 is used. Figure 11-8  Backup—private link used as primary. We will assume that AS1 and AS2 are getting full Internet routes. AS1 and AS2 should advertise each other's routes to AS3 because, for the backup behavior to occur, AS3 should be able to reach AS1's routes via AS2 and AS2's routes via AS1. Normally, this scenario is handled automatically by the BGP default behavior. Due to the shortest path rule, AS1 and AS2 will always reach each other's networks over the private link. For the sake of experimenting with setting BGP policies we will attempt to solve this problem by manipulating the local preference attribute. We will concentrate on the router configuration of RTC; RTD's configuration should be similar. RTC configuration: router bgp 1 network 192.68.11.0 neighbor 172.16.20.2 remote-as 3 neighbor 172.16.20.2 route-map PREF_FROM_AS3 in neighbor 192.68.6.1 remote-as 2 neighbor 192.68.6.1 route-map PREF_FROM_AS2 in no auto-summary ip as-path access-list 1 permit _2_ route-map PREF_FROM_AS3 permit 10 match as-path 1 set local-preference 100 route-map PREF_FROM_AS3 permit 20 set local-preference 300 route-map PREF_FROM_AS2 permit 10 set local-preference 200 Previous Table of Contents Next