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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp