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

[Tóth András]

I don't see in RFC 1122 that the original packet should/must be dropped
when a redirect condition is triggered and an icmp redirect message is
sent. So I think it's normal that the supervisor forwards all packets, RFC
792 seems to confirm this. If you want to avoid packets to be punted, "no
ip redirects" and "mls rate-limit" are there.

Are you sure that the traffic triggering the redirects is 10 Mbit/s? Are
you sure it's subject to CoPP at all? Maybe that's why you're not seeing
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.

If doing a CPU capture confirms that 10Mbps is punted indeed, TAC can help
you to perform an ELAM capture for that traffic to see if it will trigger a
redirect (based on destination index) or not. They can also assist in
performing CPU captures using netdr in RX and TX directions to see how many
and what kind of packets are punted to CPU and what is generated by the CPU.

Best regards,
Andras



On Mon, Feb 11, 2013 at 7:07 PM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:

> On 11/02/13 17:42, Tóth András wrote:
>
>> Hi Phil,
>>
>> As I understand you have disabled the MLS rate-limiter for redirects, so
>> that should not cause throttling, but you can check with "sh ibc" to see
>> the rate at which packets arrive to the CPU.
>>
>
> For clarity, I haven't disabled it; it's disabled by default. But yes, the
> MLS redirect limiter is disabled.
>
>
>
>> With mls rate-limit redirect disabled, packets will be still subject to
>> CoPP because they require CPU processing to generate a redirect, so
>> perhaps your CoPP policy (probably class default) is limiting them? That
>> can also cause packet loss between those stations if the traffic
>> requires punting.
>>
>
> Good guess, but I don't think so; removing the control-plane service
> policy has no effect (and in any case, the packets which are generating the
> redirect would be hitting a class-map with a 10Mbit/sec rate-limit, which
> is too high to make 1 redirect/sec).
>
> At this point, all the evidence suggests that:
>
>  1. The box is forwarding the packets back out
>  2. No more than once a second, the DFC/PFC is leaking a packet to the CPU
>  3. This packet generates the redirect
>
> I'm trying to determine what is going on in step 2; specifically, what's
> the "key" value for the rate-limit? Ingress interface, source IP, per
> forwarding engine?
>
> It's worth noting that this behaviour is also undocumented; all the docs
> I've seen imply that redirects happen every packet. What if you had a
> (weird!) config where you didn't *want* the sup720 to forward the original
> packet, and always wanted to *just* send the redirect?
>
> As you say, I *assume* the punts are subject to CoPP, but who knows?
>
>
>  You could also check the "ip icmp rate-limit unreachable" command, might
>> be applicable here too.
>>
>
> No effect sadly.
>
> Very weird...
>