Subject: RE: VRRP Draft

From: Mike Shand <[email-masked]>
Date: Wed, 29 Oct 1997 13:23:49 -0000

On Wednesday, October 29, 1997 12:59 AM, Acee Lindem 
[SMTP:[email-masked]] wrote:
> With the new draft, one thing that occurred to me is that
> if one is the owner of Virtual Router (i.e., the addresses
> associated with the virtual router are your own local IP addresses)
> you must use the VRID virtual MAC in ARP requests as well as
> ARP responses. The reason being that many ARP implementations
> will update their ARP cache when a ARP request is received.
>
Absolutely. The current draft is supposed to have some text to describe this 
requirement, but it may be rather obscure. Its in section 8.2 where it says 
"They should only send ARP messages that include the Virtual MAC address".
Perhaps we should make this more explicit by saying:-
"When a Master router transmits an ARP request it MUST put its virtual MAC 
address in the Sender Hardware Address field of the ARP message".

> Futhermore, the ARP requests must have the virtual MAC address
> as the MAC header source address for all the same reasons as we
> want the virtual MAC address to be the MAC header source address
> in ARP responses.
I'm not sure I understand this. Why do you think it is important for the MAC 
header source address to be "correct"? As far as I am aware, there are no RFCs 
which require any checks on this field, nor any implementations which actually 
perform such a check. If you know of any I would be very interested to know 
about them. Of course it could be argued that use of the correct MAC address 
might speed up bridge learning, but since we use the virtual MAC address as the 
source MAC address of the VRRP hellos, which are sent once per second by 
default, there seems to be very little to be gained.

> Another complication is communications between routers.
> When one receives an ARP request, one cannot determine if it
> is from a host or router. Hence, all IP exchanges must use the
> VRID MAC address. If one is running a state-full routing protocol
> (e.g., OSPF), a backup virtual router will not only take over
> forwarding packets as hosts but will also take over any
> protocol-specific flows. This shouldn't be too much of a problem
> since I would expect them to fail (however, not in a
> deterministic manner).
> Yes, that's true. Of course most of the OSPF protocol is sent in multicast 
packets which are addressed to specific MAC multicasts. i.e. the hellos and the 
normal database updates to and from the DR (and backup). The only messages that 
get unicast are the failure recovery packets. In the event of a router failing 
between the multicast transmit and the subsequent unicast recovery, then the 
packet will be delivered to the virtual MAC address and end up at the Master 
router which has adopted the failed router. However, as you correctly point 
out, since the packet is addressed to the failed router's IP address it will 
NOT be delivered to the master router's IP stack, and therefore will cause no 
interference. The loss of such a packet is immaterial to the correctness of the 
OSPF operation. Similar arguments apply to ping and SNMP packets addressed to 
the failed router. Not that it is possible that if only an interface on the 
'failed' router has actually failed, there may be an alternate path to the 
router over which such packets may be delivered (depending on exactly how the 
routers advertise subnets and host routes {i.e. /32 routes}, and what TTL is 
set in the packet). I don't think any of this causes any problems.

> When we had a separate virtual IP address these situations
> could not occur since all ARP requests and routing protocol
> exchanges could use the separate IP addresses.
>
> I'm not advocating a change back to the virtual IP address
> approach - I just wanted to assure my thinking is correct.
>
> Thanks,
> --
> Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 29 Oct 1997 09:31:50 -0500

> default, there seems to be very little to be gained.

Although I haven't thought through all the scenarios, I'm mainly
concerned 
about token ring where ARP implementations cache the source-route
bridging
RIF (Route Information Field) from the ARP MAC header. Within a couple
weeks, 
I should be able to post more on token ring operation. 

-- 
Acee