Network Virtualization using Extreme Fabric Connect
Table Of Contents
- Table of Contents
- Table of Contents
- Table of Contents
- Table of Figures
- Table of Figures
- Table of Tables
- Conventions
- Introduction
- Reference Architecture
- Guiding Principles
- Architecture Components
- User to Network Interface
- Network to Network Interface
- Backbone Core Bridge
- Backbone Edge Bridge
- Customer MAC Address
- Backbone MAC Address
- SMLT-Virtual-BMAC
- IS-IS Area
- IS-IS System ID
- IS-IS Overload Function
- SPB Bridge ID
- SPBM Nick-name
- Dynamic Nick-name Assignment
- Customer VLAN
- Backbone VLAN
- Virtual Services Networks
- I-SID
- Inter-VSN Routing
- Fabric Area Network
- Fabric Attach / Auto-Attach
- FA Server
- FA Client
- FA Proxy
- FA Standalone Proxy
- VPN Routing and Forwarding Instance
- Global Router Table
- Distributed Virtual Routing
- Zero Touch Fabric (ZTF)
- Foundations for the Service Enabled Fabric
- IP Routing and L3 Services over Fabric Connect
- L2 Services Over SPB IS-IS Core
- Fabric Attach
- IP Multicast Enabled VSNs
- Extending the Fabric Across the WAN
- Distributed Virtual Routing
- Quality of Service
- Consolidated Design Overview
- High Availability
- Fabric and VSN Security
- Fabric as Best Foundation for SDN
- Glossary
- Reference Documentation
- Revisions
Network Virtualization Using Extreme Fabric Connect
© 2019 Extreme Networks, Inc. All rights reserved. 143
Clearly for Fabric Connect fast-rerouting to be possible, the SPB core needs to be architected with
sufficient redundant paths and switching capacity such that loss of a component (link or node) does not
impact connectivity and/or switching capacity after a failure. If this premise holds, then the ability of Fabric
Connect to heal around failed links or nodes becomes an operational asset whereby any given SPB node
can be taken out of operation from the fabric for maintenance work or software updates without impacting
any applications running over the network. The virtualized network now offers the same operational
capability that virtual servers do, where Virtual Machines can be hot-migrated away from a physical server
in order to perform maintenance on the hardware.
Tip
When taking an Fabric Connect node offline for maintenance work, this can be done
gracefully by activating IS-IS overload, whereby the node will signal to the rest of the SPB
Fabric that it is no longer to be considered as a transit node for path calculations by other
nodes. If the node is a BEB using VLACP, this can be subsequently deactivated to ensure
SMLT/Fabric Attach links are also gracefully deactivated before the node is taken fully
offline.
Virtual LACP
VLACP is an extension of LACP (Link Aggregation Protocol) used exclusively for link integrity and neighbor
control plane keep alive detection.
This is accomplished by each switch transmitting VLACP PDUs on switch-switch links at a set timer interval
in order for a link to maintain a ‘link-up’ state. It allows the switch to detect unidirectional or bidirectional
link failures irrespective of intermediary devices as well as an indication of the control plane liveliness of the
adjacent node, which gigabit Ethernet auto-negotiation Far End Fault Detection (FEFI) and 10 gigabit
Ethernet Remote Fault Indication (RFI) cannot detect.
Note
LACP offers the same link integrity capability combined with the ability to dynamically
aggregate interfaces into Link Aggregation Groups (LAG), i.e., Multi-Link Trunks (MLTs)
The differences between LACP and VLACP are:
• VLACP does not have any link aggregation capabilities.
• VLACP is optimized to run on significantly faster timers, as low as 200 ms.
• VLACP can use customized multicast MAC address and ethertypes, which allows it
to be used beyond link local (i.e., across a Layer 2 Ethernet cloud).
VLACP is not required if LACP is already enabled on a given set of ports.
With Extreme Networks Fabric Connect, best practice design guidelines call for VLACP to be activated on
all switch-switch Ethernet physical (or logical) links. Because VLACP runs on fast timers, loss of link
integrity can be detected sub-second, without having to rely on IS-IS Hello timers which run at a much
slower pace (every nine seconds with three retries).
VLACP thus ensures that SPB’s fast-reroute capabilities are ensured under these extreme failure scenarios:
• Logical link failure. The link to the adjacent switch is transported over some L2 transport cloud (in
this case physical link status is no longer correlated with logical link status).
• Software lockup or not responding on adjacent switch. This is a rare but possible failure scenario in
moderns Ethernet switching platforms where the hardware is able to continue switching traffic
without software/CPU intervention, for example after a software failure/seizure.