Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!
syson suy

Multicast on 802.1Q Trunk issue

Hi All,

Multicast on 802.1Q Trunks issue;


igmp enabled on 2950 / 2960 / 2900XL access-layer L2 switches & dynamic mrouter via uplink port to 3560 (PIM sparse-mode + cgmp config on data vlan);

Ghost v11 multicast imaging server (source) on one access-layer L2 switch port & receivers only on one (1) OTHER L2 switch port works with multicast.   no other ports on this (1st & 2nd) switch receives multicast.


other access-layer L2 switches - also receives this multicast traffic on uplink port towards 3560.      I saturates all uplink ports (to access-layer L2 switches) even though there is no receivers on the rest of the cascaded L2-switches (trunked to edge router 3560).   "Show int count" on 3560 show outMulticastPkts increases on those uplink ports to 2960.     Only the one with receiver show inMulticastPkts increase.    It seems like the data vlan within 802.1Q trunks on all L2 access switches uplink ports also constains multicast traffic.   Can this be constrain to only the trunk ports (switches) that only has receivers?

ANY workarounds for this?   Another solution (other than PIM / CGMP) will also help.

Thanks in advance for your inputs!

syson.suy at

syson suy


Ghost v11 uses 224.77.x.x automatically for multicast address

Giuseppe Larosa
Hall of Fame Master

Hello Syson,

check if IGMP snooping is enabled for the data vlan on the core C3560, if it is disabled this could explain the flooding you are seeing

show ip igmp snooping vlan X

Hope to help


igmp snooping is enabled on the data VLAN.   multicast groups are attached to the different ports (downlink to 2960 access-layer switches).   any other ideas?

3560#show ip igmp snooping vlan 110
Global IGMP Snooping configuration:
IGMP snooping                : Enabled
IGMPv3 snooping (minimal)    : Enabled
Report suppression           : Enabled
TCN solicit query            : Disabled
TCN flood query count        : 2
Robustness variable          : 2
Last member query count      : 2
Last member query interval   : 1000

Vlan 110:
IGMP snooping                       : Enabled
IGMPv2 immediate leave              : Disabled
Multicast router learning mode      : pim-dvmrp
CGMP interoperability mode          : IGMP_CGMP
Robustness variable                 : 2
Last member query count             : 2
Last member query interval          : 1000

3560#show ip igmp snooping groups
Vlan      Group                    Type        Version     Port List
110               igmp        v1          Gi0/15, Gi0/16,
                                                           Gi0/17, Gi0/18,
110          igmp        v2          Gi0/14, Gi0/15,
                                                           Gi0/16, Gi0/17,
                                                           Gi0/18, Gi0/20,

Hi Syson,

When snooping is enabled and an mrouter is present on the vlan, then the switch should contain the multicast streams to the entries in the snooping table and the mrouter port.  The switch will *always* send all multicast packets to the mrouter port.  This cannot (and should not) be restricted.

However, from your description, it sounds like the switch is also flooding the multicast traffic to downstream switches that do not have receivers and are not an mrouter port.  Thus, the switch is 'flooding' multicast on the vlan instead of forwarding only to receivers.  There are a few things that can cause this behavior.  The most common is TCNs on the vlan.  When a switch receives a TCN it will automatically flood multicast traffic for the TCN flood query count (multiple of the IGMP query time).  I would recommend first checking if for TCNs on the vlan:

show spanning-tree detail | i occurr|from|ieee|rstp

This is will tell you the last time you received a TCN for each vlan and the interface you received the TCN from.  Note that when running PVST+, any user interface not configured with portfast will generate a TCN on the vlan when the link flaps (i.e., users coming on and offline).

Hope this helps,


Thanks for your response on TCN causing multicast flooding into other switches.   Executing the "show spann det" shows - Data vlan (110) receiving topology changes (2 changes) from the time of switch's initial boot up.  It doesn't look like the cause of our issue.  Port 15 is downlink to an access switch.   the mgmt & voice vlans also has similar span tree details.

Your understanding of my situation is correct (as you have restated it above) - "Thus, the switch is 'flooding' multicast on the vlan instead of forwarding only to (those switches with) receivers." <<< our issue.

We left spanning-tree enabled for loop detection between access switches.   I'll read more on spanning-tree TCN & how it'll cause multicast flooding.

3560#show spanning-tree detail | in occurr|ieee
VLAN0110 is executing the ieee compatible Spanning Tree protocol
  Number of topology changes 2 last change occurred 1w3d ago
          from GigabitEthernet0/15

Port 15 (GigabitEthernet0/15) of VLAN0110 is designated forwarding
   Port path cost 4, Port priority 128, Port Identifier 128.15.
   Designated root has priority 24686, address 0021.55b1.7500
   Designated bridge has priority 24686, address 0021.55b1.7500
   Designated port id is 128.15, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   Loop guard is enabled by default on the port
   BPDU: sent 468161, received 1


You mentioned that ... "The switch will *always* send all multicast packets to the mrouter port.  This cannot (and should not) be restricted."   All cascaded switches has the 3560E as the mrouter.   Is this the reason why the mrouter send all multicast packets down to all the access switches?   You spoke about sending multicast TO the mrouter;   I'm aluding to multicast FROM the mrouter to access switches.  Maybe this is the cause of all down-leg switches seeing multicast traffic.    Cisco TAC is still open "customer pending" and due for a traffic capture session which I have a hard time scheduling with my FS team.

Any other way of doing this multicast design more efficiently?

My issue is that when desktop management team is multicasting (Ghosting) at 100Mbps rate on a site, the whole site suffers because the access switches' uplinks are saturated with these unwanted multicast traffic between mrouter & all access switches.

Hey, thanks again for your reply.


Hi Syson,

Yes, a switch will always forward multicast traffic on its mrouter port.  The reverse is *not* true.  An upstream switch acting as an mrouter port to a downstream switch will not forward the multicast traffic "down".  The purpose of the mrouter port is to ensure that the multcast router on the vlan receives all multicast traffic.  Therefore, all switches learn where a "multicast router" is via IGMP and PIM messages and program this port as a "multicast router" port.

Are you running PIM on the 3560E in the vlan that you are performing 'ghosting'?  When you are seeing the flooding issue, do you see entries in the IGMP snooping table of the 3560E via "show ip igmp snooping groups" that correspond to the ghosting stream?  Does the 3560E know itself or some other router on the vlan as the mrouter?

Check these while the flooding is occurring:

- "show ip igmp snooping groups"

- "show ip igmp mrouter"

- "show platform ip igmp snooping flood"

You should see "local" as "disabled" which means that the L2 flooding of multicast traffic on the vlan is disabled.

Also, if possible, I would recommend setting the TTL of the ghosting to a higher number (such as 16) as a test.  I believe there was caveat with 3560/3750 running PIM such that if it receives a multicast packet with TTL of 1 and an empty snooping table it floods the packet on the vlan.