Dell OS10 SmartFabric Services: Uplink Design

SmartFabric Services (SFS) changes how a Dell PowerSwitch fabric is built: instead of configuring every leaf by hand, you bring up one designated lead switch, attach the remaining switches on the fabric links, and the fabric controller assigns VLT domains, peer links and port profiles automatically. The part that still needs human judgement is the boundary — which ports become fabric links, which become server-facing access ports, and how the fabric reaches the outside world through L2 or L3 uplinks. This guide covers that design boundary, the port roles SFS assigns, and the commands you use to verify what the controller actually built.

What SmartFabric Services automates

In an SFS fabric, one switch runs in SmartFabric mode as the lead (designated) switch. Additional switches join through designated fabric links and are discovered, after which SFS configures VLT between leaf pairs, an automated port channel for the peer link, VLANs, and per-port profiles derived from the network policy attached to the uplink. Operational reality: the leaf pair ends up as VLT peers whether or not you would have built it that way by hand, which is usually what you want for dual-homed servers.

Designing the uplink boundary

Two decisions determine most of the fabric's behaviour.

L2 uplink versus L3 uplink. An L2 uplink extends customer VLANs to an external switch and keeps the SFS fabric as a bridged domain — simple, but it puts the fabric inside the spanning tree domain and forces you to think about which switch is the root. An L3 uplink terminates VLANs in the fabric: the SFS leaf pair becomes the default gateway, and traffic leaves through a routed port or a VLT port channel with OSPF or BGP on top. Most designs that already run EVPN or a routed core should pick L3.

Uplink redundancy. With a leaf pair, attach one uplink per leaf and bundle them into a VLT port channel towards the upstream device; that gives you both link and device redundancy while keeping a single logical interface. Single-leaf fabrics should use two uplinks to two different upstream switches with LACP fallback or a validation that keeps only one active.

# verify the fabric SFS built, before you add uplinks
show smartfabric cluster
show smartfabric cluster member
show smartfabric cluster link-status
show vlt brief
show port-channel summary

Creating the uplink and attaching a network profile

The uplink wizard asks for four things: the uplink type (L2 or L3), the ports, the network or routing profile to associate, and the uplink name. Association is what ties VLANs and routing configuration to the physical members; changing the profile later re-applies network configuration across all uplink ports, which is why profiles should be treated as design artefacts rather than one-off settings.

# typical CLI side-effects to verify after an L3 uplink with a VLT LAG
show running-configuration interface port-channel 100
show running-configuration interface ethernet 1/1/1
show ip interface brief vrf default
show ip route | head

On the routed side, check that the upstream device sees exactly one LACP neighbour for the bundle and that the fabric advertises its subnets with the expected next hop. A common failure is an L3 uplink whose VLANs are still attached to the fabric's internal port profile, which produces asymmetric return paths — traffic in via the routed uplink, out via the L2 domain.

Verification and rollback

SFS keeps a transaction-style history of fabric operations. Before making a change, capture the current fabric state; after the change, compare the two.

show smartfabric cluster detail
show smartfabric cluster endpoint
show running-configuration | grep -i smartfabric
show smartfabric cluster history

If an uplink change breaks reachability, removing the uplink from the fabric configuration restores the previous network profile mapping; the leaf pair's VLT and fabric links are untouched by uplink operations, so servers stay reachable. Keep the uplink change window short anyway: a misconfigured L3 uplink is the fastest way to lose management access to the fabric, so always keep an out-of-band path to the lead switch.

Designing network profiles that survive change

In SFS the network profile is the unit of intent: it carries the VLANs, the untagged VLAN, the routing behaviour and the physical port configuration that gets applied to every port the profile touches. Treated as a design artefact, it makes adding a rack a two-minute job. Treated as a per-port setting, it produces a fabric where nobody can say which VLANs a given port should carry. The practical discipline is one profile per server role — compute, storage, hypervisor management, hypervisor data — with the profile named after the role rather than after the switch or rack it was first used in.

