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 <[EMAIL PROTECTED]> 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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
