[c-nsp] C3k: IPv6 multicast listener reports causes high CPU

Peter Rathlev peter at rathlev.dk
Mon Mar 3 14:38:38 EST 2014

We have some 3560G switches whose control-plane is useless because the
switch punts ~2200 pps via the "sw forwarding" CPU queue. Investigating
shows that it's caused to IPv6 traffic. The switch itself is stricly
layer-2, is using the "desktop default" SDM template and has no IPv6
features (like MLD snooping) configured. It is my understanding that a
strict layer-2 switch should not have any problems transporting IPv6,
and most of our switches are fine.

Two short questions to begin with: Is there any way to police the CPU
interface of Catalyst 3k switches? And are we supposed to configure
something on those switches just to support L2 forwarding of IPv6?

Description of the problem: CLI is sluggish, control plane packets (like
ping monitoring) are dropped. CPU load is high and the switch is punting
packets. Debugging with "debug platform cpu-queue software-fwd-q" gives
us thousands of lines like these two:

 113505: Mar  3 19:36:59.901 CET: SW-FWD-Q-FastSW:Dropped: Local Port
   Blocked L3If: L2If:GigabitEthernet0/49 DI:0x1F, LT:79, Vlan:628
   SrcGPN:49, SrcGID:49, ACLLogIdx:0x0,
   MacDA:3333.ff11.b8e2, MacSA: b8ca.3a80.e4be
   IPv6 SA:FE80::BACA:3AFF:FE80:E4BE DA:FF02::1:FF11:B8E2 Nexthdr:0

 113513: Mar  3 19:36:59.917 CET: SW-FWD-Q: IPv6 w/opt consumed by
   SW-Bridging: Local Port Blocked L3If: L2If:GigabitEthernet0/51
   DI:0x1F, LT:79, Vlan:0
   SrcGPN:51, SrcGID:51, ACLLogIdx:0x0,
   MacDA:3333.ff11.b8e2, MacSA: b8ca.3a80.e4be
   IPv6 SA:FE80::BACA:3AFF:FE80:E4BE DA:FF02::1:FF11:B8E2 Nexthdr:0

A tcpdump (v3.9.4) of the packets (not the same as above) says:

  20:11:49.973164 IP6 (hlim 1, next-header: Options (0), length: 32) 
   fe80::5ef9:ddff:feea:9552 > ff02::1:ff11:b8e2:
   HBH (padn)(rtalert: 0x0100)
   [icmp6 sum ok] ICMP6, multicast listener report,
   length 24max resp delay: 0 addr: ff02::1:ff11:b8e2
     0x0000: 6000 0000 0020 0001 fe80 0000 0000 0000  `...............
     0x0010: 5ef9 ddff feea 9552 ff02 0000 0000 0000  ^......R........
     0x0020: 0000 0001 ff11 b8e2 3a00 0100 0502 0100  ........:.......
     0x0030: 8300 3f04 0000 0000 ff02 0000 0000 0000  ..?.............
     0x0040: 0000 0001 ff11 b8e2                      ........

They are multicast listener reports, and there are far far too many of
them from each PC. That is a "problem" with the PC which other people
are (supposed to be) looking at.

What I don't understand is why this ends up in a CPU queue on a 3560.
Shouldn't the "Router Alert" option only be picked up by devices doing
L3 forwarding? We see several switches with these symptoms but also
several without. Even switches which are almost identical in
configuration, hardware and IOS behave differently.

The data presented here were taken from a WS-C3560G-48PS-S running
"c3560-ipbasek9-mz.122-50.SE3.bin". The uplink where the packets enter:

 interface GigabitEthernet0/51
  description auhsk-c1403-2 Gi0/51 [CDP]
  switchport trunk encapsulation dot1q
  switchport mode trunk
  switchport nonegotiate
  priority-queue out 
  mls qos trust dscp
  macro description trunk
  spanning-tree link-type point-to-point

This switch has no edge ports in VLAN 628, but we see the symptom on
switches with such. The IPv6 is link-local only; there's no IPv6
forwarding configured on any routers. In most places we outright block
IPv6 (via QoS settings on the 3k models), but not here.

So apart from just blocking all IPv6 (which wouldn't be hard, but feels
like going the wrong way) what can I do? :-)


More information about the cisco-nsp mailing list