Header Only - DO NOT REMOVE - Extreme Networks

error ipv4 multicast entry


Userlevel 1
I open a GTAC case, I just put in this x440 stack (today first day of production) and I got the ipv4 multicast entry error any suggestions?

28 replies

Userlevel 5
The following GTAC knowledge article should fix your issues:

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-F...

Bill

Admin edit: Fixed link
Userlevel 1
Bill Stritzinger wrote:

The following GTAC knowledge article should fix your issues:

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-F...

Bill

Admin edit: Fixed link

Thanks for your response Bill but the article is not available 😞

The article referenced is currently unavailable
Bill Stritzinger wrote:

The following GTAC knowledge article should fix your issues:

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-F...

Bill

Admin edit: Fixed link

440s have very small tables and you are probably exceeding the limit. Can you post a snip of the log messages?
Userlevel 1
Bill Stritzinger wrote:

The following GTAC knowledge article should fix your issues:

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-F...

Bill

Admin edit: Fixed link

12/28/2015 11:04:36.01 Slot-1: IPv4 multicast entry not added. Hardware Group Table full.
12/28/2015 10:04:15.69 Slot-1: IPv4 multicast entry
not added. Hardware Group Table full.
Bill Stritzinger wrote:

The following GTAC knowledge article should fix your issues:

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-F...

Bill

Admin edit: Fixed link

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-Full is the actual link.

Admin edit: Fixed link
Bill Stritzinger wrote:

The following GTAC knowledge article should fix your issues:

https://gtacknowledge.extremenetworks.com/articles/How_To/Multicast-Entry-not-Added-Hardware-Table-F...

Bill

Admin edit: Fixed link

How does ... command change the amount of multicast entries? I didn't understand the command well!
Userlevel 5
Sorry... Here is the full article:

Procedure:

Option conserves usage of the hardware Layer 3 multicast forwarding table:

configure igmp snooping filters per-vlan

(to set it back to default set it to per-port)

After changing the IGMP snooping filters from per-port (default) to per-vlan you can disable IGMP snooping on VLAN's where IGMP snooping is not required:

disable igmp snooping vlan

Stores multicast entries in the format (* AnySourceIP, GroupIP, VlanId), which is also referred to as (*, G):

configure igmp snooping forwarding-mode group-vlan

(to set it back to default configure it to source-group-vlan)

Routes with longer network masks might not be necessary if they are a subset of other routes with shorter network masks using the same gateway(s). When IP route compression is enabled, these unnecessary routes are not provided to the Forwarding information Base (FIB).
enable iproute compression

Additional notes:

Beginning in EXOS 15.4, the command configure igmp snooping forwarding-mode group-vlan was replaced with configure forwarding ipmc lookup-key group-vlan.

Hope it helps!

Bill
This does work very well. I have not seen the error messages on any of our stacks after making the changes Bill suggests.
Userlevel 5
Either of the last commands here will fix your issue:

If pre 15.4 - "configure igmp snooping forwarding-mode group-vlan" and if 15.4 or later "configure forwarding ipmc lookup-key group-vlan"

Bill
Userlevel 1
Bill Stritzinger wrote:

Either of the last commands here will fix your issue:

If pre 15.4 - "configure igmp snooping forwarding-mode group-vlan" and if 15.4 or later "configure forwarding ipmc lookup-key group-vlan"

Bill

Thanks for your quick response, I enter the second one, (ver 15.7.1.4) and I'll monitor to see how it responds

Thanks
Userlevel 1
Bill Stritzinger wrote:

Either of the last commands here will fix your issue:

If pre 15.4 - "configure igmp snooping forwarding-mode group-vlan" and if 15.4 or later "configure forwarding ipmc lookup-key group-vlan"

Bill

