In the last article, we discussed and configured one of the technologies that can be used to reduce the requirement of fully meshed IBGP peers within an AS. In this article, we will be discussing the second method which is by making use of Confederations.
CCNA Training – Resources (Intense)
Our network diagram for this solution is as shown below:
Two articles ago, we described how Confederations work: an AS is broken down into smaller member ASs. Within a member AS, IBGP peering still needs to be fully meshed (except when combining route reflectors with confederations) but between member ASs, we use a variation of EBGP.
There are a couple of terms we need to be familiar with when configuring confederations. The first one is the AS Confederation which is the collection of the smaller member ASs. The AS Confederation is identified by an AS Confederation Identifier and this identifier is the AS number that is advertised to external peers of that confederation. In our network diagram above, the AS Confederation ID of R1 to R5 is 1 (i.e. AS 1).
The second terminology is the Member AS which represents an AS that is contained within the confederation. Member ASs are represented by Member AS Numbers like 65000 and 65001 in our network diagram above. To avoid clashing with real AS numbers assigned on the Internet, member AS numbers are usually taken from the private use AS numbers, between 64512 and 65534.
The configuration of confederations is fairly similar to how we configure normal BGP sessions. The difference is that the BGP process ID will now be the member AS number rather than the AS Confederation ID. We then configure the BGP speakers with the AS Confederation ID using the bgp confederation identifier command. We will also use the bgp confederation peers command to specify the member ASs that are part of the confederation. We only need this command on the BGP speakers that will be forming EBGP sessions within the confederation (i.e. R2 and R4).
The configuration on the routers R2 and R4 are similar because they both have the confederation ID and the confederation peers are configured as follows:
hostname R2 ! interface Loopback0 ip address 18.104.22.168 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.12.2 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.23.2 255.255.255.0 ! interface FastEthernet1/0 ip address 192.168.24.2 255.255.255.0 ! interface FastEthernet2/0 ip address 192.168.26.2 255.255.255.0 ! router ospf 1 passive-interface FastEthernet1/0 passive-interface FastEthernet2/0 network 22.214.171.124 0.0.0.0 area 0 network 192.168.0.0 0.0.255.255 area 0 ! router bgp 65000 no synchronization bgp confederation identifier 1 bgp confederation peers 65001 redistribute ospf 1 network 126.96.36.199 mask 255.255.255.255 neighbor 192.168.12.1 remote-as 65000 neighbor 192.168.23.3 remote-as 65000 neighbor 192.168.24.4 remote-as 65001 neighbor 192.168.26.6 remote-as 6 no auto-summary !
hostname R4 ! interface FastEthernet0/0 ip address 192.168.45.4 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.24.4 255.255.255.0 ! interface FastEthernet1/0 ip address 192.168.47.4 255.255.255.0 ! router ospf 1 passive-interface FastEthernet0/1 passive-interface FastEthernet1/0 network 188.8.131.52 0.0.0.0 area 0 network 192.168.0.0 0.0.255.255 area 0 ! router bgp 65001 no synchronization bgp confederation identifier 1 bgp confederation peers 65000 redistribute ospf 1 neighbor 192.168.24.2 remote-as 65000 neighbor 192.168.45.5 remote-as 65001 neighbor 192.168.47.7 remote-as 7 no auto-summary !
Also, the configuration of the internal peers in the member ASs (i.e. R1, R3 and R5 are also similar). The only thing they have configured is the confederation ID.
hostname R1 ! interface Loopback0 ip address 184.108.40.206 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.12.1 255.255.255.0 ! router ospf 1 network 220.127.116.11 0.0.0.0 area 0 network 192.168.12.0 0.0.0.255 area 0 ! router bgp 65000 no synchronization bgp confederation identifier 1 network 18.104.22.168 mask 255.255.255.255 neighbor 192.168.12.2 remote-as 65000 neighbor 192.168.23.3 remote-as 65000 no auto-summary !
hostname R3 ! interface FastEthernet0/0 ip address 192.168.23.3 255.255.255.0 ! router ospf 1 network 22.214.171.124 0.0.0.0 area 0 network 192.168.23.0 0.0.0.255 area 0 ! router bgp 65000 no synchronization bgp confederation identifier 1 neighbor 192.168.12.1 remote-as 65000 neighbor 192.168.23.2 remote-as 65000 no auto-summary !
hostname R5 ! interface Loopback0 ip address 126.96.36.199 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.45.5 255.255.255.0 ! router ospf 1 network 188.8.131.52 0.0.0.0 area 0 network 192.168.45.0 0.0.0.255 area 0 ! router bgp 65001 no synchronization bgp confederation identifier 1 network 184.108.40.206 mask 255.255.255.255 neighbor 192.168.45.4 remote-as 65001 no auto-summary !
Notice that there is fully meshed IBGP between all the BGP speakers in a particular member AS. This is evident in AS 65000 where we have three BGP speakers – R1, R2 and R3. This tells us that unlike Route Reflection, Confederation does not remove the requirement for fully meshed IBGP within a member AS.
Finally, the configuration for R6 and R7 are standard BGP configuration for EBGP peering. However, notice that the neighbor configuration for R2 on R6 specifies the remote-as 1 and not 65000. Likewise, the neighbor configuration for R4 on R7 specifies the remote-a 1 and not 65001. This is because member ASs are not visible outside the local confederation; they are represented as a single entity by the confederation ID.
hostname R6 ! interface Loopback0 ip address 220.127.116.11 255.255.255.255 ! interface FastEthernet0/0 ip address 192.168.26.6 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.67.6 255.255.255.0 ! router bgp 6 no synchronization network 18.104.22.168 mask 255.255.255.255 neighbor 192.168.26.2 remote-as 1 neighbor 192.168.67.7 remote-as 7 no auto-summary !
hostname R7 ! interface FastEthernet0/0 ip address 192.168.47.7 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.67.7 255.255.255.0 ! router bgp 7 no synchronization neighbor 192.168.47.4 remote-as 1 neighbor 192.168.67.6 remote-as 6 no auto-summary !
Remember that we said Confederations add two new segment types to the AS_PATH attribute: AS_CONFED_SEQUENCE and AS_CONFED_SET. We will now see how these segment types are used when routing information is exchanged.
Note: The same way we don’t see AS_SET as much except during aggregation, we will also not see AS_CONFED_SET.
Scenario #1: Route advertisement within the same member AS
When a BGP speaker advertises a route to a peer within the same member AS, it does not alter the AS_PATH attribute. This is like in normal IBGP advertisement. Therefore, when R2 advertises the 22.214.171.124/32 prefix to R1, the AS_PATH remains the same.
Scenario #2: Route advertisement to another member AS (within the same confederation)
Since member ASs have a special type of EBGP peering between them, a BGP speaker will prepend its member AS number to the AS_PATH attribute. What makes this EBGP peering special is that unlike normal EBGP sessions, the NEXT_HOP, MED and LOCAL_PREF attributes are preserved just like IBGP exchange.
Therefore, when R2 advertises the 126.96.36.199/32 prefix to R4, it will prepend “65000” to the AS_PATH attribute. Also, the NEXT_HOP, MED and LOCAL_PREF values are unchanged.
Notice how the “65000” is contained in brackets on R4 to signify that it came from another member AS within the confederation. The packet capture for the 188.8.131.52/32 UPDATE is shown below. You can see that the “65000” member AS number was carried in the AS_CONFED_SEQUENCE segment type.
Scenario #3: Route advertisement to an external peer
Since member ASs should only be visible within a confederation, route advertisements to external peers must be stripped of any member ASs numbers. Also, like normal EBGP, the BGP speaker will prepend its AS number (in this case, its AS Confederation ID) in the AS_PATH attribute.
Therefore, when R2 advertises the 184.108.40.206/32 prefix to R6, it will remove the 65001 member AS number. It will then add the AS Confederation ID of 1. Also, since this is a normal EBGP session, R2 will change the value of the NEXT_HOP attribute to its own address.
Scenario #4: Locally-originated route advertisement
What happens with locally-originated route advertisement is fairly easy to infer. For example, when R2 advertises its locally-originated 220.127.116.11/32 prefix to R1 (a BGP speaker within the same member AS), the AS_PATH attribute is empty.
Also, when a locally-originated route is advertised to a BGP speaker is another member AS within the same confederation, the advertising BGP speaker will include its member AS number in the AS_CONFED_SEQUENCE segment type of the AS_PATH attribute. For example, when R2 is advertising the 18.104.22.168/32 prefix to R4, the member AS number will be contained within AS_CONFED_SEQUENCE segment type of the AS_PATH attribute as shown below:
Finally, when a locally originated route is advertised to an external peer (outside the confederation), the advertising BGP speaker will add its AS confederation ID to the AS_SEQUENCE segment type of the AS_PATH attribute.
One last thing I would like to point out is that the AS_CONFED_SEQUENCE and AS_CONFED_SET segment types are not counted when considering AS_PATH length. For example, look at prefix 22.214.171.124/32 on R4 learned from both R2 and R7. The AS_PATH of the one learned from R2 is “(65000) 6” while that of the route learned from R7 is “7 6”.
The reason R4 selected the path through R2 as the best path is because that path has an AS_PATH length of 1 (the 65000 is not counted) while the path through R7 has an AS_PATH length of 2.
In this article, we have seen how to use Confederations to reduce the number of IBGP peering sessions within an AS. In our scenario, instead of having 10 IBGP peering sessions inside AS1, we have 4 IBGP peering sessions and 1 special EBGP peering session using confederations.
One of the issues with using Confederations is that it is quite intrusive because we will need to reconfigure all the BGP speakers within an AS to use Confederations. Also, all the BGP speakers within a Confederation must support the Confederation feature unlike in the case of route reflectors.
I hope you have found this article useful and I look forward to the next one in the series.
References and further reading
RFC 5065: Autonomous System Confederations for BGP: http://tools.ietf.org/html/rfc5065
Internet Routing Architectures 2nd Edition by Sam Halabi and Danny McPheron.
BGP Case Studies: BGP Confederation: http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html#bgpconfed
BGP Confederations: https://learningnetwork.cisco.com/docs/DOC-11844
RFC 6996: Autonomous System (AS) Reservation for Private Use: http://tools.ietf.org/html/rfc6996