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.
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 184.108.40.206 igmp v1 Gi0/15, Gi0/16, Gi0/17, Gi0/18, Gi0/21 110 220.127.116.11 igmp v2 Gi0/14, Gi0/15, Gi0/16, Gi0/17, Gi0/18, Gi0/20, Gi0/21
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).
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.
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...