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.
Note
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.Note
mac-vlan mode helps increase scaling. This mode is supported on all platforms.Note
mac-vlan and mixed-mode are not supported prior to ExtremeXOS 15.3.1.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.
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.
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.
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.
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.
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.
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.
This feature is implemented on all platforms.
The following limitations exist for the L2MC table feature:
All IPv4 multicast frames use multicast mac addresses starting with 01:00:5e:xx:xx:xx. The lower order 23 bits of the IP multicast address is used in the MAC address derivation. As only 23 bits of MAC addresses are available for mapping layer 3 IP multicast addresses to layer 2 MAC addresses, this mapping results in 32:1 address ambiguity.
When traffic is received for 1 out of these 32 overlapping address, then the MAC, Vlan entry is installed in hardware based on the IGMP group membership of received traffic‘s destination multicast IP address. After this installation, traffic to any of the remaining 31 addresses is delivered based on the existing cache entry and the actual receiver list of the remaining 31 addresses will not be honored.
IPv6 multicast streams use multicast MAC addresses in the form 33:33:xx:xx:xx:xx. The lower 24 bits of the IPv6 multicast address are used to derive the MAC address. So, the address ambiguity issue is also applicable to IPv6 with more severity. Given this condition, we do not recommend using overlapping IP multicast addresses with this mode.
This limitation applies to "mixed-mode", too.
As per RFC 3307, IANA assigned reserved IPv6 multicast addresses could be in the group Id range of 0x00000001 to 0x3FFFFFFF. As a result, ExtremeXOS switches flood traffic addressed to ff02::/98 to all ports of the VLAN. Since the lower 32 bits of IPv6 multicast addresses are mapped to the multicast mac address, not installing all of the addresses in this range would make it too restrictive. So, installing entries for 33:33:00:00:00:xx in hardware would be avoided, and the traffic would be software forwarded.
In addition, the following important IPv6 multicast addresses cannot be installed as hardware forwarding entries: