Among other topics discussed during the Big Hot and Heavy Switches (Part 1) podcast (if you haven’t listened to it yet, it’s high time you do), we’ve mentioned port extenders. As our virtual whiteboard is not always clearly visible during the podcast (although we scribble heavily on it), here’s the big-picture architecture:
Port or Fabric? Cisco uses the term fabric extender; port extender is used in the IEEE 802.1Qbh standard. Obviously one is a technology term, the other one a marketing term (or product name). It looks like everything in the Data Center is *Fabric*, everything in WAN is *Borderless*. Slowly I might get used to it.
Another explanation I found says “Fabric Extender is a standalone implementation of a Port Extender”. I’m not buying it; see the 802.1Qbh introduction (from Cisco) for details; it's very clear they are not talking about a virtualized environment.
Standardized or not? Cisco brought the idea of port extenders to IEEE 802.1 and effectively started the 802.1Qbh working group. However, 802.1Qbh specifies only the control protocol between the controlling bridge and the port extender. It refers to 802.1Qbg for the specification of the tagging on the link between them. 802.1Qbg (which is close to VNTag/VNLink idea from Cisco) refers to 802.1Qbc standard (well hidden behind the paywall) which specifies the actual encapsulation mechanism. The claim that “Cisco has pioneered the VNTag scheme and IEEE 802.1Qbh will use it as a base for the standard” (Cisco Unified Computing System, Cisco Press 2010, page 85) is thus somewhat dubious.
VNTag or not? I was not able to find any authoritative information on the encapsulation format used between fabric extender and controlling bridge. There are plenty of allusions floating around, but nothing very explicit.
There’s also a slight nesting problem: if a fabric extender (Cisco UCS 2100 Fabric Extender) uses VNtag toward the controlling bridge and the UCS blade NIC (Cisco Palo) uses VNtag toward the controlling bridge, we might end with two stacked VNtags.
Fabric Extender limitations. Compared to IEEE 802.1Qbh draft that Cisco started, fabric extenders are extremely limited. For example, the standard aims to provider:
- Autodiscovery of port extenders. Not available in the Nexus software; you have to manually configure the switchport type and FEX ID on the interface to which the fabric extender is connected.
- Chaining of port extenders. A port extender can be connected to another port extender, creating a hierarchy. Not available with Nexus 2000 series.
- Port extender transparency. You can connect anything (host or another bridge) to a port extender physical port. Nexus 2000 products allow only hosts to be connected to the downstream ports; BPDU guard is automatically configured on those ports.
Fabric Extender enhancements. As always, Cisco offers more than the standard it has launched. For example, you can use Virtual Port Channel to have dual-homed fabric extenders.