Subject: RE: Virtual MAC Addresses... again.

From: Peter Higginson <[email-masked]>
Date: Thu, 18 Dec 1997 11:06:22 -0000

The purpose of the virtual MAC address in vrrp (and the similar
mechanisms in the Cisco scheme) is to switch to a backup router without
any action by the host.

Some hosts use gratuitous ARP successfully because most routers listen
to and process all ARPs they receive. It doesn't work the other way
round - when we tested this we found hosts that ignored ARPs they were
not expecting and recovered only in the 5 minute ARP timeout.

The rules for processing ARPs in the RFC have only a "suggested" status
and therefore you cannot rely on a host processing to source field of an
ARP request that is targeted at another node. There is no statement
anywhere that I have ever found to say that hosts must do this. There is
also no allowance in the specs for broadcasting an ARP response (which
might be another alternative).

Using the virtual MAC address allows the routers to control the timing
of the failover and do it deterministically. An ARP mechanism would
require retransmissions to ensure that all hosts had heard the message,
even if all implementations were fixed.

Peter

>-----Original Message-----
>From:	Rob Montgomery [SMTP:[email-masked]]
>Sent:	18 December 1997 01:38
>To:	[email-masked]
>Cc:	[email-masked]; [email-masked]; [email-masked]
>Subject:	Virtual MAC Addresses... again.
>
>I apologize in advance if I'm beating a dead horse, but upon reading
>the Nov. 21 draft, I was reminded of one question which, at least to me,
>remains unanswered. What is the overall purpose of the 'Virtual MAC
>Address'? What does it accomplish that can't be accomplished by the
>gratuitous ARP?
>
>Thanks,
>
>-Rob Montgomery
>[email-masked]
>

---

From: Rob Montgomery <[email-masked]>
Date: Fri, 19 Dec 1997 00:53:40 -0500

Correct me if I'm wrong, but RFC 826 doesn't exactly read as a
'suggestion.' The relavent portion states:

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

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

Based on this, a broadcast ARP-Response (Source Protocol Address =
Router, Source Hardware Address = Router, Target Protocol Address =
Broadcast, Target MAC Address = Broadcast) is going to be processed, and
the ARP-Cache will be updated accordingly.

Are there devices out there that don't comply with this RFC? Yes. But
allow me to point out section 2.1 of your draft:

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

2.1 IP Address Backup

   Backup of IP addresses is the primary function of the Virtual Router
   Redundancy Protocol.  While providing election of a Virtual Router
   Master and the additional functionality described below, the protocol
   should strive to:

    - Minimize the duration of black holes.
    - Minimize the steady state bandwidth overhead and processing
      complexity.
    - Function over a wide variety of multiaccess LAN technologies
      capable of supporting IP traffic.
    - Provide for election of multiple virtual routers on a network for
      load balancing
    - Support of multiple logical IP subnets on a single LAN segment.

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

Does the use of a Virtual MAC Address minimize processing complexity?
Does it function over a 'wide variety of multiaccess LAN technologies?'
Am I missing the statement that says ' - Support all proprietary
implementations of ARP'? The concept of a virtual MAC address directly
contradicts these purposes.

Also, it's not just LANE that has an issue. Again, I quote from your
draft:

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

Unicast mode on token ring has one limitation which should be
considered.  If there are VRID routers on different source-route
bridge segments and there are host implementations which keep their
source-route information in the ARP cache and do not listen to
gratuitous ARPs, these hosts will not update their ARP source-route
information correctly when a switch-over occurs. The only possible
solution is to put all routers with the same VRID on the same source-
bridge segment and use techniques to prevent that bridge segment from
being a single point of failure. These techniques are beyond the
scope this document.

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

Does this mean that I can use VRRP is a fully source-route environment,
but I still have a single
point of failure?

Please understand that VRRP is going to be very important to mission
critical networks throughout the word, and easy interoperation with
standards compliant hardware/software will be instrumental to it's
success. By concentrating on support for proprietary implementations of
ARP, you have increased the operational complexity of the protocol, made
Token Ring and FDDI implementations more difficult, made LANE 1.0 (and
some future 'compliant' 2.0) implemtations unworkable.

I apologize for my rant, but please understand my frustration. VRRP is,
at this point, a good looking protocol that, in my opinion, will be very
important. I cannot express, enough of my appreciation to the whole
working group for your work on this protocol. As an end-user it will be
extremely helpful. But please, seriously consider the ramafications of
using the Virtual MAC Address. 

Thanks for your consideration,

-Rob Montgomery
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Fri, 19 Dec 1997 08:54:00 -0800

Rob,

I think the underlying issue is current practice, not specifications.  In
practice hosts implement the specifications in various ways and there is
considerable experience that just doing gratuitous ARP is not sufficient.
It does not work with all deployed hosts.  A solution was needed that works
with all deployed hosts.

Hope this helps.

Bob

---

From: Rob Montgomery <[email-masked]>
Date: Fri, 19 Dec 1997 19:05:02 -0500

Bob,

I still disagree, but I know when I'm on the losing side. May I suggest,
however,
that the spirit that you've put forth below be properly represented in
section 2.1.

Thanks,

- Rob Montgomery
  [email-masked]