Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

uRPF with acces-list on 6500 with sup.720

I want to enable uRPF on a 6500 switch but it seems to take a lot of CPU.

So on around 170 SVIs I enter the command

ip verify unicast source reachable-via any allow-self-ping 199

and

Extended IP access list 199

10 permit ip any host x.x.x.x

So I want to drop packets that failed the reverse path verifying only if destination is not host x.x.x.x

If I enable it on only one SVI (with few traffic) it works ok. Is there a way to do this in hardware so that the cpu is not affected? The switch is a 6506 with sup720 / PFC3B

7 REPLIES
jv
New Member

Re: uRPF with acces-list on 6500 with sup.720

Danny,

On a Sup720, if you specify uRPF checking with an ACL, only the "permits" in the ACL are performed in hardware (@ the Supervisor), everything else is punted to the MSFC to be processed (which is why you're seeing high CPU utilization there).

You can either add your heavy traffic flows into the ACL so it's performed at the Sup or do uRPF without an ACL (which is hard where subnets have multiple entry points). uRPF without an ACL is usually processed in hardware.

HTH,

James

New Member

Re: uRPF with acces-list on 6500 with sup.720

James,

Thanks for reply but can you explain how to create de ACL to obtain:

let everyting for 192.168.0.1 pass even if urpf fails(the rpf check is not necessary)

for anything else perform urpf and drop if it fails

jv
New Member

Re: uRPF with acces-list on 6500 with sup.720

Unfortonately, there doesn't seem to be a scalable solution for this (170 SVIs).

The way I see it, you've got two options and none of them seem all that spectacular. You would need a somewhat customized ACL for each SVI where you have 2 permits (permit your subnet IP'd on the link and the 192.168 subnet ... assuming it's an end user subnet and not a routed link) or look at inbound ACL's instead of uRPF. Yes, I realize that both of these options are very suboptimal, but with the way it's implemented, we're out of luck.

Can you go into more detail about your 192.168 segment that needs to violate the standard uRPF check? Do you have multiple paths into a subnet?

James

jv
New Member

Re: uRPF with acces-list on 6500 with sup.720

Danny,

I thought you might find this helpful as well:

BugID: CSCsc81300

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsc81300

James

New Member

Re: uRPF with acces-list on 6500 with sup.720

I think you missundestand me. 192.168.0.1 is a DESTINATION address, not source address. It is a server which every host must reach.

So, every source hosts are verified with rpf but if the packet has destination address 192.168.0.1 the packet must be forwarded in any conditions. And the most traffic will NOT BE to this server.

In this case is there a sollution?

jv
New Member

Re: uRPF with acces-list on 6500 with sup.720

Danny,

If you only have 1 path into and out of a network, and you're not deliberately spoofing the source of traffic, then you may not need the ACL at all. If the SOURCE of all your traffic comes from legit ones, then the uRPF check has no reason to block it.

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper0900aecd802ca5d6.shtml

"Unicast Reverse Path Forwarding (URPF) discards packets that lack a consistent source IP address, such as spoofed IP source addresses created by malicious users to intercept valuable data."

James

New Member

Re: uRPF with acces-list on 6500 with sup.720

James,

I really need the uRPF feature and it is used to permit only authenticated users to acces the net ( along with blackhole method ). 192.168.0.1 is the authenticate server, that's why everybody must reach it to authenticate. Implementing uRPF assures that even outgoing packets of unauthenticated users don't get outside because of the /32 route to Null ( the replies gets droped anyway ).

494
Views
10
Helpful
7
Replies