1 / 8

TRILL issue: VLANs

TRILL issue: VLANs. Radia Perlman Radia.Perlman@sun.com. How are VLANs annoying?. Bridge configuration can partition the cloud (“I’ll use ‘LAN’) if data is tagged with VLAN A, but not if tagged with VLAN B, for some values of A and B We don’t want to have multiple DRBs on the LAN

isanne
Download Presentation

TRILL issue: VLANs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TRILL issue: VLANs Radia Perlman Radia.Perlman@sun.com TRILL WG Vancouver

  2. How are VLANs annoying? • Bridge configuration can partition the cloud (“I’ll use ‘LAN’) if data is tagged with VLAN A, but not if tagged with VLAN B, for some values of A and B • We don’t want to have multiple DRBs on the LAN • You conclude you are DRB if you hear no other IS-IS Hellos, so bad if send Hellos on partitioned VLAN • So…what VLAN tag do you use when sending Hello? TRILL WG Vancouver

  3. Alternatives considered • Send (and receive) VLANs tagged with every supported VLAN • But it’s possible (and not that unlikely for core links with bridges) for a LAN to support all 4000 VLANs • That’s a lot of Hellos • Only send on one VLAN, no configuration, VLAN 1 chosen TRILL WG Vancouver

  4. Observations • As long as a non-DRB hears the DRB’s Hellos, no reason it needs to listen to, or send, IS-IS Hellos on other VLANs • Forwarding data (especially multicast) is a mess if every adjacency requires a different (outside) VLAN tag • So, each LAN needs to have a single VLAN tag for inter-RBridge communication TRILL WG Vancouver

  5. DRB dictates VLAN for LAN for inter-RBridge communication • Default: RBridges send all inter-RBridge communication with (outer header) VLAN tag=1 • RB1 may be configured to send Hellos on a set {S} of VLANs, with one (say VLAN X) marked as the inter-RBridge VLAN • If RB1 is the DRB, it sends Hellos on all in {S}, but specifies “use VLAN X” • Other RBridges send Hellos (and all other inter-RBridge traffic) with outer tag X • RB1 continues to send, and listen for, Hellos on all {S} • Note that {S} need not be all the VLANs RB1 supports TRILL WG Vancouver

  6. Load Splitting • The DRB need not be the en/decapsulator for all VLANs to/from that link • Instead, the DRB RB1 can appoint RB2 “appointed VLAN-x forwarder” • Then RB2 will be the one to forward VLAN x traffic to/from that link • Note: There is just a single DRB on the link • That is a change from previous version, which said the DRB was the data en/decapsulator, and had separate DRB elections per VLAN TRILL WG Vancouver

  7. In RB1’s LSP • I connect to VLAN x • Multicast router attached • Non-IP-derived multicast desired • Set of root bridges TRILL WG Vancouver

  8. Additional safety precautions • An RBridge RB1 which is VLAN-x forwarder listens to (common spanning tree) BPDUs, and reports the root bridge ID in RB1’s LSP, in the set of root bridges for VLAN x • RB2 does not decapsulate a VLAN x packet from ingress RB1 unless RB2 has RB1’s LSP, and none of RB1’s root bridges (for VLAN x) are the same as the link onto which RB2 is forwarding • Wait several Hello intervals, and synchronize LSP databases on your links, before encapsulating a packet off a link TRILL WG Vancouver

More Related