Couple Questions Regarding Non-Directly-Connected iBGP peering

[Dean Romanelli]

Hi All,

I have a couple of questions regarding BGP peering non-directly-connected routers.  I’ve drawn up and attached a small lab to help me convey the questions:

In the drawing, I have iBGP sessions on AS 1 between R1, R2, R3 & R4.  Assume it is partial mesh at the moment (I know we have to fix that).  

R6 in AS 2 is eBGP peered to R1 in AS 1.  R6 is advertising the 151.216.0.0/16 subnet to R1 in AS 1.

When R3 receives this route, it does not pass it to R4 because of the rule stating that iBGP routers will not forward routes learned via iBGP to another iBGP peer. 

Therefore, R4 doesn’t know how to reach 151.216.0.0/24. I want to fix this by peering R4 to R2, which is where my questions begin:

1. I know the preferred method of non-directly-connected peering is loopback-to-loopback, but if I wanted to use the IP Addresses on the physical ports on R4 & R2 instead (10.10.10.1 & 20.20.20.1), could I do that successfully?
2. If so, I have read that when peering non-directly-connected BGP neighbors, you need to first confirm connectivity exists between the near-end and far-end, which is usually done via static routes.  However, since R3 knows about the 20.20.20.0 & 10.10.10.0 networks via directly-connected, & there are BGP sessions on all the routers on the path, wouldn’t that negate the need for further routing configs in addition to the BGP sessions?
3. Inversely, if I decided to perform the peering from loopback-to-loopback as per the recommendation, then I think I WOULD need static routes, since R3 doesn’t already know about R2 & R4’s loopback networks and if injected into BGP,  R3 wouldn’t be able to forward that info to R2/R4 since it came from an iBGP neighbor already, correct?

Or am I off base and will need the static routes regardless if I use physical interface IP addresses or loopback addresses to peer?

Lastly, I know a better solution is to run RR’s or Confeds, but for the sake of the concept, assume those aren’t options for me if you would.

Thanks Guys!

[Richard Burts · Accepted solution]

1) While there are frequently reasons why we suggest peering loopback to loopback there is not any reason why it would not work using physical interfaces. So if you want to use physical interfaces as peering addresses I do not see a reason why it would not work.

2) You do need to have IP connectivity between the peering addresses. I see your point that R3 knows both subnets as directly connected. But does R4 have a route to the interface address of R2?

3) If you decide to peer using loopback interfaces then the routers need to know how to reach each others loopback interface. Static routes is one way to achieve this and an Interior routing protocol (such as OSPF, EIGRP, or RIP) could also provide this.

HTH

Rick

[Dean Romanelli]

Hi Rick,

Thanks for responding.

As for your follow up question under question 2:

My original train of thought is that R4 being directly peered to R3, R3 being directly peered to R2, and all 3 routers belonging to BGP AS 1, there would be connectivity from R4's physical address to R2's physical address. But now that I'm thinking about it, I guess R4 wouldn't have a route to R2 since R3 can't forward BGP updates sourced from R4 to R2 & vice-versa due to the iBGP rule right?

Now if I were to implement Route-Reflectors or Confederations though, I wouldn't need to configure additional static routes or use an IGP to make this topology work as desired right?

[Richard Burts]

Perhaps it will help to think about how a BGP peer relationship gets established. R4 wants to peer with R2. So R4 needs to send a TCP syn to R2 to begin the BGP negotiation. How will R4 know how to reach the address of R2? There needs to be some kind of entry in the routing table of R4 that has the address of R2? And similarly there needs to be some routing table entry at R2 for the address of R4 to be able to respond to the TCP syn. These have to be in place before the BGP session can start. There are several ways that routing table entry can be created - static routes and an Interior routng protocol are the most common ways to do it.

I do not see how Route Reflectors or Confederations would help with this. The fundamental issue is still how will R4 and R2 find the routes for each others address? I do not see that Route Reflectors or Confederations will provide the necessary route table entries.

