Description
This article describes how to properly enable IGMP snooping and allow multicast in a controlled manner. Depending on the multicast design, the FortiGate may participate or not in the multicast control and user traffic.
Note:
When applying changes, delays can be expected as those changes would take from a few seconds to minutes between being propagated to start returning values. IGMP snooping requires observing IGMP control packets from clients to work properly.
Scope
FortiGate, Managed FortiSwitches.
Solution
Case 1: Multicast devices are on the same VLAN:
In this case, FortiGate has no direct participation in the multicast traffic other than setting and distributing IGMP configuration to managed FortiSwitches. The FortiSwitches will learn and forward multicast packets only to ports where IGMP traffic was observed (mRouter), when IGMP snooping is enabled. In such cases, multicast packets may not be forwarded upstream of the FortiGate.
This is an efficient way to prevent all ports from receiving the multicast traffic in a 'broadcast' manner.
If IGMP snooping is disabled on the VLAN interface level, packets are forwarded to ALL Switch ports in a broadcast manner.
This should not be a problem on small networks and topologies where the multicast UDP stream is not frequent, and it may be a desired outcome depending on the network design plan.
Note:
To confirm the 'broadcast' behavior, plug an endpoint to an interface part of the same VLAN and observe if receiving multicast UDP data packets without having sent any 'igmp join' packets. Make sure the promiscuous mode is enabled so unsolicited network packets can be pushed up into the stack and the Windows firewall is disabled.
Enabling IGMP Snooping on the VLAN is enough to prevent multicast broadcasts when the application is properly using IGMP. Go to Wifi & Switch Controller -> FortiSwitch VLANs, edit the VLAN -> network -> IGMP snooping: make sure it is toggled on.
After enabling IGMP Snooping on the VLAN, this setting will be propagated to all switches.
In the above diagram, client 01 will receive multicast 234.5.6.7 packets, but not client 02. The reason why is that the switch had observed IGMP packets on ports 03, 05, and 06, but not on the trunk between the switches.
CLI commands on the FortiGate:
diag switch-controller switch-info igmp-snooping group
CLI commands on the FortiSwitch:
get switch igmp-snooping group
Case 2: Multicast devices are on different VLANs:
In this case, multicast packets must cross layer-3 networks from vlan50 to vlan60 and one way to achieve this is to allow the traffic on the FortiGate on a firewall policy level.
Make sure Multicast Policy is enabled under System -> Feature Visibility -> Multicast policy.
Under Policy & Objects -> Multicast policy, make sure 234.5.6.7 is allowed from vlan50 to vlan60 given the transmitter or server lies on vlan50 as the source of the packet flow.
The settings above may not be sufficient, as on a switch level, the trunk between the switches and the upstream trunk to the FortiGate had never received a multicast packet, and they were not tagged as mRouter interfaces. One way to circumvent this design particularity is to enable the Fortigate as IGMP querier.
The IGMP querier is not a requirement, however, IGMP information may expire if no further IGMP packets are received before the aging-time is reached.
CLI commands on the FortiSwitch:
get switch igmp-snooping globals
CLI commands on the FortiGate:
get switch-controller igmp-snooping
Once the FortiGate is configured as an IGMP querier: Technical Tip: How to configure the FortiGate as an IGMP querier on a FortiSwitch topology, the IGMP query replies will allow the trunk interfaces to be tagged as mRouter interfaces. Multicast UDP and data packets will be subject to firewall inspection, and properly allowed.
CLI commands on the FortiGate:
diag sys mcast-session list
One important detail to be highlighted is FSW_01 - port3 is our server transmitting data on 239.5.6.7 and 239.5.6.8, and FSW_03 - port6 the client is requesting to join 239.5.6.7 and 239.5.6.8 groups. The multicast policy only allows 239.5.6.7, therefore only this group was allowed in the session details above.
Case 3: The usage of flood-unknown-multicast.
- If flood-unknown is enabled, multicast data packets will be forwarded out to all ports (except the ingress port).
- If flood-unknown is disabled, then the packet would only get forwarded out the ports tagged as mRouter interfaces.
- If none are known, the packet will be discarded by the switch.
This option should be enabled and used with caution as it may lead to multicast storms extended to all FortiSwitches. Multicast data packets without IGMP control packets are learned as 'unknown'.
Case 4: FortiSwitch default IGMP version.
Fortiswitches works by default with IGMP v2. Packets containing other IGMP versions may be discarded by the switch. One way to circumvent this scenario is to enable and set the proper IGMP version on the IGMP querier settings. Note that some Windows versions may enforce the usage of IGMPv3 where those packets may be discarded.
Another way to circumvent this scenario is to tune up the Windows IGMP version by following this Microsoft guidance:
This behavior can be confirmed by enabling the following debug on the Fortiswitch directly:
diag debug application mcast-snooping -1
diag debug enable
Output:
Received message type IGMPV3_HOST_MEMBERSHIP_REPORT port5 vlan50
mcast_add_report: querier version 2: ignore igmp v3 packet
Received message type IGMPV3_HOST_MEMBERSHIP_REPORT port5 vlan50
mcast_add_report: querier version 2: ignore igmp v3 packet
Once the IGMP version matches, the packet will be processed correctly.
Case 5: The usage of the range 224.0.0.1 - 224.0.0.254 non-routable and reserved range.
The 224.0.0.0/24 block from the multicast address space is reserved for the control plane and described on RFC 5771.
