# Extreme Fabric Connect: one service, edge to edge

> Nine articles on Extreme's fabric, read in the order a service comes into existence: which operating system, what the words mean, what the fabric is, how the nodes know each other, how a service rides the backbone, why multicast needs no configuration, how the edge asks for what it needs, and how the edge is dual-homed without spanning tree. The organising fact is the one the fabric is built on - a service is provisioned at the edge, not trunked hop by hop.

Source: https://ronutz.com/en/learn/extreme-fabric-connect-one-service-edge-to-edge  
Updated: 2026-09-09

---

For why multicast is expensive everywhere the fabric is not, read **[what it costs to not flood](https://ronutz.com/en/learn/multicast-what-it-costs-to-not-flood)** alongside step six.

## Why this order

A traditional campus network is understood link by link: a VLAN exists on this switch, is trunked to that one, is routed at the third. Every hop is a place where the configuration has to agree with the previous hop, and every outage is a place where it did not.

A fabric is understood the other way round. The core is a transport that carries opaque services, the services are defined once at the edge, and the middle does not know or care what they are. Almost everything that is confusing about Extreme's fabric on first contact stops being confusing once that inversion is accepted - so this page reads the nine articles in the order a *service* comes into existence, from the choice of operating system to the moment an edge device is dual-homed into it.

## 1. Which operating system

**[VOSS versus EXOS](https://ronutz.com/en/learn/voss-vs-exos)** - Extreme ships universal hardware that boots either a traditional-Ethernet operating system with a familiar command line, or a fabric-native one built around the concepts below. The decision is made per switch and it is the first decision, because everything after it differs.

**[The universal OS names](https://ronutz.com/en/learn/extreme-universal-os-names)** - the two systems were renamed on some hardware and not others while the image files and boot menus kept the old names. Worth reading before a first upgrade, and the second half - what changing persona does to a configuration - matters more than the naming.

**[How ExtremeXOS configuration is structured](https://ronutz.com/en/learn/how-extremexos-config-is-structured)** - for the traditional side: no interface sub-modes, every line a self-contained imperative command starting with a verb. A reader arriving from the other major vendors will find the shape unfamiliar and, after an hour, hard to give up.

## 2. What the words mean

**[The fabric vocabulary](https://ronutz.com/en/learn/spb-fabric-vocabulary)** - I-SID, B-VLAN, B-MAC, BEB, BCB, L2VSN, L3VSN. Which is a service, which is transport, and which is a role a switch plays, plus the one fact that makes the rest obvious. Read this before anything below; the remaining articles use the terms without re-explaining them.

## 3. What the fabric is

**[Fabric Connect and SPBM](https://ronutz.com/en/learn/voss-fabric-connect-spbm)** - Shortest Path Bridging MAC, IEEE 802.1aq: an IS-IS control plane and a MAC-in-MAC data plane, and why collapsing the core to a single protocol removes the layered stack of spanning tree, trunking, and routing that a campus otherwise carries.

## 4. How the nodes know each other

**[IS-IS and nicknames](https://ronutz.com/en/learn/voss-isis-and-nicknames)** - one link-state control plane, running on fabric links only. Each node has a 20-bit nickname that must be unique across the fabric, and its system identifier drives the backbone MAC that the data plane encapsulates with. A duplicate nickname is the fabric equivalent of a duplicate IP address, and it is the first thing to check when two nodes cannot see each other.

## 5. How a service rides the backbone

**[I-SIDs and VSNs](https://ronutz.com/en/learn/voss-i-sid-and-vsns)** - the 24-bit service identifier, and the three things that ride it: a Layer 2 VSN, a Layer 3 VSN, and IP Shortcuts. This is the article that makes the inversion concrete: the service is provisioned at the edge switch, the backbone carries it without knowing what it is, and there is no per-hop trunk configuration to get wrong.

## 6. Why multicast needs no configuration

**[Multicast addresses are computed, not learned](https://ronutz.com/en/learn/spbm-multicast-addresses-are-computed-not-learned)** - a backbone group address is never learned and never configured. It is assembled from the root node's nickname and the service's I-SID, which is why every node arrives at the same answer independently, and why multicast on the fabric does not need the rendezvous points and flooding rules it needs everywhere else.

## 7. How the edge asks for what it needs

**[Fabric Attach](https://ronutz.com/en/learn/voss-fabric-attach)** - an edge device signals the service it wants, and the fabric provisions the I-SID automatically. The server, proxy and client roles, and how the signalling rides LLDP (Link Layer Discovery Protocol). This is where an access-layer switch, an access point, or a phone joins a service without anyone touching the fabric.

## 8. How the edge is made resilient

**[SMLT and virtual IST](https://ronutz.com/en/learn/voss-smlt-and-vist)** - Split MultiLink Trunking dual-homes an edge device to a pair of switches with active-active links and no spanning tree, and the inter-switch trunk that keeps the pair coherent runs *through* the fabric rather than over a dedicated cable. Read last, because it assumes everything above.

## The habit this sequence teaches

**Find the layer where the problem lives.** A traditional network fault is diagnosed hop by hop because the configuration is hop by hop. A fabric fault is almost always in one of three places: the node cannot join (step 4 - nicknames, IS-IS adjacency on fabric links), the service is not provisioned at the edge that needs it (step 5, or step 7 if Fabric Attach should have done it), or the edge's dual-homing is inconsistent (step 8). Working the sequence is faster than tracing the path, because in a fabric there is no path to trace - only a service that either exists at both edges or does not.

For where this design sits in the longer history of the switch, see the [bridge and switch lineage](https://ronutz.com/en/learn/bridge-switch-family-history).
