Subject: Virtual MAC Addresses in VRRP

From: Rob Montgomery <[email-masked]>
Date: Mon, 10 Nov 1997 00:36:01 -0500

Hi all.

Allow me to apologize in advance if this subject has been covered
already (I did look through the archives, but it's always possible.)
As a user of Cisco's HSRP, I am excited by the idea of a standards
based solution. However, there is an operational issue with HSRP
that has not been addressed in the VRRP draft.

My concern with the VRRP protocol draft, as it stands, has to do
with the virtual MAC address. While it will function fine in most
networks, I have run across problems with Cisco's HSRP, and ATM's
LAN Emulation.

While things are slowly changing, most Proxy LEC's (Proxy LAN
Emulation Client) that I have worked with have significant trouble with
MAC Address mobility. In short, when a MAC address moves, it takes 
(in a default configuration) 300 seconds for the new location of the 
MAC address to be learned by all LEC's on the Emulated LAN. This 
gives us our 'black hole' again.

The most common solution (that I have used/seen) involves placing
both the primary and redundant routers behind the same LEC.
However, we are now left with a single point of failure - The
LEC.

I would, therefore, propose that the concept of a Virtual MAC
address be abandoned, and that we take advantage of the ARP
protocol to do it's work.

Should a fail over occur, would it not make sense for the
new master router, upon becoming the master router, to
transmit a broadcast ARP packet, with the op-code set
to ares_op$REPLY. This packet should contain the Source IP
address of the Virtual Router, the Source MAC Address of the
Master Router, an unknown Target IP Address (probably
255.255.255.255) and an unknown Target MAC Address (probably
FF:FF:FF:FF:FF:FF). By setting the op-code to 'reply', this
would not generate a storm of ARP Responses.

In this way, all devices on the broadcast domain would receive
(through the broadcast MAC Address) an updated MAC to IP pairing
for the virtual router (pairing the Virtual Router IP with the
hard coded 48 Bit MAC Address of the Master Router), without 
disrupting any LANE LE_ARP Cache, or any other tables that 
might inhibit MAC Address mobility.

I have attached the relevant portion of RFC-826. I hope this makes
some sense, and any comments are, of course, eagerly anticipated.

Thanks,

Rob Montgomery
[email-masked]

---------------------------

RFC - 826, David C. Plummer, November 1982.
An Ethernet Address Resolution Protocol or Converting Network Protocol 
Addresses to 48.bit Ethernet Address for Transmission on Ethernet
Hardware

Begin Quote---------------------------------------------------------

When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.

?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
  [optionally check the hardware length ar$hln]
  ?Do I speak the protocol in ar$pro?
  Yes:
    [optionally check the protocol length ar$pln]
    Merge_flag := false
    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true. 
    ?Am I the target protocol address?
    Yes:
      If Merge_flag is false, add the triplet <protocol type,
          sender protocol address, sender hardware address> to
          the translation table.
      ?Is the opcode ares_op$REQUEST?  (NOW look at the opcode!!)
      Yes:
        Swap hardware and protocol fields, putting the local
            hardware and protocol addresses in the sender fields.
        Set the ar$op field to ares_op$REPLY
        Send the packet to the (new) target hardware address on
            the same hardware on which the request was received.

End Quote----------------------------------------------------------

Rob Montgomery
[email-masked]

---

From: "Danny J. Mitzel" <[email-masked]>
Date: Mon, 10 Nov 1997 00:43:26 -0800

>> protocol to do it's work.

abadoning the VMAC concept would most likely also simplify implementation 
on some platforms because it eliminates the need to grunge around with
the link layer header.  however I think there has been concern raised 
about IP stacks on a non-trivial number of deployed end-hosts that do not
properly handle gratuitous ARP and changes to the IP/MAC mapping.  thus the
adoption of a fixed IP/VMAC mapping and the text at the end of section 8.2
mentioning how important it is to avoid any actions that could result in
changes to the IP/MAC mapping over time.

my personal take is that in the face of these incompatible options there 
is probably more interest/benefit in accommodating the broken end-host
implementations than dealing with LANE limitations.

---

From: Acee Lindem <[email-masked]>
Date: Mon, 10 Nov 1997 09:52:15 -0500

