topic RE: x440-24p - IPMC Group Table Entries - full in ExtremeSwitching (EXOS/Switch Engine)

x440-24p - IPMC Group Table Entries - full

Michal_Rz — Fri, 30 Dec 2016 16:55:00 GMT

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?

RE: x440-24p - IPMC Group Table Entries - full

OscarK — Fri, 30 Dec 2016 17:00:00 GMT

Probably this multicast address, 239.255.255.250.
https://gtacknowledge.extremenetworks.com/articles/Q_A/What-is-the-239-255-255-250-traffic-I-see-man...

The X440 does not have much space for multicast entries, if you dont need this IP multicast to be forwarded you can block it using an ACL.

RE: x440-24p - IPMC Group Table Entries - full

Michal_Rz — Fri, 30 Dec 2016 17:07:00 GMT

I have ACL like that on that switch. But action is deny-cpu not simple deny. Will try to block it.

entry deny_LLMNR {
if match all {
ethernet-destination-address 01:00:5e:00:00:fc;
} then {
deny-cpu;
count LLMNR-deny;
}
}
entry deny_mDNS {
if match all {
ethernet-destination-address 01:00:5e:00:00:fb;
} then {
deny-cpu;
count mDNS-deny;
}
}

RE: x440-24p - IPMC Group Table Entries - full

Michal_Rz — Fri, 30 Dec 2016 17:21:00 GMT

Changed deny-cpu to deny, next refresh policy and next step was clear ipmc fdb group 239.255.255.250 and switch rebooted itself.

At the moment its running on 16.2.1.6 (it was installed previously but not rebooted)

And shows
debug hal show ipv4Mc

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

vrId 2 G=239.2.0.252 S=255.255.255.255 Vid 391 : (HW IPMC 3 l3hash 0 hit 0)
vrId 2 G=239.2.0.252 S=xxx.xxx.xxx.xxx (public IP) Vid 391 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 391
-> 1
vrId 2 G=239.255.255.250 S=255.255.255.255 Vid 391 : (HW IPMC 3 l3hash 0 hit 0)
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=255.255.255.255 Vid 362 : (HW IPMC 2 l3hash 0 hit 0)
vrId 2 G=239.255.255.250 S=xxx.xxx.xxx.xxx (public IP) Vid 362 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 362
-> 1
vrId 2 G=239.255.255.250 S=xxx.xxx.xxx.xxx (public IP) Vid 391 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 391
-> 1
vrId 2 G=239.255.255.250 S=10.160.38.224 Vid 394 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 394
-> 1
sh access-list counter
Policy Name Vlan Name Port Direction
Counter Name Packet Count Byte Count
==================================================================
block-multicast * * ingress
LLMNR-deny 0
mDNS-deny 30
sh conf | i block
configure access-list block-multicast any ingress

Gonna do some more testing.

RE: x440-24p - IPMC Group Table Entries - full

Alexandr_P — Fri, 30 Dec 2016 17:22:00 GMT

Hello!

You have to understand that DENY and DENY-CPU - it's different actions.
deny-cpu—Prevents packets that are copied or switched to the CPU from reaching the CPU. The data-plane forwarding of these packets is unaffected.

Thank you!

RE: x440-24p - IPMC Group Table Entries - full

Michal_Rz — Fri, 30 Dec 2016 17:22:00 GMT

I know that. Its not working very good tho.

RE: x440-24p - IPMC Group Table Entries - full

Jarek — Fri, 30 Dec 2016 17:22:00 GMT

Michał

if you don't need mcast traffic on specific port, you can block it at ingress:
configure ports 1 rate-limit flood multicast 0

--
Jarek

RE: x440-24p - IPMC Group Table Entries - full

Bill_Stritzinge — Fri, 30 Dec 2016 19:26:00 GMT

Michal,

The easiest way to solve this is to set the following:
"configure igmp snooping forwarding-mode group-vlan"

- - -> reduces igmp entries – by default it was source,group,vlan – which will give you more IPMC entries

This is non-evasive and should solve the problem.

Bill

RE: x440-24p - IPMC Group Table Entries - full

OscarK — Fri, 30 Dec 2016 19:26:00 GMT

Hello Bill, this switch is already in group-vlan mode, you can see that in show forwarding config where it is shown as (*,groupIP,vlanID).

RE: x440-24p - IPMC Group Table Entries - full

Michal_Rz — Fri, 30 Dec 2016 19:26:00 GMT

Thats right, changed that some time ago.

RE: x440-24p - IPMC Group Table Entries - full

Michal_Rz — Fri, 30 Dec 2016 19:58:00 GMT

FYI I have disabled acl for tests. Also switch rebooted second time after test command: clear ipmc fdb group 239.255.255.250. Dont know why.

By the way my SIEM told me that I have loged this issue 3200 times in last year on about 30 switches, 900times on this one Im talking about.

And it shows right now that:
debug hal show ipv4Mc

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

vrId 2 G=224.0.0.251 S=255.255.255.255 Vid 392 : (HW IPMC 2 l3hash 0 hit 0)
vrId 2 G=224.0.0.251 S=255.255.255.255 Vid 362 : (HW IPMC 1 l3hash 0 hit 0)
vrId 2 G=224.0.0.251 S=xxx.xxx.xxx.xxx(public IP) Vid 362 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 362
-> 3 4 5 6 7 8 9 10 11 12
13 14 15 16 17 18 19 20 1
vrId 2 G=224.0.0.251 S=10.160.3.112 Vid 392 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 392
-> 3 4 5 6 7 8 9 10 11 12
13 14 15 16 17 18 19 20 1
vrId 2 G=239.255.255.250 S=255.255.255.255 Vid 394 : (HW IPMC 3 l3hash 0 hit 0)
vrId 2 G=239.255.255.250 S=10.160.39.15 Vid 394 : (HW IPMC -1 l3hash 0 hit 0)
-> Vid 394
-> 1
But today its lazy day, so almost no one are online.

Happy new year 🙂

RE: x440-24p - IPMC Group Table Entries - full

Bill_Stritzinge — Fri, 30 Dec 2016 20:08:00 GMT

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

RE: x440-24p - IPMC Group Table Entries - full

Jeremy_Gibbs — Fri, 30 Dec 2016 23:54:00 GMT

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.

RE: x440-24p - IPMC Group Table Entries - full

Jeremy_Gibbs — Fri, 30 Dec 2016 23:59:00 GMT

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

RE: x440-24p - IPMC Group Table Entries - full

Stephane_Grosj1 — Sat, 31 Dec 2016 19:39:00 GMT

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.