Bill, so far, after applying the instruction, no log error since yesterday 12:04pm, thanks
Userlevel 7
To add a bit to it: EXOS stores, by default, multicast entries in HW as (S,G,V) in L3 Table resources, even if operating in L2. Your issue was typical of the x440 L3 scale, which is limited. What Bill gave you was a way to better optimize the L3 Multicast resources. IF you don't need L3, but only L2, and IF you still encounter your issue in the future, you may want to try switching to L2 learning for multicast. Scale will be way higher.

configure forwarding ipmc lookup-key mac-vlan

other options are: group-vlan (what Bill gave you), source-group-vlan (default) and mixed-mode

mixed-mode may be interesting if you have a mix of L3 and L2.
Userlevel 1
Grosjean, Stephane wrote:

To add a bit to it: EXOS stores, by default, multicast entries in HW as (S,G,V) in L3 Table resources, even if operating in L2. Your issue was typical of the x440 L3 scale, which is limited. What Bill gave you was a way to better optimize the L3 Multicast resources. IF you don't need L3, but only L2, and IF you still encounter your issue in the future, you may want to try switching to L2 learning for multicast. Scale will be way higher.

configure forwarding ipmc lookup-key mac-vlan

other options are: group-vlan (what Bill gave you), source-group-vlan (default) and mixed-mode

mixed-mode may be interesting if you have a mix of L3 and L2.

Thanks for the information
Userlevel 4
A consolidated KB article is available at
https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-prevent-IPv4-multicast-entry-not-added-Hardware-L3-table-full-log-messages.
Sort of related to this,

I am working on new configs for a network refresh for one of our customers.
Code version: 15.7.2.9
Our current default multicast config for mixed networks (440/460) is:

enable igmp snooping forward-mcrouter-only vr VR-Default
configure igmp snooping filters per-vlan
configure forwarding ipmc lookup-key group-vlan

The customer has distributed routing from the the building MDF closets I started working on some of the IDFs and the above config worked fine.

When I got to the MDF I found the current gear has:

enable ipmcforwarding vlan "ADDAMSD100"
enable ipmcforwarding vlan "RO_AES_HS_link"
enable ipmcforwarding vlan "RO_AES_SVR"
enable ipmcforwarding vlan "RO_AES_USR"

This does not work with in conjunction with our current default config. So I am trying to determine how to proceed. The MDF stacks are all 460s so they should be fine with the modifications to the table entries.
My concern is will things work with modified entries in the IDF and default entries in the MDF? Or should we use the default multicast table entry method everywhere and just deal with the error messages in the IDFs?

Thanks,
Userlevel 1
The error appear again,

Slot-1 MDF-U-st.1 # sh log sev war
01/05/2016 14:14:07.07 Slot-1: IPv4 multicast entry not added. Hardware Group Table full.
01/05/2016 08:17:16.70 Slot-1: Previous message repeated 3 additional times in the last 9511 second(s)

maybe last resort will be to put only L2, will this impact current traffic? do I need a maintenance window?
Userlevel 7
Karina Del Moral wrote:

The error appear again,

Slot-1 MDF-U-st.1 # sh log sev war
01/05/2016 14:14:07.07 Slot-1: IPv4 multicast entry not added. Hardware Group Table full.
01/05/2016 08:17:16.70 Slot-1: Previous message repeated 3 additional times in the last 9511 second(s)

maybe last resort will be to put only L2, will this impact current traffic? do I need a maintenance window?

Hi,

do you have any requirement or protocol needing L3 IPMC? This include PIM, MVR IGMPv3 and Private VLAN. If so, you'll need to turn on mixed-mode instead of mac-vlan as they cannot work in L2 mode. You should have a message saying that from the CLI.

The User Guide is a helpful resource for the details.
Userlevel 5
Did the switch reboot and possibly without the configuration being saved? Assuming that is the case I would to refer to Stephane's post above and put it into L2 only, most likely based on your config as you have shared it most likely wont cause you any issue.
That command would be: "configure forwarding ipmc lookup-key mac-vlan"
Userlevel 5
Bill Stritzinger wrote:

