Whether they run STP or not, the RBridges have to ensure there’s a
single point of contact between a VLAN in the STP domain and the
backbone, otherwise all the flooded packets would enter the backbone
through multiple entry points, resulting in duplicate packets received
by the remote hosts (which might break some odd fainthearted protocols
running directly on top of L2). One of the RBridges therefore becomes an
appointed forwarder for an edge VLAN.
The right-hand
part of the figure illustrates the appointed forwarder concept: the
RBridges don’t participate in the STP, none of their edge ports are
blocked, but only one of the RBridges acts as a forwarder between the
edge STP domain and the TRILL backbone (marked with A), all other
RBridges ignore packets received through that VLAN (marked with B).
Having multiple RBridges active on a LAN segment could be an issue if
they all start forwarding traffic over the TRILL network, as this would
cause both traffic duplication and also confusion in terms of the
appropriate return path with which to populate the MAC mapping tables.
Consequently, RBridges on a VLAN see each other and elect a Designated
RBridge (DRB) for the segment, which in turn normally becomes the Appointed Forwarder
that is exclusively responsible for sending/receiving frames on that
shared segment while all other RBridges effectively are in a kind of standby mode.
Technically (i.e. in the protocol specifications) it is possible for a
DRB to make other RBridges Appointed Forwarders, but I am not aware of
this being implemented yet, and the likelihood is that the DRB will do
the AF job itself.
If there are multiple RBridges on the same link, together with end
nodes, it is important that only one of them encapsulate a packet from
an end node. As illustrated in Figure 9, if both R1 and R2 were to
encapsulate a unicast packet from S, two copies would be delivered to
the destination. However, if S were to transmit a multidestination
packet (such as a multicast, or an unknown destination), then the copy
that R1 encapsulates would be forwarded through the campus, received by
R2 (which likely would not know that the packet originated on its port
to R1), and R2 would decapsulate it. Then R1 would see a native packet
from S, exactly as the first copy, and again encapsulate it and send it
into the campus.
The hop count in the TRILL header would not solve this loop, because
the hop count does not exist while the packet is not encapsulated with a
TRILL header.IS-IS has an election protocol in which one of the RBridges is elected as the Designated RBridge (DRB). In order to allow load-splitting the task of encapsulating and decapsulating traffic, the DRB may delegate the job of encapsulation/decapsulation based on VLAN. In other words, if R1 is DRB, R1 can delegate to R2 the task of encapsulating/decapsulating traffic for a set of VLANs, say VLANs x, y, and z, and delegate to R3 a different set of VLANs, and R1 might handle the rest.
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-3/143_trill.html
By the way, in this blog the author mentions the concept of Designated VLANs. I excerpt from it as follows:
Some background points that will help to explain things:
1) When RBridges see other RBridges on a multi-access link, they will determine between them which is to be the Designated RBridge (DRB). I should note that this on Point-to-Point (P2P) links, no DRB is elected.
2) When an RBridge receives a native (i.e. non-TRILL) frame that it’s going to forward as TRILL-encapsulated, it first adds a 802.1q header to the frame so that the origin VLAN will be known when the frame is decapsulated at the egress RBridge. Thus when the frame format shows the “original Ethernet frame”, it’s really the original frame plus an 802.1q header. You could, if you wanted to make the Shortest Path Bridging folks laugh quietly, liken this a little to QinQ – you’re sending TRILL-encapsulated frames sourced from multiple VLANS over a single VLAN, and inside the TRILL data frame the 802.1q header in the “original” packet means it can be ‘demuxed’ correctly at the other end. Ugh, horrible analogy
3) The reality is that links between RBridges are unlikely to be carrying a single VLAN, but rather they’re likely to be 802.1q trunk links with many VLANs on them. You don’t want to send out TRILL-IS-IS Hellos and run an instance of IS-IS on every VLAN, as that wouldn’t be scalable. It would also be pointless, as TRILL encapsulated frames are not forwarded on the VLAN on which the frame ingressed; rather the TRILL data frames are forwarded on a common VLAN – the Designated VLAN.
So, if we put all that together:
- On any given link, there must be a single VLAN that the RBridges agree to use for the exchange of TRILL-IS-IS and TRILL data.
- On a multi-access link, the DRB dictates what the Designated VLAN will be; other (non-DRB) RBridges on that link MUST use whatever VLAN the DRB dictates.
- On a point-to-point link, the RBridges use tie-break mechanisms to determine whose Designated VLAN should reign supreme (since there’s no DRB)
- The best design obviously would be that you configure all RBridges to prefer the SAME Designated VLAN, so that if the DRB changes, you don’t change Designated VLAN as well.
- You also need to ensure that all RBridges on a link have connectivity to that Designated VLAN. Common sense, really.
So in summary, the Designated VLAN is the VLAN where TRILL-IS-IS really runs, and over which TRILL data forwarding between RBridges occurs. Make sure all RBridges on a link have the same preferred Designated VLAN configured, and ensure they all have connectivity to that VLAN.
http://lamejournal.com/2011/05/16/layer-2-routing-sort-of-and-trill/
