Mailing List Archive: Cisco: NSP

reverse path filtering doesn't seem to work

Index | Next | Previous | View Threaded

mike-cisconsplist at tiedyenetworks

Nov 20, 2009, 6:12 AM

Post #1 of 8 (955 views)
Permalink

reverse path filtering doesn't seem to work

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-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

steve at ibctech

Nov 20, 2009, 6:35 AM

Post #2 of 8 (904 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

Mike wrote:
> 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?

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-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

mike-cisconsplist at tiedyenetworks

Nov 20, 2009, 6:54 AM

Post #3 of 8 (909 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

Steve Bertrand wrote:
>
> 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-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

petelists at templin

Nov 20, 2009, 8:46 AM

Post #4 of 8 (908 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

justin at justinshore

Nov 20, 2009, 11:06 AM

Post #5 of 8 (906 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

Pete Templin wrote:

> 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-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

mike-cisconsplist at tiedyenetworks

Nov 21, 2009, 12:20 PM

Post #6 of 8 (882 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

Justin Shore wrote:
> Pete Templin wrote:
>
>> 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?
>

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-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

justin at justinshore

Nov 22, 2009, 12:08 AM

Post #7 of 8 (862 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

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

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

asturluismi at gmail

Nov 23, 2009, 10:08 AM

Post #8 of 8 (847 views)
Permalink

Re: reverse path filtering doesn't seem to work [In reply to]

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

El vie, 20-11-2009 a las 06:12 -0800, Mike escribi�:
> 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-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads