why fabricpath spine switches doesn't keep all mac addresses?

[gavin han]

why fabricpath spine switches doesn't keep all mac addresses? since spine switches don't keep all host mac address, how to trace host from core switch(where SVI for that host resides) to the Leaf switch where host is connected?

assume here is the topology:

Core switch(hosts SVI)-----spine switch-----leaf switch (actual host is connected here)

[sean_evershed]

For the spine switches reducing the MAC addresses improves scalability in the DC.

See below a link on tracing a host within a FabricPath domain.

https://edennington.wordpress.com/2014/11/05/find-the-port-a-host-is-connected-to-in-a-fabricpath-fabric/

[Steve Fuller]

In addition to what Sean has already provided, the reason the spine switches don't learn the MAC addresses of the end hosts is because of the conversational learning that is part of the operation of FabricPath.

The idea of conversational learning is that a switch will only learn a MAC address if there is an active "conversation" to a host connected to an edge port (CE port) of that switch. In this way a conversation between host A on leaf switch 1 and host B on leaf switch 2 will only populate the CAM tables on switch 1 and 2.

As FabricPath uses a MAC-in-MAC encapsulation, if the traffic between host A on switch 1 and host B on switch 2 goes via a spine switch, the MAC of host A and host B are not seen by the spine.

As Sean stated, the purpose of this is to prevent unneccesary MAC address table consumption, and so allow a FabricPath environment to scale.

There's some discussion of conversational learning in the Cisco FabricPath Design Guide.

Regards