[c-nsp] reverse path filtering doesn't seem to work
Justin Shore
justin at justinshore.com
Sun Nov 22 03:08:56 EST 2009
Mike wrote:
> Yes it's enabled per the above. The drops only occur when I use:
>
> ip verify unicast source reachable-via rx
>
> However, I discovered that if I instead use:
>
> ip verify unicast source reachable-via any allow-default
>
> That seems to at least not drop packets, but I haven't tested to see
> wether it really will drop everything but the subnet routed down this link.
>
> If I can ask, you seem to have something more than 'loopback 0' - tell
> me, how are your routes configured - I am assuming you just have a
> static route pointing thru the interface and not at 'loopback' anything,
> yes?
Lo197 is addressed with a /24. Each customer gets a /32 from that /24
via a static route pointing to the local PE interface (Se1/0/3:0 or
Mu1000 for example). If the customer needs a larger allocation I route
that to their /32 (could also route it to the local PE interface as
well). In cases where the CE is managed I also route a private IP over
to it and assign it to a local loopback on the CE. We use this for all
management tasks and never use the CE's public IP.
You're right; it is fairly simple. We're using this quite a bit these
days. Some customers insist on a dedicated /30 but it doesn't gain them
anything really. After explaining this they usually agree to a /32
instead. No sense in squandering a limited resource if we can avoid it.
I'm leaning towards an IOS bug for your particular issue. Is you IOS
release fairly modern?
Justin
More information about the cisco-nsp
mailing list