Q in Q multicast

dgahm · ‎08-20-2008

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 also posted this in Service Providers/Metro.

Giuseppe Larosa · ‎08-31-2008

Hello David,

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:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snooppim.html

PIM snooping and IGMP snooping can be enabled at the same time in a VLAN. Either RGMP or PIM snooping can be enabled in a VLAN but not both.

â€¢Any non-PIMv2 multicast router will receive all traffic.

â€¢You can enable or disable PIM snooping on a per-VLAN basis.

It looks like that for PIM snooping an SVI must be configured for your customer vlan:

Router# interface vlan 10

Router(config-if)# ip pim snooping

Router(config-if)# end

Router# show ip pim snooping vlan 10

3 neighbors (0 DR priority incapable, 0 Bi-dir incapable)

6 mroutes, 3 mac entries

DR is 10.10.10.4

RP DF Set

Router#

However, the question is : can traffic received on tunnel port be inspected at L3 by RGMP or PIM snooping ?

in the same IOS release

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dot1qtnl.html

Restrictions:

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.

Hope to help

Giuseppe

Giuseppe Larosa · ‎08-31-2008

Hello David,

only one later thought:

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.

Hope to help

Giuseppe

dgahm · ‎09-02-2008

Giuseppe,

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.

Regards, Dave

Giuseppe Larosa · ‎09-02-2008

Hello Dave,

thanks for the good remarks.

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.

Best Regards

Giuseppe