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

[Amos Rosenboim]

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



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>  
>> 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
>>>> 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
>>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp