- Integrated Systems
- About Us
- Integrated Systems
- About Us
07-10-2012 09:43 AM
Reset loop-protect question for Virtual Connect
Question on Network Loop Protection from Peter:
Has anybody done this yet and can tell me if there is any disruption to the network on any other server in the enclosure ?
Page 88 and 89 from the manual says you need to do it when a bay has a network loop detected … but doesn’t tell me if it needs downtime for the other servers in the enclosure or not ?
Network loop protection
To avoid network loops, Virtual Connect first verifies that only one active uplink exists per network from the
Virtual Connect domain to the external Ethernet switching environment. Second, Virtual Connect makes sure
that no network loops are created by the stacking links between Virtual Connect modules.
• One active link—A VC uplink set can include multiple uplink ports. To prevent a loop with broadcast
traffic coming in one uplink and going out another, only one uplink or uplink LAG is active at a time. The
uplink or LAG with the greatest bandwidth should be selected as the active uplink. If the active uplink
loses the link, then the next best uplink is made active.
• No loops through stacking links—If multiple VC-Enet modules are used, they are interconnected using
stacking links, which might appear as an opportunity for loops within the VC environment. For each
individual network in the Virtual Connect environment, VC blocks certain stacking links to ensure that
each network has a loop-free topology.
Enhanced network loop protection detects loops on downlink ports, which can be a Flex-10 logical port or
physical port. The feature applies to Flex-10 logical function if the Flex-10 port is operating under the control
of DCC protocol. If DCC is not available, the feature applies to a physical downlink port.
Enhanced network loop protection uses two methods to detect loops:
• It periodically injects a special probe frame into the VC domain and monitors downlink ports for the
looped back probe frame. If this special probe frame is detected on downlink ports, the port is
considered to cause the loop condition.
• It monitors and intercepts common loop detection frames used in other switches. In network
environments where the upstream switches send loop detection frames, the VC Enet modules must
ensure that any downlink loops do not cause these frames to be sent back to the uplink ports. Even
though VC probe frames ensure loops are detected, there is a small time window depending on the
probe frame transmission interval in which the loop detection frames from the external switch might loop
through down link ports and reach uplink ports. By intercepting the external loop detection frames on
downlinks, the possibility of triggering loop protection on the upstream switch is eliminated. When
network loop protection is enabled, VC-Enet modules intercept the following types of loop detection
o PVST+ BPDUs
o Procurve Loop Protect frames
When the network loop protection feature is enabled, any probe frame or other supported loop detection
frame received on a downlink port is considered to be causing the network loop, and the port is disabled
immediately until an administrative action is taken. The administrative action involves resolving the loop
condition and clearing the loop protection error condition. The "loop detected" status on a port can be
cleared by one of the following administrative actions:
• Restart loop detection by issuing "reset" loop protection from the CLI or GUI
• Unassign all networks from the port in "loop detected" state
The SNMP agent supports trap generation when a loop condition is detected or cleared.
Virtual Connect provides the ability to enable or disable network loop protection. The feature is enabled by
default and applies to all VC-Enet modules in the domain. Network loops are detected and server ports can
be disabled even prior to any enclosure being imported.
A loop-protect reset command resets and restarts loop detection for all server ports in a “loop-detected” error
Reply from Chuck:
It will/should only shut down the downlink port connected to the server causing the loop. It is essentially a protection against customers who have bridged their internal server nics and have caused a loop. No other ports will be affected.
Any server networks using that downlink port (uplink port from the servers’ perspective) will be inaccessible until the bridge is removed and the reset loop command is issued.