topic RE: Warn:IPRT> Route IPFDB Handle in ExtremeSwitching (EXOS/Switch Engine)

Warn:IPRT> Route IPFDB Handle

Jimmy2 — Mon, 28 Apr 2014 11:09:00 GMT

What are the source of these issues in the logs? I am seeing this on 7i's very intermittently. I have tried search extreme site but unable to get any results/.

04/17/2014 12:24:16.00 Route IPFDB Handle 0x1886c != Passed Curr Handle 0x2c46c04/17/2014 12:24:16.00 Route IPFDB Handle 0x1886c != Passed Curr Handle 0x2746c
04/17/2014 12:24:16.00 Route IPFDB Handle 0x2686c != Passed Curr Handle 0x2046c
04/17/2014 12:24:16.00 Route IPFDB Handle 0x2686c != Passed Curr Handle 0x1e86c
04/17/2014 12:24:16.00 Route IPFDB Handle 0x2686c != Passed Curr Handle 0x4c6c
04/17/2014 12:24:16.00 Port 13 link down
04/17/2014 12:21:03.31 Route IPFDB Handle 0x1445c != Passed Curr Handle 0x1585c
04/17/2014 12:21:02.93 Route IPFDB Handle 0x1745c != Passed Curr Handle 0x1445c
04/17/2014 12:21:02.11 Route IPFDB Handle 0x1785c != Passed Curr Handle 0x1705c

RE: Warn:IPRT> Route IPFDB Handle

Sumit_Tokle — Mon, 28 Apr 2014 20:50:00 GMT

04/17/2014 12:21:02.11 Route IPFDB Handle 0x1785c != Passed Curr Handle 0x1705c

Description of the above warning message:

The IPFDB was looking for an entry to flush. When IPFBDFlush went to find the entry, it had already aged out and this is why we see the error:
"IPRT: Route IPFDB Handle 0x1785c != Passed Curr Handle 0x1705c

This message means that the IPFDB entry 0x1705c will be deleted from the system, but the associated IPRoute table entry is pointing to FDB entry 0x1785c. The system ignores this inconsistency and keeps the IPRoute table as it is.

This message appears when the FDB is full. Full can be either the specified limit as specified in the Release Notes or the outcome of the FDB hashing (four entries in the FDB + four entries in the Alternate Bucket).

Below are the possible Solution:
===================================
1)To avoid this warning message, reduce the FDB entries by limiting the FDB aging timer and/or the IPFDB aging timer.

2)Reboot the switch
The reason to reboot the switch is that some time the entries in HW and SW tables did not sync up due to any reason, so when the switch reboot it will sync up both SW and HW entries.

RE: Warn:IPRT> Route IPFDB Handle

Jimmy2 — Mon, 28 Apr 2014 20:54:00 GMT

For solution number 2, would the same thing be achieved if we clear fdb on the devices in question?

RE: Warn:IPRT> Route IPFDB Handle

Sumit_Tokle — Mon, 28 Apr 2014 21:07:00 GMT

You can try to execute the command and see but the reboot should resolve this issue completely.
clear iparp
clear fdb

I have seen sometime the issue will get resolved after executing "enable ip-subnet-lookup" command.

When the ip-subnet-lookup feature is enabled it will only store 1 network address in the IPFDB table instead of 254 separate entries (when using a /24). This can give a big improvement in the IPFDB table space, but there are a few limitations:

- Flow Redirection is not supported in the IP Subnet Lookup.
- IP-based QOS or ACL cannot be active with IP Subnet Lookup.

You will need to reboot the switch before the ip-subnet-lookup feature becomes active.

Also wanted to mentioned that if switch is running with EW-7.4.3 then we have product defect in this software version and try to upgrade the latest software version which is available for your hardware.

After performing above step if the issue still present then I would recommend you to open case with TAC.

RE: Warn:IPRT> Route IPFDB Handle

Jimmy2 — Mon, 28 Apr 2014 23:13:00 GMT

Thank you for your time and input. How do we know the maximum allowable MACs allowed? I have looked on the 7i's data sheet but its not listed. ty

RE: Warn:IPRT> Route IPFDB Handle

Sumit_Tokle — Tue, 29 Apr 2014 14:21:00 GMT

Total number of MAC address should be mentioned in release notes.