Troubleshooting the failures you will actually see

A new switch never joins the fabric. Check the candidate fabric links first: if the port is configured as a server port by a profile, discovery never begins. The usual cause is a port that was previously in use with a server profile, and the fix is to clear the profile from that port before attaching the fabric link.

A server can reach its gateway but not a host on another leaf. In an L3-uplink fabric this is almost always VLAN membership: the profile on the server port does not include the VLAN the remote host lives in, so the frames never enter the fabric. Verify with show running-configuration interface ethernet 1/1/5 that the tagged VLAN list matches the design, and compare with the uplink's profile.

Uplink is up but the fabric has no route. Check whether the uplink was created with the wrong type: an L2 uplink carrying VLANs that the fabric expects to route produces a state where the fabric is working exactly as configured and nothing can be reached. Read back the uplink type before debugging routing.

show smartfabric cluster
show smartfabric cluster member
show smartfabric cluster link-status
show smartfabric cluster detail
show network-profile
show running-configuration interface port-channel 100
show vlt mismatch        # catches configuration drift between VLT peers

Scaling beyond a single leaf pair

SFS supports fabrics larger than two switches: spine switches join the fabric as member switches and the leaf pairs attach to them over fabric links. The scaling questions are the ones any fabric design answers: how much oversubscription the uplinks provide, whether the spine layer is a full mesh, and where the routing boundary sits. Because SFS configures the internal links automatically, the visible design decisions reduce to the counts: how many leaf pairs, how many uplinks per leaf pair, and what the failure of any single spine does to capacity. Model the failure case explicitly, since a spine failure in an oversubscribed design takes bandwidth from every leaf pair at once.

Two SFS-specific constraints to plan around: the fabric has a bounded number of switches it manages, and the lead switch is a single point of control even though data forwarding continues if it fails. In production, document which switch is the lead, keep out-of-band access to it, and take a configuration backup of the fabric before any structural change — the fabric's own history is useful, but a text backup of every switch is what you will actually read during an incident.

Operational routine

• After every fabric change, run the cluster verification commands and record the output in the change ticket; drift is easier to spot against a known-good sample than from scratch.
• Add a new leaf pair as a single operation rather than switch by switch, so the fabric always reflects a documented topology.
• Keep the uplink profile documents in the repository next to the switch configuration, not in a spreadsheet.
• Review firmware across the fabric as a set — SFS features and bug fixes arrive with the OS release, and a mixed-version fabric is the hardest kind to support.

FAQ

Does SmartFabric Services replace VLT configuration entirely? No — it generates and manages it. The VLT peer relationship still exists and still needs its peer link and keepalive; you simply are not typing it. Knowing the underlying construct is what lets you diagnose a split-brain or peer-link failure when it happens.

Can a non-Dell switch sit in the middle? The fabric links expect Dell switches in SmartFabric mode. Non-Dell devices belong on the uplink boundary as external switches, which is precisely what the L2 or L3 uplink option is for.

How do I add a VLAN to the whole fabric? Add it to the network profile attached to the uplink, then let the profile reapply; the VLAN propagates to the ports the profile touches. Manually creating a VLAN on individual leaves creates exactly the configuration drift the fabric model exists to remove.

What is the safest way to migrate an existing manually configured leaf pair into SFS? Treat it as a rebuild: prepare the target profiles, schedule a window, start with a leaf pair that carries no production-critical hosts, and keep the previous configuration backed up so a rollback is a restore rather than a reversal of dozens of commands.

Related Reading

Related reading: Dell OS10 VLT Setup: Step-by-Step Virtual Link Trunking Guide, Dell OS10 VXLAN BGP EVPN Configuration Guide, Dell OS10 Port-Channel Configuration: LACP Step-by-Step

原文链接：https://infohub.delltechnologies.com/p/getting-started-with-smartfabric-services/