Avaya Ethernet Routing Switch 4524GT - problems

[lemah]

Hi,

recently we had quite some problems with our datacenter. We are still looking for the root cause, but in the logs of the core switch (Avaya Ethernet Routing Switch 4524GT) I found some errors which I cannot explain. They seem quite strange (see beneath).

First part has something to do with the stack, which wasn't working properly I guess. Is this right?

Second part of the log is more complicated in my opinion. I see a lot of these in the log, and with various ip addresses, coming from all over the world.
Does this means I've been hacked somewhere or somehow? Are these real connections to the configuration page of this switch or is this just traffic passing through the switch?

Thanks for your reply!



S 1 00:00:00:00 1 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 2 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 3 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 4 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 5 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 6 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 7 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 8 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 9 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 10 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 11 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 12 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
S 1 00:00:00:00 13 NVR CDT_DB_CACHE failed DB-exchange, stack formation delayed
I 1 00:08:10:33 350 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:10:38 351 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:10:38 352 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:10:44 353 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:10:44 354 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:10:54 355 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:10:54 356 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:10:59 357 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:11:00 358 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:11:05 359 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:11:05 360 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:11:10 361 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:11:11 362 #1 Successful connection from IP address: 88.244.222.173
I 1 00:08:11:16 363 #1 Connection closed (lost connection), IP address: 88.244.222.173
I 1 00:08:11:16 364 #1 Successful connection from IP address: 88.244.222.173

[vultierp]

Hi,

You're right, the first logs concern stacking and that's not good

The last logs concern management access on your system.
The public IP 88.244.222.173 is coming from your network ?
More info about IP here: https://www.robtex.com/en/advisory/ip/88/244/222/173/

[tgruber]

Hi there,

The DB-exchange messages are all at Uptime zero (00:00:00:00). I suspect that those are from the past. They are bound to show up because they are classified as Serious (first column S) which are saved to non-volatile memory. You can clear those with "clear logging nv" but bear in mind that this command deletes all log messages from the device, so be sure that you fetch important messages before you do that.
The last messages are Management access connections as vultierp mentioned... If the IP 88.244.222.173 does not belong to your network, you should be concerned about securing access to the device. The "Successful connection" Messages suggest that the Connection and login were successful, so also change the passwords (and snmp communities) just to be safe.
If there are no more messages in the log, i would suggest to check Port error counters (show port-statistics) and see if there are issues there.

It would certainly also help to know what your exact problems are...