Internet Routing Architectures, Second Edition

172.16.70.1 (metric 192) from 172.16.30.1 (172.16.220.1) Origin IGP, metric 0, localpref 100, valid, internal, best

Originator : 172.16.220.1, Cluster list: 172.16.65.1, 172.16.112.1

Note how RTD sees the originator of route 172.16.220.0/24 as 172.16.220.1, which is the ROUTER_ID of RTA. The route also carries a cluster list that contains the ROUTER_IDs of all the route reflectors it passed through.

In the case where multiple route reflectors are configured inside the cluster, all the route reflectors need to be configured with a common CLUSTER_ID. This is needed to detect routing loops that might occur between clusters. For example, if RTE were to be configured as a route reflector, the configurations for RTF and RTE would need the additional router command bgp cluster-id number. Example 12-72 shows the configuration for RTF.

Example 12-72. Multiple Route Reflectors: RTF Configuration

router bgp 3

no synchronization

network 172.16.65.0 mask 255.255.255.192 network 172.16.50.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor REFLECTORS peer-group

neighbor REFLECTORS remote-as 3 neighbor CLIENTS peer-group neighbor CLIENTS remote-as 3

neighbor CLIENTS route-reflector-client neighbor 172.16.25.2 peer-group CLIENTS neighbor 172.16.30.2 peer-group CLIENTS neighbor 172.16.50.2 peer-group REFLECTORS bgp cluster-id 1000

no auto-summary

The CLUSTER_ID is a number identifying the cluster. Each cluster must be assigned a unique value. This is needed in order to avoid looping in case RTF and RTE are both configured as route reflectors in the same cluster. Note that it's good practice to configure a CLUSTER_ID even if you're using a single route reflector. When you configure a CLUSTER_ID, no route reflector clients can be configured on the router. Therefore, if one isn't already defined, you must unconfigure all the existing clients, configure the CLUSTER_ID, and then reconfigure the clients. Therefore, defining the CLUSTER_ID value upon initial configuration is a good idea.

Confederations

For the scenario in Figure 12-14, you want to divide AS3 into two smaller sub-ASs, AS65050 and AS65060. The AS numbers of the sub-ASs are chosen from within the private AS pool range of 64512 to 65535. OSPF is used as the IGP in each sub-AS. The OSPF within AS65050 is running independently of the OSPF in AS65060, which means that the area numbers used in AS65050 can be reused in AS65060. This takes advantage of one of the benefits of BGP—namely, that IGPs in one AS run independently of IGPs in other ASs.

page 367

Internet Routing Architectures, Second Edition

Figure 12-14. Confederations

The configuration for RTA in Example 12-73 shows that RTA has all its interfaces in OSPF area 5. RTA is running EBGP with RTC in AS1 and is running IBGP with RTG in AS65050. Note that RTA uses the bgp confederation identifier 3 router subcommand to present itself to RTC as being part of confederation 3.

Example 12-73. Confederations: RTA Configuration

router ospf 10 passive-interface Serial0

network 172.16.0.0 0.0.255.255 area 5 router bgp 65050

no synchronization

bgp confederation identifier 3

network 172.16.220.0 mask 255.255.255.0 network 172.16.70.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.70.2 remote-as 65050 no auto-summary

ip as-path access-list 10 permit ^$

As shown in Example 12-74, RTC runs normal EBGP when talking to RTA. According to RTC, RTA belongs to AS3. RTC has no visibility to the sub-ASs inside confederation 3. RTC is also running EBGP with RTH in AS2.

Example 12-74. Confederations: RTC Configuration router bgp 1

network 192.68.11.0

neighbor 172.16.20.2 remote-as 3 neighbor 192.68.6.1 remote-as 2 no auto-summary

page 368

Internet Routing Architectures, Second Edition

RTG is the sub-AS65050 border router that is running confederation EBGP with router RTF in sub-AS65060. RTG is also running IBGP with RTA. RTG is an OSPF area border router that has a common area 5 with RTA and the rest of its interfaces in area 0. Note how RTG has disabled its OSPF processing on serial 1 (passive-interface Serial1), which is the common interface with RTF. Only EBGP is run on that link. Example 12-75 shows the configuration for RTG.

Example 12-75. Confederations: RTG Configuration

router ospf 10 passive-interface Serial1

network 172.16.70.2 0.0.0.0 area 5 network 172.16.0.0 0.0.255.255 area 0 router bgp 65050

no synchronization

bgp confederation identifier 3 bgp confederation peers 65060

network 172.16.112.0 mask 255.255.255.0 network 172.16.50.0 mask 255.255.255.0 network 172.16.70.0 mask 255.255.255.0 neighbor 172.16.50.1 remote-as 65060 neighbor 172.16.50.1 next-hop-self neighbor 172.16.70.1 remote-as 65050 no auto-summary

