[c-nsp] reverse path filtering doesn't seem to work

[Mike]

Gang,

I have a 3725 with some t1 interfaces. I want to be a good netizen and
establish urpf on my customer facing interfaces to ensure they can't
send me spoofed traffic. When I enable 'ip verify unicast source
reachable-via rx' however, suddenly I can't ping the router on the other
side. Here's the relevant configs:


interface Serial0/0
ip unnumbered Loopback0
ip access-group egress-antispoof out
service-module t1 clock source internal
service-module t1 remote-alarm-enable
service-module t1 fdl both
end

ip route x.x.74.0 255.255.255.248 Serial0/0

ip access-list extended egress-antispoof
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 224.0.0.0 31.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
permit ip any any




Yes in my route table I have a directly connected route as per above:

Known via "static", distance 1, metric 0 (connected)
Redistributing via ospf 1
Advertised by ospf 1 subnets
Routing Descriptor Blocks:
* directly connected, via Serial0/0
Route metric is 0, traffic share count is 1

I am pinging from the router cli to x.x.74.1 and with the 'ip verify
unicast' enabled, packets seem to be dropped. My expectation is simply
that the above static route should be enough to tell 'ip verify' to
allow x.x.74.0/29 as a source on this interface. Does anyone know what
the deal might be?

Mike-
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mike]

Hi Mike,
It's not clear to me whether you are pinging from CPE->you or you->CPE.

I said I was pinging from my router cli - the side that I want to
implement urpf on.

Is this serial link the only connection that the CPE has? Do you have
uRPF enabled on your side, as well as the CPE?

I only enable it on my router and never touch the CPE. When I turn it
on, on my router, I can no longer ping the CPE from my router. When I
disable urpf on my router, I can again ping it.

...and perhaps a silly question... does this work if you disable uRPF?

As I said, yes it does work when urpf if off.


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Steve Bertrand]

Post by Mike
Gang,
I have a 3725 with some t1 interfaces. I want to be a good netizen and
establish urpf on my customer facing interfaces to ensure they can't
send me spoofed traffic. When I enable 'ip verify unicast source
reachable-via rx' however, suddenly I can't ping the router on the other
interface Serial0/0
ip unnumbered Loopback0
ip access-group egress-antispoof out
service-module t1 clock source internal
service-module t1 remote-alarm-enable
service-module t1 fdl both
end
ip route x.x.74.0 255.255.255.248 Serial0/0
ip access-list extended egress-antispoof
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
deny ip 224.0.0.0 31.255.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 240.0.0.0 15.255.255.255 any
permit ip any any
Known via "static", distance 1, metric 0 (connected)
Redistributing via ospf 1
Advertised by ospf 1 subnets
* directly connected, via Serial0/0
Route metric is 0, traffic share count is 1
I am pinging from the router cli to x.x.74.1 and with the 'ip verify
unicast' enabled, packets seem to be dropped. My expectation is simply
that the above static route should be enough to tell 'ip verify' to
allow x.x.74.0/29 as a source on this interface. Does anyone know what
the deal might be?

Hi Mike,

It's not clear to me whether you are pinging from CPE->you or you->CPE.

Is this serial link the only connection that the CPE has? Do you have
uRPF enabled on your side, as well as the CPE?

...and perhaps a silly question... does this work if you disable uRPF?

Steve
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Pete Templin]

Post by Mike
Gang,
I have a 3725 with some t1 interfaces. I want to be a good netizen and
establish urpf on my customer facing interfaces to ensure they can't
send me spoofed traffic. When I enable 'ip verify unicast source
reachable-via rx' however, suddenly I can't ping the router on the other

I don't know how well it'll work on an unnumbered interface etc., but I
always add the option 'allow-self-ping' to my commands, i.e. 'ip ve u s
r r allow-s'. I suspect that's related to your troubles.

pt

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Justin Shore]

Post by Pete Templin
I don't know how well it'll work on an unnumbered interface etc., but I
always add the option 'allow-self-ping' to my commands, i.e. 'ip ve u s
r r allow-s'. I suspect that's related to your troubles.

I'm using uRPF and IP Unnumbered on DS1s today and all seems to be well.
I can ping the directly-connected target of the static route from the
PE too:

interface Serial1/0/3:0
ip unnumbered Loopback197
ip verify unicast source reachable-via rx
no ip redirects
no ip unreachables
no ip proxy-arp
load-interval 30
snmp trap ip verify drop-rate
no cdp enable
service-policy input Armstrong-in
service-policy output Armstrong-out

Mike, can you make sure that IOS thinks uRPF is actually enabled?

sh ip int se0/0 | i uRPF

7206-1.bway#sh ip int se1/0/3:0 | i uRPF
Input features: Stateful Inspection, CCE Input Classification, uRPF,
QoS Marking, MCI Check


Are you seeing the drops in the sh ip int output or somewhere else?

Justin
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Mike]

Post by Justin Shore

Post by Pete Templin
I don't know how well it'll work on an unnumbered interface etc., but
I always add the option 'allow-self-ping' to my commands, i.e. 'ip ve
u s r r allow-s'. I suspect that's related to your troubles.

I'm using uRPF and IP Unnumbered on DS1s today and all seems to be
well. I can ping the directly-connected target of the static route
interface Serial1/0/3:0
ip unnumbered Loopback197
ip verify unicast source reachable-via rx
no ip redirects
no ip unreachables
no ip proxy-arp
load-interval 30
snmp trap ip verify drop-rate
no cdp enable
service-policy input Armstrong-in
service-policy output Armstrong-out
Mike, can you make sure that IOS thinks uRPF is actually enabled?
sh ip int se0/0 | i uRPF
7206-1.bway#sh ip int se1/0/3:0 | i uRPF
Input features: Stateful Inspection, CCE Input Classification, uRPF,
QoS Marking, MCI Check
Are you seeing the drops in the sh ip int output or somewhere else?

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?


Mike
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Justin Shore]

Post by Justin Shore
ip verify unicast source reachable-via rx
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


_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[luismi]

try "debug ip cef drops verify" and "debug ip cef drops
suppressed-verify" so you can see what is going on inside the router
with urpf

Post by Mike
above static route should be enough to tell 'ip verify' to
allow x.x.74.0/29 as a source on this interface. Does anyone know what
the deal might be?

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/