By default, XenServer sends multicast traffic to all guest VMs leading to unnecessary load on host devices by requiring them to process packets they have not solicited. XenServer 7.3 now allows you to enable IGMP (Internet Group Manage Protocol) snooping to better support multicast traffic. With IGMP snooping enabled, it will prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined, and improve the performance of multicast. This is especially useful for bandwidth-intensive IP multicast applications such as IPTV.
This option is disabled by default, you can enable it on a pool using either XenCenter or the xe CLI interface:
- To enable/disable IGMP snooping using XenCenter:From XenCenter menu, navigate to Pool Properties -> Network Options, choose Enable IGMP snooping (or Disable IGMP snooping to turn off the feature):
- To enable/disable IGMP snooping using xe CLI:
- SSH to pool master, get pool uuid from command xe pool-list, for example:
[root@xrtuk-11-03 ~]# xe pool-list
uuid ( RO) : 4738ddc1-c801-6a9a-b25d-b3056a7e3aa0
name-label ( RW): XS7.3Pool
name-description ( RW):
master ( RO): ea90159f-82fe-477e-a888-3eb11fbdf279
default-SR ( RW): <not in database>
- Enable/disable IGMP snooping for the pool use command:
xe pool-param-set uuid=<POOL_UUID> igmp-snooping-enabled=<true|false>
[root@xrtuk-11-03 ~]# xe pool-param-set uuid=4738ddc1-c801-6a9a-b25d-b3056a7e3aa0 igmp-snooping-enabled=true
- IGMP snooping is available only when network backend uses Open vSwitch.
- When enabling this feature on a pool, it may also be necessary to enable IGMP querier on one of the physical switches. Or else, multicast in the sub network will fallback to broadcast and may decrease XenServer performance.
- When enabling this feature on a pool running IGMP v3, VM migration or network bond failover will result in IGMP version switching to v2.
- To enable this feature with GRE network, users should set up an IGMP Querier in the GRE network or forward the IGMP query message from the physical network into the GRE network. Or else, multicast traffic in the GRE network will be blocked.
- Only IPv4 multicast is supported, not applicable to IPv6.
After enabling this feature, you can check IGMP snooping table in DOM0 (Domain Zero) with following command:
# ovs-appctl mdb/show <bridge>
[root@NKGXENRT-16 ~]# ovs-appctl mdb/show xapi1
port VLAN GROUP Age
14 0 18.104.22.168 21
8 0 22.214.171.124 16
14 0 126.96.36.199 15
1 0 querier 24
Every record contains the port of the switch (OVS), VLAN ID of the traffic, multicast group that this port solicited and the age of this record (seconds).
If the GROUP column of the record is a multicast group, this means there is a receiver listening on this port and IGMP Report message comes from the port of this record. For example, the line “14 0 188.8.131.52 15” means there is a receiver listening on port#14 for multicast group 184.108.40.206. Open VSwitch Bridge will forward the traffic of 220.127.116.11 group to all listening ports for this multicast group (for example, port#14), rather than flood. The “15” under column “Age” means this record for mapping of port#14 and group 18.104.22.168 has existed for 15 seconds. By default, the timeout interval is 300s. This means, the record will expire and be removed from this table if the listening port can’t receive new IGMP report message after 300s.
If the GROUP column of the record is “querier”, that means the IGMP Query message comes from the port of this record. A querier will send IGMP query message periodically. This message will be flooded to query who is listening on which multicast group. Once received an IGMP query message, receiver would respond IGMP report message. Consequently, the querier keeps sending IGMP query message periodically to make receivers keep responding IGMP report messages. So that switches can keep the mapping in IGMP snooping table before it expires.
The VLAN column indicates the VLAN that a receiver/querier lives. “0” means native VLAN, if you want to run multicast on some tagged VLAN, there should be records on the VLAN. Take VLAN 1209 as an example:
[root@xrtuk-11-03 ~]# ovs-appctl mdb/show xenbr0
port VLAN GROUP Age
40 0 22.214.171.124 53
45 1209 126.96.36.199 52
45 1209 188.8.131.52 52
40 0 184.108.40.206 50
40 0 220.127.116.11 50
45 1209 18.104.22.168 47
1 0 querier 55
1 1209 querier 52
1 1210 querier 19
For VLAN scenario, you should have a querier record with VLAN column value equals to the VLAN ID of the network, otherwise multicast won’t work in the VLAN network.