Posted on Tuesday, 13th September 2005 by sean
Scaling Internal BGP can be a challenge. Every iBGP router must have a peer with every other iBGP router within an AS.
Why?
BGP uses the AS-PATH attribute for loop prevention. However, the AS is only prepended between eBGP neighbours, so it will never appear in iBGP.
However, this means that you must configure n-1 peers on every one of your n routers, for a total of n^2-n configuration statement.
Route reflectors (RR) reduce the peering by designating a route reflector (or multiple route reflectors) that are allowed to relay update messages between iBGP peers. Since it’s only the RR that has to worry about loop prevention, the peers themselves don’t know they’re connecting to an RR, and therefore don’t need any special configuration.
RFC 2796 – BGP Route Reflection – An Alternative to Full Mesh IBGP defines the behaviour of Route Reflectors.
Consider the following network:
If AS2 sends an update into AS1, the router receiving it sends an update to all its peers, who aren’t allowed to send it along to other peers (hence the full mesh requirement).
Now, remove some of the iBGP connections and turn the top two routers in AS1 into route reflector clients of the bottom right router as follows (note, I also added AS3 into the mix, ignore it for now):
The three routers in the route reflector arrangement form a route reflector cluster. From the perspective of an outside peer, such as the bottom left router in AS1, the RR cluster appears to be a single peer, also called a non client peer.
When AS2 sends in an update, the non client peer only has one neighbour to send it to, so it sends it to the route reflector server. The server knows where it received it from, and knows that it must relay this message to its clients, so it does. The clients are blissfully unaware that they are in a cluster, and follow the rules by not sending the message to anyone else.
Now, if AS3 sends an update to the RR client, it sends it to its only peer, the RR itself. The RR then sends the updates to the other client peers (following split horizon, it does not send it back to the peer that sent it to him), and to its non client peers.
This brings up three possible scenarios
Non client peer receives update – Sends an update to all its peers. This is the normal iBGP behaviour
Client peer receives update – Sends an update to all its peers who must be route reflectors. The RRs then relay this message to all the RR clients, and any configured non client peers
Route reflector receives update – sends to all its RR clients and non client peers.
Again, if you think of an RR cluster as a single iBGP router, the normal iBGP rules still apply.
In order to avoid routing loops, some new path attributes are added:
ORIGINATOR_ID – created by the route reflector, this specifies the routerid of the router that originated the route. This is needed because in iBGP, everyone knows who originated the route.
CLUSTER_LIST – contains the list of clusterids (ie route reflector groups) that the route has passed through. This is for loop prevention.
Next article will get into the configuration… Just have to retool my lab a bit.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
Posted in Routing | Comments (0)
