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

[Dan Armstrong]

Those people <ahem> that first planted this notion in my head is 
watching this list - they're free to chime in anytime. :-)



James Jun wrote:
> Well, given the fact that BGP uses IGP information (metric) to make 
> best-path decision, you should include inter -AS xfernets in your IGP 
> if you want to do decent deterministic traffic engineering toward your 
> nexthops.
>
> I think the whole notion of "my IPs in IGP only" is silly..
>
> James
>
> Sent from my iPhone
>
> On Sep 9, 2008, at 4:01 PM, Dan Armstrong <dan at beanfield.com> wrote:
>
>> 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
>>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp