[c-nsp] High CPU: punted packets

[Saku Ytti]

On (2012-11-22 09:50 +0700), Jefri Abdullah wrote:

> ------- dump of incoming inband packet -------
> interface NULL, routine mistral_process_rx_packet_inlin, timestamp
> 10:21:58.298
> dbus info: src_vlan 0x402(1026), src_indx 0x342(834), len 0x5D(93)
>   bpdu 0, index_dir 0, flood 0, dont_lrn 0, dest_indx 0x380(896)
>   2D020C01 04020000 03420000 5D000000 00110000 20000000 00000000
> 03800000
> mistral hdr: req_token 0x0(0), src_index 0x342(834), rx_offset
> 0x76(118)
>   requeue 0, obl_pkt 0, vlan 0x402(1026)
> destmac 00.24.C4.C0.0B.40, srcmac 00.00.00.00.00.00, protocol 0800
> protocol ip: version 0x04, hlen 0x05, tos 0xBA, totlen 75, identifier 0
>   df 0, mf 0, fo 0, ttl 61, src *.*.*.*, dst *.*.*.*
>   udp src 20868, dst 19342 len 55 checksum 0xA915
> 
> We've no idea why the incoming interface is NULL, and why this packet
> is punted. Do you guys have any clue about this?

Clue here is 'dest_indx', we can determine this is not interface LTL index as
0x380.divmod(64) gives 14,0 and we don't have 15 slots.

You can do 'remote command switch show platform hardware tycho register 0 1794
| i 000380' to see potential reasons for punt.

On my box, I see:
----
 0x017F:            PP_RF_SRC_IDX0 = 0x00000380 [896       ]
 0x03C4:            RED_SW_ERR_IDX = 0x00000380 [896       ]
 0x0456:            RED_FINRST_IDX = 0x00000380 [896       ]
 0x045B:          RED_IPV6_SCP_IDX = 0x00000380 [896       ]
---

I happen to know from heart that one reason for 380 is MTU-failure, while it is
not obvious from above. If there is some way to know for sure which of those
registers the punt is hitting, I don't know it, but would love to hear.

But as you're having very small frame, I doubt it is MTU-failure. I'm pretty
much out of ideas. You could verify it's not URPF, but I think URPF is using
different index. (Just because uRPF is not now configured in interface in CLI,
does not mean uRPF/strict isn't dropping your frames)

If you can reliably produce it and measure via ping, you could try setting mls
rate-limites to 10/10 one by one, to see exactly which one it is hitting, it
could give more data.

-- 
  ++ytti