DellEMC SmartFabric Director

SUMMARY: DellEMC seems to be tightening its focus on VMware and NSX-T fabrics by providing tools to ease the deployment of an underlay. SmartFabric Director (SFD) is a new tool to simplify that deployment and provide the needed functions for running an ethernet fabric with NSX-T on top. All the major needs for a fabric are covered to some greater or less extent. The tool can be used for other deployments as well but I think it makes most sense when putting NSX-T on top.

See DellEMC’s presentation at NFD21 here:


SFD provides a combination of deployment and operational features. Rather than type them out, DellEMC did a great job of summarizing these into a slide:

Deployment Features

Before even building the fabric, way back at the design phase, SFD is supported by an online calculator that will help in constructing the right build-of-materials (BoM) for your fabric called Fabric Design Center (FDC). The plan is to update this tool to provide a wiring diagram JSON as well (more on the JSON to come).

SmartFabric Director requires just four (4) starting inputs if you are using it for an NSX-T deployment:

– ASNs for the leaf switches
– ASNs for the spine switches
– Loopback IPs for the switches
– Subnets for the interconnection links between leafs and spines

For the other topologies it wasn’t covered what was needed to get the tool running – likely just the last two would be needed for L2. Additionally, the presentation mentioned they support unnumbered links as well but it is unclear if SFD will support that configuration operation.

SFD runs in an out-of-band topology with the fabric. This is critical as it drastically reduces the potential causes of connectivity loss to the switches in the fabric. Again, similar to CLI disabling (covered under Operational Features) I see this as a feature. It does, however, pose some limitations I’ll cover in Deployment Limitations.

To get started with SFD you must first import a JSON file that articulates the intended network wiring for the fabric. I cover my concerns on limitations of this method below but one can see this method as a feature. The tool will allow you to verify your wiring vs. an external source of truth (SoT) – presuming that SoT can easily output the intended wiring in the proper JSON format. 

Operational Features

Switches in a fabric managed by SFD cannot be edited manually from the CLI – you have to use SFD to make any changes to the fabric from that point forward. I list this as a feature as I think this is a good thing for the intended use case but have more thoughts on it as a limitation which I’ll cover below. Also, all the show commands remain available to the administrator while in SFD mode. This is really sharp as it will allow for the still common practice of CLI output for troubleshooting and investigation to occur without being hampered but, hopefully, help limit the number of self-generated mistakes that happen on the CLI. Additionally, SFD lets you see the configuration that will be deployed in a change to the switch(es) in question. Further, it supports the ability to jump directly into the switch and look at the configuration present.


The product has a number of limitations, some more significant than others. I’ll break these into deployment and operational concerns.

Deployment Limitations

First and foremost, it currently only works on greenfield deployments. You cannot re-purpose an existing brownfield deployment of Dell switches with OS10 in using this tool. Second, all the switches in the fabric will require a minor amount of manual intervention to enable the “SFD-mode” and then join the fabric. The tool is not a zero-touch provisioning tool. The decision to deploy in out-of-band means you have to have a compute cluster that can support this tool and means you MUST have it outside the fabric. Like many data center automation tools from other vendors this means the fabric has to be of a certain size to make this reasonable from a cost perspective. For small deployments, with only a few switches and in-band management only, this is not a tool you can use.

To begin you import the fabric’s intended wiring which must be laid out in a JSON file. While the above mentioned BoM tool (FDC) could help some this is likely to be an unexpected hurdle for some engineers and, specifically, those not familiar with JSON.  Given that most network engineers will likely be creating this file by hand in a text editor, and have spent many years properly cabling things, it means most deployments will spend some time fixing JSON files and re-importing rather than swapping cables.

Operational Limitations

SFD is not intended to replace a full network monitoring or configuration tool. It does not expose all the functionality and configuration capabilities of the underlying NOS/hardware platforms. This coupled with the need to push configuration changes from SFD (as write capabilities are disabled) means you will need to think through your operational process to ensure your team understands how to make changes in SFD. Additionally, if you discover some knob you feel you need to tweak, and it isn’t exposed by SFD, you will be unable to leverage it and will need to resolve the problem some other way. For the primary use case, NSX-T deployment, is not likely as a concern but if you are using SFD for a more generic L2/L3 deployment you could see issues there. As a last limitation, while DellEMC’s switches can support other vendor’s OSes. It doesn’t appear SFD will similarly support those other vendor NOS deployments. 


It is early days still for SFD and the features it provides to the network owner and operator. A number of bold decisions have been made by DellEMC in the product – a focus on the tool for configuration, the insistence on out-of-band management, and keeping to a limited set of deployment topologies. It provides a path to quickly and easily deploy a data center fabric for running NSX-T on top. Accounting for the current features and limitations I feel SFD hits its intended target for the first iteration – to help in getting a fabric built with minimal extra effort on the part of the network engineering team and then supporting ongoing, basic operations needed for that fabric. Further iteration will expand SFD’s features and provide a more comprehensive tool. I hope DellEMC does iterate on the product and does keep a strong focus on on the use case of a straightforward tool to build and then manage a standardized, simple underlay network on which to run NSX-T. 


Disclosure: I was invited to participate in NFD21, and my participation is voluntary. Gestalt IT hosts the event and my transportation, accommodations, food and beverage is paid for by Gestalt IT for the duration of NFD21. I am not required to produce this post, and it was not reviewed or edited by Gestalt IT, other delegates or the sponsors of the event. I’ve edited this post a few times for typographic and similar issues and to add more links.