> might inhibit MAC Address mobility.

Rob, 

Unfortunately, many host TCP/IP stack implementations do not 
listen to gratuitous ARPs as documented in RFC 826. At this
point, it makes more sense to provide MAC level transparency 
in the routers than to fix/update all the host implementations. 
However, I agree with you that in an RFC826-conformant world 
this would be a much cleaner solution. 

Thanks, 
-- 
Acee

---

From: Rob Montgomery <[email-masked]>
Date: Mon, 10 Nov 1997 19:52:58 -0500

Based on the responses that came back today, and the archives that 
I've read, I've put together a list of reasons for using a virtual 
MAC Address, and reasons for only using gratuitous ARP. Obviously, 
this  will come out fairly slanted as people don't tend to question 
things that haven't been proposed yet.

Reason's for a Virtual MAC:
1. Responds better in the event of dropped announcements.

2. Not all devices fully support RFC 826.*

Reason's for Gratuitous ARP:
1. Simplifies the protocol (speeds up vendor implementation, and
reduces the cost of that implementation.)

2. Simplifies the protocol (by eliminating special MAC address
filters, it alleviates a potential performance hit that can be
taken by low end routers.)

3. Allows the protocol to operate over a wide variety of technologies
(i.e. ATM/LANE and primitive VLAN's) that may not permit rapid MAC
address mobility.

4. Simplifies operations in a Token Ring environment.

5. Simplifies operations in an FDDI environment.

6. Eliminates any conflicts between the registered MAC address of
a Non Proxy LEC (LAN Emulation Client) and the virtual MAC address.

*While I appreciate all concerns in regards RFC 826 compliance, I am
concerned by the subtext of this action. By placing interoperability
with proprietary implementations of a standards based protocol above
interoperability with standards based networks, why even bother
writing a standard? 

Thanks for listening.

-Rob Montgomery
[email-masked]

ps. Can anyone give me an example of some implementations that don't
work with Gratuitous ARP? I've been experimenting in the lab, but
I haven't found any yet. I'd love to play with one. Thanks in advance.

---

From: Joel Halpern <[email-masked]>
Date: Wed, 12 Nov 1997 09:08:10 -0500 (EST)

There are other solutions in the ATM FOrum LANE case.  There is a message
in LANE V2 that is a gratuitous ARP which goes to everyone.  That can be
used to easily propagate the fact that the virtual MAC has moved.  

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.

---

From: Joel Halpern <[email-masked]>
Date: Wed, 12 Nov 1997 11:43:50 -0500 (EST)

Slight problem in the above.  I left of a letter set.
The message I am referring to is a gratuitous LE-ARP, a LANE specific
message that LANE devices are required to accept.

Yours,

---

From: Rob Montgomery <[email-masked]>
Date: Wed, 12 Nov 1997 21:54:41 -0500

I appreciate the heads up.  If there is widespread support 
of this 'Targetless LE_ARP_REQUEST'  feature, this should 
minimize the effects of this problem for routers behind a 
proxy-LEC.

I'm still concerned by the optional nature of this clause,
and by the fact that I haven't found a solution to the
problems associated with dynamic MAC addressing on
ATM Attached Routers.

If a client sends an LE_REGISTER_REQUEST for a (virtual)
MAC Address that has not been unregistered by the previous
owner, are there any guarantees that a LES will not reject
the registration attempt?

Thanks,

-Rob Montgomery
[email-masked]

---

From: Joel Halpern <[email-masked]>
Date: Thu, 13 Nov 1997 09:49:18 -0500 (EST)

> the registration attempt?

If a client drops his LANE Control Direct VC (the VC over which one does
registrations), then all of ones registrations are deleted.  The speed of
propagation of this information (assuming the proposed LANE V2 LNNI
operation) is faster than the VRRP detection time.  So, if the router
failure brings down the VC (as it should), then the registration will go
away.  
There is one "corner" case.  If the router fails "soft", in such a way
that his VCs don't go down, then the registration won't go away.
I would not consider this a big case.  If we want to fix it, all VRRP
routers can be Proxy LECs, and not register the virtual MAC address.  The
price ist that the routers will get more LE-ARPs.  (Note, if the router is
also a bridge then it already was a Proxy LEC.)

Yours,