[c-nsp] IP Options Drop

[Robert Williams]

Hi,

>I believe you need to use 'mls rate-limit unicast ip options', of course it will break your IP options
> dependent service earlier, but at least your whole network won't be dead.
>
>--
>  ++ytti

Yes indeed thanks - I've set that up (well, increased the limit because it was already active) as I can't find any documentation which indicates where/how/why IP Options are not matching in the ACLs.

I also found out something interesting with my testing in the Lab. The "ip options drop" setting doesn't work, or at least not as I would expect. The RP _always_ gets _all_ the packets with IP options punted to it regardless of the state of the "ip options drop" or "no ip options" setting.

If the drop setting is active then the RP doesn't appear to _process_ the IP options, but it still _gets_ them punted, so they are not exactly dropped as the name suggests. Which means that if you send >1Gbit/s of IP Options to the chassis with ip options drop enabled, it dies because it saturates the control-plane interface's line rate. I tested this incidentally and it's true.

So the maximum you can set the mls rate-limit unicast ip options is ~80,000pps so that it drops if you receive > 80kpps of ~1500 frames, with a little bit of space for other normal packets. The same is true for multicast frames with IP Options set, although storm-control would handle these also of course.

I've also found that you can use the per-interface hold-queues and SPD headroom to ensure that even when flooded at >80kpps of IP options frames your 'required' IP Options (RSVP in this case) still have a reasonable chance of getting through. This was achieved by lowering the hold-queue on the non-core interfaces so that they cannot punt more than a certain rate (in my case "hold-queue 25 in" was perfect). It now takes 2.2GBit/s across spread across 5 x 1G interfaces (circa 170kpps total) before the RSVP interaction eventually breaks down intermittently. Which is more than sufficient for this particular scenario.

Anyway, it's been an interesting little experience! :)

Cheers!


Robert Williams
Custodian Data Centre
Email: Robert at CustodianDC.com
http://www.CustodianDC.com