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. And see here for current known issues.

New Member

ip verify unicast reverse-path not working

I've configured ip ip verify unicast reverse-path on a Cisco 2611 running 12.3(26) code. ip cef is enabled globally but turned off using the no ip route-cache cef command on all interfaces except the WAN facing interface (serial 0/0).

!

interface Serial0/0

description connected to internet

bandwidth 768

ip address 100.100.20.10 255.255.255.252

ip verify unicast reverse-path

no ip redirects

no ip unreachables

no ip proxy-arp

ip accounting access-violations

ip nat outside

ip route-cache flow

no ip mroute-cache

no fair-queue

no cdp enable

!

Whenever I reload the router, it works for a while, then quits working. The show ip traffic counter for unicast rpf drops quits climbing after a few minutes and stays where it stopped.

IP statistics:

Rcvd: 35015 total, 346 local destination

0 format errors, 0 checksum errors, 0 bad hop count

0 unknown protocol, 17 not a gateway

0 security failures, 0 bad options, 0 with options

Opts: 0 end, 0 nop, 0 basic security, 0 loose source route

0 timestamp, 0 extended security, 0 record route

0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump

0 other

Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble

0 fragmented, 0 fragments, 0 couldn't fragment

Bcast: 6 received, 0 sent

Mcast: 0 received, 0 sent

Sent: 265 generated, 23074 forwarded

Drop: 1 encapsulation failed, 0 unresolved, 0 no adjacency

120 no route, 467 unicast RPF, 0 forced drop

0 options denied

Drop: 0 packets with source IP address zero

Drop: 0 packets with internal loop back IP address

Can anyone think of a reason it works for a few seconds after bootup then stops?

[edit]

I took out the ip route-cache flow statement thinking that was the problem, but still no change in the counter so far.

1 ACCEPTED SOLUTION

Accepted Solutions

Re: ip verify unicast reverse-path not working

There are multiple ways you can use to achieve the same goal, some examples are:

> ACLs

> Policy Based Routing + ACLs (Two interfaces, marking on one, dropping via ACL)

> MPF 'drop' keyword

> Black Hole Routing (Routes to Null 0)

> uRPF

Each method has its pros and cons, ACLs and Static routes are difficult to maintain and operate. ACLs with the 'log' keyword are process switched, making them slow.

Black hole routing works by sending spoofed traffic (hitting the bogons) to Null0, since Null0 is a direct adjacency (Sort-of interface) of all CEF-enabled routers, this is relatively faster.

uRPF is commonly used with Remotely Triggered Blackhole routing (RTBH). For example one manages a large organization with multiple entry points into the network. Now you know your network is under a DoS attack from Source 1.2.3.0/24, with RTBH, all edge routers have uRPF enabled, and there is an internal router known as a 'Trigger Router'. You could inject a route into your IGP domain, something like:

ip route 1.2.3.0 255.255.255.0 null0 tag 255

And then all your edge routers would receive this route and with the help of uRPF drop all packets 'sourced' from the attacker network. The process is a little more complicated than this, but I hope you get the idea.

Regards

Farrukh

9 REPLIES
New Member

Re: ip verify unicast reverse-path not working

I think I've found my answer here:

http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/uni_rpf.html

"Routing Tables Requirements

To work correctly, Unicast RPF needs proper information in the CEF tables. This requirement does not mean that the router must have the entire Internet routing table. The amount of routing information needed in the CEF tables depends on where Unicast RPF is configured and what functions the router performs in the network. For example, in an ISP environment, a router that is a leased-line aggregation router for customers needs only the information based on the static routes redistributed into the IGP or IBGP (depending on which technique is used in the network). Unicast RPF would be configured on the customer interfaces-hence the requirement for minimal routing information. In another scenario, a single-homed ISP could place Unicast RPF on the gateway link to the Internet. The full Internet routing table would be required. Requiring the full routing table would help protect the ISP from external DoS attacks that use addresses that are not in the Internet routing table."

Being that this is a pass-through border router between my ISP and my firewall, it has almost nothing in the routing tables. Just a default route to my ISP and its own directly connected networks from the assigned IP's.

I think I have to use a simple bogon and martian ACL to stop invalid packets.

Re: ip verify unicast reverse-path not working

It depends on which mode of uRPF you are using, loose or strict, both behave differently.

ISPs usually go for the loose mode implementation. Also there is an 'allow-default' keyword to use the default route in uRPF check (which is enabled by default).

Have a look at these links:

Strict mode (with old syntax):

http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrpf.html

Loose mode:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ft_urpf.html

Regards

Farrukh

New Member

Re: ip verify unicast reverse-path not working

Thanks Farukh,

I'm looking over those articles. I have no routing protocol like BGP running between my ISP and my router, only a default route for all unknown traffic to go to the ISP's router. How would uRPF know to drop any packets if the default route is allowed?

When using the new command, ip verify unicast source reachable-via rx [edit](strict mode), without allow-default, all packets are dropped. If I allow default, aren't all packets permitted?

The router would only drop packets from subnets on other interfaces. It knows of no other routes [edit] regardless of whether I'm using strict or loose mode.

[edit] I gues I'm wondering if verify unicast reverse-path requires a routing protocol to be in use, or if it will work if there is no routing protocol in use and only a default route to the ISP is configured.

Re: ip verify unicast reverse-path not working

Your understanding is correct. If you don't have any bogons, RFC 2827 filters etc and just have a default route, uRPF won't be able to do much. The use of a routing protocol is not a must.

Re: ip verify unicast reverse-path not working

Btw, this is a good place to start with the appropriate router configuration:

http://www.cymru.com/Documents/secure-ios-template.html

Regards

Farrukh

New Member

Re: ip verify unicast reverse-path not working

Hi Farukh,

I'm using that, the NSA SNAC Router Security Configuration Guide, and the Cisco Guide to Harden Cisco IOS Devices, Doc. ID 13608.

I'm also using Thomas Akin's book "Securing Cisco Routers".

I'm working on a Master's Project in Information Technology and it involves router security. Thanks for your help with this!

Ted

New Member

Re: ip verify unicast reverse-path not working

I'm not clear on what advantage would be provided over a straight anti-bogon/martian acl.

Re: ip verify unicast reverse-path not working

There are multiple ways you can use to achieve the same goal, some examples are:

> ACLs

> Policy Based Routing + ACLs (Two interfaces, marking on one, dropping via ACL)

> MPF 'drop' keyword

> Black Hole Routing (Routes to Null 0)

> uRPF

Each method has its pros and cons, ACLs and Static routes are difficult to maintain and operate. ACLs with the 'log' keyword are process switched, making them slow.

Black hole routing works by sending spoofed traffic (hitting the bogons) to Null0, since Null0 is a direct adjacency (Sort-of interface) of all CEF-enabled routers, this is relatively faster.

uRPF is commonly used with Remotely Triggered Blackhole routing (RTBH). For example one manages a large organization with multiple entry points into the network. Now you know your network is under a DoS attack from Source 1.2.3.0/24, with RTBH, all edge routers have uRPF enabled, and there is an internal router known as a 'Trigger Router'. You could inject a route into your IGP domain, something like:

ip route 1.2.3.0 255.255.255.0 null0 tag 255

And then all your edge routers would receive this route and with the help of uRPF drop all packets 'sourced' from the attacker network. The process is a little more complicated than this, but I hope you get the idea.

Regards

Farrukh

New Member

Re: ip verify unicast reverse-path not working

Thanks Farukh,

I'll look into each and try to figure out what suits my situation the best.

Ted

624
Views
5
Helpful
9
Replies