- Difficult for migration to because the BGP process has to be deleted/restarted.
- Configuration:
- ‘router bgp <sub-as>’
- ‘bgp confederation-id <main-as>‘
- ‘bgp confederation-peers <sub-as1 sub-as>
- Only Sub-AS that the router is peering with.
Example configuration:
In the example above the scope of the confederations configuration is all within AS 100, and the sub-AS peer is 65005.
R1 is running EBGP (within the confederation) to R5 and iBGP to R6. The confederation configuration is very similar to regular BGP, it just has the two main commands, identifier and peers. The configuration on R3 and R2 are exactly the same except they have different Sub-AS numbers. R3 is below:
After this configuration on R1, R2, R3, and R5 there’s still no BGP adjacency between the different sub-AS’ – ie. R5 to R1 R3 and R2. The reason for this is because they’re all now technically running EBGP between each other. EBGP has the default rule that peers need to be directly connected, whereas iBGP has the default TTL 255. One of the fixes is to run the neighbor ‘disable-connected-check’.
After the above command is entered in both R1 and R5, adjacency comes up.
Another option to fix this is do EBGP Multi-hop. On R3 we’ll run the below command, as well as R5 for the other side.
After entering the command ‘neighbor 192.168.10.1 ebgp-multihop 2’ on both sides, adjacency comes up very quickly. The same thing will be done on R2 to R5.
Now on R5 after neighbor adjacencies are up, ‘show ip bgp’ will show the sub-AS numbers in the path to reach different destinations.
If we look at the ‘normal’ EBGP peering to R8 however, the path to these destinations all appear to be coming from AS 100.
mickx009.org 