HTH

Rick

[Dean Romanelli]

Gotcha, I see what you're saying.

I think the problem is I am looking at BGP too much like a layer 3 routing protocol, like the IGP's, and not a layer 4 protocol.  I think what I need to do is remember that "in order for BGP to function, layers 1-3 need to be in tact first." 

Followup question on that:  If I chose to provide the layer 3 connectivity for this topology via an IGP like EIGRP for example, is there any reason I would need to redistribute that into BGP?  There shouldn't be unless I want EIGRP to know about exterior routes or the existence of the iBGP session right?

[Richard Burts]

Understanding how the routing protocols work can get a bit complex. One thing that helps me is to remember that the IGPs (OSPF, EIGRP, RIP) have mechanisms that automatically discover neighbors, and that their neighbors are always on the conected subnet. BGP is different about this. There is not an automatic neighbor (peer) discovery so we need to configure the peer relationship. And most importantly BGP is different where peers (neighbors) can be in a different subnet. So it becomes important for BGP to have a route to a peer's address. We do not need to think about that for EIGRP, or for OSPF, or for RIP. But we do for BGP.

If you run an IGP such as EIGRP there is no need to redistribute that into BGP unless there are routes learned by EIGRP that you would want BGP to advertise.

HTH

Rick

[Dean Romanelli]

That's a great way to remember it, I copied that and put it in my notebook.

So, this may be a silly question, but if connectivity already needs to be in place at layer 3 via static routing or an IGP to use BGP, what is the purpose of using BGP in addition to the IGP, other than the ability of taking advantage of the reliability and tools TCP offers? 

[Richard Burts]

It is certainly not a silly question. I think it is a quite significant question and I hope that I can supply an answer that does it justice.

The purpose of using BGP is that it was designed to accomplish some things that are quite different from our IGPs. Probably first and foremost BGP was designed to scale to very large sizes (think of the size of the Internet routing table and how difficult it would be to advertise that with OSPF or with EIGRP). Also BGP was designed to make routing choices that reflect policy. If you think about it all of our IGPs are making their routing choices based on comparison of the links over which traffic will be forwarded (which has the highest bandwidth, or which has the lowest delay, or which has the fewest hops). BGP does not consider those factors at all as it makes its routing choices.

If you think about it we call BGP an Exterior routing protocol and the others are Interior routing protocols because they have different objectives and use different techniques to implement their routing choices. I am sure that other members of the forum may add some additional considerations about why we use BGP but I hope that my suggestions will start an interesting discussion.

HTH

Rick

[Dean Romanelli]

I'm with ya, makes sense.  Thanks Rick.

I too will be checking in over the weekend hopefully to see what other info is provided as well.  Also, your 2nd paragraph had me thinking; how about in the case of internal BGP (iBGP) as opposed to just running a local IGP alone?  I guess the main reason would still be for greater policy control even within a local AS that doesn't do any inter-AS peering?

[cadet alain]

Hi,

if you didn't use iBGP then you would have to redistribute BGP prefixes into your IGP and that wouldn't scale well at all if you had thousands of BGP prefixes.

Regards

Alain

[Jon Marshall]

Dean

When R3 receives this route, it does not pass it to R4 because of the rule stating that iBGP routers will not forward routes learned via iBGP to another iBGP peer. 

Just to clarify R3 should not receive the route because of the rule you state above. R2 is running IBGP with R1 so when it receives that route it has received it from an IBGP peer. Yes R1 is running EBGP with R6 but it is still an IBGP peer with R2.

So it is both R3 and R4 that should not receive the route.

Jon

[Dean Romanelli]

Hi Alain,

Thanks for replying. That definitely makes sense.

Hi Jon,

You're right.  I just noticed I had R1 in there after reading your comment. I meant to draw it up without that 3rd router on the bottom segment.  But yeah, I'm with ya, the way it is drawn you are right.