On 02/11/2013 08:07 PM, Tóth András wrote:
I don't see in RFC 1122 that the original packet should/must be dropped
Sure; never suggested it did/should. I'm trying to understand what IOS feature/command/whatever distinguishes between the the packets that are just forwarded, and those that also generate a redirect.
RFC 792 seems to confirm this. If you want to avoid packets to be punted, "no ip redirects" and "mls rate-limit" are there.
Not what I want at this stage; I don't even know if the redirects are implicated, and need to understand more.
Are you sure that the traffic triggering the redirects is 10 Mbit/s? Are
Think we're talking at cross-purposes there; I'm saying it's *less* than 10Mbit/sec, therefore should *not* be policed, and should (if punting is happening) all be passed to the CPU.
you sure it's subject to CoPP at all? Maybe that's why you're not seeing
Yes; the 10Mbit/sec class is last in the list, with an "ip any any" ACL. So, unless CoPP isn't *working* (and I have checked the internal vlan TCAM on the SP) the traffic triggering the redirects should either:
a. not be punted at all b. every packet punted
matches in CoPP counters. You can do an inband SPAN or netdr capture to see if packets are really punted. I would keep on the table that maybe some pings between host1 and host2 or some other hosts trigger the redirects and that original traffic is 1 pps.
No, that's not the case. I'm using actual SPAN on the physical gigE to observe a continually flowing TCP stream of 10-50pps, and I am seeing ICMP redirect at very precise 1-second intervals, with embedded IP payloads corresponding to packets from that TCP stream.
So, something somewhere is making the decision to issue a redirect 1/sec in response to traffic that's >10pps. I'm confident it's not CoPP, and am wondering what.
If doing a CPU capture confirms that 10Mbps is punted indeed, TAC can
Unfortunately, this particular box has had problems with CPU SPAN in the past (total loss of RP CPU packet reception) so until it's reloaded I can't do a SPAN. ELAM is a possibility, but to be honest, your faith in TAC considerably exceeds my own - I have no wish to waste my time dealing with a clueless TAC engineer, which is the usual outcome.
At this point I think we've done the issue to death - unless someone knows where this 1/sec thing comes from, I'm going to let it drop. Thanks for your interest.
Cheers, Phil _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
