Question on comparison:BGP full mesh vs Route Refl. vs Confederations

Unanswered Question
Nov 20th, 2009


Imagine that in order to overcome the looping prevention mechanism of iBGP (in this specific case, not advertising prefixes into the IGP routing table which were learned from iBGP), one could implement route-reflectors or confederations.


As far as performance goes (CPU, memory consumption, latency), which method still offers better performance overall? I just would like to confirm the practical cons and pros of full-mesh vs route-reflectors vs confederations from a performance viewpoint.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Danilo Dy Sat, 11/21/2009 - 09:49

Full mesh iBGP consume cpu and memory very quickly. For a small network, full mesh iBGP offer better latency.

Confederation reduce cpu utilization due to internal route churn, but can increase cpu utilization due to external route churn (in some cases).

Route Reflector only taxed route reflectors, not the clients. IMO, Route Reflector have the worst latency.

iBGP does not advertise 3rd party routes to other iBGP peers. iBGP peer will not advertise routes learned by one iBGP peer to another iBGP peer. This is because iBGP has no loop prevention, so this solves it.

iBGP full mesh have a scalability constraint. In a small network, an iBGP full mesh of up to 10 routers is okay; with 30 routers, it is stretched; with 100 routers, it is taxed.

Confederation and Route Reflector are use to address iBGP full mesh constraint. In a large network, these two techniques are combined to provide a highly scalable network.

Peter Paluch Sat, 11/21/2009 - 10:16


Personally, I believe that the route reflector can be more conservative on CPU resources overall, as the number of BGP adjacencies with route reflectors is the minimum possible. The main difference is, however, in the way these two approaches tackle the problem of simplifying the full mesh of BGP neighbors, and the resulting features you are given as a consequence.

With confederations, you split your AS into sub-ASes. BGP speakers inside a sub-AS have still to be fully meshed (or use an internal route reflector). With confederations, you are given a crude form of traffic engineering within your own AS, as you can determine the path between internal sub-ASes using ordinary BGP attributes, just like you can do it between normal ASes.

The route reflector relaxes the requirement on disseminating information between iBGP peers. However, in order to prevent routing loops, each route reflector adds two new BGP attributes to each reflected prefix (the ORIGINATOR_ID and CLUSTER_LIST). With route reflectors, the logical topology between BGP speakers in an AS reduces itself to hub and spoke (it may get more complicated, though, if redundant route reflectors are used).

The confederations and route reflectors can be combined together. However, according to what I have heard, the confederations have not been very popular. I am sure other friends here can share their own experiences.

Best regards,



This Discussion