Unknown statements in syslog....

[Jimmy2]

We have a device (7i 7.8.4.1) that the connection between the LAN and WAN routers is flapping. So it appears. The Extreme shows the int going to down, the WAN rtr loses its OSPF then rejoins a few seconds later. Its not OSPF related, standard config shared on hundreds of devices with only site specifics items changed, plus its work for years. Its not physical as fiber has been tested, changed out, varying ints on both devices have been tried, SFP/GBIC have been tested/tried, all the physical items have been checked and have proven to be known good working, issue still around. I ran some debug trace commands....can someone interpret them. I tried extreme site, no good, tried extremeware decoder, its not in there...

06/23/2016 23:13:03.57 isrtask2: active ints = 18
06/23/2016 23:13:03.57 isrtask2: slot 0 port 30 ISRwd
06/23/2016 23:13:03.57 isrtask2 31
06/23/2016 23:13:03.45 isrtask2: kicking off timer with todo
06/23/2016 23:13:03.45 isrtask2 TODO: 31
06/23/2016 23:13:03.33 Filter on. Start down timer 31, tiebreak: link down
06/23/2016 23:13:03.33 slot 1, port 31 put in todo list 120 ms
06/23/2016 23:13:03.33 active ints = 18
06/23/2016 23:13:03.33 card 0 chip 7 mac 2 port 30 in macISR
06/23/2016 23:13:03.33 Check ints on mac 7
06/23/2016 23:13:03.33 Check ints on mac 6
06/23/2016 23:13:03.33 Check ints on mac 5
06/23/2016 23:13:03.33 Check ints on mac 4
06/23/2016 23:13:03.33 Check ints on mac 3
06/23/2016 23:13:03.33 Check ints on mac 2
06/23/2016 23:13:03.33 Check ints on mac 1
06/23/2016 23:13:03.33 Check ints on mac 0
06/23/2016 23:13:03.33 Card 0 MAC ISR searching nExtChan = 8
06/23/2016 23:13:03.33 isrtask2: active ints = 10
06/23/2016 23:13:03.33 isrtask2: slot 0 port 30 ISRwd
06/23/2016 23:13:03.33 isrtask2 31
06/23/2016 23:13:03.21 Filter on. Start down timer 31, link down
06/23/2016 23:13:03.21 active ints = 10
06/23/2016 23:13:03.21 card 0 chip 7 mac 2 port 30 in macISR
06/23/2016 23:13:03.21 Check ints on mac 7
06/23/2016 23:13:03.21 Check ints on mac 6
06/23/2016 23:13:03.21 Check ints on mac 5
06/23/2016 23:13:03.21 Check ints on mac 4
06/23/2016 23:13:03.21 Check ints on mac 3
06/23/2016 23:13:03.21 Check ints on mac 2
06/23/2016 23:13:03.21 Check ints on mac 1
06/23/2016 23:13:03.21 Check ints on mac 0
06/23/2016 23:13:03.21 Card 0 MAC ISR searching nExtChan = 8

The uplink goes in port 30 and all the normal show commands have not dealt us a smoking gun yet.

Side note: We also get these in the logs all the time:

06/21/2016 09:52:21.13 Route IPFDB Handle 0x1e8d8 != Passed Curr Handle 0x1e4d8
06/21/2016 09:52:21.13 Route IPFDB Handle 0x1e8d8 != Passed Curr Handle 0x1b8d8
06/20/2016 11:13:55.51 Route IPFDB Handle 0x1b4d8 != Passed Curr Handle 0x1c0d8
06/20/2016 10:27:36.66 Route IPFDB Handle 0x38d8 != Passed Curr Handle 0x1c8d8
06/20/2016 07:20:32.12 Route IPFDB Handle 0x30d8 != Passed Curr Handle 0xccd8
06/19/2016 20:06:26.79 Route IPFDB Handle 0xdcd8 != Passed Curr Handle 0x98d8
06/19/2016 13:16:41.06 Route IPFDB Handle 0x184d8 != Passed Curr Handle 0x20d8

But I personally do not know why. The switch has passed diags.

[Ron_Huygens]

Hi Jimmy, This is really old and unsupported stuff:

I will give it a try but without any guarantee:

For the first couple of messages in your question:

Check ints on mac 2
Check ints on mac 1
Check ints on mac 0
Card 1 MAC ISR searching nExtChan = 3

Decription: When cards are inserted in the switch the errors messages are written to the log.

Solution: These are all MAC level messages which gets logged when debug-trace is configured. These are all internal interrupts sent across the slots when the link goes up-down on the slots. All the messages are base 0 so, card 1 means slot 2. To resolve this issue, you would need to have the debug-trace turned off.

Clear debug-trace
Config debug-trace debug-link 0 ? Disable debug-trace for link detection

The last part:

06/21/2016 09:52:21.13 Route IPFDB Handle 0x1e8d8 != Passed Curr Handle 0x1e4d8
This message means that the IPFDB entry 0x1e4d8 will be deleted from the system, but the associated IPRoute table entry is pointing to FDB entry 0x1e8d8.
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 in the Release Notes or the outcome of the FDB hashing (4 entries in the FDB + 4 entries in the Alternate Bucket).
The solution is to reduce the FDB entries by limiting the FDB aging timer and/or the IPFDB aging timer.

That is all I can give you.