Subject: Possible flaw in VRRP ?

From: "Smith, Mark" <[email-masked]>
Date: Tue, 18 Sep 2001 15:05:56 +0800

Hi,

I've have been doing some work with VRRP recently, and have come across what
could be a flaw in RFC 2338 VRRP. I've looked through the new VRRP draft,
and it doesn't seem to be addressed there either.

The flaw can be demonstrated with the simple example in section 4.1 of RFC
2338. 

                  +-----+      +-----+
                  | MR1 |      | BR1 |
                  |     |      |     |
                  |     |      |     |
     VRID=1       +-----+      +-----+
     IP A ---------->*            *<--------- IP B
                     |            |
                     |            |
                     |            |
   ------------------+------------+-----+--------+--------+--------+--
                                        ^        ^        ^        ^
                                        |        |        |        |
                                      (IP A)   (IP A)   (IP A)   (IP A)
                                        |        |        |        |
                                     +--+--+  +--+--+  +--+--+  +--+--+
                                     |  H1 |  |  H2 |  |  H3 |  |  H4 |
                                     +-----+  +-----+  +--+--+  +--+--+

  Legend:
           ---+---+---+--  =  Ethernet, Token Ring, or FDDI
                        H  =  Host computer
                       MR  =  Master Router
                       BR  =  Backup Router
                        *  =  IP Address
                     (IP)  =  default router for hosts

The problem occurs when MR1 needs to resolve the MAC address of one of the
Hosts via ARP. This can occur just after cold start of the VRRP routers, or
at any time after the ARP entries have timed out in the ARP cache on the MR1
router.

The problem I'm seeing is that the ARP request from the MR1 router uses the
interface's real MAC address rather than the VRRP virtual MAC address as
it's source MAC address.

When the host receives the ARP request, in addition to sending a
corresponding ARP reply, it also puts the source MAC and source IP address
into its own ARP cache, as per RFC 826 behaviour. The host now has an ARP
cache entry for the VRRP router with the VRRP IP address and the router's
real MAC address, rather than the VRRP virtual MAC address. This appears
contrary to VRRP's intention of the hosts only ever associating the VRRP IP
address with the VRRP Virtual MAC address in their ARP cache.

Packet forwarding via the MR1 router will still work as long as it is
willing to accept packets with a destination MAC address of the real
interface MAC address in addition to the VRRP virtual MAC address. RFC 2338
doesn't specifically say the router shouldn't.

There could be a problem when MR1 fails over to BR1. The MAC address in the
host's ARP cache would then be wrong, and the host would not be able to send
any remote traffic. The blackhole would exist until :

1) The host's ARP cache entry times out, and it then issues an ARP request
for the MAC address of its default gateway. The new VRRP Master would issue
an ARP response with the VRRP virtual MAC address, as per RFC 2338 section
8.2.

2) The new VRRP Master issues a gratuitous ARP, with a Virtual MAC address
as the source MAC address.

When a VRRP Backup becomes a Master, as part of its initialisation it issues
a gratuitous ARP. The intention of this gratuitous ARP appears to be to
update the layer 2 learning bridge tables with the new location of the VRRP
Virtual MAC address. Fortunately, it also ends up updating the ARP cache of
the attached hosts with the VRRP Virtual MAC address of the VRRP IP address,
allowing the hosts to continue sending packets to remote destinations, via
the new VRRP Master.

Section 8.2 does specify that the VRRP router should not send any ARP
messages with a source MAC address of its physical address, but it only
specifies this behaviour at system boot or when configuring the interface.
It doesn't specify that the VRRP Virtual MAC address should be used as the
source MAC address for ARP requests during normal operation.

Reading through the RFC, I have noticed that it only specifies that the VRRP
Virtual MAC address is used as the source MAC address for selected traffic
eg VRRP advertisements. It does not cover general IP traffic being emitted
by the VRRP Master.

I would have thought that the VRRP Virtual MAC address should be used as the
source MAC address for all (ie ARP, IP) traffic with a destination within
the VRRP protected subnet address range. This would include directly
attached hosts, as well as down stream routers with an IP address within the
protected VRRP subnet.*

Regards,
Mark.

* which is where our interest is, as we want to have four router's working
as two VRRP pairs, facing each other. Each router would have static routes
with a next hop IP address of the remote pair VRRP IP Address. Proper
dynamic routing protocols would do the trick, however in our scenario we
want to avoid having our managed routers participate in the customer's
dynamic routing protocols. VRRP + Static routes gives us most of the
characteristics of a dynamic routing protocol, restricted to within the
scope of a single subnet.

--
mark smith
asia pacific vpn engineering - worldcom
(e) [email-masked] (p) +61 2 9434 5014

---

From: danny mitzel <[email-masked]>
Date: Wed, 19 Sep 2001 00:12:04 -0700 (PDT)

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.

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

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.

good luck!  danny

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/