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