I had that thought too - but for some reason this condition matches all
external routes... even those learned by other ebgp routers... so this
effectively sucks all traffic towards the rr server too..
Sean Clarke wrote:
Hi Dan
You may want to use the "external" keyword in your policy. This way
you only set nhs to the external bgp routes, not ones learned via iBGP.
i.e.
policy-options {
policy-statement nhs {
from {
protocol bgp;
external;
}
then {
next-hop self;
accept;
}
}
}
cheers
Sean
Dan Armstrong wrote:
I'm new to JunOS, coming from IOS - and I'm having a heck of a time
wrapping my brain around something that should be fairly simple...
eg:
If I am a route-reflector server. I also have eBGP sessions. My
ebgp session's next hop is in 'other people's' address space, so I
don't carry it in my IGP, so I use next-hop self... Seems fairly
normal and common right?
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.
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.)
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
