I haven't tested this but I think:
term term1 {
from {
protocol [ direct static ];
interface fxp0.0;
}
then reject;
}
in your export policy would be a "generic" way to prevent any routes
from the fxp interface from being injected into BGP.
In our policies we explicitly allow prefixes we want in BGP and deny
everything else by default so it's not really an issue. In my
experience that is pretty much standard practice for BGP...otherwise you
could accidentally leak all sorts of nasty things.
Kevin
On 09/27/2012 03:06 PM, Jo Rhett wrote:
Reply to Harry and Doug both since you mostly asked the same question.
On Sep 27, 2012, at 12:13 PM, Harry Reynolds wrote:
It might help if you posted your BGP export policy. IIRC, there is a
no-readvertise flag available for a static but not aware of any inherent
blocking of the advertisement of an fxpo address via BGP, more so if your
export permits it.
To me it is a bug to advertise a route which you won't route packets for.
Obviously it's your fault if you advertise a route and have a packet filter
blocking packets -- the routing engine isn't responsible for this. But fxp0 is
supposedly on its own routing fabric. I can't send packets in ae0 destined for
something on the fxp0 network.
If a route visible in one routing engine was advertised out by another routing
engine (with no route-sharing between them) this would be a bug, yes? Why isn't
fxp0 treated the same way?
Finally, we have the same export policy on every node in our network. Having to
break that out, and hand-tune every export policy to explicitly deny the fxp0
interface's routes is a lot of work with zero gain. If for some reason Juniper
feels that it's important to someone somewhere to announce a route you won't
accept packets for, why isn't there any easy method to disable this
nonsensical, nonfunctional, nobody in their right mind would or could use it
(non)functionality?
Obviously, a feature request for "protocol bgp { interface fxp0 { ignore; }}"
would do the trick, but I struggle to believe that you've never seen this problem before,
and you don't have a better way to prevent this behavior.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
