[rbridge] Proposed resolution of DRB election/MTU testing

Ali Sajassi (sajassi) sajassi at cisco.com
Fri May 1 10:20:19 PDT 2009


James,

If we need to send "protective hello" on each VLAN in order to monitor
the connectivity of that VLAN over .1Q bridged network as described in
section 4.2.4.2, then so be it (although I think we can do it more
efficiently as I will talk in next paragraph). However, this is not the
point that I am driving at. If you need to have two types of TRILL
hellos messages (e.g., neighbor discovery vs.. protective), then that's
O.K. My point is that we should be able to use the same IS-IS hello
message with MTU padding for both because I don't think the frame size
can exceed 1522 bytes !! (please refer to my email on scenarios for
TRILL access/trunk ports regarding why it cannot exceed 1522).

Now regarding more efficient mechanism for sending TRILL hellos. Two
cases to consider:

1) .1Q network is running STP/RSTP: In this case, there is only a single
active topology in the .1Q network and we can have a single VLAN that
covers the entire active topology (e.g., VLAN 1). Then just monitoring
this VLAN will be sufficient - e.g., if this VLAN is partitioned, then
the network is partitioned and all the other VLANs are partitioned. In
other words, in this scenario, there is no need to send protective hello
messages (per VLAN).

2) .1Q network is running MSTP: In this case, there are several active
topologies (one per MSTI). So, in this case, we can just have a single
VLAN per MSTI that covers the entire active topology for that MSTI. If
there are 2 or 3 MSTIs for 4K VLANs (which is typical), then you only
need to monitor 2 or 3 VLANs rather than 4K VLANs. We should know the
number of MSTIs because we have this info from BPDU in root-collision
detection procedure.

Cheers,
Ali


 

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at Sun.COM] 
> Sent: Friday, May 01, 2009 7:50 AM
> To: Ali Sajassi (sajassi)
> Cc: Radia Perlman; rbridge at postel.org
> Subject: Re: [rbridge] Proposed resolution of DRB election/MTU testing
> 
> Ali Sajassi (sajassi) writes:
> > Regarding your comment that loop can happen as the result 
> of one-way 
> > connectivity via partitioned VLAN, AFAIK DRB selection is done over 
> > designated VLAN and if that VLAN is partitioned, then the bridged 
> > network is partitioned because this VLAN is expected to be 
> reachable 
> > via all the access ports. And if the bridged network is 
> partitioned, 
> > the it is O.K. to have a DRB for each of the partitions. 
> So, where is the loop?
> 
> Suppose A and B are RBridges that are communicating over VLAN 
> 1 as the primary VLAN.  They're forwarding for VLANs 2, 3, 
> and 4 as well.
> 
> Now suppose that VLAN 1 becomes partitioned.  Both can now become DRB.
> They are still forwarding for those other VLANs, though, and 
> this potentially means we have two forwarders on the same 
> VLAN, which leads to fatal forwarding loops.
> 
> It's a problem that's specific to TRILL, because of the L2 
> work that it does.  It's not something that would happen with 
> an L3 protocol.
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 



More information about the rbridge mailing list