[rbridge] Shared VLAN learning: What is it and why should we care?

[Caitlin Bestler]

Eric Gray wrote:
> Radia,
> 
> 	Let me try to re-state your explanation to see if I understand
it...
> 
> 	You believe that the problem that shared VLAN learning
> is used to solve is conservation of IP addresses used in a
> single IP subnet, and that it is necessary to use shared VLAN
> learning to keep routers (in the subnet) from having to
> re-learn MAC+IP associations across a set of VLANs in that
> same IP subnet, is that correct?
> 

It's a more fundamental problem that re-learning, and the goal
could more properly be stated as avoiding the neccesity of 
creating distinct subnets. Sharing the IP subnet does conserve
IP Addresses, but more importantly it conserves the effort of
dividing the IP addresses up into VLAN specific portions, and
of updating DNS entries when a host migrates to a new VLAN, etc.

There was actually a very good summary of the usage of such
a feature on a BSD list in 2005:

http://lists.freebsd.org/pipermail/freebsd-net/2005-November/009064.html

Different switches having different VID/FID mappings is confusing,
but ultimately it isn't that bad, especially since global MAC addresses
do tend to be unique within a campus even when they are being assigned
by decidedly non-global techniques.

But the associated ARP Proxy has a totally different problem.
Specifically, the scenario is where the *same* IP subnet is
used for two or more VLANs. Or to be more precise, what is
to *appear* to be one IP subnet to the outside world is
actually two or more VLAN divided subnets, and the assignment
of specific IP addresses to specific VLANs is dynamically
learned rather than administered.

So if RBridges scope the MAC/IP learning to a VID
specific instance then two RBridges can have
contradictory information about the meaning of
an IP address.

In fact, a single RBridge could have contradictory
information in two VID-specific instances about the
same IP address.

This creates a severe problem for the router (existing
router, mind you) that is the ingress point to this
shared IP subnet. When it has a received IP datagram
to x.y.z.1, and no entry in its ARP table, it will
have no idea which VLAN the datagram belongs to.
Therefore it will ARP on all VLANs to see where
it goes, and it expects to get at most one reply
because an IP address is only supposed to be
assigned to a single host. Not that the router
will get upset or have a fault. It will more
likely assume to all replies are redundant and
therefore it can always just use the most recent
one without bothering to remember any prior ARP
responses.

So, when a host migrates from VLAN A to VLAN B,
we have a problem if the RBridge on VLAN B does
not share its discovery with the RBridge on VLAN
A (and the two are part of a group / share the
same IP subnet). If the discovery is shared, then
the RBridge on VLAN A will delete its entry for
the IP address, and when the Router next ARPs
it will only get a response from VLAN B.

So while the groups that Radia describes will
solve the problem, the fundamental justification
for the solution arises when the semantics of
an IP subnet span multiple VIDs. When the
IP Address retained for Proxy ARP purposes
has a wider scope that the VLAN dissemination
of discovery cannot be confined to the VLAN.

And while I could see actually making the determination
based on IP Addressing, I don't see any real advantage
to doing so.

While we've been refining the examples, the underlying
problem remains as originally stated. Since RBridges
provide a distributed Proxy ARP service they simply
must avoid having contradictory information held 
by different RBridges (they can and should have
different subsets of the entire picutre, but no
RBridge should ever have data that contradicts the
data that other RBridgess have).