For all routes originated by AS1 (customer local routes) such as 192.68.11.0/24, AS4 will go directly to AS1. For routes belonging to AS2 (customer transit routes), such as 192.68.10.0/24, AS4 will use the other provider AS3. For other routes advertised by the provider (ISP routes), AS4 will go directly to AS3.

The AS_Path Approach

As an alternative to the community approach, AS_path can be be used to achieve the desired routing in figure 11-9. In our example, RTC will prepend an extra AS entry in its routing updates toward AS4 for all routes received from AS2. AS4 will see AS2's updates with a longer path via AS1 and will go via AS3.

RTC configuration:

    router bgp 1
     network 192.68.11.0
     neighbor 172.16.20.2 remote-as 4
     neighbor 172.16.20.2 route-map setpath out
     neighbor 172.16.20.2 filter-list 10 out
     neighbor 192.68.6.1 remote-as 2
     no auto-summary

     ip as-path access-list 2 permit _2_

     ip as-path access-list 10 permit ^$
     ip as-path access-list 10 permit ^2$

     route-map setpath permit 10
     match as-path 2
     set as-path prepend 1

    route-map setpath permit 20

RTC has prepended an additional AS number 1 to its updates toward RTA. This is how RTA's BGP table will look:

    RTA#show ip bgp
    BGP table version is 9, 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
    *> 172.16.10.0/24   172.16.1.2     0       0 3 i
    *> 172.16.65.0/26   172.16.1.2     0       0 3 i
    *> 172.16.220.0/24  0.0.0.0       0     32768 i
    *> 192.68.10.0      172.16.1.2           0 3 2 i
    *              172.16.20.1         100   0 1 1 2 i
    *> 192.68.11.0      172.16.20.1   0    100  0 1 i

Note how RTA now prefers AS3 to reach prefix 192.68.10.0/24. Care must be taken to make sure that the provider AS1 is not using any access list to accept only routes of the form ^1$ or ^1 2$ from your AS. It is always good to coordinate with the provider regarding the changes you want to make.

Following Defaults Inside an AS

The following examples show how border routers can inject defaults inside your AS for your IGP to follow. Figure 11-10 illustrates the following scenario: AS3 is multihomed to two providers, AS1 and AS2. RTA is running EBGP with RTC, and RTF is running EBGP with RTD. Inside AS3, RTA and RTF are running IBGP. We will experiment with two situations: first, RTA and RTF having a direct physical connection and second, RTA and RTF not having a direct physical connection. The latter scenario is used to demonstrate what could go wrong if your IGP traffic is following a default that conflicts with your BGP policies. Finally, RTG is an interior router that is running an IGP; RTG is following the default route 0/0 to reach networks outside AS3.

Figure 11-10  Following defaults inside the AS; border routers connected.

The scenario where RTA and RTF are directly connected is easy; it is very hard for things to go wrong. As long as RTA and RTF are injecting defaults inside the IGP, traffic that reaches any of the BGP routers will find its way outside the AS. It is important that outbound traffic that reaches a BGP router does not go back to the non-BGP routers to avoid possible routing loops.

In case the border routers are not carrying full routes, they can accept a default to the providers to which they are connected. Both links can be used at the same time, or one link could be used as primary and the second as backup. Whichever policy you use, traffic will find its way out.

In the following configuration, RTA and RTF are accepting full routes from their respective providers. RTA and RTF are injecting defaults inside the AS (they are not getting any defaults themselves because they carry full routes). We will use OSPF as an IGP (other IGPs will be used in different scenarios later on).

RTA configuration:

    router ospf 10
     passive-interface Serial0
     network 172.16.0.0 0.0.255.255 area 0
     default-information originate always

     router bgp 3
     no synchronization
     network 172.16.1.0 mask 255.255.255.0
     network 172.16.70.0 mask 255.255.255.0
     network 172.16.220.0 mask 255.255.255.0
     neighbor 172.16.20.1 remote-as 1
     neighbor 172.16.20.1 filter-list 10 out
     neighbor 172.16.1.2 remote-as 3
     no auto-summary
    ip as-path access-list 10 permit ^$

RTF configuration:

    router ospf 10
     network 172.16.0.0 0.0.255.255 area 0
     default-information originate always

     router bgp 3
     no synchronization
     network 172.16.1.0 mask 255.255.255.0
     network 172.16.50.0 mask 255.255.255.0
     neighbor 172.16.1.1 remote-as 3
     neighbor 172.16.1.1 next-hop-self
     neighbor 192.68.5.2 remote-as 2
     neighbor 192.68.5.2 filter-list 10 out
     no auto-summary

    ip as-path access-list 10 permit ^$

RTG configuration:

    router ospf 10
     network 172.16.0.0 0.0.255.255 area 0

Note that the RTA and RTF configurations use the router command default-information originate with the always keyword. This command forces OSPF to inject a 0/0 default route into the OSPF domain at all times. The internal router RTG, which is running OSPF only, will receive the default from multiple sources and will follow the shortest internal metric. Routers that are closer (metric-wise) to RTA will use RTA for default; routers closer to RTF will use RTF.

    RTG#sh ip route
    Codes: C - connected, S - static, I - IGRP,
    R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF,
      IA - OSPF inter area
      N1 - OSPF NSSA external type 1,
      N2 - OSPF NSSA external type 2
      E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
      i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2,
      * - candidate default U - per-user static route, o - ODR
    Gateway of last resort is 172.16.70.1 to network 0.0.0.0
     172.16.0.0/16 is subnetted, 5 subnets
    O    172.16.220.0/24 [110/74] via 172.16.70.1,
    00:03:27, Serial0
    C    172.16.50.0/24 is directly connected, Serial1
    O    172.16.20.0/24 [110/74] via 172.16.70.1, 00:03:27, Serial0
    O    172.16.1.0/24 [110/74] via 172.16.70.1, 00:03:27, Serial0
    C    172.16.70.0/24 is directly connected, Serial0
    O*E2 0.0.0.0/0 [110/1] via 172.16.70.1, 00:03:27, Serial0

Note how RTG has set its gateway of last resort to RTA (172.16.70.1), which happens to be at a shorter internal metric than RTF.