Is Fortigate implementation of VRRP RFC compliant?

Question

By looking at RFC 3768, section 5.3.9 seems to indicate that indeed you should be able to configure more than one virtual IP in a single instance:

5.3.9.  IP Address(es)

   One or more IP addresses that are associated with the virtual router.
   The number of addresses included is specified in the "Count IP Addrs"
   field.  These fields are used for troubleshooting misconfigured
   routers.

What would you call a manufacturer that allows you to define secondary IPs on an interface/VLAN, but not in a VRRP instance on that interface? Instead, they say you should just create another instance. While that would work, interoperability with other gear may be at stake.

We're talking about Fortinet, and all I ever hear from them is "our gear just works that way".

Answer 1

It's hard to say exactly what the question is.

Maybe you should rephrase it, with something like :

"Is fortinet implementation of VRRP RFC-Compliant?"

The fact is the RFC3768 is obsoleted by RFC5798, where it is stated in section 3 :

VRRP specifies an election protocol to provide the virtual router function described earlier. All protocol messaging is performed using either IPv4 or IPv6 multicast datagrams; thus, the protocol can operate over a variety of multiaccess LAN technologies supporting IPvX multicast. Each link of a VRRP virtual router has a single well-known MAC address allocated to it. This document currently only details the mapping to networks using the IEEE 802 48-bit MAC address. The virtual router MAC address is used as the source in all periodic VRRP messages sent by the Master router to enable bridge learning in an extended LAN.

A virtual router is defined by its virtual router identifier (VRID) and a set of either IPv4 or IPv6 address(es). A VRRP router may associate a virtual router with its real address on an interface. The scope of each virtual router is restricted to a single LAN. A VRRP router may be configured with additional virtual router mappings and priority for virtual routers it is willing to back up. The mapping between the VRID and its IPvX address(es) must be coordinated among all VRRP routers on a LAN.

There is no restriction against reusing a VRID with a different address mapping on different LANs, nor is there a restriction against using the same VRID number for a set of IPv4 addresses and a set of IPv6 addresses; however, these are two different virtual routers.

Following your comment I goes trough the entire RFC and you're right in the fact it always mention "a set of IP address". It even speak about the "primary address" in a set.

So it's quite clear that the author itended the protocol to support multiple IPs per VRID.

However, nowhere in the RFC is mentioned something like "the router MUST support a set of X IP address for a given VRID"

5.2.5. Count IPvX Addr

This is the number of either IPv4 addresses or IPv6 addresses contained in this VRRP advertisement. The minimum value is 1.

So I would say, despite the fact the RFC clearly spoke about a "set" of IP address, unfortunately it lacks a "MUST" statement to force vendors to implement it.

I guess we have to conclude that, regarding this specific point, Fortinet implementation is RFC-compliant (but I would say, really border-line).

Answer 2

It appears to me that the only real questions that you ask is for comments about Fortinet. You probably aren't going to like this but I can see what might have been some motivation for their decision. (Please keep reading I promise I have a point to make.)

One of the true shortcomings (my opinion of course) of VRRP has to do with the amount of idle hardware that it employs. That is, if you want redundancy for LAN-A you must install and configure 2 routers - one as a primary router and the other as backup. The backup does very little all day long but monitor the primary router and if the primary never fails the backup might never route a single packet. If you have a need for secondary addresses then you can possibly split the workload (maybe even load balance) across those very two routers. Allow me to attempt to demonstrate:

Let's say you have 2 IP subnets (172.22.1.0/24 and 172.22.2.0/24) in use hanging from the same router interface and desrie to employ VRRP for redundancy. You could (add a second router obviously) service the first subnet (172.22.1.0/24) with VRRP instance 1 utilizing router-A as primary and router-B as backup. You could then service the second subnet (172.22.2.0/24) with VRRP instance 2 utilizing router-B as primary and router-A as backup. Thus tasking both routers with full time duties (possibly load balancing) at the same time you are providing redundancy for both subnets. Now you no longer have idle hardware.

Having said all of that you are correct that interoperability might be difficult with other manufacturers if/when one of them doesn't employ an entire standard.

I desperately hope you find this helpful in some small way.