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