Does IGMP snooping work with Q in Q 802.1ad(dot1q tunneling)? I have searched extensively but can't find a clear answer.
I am on the customer side, and my testing suggests that either snooping is working on the carrier side or flooding is restricted to the inner tagged VLAN originating the multicast. I set up a multicast stream on one VLAN and do not see it (based in show interface input and multicast packet counts)at other sites on different VLANs.
My concern is that multicast traffic might be flooded to all ports assigned to our service provider VLAN resulting in problems for low bandwidth ports. The service provider core is using 6509s, with 3550s or Ethernet over copper modems as CPE equipment.
We are using IP PIM sparse mode with all Q in Q VLANs set up as point to point routing links.
I understand your concern because QinQ adds an 802.1Q that is inserted after the destination MAC address so the resulting frame will still be a multicast frame.
Without QinQ you could control the multicast traffic forwarding at L3 on each poin-to-point Vlan to each remote site.
In this scenario, any L3 control action could be overriden by the L2 nature of this service: in the service provider's network it sees multicast frames sent on your customer Vlan and it should try to forward them to all ports belonging to it.
These multicast frames can then be delivered over a dot1q tunnel to a remote site that doesn't use the inner vlan-id or has not joined the group and so wasting bandwidth or worse isolating the remote site.
With IGMP snooping working on your customer Vlan-id the multicast flooding will be constrained only to the ports where IGMP reports are listened (this is if your CPEs are L2 devices).
If your CPE devices are L3 devices and multicast capable routers as I see for your note about enabling ip pim sparse mode you need another mechanism that is called RGMP: it allows a switch to sniff PIM messages on ports to build an optimized forwarding in a Vlan where routers are connected.
In new release of IOS the PIM snooping feature has been introduced:
Because tunnel traffic has the added ethertype and length field and retains the 802.1Q tag within the switch, the following restrictions exist:
-The Layer 3 packet within the Layer 2 frame cannot be identified in tunnel traffic.
-Layer 3 and higher parameters cannot be identified in tunnel traffic (for example, Layer 3 destination and source addresses).
-Because the Layer 3 addresses cannot be identified within the packet, tunnel traffic cannot be routed.
-The switch can provide only MAC-layer filtering for tunnel traffic (VLAN IDs and source and destination MAC addresses).
-The switch can provide only MAC-layer access control and QoS for tunnel traffic.
-QoS cannot detect the received CoS value in the 802.1Q 2-byte Tag Control Information field.
The most interesting aspect is that there are a lot of presentations in networkers slides or Metro Ethernet Forum that show scenarios with QinQ and EoMPLS and they declare efficient support for multicast traffic.
Are we missing something ?
If the answer is negative to avoid flooding you need to carry multicast traffic inside GRE tunnels and to remove pim from the point-to-point Vlans so that the destination MAC becomes unicast.
in Q in Q networks could be enough to provide some control of multicast flooding if tunnel ports were using some form of Vlan tags learning:
don't send out frames with an inner vlan tag never heard on port from the L2 CE.
If this is true L3 control with PIM would be enough: the frames could go to all tunnel ports with your customer-vlan tag but frames will not be sent out wasting bandwidth if that inner vlan tag is not already used on the specific tunnel port.
Thanks for the very useful information. I was not aware of the PIM snooping feature, but as you note it does not appear to work with QnQ. We are already configured for point to point routing VLANs so simply removing the tunneling will eliminate the issue without needing PIM snooping. It appears our VLAN IDs do not conflict with the service provider, so it will be an easy change for us. All we give up is the flexibility to re-configure endpoints without involving the SP.
I am also a bit perplexed at this limitation with QnQ given the increasing popularity.
I was also surprised that everyone states on slides that multicast is supported in an efficient manner with Carrier Ethernet scenarios, and when we look at the details we discover that flooding is not so well controlled.
I haven't used PIM snooping up to now only the previous RGMP.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...