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

From: [email-masked]
Date: Sat, 6 Sep 2003 13:43:42 -0600 (MDT)

>Why is there
>a need for a virtual MAC address?  The reason given is "to enable bridge
>learning in an extended LAN".

That was not my understanding as to why there were
VMACs, and indeed having each router have its
own MAC address would make bridge learning simpler (since things wouldn't
move).

My understanding of the reason for VMACs is for the endnodes. In theory
in IPv4 (as you pointed out, Matthew)
a gratuitous ARP should cause all the endnodes to
update their ARP caches. However, there are two possible problems with this:

a) since behavior on gratuitous ARP wasn't architected into IPv4 from
the start, we can't count on all endnodes updating their ARP caches.

b) the gratuitous ARP could in theory get lost, so perhaps should
be done periodically.

There is a separate thread of whether VMACs are needed for IPv6.
I think the ball on that thread got dropped, or perhaps people gave up.
There isn't ARP in IPv6, so is there some other mechanism by which
IPv6 endnode "ARP" (neighbor discovery) caches can be guaranteed to
be updated in a timely way?

As for whether it's good to configure a switch setting "I know all the endnodes
on this LAN react to gratuitous ARP"...without a hat on (since I'm
expressing an opinion), I'd say that would be dangerous, since if
you get that wrong, very weird things will happen.

Radia

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

---

From: Matthew Bloch <[email-masked]>
Date: Sun, 7 Sep 2003 19:00:08 +0100

> the start, we can't count on all endnodes updating their ARP caches.

I'm not sure I understand this issue because my knowledge is based on how
Windows and Linux ARP caches work (and this was also what we were taught at
college): that ARP replies always update caches on machines that receive
them, whether or not those machines made an ARP request.

> b) the gratuitous ARP could in theory get lost, so perhaps should

Yes, this and the above issue are handled by wackamole by the user
configuring who to notify and how often: i.e. it can send broadcast ARPs, it
can send an individual ARP to each host on the network (assuming maybe that
they will ignore broadcast ARPs, or that there's something else in the way
of a broadcast), and/or notify every host in the new router's ARP cache.  I
think this covers all practical possibilities.

[snip]
> you get that wrong, very weird things will happen.

I'd be interested to know from anyone else in what circumstances (barring
the ARP being lost) a host receiving a gratuitous ARP would not update its
cache.

cheers,

- -- 
Matthew Bloch                             Bytemark Hosting
                                  tel. +44 (0) 8707 455026
                        http://www.bytemark-hosting.co.uk/
          Dedicated Linux hosts from 15ukp ($26) per month

---

From: "Don Provan" <[email-masked]>
Date: Mon, 8 Sep 2003 14:48:48 -0700

> the ARP being lost) a host receiving a gratuitous ARP would not update its

It's true that ARP from the very beginning has called for this behavior, but
not all implementations agreed with it. Mr. Haas mentioned BSD/OS. The only
specific example I'm aware of was the Lucent (nee Livingston) PortMaster
product line, but I'm sure there are some others, though likely as obscure
these days.

It's not hard to see why people made this decision, since in practice a MAC
address change in an ARP packet is probably about a thousand times more
likely to be wrong than right. But that's not VRRP, so we won't argue that.

What I really wanted to get to is the possibility of the spec being
expanded to allow an implementation to use natural MAC addresses.
As Mr. Bloch points out, there are no interoperability issues in VRRP
itself. In Linux, the other two implementations I am aware of also did
not use the VR MAC addresses, and I had to make kernel mods to support
my implementation. So perhaps the VR MAC address could be made an optional
feature that can be left out by people that aren't worried about these
non-compliant ARP implementations that have existed over the years.

-don

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Sep 2003 17:56:07 -0400

> likely to be wrong than right. But that's not VRRP, so we won't argue that.

It is also a potential security issue.  Since the ARP protocol has
no inherent security, allowing differing addresses to be arbitrarily
overwritten from gratuitous ARPs is problematic.

This was the root of why having security on VRRP was silly after all. :-)

> expanded to allow an implementation to use natural MAC addresses.

One could easily argue for an extension to the base spec that
allowed this.  However, given VRRP's current place on the standards
track, such a big change is probably unlikely to the base protocol.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Sep 2003 08:29:25 -0400

> them, whether or not those machines made an ARP request.

To give an example from within recent memory, BSD/OS didn't respond
to gratuitous ARPs as late as 1999.  This made moving virtual web
servers bound to an address from one machine to another, even on
the same physical subnet, painful.

I don't know if the OS behaves this way still.

> the ARP being lost) a host receiving a gratuitous ARP would not update its

While this portion of the spec is perhaps the most painful of the VRRP
spec, it guarantees correct behavior with no end-host changes.  Thus,
it is completely transparent.  This, I believe, is one of the goals of
VRRP.

That said, it'd be nice to have a standard API to spewing ARP messages
and altering the cache.  It would certainly simplify implementing VRRP.

-- 
Jeff Haas 
NextHop Technologies