Confederations propagate routes to all routers, without a full mesh of peers inside the entire AS. To do so, confederation eBGP peer connections act like true eBGP peers in some respects.
By the end of these steps, all the routers inside ASN 123 have learned of the 21.0.0.0/8 prefix. Also, ASN 678 (R6 in this case) learned of a route for that same prefix - a route that would work and would not have the black-hole effect. In fact, from ASN 678’s perspective, it sees a route that appears to be through ASNs 123 and 45. Also note that routers in sub-AS 65002 and 65003 will not advertise the prefix back into sub-AS 65001 because AS 65001 is already in the confederation AS_PATH.
ASNs 64512 through 65535 are private ASNs, meant for use in cases where the ASN will not be advertised to the Internet or other autonomous systems. By using private ASNs, a confederation can hopefully avoid the following type of problem.
The following list summarizes the key topics regarding confederations:
■ Inside a sub-AS, full mesh is required, because full iBGP rules are in effect.
■ The confederation eBGP connections act like normal eBGP connections in that iBGP routes are advertised—as long as the AS_PATH implies that such an advertisement would not cause a loop.
■ Confederation eBGP connections also act like normal eBGP connections regarding Time to Live (TTL), because all packets use a TTL of 1 by default. (TTL can be changed with the neighbor ebgp-multihop command.)
■ Confederation eBGP connections act like iBGP connections in every other regard for example, the NEXT_HOP is not changed by default.
■ Confederation ASNs are not considered part of the length of the AS_PATH when a router chooses the best routes based on the shortest AS_PATH.
■ Confederation routers remove the confederation ASNs from the AS_PATH in Updates sent outside the confederation; therefore, other routers do not know that a confederation was used.
Below a simple configuration for the topology in Figure:
In this internetwork topology, R1 is in sub-AS 65001, with R2 and R3 in sub-AS 65023. In this case, R1 and R3 will not be neighbors. The following list outlines the sequence of events to propagate a prefix:
1. R3 will learn prefix 21.0.0.0/8 through eBGP from AS 45 (R4).
2. R3 will advertise the prefix through iBGP to R2.
3. R2 will advertise the prefix through confederation eBGP to R1
R1# sh run | s router bgp
router bgp 65001 bgp router-id 1.1.1.1 bgp log-neighbor-changes bgp confederation identifier 123 bgp confederation peers 65023 neighbor 2.2.2.2 remote-as 65023 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback1 neighbor 2.2.2.2 next-hop-self neighbor 172.16.16.6 remote-as 678
R2# sh run | s router bgp
router bgp 65023 bgp log-neighbor-changes bgp confederation identifier 123 bgp confederation peers 65001 neighbor 1.1.1.1 remote-as 65001 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback1 neighbor 3.3.3.3 remote-as 65023 neighbor 3.3.3.3 update-source Loopback1
R3# sh run | s router bgp
router bgp 65023 bgp log-neighbor-changes bgp confederation identifier 123 neighbor 2.2.2.2 remote-as 65023 neighbor 2.2.2.2 update-source Loopback1 neighbor 2.2.2.2 next-hop-self neighbor 4.4.4.4 remote-as 45 neighbor 4.4.4.4 ebgp-multihop 2 neighbor 4.4.4.4 update-source Loopback1
R1 has received the 21.0.0.0/8 prefix, with sub-AS 65023 shown in parentheses, and true AS 45 shown outside the parentheses. R1 has also learned the same prefix via AS 678 and R6. The route through the sub-AS is best because it is the shortest AS_PATH; the shortest AS_PATH logic ignores the confederation sub-autonomous systems.
R1# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 21.0.0.0 3.3.3.3 0 100 0 (65023) 45 i
R6 shows its received update from R1, showing the removed sub-AS, and the inclusion of the true AS, AS 123.
R6# show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 21.0.0.0 172.16.16.1 0 123 45 i
biOos
