IP Multicast Hardware Lookup Modes

Extreme platforms support various hardware forwarding lookup modes by using a combination of L3 hash table and L2 (FDB) table. Refer to Multicast Table Management for details on these tables. The scalability limits vary based on the lookup mode used.

Configuration Options

Configuration options allow you to choose the hardware forwarding lookup mode for multicast forwarding. Here is a list of options:
  • source-group-vlan -- Uses L3 hash table with S,G,V lookup. This is the default mode for all platforms.
  • group-vlan -- Uses L3 hash table with *,G,V lookup.
  • mac-vlan -- Uses L2 table with DMAC, VLAN lookup.
  • mixed-mode -- Uses both L2 and L3 tables for multicast. In this mode, the following logic is applied on installing the cache entries in the hardware:
    • Multicast cache entries requiring forwarding across VLANs would be installed in the L3 IP multicast table. This includes PIM, MVR, and PVLAN cache entries.
    • Multicast cache entries requiring L2 forwarding within a VLAN are installed in the L2 table. This includes entries corresponding to IGMP Snooping, PIM snooping, and MLD snooping.
    • Any IPv4/v6 reserved multicast addresses (for example, 224.0.0.x or IPv6 equivalent) are installed in the L3 IP multicast table as needed. These reserved addresses map to the following multicast MAC addresses: 01:00:5e:00:00:xx, 33:33:00:00:00:xx, 33:33:00:00:01:xx, or 33:33:ff:xx:xx:xx.


    Any change in the lookup key configuration causes all cache entries to be cleared, and traffic is temorarily dropped until the system re-learns the multicast caches and associated subscriptions.


    mac-vlan mode helps increase scaling. This mode is supported on all platforms.


    mac-vlan and mixed-mode are not supported prior to ExtremeXOS 15.3.1.
The ExtremeXOS multicast process continues to maintain the cache entries as "S,G,V", and interacts with HAL the same way as today. ExtremeXOS hardware abstraction layer (HAL) applies the logic explained above and installs the cache entries in the appropriate hardware table. If the cache entry needs to be installed in the L2 multicast table, HAL derives the MAC address based on the standard logic and installs the MAC entry in the L2 table.

The IP multicast address to MAC address mapping is not validated for the received/forwarded multicast packets in ExtremeXOS to date. If the lookup mode is configured either as "mac-vlan" or "mixed-mode", the multicast kernel module is modified to validate this mapping and, if a packet does not use the standard mapping, the packet is dropped.

IPMC Compression

In order to increase the scaling of multicast entries, ExtremeXOS implements a feature called IPMC compression which allows multiple <S,G,V> (or <*,G,V>) IP multicast FDB entries to utilize the same IP multicast group table entry when the associated egress port lists are the same. The base IP multicast compression implementation will be reused for achieving L2 multicast entry reuse. In this case, multiple <MAC,VLAN> multicast FDB entries can use a single L2MC index if the egress port lists of the cache entries are the same.

Interactions with Static FDBs

ExtremeXOS allows you to create FDB entries for multicast MAC address using:

create fdb mac_addr {vlan} vlan_name ports port_list

These entries also get installed in the L2 table and use the L2MC table for hardware forwarding. If there is a dynamic <MAC,VLAN> entry from MCMGR and a static entry from FDB manager, the static entry takes precedence and the dynamic entry would get deleted in hardware. Compression of L2MC indices is not supported on these types of entries. Each newly created static multicast FDB will cause the allocation of a new L2MC index.

Interactions with Dynamic FDBs

When IP multicast forwarding entries are utilizing the L2 MAC table, the multicast entries are installed as static in the hardware L2 table to avoid undesirable interactions with L2 protocol or user administered FDB flushing. These multicast L2 entries also take precedence over dynamic unicast L2 MAC entries. If there is a hash bucket collision upon inserting an L2 multicast entry, it will replace another dynamic unicast L2 entry if one exists in the same hash bucket.

Virtual Router Support

Current IPMC cache hardware entries stored as <S,G,V> additionally include the VRID associated with the ingress virtual router. In this feature, <MAC, VLAN> cache entries are stored in the L2 table which does not additionally include the VRID. However, user VRs are still supported since the VLAN portion of the lookup key is unique across all VRs.

IPMC Cache Rate Limiting

Based on the number of cache entries supported on each platform, there is a software cache limiting implementation present in ExtremeXOS multicast. The HAL module informs MCMGR about the supported limit, MCMGR creates cache entries up to MAX supported limit, and the remaining traffic is dropped in software.

Flood to VLAN Filters for mDNS, LLMNR, and UPnP protocols

Version 32.2 introduces support for flood to VLAN Filters for mDNS, LLMNR, and UPnP protocols. This feature enables you to create filters that forward to VLAN for these three protocol packets on both standalone switches and stacks. When flood to VLAN is enabled, an ACL filter is installed, and one ACL entry is consumed for each of the three protocols. When in learn mode, no ACL filters are installed, and no ACL resources are consumed.

Supported Platforms

This feature is implemented on all platforms.


The following limitations exist for the L2MC table feature: