IPv4 multicast entry not added

[EtherNation_Use]

Create Date: Feb 16 2013 9:47AM

Good day!

We have few new X670-48x with 12.6.2.10.
This devices new for us, and we don't know all hints etc.

About 2 days ago we got issues from customers about multicast tv.
We found some linelogs like:
IPv4 multicast entry not added. Hardware L3 Table full. (Logged at most once per hour.)

And after
clear igmp groups
clear igmp snooping
Customers said, that tv begin work again. But not for a long time.

topology:
only L2 vlans(over 2k) with customers and one vlan with multicast for mvr at access layer.

Could you tell us, where we should begin found problem?

Running config:
#
# Module devmgr configuration.
#
configure snmp sysName "RamAGGR"
configure timezone name MSK 240
configure sys-recovery-level switch reset

#
# Module vlan configuration.
#
configure vlan default delete ports all
configure vr VR-Default delete ports 1-48
configure vr VR-Default add ports 1-48
configure vlan default delete ports 1-47
create vlan "v100"
configure vlan v100 tag 100
create vlan "v1000"
configure vlan v1000 tag 1000
create vlan "v1001"
configure vlan v1001 tag 1001
create vlan "v101"
configure vlan v101 tag 101

* * * a lot customer vlans

# IPTV vlan
create vlan "v998"
configure vlan v998 tag 998

configure vlan v1000 add ports 1, 9, 11, 13 tagged
configure vlan v1001 add ports 1-2, 13, 48 tagged
configure vlan v101 add ports 1, 11, 41 tagged
configure vlan v102 add ports 1, 9, 11, 41 tagged
* * *
configure vlan v998 add ports 1, 7, 9, 11, 13-14, 48 tagged

configure vlan v123 ipaddress 172.30.21.254 255.255.255.0

#
# Module fdb configuration.
#

#
# Module rtmgr configuration.
#
configure iproute add default 172.30.21.1

#
# Module mcmgr configuration.
#
disable igmp snooping vlan "Default"
disable igmp snooping vlan "v1001"
* * * all vlans but not v998(iptv vlan)

disable igmp vlan "v103"
disable igmp vlan "v1030"
disable igmp vlan "v1031"
* * * all vlans (with v998 too)
disable igmp vlan "v998"

# all ports without uplink
# policy file will attach
configure igmp snooping vlan "v998" ports 2 filter allowed_mcast_list
configure igmp snooping vlan "v998" ports 3 filter allowed_mcast_list
* * *
configure igmp snooping vlan "v998" ports 48 filter allowed_mcast_list

configure account admin encrypted "***********************"

configure access-list zone SYSTEM application NetLogin application-priority 3
configure access-list zone SECURITY application GenericXml application-priority 2

enable cli-config-logging

# Module lldp configuration.
#
enable lldp ports 1-48
configure lldp port 1-48 advertise port-description
configure lldp port 1-48 advertise system-name
configure lldp port 1-48 advertise system-capabilities

configure sntp-client primary * * * vr VR-Default
enable sntp-client

configure snmpv3 add community cmmnty name cmmnty user v1v2c_ro

#
# Module stp configuration.
#
configure mstp region 00049652ac67
configure stpd s0 delete vlan default ports all
disable stpd s0 auto-bind vlan default
enable stpd s0 auto-bind vlan Default

policy file allowed_mcast_list.pol:
#
# Add your group addresses between "Start" and "end"
# Do not touch the rest of the file!!!!
entry igmpFilter {
if match any {
#------------------ Start of group addresses ------------------
nlri 224.0.42.0/23;
nlri 224.0.44.0/23;
nlri 239.60.8.1/32;
#------------------- end of group addresses -------------------
} then {
permit;
}
}
entry catch_all {
if {

} then {
deny;
}
}

(from NatanFrei)

[EtherNation_Use]

Create Date: Feb 20 2013 7:22PM

Oh, and you may need to clear the IGMP entries again, or reboot the switch, to get things moving after running those commands. Some of the commands may temporarily spike CPU usage if you have a large routing table, but it will pass once all the routes are re-parsed.

You can run "show iproute reserved-entries statistics" to get an idea of how your hardware forwarding resources are being utilized. There's a table below the numbers that shows theoretical maximums for all the different switch models, including the X670; it's unlikely that you'll get that level of efficiency, but hopefully those commands will get you closer to the maximum. EDIT: formatting. (from Ansley_Barnes)

[EtherNation_Use]

Create Date: Feb 20 2013 7:13PM

While I don't have experience with this issue on the multicast side, I have seen this message presenting in a unicast-only environment and the reason is the same - the switch's hardware forwarding table isn't being used as efficiently as it could be. I'd recommend a couple of things:

run: "configure forwarding hash-recursion-level 3" - this configures the switch to hash table entries more times, resulting in more efficient usage
run: "configure forwarding external-tables l2-and-l3-and-ipmc" - this configures the switch to allocate external TCAM resources to multicast entries, which should help alleviate resource pressure
run: "configure forwarding ipmc compression group-table" - this should be on by default but just in case, this helps the switch do multicast forwarding more efficiently
run: "enable iproute compression" - this compresses the IP route table (your switch in this case may or may not be using a big one anyway) to free up TCAM resources for more multicast entries

I'm not a multicast expert so I don't know if your implementation is optimal, but nothing stands out as a glaring problem to me. These commands may help. I would also suggest moving to XOS version 12.6.3 or above, as those versions do fix some issues. Hope this helps!

EDIT: formatting. (from Ansley_Barnes)