Subject: RE: [VRRP] Explanation of virtual MAC addresss

From: "Don Provan" <[email-masked]>
Date: Fri, 19 Sep 2003 17:22:17 -0700

> > My tests showed that when the NetGear FS524S switch received a
> > packet which changed its knowledge of where a MAC address was
> > would not forward that packet to the link that had previously
> > been the source of that MAC address.
>
>  Sounds like a bug: station movement behavior should be configurable.

1. This is a simple switch with no configuration.

2. If you could cite chapter and verse that proves this is a bug,
I'd appreciate it. I could find nothing in any 802.x spec which
precludes this behavior. I'm no 802 expert, but as far as I could
tell, the specs basically say that a switch can do whatever the
heck it wants when an address moves, as long as it starts sending
subsequent packets for that address in that direction.

> > I've also had trouble with higher end switches, too. For
> > example, some Extreme switches can be configured to assume
> > that two links using the same MAC address is a trunk: all
> > packets to that MAC address are sent down both links. VRRP
> > works fine, but the bandwidth is wasted.
> >
>
> Another thing thats configurable. Also sounds like a big assumption
> being made by extreme .. that a) it is a trunk and b) a copy
> to be sent to each port..

My point is that switches require specific configuration to
handle the shared MAC. And so far, I've never seen a switch
have a configuration option like "behave in a way that's
friendly to VRRP. This isn't an argument for or against the
shared MAC, it's just an answer to Jeff Hass's query about
relevant "switching situations".

> > Another example is the ability to subdivide a switch
> > internally using VLANs. Since the VLANs share MAC addresses,
> > VRIDs must be unique through the entire switch, but that's
> > not apparent from the external nodes that aren't aware their
> > traffic is being bridged to a VLAN within the switch.
>
> I am not sure i understood the above:
> VLANID+MAC address is typically considered a unique entity/key in most
> L2 switch lookups. A VLAN is typically a separate subnet when you
> manage it with IP; so i would think unique VRID is a MUST to get it to
> work.

Sounds like you understood fine, as that is my point. The point
is that VLANs are being used behind the scenes, within the switch,
so unique VRIDs are required, yet the router itself is NOT aware
of the VLAN, so the person configuring it may not realize that
two VRs on two different networks require unique VRIDs because
the two networks are being maintain via a single switch.

> > > What was definitely the case was the problem with gratuitous arps
> > > and hosts that didn't listen to them.   In this particular case,
> > > our question should be "Do common implementations support
> unsolicited
> > > ND messages and thus don't require a virtual mac?"
> >
> > Right. This is indeed a key point. Perhaps the question to ask is,
> > "Can we require that implementations support unsolicited ND
> messages?"
> > The problem in IPv4 was implementations that didn't follow the
> > ARP spec, but can we avoid that problem in v6?
> >
>
> Any packet (broadcasts prefered - since everything in the collision
> domain will at least see the packet) with the right src MAC addresses
> helps to update L2 tables in ethernet.

Not clear what your point is here. The spec does not call for ARP
packets to be send with the VR MAC as the source, so they shouldn't
have any bearing on the L2 tables. Are you suggesting the spec
change this for ND packets?

> If something is broken like that
> netgera switch or older OSes which dont update their tables, then i
> suggest you junk them if you are serious about getting VRRP working.
> Either that or have the vendor fix it if you have enough clout.

Customers typically get annoyed when you tell them that the
equipment they've been using without any problems is broken.
particularly when the evidence you present is that *your*
product doesn't work.

But that's really the point here: can we arrange things so
that a product is considered officially and demonstrably
broken if it doesn't support unsolicited ND messages?

-don

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: jamal <[email-masked]>
Date: 20 Sep 2003 13:20:36 -0400

> subsequent packets for that address in that direction.

I cant cite verse for you, but i can share from my experiences
programming these beasts. Chips produced in the last 4-6 years to do L2
typically allow programmability for station movement behavior. The
default maybe to drop the packet - a good standard default is to
forward. If you build for paranoia, sure drop is a good policy.
If you assume paranoid mode then i agree with you station movement
(maintaining the same VMAC across) is bad. Question is the type of
switches that you describe are a minority. Infact i could further claim
that paranoid-mode doesnt give you any guarantees.

> relevant "switching situations".

Understood - i am claiming that infact your examples are to be
considered misconfigurations if you want to use VRRP. 

> the two networks are being maintain via a single switch.

I dont know which switches you are buying ;-> perhaps i could sell you a
swithc which handles this fine (Apologies in advance, no insult
intended).
A VLAN is a collision domain. Take that into account then you are set.

> change this for ND packets?

My experiences are with V4. For that yes, sending the VMAC does help in
getting the failover shortened.
For V6, i am just handawving - but i would say Yes.

> particularly when the evidence you present is that *your*

I agree with you that its a balancing act.
A good implementation should have as many workarounds as possible;
however, sometimes you gotta draw a line and not solve world
hunger(unless you have a lot of resources). I can see value in adding
something to the protocol if theres so many switches broken.

> broken if it doesn't support unsolicited ND messages?

For soem reason i have always assumed ND as a given; probably because
all Linux devices with V6 support issue them. I am not too familiar with
internals to put a good opinion.

cheers,

---

From: "Don Provan" <[email-masked]>
Date: Mon, 22 Sep 2003 12:21:37 -0700

> programming these beasts.

Normally one bases protocol design on specifications because they
are written down and only subject to change in specific ways. So
while it's useful to discuss common practice, in the end we still
have to spell out what range of behaviors within the specifications
we're depending on.

> considered misconfigurations if you want to use VRRP.

Correct. They are configurations which cause problems for VRRP
because shared MAC address.

> My experiences are with V4. For that yes, sending the VMAC
> does help in getting the failover shortened.

OK. Could you spell out the case where this helps? It sounds
like another data point where VR MAC addresses cause problems
with switches.

Would you suggest using the VR MAC for only the unsolicited
ARPs, or for all ARPs supplying the VR IP to VR MAC mapping?

My problem with ARP messages using the VR MAC address as
the source is that it is impossible to tell who sent them.
This can make debugging a problem difficult.

> something to the protocol if theres so many switches broken.

Again, I wasn't suggesting adding (or even removing) anything
from the protocol. I'm just spelling out some issues.

-don

---

From: "Don Provan" <[email-masked]>
Date: Thu, 25 Sep 2003 15:26:07 -0700

> swithc which handles this fine (Apologies in advance, no insult intended).

I'd like to thank Jamal for slapping me around with unpleasant
facts about actual practice, 'cuz it made me dig out the specs
(in this case, 802.1Q-1998) so I can talk reasonably about it.

It turns out that 802.1Q describes two modes of operation. The
simpler is Shared VLAN Learning (SVL). An SVL bridge learns MAC
addresses independently of VLAN. The mode Jamal is describing --
and I have no doubt it is the more common -- is Independent VLAN
Learning (IVL). An IVL bridge learns MAC addresses separately for
each VLAN. In this case, as Jamal puts it, "A VLAN is a collision
domain." A bridge can be both SVL and IVL at the same time.

So the restriction I was trying to describe is that unique VRIDs
must be used for all VRs on all VLANs within the same SVL
domain. In real life deployments, this is probably not an
issue, but it might trip people up in test or development
setups where a $10 switch is standing in for the $100K switch
that would be used in a real network.

-don