390 394 ezvsba2wgoc7nualallnxgc6cwsmpxxds5ar7ni EZVSBA2WGOC7NUALALLNXGC6CWSMPXXDS5AR7NI





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














Wyszukiwarka

Podobne podstrony:
390 394 nb6nfq3lvtcpovqczyro5itxp4yjepjsn7zjiby
390 393
394 396
390 (2)
07 (394)
08 (390)
103907 kierownik firmy sprzatajacej
11 (390)
390,28,artykul

więcej podobnych podstron