Cisco FabricPath vs TRILL: Data Center Fabrics

Before VXLAN EVPN became the default answer, the data centre had a different one: build a Layer 2 fabric with a routing protocol underneath and get rid of spanning tree entirely. Cisco FabricPath and the IETF's TRILL were two implementations of that idea. Understanding them still pays off, because they explain why today's fabrics look the way they do — and they show up in plenty of installed networks that are still running.

The problem both technologies solved

Classic Ethernet has three properties that hurt at data-centre scale: only one path can be active between any two switches (spanning tree blocks the rest), MAC address tables grow with the number of hosts rather than switches, and convergence after a failure is measured in seconds. A resource-pooling fabric needs multiple equal-cost paths, a control plane that converges in milliseconds, and a forwarding table indexed by switch rather than by host.

FabricPath: MAC-in-MAC with an L2 IS-IS control plane

FabricPath encapsulates the original Ethernet frame with a new outer header containing a 12-bit SwitchID as the destination. Switches forward on the SwitchID, not on the host MAC, so the fabric's forwarding table is proportional to the number of switches rather than hosts. An L2 IS-IS instance builds the topology and computes shortest paths, and equal-cost multipath means every link can be active.

install feature-set fabricpath
feature-set fabricpath
feature fabricpath
!
fabricpath switch-id 100        ! unique per switch in the fabric
!
! verification
show fabricpath switch-id
show fabricpath route
show fabricpath isis adjacency
show fabricpath isis topology summary

Two operational details matter. Switch IDs are assigned automatically in some designs and statically in others; a duplicate ID is a serious fabric fault, and it is worth pinning IDs deliberately on large fabrics. And FabricPath edge ports are ordinary Ethernet ports (the frame is only encapsulated once it enters the fabric), so hosts see no difference.

Conversational learning and MAC scale

Instead of learning every source MAC on every switch, FabricPath uses conversational learning: a switch only installs a MAC in its table once it has seen traffic destined to that MAC. Combined with the SwitchID-based core, this is what allowed fabrics with tens of thousands of hosts without the MAC table explosion that flat Layer 2 would produce.

TRILL: same idea, standardised

TRILL (RFC 6325) replaces the FabricPath outer header with a standard TRILL header containing ingress and egress RBridge nicknames, plus a hop count. RBridges run IS-IS at Layer 2, and the encapsulation is MAC-in-MAC with an Ethernet type of 0x22F3. Functionally it overlaps heavily with FabricPath; the differences are in the details — nickname allocation, the encapsulation format, and multi-topology extensions.

! TRILL on NX-OS where supported - feature names differ by release
feature trill
trill nick-name 0x10
show trill route
show trill isis adj

Where they differ, practically

• Standards position: TRILL is an IETF standard; FabricPath is a Cisco implementation described as a superset, with Cisco committing to TRILL support when the standard matured.
• Platform support: FabricPath was built around the Nexus 7000/5500 F-series hardware; TRILL support was platform- and release-dependent. Both are narrow compared to VXLAN, which runs on virtually every merchant-silicon switch.
• Control plane: both use IS-IS at Layer 2, so operational skills transfer directly.

Why VXLAN EVPN superseded both

The decisive difference is where the fabric can run. FabricPath and TRILL require hardware support in the switch silicon and a specific platform family. VXLAN encapsulates in UDP and can be implemented in software, on merchant silicon, on a hypervisor, or on a NIC — and it pairs with BGP EVPN, a control plane every network engineer already knows how to run. That combination of universality and familiarity is why new builds use it.

If you are running FabricPath today, the migration question is usually not "when do we replace it" but "can we grow it further" — the answer being that upstream development effort moved on long ago. The EVPN equivalents to study are EVPN-VXLAN symmetric IRB, which replaces the L2/L3 fabric services FabricPath provided, and EVPN multihoming vs MLAG for the dual-homing behaviour that vPC+ delivered on FabricPath.

Verification and troubleshooting notes that carry over

show fabricpath route switch-id 100
show fabricpath isis adjacency detail | include Interface|State
show fabricpath isis database detail
show interface Ethernet2/1 counters     ! fabric link health
show logging | include FABRICPATH

Symptoms worth recognising on any IS-IS-based fabric: all adjacencies up but no routes (a switch ID conflict), routes present but traffic drops (an MTU mismatch on the outer header — the encapsulation steals bytes from the payload budget), and one switch missing from the topology (a misconfigured metric or a blocked IS-IS interface).

原文链接：https://community.cisco.com/t5/data-center-and-cloud-blogs/chalk-talk-fabricpath-trill-vxlan/ba-p/3099807