FabricPath interview questions become easier when you separate three jobs: finding a path through the fabric, learning which edge reaches a host, and delivering a frame to multiple destinations.
Short answer: FabricPath provides Layer 2 multipathing using a dedicated IS-IS control plane and an outer header that identifies fabric switches; conversational learning limits remote host-MAC learning to relevant conversations.[2] Known unicast uses ECMP, while broadcast, unknown unicast and multicast use multidestination trees.[3]
What does IS-IS do in FabricPath?
FabricPath runs its own Layer 2 IS-IS process, separate from IP-routing IS-IS; neighbors exchange topology information and compute paths to fabric switch IDs.[2] This is why “routing at Layer 2” is a useful shorthand, but “IS-IS advertises every server MAC” is the wrong mental model: the fabric topology and edge host learning are different jobs.[2]
The basic process is: core-port hellos → adjacency → link-state database → shortest-path calculation → forwarding toward a destination switch.[2] For known unicast, multiple equal-cost next hops can be usable rather than selecting an STP tree for the fabric.[3]
Ask yourself two separate troubleshooting questions: “Can this switch reach the remote edge?” and “Does this edge know where the destination host lives?” Do not treat success on the first question as proof of the second.
Inner MAC addresses versus outer switch addresses
Encapsulation preserves the original Ethernet frame inside a FabricPath frame; the outer source identifies the ingress switch and the outer destination identifies the egress switch for known unicast.[2] Transit forwarding can therefore operate on fabric-switch reachability instead of requiring every transit switch to learn every host.[2]
The FabricPath header also has a TTL that decreases across the fabric and bounds how long a looping frame can survive.[1] This is a fabric forwarding safeguard, not a reason to ignore inconsistent topology or forwarding state.
Example: a known-unicast frame
Consider this fictional topology, with Host A and Host B in the same VLAN and with their relevant MAC mappings already learned:
Host A -- Edge A -- Transit X -- Edge B -- Host B
\- Transit Y -/
- Edge A receives A's ordinary Ethernet frame addressed to B.
- Edge A's destination lookup identifies Edge B as the remote destination.
- Edge A encapsulates the frame with itself as the ingress switch and Edge B as the egress switch.
- A selected equal-cost path carries the frame through the fabric.
- Edge B removes the encapsulation and delivers the original frame toward B.
This is a conceptual application of Cisco's encapsulation and ECMP model, not a captured lab result.[2][3] In your interview sketch, label the inner host addresses and outer switch identities separately.
What is conversational MAC learning?
Conversational learning reduces remote MAC-table population: a received source MAC is learned when its destination is already known, rather than making every edge learn every remote source it sees.[2] Explain this as selective learning around actual host conversations, not “there is no MAC learning.”
For an illustrative learning exercise, assume A is already locally learned on Edge A and B on Edge B. Follow A's first unknown-destination unicast, B's response, and A's next packet; at each receiving edge, ask whether the destination is already in its table before predicting remote-source learning.[2] Do not mistake this learning exchange for TCP's three-way handshake: it describes Layer 2 learning behavior, not a requirement to use TCP.[2]
Important exception: avoid the absolute statement that every FabricPath VLAN always uses conversational learning. The Nexus 5500 guide ties it to whether an SVI is enabled, and the Nexus 7000 8.x guide explicitly describes traditional learning when the VLAN's SVI is operationally up.[1][2] Check the exact platform, line card, release and SVI state before judging a MAC table.
Why are multidestination trees needed?
An unknown unicast cannot yet be sent to one known egress switch, and broadcasts need distribution beyond a single destination; FabricPath handles these alongside multicast using loop-free forwarding trees.[3]
In the documented two-tree model, broadcast and unknown unicast use the first tree, while multicast flows can be distributed across both trees.[3] The ingress assigns an FTag identifying the selected tree, and subsequent switches keep that tree choice; RPF checks reject multidestination traffic arriving outside its expected tree path.[3]
Do not describe this as copying every multicast packet onto both trees. A flow is assigned a tree, not duplicated across both for redundancy.[3]
Troubleshooting checklist: separate the failure domains
Use this checklist as a proposed investigation order, not as a claim that every symptom has one cause.
| Observation | Next question to investigate |
|---|---|
| No remote communication | Are core interfaces operational, neighbors present, and remote switch IDs reachable? |
| One VLAN fails | Is that VLAN active and configured for the intended FabricPath topology? |
| Unknown traffic fails but learned unicast works | Are the relevant tree, FTag and multidestination forwarding state correct? |
| Unexpectedly small MAC table | Is this expected conversational learning, or is a required host mapping missing? |
| Unexpectedly large MAC table | Is an SVI or hardware-specific learning mode changing the behavior? |
| One flow uses only one path | Is that consistent with the configured hash rather than an ECMP failure? |
The checklist separates the documented switch-ID, VLAN, tree and learning mechanisms; it is a diagnostic starting point rather than a vendor fault-isolation procedure.[1][2][3]
Read-only verification examples
The following commands are documented for the referenced Nexus guides; availability and optional syntax depend on the device and release.[1][3]
show feature-set
show fabricpath switch-id
show fabricpath conflict all
show fabricpath route
show fabricpath topology
show fabricpath topology vlan
show fabricpath topology ftag
show mac address-table learning-mode vlan 100
VLAN 100 is only an example. These commands have not been executed on a switch for this article. Record the actual state before changing timers, VLAN modes or learning behavior.
Common interview pitfalls
- “FabricPath is ordinary IP IS-IS.” Its Layer 2 control plane is separate.[2]
- “No STP means no forwarding safeguards.” FabricPath adds TTL and uses calculated paths; multidestination forwarding also uses RPF.[1][3]
- “Every edge learns every MAC.” Conversational learning is specifically intended to reduce that requirement, with platform/SVI caveats.[1][2]
- “Unknown unicast follows known-unicast ECMP.” It belongs to the multidestination case until the destination is learned.[3]
- “Two trees mean every packet takes both.” Multicast tree selection is per flow.[3]
A concise interview answer
Here is an original answer to practise aloud:
“FabricPath carries Ethernet across a multipath fabric. Its dedicated IS-IS process builds switch reachability, while the edge encapsulates host frames using outer fabric-switch identities. The core forwards toward the egress switch, which removes the encapsulation.”[2]
“Known unicast uses ECMP. Broadcast, unknown unicast and multicast use trees identified by FTags, with RPF checks for multidestination traffic. Conversational learning reduces remote MAC state at the edges, but I would verify the platform and SVI exceptions before calling a missing entry a fault.”[1][2][3]
Related reading
- OSPF vs IS-IS: areas, levels and interview answers
- STP vs RSTP: port states and roles
- vPC orphan-port troubleshooting
Summary and interview practice
Keep four labels on your diagram: topology, host learning, unicast path, multidestination tree. Then walk one frame through it without mixing those jobs. Preparing for a network engineering interview? Practise the short answer, then explain what you would inspect if learned unicast worked but a new host could not communicate.
Post a Comment