Management Station Loses Communication To Stack After Master Unit Failure; Sntp Interface Polling; Migration Of Hosts From One Device Port To Another - Dell PowerConnect 3424 Release Notes

Management Station Loses
Communication to Stack
after Master Unit Failure.

SNTP Interface Polling

Migration of hosts from
one device port to another.
System Firmware Version 2.0.0.20
PowerConnect 3424/3448 Release Notes
When a management station is connected to a stack, which undergoes a
master failover, so that the backup unit takes over, connectivity to the
stack may be lost. The backup unit does take over the IP address of the
stack, but the management station cannot communicate with the stack
using the management IP address. This is due to the fact that the
management station associates the management station's IP address
with the MAC address of the "old" Master unit. The management station
does not update its ARP table, unless the ARP cache of the management
station is deleted.
How to rectify the situation:
To ensure connectivity to a management station following master failover,
the ARP cache on the management station must first be deleted.
If the IP interface is configured on a physical interface (port, LAG), which
goes to down, the device continues to poll until the timer expires. If the
physical interface goes up again, the unit will not continue to poll.
Consider, for example, a case of a stack in which an IP interface is
configured on a physical interface of the backup unit (or any other unit). If
that unit is severed from the stack, the master unit continues to poll until
the timer expires. After that, it ceases polling, even if the backup unit is
reconnected to the stack.
How to avoid the situation:
It is recommended to configure SNTP servers on the default VLAN.
How to rectify the situation:
If you have not configured SNTP servers as recommended, use the
Global Configuration command clock source sntp to re-activate the
server.
MAC addresses are not flushed when a port goes down. Relearning
occurs when a packet is sent from the host.
Therefore, when a host migrates from the one port to another, it is not
erased from the database, and therefore not relearned. This issue is
apparent when the user tries to ping from the device to the host, as no
traffic has been sent yet from the host to the device.
The address is learned when a packet is received from the host, or after
the address ages out from the old location.
How to avoid this situation:
When a host moves from one port to another, check viability by pinging
from the host to the device, and not vice verse.
Subject to Change Without Notice
35954
34466
36314
Page 3