[rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Joe Touch
touch at ISI.EDU
Mon Dec 10 07:14:17 PST 2007
The system that handles this list processes email on a periodic basis.
Posts can be delayed up to 15 minutes. This is not uncommon for large
mail list servers - it avoids process thrashing for individual posts.
If anyone else has seen substantial delays, please let me know and I'll
look into it.
This message, FWIW, was posted at 07:14am PST; let's see when it shows up.
Joe (list admin)
Eric Gray wrote:
> By the way, there is definitely something wrong with the mailing
> list. The mail below was not received until 12 hours after it
> was sent. This is particularly annoying since I was getting ready
> to pack for my return trip when I sent it, but I was in an airplane
> at probably about 30,000 feet when people started receiving it.
>
> Is it possible to determine what is causing the posting delay?
>
> --
> Eric Gray
> Principal Engineer
> Ericsson
>
>> -----Original Message-----
>> From: rbridge-bounces at postel.org
>> [mailto:rbridge-bounces at postel.org] On Behalf Of Eric Gray
>> Sent: Thursday, December 06, 2007 9:53 PM
>> To: Anoop Ghanwani; Radia Perlman
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Orphaned endnodes with partitioned
>> VLANs on a cloud
>>
>> Anoop,
>>
>> The picture is a direct variation from the access-like
>> network picture you drew on a napkin in whatever restaurant
>> it was that we started talking about this in.
>>
>> The aggregation bridges - according to your description
>> would assign VIDs to aggregated subscribers. Let us ignore -
>> for a while (as we did during that discussion) that this is
>> very explicitly not in scope for the chartered objective and
>> pretend that this type of deployment is common (or, at least,
>> not unheard of) in a large enterprise network.
>>
>> As I was then, I am still prepared to stipulate that may
>> be the case - at least somewhere in the universe.
>>
>> In your example, the aggregation bridges would have many
>> (as in a thousand or more) down-link interfaces which they are
>> aggregating onto a much smaller number of up-link interfaces.
>> Your claim at the time was that most such deployments wouldn't
>> trunk (Q-in-Q) these VIDs - hence all of them would be visible
>> to the RBridges (RB-1 and RB-2 in my example). This was the
>> basis for your claim that per-VLAN peering of IS-IS instances
>> could produce serious scalability issues.
>>
>> This is a not-unreasonable claim to make and a hard claim
>> to argue against, especially given the already deep level of
>> suspended disbelief involved at this point in our discussion.
>>
>> Now, you propose that I should label the interfaces I've
>> adopted from your example with VLAN IDs? Are you sadistic, or
>> just having a mean moment? :-)
>>
>> Frankly, given the nature of the problem, I can't imagine
>> why you really need to have that information. What is important
>> is that there are two VLANs (A and B) that are being routed in
>> some special way (shown in the diagram) and an arbitrary number
>> of VLANs (but necessarily at least 1 and not more than 4092) of
>> other VLANs that are also present in the network (as shown - and
>> described - in my diagram).
>>
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson
>>
>>> -----Original Message-----
>>> From: Anoop Ghanwani [mailto:anoop at brocade.com]
>>> Sent: Thursday, December 06, 2007 9:33 PM
>>> To: Eric Gray; Radia Perlman
>>> Cc: Developing a hybrid router/bridge.
>>> Subject: RE: [rbridge] Orphaned endnodes with partitioned
>>> VLANs on a cloud
>>> Importance: High
>>>
>>>
>>> (There was some problem with the outgoing
>>> alias of my email and as a result my posts
>>> haven't been making it to the list; just
>>> to private parties listed in the recipient
>>> list. Hopefully that should be fixed at
>>> the time I send this message.)
>>>
>>> Hi Eric,
>>>
>>> I can't fully remember the example. Would it
>>> be possible for you to put the VLAN memberships
>>> on the various ports in your figure? That would
>>> help me understand the picture better.
>>> (I know I may be asking for much but please
>>> be patient with me because I'd like to address
>>> all your concerns.)
>>>
>>> It is possible to misconfigure bridged LANs
>>> so that VLANs end up getting partitioned.
>>> The automated way to avoid that is using
>>> MVRP.
>>>
>>> Anoop
>>>
>>>> -----Original Message-----
>>>> From: Eric Gray [mailto:eric.gray at ericsson.com]
>>>> Sent: Wednesday, December 05, 2007 2:25 PM
>>>> To: Anoop Ghanwani; Radia Perlman
>>>> Cc: Developing a hybrid router/bridge.
>>>> Subject: RE: [rbridge] Orphaned endnodes with partitioned
>>>> VLANs on a cloud
>>>>
>>>> Anoop/Radia,
>>>>
>>>> This is not exactly the note on which we left off in
>>>> the off-line discussion. As I recall (isn't E-Mail great!),
>>>> I replied to this with the following:
>>>>
>>>> ============================================================
>>>> If the RBridges were inserted to replace 802.1Q
>>>> bridges, and each was configured as I've described for access
>>>> to both VLAN A and B, then the bridge failure I described
>>>> would simply result in a different spanning tree for VLAN A.
>>>> VLAN A would not be broken, it would simply be (potentially)
>>>> less optimal.
>>>> ============================================================
>>>>
>>>> This was specifically in response to your comment (to
>>>> the effect that this wouldn't have worked in an 802.1Q LAN -
>>>> so it would have been a misconfiguration there as well).
>>>>
>>>> In response to the above observation you said that you
>>>> agreed that this would not have been a misconfiguration error
>>>> in that case. Aactually, what you said exactly was "Yes, you
>>>> are right."
>>>>
>>>> More on this in a separate mail message response to Radia...
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Eric Gray
>>>> Principal Engineer
>>>> Ericsson
>>>>
>>>>> -----Original Message-----
>>>>> From: Anoop Ghanwani [mailto:aghanwan at brocade.com]
>>>>> Sent: Tuesday, December 04, 2007 11:27 PM
>>>>> To: Radia Perlman; Eric Gray
>>>>> Cc: Developing a hybrid router/bridge.
>>>>> Subject: RE: [rbridge] Orphaned endnodes with partitioned
>>>> VLANs on a
>>>>> cloud
>>>>> Importance: High
>>>>>
>>>>>
>>>>> Radia,
>>>>>
>>>>> This is what I told Eric during the offline discussion as
>>>> well - that
>>>>> this is a misconfiguration and as long as bad things aren't
>>>> happening,
>>>>> it's up to the administrator to configure things so that
>>> they work
>>>>> correctly when such failures happen.
>>>>>
>>>>> It is no worse than what can happen in a misconfigured bridged
>>>>> network.
>>>>>
>>>>> Anoop
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: rbridge-bounces at postel.org
>>>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
>>>>>> Sent: Tuesday, December 04, 2007 7:15 PM
>>>>>> To: Eric Gray
>>>>>> Cc: Developing a hybrid router/bridge.
>>>>>> Subject: [rbridge] Orphaned endnodes with partitioned VLANs
>>>>> on a cloud
>>>>>> Putting in a subject line since Eric didn't.
>>>>>>
>>>>>> To restate Eric's concern -- it is possible that VLAN A
>>> might be
>>>>>> partitioned on a link, and since the DRB selects only
>> a single
>>>>>> VLAN-A-forwarder, some VLAN A endnodes on the cloud might get
>>>>>> orphaned (since they are on the other side of the
>>>> partition from the
>>>>>> appointed VLAN A forwarder on the link).
>>>>>>
>>>>>> And that is correct.
>>>>>>
>>>>>> So, what is the alternative? Everything is an engineering
>>>> tradeoff.
>>>>>> We could run DRB elections on every possible VLAN, and with a
>>>>>> partitioned VLAN, wind up with multiple DRBs for that VLAN.
>>>>>> If there were n VLANs, we'd wind up with n DRBs (one
>>> per VLAN), n
>>>>>> pseudonodes, n times as many Hello messages, etc.
>>>>>>
>>>>>> We chose to consider a partiitoned VLAN, caused by bridges
>>>>>> configured to not pass data traffic for a particular
>> VLAN, as a
>>>>>> misonfiguration. This can happen with bridges anyway, if
>>>> you mark a
>>>>>> bunch of your potential through links as not being
>>>> allowed for VLAN
>>>>>> A transit. The solution in the current spec is low
>>>> overhead (at most
>>>>>> one pseudonode per link, one Hello per RBridge except for
>>>> the DRB)
>>>>>> and relatively simple.
>>>>>> Hopefully eventually more bridges will be replaced by
>>>> RBridges and
>>>>>> this sort of thing won't happen.
>>>>>>
>>>>>> Radia
>>>>>>
>>>>>>
>>>>>> Eric Gray wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> Here is the problem that occurs when VLAN state is
>>>>>> inferred for one
>>>>>>> VLAN from connectivity provided by another. This is
>>> a general
>>>>>>> problem, but has specific applicability to the
>> current set of
>>>>>>> assumptions used in the protocol specification. This
>>>> came up in
>>>>>>> off-line discussions with Anoop Ghanwani (and others)
>>>> at an IEEE
>>>>>>> meeting a couple of weeks ago.
>>>>>>>
>>>>>>> A key thing to understand in looking at this
>>>> problem is it is a
>>>>>>> comparison between how a network works with 802.1Q
>>>>> bridges and the
>>>>>>> same network after some 802.1Q bridges have been
>>> replaced with
>>>>>>> RBridges. The example shows a partial RBridge deployment
>>>>>> and this is
>>>>>>> compared with how it will have worked with 802.1Q bridges
>>>>> where the
>>>>>>> example shows RBridges (i.e. - it is an after- the-fact
>>>>>> comparison of
>>>>>>> L2 forwarding functionality).
>>>>>>>
>>>>>>> The network looks like this (initially):
>>>>>>>
>>>>>>> \\\\|//// \\\\\|||///// \\\|///
>>>>>>> __|__ __|__ __|__
>>>>>>> | B-1 | | B-2 | | B-3 |
>>>>>>> |_____| |_____| |_____|
>>>>>>> | \ / \_____ / |
>>>>>>> | \_____/ | B-5 | |
>>>>>>> | | B-4 | |_____| |
>>>>>>> | |_____| | |
>>>>>>> __|__ \ | |
>>>>>>> | B-6 |_______\ _______| __|__
>>>>>>> |_____| \___________| B-7 |
>>>>>>> | |_____|
>>>>>>> | |
>>>>>>> __|___ __|___
>>>>>>> | RB-1 | | RB-2 |
>>>>>>> |______| |______|
>>>>>>> \ _ /
>>>>>>> \__ __( )___ _/
>>>>>>> \_( Core )_/
>>>>>>> (_ RBridge _)
>>>>>>> (_ Cloud _)
>>>>>>> (_ _)
>>>>>>> (_)
>>>>>>>
>>>>>>> In this figure, B-1, B-2 and B-3 are
>>>> aggregation bridges with
>>>>>>> multiple (lots and lots) of VIDs.
>>>>>>>
>>>>>>> B-4 is a special purpose bridge used for VLAN-A only,
>>>>>> and B-5 is a
>>>>>>> special purpose bridge used for VLAN-B only.
>>>>>>>
>>>>>>> All remaining bridges are configured to participate in
>>>>>> VLAN-A, VLAN-B
>>>>>>> and an arbitrary set of zero or more other VLANs. Since
>>>>>> B-4 and B-5
>>>>>>> are configured for specific VLANs only, the ports on
>>>>> their adjacent
>>>>>>> bridging peers are configured only for those VLANs.
>>>>>>>
>>>>>>> To be clear, the links between B-4 and B-7, and between
>>>>>> B-6 and B-5
>>>>>>> are not connected (they merely overlap in the drawing).
>>>>>>>
>>>>>>> In this network, RB-1 and RB-2 are both RBridges and
>>>>>> both have access
>>>>>>> to VLAN A and VLAN B and each other (via both VLAN
>> A and VLAN
>>>>>>> B) - as well as the same arbitrary set of zero or more
>>>>>> VLANs that any
>>>>>>> of the other bridges in the drawing have. However, the two
>>>>>> RBridges
>>>>>>> use another VLAN - say VLAN C - to exchange hellos. Under
>>>>>> the normal
>>>>>>> operating conditions intended, this works fine and RB-1 and
>>>>>> RB-2 may
>>>>>>> separately be elected DRB for either of VLAN A or VLAN B.
>>>>>>>
>>>>>>> If bridge B-4 fails, then VLAN A would be
>>>> segmented, at least
>>>>>>> temporarily. Hellos continue to work, however, so the 2
>>>>>> RBridges do
>>>>>>> not discover the partition and the DRB election remains
>>>> unchanged.
>>>>>>> In this case, part of the VLAN is orphaned - particularly
>>>>> from the
>>>>>>> perspective of any locally attached end-stations.
>>>>>>>
>>>>>>> However, this is not acceptable behavior. No
>>>>>> misconfiguration exists
>>>>>>> and the ideal (and reasonably expected) behavior would
>>>> be for the
>>>>>>> RBridges to discover the partition and redo the DRB
>>>>>> election - making
>>>>>>> RB-1 the DRB for one partition and RB-2 the DRB for
>> the other
>>>>>>> partition.
>>>>>>>
>>>>>>> If (when) RB-1 and RB-2 were 802.1Q bridges, using MSTP
>>>>>> for multiple
>>>>>>> VLANs (in particular, for VLAN A and B), this failure
>>> will have
>>>>>>> resulted in re-running (M)STP for the affected VLAN
>>>>>> connectivity and
>>>>>>> the segmentation (partitioning) would be healed. In the
>>>>>> same way, if
>>>>>>> the status of VLAN's A and B were derived directly from
>>>>>> messages that
>>>>>>> use VLAN A and VLAN B (as opposed to using VLAN C), this
>>>>>> same robust
>>>>>>> behavior would occur.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Eric Gray
>>>>>>> Principal Engineer
>>>>>>> Ericsson
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> rbridge mailing list
>>>>>>> rbridge at postel.org
>>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>>
>>>>>> _______________________________________________
>>>>>> rbridge mailing list
>>>>>> rbridge at postel.org
>>>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071210/6b0c24b8/signature-0001.bin
More information about the rbridge
mailing list