[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