Meru Technical Note - How are Multicast and Broadcast traffic supported by the Meru Controller and AP's ?

[Andy_G]

Description

How are Multicast and Broadcast traffic supported by the Meru Controller and AP's ?

Scope

KB ARTICLE TYPE: Design

RELATED PRODUCTS: All controllers, AP300s and AP400s

RELATED SOFTWARE VERSIONS: 5.1 and 5.2

KEYWORDS: multicast

Solution
A number of applications used by Meru customers depend on multicast or broadcast traffic to work. Application examples are NetSchool, digital picture frames,airplay and many others. The purpose of this section is to document what is supported and what is not supported.

What is supported:

    
• Multicast traffic from wired -> wireless. This means that a multicast packet that reaches the Ethernet interface of the controller will be forwarded to all APs and out over the air.
    
• Multicast traffic from wireless->wired and wireless->wireless. This means a multicast packet sent from a wireless station will be forwarded to the wired side of the controller and so all wired-side devices will see the multicast packet. That same multicast packet will be forwarded to all APs and so all wireless stations using the same ESSID service as the sender will see the multicast packet.
    
• Broadcast from wired->wireless. This means that a broadcast packet that reaches the Ethernet interface of the controller will be forwarded to all APs and out over the air.
    
• Broadcast from wireless->wired and wireless -> wireless (the latter supported starting in 3.6.1). This means a broadcast packet sent from a wireless station will be forwarded to the wired side of the controller and so all wired-side devices will see the broadcast packet. That same broadcast packet will be forwarded to all APs and sent to all wireless clients using the same ESSID service as the broadcast sender will see the broadcast packet.

In each of the supported cases, the configuration requirement is that 1) "multicast-enable" be turned on for the ESSID profile and 2) The VLAN to which that ESSID profile is associated may not have any other ESSID profiles associated to it (This is not a requirement in SD version 5.1 and above). Note that when an ESSID is not configured to use a VLAN, it is considered to be associated to the "default" VLAN.

Behaviour prior to 5.1:
For example, suppose you have a customer that is using two ESSID profiles and no VLANs. The customer desires to use multicast on one of the ESSID profiles and so turns on "multicast enable" on the ESSID profile. The multicast traffic will be blocked by the controller because both ESSID profiles use the same VLAN, in this case the "default" VLAN. This is documented in the "Multicasting" section of ESSID configuration in the Configuration Guide.

Each of the above cases and descriptions assumes the data-plane mode is "tunneled" as the decision to forward or not forward a multicast or broadcast packet is done at the controller. If the data-plane mode is bridged, multicast and broadcast traffic that reaches the Ethernet interface of an AP is forwarded over the air (to all BSSIDs supported by the AP) regardless of configuration. Similarly, any multicast or broadcast traffic received by an AP's radio is forwarded to the wired side regardless of configuration.

IGMP snooping feature

The controller supported "IGMP snooping" started in 3.6.1. When enabled, IGMP snooping will forward only multicast traffic sent to an IGMP group to which some wireless client has subscribed. Said another way, enabling IGMP snooping will cause all Ethernet->wireless multicast traffic to be discarded initially. As wireless clients join/subscribe to an IGMP group, the controller detects the relevant IGMP group and dynamically opens a pin-hole for multicast traffic sent to that particular IGMP group to be forwarded to wireless client(s) subscribed to that IGMP group.

Some other particulars about the IGMP snooping feature in the controller:

    
• When using IGMP snooping, the controller will send one multicast stream to each AP providing service to a wireless client that has joined the IGMP group.
    
• The AP will then retransmit the stream to those wireless clients that have joined the IGMP group, converting the stream to unicast when virtual-port is enabled so it can be sent at the optimal transmission rate of each wireless client. When non-vcell is configured, the multicast is sent as L2 multicast at the lowest base rate configured on the ESSID profile.
    
• CLI command "sh igmp-snoop subscription-table" will show you what wireless clients have joined which IGMP groups.