[nsp] CAR bug

From: Hank Nussbacher (hank@att.net.il)
Date: Wed Jan 26 2000 - 06:15:54 EST


For the past 3 weeks I have been trying to view some Mpeg-1 videos at
around 2-3Mb/sec at Berkeley:
http://media2.bmrc.berkeley.edu/demo/mpeg/

All attempts to view the video clips at any rate above 1Mb/sec would lead
to failure. The problem was tracked down to a 7513 router running
12.0(5)T1 with CEF. There appear to a problem that UDP packets were being
affected by the acls even though it was only supposed to affect ICMP. This
is a heads-up for all those who use CAR to limit Smurf damage. You may be
affecting UDP as well.

BAD CAR:
  
  !
  interface FastEthernet8/0/0
   description Tier2 backbone, side A
   ip address 128.32.0.10 255.255.255.224
  ! NOTE: do not remove these access-group statements
   ip access-group 111 in
   ip access-group 110 out
   no ip directed-broadcast
   no ip proxy-arp
   ip pim sparse-dense-mode
   rate-limit input access-group 121 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit input access-group 122 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit output access-group 121 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit output access-group 122 64000 8000 8000 conform-action
transmit exceed-action drop
   ip route-cache flow
   no ip route-cache distributed
   full-duplex
  !
  interface FastEthernet9/0/0
   description Tier2 backbone, side B
   ip address 128.32.0.42 255.255.255.224
  ! NOTE: do not remove these access-group statements
   ip access-group 111 in
   ip access-group 110 out
   no ip directed-broadcast
   no ip proxy-arp
   rate-limit input access-group 121 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit input access-group 122 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit output access-group 121 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit output access-group 122 64000 8000 8000 conform-action
transmit exceed-action drop
   ip route-cache flow
   no ip route-cache distributed
   full-duplex
...
  ! acl 121 - rate limiting icmp echo requests
  access-list 121 permit icmp any any echo
  access-list 121 deny ip any any
  ! acl 122 - rate limiting icmp echo replies
  access-list 122 permit icmp any any echo-reply
  access-list 122 deny ip any any
...

GOOD CAR:
...
  !
  interface FastEthernet8/0/0
   description Tier2 backbone, side A
   ip address 128.32.0.10 255.255.255.224
  ! NOTE: do not remove these access-group statements
   ip access-group 111 in
   ip access-group 110 out
   no ip directed-broadcast
   no ip proxy-arp
   ip pim sparse-dense-mode
   rate-limit input access-group 120 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit output access-group 120 64000 8000 8000 conform-action
transmit exceed-action drop
   ip route-cache flow
   no ip route-cache distributed
   full-duplex
...
  !
  interface FastEthernet9/0/0
   description Tier2 backbone, side B
   ip address 128.32.0.42 255.255.255.224
  ! NOTE: do not remove these access-group statements
   ip access-group 111 in
   ip access-group 110 out
   no ip directed-broadcast
   no ip proxy-arp
   rate-limit input access-group 120 64000 8000 8000 conform-action
transmit exceed-action drop
   rate-limit output access-group 120 64000 8000 8000 conform-action
transmit exceed-action drop
   ip route-cache flow
   no ip route-cache distributed
   full-duplex
...
  ! acl 120 - rate limit icmp
  access-list 120 permit icmp any any
  access-list 120 deny ip any any
...

Ken tried:
access-list 120 permit icmp any any echo
access-list 120 permit icmp any any echo-reply
access-list 120 deny ip any any

and the UDP streams throttled.

Ken then tried the following acl:
  access-list 120 permit icmp any any echo
  access-list 120 deny ip any any
this too caused the stream to be throttled.

Whereas:
  access-list 120 permit icmp any any
  access-list 120 deny ip any any
seems okay.

Perhaps it's the extra processing incurred by looking deeper into the
packet (for the icmp type), or it's simply an IOS bug. Has anyone seen
anything like this?

-Hank



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:09 EDT