On Sunday 5th March the University started making use of the virtual router redundancy protocol (VRRP) on all its core routers. The idea of VRRP is to allow critical IP addresses, such as those of subnet default gateways, to be bound on more than one machine.

At the moment four subnets make use of VRRP to provide a redundant default gateway address. These subnets are (wireless), (wardens), (catering), and (voip). In each instance the default gateway for these subnets is bound by both struben.core and amm.core. It is intended that the number of subnets that make use of VRRP will increase over time.

The introduction of VRRP on campus has some implications that technical staff and those experimenting with systems should be aware of. Like VLANs, VRRP instances are identified by a unique number (known as the VRID). As with VLAN ids, VRIDs must, by definition, be organisationally unique and as a result their allocation must be controlled. The IT division intends to mange VRID space for the University in a similar way to the current allocation of VLAN ids. Current VRID allocations can be viewed at http://systems.ru.ac.za/networks/vlans.cgi.

Another important consideration is that VRRP is fundementally incompatible with another, similar protocol, the Common Address Redundancy Protocol (CARP). CARP was introduced by OpenBSD as a patent-free alternative to VRRP and has subsequently been imported into several other operating systems including FreeBSD. It is not clear as to whether the two protocols can co-exist on the same shared media segment as they share the same protocol number, multicast address and MAC address format. As a result of this it would be unwise to use CARP on any shared media segment passing through one of the core switches.

The implication of this is that anyone considering experimenting with or using either VRRP or CARP on the University's network should approach the Information Technology division to discuss the matter before implementing a solution.