[j-nsp] Route Reflecting & Next-Hop Self

[Dan Armstrong]

A hotly debated topic among BGP nerds....     I honestly don't know how 
I feel about it either way.


Many people think that because the IPs that you often use between 
yourself and a transit provider belong to your transit provider, they 
have no business being in your IGP.... "My IGP is for MY address 
space".    At the end of the day I don't think it really matters, but 
you know how passionate some people can be. 





Amos Rosenboim wrote:
> Hello Dan,
>
> You can also work around all of this by simply adding the inter-AS 
> prefix into your IGP by adding this interface as a passive interface 
> for the IGP.
> This will eliminate the need for next hop self in the first place.
> This seems simpler to me, am I missing any reason not to use this?
>
> Regards
>
> Amos Rosenboim
> amos at oasis-tech.net <mailto:amos at oasis-tech.net>
>
>
>
> On Sep 6, 2008, at 12:46 AM, Dan Armstrong wrote:
>
>> EUREKA you're a genius!
>>
>> Thanks...  That works perfectly.
>>
>> And thanks to all who replied!
>>
>>
>>
>>
>>
>> Kevin Hodle wrote:
>>> Hi Dan,
>>>
>>> Instead of 'from external' you need 'from route-type external', like so:
>>>
>>> term external-nexthopself {
>>>     from {
>>>         protocol bgp;
>>>         route-type external;
>>>     }
>>>     then {
>>>         next-hop self;
>>>         accept;
>>>     }
>>> }
>>>
>>> HTH,
>>> Kevin
>>>
>>> On Fri, Sep 5, 2008 at 9:26 AM, Dan Armstrong <dan at beanfield.com 
>>> <mailto:dan at beanfield.com>> wrote:
>>>
>>>   
>>>
>>>> I was trying to make a generic policy statement that I could deploy 
>>>> across all our boxes... this is not possible if we name ebgp peers 
>>>> specifically, and if we change transit providers - we have to keep 
>>>> track of changing policy statements as well... kind of messy.
>>>>
>>>>
>>>>
>>>> Chuck Anderson wrote:
>>>>
>>>>     
>>>>
>>>>> On Thu, Sep 04, 2008 at 10:08:45PM -0400, Dan Armstrong wrote:
>>>>>
>>>>>       
>>>>>
>>>>>> In IOS, if I set next-hop self in a neighbor relationship with 
>>>>>> an  RR-Client, it sets the next-hop to itself for routes learned 
>>>>>> from local  eBGP sessions, but leaves the next-hop unchanged for 
>>>>>> routes that it's  passing on from other fellow route-reflectors...
>>>>>>
>>>>>> The *problem* is that in JunOS, if I set next-hop self on a 
>>>>>> neighbor  relationship with an RR-Client, it sets the next-hop to 
>>>>>> itself all the  time, even on routes it's passing on from other 
>>>>>> fellow route-reflectors,  effectively sucking all traffic into 
>>>>>> the route reflector and totally  defeating the purpose of route 
>>>>>> reflecting.
>>>>>>
>>>>>>         
>>>>>>
>>>>> That's just the way it is in JunOS--not much policy-related 
>>>>> behavior is hard-coded into JunOS like it might be in other 
>>>>> vendors.  This gives you the most flexibility in writing policy to 
>>>>> do exactly what you want.
>>>>>
>>>>>
>>>>>       
>>>>>
>>>>>> Now, of course we can policy-statement our way out of this - with 
>>>>>> big  messy kludgey stuff, but it seems to me that there has to be 
>>>>>> a fairly  simple and elegant way to do this, since it's pretty 
>>>>>> common, no?
>>>>>>
>>>>>> (My current kludge is to set an import policy on my eBGP sessions 
>>>>>> that  tag each route with a community called "HERE", have an 
>>>>>> export policy  towards all my iBGP neighbors to set next-hop self 
>>>>>> if the route is  tagged with the community "HERE", then strip it 
>>>>>> off - so that the  community "HERE" never leaves any box.)
>>>>>>
>>>>>>         
>>>>>>
>>>>> That is one recommended method.  The other is to match the eBGP 
>>>>> neighbor and only apply next-hop self to routes from your eBGP peers.
>>>>>
>>>>> e.g. in your IBGP export policy (from the JNCIP study guide):
>>>>>
>>>>> term 3 {
>>>>>    from {
>>>>>        protocol bgp;
>>>>>        neighbor [ 172.16.0.14 172.16.0.18 ];
>>>>>    }
>>>>>    then {
>>>>>        next-hop self;
>>>>>    }
>>>>> }
>>>>>
>>>>> where 172.16.0.14 and 17.16.0.18 are eBGP peer addresses.
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net 
>>>>> <mailto:juniper-nsp at puck.nether.net>
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>
>>>>>       
>>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net 
>>>> <mailto:juniper-nsp at puck.nether.net>
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>>     
>>>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net 
>> <mailto:juniper-nsp at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>