Subject: comments on VRRP-spec-06 Draft

From: Carol Iturralde <[email-masked]>
Date: Fri, 03 Apr 1998 09:49:57 -0500

I agree with many of the points made by Mark Hollinger.
I'd like to add my own reasons for supporting his suggestions,
and also suggest a few additional changes:

  - Priorities of backup routers should be 'spread out'
    --------------------------------------------------
    (e.g., not 50, 51, 52).  In my case, the granularity of the
    timers in some of our routers is 60 times per second (and
    not the 256 times per second required for skew times like
    these to really work).  For this reason, backup routers whose
    priorities differ by small values (1,2,3.) will behave as if
    the priorities were equal.  I expect that I am not alone,
    and that there will be many routers whose timer granularity
    is less than 256/sec.  For this reason, I recommend adding
    a sentence to the spec. suggesting that 'spreading out' the
    backup priorities may be helpful for boxes whose timers 
    have this characteristic.  I plan to include such a recommendation
    (with specific values) in our user documentation.

  - Using same VRID on different interfaces
    ---------------------------------------
    The spec. says that a virtual router is uniquely identified
    by (VRID, Interface).  This allows customers to re-use
    the SAME ID on a DIFFERENT INTERFACE.  

    It should be noted that doing this could produce a DUPLICATE MAC
    on your network, which could confuse VLAN-capable bridges.
    Let me explain.  Some bridges implement VLANs in such a way
    that a single physical bridge acts as if it were, for example,
    two logical bridges (say odd ports are one bridge, and even
    ports another).  Many vendors have made this work EXCEPT for
    the case where the SAME MAC address is seen on both VLANs
    (seen on an odd port, and then see on an even port).  Rather
    than learning the MAC address twice (once on the odd port,
    again on the even port), some bridges trash -- they learn
    it on the odd port, then move it to the even port, then
    back again, as they see packets with source addresses == this
    MAC.  This can be a very big problem.  Up to now, I have only
    seen it happen when:

         - DECnet routers are connected to each VLAN (because
           DECnet routers use the same MAC address each interface), 
         - ATM ELANs are connected to each VLAN (because some
           switches use the same MAC address on all ELANs)
         - multi-homed Sun workstations sometimes use the same MAC
           address on interfaces

    Notice that we have added VRRP-routers to the above list,
    as a source of DUPLICATE MACs which may cause great trouble
    with your VLAN bridges.  I strongly suggest that we make
    a note of this in the spec.  It can be easily avoided by
    simply using unique VRIDs on all LANs interconnected by
    VLAN-capable routers which suffer from this duplicate MAC
    problem.

  - Need for a Subnet Mask
    ----------------------
    Configuring backup routers with the Virtual IP Addresses may
    not be good enough -- we may want to include a subnet mask.
    The reason is as follows:

    Assume that a backup router has become Master.  Assume that
    this router receives a packet to the Virtual MAC, for which
    it must send an ICMP redirect to the originating host.
    The router needs to select a source IP address for the ICMP
    packet.  If the router has several Virtual IP Addresses,
    it would typically choose the one which is in the same
    subnet as the sending host.  It cannot do this if (1)
    it does not have the subnet mask, and (2)one of the IP
    addresses is a subnet of the other (unlikely, I grant you).
    Rather than making this complicated, I suggest we add
    the subnet mask to the mib, and to the configurable parameters
    (coupled with the Virtual IP Addresses).  Users are accustomed
    to entering IP addresses and associated subnet masks --
    why not add it?

  - TTL should be 1, not 255
    ------------------------
    A value of 255 just plain looks wrong... and confusing.