10-22-2010 09:50 AM - edited 03-06-2019 01:41 PM
Hi All,
Multicast on 802.1Q Trunks issue;
Scenario-
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.
Issue-
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 tdsb.on.ca
10-22-2010 11:09 AM
Notes:
Ghost v11 uses 224.77.x.x automatically for multicast address
10-22-2010 01:50 PM
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
Giuseppe
10-25-2010 05:16 AM
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 224.0.1.60 igmp v1 Gi0/15, Gi0/16,
Gi0/17, Gi0/18,
Gi0/21
110 239.255.255.250 igmp v2 Gi0/14, Gi0/15,
Gi0/16, Gi0/17,
Gi0/18, Gi0/20,
Gi0/21
10-25-2010 07:57 PM
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,
-Andy
10-26-2010 06:13 AM
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
12-09-2010 06:10 AM
Andrew,
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.
Syson
12-11-2010 06:55 AM
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.
-Andy
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide