Showing results for 
Search instead for 
Did you mean: 

Fabricpath troubleshooting command

I've been using the "sh fabricpath load-balance unicast forwarding-path ftag 1 switchid 1430 flow-type l2 src-mac 1111.1111.1111 dst-mac 2222.2222.2222 ether-type 0x0800 vlan 604 module 7" ; "This flow selects Po3"....and I have some questions about how to interpret the output.

(Basic topology, 2 Aggs-->three spines-->10 leafs)

ftag 1<-- If I understand correctly, the ftag 1 applies to multidestination traffic, so how does this command work with the "unicast" command switch? (or how does the "unicast' command switch effect the "ftag 1" command switch)

switchid 1430<-- We have 10 leaf switches and they are paired (A/B; C/D; etc). regardless of the switch ID I put into this command, the output is always the same. In this case it is always if i enter switchid 1470, or 1510, the flow will select the same port-channel. OK...I understand that the flow is taking the same path but, what is the point of the switchid in the first place? How does it alter the output?

vlan 604<-- Regardless of the VLAN number entered, the output is the same even if the VLAN is not the source or destination network, so what is the purpose of the VLAN number?


Paul Chapman

Hi Brian -

I think that the problem here is that you are using random information to put in this command. 

What's happening in the background is that the switch is checking the FP routing table and not finding the listed MAC addresses.  If the traffic doesn't match the routing table, then it is considered "unknown unicast" and sent to root of multi-destination tree 0 (MT0) for flooding across the FP domain.

If you put in actual source and destination information, you will see different results.


Those MAC addresses were merely used as examples. In the even that somebody replied and had to retype the command or part of it, 1111........ and 2222....... is a bit easier to remember (and type) than an actual MAC address.

Hi Brian -

I stand by my previous answer that information that doesn't match the FP routing table will end up going to root of MT0.