Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Blue

BGP Sanity Check

R3 has an eBGP peering with R1 and R2.

R3 has next-hop-self under those peerings.

What for? Doesnt makse sense, right? The only time you would use that is when a prefix is learned through eBGP and is going to advertise it to an iBGP neighbos.

Just doing a sanity check...

Anyone?

14 REPLIES
Hall of Fame Super Blue

Re: BGP Sanity Check

Victor

Correct, next-hop-self is used when an EBGP router is advertising routes to an IBGP peer ie.

R1 <- IBGP -> R2 <- EBGP R3


without next-hop-self R2 advertises routes to R1 that it has received from R3 with the next-hop set to R3 which R1 may or may not know how to get to. With next-hop-self on R2 then routes received from R3 advertised to R1 have the next-hop of R2.

Jon

Blue

Re: BGP Sanity Check

Jon:

Exactly.

Hall of Fame Super Blue

Re: BGP Sanity Check

Victor

Sorry, i thought you were asking what was the use of next-hop-self with an IBGP peering, totally my fault should have read your post more carefully.

You are right in that by far the most common use of next-hop-self is with IGBP peerings but it can also be used with EBGP peerings under specific circumstances. See this doc for more details -

EBGP next-hop-self uses

Jon

Blue

Re: BGP Sanity Check

No apologies necessary.

The document reminded me of this situation -- I had forgotten about this scenario

Anyway, so to summarize -- and make sense out of it by "saying" it out loud -- the next hop self command is used if an eBGP neighbor receives a route and must advertise it through iBGP and the eBGP neighbors are NOT on the same broadcast segment as the iBGP neighbors. This was the scenario you described and the one I was thinking of when I ran my sanity check. In this scenario, in which the eBGP speaker is receiving a route, the next hop self command would not be needed if the eBGP neighbors were sitting on the same logical broadcast segment. In other words, you only need the command if the eBGP neighbors are not on the same logical broadcast segment.

This, however, isnt true in the opposite direction, so to speak. By opposite, I mean the scenario in which an iBGP speaker originates a route, advertises it through iBGP to a router that will then advertise it through eBGP to a 3rd router. Whether the eBGP neighbors are on the same segment or not, in this scenario, the next hop self command is never needed on a broadcast segment. The reason is that a prefix advertisement originated by a router and advertised through iBGP will then be advertised through eBGP to the 3rd router -- moreover, the second router (the one running i and eBGP) will advertise itself as the next hop in non multiaccess segments, or the iBGP neighbor as the next hop in a multiaccess segment -- but either way, the e neighor (the third router) is fine and will know how to reach the prefix.

Sheeeew...

that sort of hurt my brain...lol

[EDIT] So, really, the only time that BGP's behavior on a multiaccess segment necessitates the use of the next hop self command for an eBGP peer is when the multiaccess segment is NBMA -- non-broadcast. [EDIT]

Victor

Hall of Fame Super Blue

Re: BGP Sanity Check

Victor

In this scenario, in which the eBGP speaker is receiving a route, the next hop self command would not be needed if the eBGP neighbors were sitting on the same logical broadcast segment. In other words, you only need the command if the eBGP neighbors are not on the same logical broadcast segment.

Okay, this may be the way you have written it but this was not the scenario i was describing. I was talking specfically about EBGP -> IBGP which has nothing to do with whether the EBGP neighbors are on the same logical broadcast subnet or not. Where it does matter is in the 2 examples in the doc where you have 2 very specific examples -

1) a NBMA network

2) a shared broadcast segement between EBGP AND IBGP peers which lets be honest is not a very common scenario.

As i say, i may be misunderstand what you are getting at and it may be your use of EBGP peers when you meant EBGP/IBGP but then again you may not have meant that - you see my brain hurts now as well

Jon

Blue

Re: BGP Sanity Check

Jon, I think were saying the same thing but differently...discussions liek this are best had in person on a whiteboard....

I was just thinking out loud, basically...

Thanks

Hall of Fame Super Silver

Re: BGP Sanity Check

Hello Victor,

going back to your initial post, what is the network scenario where you have seen next-hop-self applied?

It was a form of ATM or FR NBMA between eBGP peers?

this is just to complete this story

Hope to help

Giuseppe

Blue

Re: BGP Sanity Check

Giuseppe:

No NBMA, which is the only case in which you really need to use the next hop self command for eBGP neighbors....

These are just data center routers -- and for some reason, they like using /29s to peer...have no idea why

VIP Super Bronze

Re: BGP Sanity Check

In addition to Jon's comments, although it is very common to deploy next-hop self but if you do not desire to do so, you can also run passive interface under your IGP, ie OSPF, ISIS, etc,

r1----IBGP----r2----EBGP----r3

Just another way of doing the same thing.

HTH

Reza

Blue

Re: BGP Sanity Check

Reza, I dont like that solution. Its clumsy, but yes, youre right, I know it can be done....

Blue

Re: BGP Sanity Check

Jon, I updated my answer to you a few times, so please read it now if you have already read it...

Blue

Re: BGP Sanity Check

Jonny poo? Where are you?

VIP Super Bronze

Re: BGP Sanity Check

Victor,

He is probably sleep now.  It is almost midnight there.

Reza

Blue

Re: BGP Sanity Check

lol..youre right, Reza...

1111
Views
10
Helpful
14
Replies
CreatePlease login to create content