Fabric patch header reading

[kumarvi@hcl.com]

when we are using fabricpatch, if a frame comes on edge switch, who encapsulates that packet and forwards it to spine switch, does every switch further in the path opens that packet to to read inside information like vlan from the original paylod or there is anything in the FP header which tell to which vlan that packet belong to.

i have studied the entire FP frame but doesnt see any information about vlan tag...then how come spine/core switch come to know about to which vlan that packet belong to? any idea friends...?

Thanks

[Jon Marshall]

Each switch in a FabricPath network has a switch ID associated to it which is unique per switch. The switches exchange this information and each switch builds a routing table containing switch IDs and the corresponding next hop to get to that switch.

When a packet comes into the ingress switch it will do a lookup for the destination mac address. If the destination mac address is on a remote switch then it will have a corresponding switch ID in the lookup table.

The ingress switch adds a FabricPath header which, amongst other things, has a destination address. This destination address is the switch ID.

The core switches then simply look at the header to find the destination address (switch ID), consult their routing tables to find out which link to forward the packet on and send it out of the corresponding interface.

When the egress switch receives the packet it removes the header and forwards the packet on to the destination device.

So the core switches do not need to know which vlan the packet is in.

Note i have skipped over how edge switches learn of remote mac addresses and when i refer to the routing table i am talking specifically about the routing table for FabricPath and not the IP routing table.

So the above explanation is for unicast traffic where the edge switch knows which remote switch the destination mac address is located on.

Jon

[kumarvi@hcl.com]

Hi Jon,

If they dont need to look into the packet to identify for which vlan it its, lets suppose there is ARP broadcast, which has to be forwarded into every port which is in that particular vlan and lets suppose there is a some system is also in same vlan on core switch, i mean a source is connected on switch A and sending a packet to a destination on switch D, what if there is a port on switch B also in same vlan, then arp request must be forwarded to that port also...so i am still not clear if any other switch other than edge switch will open that packet upto inner encapsulated ethernet frame or will jst open it to outside fabricpath frame.

SwitchA-------SwitchB-------SwitchC-------SwitchD

if you look at the white paper...

http://www.cisco.com/c/en/us/products/collateral/switches/nexus-7000-series-switches/white_paper_c11-687554.html

there is an example given of mac learning...and if you look at the step no. 10,

"On S20, S30, and S40, no interfaces other than the one on which the frame was received belong to multidestination Tree 1, and no FabricPath edge ports exist in VLAN 10 on these switches. Therefore, these three switches discard the frame. Note that no MAC learning occurs on these switches based on these actions "

in this example s20,30 40 are core switch and look at the above statement " no FabricPath edge ports exist in VLAN 10 on these switches" ... how do they come to know that packet is for vlan10??

[Jon Marshall]

in this example s20,30 40 are core switch and look at the above statement " no FabricPath edge ports exist in VLAN 10 on these switches" ... how do they come to know that packet is for vlan10??

Okay, i understand what you are asking.

As far as i know  what it is really saying is that on those switches no FabricPath edge ports exist at all regardless of the vlan. Because there are no edge ports that means those switches never need to remove the FabricPath header to look at vlan tag because they only forward based on the switch ID as previously discussed.

If any of those switches did have edge ports then they would need to look at the vlan tag in the original header to see if any of their edge ports belonged to that vlan.

That is how i understand it works but i will have a full read of the document you linked to in case i missed something.

Jon

[kumarvi@hcl.com]

Hi Jon,

i also feel that it must be working that way but couldnt find any clear information about that. if it is working that way, then one case is  that the packet is for vlan 100, but there is an edge port exist in vlan 200 on core switch, then also he will need to decapsulate the packet? becoz then only it can identify if that packet is for vlan 100 or 200. that eventualy means, any switch which has a port in ANY VLAN or suppose an SVI in that vlan, then it will need to decapsulate the packet?

[Jon Marshall]

Yes, i think you are right in what you say.

I believe the design principle would be that your core switches wouldn't have any edge ports because by definition you only want edge ports for connectivity to the rest of the ethernet network.

The actual FabricPath core should really just be switches with FabricPath core ports connected to other FabricPath switches.

Jon

[kumarvi@hcl.com]

yes, but core switch will have SVIs for sure and then it means every packet will be decapsulated....this is not 100% convincing to me...i thought there must be something in FP header which should tell about vlan tag...but i could not find anything so may be that does not exist...so edge switch will have edge ports in every design...may be in different vlan or same, core ones will hv SVIs...so ultimately i feel every switch will gona remove FP header to read the payload which is actual ethernet frame... :-(