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

[James Jun]

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