Subject: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud (Example 1)

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 18:20:23 -0500

Suppose we have a simple network, where A, B, and C are all connected to
a single link, a broadcast of some type:

A--+
   |
   +--B
   |
C--+

Now, assume all three are members of VLANs 1, 2, and 3 on this link. All
three are properly configured to use VLAN 1 as the rbridge vlans. A is
designated as the DRB.

Now, things are running along fine, but, for some reason, A
malfunctions, or some such, and can no longer send multicast packets on
VLAN 1. The result is that B and C detect they've lost their connection
to A, but they won't elect a new DRB at all. Why? Because they are still
receiving hello's with A claiming to be the DRB, and with A's original
priority and ID, on the other two VLANs.

Now the link is completely out of the SPF tree, and not used at
all--because of a partial failure on the DRB. This is broken, and
unexpected behavior.

The IS-IS hellos are there to find per link bidirectional reachability.
When you take that away, and assume reachability on one logical link
because you have reachability on another logical link, you wind up in a
mess that's harder to fix than the original problem you were trying to fix.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 18:28:24 -0500

Suppose you have a simple network where A, B, and C are on the same
broadcast segment, but there are several possible VLANs on which rbridge
traffic could run:

A--+
   |
   +--B
   |
C--+

Now, A is able to talk on VLANs 1, 2, and 3, while B and C are able to
talk on VLANs 2, 3, and 4. The "correct" vlan for rbridge traffic to
flow across is 2, which A and C are configured for. B, however, is
configured to pass rbridge traffic across VLAN 4, which is a
misconfiguration.

Suppose C is chosen as the DRB in this case. It advertises VLAN 2 as the
correct rbridge VLAN, and hence, B's misconfiguration is "covered up."
The system works as designed. However, when C fails, B is chosen as the
DRB on this link. Since B is misconfigured, the link now falls off the
network.... Hmmm.... This isn't what we were after, was it? If there is
a large number of routers on the link, if the rbridge which happens to
be elected DRB is misconfigured, the entire link is tossed for transit
use, rather than just taking those misconfigured rbridges off the link.
That's an unexpected, and bad, side effect.

The problem here is that you're assuming that while all the other nodes
might be misconfigured, the node selected as the DRB won't be
misconfigured. That's a rather odd assumption--especially since the DRB
is elected, not manually configured. Most folks have to go look when you
ask them which router on their network is the DIS, I don't expect it
will be much different with rbridges.

There's at least one more failure mode in this scheme, I'll try and
cover it later.

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 18:55:58 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Thursday, December 06, 2007 6:20 PM
> To: [email-masked]
> Subject: [rbridge] Orphaned endnodes with partitioned VLANs 
> on a cloud(Example 1)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Suppose we have a simple network, where A, B, and C are all 
> connected to a single link, a broadcast of some type:
> 
> A--+
>    |
>    +--B
>    |
> C--+
> 
> Now, assume all three are members of VLANs 1, 2, and 3 on 
> this link. All three are properly configured to use VLAN 1 as 
> the rbridge vlans. A is designated as the DRB.
> 
> malfunctions, or some such, and can no longer send multicast 
> packets on VLAN 1. The result is that B and C detect they've 
> lost their connection to A, but they won't elect a new DRB at 
> all. Why? Because they are still receiving hello's with A 
> claiming to be the DRB, and with A's original priority and 
> ID, on the other two VLANs.

I don't understand what kind of failure would prevent
sending of multicast packets on VLAN 1.  And if a failure
should happen, the correct thing is for the network
operator to fix the failure. 

> Now the link is completely out of the SPF tree, and not used 
> at all--because of a partial failure on the DRB. This is 
> broken, and unexpected behavior.

 I'm almost certain I will find
scenarios that break even if the hellos are sent per VLAN
(once I see that proposal).  One of the things oft mentioned
on this list is partial connectivity on different VLANs
and the handling of multicast traffic when that happens.
There has been no good solution to that problem.

> When you take that away, and assume reachability on one 
> logical link because you have reachability on another logical 
> link, you wind up in a mess that's harder to fix than the 
> original problem you were trying to fix.

I totally understand the need for this, but we also
have to concern ourselves with scalability, or nobody
is going to be able to build this technology at
a price that would make sense to deploy it.

Anoop

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:15:09 -0500

> operator to fix the failure. 

All routing protocols guard against this failure mode, because it is
known to happen. The correct action should be for the protocol to be
designed not to have unexpected state changes, and not to try and mend a
misconfiguration in the network. Full failure is always preferred over
unexpected secondary states.

> (once I see that proposal).  

It's the proposal this WG started with, and which was abandoned.

> One of the things oft mentioned

If there is partial connectivity on multiple VLANs, connectivity fails,
and rbridges shouldn't try and "work around" it in any way. Rbridges
should expect a layer two interconnect that connects them into the
rbridge cloud. Rbridges should not *care* what the underlying medium is,
how it's designed, or what it's doing, as long as that connectivity is
there.

> a price that would make sense to deploy it.

Can you please back this up with something concrete? Can you give me a
price point? I hear a lot of numbers thrown around.

IMHO, the correct course of action is to take the simple path. If, when
these things are deployed, it's found that they won't scale, and they
can't scale to the numbers people want, and protocol changes are
required to make them scale, or that protocol changes are required to
make them work on "broken underlying Ethernet networks," then we can
address those problems then.

Until then, let's focus on the task at hand--emulating 802.1q over
what's assumed to be reliable and well configured underlying media.

:-)

Russ

- --