cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9940
Views
15
Helpful
9
Replies

when should i use BGP confederation or Reflectors?

hanyawad
Level 1
Level 1

Hi,

the main purpose of BGP confederation and Route Reflecor is to prevent loops, but when i design my BGP network in which situation i should use 

BGP confederation or Route Reflector design.

thanks,

Makar

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

Hi Makar,

The main purpose of route reflectors and confederations is not to prevent loops but to avoid the need to have all iBGP routers fully meshed (fully peered in BGP).

The route reflector design is usually preferred to confederations. It is a relatively lightweight solution that scales nicely. Confederations are usable only for huge autonomous systems where you can afford to split them into several sub-ASes. Note that each sub-AS in a confederation needs to have its internal iBGP peers either fully meshed, or use route reflection internally, returning back to the route reflector concept. As you can see, the confederations are not much of an advantage for small ASes having a few BGP routers.

Feel welcome to ask further.

Best regards,

Peter

View solution in original post

9 Replies 9

Peter Paluch
Cisco Employee
Cisco Employee

Hi Makar,

The main purpose of route reflectors and confederations is not to prevent loops but to avoid the need to have all iBGP routers fully meshed (fully peered in BGP).

The route reflector design is usually preferred to confederations. It is a relatively lightweight solution that scales nicely. Confederations are usable only for huge autonomous systems where you can afford to split them into several sub-ASes. Note that each sub-AS in a confederation needs to have its internal iBGP peers either fully meshed, or use route reflection internally, returning back to the route reflector concept. As you can see, the confederations are not much of an advantage for small ASes having a few BGP routers.

Feel welcome to ask further.

Best regards,

Peter

turbo_engine26
Level 4
Level 4

As Peter perfectly explained it very well, please allow me to add couple of small points regarding why RR is also preferred over Confederation.

Advantage of RR:

RR is supported only on a router acting as RR server and doesn't need to be supported on both the server and the client. From the client's perspective, RR server is a normal BGP neighbor with no further configuration.

Disadvantage of Confederation:

All routers in the Confederation AS must support the Confederation functionality to work.

HTH

AM

Hello,

Good points - thank you! It is noteworthy to say that it is recommended that even with route reflectors, the clients should be aware of this addition to BGP (in order to recognize the ORIGINATOR_ID attribute), but even if they do not support it, route reflectors will work fine.

For conferedations, there are specific extensions to be supported in the AS_PATH attribute and rules to interact with outside world within and without the confederation, and truly - each confederation member must support the confederation functionality.

Most BGP implementations, however, support both route reflection and confederations.

Best regards,

Peter

Correct me if I am wrong..the iBGP full mesh requirement stems from maintaining a loop free topology? I agree with previous poster in that the intent of RR and confederations was not to prevent loops but rather address scalability issues with iBGP full mesh while maintaining a loop free topology.

Regards,

Ryan

Hello Ryan,

Correct me if I am wrong..the iBGP full mesh requirement stems from maintaining a loop free topology?

Not directly. As you know, there is a rule in iBGP that says that "a route learned via iBGP will not be advertised via iBGP". Some people like to call it the "iBGP split horizon rule" although I personally dislike this name. This rule was created to prevent routing loops, because within iBGP, no special attribute is added to a prefix to identify the sequence of iBGP routers the prefix went through - as opposed to eBGP where the ASN is prepended to the AS_PATH list. An iBGP speaker has therefore no clue whether the prefix it is receiving is a prefix it originally advertised itself, or if it is an alternate path to the same destination. Hence, the easiest way to prevent routing loops in iBGP is simply - to keep an iBGP-learned route just to yourself and to not advertise it to any other iBGP peer.

Surely, however, any iBGP speaker may learn about a prefix that needs to be known by all other iBGP speakers. However, with this iBGP rule in place - and with no additional mechanisms such as RRs or confederations - the only way to have all other iBGP speakers know it is to tell them directly. And because any iBGP speaker can at any time learn about a topology change and tell about to all other iBGP peers, we need the iBGP full mesh. Hence the full mesh requirement.

So the sequence of consequences is: we want loop-free routing -> iBGP has no attribute to prevent routing loops -> iBGP will not further advertise iBGP-learned routes -> we need iBGP full mesh

I am not sure if I answered your question so please feel welcome to continue the discussion.

Best regards,

Peter

Thank you for your post Peter. In my attempt to be brief I didn't include the level of detail you did. The point I trying to make was the iBGP full mesh blossomed from the desire to have a loop-free routing topology. I think your sequence of consequences proves that. The statement was made that RR and confederations were not developed to prevent loops. I agree and was making the additional point to the original poster that RR and confeds were not birthed to prevent loops but rather address scalability while maintaining a loop free topology.

Regards,

Ryan

Hello Ryan,

Oh, I see now. Thank you. Sorry for lecturing you... I didn't mean it.

Best regards,

Peter

Please do not apologize. I did not take it that way at all!! I always appreciate your comments. And it served to confirm what I was thinking. Please continue to post as you see fit, I'm sure I speak for everyone when I say your feedback is always helpful! : )

Regards,
Ryan

hanyawad
Level 1
Level 1

thanks so much guys for your significant and perfect explanation

Best Regards,

Makar

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: