[c-nsp] sup720 ICMP redirects "once per second"

[Phil Mayers]

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