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

From: "Don Provan" <[email-masked]>
Date: Fri, 19 Sep 2003 11:40:55 -0700

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

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

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

-don

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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 19 Sep 2003 12:25:02 -0400

On Thu, Sep 18, 2003 at 02:19:50PM -0400, Radia Perlman - Boston Center for Networking wrote:
> Anyway, it would be good if people who care either way would give their
> arguments:
> 
> a) for VMACs
> b) for no VMACs, and using unsolicited ND once
> c) for no VMACs, and using unsolicted ND periodically
> d) some other proposal

Seems like a good question for the ipv6 folks.

-- 
Jeff Haas 
NextHop Technologies

---

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

> > What has worked well with IPv4 and ARP is sending two or three
unsolicited
> > broadcast messages when the address first becomes active.
>
> For those of us who aren't familiar with the implementation issues....
> why the heck do we need to send these at all?

Basically for the same reason any IP address coming on line needs
them. Yes, in a steady state situation where all VRs actually follow
the spec, the ARP messages should be the same. But the master system
doesn't know whether it's entering a steady state environment, so it
needs to send ARPs in case, for example, VRRP is just now being
deployed or the VRID has just been reconfigured, either of which
would mean that the IP address is being transferred to a different
MAC address.

In practice, not all VRRP implementations actually use the VR MAC
address. To interoperate with them, the ARP is necessary.

This is all somewhat off the VR MAC issue, except to note that
the ARP messages are already required for other reasons, so it's
not a question of adding them (or gratuitous ND messages) in
order to avoid sharing a MAC address.

-don

---

From: "M. T. Hollinger" <[email-masked]>
Date: Fri, 19 Sep 2003 12:26:50 -0400

> There are two alternatives though.
> a) send one unsolicited ND message, and assume everyone will receive it
> b) send periodic ND messages

Well, I don't have much operational experience yet with virtual addresses
under IPv6.

What has worked well with IPv4 and ARP is sending two or three unsolicited
broadcast messages when the address first becomes active.  Repeating the
message helps to cover the case where one packet is dropped due to some
transient problem on the LAN.  Periodic repetitions aren't necessary because
others on the LAN will be timing out their ARP (or neighbor) cache and
re-resolving the MAC address anyway.

               - M

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 19 Sep 2003 13:03:40 -0400

> Well, I don't have much operational experience yet with virtual addresses

Nor do I.  So, I'm speaking from a purely theoretical standpoint.

When the first VR comes up, we need to send them.  We need to
respond to who-has requests.  However, in a transition all that
should change is the host giving the information.  The contents
of the arps should be identical, correct?

If so, is this meant to make switches happy?

> Repeating the
> transient problem on the LAN.

Going back to just protocol issues, "periodic" means a timer.
This means that in cases where a switchover needs to happen, one
host may be sending its periodic arp to cover it having become
the master and that timer might still be active while there was
a transition to another master.

Not a huge deal, but it impacts the state machine.

-- 
Jeff Haas 
NextHop Technologies

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 18 Sep 2003 14:19:50 -0400 (EDT)

Trying to see where we are on this issue.

To summarize, some people were hoping we'd do away with VMACs for IPv6.
I asked if there was an equivalent to gratuitous ARP for IPv6 and
Jeffry Haas pointed me at RFC 2461, sec 7.2.6 ("unsolicited
neighbor discovery" message). In theory then, all
IPv6 endnodes should be implementing that.

I don't think anyone described crisply what the alternative to VMACs for
IPv6 would be, but I'll try to summarize that as well. The proposal
would be that each router would just use their own physical MAC, and
whoever took over the IP address of the virtual router would advertise
an unsolicited neighbor discovery message.

Note that solution b) becomes similar to the ES-IS protocol with the
IPv6 unsolicited ND msg being like the ES-IS router advertisement.

a) for VMACs

Thanks,

Radia