x440-24p - IPMC Group Table Entries - full

[Michal_Rz]

Hello,
I have problem that apears here kinda often, but not a single one that matches mine.

In logs of X440-24p running on 16.1.3.6 i see from some time:
IPv4 multicast entry not added. Hardware Group Table full.

I have only few vlans on it, and it works as AP access switch. Nothing special.

Some commands that I think might be interesting.
debug hal show ipv4Mc

Total IPMC Cache Entries : 2(IPv4 : 2, IPv6 :0)
Total IPMC Caches with No Group Index : 1(IPv4 : 1, IPv6 :0)
L2 Mode Caches with No Group Index : 0(IPv4 : 0, IPv6 :0)
L3 Mode Caches with No Group Index : 1(IPv4 : 1, IPv6 :0)
IPMC Group Table Entries In-use : 64
IPMC Group Table Entries Max : 64
L2MC Group Table Entries In-use : 0
L2MC Group Table Entries Max : 0
IPMC Forwarding Mode : 1

vrId 2 G=239.255.255.250 S=255.255.255.255 Vid 394 : (HW IPMC -1 l3hash 0 hit 0)
vrId 2 G=239.255.255.250 S=10.160.35.30 Vid 394 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 394
-> 1

show iproute reserved-entries statistics
|-----In HW Route Table-----| |-------In HW L3 Hash Table------|
# Used Routes # IPv4 Hosts IPv4 IPv4 IPv6 IPv4 IPv6
Slot Type IPv4 IPv6 Local Remote Local Rem. Local MCast MCast
---- --------------- ------- ------ ------ ------ ----- ----- ----- ------ ------
1 X440-24p 0 0 0 0 0 0 0 0 0

show forwarding configuration

L2 and L3 Forwarding table hash algorithm:
Configured hash algorithm: crc32
Current hash algorithm: crc32
L3 Dual-Hash configuration:
Configured setting: on
Current setting: on
Dual-Hash Recursion Level: 3
Hash criteria for IP unicast traffic for L2 load sharing and ECMP route sharing
Sharing criteria: L3_L4
IP multicast:
Group Table Compression: on
Local Network Forwarding: slow-path
Lookup-Key: (*,GroupIP,VlanId)
Switch Settings:
Switching mode: store-and-forward
L2 Protocol:
Fast convergence: on
Fabric Flow Control:
Fabric Flow Control: auto

Any ideas what might fill the IPMC Group Table to the maximum? Or its not the issue?

[Stephane_Grosj1]

As Oscar said, the multicast table is rather limited on the x440 (G1). If you are not doing L3 on this switch, then change the lookup key for multicast.

By default (S,G,V) is used: it uses L3 Hash table.
I see you changed that to (*,G,V), which can help but:
1) you're still using the L3 hash table
2) it depends on your traffic type

So, the best way to scale up, if you don't do L3 Multicast (that includes PVLAN, MVR...), is to configure the lookup-key to mac-vlan.

configure forwarding ipmc lookup-key [group-vlan | source-group-vlan | mac-vlan | mixed-mode]

mac-vlan: Uses L2 Multicast FDB table with (DMAC, V) lookup. This is the default for Summit x430. This mode helps Multicast scaling on entry-level platforms where the L2 Multicast FDB table can store a significantly higher number of entries. As an example, Summit x440 can scale up to 4,000 entries in this mode compared to 192 (with Multicast compression enabled).

mixed-mode: Uses both L2 Multicast FDB and L3 Hash tables for multicast. In this mode, the following logic is applied on installing the cache entries in hardware:
- Multicast cache entries requiring to be forwarded across VLANs are installed in the L3 Hash table. This includes PIM, MVR and PVLAN cache entries.
- Multicast cache entries requiring L2 forwarding within a VLAN are installed in the L2 Multicast FDB table. This includes entries corresponding to IGMP Snooping, PIM Snooping and MLD Snooping.
- Any IPv4/IPv6 reserved multicast addresses (for example 224.0.0.x) are installed in the L3 Hash 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 temporarily dropped until the system re-learns the multicast caches and associated subscriptions.

[Jeremy_Gibbs]

Why things are appearing twice.. maybe ones for the query and ones for the response.. but technically you only need to deny the query.

[Jeremy_Gibbs]

If you are using Extreme Wireless, it is very easy to deny LLMNR with a policy right from the wireless controller. If you are doing filtering at the AP, this would work for ya too.

[Bill_Stritzinge]

Michal,

In some cases there are times when the application vs. the hardware come into play and in this situation this might be the case. You may want to think about replacing this switch with something a little more robust such as a X440-G2 or higher with more table sizes to accomoidate you application. The other thing since you say it is that this switch aggregates AP's is maybe to tunnel your wireless traffic and then turn off IGMP snooping and allow the switch where the controller is connected to handle things? It would seem you are local bridging the traffic and thus getting all of the multicast from those wireless clients on the X440.

Bill