It is important to remember when doing confederations that although external confederation peers behave like EBGP peers in several ways, they do NOT modify the next hop without manual configuration.
Example:
R4 --- [[R1---R3]---[R2]]---R5
R1, R2 and R3 are in AS#2 as far as R4 and R5 are concerned. But R1 and R3 share sub-AS 65013, and R2 is in sub-AS 65002. Confederations allow R3 to advertise routes learned from R1 to R2 and vice-versa. Without confederations, this would not happen because routes learned from IBGP neighbors do not get advertise to other IBGP neighbors.
Confederations allow this to happen but be careful with the next hop attribute. When R2 passes routes learned from R5 to R3, it will not modify the next hop, but instead leave it pointing to R5. You must use the next-hop-self argument on the neighbor command to allow R3 to install these routes (unless R3 has a route to the R2-R5 network).
Suppose the network in questions is 155.1.5.0/24. Here is the output of show ip bgp before the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 5
Paths: (1 available, no best path)
Flag: 0x208
Not advertised to any peer
(65002) 1
155.1.0.5 (inaccessible) from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external
And after the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Advertised to non peer-group peers:
155.1.13.1
(65002) 1
155.1.23.2 from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external, best
Example:
R4 --- [[R1---R3]---[R2]]---R5
R1, R2 and R3 are in AS#2 as far as R4 and R5 are concerned. But R1 and R3 share sub-AS 65013, and R2 is in sub-AS 65002. Confederations allow R3 to advertise routes learned from R1 to R2 and vice-versa. Without confederations, this would not happen because routes learned from IBGP neighbors do not get advertise to other IBGP neighbors.
Confederations allow this to happen but be careful with the next hop attribute. When R2 passes routes learned from R5 to R3, it will not modify the next hop, but instead leave it pointing to R5. You must use the next-hop-self argument on the neighbor command to allow R3 to install these routes (unless R3 has a route to the R2-R5 network).
Suppose the network in questions is 155.1.5.0/24. Here is the output of show ip bgp before the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 5
Paths: (1 available, no best path)
Flag: 0x208
Not advertised to any peer
(65002) 1
155.1.0.5 (inaccessible) from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external
And after the change:
R3#show ip bgp 155.1.5.0
BGP routing table entry for 155.1.5.0/24, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
Advertised to non peer-group peers:
155.1.13.1
(65002) 1
155.1.23.2 from 155.1.23.2 (155.1.23.2)
Origin IGP, metric 0, localpref 100, valid, external, best
