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. 159
• Simple Loop Prevention Protocol (SLPP) on distribution (IP gateway) nodes.
Extreme Networks’ best design guidelines mandate that user and server access ports must always be
configured with Spanning Tree enabled as MSTP Edge ports (or STP FastStart). In an Extreme Networks
Fabric Connect design, these are the only ports where Spanning Tree should be left running; this is done to
ensure they emit BPDUs every second, which can then be used to preempt a patch panel loop condition.
The very same access ports should also always be provisioned with both BPDU Filtering and SLPP-Guard
enabled.
An access port with BPDU Filtering enabled will immediately go offline if it receives a Spanning Tree BPDU.
Likewise, an access port with SLPP-Guard enabled will immediately go offline if it receives an SLPP packet.
SLPP is a simple protocol that consists of generating an L2 broadcast packet (an SLPP PDU, which carries
information of the VLAN it was originated on) on a given VLAN at regular intervals. Like for any broadcast
packet, the expectation is that these packets will be flooded across all port members of the VLAN but are
never seen to come back (on same or different VLAN). SLPP is configured on distribution layer nodes,
which is usually where all the VLAN IP interfaces are also configured (though SLPP has no IP
dependencies). SLPP PDUs will be flooded on VLANs and L2 VSNs alike.
Let us cover the layers of defense as they would trigger following a patch panel loop condition.
First Line of Defense – BPDU Filtering on Access Ports
1. Patch panel loop is introduced.
2. Link up event on access ports involved.
3. Spanning Tree BPDUs will be the first packets to be sent out of the access ports.
4. If the patch panel loop is just a cable, the access ports will receive eachother’s BPDUs and BPDU
Filtering will immediately shut down one or both the access ports. A trap is generated and the fault
condition is averted.
Second Line of Defense – SLPP Guard on Access Ports
1. If the access loop is via a hypervisor server, or via an IP phone (neither of which is likely to relay or
generate BPDUs), BPDU Filtering will not detect anything and both access ports will settle into a
Forwarding state where packet forwarding onto the external loop commences.
2. The first packets to make it out onto the external loop segment will be broadcast or multicast
packets among these SLPP packets (which are typically generated every 500 milliseconds).
3. The first access port to receive an SLPP PDU over the external loop segment will immediately shut
down thanks to SLPP-Guard. A trap is generated, no loop has time to form, and the fault condition is
averted.
Third Line of Defense – SLPP on Wiring Closet Distribution
1. This scenario is only applicable if the access switches were not correctly provisioned with SLPP-
Guard or there is a problem with the access switch’s MLT uplinks into the distribution nodes causing
packet reflection. In this case, SLPP-Guard on the access switches cannot be relied on to detect or
prevent looped packets.
2. In this case, a loop condition will take hold (either a full loop or a half loop or collapsed edge VLANs)
3. If we are experiencing a full or half loop within the same VLAN:
a. Distribution nodes that are running SMLT links (with or without Fabric Attach) toward the wiring
closet access switches will start seeing SLPP PDUs returning to them on those uplinks, and will
count these packets against configured slpp-rx-thresholds.
b. A first distribution node will disable its uplink to the offending wiring closet switch and generate
a trap. If the fault condition was due to MLT misconfiguration on the access switch, the fault
condition is corrected and users connected to the access switch retain connectivity. However,
that access switch has now lost uplink redundancy.