Subject: Q's about VRRPv3 draft

From: "Smith, Mark" <[email-masked]>
Date: Fri, 14 Dec 2001 08:56:16 +0800

Hi Bob,

I've read through your VRRP for IPv6 draft, and have a few questions.

2.5 Efficient Operation over Extended LANs

The description of packets that use the virtual router MAC address as their
source could be interpreted as being restricted to only the VRRP packets
issued by the router.

Would it be better to change "1) use the virtual router MAC as the source in
a packet sent by the Master to trigger station learning" to "1) use the
virtual router MAC as the source in *all packets* sent by the Master to
trigger station learning" ?

I've read though this section myself a few times (in both this draft, and
RFC 2338), and only interpreted it the right way as a final check before
sending this email.

I would suggest expanding this section (and possibly renaming it) to cover
all the link layer issues, including virtual router MAC address, source link
layer address selection, ND neighbour solicitation and advertisement
procedures, and operation over extended LANs.

8.2  ND Neighbour Solicitation

'When a VRRP router restarts or boots, it SHOULD not send any ND messages
with its physical MAC address for the IPv6 address it owns, it should only
send ND messages that include Virtual MAC addresses.'

I would think that any time (rather an just after restarts or reboots) the
VRRP master performs a ND neighbour solicitation for one of the VRRP
protected hosts, it should use the virtual router MAC address for both the
src MAC address in the link layer header, as well as supplying it in the
source link-layer address option of the neighbour solicitation packet.

This also seems to be an vague area in the current IPv4 version of VRRP.
I've recently worked with an implementation of RFC 2338 where the following
would happen :

1) The VRRP master would come up.
2) The first ever packet to be forwarded by the VRRP router was in the VRRP
router to VRRP protected host direction, which caused the VRRP router to
issue an ARP for the Host's link layer address. The VRRP router would supply
it's real MAC address as the link layer source address in the ARP packet.
3) The host would respond to the ARP, but also add an entry into its own ARP
cache, with the real MAC address for the VRRP master.
4) The host would only replace the real MAC address in its ARP cache with
the virtual VRRP MAC address if its the ARP entry timed out and it issued an
ARP for the VRRP router, or the VRRP master failed, and the VRRP backup
route issued a gratuitous ARP as part of its master transition procedure.

I initially though this might be a problem with the implementation, and
figured I would read through the RFC to find out how things should really
work. I found that the RFC doesn't seem to specifically cover the case of
what link layer address the VRRP router should supply when ARPing for a VRRP
protected host.

Fortunately the gratuitous ARP seems to cover up this flaw , however, the
single gratuitous ARP could be lost due to a high amount of traffic on the
network during the master to backup transition.

Regards,
Mark.

---

From: "Smith, Mark" <[email-masked]>
Date: Mon, 17 Dec 2001 07:25:46 +0800

Hi Danny,

> -----Original Message-----
> From: danny mitzel [mailto:[email-masked]]
> Sent: Saturday, 15 December 2001 10:20
> To: Smith, Mark; 'Bob Hinden'
> Cc: [email-masked]'
> Subject: Re: Q's about VRRPv3 draft
> 
> 
> 
> --- "Smith, Mark" <[email-masked]> wrote:
> 
> > source could be interpreted as being restricted to
> > only the VRRP packets issued by the router.
> 
> that's the correct interpretation.  to be RFC
> compliant (with regard to source MAC selection)
> all you need to do is send your VRRP Advertisement
> with the VRRP MAC.
> 

I agree that only using the VRRP virtual MAC for VRRP packets would satisfy
the extended LAN requirement.

I suppose what I'm really focusing on is "truth in advertising". If the VRRP
Master router is going to answer ARP requests (and IPv6 ND Neighbor
Solicitations) with the virtual MAC address, isn't the VRRP Master router
stating to the end-node that "all traffic from me to you will come from this
link layer source address", and therefore all traffic from the VRRP Master
router should use the virtual MAC for all (ipv4 / ipv6) packets to the VRRP
protected end-nodes.

In addition to the ARP Reply / ND Neighbor Advertisement answer being "the
complete truth", a minor benefit would be a reduction by one in the entries
in the bridge learning cache. Also, fault diagnosis would be easier, if you
were using link layer sniffing to capture the packets coming from the VRRP
master router (a very minor benefit I know, but it would be confusing to
people to see a ARP reply / ND NA and then not see any traffic (other than
VRRP) coming from that link layer address).

> > RFC 2338), and only interpreted it the right way as
> > a final check before sending this email.
> 
> sounds like what you're really saying is that you
> interpretted it correctly every time except this
> last. ;-)  I agree it could be made a bit more 
> explicit in stating that source MAC == VRRP MAC
> only mandated for VRRP packets.  I've heard this
> question several times.
> 
> I believe you posted the ARP scenario a couple
> months back and there was some discussion?  I
> believe request was to modify that section 8.2
> clarify/cover both ARP request and reply sent by
> VRRP router. set sender hardware address (ar$sha)
> to VMAC whenever sender protocol address (ar$spa)
> is the VIP.  seems reasonable clarification if
> this is what is what you're referring to?
> 

Didn't really get that far ie. regarding modifying section 8.2. At that time
I was just making sure that I understood the spec properly.

I've read through RFC 2338 a few more times now, and have had a few people
confirm my understanding .. it does seem that this is a case (ie ARP
requests from the VRRP master router) that could be clarified further.

Thanks,
Mark.

---

From: "Smith, Mark" <[email-masked]>
Date: Wed, 19 Dec 2001 13:33:34 +0800

Hi Danny,

> Sent: Tuesday, 18 December 2001 8:40
> Subject: RE: Q's about VRRPv3 draft
> 
> 
> Re: source MAC selection
> 
> I guess my main objection regarding mandating use of
> VMAC as frame source MAC is that it becomes ambiguous
> as soon as you're master for more than 1 VR.
> 

I might be a bit confused, but I thought different VRID for each VR would
avoid this ambiguity ?

> in some implementations / architectures overriding the
> HW MAC may be slightly more expensive (time consuming)
> than using the burned in MAC.  for VRRP Advertisement
> and filling in ARP payload this is likely not too
> burdomsome as they're quite low datarate.  but some
> vendors may not like paying the extra expense for 
> every single packet forwarded in the highly optimized
> forwarding path.
>

Fair enough, I read through (well read might be a bit too strong a word -
the "great spam tidal wave of 2000" slowed me down a bit) all the VRRP
mailing list archives and noticed a few emails from people indicating that
they would prefer to avoid using the VMAC as the source for all packets due
to performance issues.
 
I suppose ideally the protocols definitions should come first, and then the
vendor develops equipment that implements the protocols and performs
adequately. On the other hand, MPLS was originally designed to address
equipment performance problems, so there seems to be precedent.

Using the real link layer address as the src MAC in the link layer headers
for normal packets is probably ok as long as it doesn't break anything above
it eg ARP, IP etc.

I would still argue for modifying the RFC(s) (ie 2338, plus VRRP for IPv6
draft) to cover the one case where the VRRP Master Router ARPs / ND Neighbor
Solicits for an end node, supplying the VRRP Virtual MAC as the link layer
source address in the appropriate ARP / ND Neighbor Solicitation payload
field.

> overall the RFC is targetted at specifiying 
> minimal requirements for correct operations and
> interoperation of the protocol.  I think
> vendor is free to embelish their implementation
> with features like this if they see some
> strategic advantage as it doesn't really impact
> interoperability.
> 

Agreed.

Thanks,
Mark.