0

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

2

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

  • I'm not sure if I understand the terminology correctly. By looking at "1.6. Definitions" in RFC5798, IMHO the part "A VRRP router may be configured with additional virtual router mappings..." translates to me that you may have more than one VRID in a VRRP router, obviously. However, the part that I am talking about (what happens inside the VRID) is defined by "A virtual router is defined by its virtual router identifier (VRID) and a set of either IPv4 or IPv6 address(es).". – Marki Aug 28 '15 at 21:31
  • Your're right, I have edited my answer, please review the new version. – JFL Aug 29 '15 at 20:28
  • RFC5798 talks about "address**(es)**" and "set"s of addresses everywhere and additionally section 5.2.9 states "This refers to one or more IPvX addresses associated with the virtual router." That's pretty clear to me. Even without a "must" anywhere, I guess just implementing for one address is border-line at best. Sure, they talk about a minimum in the count field. Meaning the "count" field possibly can be bigger, which is the case when the "set" is larger than one. If it should never be larger than one, you wouldn't need a set and you wouldn't need to define a minimum. – Marki Aug 29 '15 at 20:41
0

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.

  • Sure, you can do that. However you are then misusing your DR equipment for optimization/load-balancing purposes. Aside from making your environment much more complicated, what happens when you get to the point where you are fully utilizing both devices, and then one of them fails? Will the remaining one still be able to handle the load? – Marki Aug 28 '15 at 21:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.