additional iBGP session between two route-reflectors client?

[Konstantin Dunaev]

Hi,

is there any problems if one set an additional iBGP session between route-reflector clients? 

[Marwan ALshawi]

No it is ok

But this will eliminate the benefit of RR

Also be careful that the clients won't prefer the direct peering session if you want to keep the RR as the primary path

Sent from Cisco Technical Support iPhone App

[Konstantin Dunaev]

Hi,

thank you for replay!

Actually, I'd like to set the BGP session with another RR-client more preferable as to RR router and to route the traffic accordingly.

the problem is that those two RR-cleints are pysicaly connected and  only one RR-Cleint has physical path to RR-routers, so traffic  to RR-routers goes anyway via one of the RR-client.

[Mahesh Gohil]

Hi,

BGP has one great rule (it is in your interest you follow that rule or not) and that is: with introduction of RR a BGP peer should have as many session for EBGP but should have only one (can be two also in case of two RR in network) and that is with RR only to avoid any looping.

I assume you have below kind of network

RR

|

|

Client-1-----------Client-2

above are physical link, so even if you configure IBGP session between two clients: routes learned by client-2 from RR will not be propogated to client-1 and same is the case for Client-1 also...so in my viw no harm at all.

considering above points it is very much necessary to know what you want to achieve with this IBGP session between clients

regards # Mahesh

[rais]

RR-client with direct link to RRs can itself become RR for the RR-client with no direct access to existing RR.

Thanks.

[Konstantin Dunaev]

Hi Mahesh,

the topology looks like

the problem is the RC-E001 sees both RC-RR1 and RC-RR2 (route-reflectors) as  next-hops for the external prefixes, but I'd like that traffic goes out directly via RC-E002  and doesn't travers the whole backbone.

If I set a iBGP session between RC-E001 and RC-E002 I could configure the weidth/localpreference and so on to prefer the path via RC-E002

update! on the picture: the iBGP session between RC-E001 and RC-E002 doesn't exist yet, I've created this topology in order to play with different posiibilities, one of them was set another level of RR's but I'm not sure it's a good idea. I think a simple iBGP session between RC-E001 RC-E002 should really solve my problem.

[rais]

RRs would always prefer eBGP learned routes over iBGP learned from E002 and hence reflect their best route. New iBGP session between E00[1-2] routers should send E001's Internet bound traffic out E002.

Thanks.

[Mahesh Gohil]

Hi Konstantin Dunaev,

Let me ask some more questions to understand it better.

I didn't understand why the next-hop for these external prefix is RR1 or RR2. There are two possibility

1/ Either those prefixes are learned by external session configured at RR1 or RR2

2/ You have manually configured next-hop self at RR while IBGP session with RC-001.

if it is first case: No need of IBGP session between clients but you can increase LP of routes learned at RC-002

if it is second case: Just remove next-hop self and let it be the next-hop as that of RC-002.

In both solution you need not to configure any additional IBGP session because if next-hop for these prefixes is RC-002 then traffic will move via. direct link between RC-001<>RC-002 irrespective of from which RR's the prefixes are learned.

Let me know if I have misunderstood at some point.

Hope this helps

Regards # Mahesh

[Konstantin Dunaev]

Hi Mahesh,

The RR's have an external BGP session and (of course) use next-hop-self on all iBGP sessions.

RC-E001 has only 2 BGP sessions with both RR's and that is why all external prefixes has RR's as next-hop.

Without additional BGP session with RC-E002 there is no chanse for RC-E001 to know that RC-E002 have a way outside as well - the RC-E001 simply dosn't know about existing of RC-E002, from BGP point of view.

[Mahesh Gohil]

Hi,

If I am not wrong next-hop-self is per neighbor command so even if you have configured peer-group and defined next-hop-self for that peer group, you can create one more peer group for RC-001 and do not configure next-hop-self for this group. I think this is better option than to configure IBGP between two clients (why to add complexity)..Finally it is upto you to decide which better suit to your need

Regards

Mahesh

[Konstantin Dunaev]

let say it so, according the cisco'S best practice the edge router should use next-hop-self for their iBGP sessions, in this case the internal IGP doesn't need to know about externla link-net which uses to connect to ISP router.

And from other side, "next-hop-self " doesn't really make difference, it's no difference for RC-E001 if it sees RR self as next hop or RR's link-net to ISP router, traffic goes still to one of RR's.

   Or am I wrong?

[Mahesh Gohil]

RR is just advertising prefixes and not attracting traffic towards him. You purposefully set RR to attract traffic which is not needed.

The ideal design is not using RR as a IGP next-hop unless it is needed (mostly for financial reason). You have chance here to improve your design just by configuring one more peer-group.

Cisoc best practice is best if it is meeting your requirement and believe me you will still follow best practice, by configuring IBGP between clients you are adding complexity.

But as I said it is upto you to decide which is better one for you.

Regards # Mahesh

[Konstantin Dunaev]

mahesh Gohil wrote:
 RR is just advertising prefixes and not attracting traffic towards him. You purposefully set RR to attract traffic which is not needed. 

could you explain it a little more? For the internal prefixes it's correct - iBGP sessions doesn't  change the next-hop and it doesn't metter how the RR-cleints gets the BGP information, but for the external prefixes it's not a case, if RR's have external BGP sessions then they will announce thier own IP as next-hop (or ISP provider if no next-hop-self is used) and then all RR-cleints use RR's as next-hop for the externla communications.

you're right, the best topology is just a full-mesh BGP, but with 30 routers it is not any more the best topology

The question was - how the additional iBGP session between RR-cleints will influence the BGP routing. I've tested it on my  test-lab and haven't seen any problems, but not really 100% convince because I could test only a part of configuration.

[Mahesh Gohil]

Agree with your first statement. I mean to say for IBGP only and not for external prefix.

But i did not recommended for full-mesh. However coming back to original question of how IBGP between clients affects routing: No it won't affect anymore as far as I thnik basen on the topology shown by you.

I have tried to suggest for workaround in all my above posts.

Regards # Mahesh

[Konstantin Dunaev]

Thank you, Mahesh, for your comments!

It's always useful to get a second opinion to a problem.