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: rob...@custodiandc.com
http://www.CustodianDC.com


_______________________________________________
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to