Did the switch reboot and possibly without the configuration being saved? Assuming that is the case I would to refer to Stephane's post above and put it into L2 only, most likely based on your config as you have shared it most likely wont cause you any issue.
That command would be: "configure forwarding ipmc lookup-key mac-vlan"

You can check to make sure that the configuration is there by doing the command, "show config mcmgr" - It should show you the configuration that you are using assuming it is there.
Userlevel 1
Bill Stritzinger wrote:

Did the switch reboot and possibly without the configuration being saved? Assuming that is the case I would to refer to Stephane's post above and put it into L2 only, most likely based on your config as you have shared it most likely wont cause you any issue.
That command would be: "configure forwarding ipmc lookup-key mac-vlan"

Thanks.. No reboot I check

Slot-1 MDF-U-st.2 # sh config "mcmgr"
#
# Module mcmgr configuration.
#
configure igmp snooping filters per-vlan
configure forwarding ipmc lookup-key group-vlan
Userlevel 5
Bill Stritzinger wrote:

Did the switch reboot and possibly without the configuration being saved? Assuming that is the case I would to refer to Stephane's post above and put it into L2 only, most likely based on your config as you have shared it most likely wont cause you any issue.
That command would be: "configure forwarding ipmc lookup-key mac-vlan"

I would make the change as suggested to "configure forwarding ipmc lookup-key mac-vlan" and let it roll...

Couple of other commands to see the mcast cache...

"show mcast cache summary"
or
"show mcast cache" (will show you all)
Userlevel 7
Bill Stritzinger wrote:

Did the switch reboot and possibly without the configuration being saved? Assuming that is the case I would to refer to Stephane's post above and put it into L2 only, most likely based on your config as you have shared it most likely wont cause you any issue.
That command would be: "configure forwarding ipmc lookup-key mac-vlan"

A command that is useful to check the current HW settings of a given platform (including ipmc lookup-key) is:

show forwarding config
Userlevel 1
Thanks all for your feedback...

I have also another group of x440 switches, they are not in stack, are daisy chain, but I don't see that error on them... they are running an oldest xos version, 15.2.1.5 the stack 15.7.1.4.. so the warning error is due to the stack configuration? on the daisy chain I haven't apply any mcast configuration and the cache shows 24 entries on the stack around 46

Thanks
Userlevel 1
And by the way... The Hub is the Best support group ever! 🙂
Userlevel 1
Error still showing, not as much, I applied same rules in the MDF-u Stack of summit x440 and on the summit x440-24x, in the stack still showing, the only difference I see on the forwarding configuration is the hash recursion level

Slot-1 MDF-U-st.2 # sh forwarding configuration
L2 and L3 Forwarding table hash algorithm:
Configured hash algorithm: crc32
Current hash algorithm: crc32

L3 Dual-Hash configuration: (Applies to X460, X480, X650 and X670 only)
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: off
Local Network Forwarding: slow-path
Lookup-Key: (*,GroupIP,VlanId)

External lookup tables:
Configured Setting: l2-and-l3
Current Setting: l2-and-l3

Internal lookup tables:
Configured Setting: l2-and-l3
Current Setting: l2-and-l3

Switch Settings:
Switching mode: store-and-forward

L2 Protocol:
Fast convergence: on

Fabric Flow Control:
Fabric Flow Control: auto
Slot-1 MDF-U-st.3 #

And this is the other switch (no error since yesterday after applied instructions)

mdf-24x-uplink.1 # sh 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: 1

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
mdf-24x-uplink.2 #

and the mcmgr config information

Slot-1 MDF-U-st.3 # sh config "mcmgr"#
# Module mcmgr configuration.
#
configure igmp snooping filters per-vlan
configure forwarding ipmc lookup-key group-vlan
Slot-1 MDF-U-st.4 #

device no longer showing the error

mdf-24x-uplink.2 # sh confi "mcmgr"#
# Module mcmgr configuration.
#
configure igmp snooping filters per-vlan
configure forwarding ipmc lookup-key group-vlan
mdf-24x-uplink.3 #

Reply