PC-A and PC-B belong to the same broadcast domain that is defined by vlan X. Without FabricPath (FP), a frame that is sent by PC-A is received by FP-SW1. PC-1 MAC source address is learnt by FP-SW1 in CAM to ease further frame local forwarding decisions.

Initially PC-1 did not know PC-B MAC address and floods PC-A frame to FP-SW2 and FP-SW3. Similarly FP-SW2 and FP-SW3 learns PC-A MAC source address and flood it over all vlan ports except the one the frame was received on.

The problem here is that FP-SW2 and FP-SW3 re-learn this MAC address a second time from each other. This new entry updates the old one that was pointing to FP-SW1. Imagine a huge amount of traffic from PC-A, this would result in inefficient switching and network congestion among other problems pertaining to system resources RAM and CPU consumption.

A spanning-tree like protocol is necessary to avoid such a situation. Spanning-tree protocol builds a loop-free tree by allowing designated and root ports to forward traffic and disallowing the non-designated ones.

This solves the previous problems but burden the network capacity as in this tree PC-A communicate with PC-B over exactly one path at a time: PC-A_FP-SW1_FP-SW3_PC-B. The other path PC-A_FP-SW1_FP-SW2_ FP-SW3_PC-B is unusable being blocked by spanning-tree.

Here FabricPath (FP) comes into play. FP processes a multipath loop-free tree for PC-A and PC-B to communicate. When FP is enabled, the switches establish IS-IS L2 adjacencies to each other and exchange topological information. The result of this is that each FP-SW1 is now aware of 2 paths  that lead to FP-SW3 for PC-A to reach PC-B.

Only FP-SW1 and FP-SW3 learn PC-A and PC-B corresponding MAC addresses. FP-SW2 that is a core switch in this case, does not learn these MAC addresses that are not attached to it.

How FP-SW1 dertermines the path to PC-B that is behind FP-SW3? FP-SW1 receives an FP frame from FP-SW3 with an outer source address field that contains FP-SW3 switch ID (SID) and in the payload, the original Ethernet frame which hints on the source MAC address of PC-B. To reach PC-B MAC address, FP-SW1 builds an FP frame (Ethertype:0x8903)  destined to FP-SW3 based on the already learnt information that matches FP-SW3 SID (FP attribute) to PC-B MAC address (Classical Ethernet (CE) attribute). Forwarding of this frame in the FabricPath is based solely on the SID.

In FP domain, broadcast, multicast or unknown unicast traffic is not handled the same way as unicast known destination MAC address traffic. Similarily to spanning-tree, topologicial trees (identified by FTAG and assigned by ingress FP switch) for this trafic are built by electing roots and identifying least cost path to these roots from FP nodes. The number of these trees is platform dependent and used for load-balancing.

Multicast trees in an FP domain are per-vlan. If a vlan is not configured in a switch, this switch is not part of the corresponding tree and is pruned from the corresponding vlan tree.

Is it possible from any switch to identify the switches that are participating (not pruned) in a per-vlan topology? Is this view consistent over all FP domain nodes? Yes, group memberships are learnt from igmp at switches (with CE links) using IS-IS by means of GM-LSPs and could be checked in this way:

• On any FP switch check that the required list of vlans are added to the FP topology : show fabricpath topology vlan
• Check the FP multicast routing table that hints on the received group memberships per vlan and the corresponding FP switch-ids
• Use eventually “show fabricpath isis hostname/switch-id” to match switches’ hostnames to switch-ids.
• If vlan is present but some switch-ids are missing. Then check if that vlan is configured on these switches.