Subject: RE: Possible flaw in VRRP ?

From: "Smith, Mark" <[email-masked]>
Date: Thu, 20 Sep 2001 07:51:26 +0800

Hi Danny,

Thanks for your response.

See below ...

> -----Original Message-----
> From: danny mitzel [mailto:[email-masked]]
> Sent: Wednesday, 19 September 2001 17:12
> To: Smith, Mark; [email-masked]'
> Subject: Re: Possible flaw in VRRP ?
> 
> 
> the ARP protocol does not rely on the link-level
> ethernet frame source or destination address.  all of 
> the ARP information is in the ethernet packet data
> field.
> 

Yes, the ethernet header will be stripped off before handing the ARP payload
to the ARP module, so the ARP cache should only be populated with the source
MAC address from the ARP payload. 

> for ARP request/reply sent by the VRRP master the
> sender hardware address (ar$sha) is the VMAC and the
> sender protocol address (ar$spa) is the VIP.

And that's the problem, the implementation is putting the real MAC address
in the ARP payload - which is why I'm getting a "bad" ARP cache entry for
the VRRP Virtual IP address. Unfortunately the RFC does not specifically say
this is wrong (as it doesn't seem to address the case of the VRRP router
generating the ARP request during normal operation at all), so I can't blame
the implementation.

  if the
> VRRP implementation you're using does not conform to
> this then it's violating the spirit of rfc2338 
> section 8.2 stating ``...it SHOULD not send any ARP
> message with its physical MAC address...it should only
> send ARP messages that include Virtual MAC
> addresses.''
> 

Agreed, however section 8.2 only addresses ARP requests generated by the
VRRP Master "When the VRRP router restarts or boots, ...", not during normal
operation.

> as you noted there's no mention in rfc2338 of usage 
> of the ethernet frame source address except for the
> periodic VRRP hello.  this is just to maintain proper
> bridge station learning caches in L2 switched 
> envrionments.  if your host implementations are 
> populating ARP table based on ethernet franme source
> rather than ARP sender hardware address field then
> they're broken.
> 

My primary testing hosts have been a mix of Solaris 2.6 and 8, I would be
quite surprised if Sun haven't got ARP right yet :-)

The other thing the RFC doesn't appear to address is transmission of
standard IP packets (ie holding TCP/UDP etc payloads) from the VRRP routers
towards the VRRP protected hosts. I figure if the VRRP router is going to
tell the end hosts that its MAC address is the VRRP Virtual MAC address (via
the ARP Replies (and possibly ARP Requests as per my previous notes)), then
all traffic towards those hosts should have a source MAC address of the VRRP
Virtual MAC address. At least then the ARP information supplied by the VRRP
router is true, and corresponds to what MAC address the VRRP router is going
to use.

Although I've never seen any statements about hosts doing this (eg in any
RFCs etc), it could be possible for a host to validate it's ARP cache entry
for a particular host on each and every IP packet it receives - at the cost
of a few extra CPU cycles, the host's ARP cache would be more current than
if it just relied on ARP requests and replies to keep the ARP cache current,
which is another possible reason why the VRRP router should use the Virtual
MAC address as its source MAC address for all packets towards the VRRP
protected hosts.

Thanks,
Mark.