On Sat, Jul 13, 2002 at 02:03:46AM +1000, Vic Cross wrote: > Hello all, > > Recent discussions about virtual routing and such led me to find if VRRP was > actually implemented for Linux. It is, and one (the?) implementation can be > found at http://w3.arobas.net/~jetienne/vrrpd/index.html. > > Downloaded, compiled, all ok. When I run the daemon, it appears to work fine > (although I haven\'t given it the real test of bringing up a second router). \
Er, no it doesn't. You will notice that your original IP address on that interface no longer works for the rest of the world. Or at least, I noticed that, on both OSA and HiperSockets networks. It also doesn't really bring up the new address in such a fashion that the rest of the world can use it. If you *are* able to use vrrpd in an emulated OSA or HIPER environment, please, please, *please* let me know how you did it. However, read on for a workaround, or if you're impatient, go to http://www.sinenomine.net/downloads/ and look at the VRT links. > I do see something odd, however - every second, when the VRRP advertisement goe\ s > out, I get the following messages on my console: > > qeth: QETH_IP_VERSION is 0 > qeth: skb->protocol=x0=0 > qeth: skb:01 00 5e 00 00 12 00 00 5e 00 01 32 08 00 45 00 > qeth: skb:00 28 18 3c 00 00 ff 70 b6 11 0a 00 03 06 e0 00 > > A couple of bytes in the hex dump do increment or decrement, but otherwise th\ e > messages are identical (and consistent, and annoying). I get that too. > I\'m running a SLES7 system with a 2.4.17-timer kernel under z/VM 4.3 on a z9\ 00. > The network is a QDIO Guest LAN. > > Could someone with an insight into the qeth driver shed some light on this? \ Is > it something to be concerned about, or should I just find a way to filter the > messages out of syslog? I suspect it's something to be concerned about, since the VRRP function doesn't seem to work. However, all is not lost. If what you want is a way to do a virtual IP address that fails over between two different router machines, I've written a fairly simple tool I call "vrt" to do just that. It works in our test environment. If you have ---R1---+ +---H1 ---R2---+ And R1 and R2 share a virtual address on each interface, so you have ---192.168.0.1---R1---192.168.1.1---+ | | | | | | VRT 192.168.0.3 VRT 192.168.1.3 +---192.168.1.4 H1 | | | | | | ---192.168.0.2---R2---192.168.1.2---+ And the outside world has a static route to 192.168.1.4 through 192.168.0.3, and 192.168.1.4 has 192.168.1.3 as its default route, then not only does it work, but if you clobber either R1 or R2, as long as they're both running VRT, the other router picks the route up, and TCP sessions even survive. That URL again: http://www.sinenomine.net/downloads/ And look for "VRT" on that page. Note that vrt does not implement either VRRP or HSRP. Instead it relies on ifconfig to check what IP addresses it owns, the humble ping to determine the reachability of the virtual address, and a little bit of grep to figure out if the OSA/HiperSocket objected to having its IP address set. It does assume that the qeth driver will complain and have its complaint logged if setting the IP address fails, and it further assumes that logger can write to the same file. Share and Enjoy, Adam
