File: README

package info (click to toggle)
vrrpd 1.0-1
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, lenny, sarge
  • size: 300 kB
  • ctags: 308
  • sloc: ansic: 2,618; makefile: 68; sh: 35
file content (70 lines) | stat: -rw-r--r-- 2,703 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
vrrpd version 1.0 2002/02/05
============================

The Monitored Interface extensions to vrrpd were originally
implemented to provide support for failover between a pair
of state-synchronised Checkpoint Firewall-1 modules. These
servers were HP LT6000r machines with two quad ethernet
NICs each and Red Hat Linux 7.0 (2.2 kernel required by
Firewall-1 v4.1 SP5).

Full credit to David Moore of Hewlett-Packard (NZ) Ltd
for initiating the project that made this necessary.

Anyway, an example command line for a primary server is;

  vrrpd -i eth0 -v 10 -p 200 -m "eth1 eth2 eth3" -c 100

This specifies eth0 as the interface to run the VRRP process
on, a VRID of 10, a priority of 200, that interfaces eth1, eth2
and eth3 are to be monitored for failure, and that if one of
these interfaces does fail, the priority is to be reduced by 100.

This allows the vrrpd process below (on the standby) to win;

  vrrpd -i eth0 -v 10 -p 150

as the master will advertise a priority of 100 while any of eth1-3
are disconnected or administratively down. Note that there is
little point in monitoring interfaces on the secondary UNLESS
you are load balancing PAIRS of interfaces across different
servers.

This configuration has been tested as providing transparent
failover for HP-UX systems as well as routers, with up to five
vrrpd daemons running concurrently on separate interfaces.
Each vrrpd process was monitoring the other four interfaces,
and was using the multicast VRRP MAC address so that arp
caching was not an issue. Intel 82559-based cards (eepro100
driver) were used.

During a failure (ie: ifconfig ethX down, pull cable out, turn
switch off, etc.) there is a 3x advertisement delay while the
VRRP election takes place. At the default advertisment interval
(1 sec), this was not long enough to cause TCP streams to break.

Interfaces are monitored in two different ways. The IFF_UP flag
is checked to detect an administrative shutdown, and the link
status bits of the MII transceiver status word are checked to
detect a failed cable, switch or port. This should work with
most Fast Ethernet drivers, but not with 10Mbps-only cards.
Gigabit NICs have not been tested.

There is no way to have different priority deltas for the
different monitored interfaces at present. However, it would
not be difficult to implement.

As a last point, if you are using this on a firewall (eg: FW-1),
do not forget to allow VRRP and IGMP traffic from the 'original'
IP addresses of all interfaces running vrrpd to destination
address 224.0.0.18, otherwise elections will not work.

Comments are welcome, I guess...


David Hunter
Technical Consultant
gen-i limited
Auckland, NZ
<david.hunter@gen-i.co.nz>