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. I thought I had a better handle on TRILL and FabricPath than I really did. 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

Just a note first: The points below are all relevant to unicast traffic within the fabric. I'm going to leave multicast and broadcast alone for now.

TRILL

RFC 6325 clearly outlines the methods in which a TRILL RBridge can learn MAC addresses. Section 4.8.1 lists (5) methods of which only (2) are required in every RBridge:

  1. Through observation of ethernet frames received on native ports (learn source MAC address and ingress port)
  2. Through decapsulation of TRILL frames received from other RBridges (learn source MAC of encapsulated frame and source RBridge nickname)

Note that both of these methods are happening at the data plane. This was the source of my misunderstanding: I thought the control plane was responsible for advertising the learned MAC addresses to other RBridges. Not so. MACs are learned locally on each RBridge.

Well, that's mostly true. One of the other (3) methods for learning MACs is something called the End Station Address Distribution Information (ESADI) Protocol. ESADI is an optional method for RBridges to advertise and learn remote 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. These advertisements allow the receiving RBridge to determine the VLAN and ingress RBridge nickname of one or more MAC addresses. 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).

Similar to Per-VLAN Spanning Tree, an ESADI instance is initialized on a per-VLAN basis. 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). 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.

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. For anyone that's worked in a service provider network, it's kind of like the IGP advertising your loopback IPs throughout the network. 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.

Just as important as learning MACs is forgetting them. 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. When a frame is seen coming from a MAC, the TTL is reset. This is the same way a native ethernet bridging table works. 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. If an ESADI neighbor times out then the learned MACs are also flushed.

FabricPath

While FabricPath has a basis in TRILL, the method it uses to learn MAC addresses is quite different. As I've written about before, FabricPath uses something called "conversational learning". Put simply, this means a FP switch will not learn the source MAC unless it already has the destination MAC in its forwarding table. The idea here is that a switch doesn't have to learn MAC addresses from across the fabric unless there is a reasonable expectation that the switch will have to forward some frames back to that MAC. If a switch receives a broadcast frame on a FP port, why would it need to learn the source MAC of that frame when odds are that it will not have to send anything back to that source? Conversational learning should allow the forwarding tables on the FP switches to scale further since they only have to store MAC addresses of interest.

Like TRILL, FP switches unconditionally learn source MACs on classic ethernet ports. Also like TRILL, the Layer 2 IS-IS run within the fabric is only used to advertise the FabricPath SwitchIDs and path information and does not carry MAC information.

Unlike TRILL, FabricPath does not have a control plane protocol for advertising MAC addresses between switches. The reason for this is something I already mentioned: FP switches do not learn MAC addresses that they are not interested in. A protocol for advertising MACs would break this principle.

Lastly, FP also ages out MAC addresses using a TTL value.


Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Cisco Systems.