bgp ibgp routing

Unanswered Question
Nov 21st, 2008

Not sure if this can be done. I can't seem to get it work.

router a

router bgp 10

neighbor switch a

switch a

router bgp 10

redistribute connected

neighbor router a

neighbor switch b

switch b

router bgp 10

redistribute connected

neighbor switch a

neighbor router b

router b

router bgp 10

neighbor switch b

router a can see the routes redistribute connected from switch a but not the bgp routes learned from switch b even though they are in switch a's routing table.

Same is true for router b, it sees the routes redistributed from switch b but not the routes switch b learned from switch a. I tried using network statements and I can't get either switch a or b to foreward the routes. Do I have to bite the bullet and fully mesh this thing....thx

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
ullasupendran Fri, 11/21/2008 - 12:00

Hi hanson

try the following

switch a

router bgp 10

neighbor router a route-reflector-client

neighbor switch b route-reflector-client

switch b

router bgp 10

neighbor switch a route-reflector-client

neighbor router b route-reflector-client

It should work

Ullas

marikakis Fri, 11/21/2008 - 12:50

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.

Giuseppe Larosa Sat, 11/22/2008 - 07:01

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

marikakis Sat, 11/22/2008 - 10:11

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.

marikakis Sat, 11/22/2008 - 12:34

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

Giuseppe Larosa Sat, 11/22/2008 - 13:07

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

whanson Thu, 11/27/2008 - 07:59

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.

marikakis Thu, 11/27/2008 - 12:03

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.

deshpande-s Sat, 11/29/2008 - 09:11

In short, you have to create full mesh ibgp neighbourship between all routers because BGP rule says that one ibgp neighbour can not foward routes to another ibgp neighbour, reason is that Local AS number is not included in the internal ibgp routes then we have to configure the RR to solve the prolem

Actions

This Discussion