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

From: jamal <[email-masked]>
Date: 19 Sep 2003 15:25:40 -0400

On Fri, 2003-09-19 at 14:40, Don Provan wrote:
> > I believe it was asserted at some point that the vmac made certain
> > switching situations easier to deal with.  If someone could expand
> > on that point a bit, that might be helpful.
> 
> 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. Normally this wouldn't be
> a problem and I never found anything in the spec that made this
> behavior illegal, but with VRRP it meant that two competing routers
> would never hear each other.

 Sounds like a bug: station movement behavior should be configurable.

> 
> I mention the specific model because people have told me that
> other NetGear switches don't seem to do this.
> 
> 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..

> 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.
> 
>
> The point is that the shared MAC address puts a burden
> on the person configuring the switch to understand that
> VRRP is running and to know how the switch configuration
> will impact VRRP. This worries me particularly because the
> switch infrastructure may be invisible to the person
> deploying VRRP.
> 

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. 

> > 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. 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.

cheers,
jamal

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

---

From: "Don Provan" <[email-masked]>
Date: Fri, 19 Sep 2003 10:49:33 -0700

> Now the debate can be "should the hosts be aware of
> the switch over or not" ??
>
> Opinions/arguments ??

I agree this is one issue. Another issue to debate
is whether the *switch* should be aware of the switch
over. I don't consider this the deciding point, but
of the two, I'd much rather have the host know about
the failure of our layer 3 device than the layer 2
switch. One reason is that the layer 2 specs seem
fairly intent on treating a MAC address as the
identity of a physical piece of hardware. They
become somewhat vague about what happens if a MAC
address mysteriously moves from one device to another.

-don