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

Chuck Anderson cra at WPI.EDU
Thu Sep 4 22:47:56 EDT 2008


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.


More information about the juniper-nsp mailing list