BGP confederation is implemented in order to reduce the IBGP mesh inside an AS. The trick is to divide an AS into multiple ASs and assign the whole group to a single confederation. Each AS by itself will have IBGP fully meshed and has connections to other AS's inside the confederation. Even though these ASs will have EBGP peers to ASs within the confederation, they exchange routing as if they were using IBGP; next hop, metric and local preference information are preserved. To the outside world, the confederation (the group of ASs) will look like a single AS.
To configure a BGP confederation use the following:
Peering within the confederation between multiple ASs is done via the following command:
Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also, but we are only interested in the BGP speakers that have EBGP connections to other ASs). If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router, 8 IBGP peers and one EBGP peer to external ASs.
By using confederation we can divide AS500 into multiple ASs: AS50, AS60 and AS70. We give the AS a confederation identifier of 500. The outside world will see only one AS500. For each AS50, AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.
Let's look at a sample configuration of routers RTC, RTD and RTA. Note that RTA has no knowledge of ASs 50, 60 or 70. RTA has only knowledge of AS500.
bgp confederation identifier autonomous−systemThe confederation identifier will be the AS number of the confederation group. The group of ASs will look to the outside world as one AS with the AS number being the confederation identifier.
Peering within the confederation between multiple ASs is done via the following command:
bgp confederation peers autonomous−system [autonomous−system]The following is an example of confederation:
Let us assume that you have an autonomous system 500 consisting of nine BGP speakers (other non BGP speakers exist also, but we are only interested in the BGP speakers that have EBGP connections to other ASs). If you want to make a full IBGP mesh inside AS500 then you would need nine peer connections for each router, 8 IBGP peers and one EBGP peer to external ASs.
By using confederation we can divide AS500 into multiple ASs: AS50, AS60 and AS70. We give the AS a confederation identifier of 500. The outside world will see only one AS500. For each AS50, AS60 and AS70 we define a full mesh of IBGP peers and we define the list of confederation peers using the bgp confederation peers command.
Let's look at a sample configuration of routers RTC, RTD and RTA. Note that RTA has no knowledge of ASs 50, 60 or 70. RTA has only knowledge of AS500.
RTC#
router bgp 50
bgp confederation identifier 500
bgp confederation peers 60 70
neighbor 128.213.10.1 remote−as 50 (IBGP connection within AS50)
neighbor 128.213.20.1 remote−as 50 (IBGP connection within AS50)
neighbor 129.210.11.1 remote−as 60 (BGP connection with confederation peer 60)
neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)
neighbor 5.5.5.5 remote−as 100 (EBGP connection to external AS100)
RTD#
router bgp 60
bgp confederation identifier 500
bgp confederation peers 50 70
neighbor 129.210.30.2 remote−as 60 (IBGP connection within AS60)
neighbor 128.213.30.1 remote−as 50(BGP connection with confederation peer 50)
neighbor 135.212.14.1 remote−as 70 (BGP connection with confederation peer 70)
neighbor 6.6.6.6 remote−as 600 (EBGP connection to external AS600)
RTA#
router bgp 100
neighbor 5.5.5.4 remote−as 500 (EBGP connection to confederation 500)
