A large company recently configured one of its Virtual Connect production networks in an Active-Active configuration with SmartLink enabled.
This configuration is designed to provide full redundancy. Should a component such as a backbone or card on one vNet lose power or connectivity, Smartlink enables the network to continue functioning by redirecting the traffic to the other vNet (Virtual Connect internal network).
Despite the mixup traffic continued to flow, albeit in a circuitous route, as Flex2 traffic routed through Flex1 and Flex2 travelled through the Flex1 production network, since that was the logical definition.
However, at one point, a card in Flex1 lost connectivity. Ordinarily Smartlink would have enabled Flex2 to take over, providing failover service. However, because in this case the vNets were reversed, no traffic could flow since ‘logically’ all paths were blocked; Flex1 network traffic could not flow because it was blocked physically with the loss of communication, and Flex2 traffic was blocked logically. Therefore all traffic in and out of the Blade was halted.
With this shutdown, the customer was facing a crippling loss of service and installed MagicFlex to determine the source of the problem. The configuration error quickly appeared in the Analysis area of the MagicFlex dashboard.
The enterprise was then able to correct the configuration so that all traffic could flow through Flex2 until power was restored in Flex1 and to prevent further mishap.