[rbridge] it's time to summarize things
touch at ISI.EDU
Thu Dec 15 09:11:21 PST 2005
Gray, Eric wrote:
> I've addressed this issue before, just as you have
> raised it before.
> Assuming that "external nodes" below refers to the
> portions of the L2 broadcast domain that are topologically
> outside of the RBridge campus, the RBridge campus actually
> looks to external nodes as if it is a (possibly largish)
> collection of L2 frame sources and sinks.
For internal traffic, sure. For ingress/egress traffic, this would need
to hijack ARP to work.
To external nodes, the rbridge MUST act like a transit, not a source or
> In other words, from the perspective of any existing
> technology, external nodes (those that are outside of the
> RBridge campus) see what looks like a shared ethernet link
> with (possibly very many) directly attached L2 sources and
> On the other hand, non-RBridge nodes that make up a
> part of the infrastructure within the campus see only the
> RBridges themselves (along with possibly locally attached
> L2 sources and sinks) as L2 sources and sinks.
> We have to be careful about understanding this. For
> one thing, we have to realize that - within this common L2
> broadcast domain - there can be no "back-routes" by which
> an external node can become confused in filtering database
> learning as a result of "hearing" the same source MAC from
> more than one direction. But this can be managed - mostly
> because "external" (outside the RBridge campus) back-routes
> cannot exist (any such back-route indicates that RBridges
> are connected over it and it is therefore not ouside of the
> RBridge campus).
> Inside the RBridge campus, ambiguity is resolved by
> IS-IS routing, and by well-made RBridge implementations.
> --> -----Original Message-----
> --> From: rbridge-bounces at postel.org
> --> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
> --> Sent: Thursday, December 15, 2005 11:03 AM
> --> To: Radia.Perlman at Sun.COM; Developing a hybrid router/bridge.
> --> Subject: Re: [rbridge] it's time to summarize things
> --> _______________________________________________
> --> rbridge mailing list
> --> rbridge at postel.org
> --> http://www.postel.org/mailman/listinfo/rbridge
> Earlier, you wrote (paraphrased for context):
>> An RBridge campus should look like a single broadcast domain
>> to layer 3 devices, but that doesn't mean an RBridge should
>> participate in spanning tree, any more than that if it had
>> two token ring interfaces, that it should pass the token from
>> one interface to another. (though hopefully this analogy won't
>> confuse people, since a station on a token ring *does* have to
>> pass the token within that ring...
>> however an Ethernet endnode does NOT have to participate
>> in spanning tree (nor should it), and likewise, an RBridge
>> does not have to participate in spanning tree.
> That logic is makes as much (or as little) sense as an rbridge
> correlating to a router. Routers and hosts on L2 are L2 sources
> and L2 sinks. To the existing L2, external traffic transits the
> rbridge; the rbridge sources and sinks no traffic to these
> external nodes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051215/eb849e85/signature.bin
More information about the rbridge