Jon:

Exactly.

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

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

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

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

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

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

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

Jonny poo? Where are you?

Victor,

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

Reza

lol..youre right, Reza...