[c-nsp] CoPP not catching software-switched CEF

[Blake Willis]

         Average packet size was 84 bytes, so it shouldn't be a large MTU 
fragmentation issue, but it could be another type of fragmentation attack given 
the packet size and the fact that the PFC obviously couldn't grok the L4 header. 
Digging around a bit, we have a command (in SXD7b anyway) that seems to be 
completely undocumented and un-googlable (bug tool didn't find anything either. 
There's RFC1858 and plenty of other doc on the subject in general though):

lab-3bxl#sh mls qos tiny-fragment
tiny-fragment policing is not running
current thresholds: low 0, high 0, aggregate 0

lab-3bxl(config)#mls qos protocol ip ?
   tiny-fragment  rate limit IP fragments with offset of 1

lab-3bxl(config)#mls qos protocol ip tiny-fragment ?
   aggregate-threshold  configure the aggregate threshold
   high-threshold       configure the high threshold
   low-threshold        configure the low threshold

lab-3bxl(config)#mls qos protocol ip tiny-fragment aggregate-threshold 1024000
Global monitoring of IPv4 packets whose fragment offsets are 1 has STARTED.
lab-3bxl(config)#^Z
lab-3bxl#sh mls qos tiny-fragment
tiny-fragment policing is running
current thresholds: low 51200, high 512000, aggregate 1024000

 	It would be great if someone from Cisco could chime in on what these 
thresholds represent, if there's some way to monitor the current rate, and how 
this thing works in general...

 	BTW I've noticed that some folks on the list have this turned off on an 
interface basis, probably assuming that the 'no' version of this command would 
block tiny fragments on the interface, but in fact it seems to do the opposite 
when the "mls qos protocol ip tiny-fragment" policer is running (and nothing 
otherwise):

lab-3bxl#conf t
lab-3bxl(config)#int t2/1
lab-3bxl(config-if)#no mls qos ?
   tiny-fragment      allow IP fragment rate limiting

  -Blake

---
  Blake Willis
  Network Engineer
  blake at 2112 dot net