VRRP Abuse

This article is abandonware. It has not been maintained since 2007 and is here only because some people still refer to it.

Introduction

This is a collection of various things I ran into while dealing with VRRP on Linux. Some of them may be of interest to someone out there. It is a bit random as my run-ins with VRRP are quite random.

Quirks

In order to function on Linux VRRP has to use an extra MAC address. It either tries to make the card add this extra MAC address or does some silly things with multicast address lists and promiscuity. Either one of these may cause a problem if the card has a bug in the respective functions. Very few cards are tested for this so essentially you should expect them to fail more often then not. So far my results are as follows:

• Via Rhine (various revisions) - 802.1q works, VRRP works, VRRP + 802.1q works, card goes into promiscuous mode so you have to have a switched network if you do not want to sacrifice performance. Multicast is leaky so processes listening on different interfaces will hear each other announcements.
• Intel Eepro100 - 802.1q works, VRRP works, VRRP + 802.1q works (Intel driver, becker driver 802.1q does not work). I have not done full testing for filter leakage, but as it is similar to the e1000 I would not expect it to be different.
• Intel E1000 - 802.1q works (accelerated), VRRP works, VRRP + 802.1q with caveats due to multicast filter leakage.
• NatSemi? 10/100- 802.1q does not work, VRRP does not work, interface goes belly up.
• Natsemi 1G - 802.1q works, VRRP does not work, interface goes belly up, have not tested 802.1q + VRRP

Caveats

VRRP on linux is as dependant on the multicast and virtual MAC implementation in the underlying ethernet driver. For most ( but not all) modern cards these work fine on a "plain" interface.

Adding 802.1q VLANs complicates matters considerably because most cards and drivers do not handle multicast filtering correctly on 802.1q subinterfaces. Applications bound to one subinterface "hear" multicast traffic from other subinterfaces. As a result the application has to perform extra filtering to honour only the correct announcements.

VRRP does not seem to perform any extra filtering and it will hear announcements from other interfaces. This is still OK if there is no auth configured. Configuring auth will cause VRRP processes belonging to different interfaces to hear each others traffic. The result is that it goes berserk. I still have not debugged this fully, and frankly, I cannot understand why it should care when the different processes and interfaces use different VRRP ids (definitely logical error in the code somewhere). None the less, the only way of running multiple vrrp instances on vlan subinterfaces on Linux is with the auth turned off.

Abuse & Misuse

VRRP on linux uses interface aliasing to assign an extra IP to the ethernet on the master. This is an IP address "proper" that can be used by the network stack to run applications of it. There are cases where running it may be a bad idea because some cards impose a performance penalty for the extra MACs used by VRRP.

That is not the case for Via-Rhine as shipped on the recent Via Epia motherboard. You can use this card/motherboard in a low load high availability application based on VRRP. No need for clustering, no need for extra software to maintain, no kernel patches, nothing.

This is VRRP misuse as it was never intended for protocol fallback. It is ugly... But it works quite well for something trivial like an end-user facing SME SMTP relay. It will also work fairly well for any other protocol where the clients do not maintain persistent connections and establish a connection only when necessary.

Caveats

Linux VRRP is "offensively coded" - it assumes that some system calls always succeed. When the backup router surrenders the virtual IP address back to the master it does not check if the "Change MAC" call has failed (Debian bug 404427). As a result the NIC may still have the vrrp virtual MAC and more then one system on the network will have the same MAC. That is usually enough to cause total mayhem.