When ESADI is in use, it's up to the originating RBridge to signal when it no longer sees a MAC so its neighbors can remove it from their tables. This is the same way a native ethernet bridging table works. When a frame is seen coming from a MAC, the TTL is reset. As I alluded to above, in the absence of ESADI, TRILL relies on a Time To Live value associated with each learned MAC address to know when each MAC should be flushed. Just as important as learning MACs is forgetting them. Your BGP routes (which in the TRILL network I will liken to the MAC addresses advertised through ESADI) then leverage the IGP routes for end-to-end reachability. For anyone that's worked in a service provider network, it's kind of like the IGP advertising your loopback IPs throughout the network. So then what role does IS-IS play? IS-IS is used to build the core topology of the network and advertise the RBridge nicknames and path information amongst all the RBridges. Because of this selective advertisement, ESADI does not leverage the TRILL IS-IS protocol as the IS-IS LSPs are unconditionally sent and received by all RBridges in the domain. An RBridge that is running ESADI will advertise the VLAN(s) that it wishes to learn remote MACs for and will only send its locally learned MACs to those RBridges which have also expressed an interest in the same VLAN(s). Similar to Per-VLAN Spanning Tree, an ESADI instance is initialized on a per-VLAN basis. By using ESADI in a TRILL network, blackholing of traffic can be avoided when a source MAC address moves between RBridges (without ESADI, TRILL relies on a timer expiring to flush a learned MAC just like in native ethernet). These advertisements allow the receiving RBridge to determine the VLAN and ingress RBridge nickname of one or more MAC addresses. In the same way that a routing protocol advertises the local networks to remote neighbors, ESADI advertises MAC address information to other RBridges. ESADI is an optional method for RBridges to advertise and learn remote MAC addresses. One of the other (3) methods for learning MACs is something called the End Station Address Distribution Information ( ESADI) Protocol. MACs are learned locally on each RBridge. This was the source of my misunderstanding: I thought the control plane was responsible for advertising the learned MAC addresses to other RBridges.

Note that both of these methods are happening at the data plane. Through decapsulation of TRILL frames received from other RBridges (learn source MAC of encapsulated frame and source RBridge nickname).Through observation of ethernet frames received on native ports (learn source MAC address and ingress port).Section 4.8.1 lists (5) methods of which only (2) are required in every RBridge: RFC 6325 clearly outlines the methods in which a TRILL RBridge can learn MAC addresses. I'm going to leave multicast and broadcast alone for now. Just a note first: The points below are all relevant to unicast traffic within the fabric. Since I retain things far better when I write them down, I'm going to blog the differences between TRILL and FabricPath when it comes to address learning and what role the control plane plays in building the network topology Preface ⌗ I thought I had a better handle on TRILL and FabricPath than I really did. Do you ever find yourself in a conversation with someone where you attempt to explain a concept in detail and you realize that you don't know that concept at the level of detail that you thought you did? That happened to me recently.

Cisco fabricpath mac address learning