One of the things to take into account when working with iBGP is the necessity of a full-mesh BGP topology. As we already know, BGP has the rule of not announcing to iBGP neighbors what has been learned from another iBGP peer, so that’s why we need to build a full-mesh BGP topology.
As we have mentioned in other posts, there are two alternatives to the full-mesh BGP topology:
- Route-Reflectors
- Confederations
In my last post I already talked about Route-Reflectors. Today I want to focus on Confederations.
BGP Confederations
With confederations we partition the whole AS network in sub-AS, without needing to build a full-mesh topology between all the BGP routers involved in the network. Each confederation, or sub-autonomous system, will have a full-mesh BGP topology between the routers forming the confederation. But between confederations, the behaviour will be more like eBGP sessions with some differences (in fact, it’s called Confederation BGP, cBGP). Each confederation has a different sub-AS number, usually a private one (from 64512 to 65534).
The topology we will focus on its as follows:
Two things are necessary to build a confederation:
- The private sub-ASNs that will be used in the confederations (64990 and 64991 in our topology)
- The ASN that the whole confederations system will assume towards true eBGP sessions (2222 in our topology)
Routers in confederations can have 3 types of BGP sessions:
- Regular iBGP sessions: with routers inside the same sub-AS. All these routers having iBGP sessions must have the same ASN to identify the BGP process (64990 and 64991 in our topology). Furthermore, it’s necessary to build a full-mesh iBGP topology inside each sub-AS. All the rules for iBGP sessions apply here.
- cBGP sessions: the BGP session built between sub-AS is called cBGP (confederation BGP), and its characteristics are a mix between iBGP and eBGP sessions. The topology between sub-AS doesn’t need to be full-mesh.
- Regular eBGP sessions: the whole confederations system behaves as a unique ASN towards eBGP sessions. All the rules for eBGP sessions apply here.
Every router inside the confederations system must know the ASN of its sub-AS, the ASNs peers inside the confederations system, and the ASN that the whole confederations system will assume towards eBGP sessions.
The configuration of each router in the example is as follows:
Configuration on R1:
router bgp 1111
network 100.100.100.0 mask 255.255.255.0 route-map LOOPBACK
neighbor 20.20.12.2 remote-as 2222
Configuration on R2:
router bgp 64990 bgp confederation identifier 2222 bgp confederation peers 64991 neighbor 3.3.3.3 remote-as 64990 neighbor 3.3.3.3 update-source Loopback0 neighbor 3.3.3.3 next-hop-self neighbor 4.4.4.4 remote-as 64990 neighbor 4.4.4.4 update-source Loopback0 neighbor 4.4.4.4 next-hop-self neighbor 20.20.12.1 remote-as 1111
Configuration on R3:
router bgp 64990 bgp confederation identifier 2222 bgp confederation peers 64991 neighbor 2.2.2.2 remote-as 64990 neighbor 2.2.2.2 update-source Loopback0 neighbor 4.4.4.4 remote-as 64990 neighbor 4.4.4.4 update-source Loopback0
Configuration on R4:
router bgp 64990 bgp confederation identifier 2222 bgp confederation peers 64991 neighbor 2.2.2.2 remote-as 64990 neighbor 2.2.2.2 update-source Loopback0 neighbor 3.3.3.3 remote-as 64990 neighbor 3.3.3.3 update-source Loopback0 neighbor 5.5.5.5 remote-as 64991 neighbor 5.5.5.5 update-source Loopback0 neighbor 5.5.5.5 ebgp-multihop 2
Configuration on R5:
router bgp 64991 bgp confederation identifier 2222 bgp confederation peers 64990 neighbor 4.4.4.4 remote-as 64990 neighbor 4.4.4.4 update-source Loopback0 neighbor 4.4.4.4 ebgp-multihop 2 neighbor 6.6.6.6 remote-as 64991 neighbor 6.6.6.6 update-source Loopback0
Configuration on R6:
router bgp 64991 bgp confederation identifier 2222 bgp confederation peers 64990 network 166.166.166.0 mask 255.255.255.0 neighbor 5.5.5.5 remote-as 64991 neighbor 5.5.5.5 update-source Loopback0
We must pay attention to the BGP session between R4 and R5. They belong to different confederations, so the BGP session that they build up is a cBGP. This means some rules from eBGP apply here. And one of the rules is the bgp-multihop limit of 1. In order to build a BGP session between routers of different confederations, we need to use either the interface IP or the command ebgp-multihop 2.
Now, let’s have a look to the AS_Path attribute inside the confederations system. Let’s check how the Loopback 100.100.100.1/24 from R1 is seen by R6:
R6#show ip bgp
BGP table version is 5, local router ID is 6.6.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i100.100.100.0/24 2.2.2.2 0 100 0 (64990) 1111 i
*> 166.166.166.0/24 0.0.0.0 0 32768 i
R6#
R6#show ip bgp 100.100.100.0/24
BGP routing table entry for 100.100.100.0/24, version 5
Paths: (1 available, best #1, table default)
Not advertised to any peer
(64990) 1111
2.2.2.2 (metric 31) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
You see that? The new AS_Path is (64990) 1111. Inside the confederations system, the AS_Path grows based on the eBGP rule: all the ASN confederations for which the BGP announcement passes through are added between brackets to the AS_Path attribute.
Well, nice. Let’s see how the Loopback 166.166.166.66/24 from R6 is seen by R2:
R2#sh ip bgp
BGP table version is 3, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.0/24 20.20.12.1 0 0 1111 i
*>i166.166.166.0/24 6.6.6.6 0 100 0 (64991) i
R2#
R2#sh ip bgp 166.166.166.0/24
BGP routing table entry for 166.166.166.0/24, version 3
Paths: (1 available, best #1, table default)
Advertised to update-groups:
8
(64991)
6.6.6.6 (metric 31) from 4.4.4.4 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
And now, by R1:
R1#sh ip bgp
BGP table version is 8, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.0/24 0.0.0.0 0 32768 i
*> 166.166.166.0/24 20.20.12.2 0 2222 i
R1#
R1#sh ip bgp 166.166.166.0/24
BGP routing table entry for 166.166.166.0/24, version 8
Paths: (1 available, best #1, table default)
Not advertised to any peer
2222
20.20.12.2 from 20.20.12.2 (2.2.2.2)
Origin IGP, localpref 100, valid, external, best
As we can see, towards R1 the info comes from the ASN 2222. All the confederations system topology are hidden to R1.
In the following table we can find how the different attributes of BGP are seen when working with confederations:
| FEATURE | SEEN IN THE CONFEDERATION |
| Peering | There is no need for full-mesh peering between sub-autonomous systems.
Within each sub-AS, full-mesh peering is required (or route-reflectors used).
|
| Communications between peers | iBGP is used within each sub-AS
cBGP is used between sub-autonomous systems, similar to eBGP but with the following differences:
|
| Additions to the BGP attributes | Enhancements to the AS_Path attribute, adding the sub-AS IDs.
This enhancement is not advertised to the external Autonomous Systems.
|
| Handling of next-hop attribute | Although there is eBGP like communication between sub-autonomous systems, next-hop attribute is preserved and passed, in opposition to the eBGP rule |
| Handling of Local Preference attribute | Although there is eBGP like communication between sub-autonomous systems, the local preference attribute is preserved and passed, in opposition to eBGP rule. |
| Handling of MED attribute | Although there is eBGP like communication between sub-autonomous systems, the MED attribute is preserved and passed, in opposition to eBGP rule. |
| Readvertising a learned prefix | Because the protocol between sub-autonomous systems is like eBGP, the prefixes learned from another sub-AS can be readvertised to other sub-autonomous systems if they are selected as best. |
| Communications with non member BGP peers | If a member of the confederation is peering with a BGP peer located in another AS, the sub-AS numbers located in the AS_Path attribute are supressed and only the confederation number is passed within the AS_Path attribute. |
| User of multi-hop parameter | Might be needed. cBGP is a derivative of eBGP. Therefore, if the peer IP address is not configured as the interface IP address of the neighbor, multihop setting will be needed. |
Things to remember
Some things useful to remember when facing confederations:
- Confederations are another alternative to the iBGP full-mesh topology.
- Inside a confederation, all the routers must be in full-mesh (or in a route-reflector topology), and the iBGP rules apply.
- Between confederations, the multihop limit is 1, so either it’s changed to 2, or the IP of the interface directly connected is used to build the session.
- The next-hop attribute is not changed, and is passed to the next confederation peer.
- The AS_Path attribute is modified inside the confederation with the sub-autonomous ASNs. When announcing to an external AS, the sub-autonomous ASNs are supressed and only the ASN of the whole confederations system is added.
No comments:
Post a Comment