Also make sure that synchronisation is disabled in all routers :-)

Hello,

I do not disagree with the solution from Ullas. Your setup can also work by entering just 2 neighbor commands:

1) on switch a, in session with router a, specify router a as a route-reflector-client.

2) on switch b, in session with router b, specify router b as a route-reflector-client.

This means that you have 2 RRs (switch a and switch b). The iBGP full-mesh requirement is now relaxed to the requirement of full-mesh only between RRs. The existing normal iBGP session between switch a and switch b is sufficient to serve this purpose.

Kind Regards,

M.

Hello Maria,

I don't like Ullas's proposed solution switch A and switchB should be a normal iBGP session: two routers cannot be route-reflector-client of each other this shouldn't lead to a working configuration.

It is allowed to build multi-level reflection servers where the second level RRS have as clients the RRS at first level but on an single iBGP session only one side can be treated as route-reflector-client.

At least it isn't correct in theory.

Hope to help

Giuseppe

Hello Guiseppe,

I did not think through Ullas's proposed solution enough. You are right. Thank you for pointing that out. So, I guess the solution I proposed turns out better :-)

Kind Regards,

Maria

p.s. The rating of your useful posts is implied. I won't be saying that every time I do it.

Hello Giuseppe,

I am still thinking of this point that you mentioned (yes, I get obsessed from time to time with certain issues). The link that Edison posted earlier says for example "Each route reflector would be configured with other route reflectors as nonclient peers (thus, all the route reflectors will be fully meshed).", which supports your argument. It seems straightforward at a first glance. However, when I think about it more, I fail to see the reason behind this suggestion.

I mean, an RR client is not aware that it is a client of the RR, right? An RR client will not receive less updates from an RR than a non-client does (if I recall correctly, the only case an RR will not pass updates is this: from a non-client iBGP peer to a non-client iBGP peer, following normal iBGP rules). If for some reason more updates are passed between the 2 RRs than they would with plain iBGP session, I suppose a routing information loop can be detected via the ORIGINATOR_ID of the first RR. What do you think?

Have you ever tried such a setup or are you aware of a particular theoretical reason that prohibits this setup from working? Sure this setup looks like looking for trouble (and I normally avoid things when in doubt), but I would still like to know a particular scenario that could break if this setup is followed.

Kind Regards,

Maria

Hello Maria,

on a lab setup with 4 routers probably it can work but in real world some serious issues could arise.

It is true that the client side is not configured to be a client explicitly and it is even unaware to be.

What changes is the behaviour of the RRS side when it has to decide if a received advertisement has to be sent to a specific neighbor or not:

in this case to a normal iBGP session peer the RRS will propagate a BGP advertisement if:

comes from a client

or if comes from a direct eBGP peer

if the neighobor is a route-reflector-client

first of all client to client reflection can be disabled with a specific command.

Probably the RRS will examine the BGP attributes Originator-ID (BGP router-id of the advertisement originator ) and the Cluster-List attribute that is the history of reflection(s) of the advertisement:

if there is a consistency check, if inside the cluster-list on a received route the router finds the BGP router-id of a device that it considers one of its clients probably it can decide to discard it or even to tear down the BGP session.

I would expect something like this.

In my working experience I have seen some service providers networks and the domain is divided into clusters where there is a group of routers served by a pair of RRS that share a cluster-id parameter so that they can realize they are serving the same set of routers.

Then the RRS are in full mesh between each other with standard iBGP sessions.

This is the idea to reduce the total number of BGP sessions in the routing domain.

For some time they had a two level RRS infrastructure that was then changed in per-address family RRS (one group of RRS for MPLS VPN vpnv4 another one for GRT customer routes)

What is very nice about RRS is that they don't need to route the traffic of the BGP prefixes they reflect: BGP next hop is kept unchanged.

So they usually are C7206VXR with NPEG1 or NPE-G2 and 1 to 2 GB of RAM.

Hope to help

Giuseppe

Thanks Giuseppe, I am glad I asked! :-)

I want to thank everyone who responded. Apparently, I opened quite a lively discussion on this. I have decided though to take the safe route and mesh the customers bgp environment. However, I did learn quite a bit from the ensuing discussion. thanks again.

Hello,

Nice to hear you liked the discussion (at some point I felt guilty for almost hijacking your thread).

I have only one last comment. You are probably right to choose the full iBGP mesh option in a simple network like the one you described. The only problem with this choice is accomodating future growth (it won't scale), but that's up to you to judge and it's still good at any case to choose the option you feel most comfortable with.

Sometimes we read about features and we can't know for sure how realistic they are until we see them in live networks. Route reflectors are not like redistribute-from-RIP-to-EIGRP-and-then-to-BGP-and-back-into-RIP or exotic feature 666-the-number-of-the-beast kind of stuff. Route reflectors are pretty decent solution used in ISP networks (ISP cores follow conservative policies, I used to work in an ISP x years ago) and I have seen it work decently in many networks.

I felt like adding those comments because at some point I might have implied (against my will) that the route reflector solution is like looking for trouble. I only meant that it might be if commonly available design guidelines are not followed.

Kind Regards,

M.