Cisco uRPF failures

Saku Ytti saku+nanog at ytti.fi
Mon Sep 8 03:55:10 CDT 2008


On (2008-09-04 09:35 -0700), Jo Rhett wrote:

> quickly, but that turns out not to be the case.  To this day I've never 
> found a network operator using uRPF on Cisco gear.
>   (note: network operator. it's probably fine for several-hundred-meg  
> enterprise sites)

To this day I've never met network operator not using uRPF on Cisco gear.
(note: network operator. It's probably not used widely by enterprises)

HOXBOX#sh run int ten4/1
Building configuration...

Current configuration : 126 bytes
!
interface TenGigabitEthernet4/1
 no ip address
 no ip redirects
 no ip proxy-arp
 load-interval 30
 hold-queue 4096 in
end


HOXBOX#sh run int ten4/1.42
Building configuration...

Current configuration : 220 bytes
!
interface TenGigabitEthernet4/1.42
 encapsulation dot1Q 42
 ip address 42.42.42.1 255.255.255.0
 ip verify unicast source reachable-via rx allow-default
 no ip redirects
 no ip proxy-arp
 no snmp trap link-status
end


HOXBOX#debug ip cef drops rate 5
IP CEF drops debugging is on rate 5
HOXBOX#term mon
HOXBOX#
Sep  8 10:49:58.622 CEST: CEF-Drop: Packet from 103.63.17.0 (Te4/1.42) to 205.219.27.0, Verify Unicast Reverse-Path feature
Sep  8 10:49:58.822 CEST: CEF-Drop: Packet from 121.215.245.0 (Te4/1.42) to 126.154.213.0, Verify Unicast Reverse-Path feature
Sep  8 10:49:59.022 CEST: CEF-Drop: Packet from 150.38.77.0 (Te4/1.42) to 108.119.215.0, Verify Unicast Reverse-Path feature
Sep  8 10:49:59.222 CEST: CEF-Drop: Packet from 133.69.24.0 (Te4/1.42) to 57.128.16.0, Verify Unicast Reverse-Path feature
Sep  8 10:49:59.422 CEST: CEF-Drop: Packet from 114.46.39.0 (Te4/1.42) to 192.4.227.0, Verify Unicast Reverse-Path feature
Sep  8 10:49:59.622 CEST: CEF-Drop: Packet from 135.96.1.0 (Te4/1.42) to 2.151.158.0, Verify Unicast Reverse-Path feature
Sep  8 10:49:59.822 CEST: CEF-Drop: Packet from 162.16.59.0 (Te4/1.42) to 205.67.228.0, Verify Unicast Reverse-Path feature
....


HOXBOX#sh int ten4/1
TenGigabitEthernet4/1 is up, line protocol is up (connected)
  Hardware is C6k 10000Mb 802.3, address is 0011.bb33.2600 (bia 0011.bb33.2600)
  MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 194/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
  Keepalive set (10 sec)
  Full-duplex, 10Gb/s
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:05:00, output 00:00:37, output hang never
  Last clearing of "show interface" counters 00:05:26
  Input queue: 0/4096/12860846/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 7618968000 bits/sec, 14880795 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 2 pkt, 180 bytes
  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
     4538227508 packets input, 290446560820 bytes, 0 no buffer
     Received 2 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 6430423 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     5 packets output, 2130 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out


HOXBOX#show processes cpu | i ^CPU
CPU utilization for five seconds: 9%/0%; one minute: 3%; five minutes: 6%


SRC: rand(43.0.0.0 .. 220.255.255.255)
DST: rand(1.0.0.0 .. 220.255.255.255)


It's entirely possible, and rather easy, to get interrupt load to 100%
in PFC3. One easy way to do it, is to send L2 broadcast to valid L3
IP unicast. And others. Most likely you just generated packets
that were punted to software, perhaps you may have been able
to secure them with mls rate-limit or CoPP, but there are DoS
vectors you can't protect PFC3 from.


-- 
  ++ytti




More information about the NANOG mailing list