|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Cisco uRPF failures
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
|