x440-24p - IPMC Group Table Entries - full

  • 0
  • 1
  • Problem
  • Updated 2 years ago
  • Solved
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:
<Erro:HAL.IPv4Mc.GrpTblFull> 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?
Photo of Michal Rz

Michal Rz

  • 742 Points 500 badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of OscarK

OscarK, ESE

  • 7,912 Points 5k badge 2x thumb
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.
Photo of Michal Rz

Michal Rz

  • 742 Points 500 badge 2x thumb
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;
}
}
(Edited)
Photo of Michal Rz

Michal Rz

  • 742 Points 500 badge 2x thumb
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.
Photo of Alexandr P

Alexandr P, Embassador

  • 12,670 Points 10k badge 2x thumb
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!
Photo of Michal Rz

Michal Rz

  • 742 Points 500 badge 2x thumb
I know that. Its not working very good tho.
Photo of Jarek

Jarek

  • 2,398 Points 2k badge 2x thumb
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
Photo of Bill Stritzinger

Bill Stritzinger, Alum

  • 6,036 Points 5k badge 2x thumb
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

Photo of OscarK

OscarK, ESE

  • 7,912 Points 5k badge 2x thumb
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).
Photo of Michal Rz

Michal Rz

  • 742 Points 500 badge 2x thumb
Thats right, changed that some time ago.
(Edited)
Photo of Michal Rz

Michal Rz

  • 742 Points 500 badge 2x thumb
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 :)
Photo of Bill Stritzinger

Bill Stritzinger, Alum

  • 6,036 Points 5k badge 2x thumb

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

Photo of Jeremy

Jeremy, Embassador

  • 9,788 Points 5k badge 2x thumb
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.
Photo of Jeremy

Jeremy, Embassador

  • 9,788 Points 5k badge 2x thumb


Why things are appearing twice.. maybe ones for the query and ones for the response.. but technically you only need to deny the query. 
(Edited)
Photo of Grosjean, Stephane

Grosjean, Stephane, Employee

  • 13,650 Points 10k badge 2x thumb
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.