AOS Release 6.4.6.R01 Release Notes November 2013
6.4.6.R01 - New Feature/Enhancement Descriptions
Hardware/Stacking Features
Split Stack Protection (SSP)
In the case of a stack, with mac-retention enabled, splitting into disjoint sub-stacks due to the failure of one
or more stacking links / stack elements, both of the resulting stacks could end up having the same system
MAC and IP addresses. Since there is no communication between these individual stacks due to the
stacking link failure they end up communicating with the rest of the network devices using the same MAC
and IP addresses. This stack split scenario is disruptive to the network as the conflicting MAC and IP
addresses can lead to layer 2 loops and layer 3 traffic disruption.
Stack Split Protection provides the following benefits:
• Avoid network disruptions by preventing duplicate MAC and IP addresses on the network.
• The sub-stack that forms out of the stack split is able to detect that a stack split has occurred by use
of a helper switch. The helper functionaltiy is supported on an OS6850E, OS9000E, or OS6450
(with the appropriate 6.6.4 maintenance release).
• Once the stack split condition has been determined, the sub-stack will put its front-panel ports into
an operationally down state preventing traffic forwarding and avoiding loops and possible traffic
disruption. The SSP link aggregate ports will remain up.
• A trap can be sent by the active-stack indicating the stack split state. The trap indicates that the
stack split has occured and which elements are in the operationally down sub-stack.
• The entire stack will automatically recover when the sub-stacks rejoin the stack.
This feature can also be leveraged for detecting a stack split in a remote stacking topology where the stack
may consist of elements located in different physical locations such as a remote site, or multiple floors of a
building.
Note: A redundant stacking cable should be used for best traffic convergence in the event of failure.
Note: Please contact Service & Support for information on availability for OS6855 platforms.
LLDP PoE Power Negotion
With power-via-mdi configured the power for the powered device is negotiated using the optional power
via MDI TLV in the LLDPDU. The powered device can request additional power using the power via MDI
TLV. The switch will check the current PoE budget and if power is available the switch will provide the
requested power to the powered device. If power is unavailable, the switch will respond with the existing
maximum power information.
• Power negotiation is supported for Class 4 powered devices.
• The maximum power a powered device can request cannot exceed the maximum power allowed
for the PoE class in which the powered device is detected.
• If the port is manually configured with a maximum power value, the powered device cannot
receive more power than the maximum configured value.
OmniSwitch 6850E/6855/9000E------ Release 6.4.6.R01 Page 11 of 80
To Next Page
Loading...
