Info:Kern.IPv4Adj.Info Table full

Userlevel 6
Hello, all!

Customer has messages in logs:
07/06/2016 11:49:49.69 [i] vrId 2 adj 0x5F430C4F Add Retry failed. (Table full) flags 0
07/06/2016 11:49:37.68 [i] vrId 2 adj 0x5F430C13 Add Retry failed. (Table full) flags 200

What table is full?
In what direction I have to look?

Thank you!

5 replies

Userlevel 3
Hi Alexandr,

Below is a link to an article that has a similar message. Basically, the message indicates the switch was not able to add the entries mentioned in hex into the ARP table as it was full. Looks like there were two entries that were not added into the hardware table.

The traffic for those addresses will be forwarded by the CPU (instead of via hardware lookup and ASIC forwarding) so the packets will reach their destination, but there may be some slight increase in latency due to the software (CPU forwarding).

Hope this helps.
Userlevel 6
Hello, Tony!

First of all - thank you for quick reply!

Output from this switch:
# sh iproute reserved-entries statistics
|-----In HW Route Table-----| |--In HW L3 Hash Table--|
# Used Routes # IPv4 Hosts IPv4 IPv4 IPv6 IPv4
Slot Type IPv4 IPv6 Local Remote Local Rem. Local MCast
---- --------------- ------- ------ ------ ------ ----- ----- ----- -----
1 X670-48x 14825 40> - - 339 0 0 2969

Summit X670 can have 6K ARP records in it's table, but we can see that this HW table isn't full.

Thank you!
Userlevel 6
Also in my case there is Information message.
In you example there is Warning message.

Thank you!
Userlevel 3

As you mentioned, it looks like the table is not full. As mentioned in the article, this is most likely a temporary hardware / software table sync issue. If the messages were only seen this one time, I would not worry about it. If the messages continue to be seen you would want to look into it further to see if the cause may be due to an EXOS code issue. At that point, if you have a support contract with Extreme, opening a case with GTAC would be advised for further assistance.

Userlevel 6
Alexandr, I agree with what Tony has said. We have dealt with these messages for at least 3 or 4 years. Only happens where you have a lot of vlans /vmans and the users are either true Mcast for IPTV or video/ lan leaking UPNP Mcast traffic into core/ lots of routers talking OSPF/ EIGRP/ ect. We spent a good 3 or 4 months with GTAC to only determine it was indeed the hardware and software tables not being in sync. As a rule we disable IGMP snooping on all core or aggregation switches so we have assurances Mcast will be forwarded correctly. Mcast table size has always been a concern and a problem we have had to deal with. To many people only associate Mcast with IPTV and forget about routing protocols are 100 % dependent on healthy Mcast in your system. Good luck