RTG also identifies itself as being part of confederation 3 (bgp confederation identifier 3). RTG uses the router command bgp confederation peers 65060 to preserve all the attributes, such as local preference and next hop when traversing the EBGP session to AS65060. This will make the confederation EBGP session with sub-AS65060 look like an IBGP session. The neighbor 172.16.50.1 next-hop-self command will set the next-hop address of routes going from RTG to RTF to RTG's IP address. Without this command, the next-hop address of all EBGP routes from AS1 will be sent to RTF with the external next hop 172.16.20.1, which is acceptable only as long as routers in sub-AS65060 can reach it from within the confederation.

As illustrated in Example 12-76, the same configuration that is in RTG applies to RTF, which is the border router of sub-AS65060. RTF is also an area border router in areas 0 and 5. Areas 0 and 5 in AS65060 are totally independent of areas 0 and 5 in AS65050. The two IGPs are shielded from each other by BGP. Full-mesh IBGP sessions are configured between RTE, RTD, and RTF using the peer group SUB_AS_65060.

Example 12-76. Confederations: RTF Configuration

router ospf 10 passive-interface Serial2/1

network 172.16.25.1 0.0.0.0 area 5 network 172.16.0.0 0.0.255.255 area 0 router bgp 65060

no synchronization

bgp confederation identifier 3 bgp confederation peers 65050

network 172.16.65.0 mask 255.255.255.192 network 172.16.50.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor SUB_AS_65060 peer-group

page 369

Internet Routing Architectures, Second Edition

neighbor SUB_AS_65060 remote-as 65060 neighbor 172.16.25.2 peer-group SUB_AS_65060 neighbor 172.16.30.2 peer-group SUB_AS_65060 neighbor 172.16.50.2 remote-as 65050 neighbor 172.16.50.2 next-hop-self

RTD is a border router for confederation 3. As demonstrated in Example 12-77, RTD is running EBGP with RTH in AS2 and a full IBGP mesh with routers RTE and RTF in subAS65060. RTD has all its interfaces in area 0. RTD is not running OSPF on the external link to AS2. This is why the next hop of external updates coming to RTD has to be set to self before the routes are propagated to RTF and RTE.

Example 12-77. Confederations: RTD Configuration

router ospf 10

network 172.16.0.0 0.0.255.255 area 0.0.0.0 router bgp 65060

no synchronization

bgp confederation identifier 3 network 172.16.90.0 mask 255.255.255.0 network 172.16.30.0 mask 255.255.255.0 neighbor 172.16.25.2 remote-as 65060 neighbor 172.16.25.2 next-hop-self neighbor 172.16.30.1 remote-as 65060 neighbor 172.16.30.1 next-hop-self neighbor 192.68.20.2 remote-as 2

neighbor 172.16.20.2 filter-list 10 out no auto-summary

ip as-path access-list 10 permit ^$

As illustrated in Example 12-78, RTE has all its interfaces in OSPF area 5 and is running a full IBGP mesh with RTF and RTD.

Example 12-78. Confederations: RTE Configuration

router ospf 10

network 172.16.0.0 0.0.255.255 area 5 router bgp 65060

no synchronization

bgp confederation identifier 3 network 172.16.60.0 mask 255.255.255.0 network 172.16.25.0 mask 255.255.255.0 neighbor 172.16.25.1 remote-as 65060 neighbor 172.16.30.2 remote-as 65060 no auto-summary

As Example 12-79 shows, RTH is a BGP border router in AS2 that is running EBGP with AS1 and AS3. RTH has no visibility to the sub-AS in confederation 3.

Example 12-79. Confederations: RTH Configuration

router bgp 2 network 192.68.222.0

neighbor 192.68.6.2 remote-as 1

page 370

Internet Routing Architectures, Second Edition

neighbor 192.68.20.1 remote-as 3 no auto-summary

Now let's look at some excerpts from the BGP tables.

In Example 12-80, note how RTH sees all routes via two paths—one via AS1 and one via AS3. As you can see, all the sub-ASs are hidden from RTH.

Example 12-80. Confederations: RTH BGP Table

RTH#show ip bgp

BGP table version is 477, local router ID is 192.68.222.1 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Looking at RTA's BGP table in Example 12-81, all the sub-ASs are indicated between parentheses. Any path taken between sub-ASs has a length of 0. Note how prefix 192.68.222.0/24 is learned via two paths—one internal via (65060) 2, and the other external via 1 2. The path length of the internal route via (65060) 2 is considered to be shorter because the sub-ASs are not counted in calculating the path length. This is why the internal path has been chosen over the external path.

Example 12-81. Confederations: RTA BGP Table

RTA#show ip bgp

BGP table version is 13, local router ID is 172.16.220.1

Status codes: s suppressed, d damped, h history, ? valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

page 371