On 13.07.2002 at 14:58:57, Adam Thornton <[EMAIL PROTECTED]> wrote: > After further experimentation with vrrpd, let me amplify my earlier \"it > doesn\'t work.\" > > It sort of works, in that the first router to claim the virtual IP > address sets it. Although it also does seem to delete your default > route.
I did see my default route go away, although I didn\'t notice at what point in the proceedings that occurred. I was also able to use the original IP address of the interface without problems. In fact, the virtual router IP address didn\'t show up in ifconfig output... > However, when that router goes down, vrrpd never fails over to the other > router. <snip> Here\'s what I see on the QDIO Guest LAN. It looks like the problem with the second and subsequent routers is that they do not receive the multicast advertisements from the first router. This causes vrrpd to try and take over the IP address, which fails because the first router is still up (I get \'duplicate IP address\' failure messages from qeth). So you end up with a bunch of vrrpd routers all thinking that they are the \'master\' (from the RFC). None of them will try and take on the router IP address when the real master fails because they all think they are already the master. The multicast registration works, because I can ping the VRRP multicast address and get ping responses from each of the guests on which I am running a vrrpd daemon. More diagnosis required, but I suspect it\'s something to do with MAC processing (and this ties in with some *very* strange things I am seeing using tcpdump and ntop on Guest LAN...). > VRT gets around this in a sneaky fashion by watching /var/log/messages > to see if setting that IP address failed. If it did it ifconfigs it > down, so Linux doesn\'t (incorrectly) believe that it owns that address. VRT sounds like good gear; I will have a look when I can. Cheers, Vic -- Vic Cross MACS mailto:[EMAIL PROTECTED] Networking, Linux, on zSeries and S/390
