cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

5968
Views
0
Helpful
6
Replies
Highlighted

Route Reflector BGP

I am going to design a  two level Route Reflector architecture in order to get scaling and flexibility for the BGP updates coming for a large number of clients. I am not sure of the basic configuration iBGP and iBGP-RR necessarily for create the core of route reflector in the network.

My aim is to design the first hierarchy made by two routers RR1 and RR2 (I tier) nad the second hierarchy composed by two couple of Route Reflector (RR3&RR4 and RR5&RR6). Route reflectors belonging to the second hierarchy must be client of route reflectors belonging to the first hierarchy. Each RR's pair (like RR1&RR2 or RR5&RR6) is supposed to accomplish redundancy for clients, so that RR1 is redundant with RR2, RR3 is redundant with RR4 and RR5 is redundant with RR6. A big number of client routers will be connected through two BGP sessions to the closest RR pair belonging to the second hierarchy (look at the picture below).

Screen shot 2011-01-02 at 10.59.57 PM.png

                                                       PICTURE 1

My question is: have I to configure the iBGP session between each pair of RR (red arrows in the picture below)? My guesstimate is that i am allowed to not configuring the iBGP session between the RR's pairs because that doesn't make big difference:

For example: would the route coming from RY propagates across the net if i had a eBGP session between an external router RY and R3? I guess the routes coming from RY would be definitely propagate to any router in the internal network even though the iBGP between RR's pairs has not be configured (Note that in the picture below i have cancelled the red arrows):

Screen shot 2011-01-02 at 11.00.12 PM.png

                                                       PICTURE 2

The same happend in my opinion for a route coming from a Client: teh route advertised by ClientrA will reach Clielt B with redundant paths:

Screen shot 2011-01-02 at 11.00.21 PM.png

                                                       PICTURE 3

Does anybody have designed multi tiers of Route reflector hierarchy for giving to my any tip? The model i have thought looks like CORE DISTRIBUTION of RR, does it make sense for scaling?

Thanks

M

6 REPLIES 6
Highlighted
Rising star

Re: Route Reflector BGP

Hello M,

Looking at example you shared it is ok not to have full-mesh between RR's if you have configured

as Clients of each other.

Even rfc 4456 is also supporting with below statement

Each RR would be configured with other RRs as Non-Client
   peers (thus all the RRs will be fully meshed).

But as per few cisco press bgp books it is recommended to have full-mesh ibgp between Tier-1 RR's in hirerchical route reflector design

section.

Well the end role is to have route reflection of prefix to all parts of network with minimum no. of ibgp sessions and if you can

achieve this without full-mesh then i don't think you need that

Hope this helps

regards

mahesh

Highlighted
Beginner

Agreed with the full-mesh of

Agreed with the full-mesh of top-tier RR's -

However, one thing from Halabi (http://www.ciscopress.com/store/internet-routing-architectures-9781578702336), logical should always follow the physical. 

the connection between RR1 and RR2 should involve physical links (802.1ad perhaps) to prevent AS segmentation.

-Dan

Highlighted
Hall of Fame Mentor

Re: Route Reflector BGP

I agree with Mahesh. A Full Mesh provides a more sound design than using RR for the number of routers at hand.

Highlighted
Beginner

Re: Route Reflector BGP

hi Maurizio,

It depends on lot of more factors before you decide on your bgp topology design:

  • how many ibgp speakers

  • what kind of hardware, cpu, memories available
  • how many routes , full routes on all speakers
  • what is th underlying physical topology
  • how traffic is forwarded, plain ip or mpls
  • if plain ip, the RRs are on the forwarding path?
  • loopback based peering only?

if you have these metrics then you can decide on more reasonable design


specific to your question 1, you dont need ibgp session between rr3 and rr4, or top level RRs for to distribute RY routes to all routers in your bgp domain, however, if you need to originate route from RR it's self, there will be a problem, because there is no ibgp sessions between each RR pair.

HTH

Guan

Highlighted

Re: Route Reflector BGP

Hey thanks everybody for suggestions.

@Guan: though I do not agree with you as I think if a RR generate a route of it's own the route will be propagated to all the RR and Clients in the net (this is because every RR3,RR4,RR5,RR6 is also a Client in it's turn and it will advertise to the its upper RR1 and RR2 the route andn these in turn will advertise to all its clients). However you are right that this doesn't happend when we consider RR1 and RR2: in fact the RR1 and RR2 are the only RR in teh net which are not Client in turn. That's mean that if RR1 announces a route (or if RR1 receives the route by eBGP as well) it will propagate every router in the net but RR2!! So RR2 are supposed not to know the route!! That's woudl eb a mistake! Following this idea I suggest the suitable design to get The FULL-MESH BGP with minimum no. of ibgp sessions as Mahesh has sugegsted,  is depicted in the following picture:

In this case the iBGP session between RR1 and RR2 allows RR2 to receive the routes from RR1 and viceversa.

All the other route propagation is guaranteed each RR belonging to the II Tier being in turn Clients of RR of the I tier.

Does this make sense?

The factors you have listed are very important in chosing the Design of course and I have taken them intoconsideration at choosing teh TWO TIER MODEL RR. My questions aimed just to understand how many BGP connections I have to configure to get the full mesh with redundancy.

Thank you very much indeed guys

Maurizio

Highlighted
Beginner

Re: Route Reflector BGP

You right Maurizio,what i meant was the top level RRs.

Be aware the very much centralized RR has it's drawbacks such that some path may became unavailable depending where your ebgp peers are connected.