[c-nsp] High CPU: punted packets

[Tóth András]

Hi,

Dest Index 0x380 means the traffic is punted to the RP CPU. That can be due
to several reasons, such as various exceptions, or simply because traffic
is destined to the switch.

The all-0 src mac seems strange. I would recommend doing a full packet
capture of the interface where this is coming from to see how the packets
look like. Maybe they're corrupted, or have IP Options which require
punting. You could try configuring 'ip options drop' as well.

Any fancy thing on the ingress port or the destination port (where traffic
should be sent based on dest IP), or the Vlan interface? Things like uRPF,
ACL, Netflow, PBR, Tunneling, etc? Try turning these off to see if there's
any improvement.

Best regards,
Andras


On Thu, Nov 22, 2012 at 8:49 AM, Saku Ytti <saku at ytti.fi> wrote:

> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>