BGP Confederations and Route Reflectors – A design overview.
Folks welcome back, in this section we would design a network that employs confederations and route-reflectors. Confederations help us divide a larger BGP autonomous system into smaller autonomous systems. Route-reflectors on the other hand are employed to suppress the split horizon rule of BGP (split horizon in BGP stops a router from advertizing a route it learned from an iBGP peer to another neighbor, because iBGP expects full mesh connectivity between all the routers running it).
To illustrate how these concepts come into play in a real network design, check out the diagram mentioned above. There are two main autonomous systems (AS) here, AS 10000 and AS 20000 (indicated by a red dotted line).I have split up AS 10000 into two confederation autonomous systems, AS 65010 to the left and AS 65020 to the right. Routers R1, R2 and R3 form a part of the confederation 65010 and router R4 & R5 form a part of confed 65020, (indicated by black dotted line encircling these routers). R6 is placed in an external AS of 20000 and has peering at two points with AS 10000, on router R2 and on router R4. Note that all the confederation autonomous system numbers should be in the range of 64512 to 65535, and are locally significant (think private IP address blocks)
Mentioned below is R1’s configuration:
Note that the BGP process of member routers takes the AS number of the confederation AS, hence R1’s running 65010.
R3 and R5 would have similar configurations as that of R1; all are internal confederation routers with no direct peering to the external networks.
Now let’s take a look at the R2’s configuration.
Most of the statements on R2 are self explanatory except for “bgp confederation identifier 10000” and “bgp confederation peer 65020”. Confederation identifier config identifies R2 as a part of the main autonomous system 10000 to the external router R6 on AS 20000. Note that this command is necessary only on the routers that interface with the external network in a confederation (for instance R1, R3 and R5 does not need this configuration). bgp confederation config on the other hand identifies R3 as a part of the confederation 65010 to R4, a similar config is needed on R4 to identify itself as a part of the confed 65020 to R2.
Taking a look at the R4’s config, it looks just like a mirror image of R3. Note that the bgp confederation peer on R4 is set to 64010 to mirror R3’s config’s.
Simple enough! Now let’s take a look at R6’s config’s and its routing tables.
R6 is unaware of any complexity within the AS 10000 and peers with the AS on R2 and R4; R6 sees the AS just as AS 10000.
Further looking at the routing table for R6 we see that all the routes R6 has learned are learned through autonomous system 10000 regardless of which confederation within autonomous system 10000 they originated from.
That completes our discussion on BGP confederations.
Let’s briefly take a look at the route reflectors now, consider router R1, R2 and R3 from the architecture, per BGP split horizon rule, R2 should not advertize the routes learned from R1 to any of its downstream routers, which in this case is R3. Rule was put in place because the creators of BGP saw that iBGP is deployed only on service provider cores, so full mesh connectivity of the routers was made mandatory. Which means there are is no need for one router to advertize its routes learned via iBGP to another neighbor. But when the routers are not run in full mesh connections, this rule becomes a pain in the a**. By making a peer a route reflector client, split horizon rule is selectively suppressed for that particular peer.
Now let’s remove the route reflector config from the R2;
Mentioned below is a snapshot of R1’s BGP topology table with the route-reflector client removed from R2. Note that R2 drops all the routes that it learned from iBGP neighbor R3 from being advertized to R1, but advertizes the routes that are learned via other EBGP neighbors to R1. As a result R3’s subnets 220.127.116.11/21 disappears from the routing table of R1.
Similarly R3 also gets all other routes, but for the ones originated by R1 (being advertized by R2 of course). Hence the subnets 10.1.0.0 /22 subnets vanish from the routing table.
Let’s now try putting the configurations back and see how it impacts the routing table
Once the change is made R1 starts seeing the 18.104.22.168/21 network once again,
Similarly we see the 10.1.0.0/22 subnet network once again on R3’s routing tables.
Note that there were some route-maps created on R2 to achieve the next hop changes to the network that were advertized between R1 and R3, without which the routes would not be accessible. I am not showing this step to limit the length of the article. The next-hop-self command on BGP peering relationships does not apply for route-reflector based routes (and Cisco and juniper opines it as a feature and not a bugJ).
Hope you enjoyed the article; stay tuned for more and have a nice summer.