You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(8) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Stealth <st...@al...> - 2013-05-06 16:23:01
|
Le 06/05/2013 17:51, Snehalata Prabhu a écrit : > Hello, > > Initially I tried vrrpd 1.0 and then version 1.8. It seems like the buffer was getting corrupted during the checksum calculation. I have a work around. I created a temp buffer and created the header with the temp buffer. After the checksum was calculated I put the contents of the temp buffer back into the original buffer. It seems to work that way. > > Thanks and regards, > Sneha > > Strange, maybe a problem with br-lan because vrrpd send packets from the physical nic eth0 10.1.1.1 with virtual 10.1.1.2 -> source IP address is 10.1.1.1 |
From: Snehalata P. <sk...@en...> - 2013-05-06 16:12:00
|
Hello, Initially I tried vrrpd 1.0 and then version 1.8. It seems like the buffer was getting corrupted during the checksum calculation. I have a work around. I created a temp buffer and created the header with the temp buffer. After the checksum was calculated I put the contents of the temp buffer back into the original buffer. It seems to work that way. Thanks and regards, Sneha -----Original Message----- From: st...@al... [mailto:st...@al...] Sent: Monday, May 6, 2013 11:12 AM To: Snehalata Prabhu Cc: vrr...@li... Subject: Re: [vrrpd] VRRPd packets going with incorrect IP addresses and checksum > Hello, > > I am having an issue with the VRRPd generated packets on my setup. > VRRPd packets are being sent out with incorrect IP addresses. I have > the following configuration. > > config 'vrrpd' 'vid1' > option enabled 1 > > # set the interface to run on > # (default: lan) > option interface 'lan' > > # set the ID of the virtual server (1-255) > # (default: 1) > option virtual_id '1' > > # set the IP address(es) of the virtual server > list virtual_ip '192.168.1.3' > > > # set the priority of this host in the virtual server > # (default: 100) > option priority '100' > > # set the advertisement interval (in seconds) > # (default: 1) > option delay '1' > > # don't handle the virtual MAC address > # (default: false) > # option no_virtual_mac '0' > > I start the vrrp process using the following command /usr/sbin/vrrpd > -v 1 -i br-lan -d 1 -p 100 192.168.1.3 > > > When I check the packets on wireshark I see the header has an source > IP address of 1.2.224.0 and the destination IP address of 0.18.0.0. > The VRRP header is also incorrect. It shows the IP address as 1.3.0.0. > For some reason the 192.168 seem to be missing from the packets. As a > result, the checksum caluculated is incorrect too. Can anyone please > help me out with this? > Thanks. > -------------- next part -------------- An HTML attachment was > scrubbed... > ---------------------------------------------------------------------- > -------- Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET Get 100% visibility into your production application - at no > cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Vrrpd-general mailing list > Vrr...@li... > https://lists.sourceforge.net/lists/listinfo/vrrpd-general > Hello, Which version ? |
From: Snehalata P. <sk...@en...> - 2013-05-03 16:38:51
|
Hello, I am having an issue with the VRRPd generated packets on my setup. VRRPd packets are being sent out with incorrect IP addresses. I have the following configuration. config 'vrrpd' 'vid1' option enabled 1 # set the interface to run on # (default: lan) option interface 'lan' # set the ID of the virtual server (1-255) # (default: 1) option virtual_id '1' # set the IP address(es) of the virtual server list virtual_ip '192.168.1.3' # set the priority of this host in the virtual server # (default: 100) option priority '100' # set the advertisement interval (in seconds) # (default: 1) option delay '1' # don't handle the virtual MAC address # (default: false) # option no_virtual_mac '0' I start the vrrp process using the following command /usr/sbin/vrrpd -v 1 -i br-lan -d 1 -p 100 192.168.1.3 When I check the packets on wireshark I see the header has an source IP address of 1.2.224.0 and the destination IP address of 0.18.0.0. The VRRP header is also incorrect. It shows the IP address as 1.3.0.0. For some reason the 192.168 seem to be missing from the packets. As a result, the checksum caluculated is incorrect too. Can anyone please help me out with this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... |
From: wimpunk <wi...@us...> - 2013-02-16 11:05:23
|
Hi, On 02/16/13 10:24, Stealth wrote: > >> Stealth, >> >> I'm the maintainer of vrrpd without the time to maintain. Maybe we >> could check if we can merge the two versions? >> >> Regards, >> >> wimpunk. >> >> ------------------------------------------------------------------------------ > > Hi winpunk, > > I've received a lot of email about advanced-vrrpd > and vrrpd, I think you are right, now there is a > confusion about this. For some odd reason I didn't got any mentions on the changes. I'll take a closer look what went wrong. > I'm not familiar with the sourceforges tools, can > you merge the project please ? Maybe first save > the old version in directory named like "old" or > something like that I'm trying to get used to the new system on sf.net. That could be a good idea to put them together. I'll try to find out what's possible and what isn't. Which environment do you prefer to work on? git or svn? > The code and debian packages are here > https://sourceforge.net/projects/vrrpd/files/vrrpd/Unofficial/ > (latest version 1.8) > Just saw it, as I said I think it's a bit weird I didn't got any mention of the sf system. > Thanks > > Frederic Bourgeois > > Nice job! wim. |
From: Stealth <st...@al...> - 2013-02-16 09:43:47
|
> Stealth, > > I'm the maintainer of vrrpd without the time to maintain. Maybe we > could check if we can merge the two versions? > > Regards, > > wimpunk. > > ------------------------------------------------------------------------------ Hi winpunk, I've received a lot of email about advanced-vrrpd and vrrpd, I think you are right, now there is a confusion about this. I'm not familiar with the sourceforges tools, can you merge the project please ? Maybe first save the old version in directory named like "old" or something like that The code and debian packages are here https://sourceforge.net/projects/vrrpd/files/vrrpd/Unofficial/ (latest version 1.8) Thanks Frederic Bourgeois |
From: Stealth <st...@al...> - 2012-08-06 09:36:36
|
> Stealth, > > I'm the maintainer of vrrpd without the time to maintain. Maybe we > could check if we can merge the two versions? > > Regards, > > wimpunk. > Hi wimpunk, Maybe it would be a better thing that a new maintainer(s) takes this work ? For better stability with continuing bug fixes and long-term support //What do you think to make an announcement on sourceforge (or other websites ?), something like, new maintainer needed for vrrpd. Regards, Fred // -------------- next part -------------- An HTML attachment was scrubbed... |
From: wimpunk <wi...@us...> - 2012-07-30 20:19:35
|
On 07/25/12 21:36, Stealth wrote: > Le 25/07/2012 11:35, Florian Schoedel a écrit : >> Do anyone know what's the difference between 1.0 and Advanced Vrrpd 1.6 >> regarding the problem I've described below? Now I've installed 1.6 and >> mentioned that this behaviour doesn't occure anymore. >> How long will it take until 1.6 is included in stable debian repositories? >> >> Best regards, >> >> Florian >> >> > > Hi, > > I'm the maintainer of this version - 1.6 - an > unofficial fork of vrrpd > I think Vrrpd need a new leader now and > Unfortunately I have no time for this. > > So for stable debian repositories ... > > Best regards, Fred > Stealth, I'm the maintainer of vrrpd without the time to maintain. Maybe we could check if we can merge the two versions? Regards, wimpunk. |
From: Stealth <st...@al...> - 2012-07-25 19:53:16
|
Le 25/07/2012 11:35, Florian Schoedel a écrit : > Do anyone know what's the difference between 1.0 and Advanced Vrrpd 1.6 > regarding the problem I've described below? Now I've installed 1.6 and > mentioned that this behaviour doesn't occure anymore. > How long will it take until 1.6 is included in stable debian repositories? > > Best regards, > > Florian > > Hi, I'm the maintainer of this version - 1.6 - an unofficial fork of vrrpd I think Vrrpd need a new leader now and Unfortunately I have no time for this. So for stable debian repositories ... Best regards, Fred |
From: Florian S. <Flo...@me...> - 2012-07-25 09:35:17
|
Do anyone know what's the difference between 1.0 and Advanced Vrrpd 1.6 regarding the problem I've described below? Now I've installed 1.6 and mentioned that this behaviour doesn't occure anymore. How long will it take until 1.6 is included in stable debian repositories? Best regards, Florian -----Original Message----- From: "Florian Schoedel" <Flo...@me...> To: vrr...@li... Date: Wed, 25 Jul 2012 10:39:47 +0200 Subject: [vrrpd] vrrpd and quagga with bgp Hello, I've encountered a very strange problem regarding the fail over behaviour with vrrpd in conjunction with quagga. My Setup: R3 (no vrrp at all) ___________________________|_______________ | (eth1 no vrrp) | (eth1 no vrrp) R1 R2 __| (eth2 with vrrp)_____________|_(eth2 with vrrp)___ | Client Ubuntu 12.04 / 3.2.0-23-generic 64 bit (on all routers) / VRRPD 1.0 (on R1 and R2) / Quagga : 0.99.20.1-0ubuntu0.12.04.2 (on all routers) R1 and R2 are both route reflector clients of R3; R3 is the Route reflector (I thing that doesn't matter here). Each of the three routers has the full internet routing table with about 450000 routes. R1 and R2 are running vrrpd (version 1.0) in order to share the same virtual IP address on eth2. The failover works fine after I shut down R1; The failback also works as expected. I have noticed that this only works while the routing wasn't filled with all routes. I've seen that vrrpd is running at 100% of CPU during failover. This is when there are about 50k routes in kernel routing table. This takes about 1 minute. As the routing table grows the failover time takes longer and longer. With the full routing table the failover takes about 10 minutes. Are there any known issues regarding such a setup (vrrpd + quagga)? Thanks a lot Florian Thüga MeteringService GmbH, Sitz: Naila, eingetragen beim Amtsgericht in Hof, HRB: 4125 Geschäftsführer: Peter Hornfischer StNr.: 223/140/10756, geführt beim Finanzamt Hof, USt-ID-Nr.: DE 246359579 Bankverbindung: BayernLB München, BLZ 700 500 00, Konto-Nr. 4113816 Geschäftsadresse Thüga MeteringService GmbH, Zum Kugelfang 2, 95119 Naila Haftungsausschluss: Diese Nachricht erhält vertrauliche Informationen, welche nur für den Empfänger bestimmt sind. Falls Sie diese Nachricht irrtümlicherweise erhalten haben, benachrichtigen Sie uns bitte sofort und vernichten Sie sämtliche Kopien (digital/Papier). Danke. Disclaimer: The information contained in this message is confidential and may only be used by the intended recipient. If you received it in error, please notify us immediately and destroy any copies (digital and paper). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Vrrpd-general mailing list Vrr...@li... https://lists.sourceforge.net/lists/listinfo/vrrpd-general Thüga MeteringService GmbH, Sitz: Naila, eingetragen beim Amtsgericht in Hof, HRB: 4125 Geschäftsführer: Peter Hornfischer StNr.: 223/140/10756, geführt beim Finanzamt Hof, USt-ID-Nr.: DE 246359579 Bankverbindung: BayernLB München, BLZ 700 500 00, Konto-Nr. 4113816 Geschäftsadresse Thüga MeteringService GmbH, Zum Kugelfang 2, 95119 Naila Haftungsausschluss: Diese Nachricht erhält vertrauliche Informationen, welche nur für den Empfänger bestimmt sind. Falls Sie diese Nachricht irrtümlicherweise erhalten haben, benachrichtigen Sie uns bitte sofort und vernichten Sie sämtliche Kopien (digital/Papier). Danke. Disclaimer: The information contained in this message is confidential and may only be used by the intended recipient. If you received it in error, please notify us immediately and destroy any copies (digital and paper). Thank you. Thüga MeteringService GmbH, Sitz: Naila, eingetragen beim Amtsgericht in Hof, HRB: 4125 Geschäftsführer: Peter Hornfischer StNr.: 223/140/10756, geführt beim Finanzamt Hof, USt-ID-Nr.: DE 246359579 Bankverbindung: BayernLB München, BLZ 700 500 00, Konto-Nr. 4113816 Geschäftsadresse Thüga MeteringService GmbH, Zum Kugelfang 2, 95119 Naila Haftungsausschluss: Diese Nachricht erhält vertrauliche Informationen, welche nur für den Empfänger bestimmt sind. Falls Sie diese Nachricht irrtümlicherweise erhalten haben, benachrichtigen Sie uns bitte sofort und vernichten Sie sämtliche Kopien (digital/Papier). Danke. Disclaimer: The information contained in this message is confidential and may only be used by the intended recipient. If you received it in error, please notify us immediately and destroy any copies (digital and paper). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... |
From: Florian S. <Flo...@me...> - 2012-07-25 09:06:49
|
Hello, I've encountered a very strange problem regarding the fail over behaviour with vrrpd in conjunction with quagga. My Setup: R3 (no vrrp at all) ___________________________|_______________ | (eth1 no vrrp) | (eth1 no vrrp) R1 R2 __| (eth2 with vrrp)_____________|_(eth2 with vrrp)___ | Client Ubuntu 12.04 / 3.2.0-23-generic 64 bit (on all routers) / VRRPD 1.0 (on R1 and R2) / Quagga : 0.99.20.1-0ubuntu0.12.04.2 (on all routers) R1 and R2 are both route reflector clients of R3; R3 is the Route reflector (I thing that doesn't matter here). Each of the three routers has the full internet routing table with about 450000 routes. R1 and R2 are running vrrpd (version 1.0) in order to share the same virtual IP address on eth2. The failover works fine after I shut down R1; The failback also works as expected. I have noticed that this only works while the routing wasn't filled with all routes. I've seen that vrrpd is running at 100% of CPU during failover. This is when there are about 50k routes in kernel routing table. This takes about 1 minute. As the routing table grows the failover time takes longer and longer. With the full routing table the failover takes about 10 minutes. Are there any known issues regarding such a setup (vrrpd + quagga)? Thanks a lot Florian Thüga MeteringService GmbH, Sitz: Naila, eingetragen beim Amtsgericht in Hof, HRB: 4125 Geschäftsführer: Peter Hornfischer StNr.: 223/140/10756, geführt beim Finanzamt Hof, USt-ID-Nr.: DE 246359579 Bankverbindung: BayernLB München, BLZ 700 500 00, Konto-Nr. 4113816 Geschäftsadresse Thüga MeteringService GmbH, Zum Kugelfang 2, 95119 Naila Haftungsausschluss: Diese Nachricht erhält vertrauliche Informationen, welche nur für den Empfänger bestimmt sind. Falls Sie diese Nachricht irrtümlicherweise erhalten haben, benachrichtigen Sie uns bitte sofort und vernichten Sie sämtliche Kopien (digital/Papier). Danke. Disclaimer: The information contained in this message is confidential and may only be used by the intended recipient. If you received it in error, please notify us immediately and destroy any copies (digital and paper). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... |
From: Stealth <st...@al...> - 2012-02-19 13:07:43
|
Le 17/02/2012 20:24, Jon Foster a écrit : > I'd like to move forward using vrrpd but IPv6 is mandatory. Keepalived > does IPv6 but it has "suicidal" tendencies. It peels off all IPs from a > nic when shutting down, even if they aren't under VRRP control. That in > combination with your simple configuration makes vrrpd my preferred > solution. > > THX - Jon > About this point, perhaps you can use a version with up/down script ? An example with vlan interfaces and fake VIP ./vrrpd -i eth0 10.1.1.1 -v 51 -U /etc/scripts/MASTER.sh -D /etc/scripts/DOWN.sh Master script: ifconfig eth0.200 192.168.200.254 netmask 255.255.255.0 up ifconfig eth0.201 192.168.201.254 netmask 255.255.255.0 up ifconfig eth0.210 192.168.210.254 netmask 255.255.255.0 up And of course in backup script: vconfig rem eth0.200 vconfig rem eth0.201 vconfig rem eth0.210 All address will use the same vmac without problem Fred |
From: Jon F. <jo...@jf...> - 2012-02-17 19:25:14
|
It seems that there has been very little activity on vrrpd. Notes that I've seen on other sites including Debian's seem to indicate that vrrpd has been abandoned. Yet it seems that many patches are floating about in the wild and some useful ones on your source forge site. So I'm left wondering: 1. Has vrrpd been abandoned by this crew? 2. Is there any plans for active development on it? 3. Are there any plans to incorporate IPv6 functionality? 4. What about accumulating the patches that various distros, like Debian, have put together and supply in their standard packages? I'd like to move forward using vrrpd but IPv6 is mandatory. Keepalived does IPv6 but it has "suicidal" tendencies. It peels off all IPs from a nic when shutting down, even if they aren't under VRRP control. That in combination with your simple configuration makes vrrpd my preferred solution. THX - Jon -- Jon Foster JF Possibilities, Inc. jo...@jf... 541-410-2760 Making computers work for you! |
From: Grzegorz W. <grz...@gm...> - 2011-12-29 01:59:25
|
Ok, there is no more problem. My answer was iptables -F |
From: Grzegorz W. <grz...@gm...> - 2011-12-29 01:24:17
|
I have problem with running vrrpd. On one computer i run: sudo ./vrrpd -i eth0 -n -v 11 -p 150 10.33.8.100 -d 2 on second computer: sudo ./vrrpd -i eth0 -n -v 11 -p 200 10.33.8.100 -d 2 on first i have: Dec 29 02:12:52 Spock vrrpd[14854]: VRRP ID 11 on eth0 (prio: 150): we are now the master router. on second: Dec 29 02:03:33 balancer0 vrrpd[1912]: VRRP ID 11 on eth0 (prio: 200): we are now the master router. Both are in master status. from tcpdump i get: 02:23:02.042717 IP 10.33.8.63 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 200, authtype none, intvl 2s, length 20 02:23:03.367653 IP 10.33.8.38 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 150, authtype none, intvl 2s, length 20 02:23:04.048119 IP 10.33.8.63 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 200, authtype none, intvl 2s, length 20 02:23:05.370008 IP 10.33.8.38 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 150, authtype none, intvl 2s, length 20 02:23:06.052518 IP 10.33.8.63 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 200, authtype none, intvl 2s, length 20 02:23:07.372955 IP 10.33.8.38 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 150, authtype none, intvl 2s, length 20 02:23:08.057413 IP 10.33.8.63 > 224.0.0.18: VRRPv2, Advertisement, vrid 11, prio 200, authtype none, intvl 2s, length 20 vrrpd is compiled from svn. Please reply ASAP. |
From: wimpunk <wi...@us...> - 2010-12-21 08:47:06
|
It was waiting because you weren't subcribed to the list. I approved it to let others know you have to subscribe before you can post. Blame the spammers. wimpunk. On Fri, 2010-12-17 at 08:51 -0200, Carlos Xavier wrote: > HI. > Im sorry. I dont know how this mail just hit the list now, it was sent on November 20, 2010. > Please just ignore it. > > Regards, > Carlos Xavier. > > > ----- Original Message ----- > From: "Carlos Xavier" <cb...@co...> > To: <vrr...@li...> > Sent: Saturday, November 20, 2010 3:47 AM > Subject: [vrrpd] Is this list working? > > > > Hi. > > I cant see a place to register on the list. > > Is there anobody reading this list and answering it, or should iI try to cntact the developer? > > > > Im doing some tests with VRRPD and found a issue on it running on a Linux box and I need to talk > > to > > someone. > > > > Regards, > > Carlos > > > > > > ------------------------------------------------------------------------------ > > Lotusphere 2011 > > Register now for Lotusphere 2011 and learn how > > to connect the dots, take your collaborative environment > > to the next level, and enter the era of Social Business. > > http://p.sf.net/sfu/lotusphere-d2d > > _______________________________________________ > > Vrrpd-general mailing list > > Vrr...@li... > > https://lists.sourceforge.net/lists/listinfo/vrrpd-general > > > > > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Vrrpd-general mailing list > Vrr...@li... > https://lists.sourceforge.net/lists/listinfo/vrrpd-general |
From: Stealth <st...@al...> - 2010-12-17 16:34:56
|
Hi, If you want to try vrrpd with this patch http://numsys.eu/Vrrpd/Vrrpd-FredB-1.2_12-2010.tar.gz Le 13/12/2010 19:53, Stealth a écrit : > Hi, > > I don't see that with my version > > debian lenny > > ./vrrpd -i eth0 -v 70 -p 40 192.168.2.251 > > Dec 13 19:38:52 Arrakis vrrpd: VRRP ID 70 on eth0: > we are already a backup router, going to STATE INIT. > Dec 13 19:38:52 Arrakis vrrpd: VRRP ID 70 on eth0: > we are now a backup router (STATE INIT). > Dec 13 19:38:56 Arrakis vrrpd: VRRP ID 70 on eth0: > we are now the master router. > > ping 192.168.2.251 > PING 192.168.2.251 (192.168.2.251) 56(84) bytes of > data. > 64 bytes from 192.168.2.251: icmp_req=1 ttl=64 > time=0.056 ms > 64 bytes from 192.168.2.251: icmp_req=2 ttl=64 > time=0.046 ms > 64 bytes from 192.168.2.251: icmp_req=3 ttl=64 > time=0.056 ms > > Please, can you repost your patch to the mailing > list (your AV program has deleted it//) > > Le 13/12/2010 18:48, Carlos Xavier a écrit : >> Hi, >> I was afraid my patch had a trouble but it doesnt have. >> >> Deeper tests proved there is a hidden bug on the VRRPD daemon related to the >> vrrp ID. I had the following configuration: >> >> #!/bin/bash >> /usr/sbin/vrrpd -i eth0 -v 50 -p 40 200.160.211.132 >> /usr/sbin/vrrpd -i eth1 -v 60 -p 40 172.31.0.4 >> /usr/sbin/vrrpd -i eth2 -v 70 -p 40 192.168.2.251 >> /usr/sbin/vrrpd -i eth3 -v 80 -p 40 172.31.3.2 >> >> Every time the daemons were started the eth2 didnt get its MAC address >> changed nor the virtual ip address allocated >> and do not start sending the VRRP announc on the interface. >> I suspected on the patch, and used a deamon with no changes, the behavior >> for my surprise was the same. I begin >> to comment the lines of the start daemons until I get only the one related >> to the eth2, and after starting the interface >> remained not getting any change. By a chance I changed the VRRP ID from 70 >> to 40 and the interface was changed. >> >> To make a full test I used the following configuration: >> >> #!/bin/bash >> /usr/sbin/vrrpd -i eth0 -v 50 -p 40 200.160.211.132 >> /usr/sbin/vrrpd -i eth1 -v 60 -p 40 172.31.0.4 >> /usr/sbin/vrrpd -i eth2 -v 40 -p 40 192.168.2.251 >> /usr/sbin/vrrpd -i eth3 -v 80 -p 40 172.31.3.2 >> >> Every interface was correctly configured, just to check, I start testing >> VRRP ID from 68 to 75 and noticed the trouble >> happens only with the ID 70, it doesnt matter wich interface it is alocated. >> >> For the FreB version the effect of this issue was even worse, making the >> daemons hang around waiting the >> interface status to come up: >> >> Dec 10 23:58:36 rjgw vrrpd: VRRP ID 60 on eth1: Wait 5 s >> Dec 10 23:58:41 rjgw vrrpd: VRRP ID 50 on eth0: WARNING: No state MASTER -> >> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 >> Dec 10 23:58:41 rjgw vrrpd: VRRP ID 50 on eth0: Wait 5 s >> Dec 10 23:58:41 rjgw vrrpd: VRRP ID 80 on eth3: WARNING: No state MASTER -> >> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 >> Dec 10 23:58:41 rjgw vrrpd: VRRP ID 80 on eth3: Wait 5 s >> Dec 10 23:58:41 rjgw vrrpd: VRRP ID 60 on eth1: WARNING: No state MASTER -> >> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 >> Dec 10 23:58:41 rjgw vrrpd: VRRP ID 60 on eth1: Wait 5 s >> Dec 10 23:58:46 rjgw vrrpd: VRRP ID 50 on eth0: WARNING: No state MASTER -> >> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 >> Dec 10 23:58:46 rjgw vrrpd: VRRP ID 50 on eth0: Wait 5 s >> Dec 10 23:58:46 rjgw vrrpd: VRRP ID 80 on eth3: WARNING: No state MASTER -> >> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 >> Dec 10 23:58:46 rjgw vrrpd: VRRP ID 80 on eth3: Wait 5 s >> Dec 10 23:58:46 rjgw vrrpd: VRRP ID 60 on eth1: WARNING: No state MASTER -> >> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 >> >> I dont know what makes this happen but you cant use the ID 70 with the >> daemon, maybe a bug ticked should be oppened. >> >> The patch is ready to be tested, actualy im curently using the modified >> daemon. >> >> Best regards, >> Carlos Xavier. >> >> >> >> ----- Original Message ----- >> From: "Carlos Xavier"<cb...@co...> >> To:<vrr...@li...> >> Sent: Friday, December 10, 2010 1:42 PM >> Subject: Re: [vrrpd] Vanishing routes, solved - patch attached >> >> >> >> Hi. >> >> I apologize, it seams to have a fault on the patch, I´m investigating what >> is going on. >> >> Best Regards, >> Carlos Xavier. >> >> >> >> >> >> >> __________ Informação do ESET NOD32 Antivirus, versão da vacina 5699 (20101213) __________ >> >> A mensagem foi verificada pelo ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> ------------------------------------------------------------------------------ >> Lotusphere 2011 >> Register now for Lotusphere 2011 and learn how >> to connect the dots, take your collaborative environment >> to the next level, and enter the era of Social Business. >> http://p.sf.net/sfu/lotusphere-d2d >> _______________________________________________ >> Vrrpd-general mailing list >> Vrr...@li... >> https://lists.sourceforge.net/lists/listinfo/vrrpd-general >> > -------------- next part -------------- > An HTML attachment was scrubbed... > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Vrrpd-general mailing list > Vrr...@li... > https://lists.sourceforge.net/lists/listinfo/vrrpd-general > |
From: Carlos X. <cb...@co...> - 2010-12-17 11:24:54
|
Hi. Just to close this topic and let it well documented. The patch is ok and can be retieved at: https://sourceforge.net/tracker/?func=detail&aid=3139013&group_id=61952&atid=498951 I also oppened a ticket aiming the patch be added to the main source of VRRPD. Best Regards. Carlos Xavier |
From: Carlos X. <cb...@co...> - 2010-12-17 10:53:01
|
HI. Im sorry. I dont know how this mail just hit the list now, it was sent on November 20, 2010. Please just ignore it. Regards, Carlos Xavier. ----- Original Message ----- From: "Carlos Xavier" <cb...@co...> To: <vrr...@li...> Sent: Saturday, November 20, 2010 3:47 AM Subject: [vrrpd] Is this list working? > Hi. > I cant see a place to register on the list. > Is there anobody reading this list and answering it, or should iI try to cntact the developer? > > Im doing some tests with VRRPD and found a issue on it running on a Linux box and I need to talk > to > someone. > > Regards, > Carlos > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Vrrpd-general mailing list > Vrr...@li... > https://lists.sourceforge.net/lists/listinfo/vrrpd-general > > |
From: Stealth <st...@al...> - 2010-12-13 18:53:36
|
Hi, I don't see that with my version debian lenny ./vrrpd -i eth0 -v 70 -p 40 192.168.2.251 Dec 13 19:38:52 Arrakis vrrpd: VRRP ID 70 on eth0: we are already a backup router, going to STATE INIT. Dec 13 19:38:52 Arrakis vrrpd: VRRP ID 70 on eth0: we are now a backup router (STATE INIT). Dec 13 19:38:56 Arrakis vrrpd: VRRP ID 70 on eth0: we are now the master router. ping 192.168.2.251 PING 192.168.2.251 (192.168.2.251) 56(84) bytes of data. 64 bytes from 192.168.2.251: icmp_req=1 ttl=64 time=0.056 ms 64 bytes from 192.168.2.251: icmp_req=2 ttl=64 time=0.046 ms 64 bytes from 192.168.2.251: icmp_req=3 ttl=64 time=0.056 ms Please, can you repost your patch to the mailing list (your AV program has deleted it//) Le 13/12/2010 18:48, Carlos Xavier a écrit : > Hi, > I was afraid my patch had a trouble but it doesnt have. > > Deeper tests proved there is a hidden bug on the VRRPD daemon related to the > vrrp ID. I had the following configuration: > > #!/bin/bash > /usr/sbin/vrrpd -i eth0 -v 50 -p 40 200.160.211.132 > /usr/sbin/vrrpd -i eth1 -v 60 -p 40 172.31.0.4 > /usr/sbin/vrrpd -i eth2 -v 70 -p 40 192.168.2.251 > /usr/sbin/vrrpd -i eth3 -v 80 -p 40 172.31.3.2 > > Every time the daemons were started the eth2 didnt get its MAC address > changed nor the virtual ip address allocated > and do not start sending the VRRP announc on the interface. > I suspected on the patch, and used a deamon with no changes, the behavior > for my surprise was the same. I begin > to comment the lines of the start daemons until I get only the one related > to the eth2, and after starting the interface > remained not getting any change. By a chance I changed the VRRP ID from 70 > to 40 and the interface was changed. > > To make a full test I used the following configuration: > > #!/bin/bash > /usr/sbin/vrrpd -i eth0 -v 50 -p 40 200.160.211.132 > /usr/sbin/vrrpd -i eth1 -v 60 -p 40 172.31.0.4 > /usr/sbin/vrrpd -i eth2 -v 40 -p 40 192.168.2.251 > /usr/sbin/vrrpd -i eth3 -v 80 -p 40 172.31.3.2 > > Every interface was correctly configured, just to check, I start testing > VRRP ID from 68 to 75 and noticed the trouble > happens only with the ID 70, it doesnt matter wich interface it is alocated. > > For the FreB version the effect of this issue was even worse, making the > daemons hang around waiting the > interface status to come up: > > Dec 10 23:58:36 rjgw vrrpd: VRRP ID 60 on eth1: Wait 5 s > Dec 10 23:58:41 rjgw vrrpd: VRRP ID 50 on eth0: WARNING: No state MASTER -> > Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 > Dec 10 23:58:41 rjgw vrrpd: VRRP ID 50 on eth0: Wait 5 s > Dec 10 23:58:41 rjgw vrrpd: VRRP ID 80 on eth3: WARNING: No state MASTER -> > Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 > Dec 10 23:58:41 rjgw vrrpd: VRRP ID 80 on eth3: Wait 5 s > Dec 10 23:58:41 rjgw vrrpd: VRRP ID 60 on eth1: WARNING: No state MASTER -> > Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 > Dec 10 23:58:41 rjgw vrrpd: VRRP ID 60 on eth1: Wait 5 s > Dec 10 23:58:46 rjgw vrrpd: VRRP ID 50 on eth0: WARNING: No state MASTER -> > Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 > Dec 10 23:58:46 rjgw vrrpd: VRRP ID 50 on eth0: Wait 5 s > Dec 10 23:58:46 rjgw vrrpd: VRRP ID 80 on eth3: WARNING: No state MASTER -> > Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 > Dec 10 23:58:46 rjgw vrrpd: VRRP ID 80 on eth3: Wait 5 s > Dec 10 23:58:46 rjgw vrrpd: VRRP ID 60 on eth1: WARNING: No state MASTER -> > Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 > > I dont know what makes this happen but you cant use the ID 70 with the > daemon, maybe a bug ticked should be oppened. > > The patch is ready to be tested, actualy im curently using the modified > daemon. > > Best regards, > Carlos Xavier. > > > > ----- Original Message ----- > From: "Carlos Xavier"<cb...@co...> > To:<vrr...@li...> > Sent: Friday, December 10, 2010 1:42 PM > Subject: Re: [vrrpd] Vanishing routes, solved - patch attached > > > > Hi. > > I apologize, it seams to have a fault on the patch, I´m investigating what > is going on. > > Best Regards, > Carlos Xavier. > > > > > > > __________ Informação do ESET NOD32 Antivirus, versão da vacina 5699 (20101213) __________ > > A mensagem foi verificada pelo ESET NOD32 Antivirus. > > http://www.eset.com > > > > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Vrrpd-general mailing list > Vrr...@li... > https://lists.sourceforge.net/lists/listinfo/vrrpd-general > -------------- next part -------------- An HTML attachment was scrubbed... |
From: Carlos X. <cb...@co...> - 2010-12-13 17:50:02
|
Hi, I was afraid my patch had a trouble but it doesnt have. Deeper tests proved there is a hidden bug on the VRRPD daemon related to the vrrp ID. I had the following configuration: #!/bin/bash /usr/sbin/vrrpd -i eth0 -v 50 -p 40 200.160.211.132 /usr/sbin/vrrpd -i eth1 -v 60 -p 40 172.31.0.4 /usr/sbin/vrrpd -i eth2 -v 70 -p 40 192.168.2.251 /usr/sbin/vrrpd -i eth3 -v 80 -p 40 172.31.3.2 Every time the daemons were started the eth2 didnt get its MAC address changed nor the virtual ip address allocated and do not start sending the VRRP announc on the interface. I suspected on the patch, and used a deamon with no changes, the behavior for my surprise was the same. I begin to comment the lines of the start daemons until I get only the one related to the eth2, and after starting the interface remained not getting any change. By a chance I changed the VRRP ID from 70 to 40 and the interface was changed. To make a full test I used the following configuration: #!/bin/bash /usr/sbin/vrrpd -i eth0 -v 50 -p 40 200.160.211.132 /usr/sbin/vrrpd -i eth1 -v 60 -p 40 172.31.0.4 /usr/sbin/vrrpd -i eth2 -v 40 -p 40 192.168.2.251 /usr/sbin/vrrpd -i eth3 -v 80 -p 40 172.31.3.2 Every interface was correctly configured, just to check, I start testing VRRP ID from 68 to 75 and noticed the trouble happens only with the ID 70, it doesnt matter wich interface it is alocated. For the FreB version the effect of this issue was even worse, making the daemons hang around waiting the interface status to come up: Dec 10 23:58:36 rjgw vrrpd: VRRP ID 60 on eth1: Wait 5 s Dec 10 23:58:41 rjgw vrrpd: VRRP ID 50 on eth0: WARNING: No state MASTER -> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 Dec 10 23:58:41 rjgw vrrpd: VRRP ID 50 on eth0: Wait 5 s Dec 10 23:58:41 rjgw vrrpd: VRRP ID 80 on eth3: WARNING: No state MASTER -> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 Dec 10 23:58:41 rjgw vrrpd: VRRP ID 80 on eth3: Wait 5 s Dec 10 23:58:41 rjgw vrrpd: VRRP ID 60 on eth1: WARNING: No state MASTER -> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 Dec 10 23:58:41 rjgw vrrpd: VRRP ID 60 on eth1: Wait 5 s Dec 10 23:58:46 rjgw vrrpd: VRRP ID 50 on eth0: WARNING: No state MASTER -> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 Dec 10 23:58:46 rjgw vrrpd: VRRP ID 50 on eth0: Wait 5 s Dec 10 23:58:46 rjgw vrrpd: VRRP ID 80 on eth3: WARNING: No state MASTER -> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 Dec 10 23:58:46 rjgw vrrpd: VRRP ID 80 on eth3: Wait 5 s Dec 10 23:58:46 rjgw vrrpd: VRRP ID 60 on eth1: WARNING: No state MASTER -> Another vrrpd with state Backup : /var/run/vrrpdstatedowneth2 I dont know what makes this happen but you cant use the ID 70 with the daemon, maybe a bug ticked should be oppened. The patch is ready to be tested, actualy im curently using the modified daemon. Best regards, Carlos Xavier. ----- Original Message ----- From: "Carlos Xavier" <cb...@co...> To: <vrr...@li...> Sent: Friday, December 10, 2010 1:42 PM Subject: Re: [vrrpd] Vanishing routes, solved - patch attached Hi. I apologize, it seams to have a fault on the patch, I´m investigating what is going on. Best Regards, Carlos Xavier. __________ Informação do ESET NOD32 Antivirus, versão da vacina 5699 (20101213) __________ A mensagem foi verificada pelo ESET NOD32 Antivirus. http://www.eset.com |
From: Carlos X. <cb...@co...> - 2010-12-10 15:42:46
|
Hi. I apologize, it seams to have a fault on the patch, I´m investigating what is going on. Best Regards, Carlos Xavier. __________ Informação do ESET NOD32 Antivirus, versão da vacina 5692 (20101210) __________ A mensagem foi verificada pelo ESET NOD32 Antivirus. http://www.eset.com |
From: Carlos X. <cb...@co...> - 2010-12-08 20:19:50
|
Hi. I took some time testing the VRRPD and I could observe that when it starts the master host loose its default route (after some time, I realize that any routes belonging to a VRRP interface are lost). Also at the time of the change from Backup to Master the same thing happens, and depending on the network switch (auto negotiation and so on), the interface was kept bouncing until the VRRPd is stopped. I work with Nokia IPSO, they use VRRPD, and you dont see this behavior on VRRPD when it is starting or the hosts are swapping the roles. Tanks to the well documented code of the daemon I found out that the interfaces are set down to change the hardware address and set up again, because of the kernel refusing to change the address when the interface is up. At the time VRRPD was developed the requirement of this action was true, but with the kernel 2.6 this is no need anymore. This can be quick checked with the "ip" command changing the hardware address. For example you can set up a new MAC Address on the interface with: ip link set eth0 address 00:00:5e:00:01:40 To avoid the trouble of shutting down the interfaces, I made a patch that checks the Kernel version and major number to see if it is 2.6 or greater. It only set down the interfaces in case the Kernel version/major number is smaler than 2.6. Im sending attached the patch for the official version of VRRPD and also for the FredB´s version. Its a level 1 patch. Im not a well skilled coder, maybe you can improve it :-) Best Regards, Carlos Xavier __________ Informação do ESET NOD32 Antivirus, versão da vacina 5686 (20101208) __________ A mensagem foi verificada pelo ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... -------------- next part -------------- A non-text attachment was scrubbed... Name: vrrpd.c.patch Type: application/octet-stream Size: 2962 bytes Desc: not available -------------- next part -------------- A non-text attachment was scrubbed... Name: Vrrpd-FredB-vrrpd.c.patch Type: application/octet-stream Size: 3724 bytes Desc: not available |
From: <st...@al...> - 2010-11-23 09:06:55
|
Hi, Quick answer > One thing I could notice is the creation of the address "inet > 255.255.255.255/32 scope global ethxx" > on all the interfaces, does it have to do with monitoring the processes? Could you post your Vrrpd configuration ? the result of ps -edf | grep vrrp In http://numsys.eu/vrrpd.php you can read a sample with two hosts > Now I need to learn more about the atropos client, I wish I could have > learned French, I saw mome > interesting documentation on your repository and to read the Changes file > :-) > Yes i have no time for translate now (and my english is not good enough), if you write something it could be interesting to post somewhere your notes for English readers Perhaps it is not desirable to continue our discussion here, because we're not talking about the version of sourceforge. A while ago someone had planned to merge the two versions, it explains why i'm in the dev team Best Regards, Fred |
From: Carlos X. <cb...@co...> - 2010-11-23 07:16:57
|
Hi Fred Once again i wish to tank you. I got it up and running on one host. I did some modification on the script so as the VRRPD cal ir recursively to restore the defaut route. Tomorrow ill install it on another host and test the fallback. One thing I could notice is the creation of the address "inet 255.255.255.255/32 scope global ethxx" on all the interfaces, does it have to do with monitoring the processes? Now I need to learn more about the atropos client, I wish I could have learned French, I saw mome interesting documentation on your repository and to read the Changes file :-) Best Regards, Carlos ----- Original Message ----- From: "Carlos Xavier" <cb...@co...> To: <vrr...@li...> Sent: Saturday, November 20, 2010 8:28 PM Subject: Re: [vrrpd] Vanishing default route when starting or changing stateof VRRPD on the main interface Hi Stealth. Tank you very much for the quick answer. Ill take alook at it. Regards. Carlos ----- Original Message ----- From: "Stealth" <st...@al...> To: <vrr...@li...> Sent: Saturday, November 20, 2010 2:59 PM Subject: Re: [vrrpd] Vanishing default route when starting or changing state of VRRPD on the main interface Hi, You can use this version ( http://www.numsys.eu/Vrrpd/ ) 1) Allow the vrrpd daemon to run a script (users choice) when a backup state happens and whenmaster stateis restored (for example restore the default route and anything else) + monitoring all interfaces link (down/up) 2) Add atropos client 3) Sync vrrpd state for all interfaces. Regards, Fred snip ... |
From: Carlos X. <cb...@co...> - 2010-11-20 22:39:25
|
Hi Stealth. Tank you very much for the quick answer. Ill take alook at it. Regards. Carlos ----- Original Message ----- From: "Stealth" <st...@al...> To: <vrr...@li...> Sent: Saturday, November 20, 2010 2:59 PM Subject: Re: [vrrpd] Vanishing default route when starting or changing state of VRRPD on the main interface Hi, You can use this version ( http://www.numsys.eu/Vrrpd/ ) 1) Allow the vrrpd daemon to run a script (users choice) when a backup state happens and whenmaster stateis restored (for example restore the default route and anything else) + monitoring all interfaces link (down/up) 2) Add atropos client 3) Sync vrrpd state for all interfaces. Regards, Fred Le 20/11/2010 14:49, Carlos Xavier a écrit : > Hi. > > We have the folowing topology on our network > > > +------+ > 172.31.0.0/24 --eth1--| Linux | > | FW | 200.xx.211.0/24 > 192.168.2.0/24 --eth2--| |--eth0----------Router-----Internet > | | > 172.31.3.0/24 --eth3--| | > +------+ > > I set up two machines and configured VRRPD Master/Backup without owner on the four interfaces. > > This is how they are configured: > > Master > eth0: 200.xx.211.131 > eth1: 172.31.0.2 > eth2: 192.168.2.2 > eth3: 172.31.3.2 > > /usr/sbin/vrrpd -i eth0 -v 50 -p 90 200.xx.211.133 > /usr/sbin/vrrpd -i eth1 -v 60 -p 90 172.31.0.1 > /usr/sbin/vrrpd -i eth2 -v 70 -p 90 192.168.2.1 > /usr/sbin/vrrpd -i eth3 -v 80 -p 90 172.31.3.1 > > Backup > eth0: 200.xx.211.132 > eth1: 172.31.0.3 > eth2: 192.168.2.3 > eth3: 172.31.3.3 > > /usr/sbin/vrrpd -i eth0 -v 50 -p 80 200.xx.211.133 > /usr/sbin/vrrpd -i eth1 -v 60 -p 80 172.31.0.1 > /usr/sbin/vrrpd -i eth2 -v 70 -p 80 192.168.2.1 > /usr/sbin/vrrpd -i eth3 -v 80 -p 80 172.31.3.1 > > > The machimes have their default route set to 200.xx.211.130. > > I noticed that when starting the VRRPD the interfaces are take down to be reconfigured, At this > time > the default route vanishes, and when the interfaces come back the default route isn´t restored. I > solved this issue with a start script that restore the default route when starting the VRRPD. > > The trouble arive when the Backup host change its role to Master, VRRPD takes out the default > route > by reconfiguring the interface and dont restore it, and since the start script is not running at > this time the default route can´t be restabilished. > > On my point of view, VRRPD could save the default route and check it after the swapping, if it > was > deleted then restore the default route. > > I read about a patch that allow you to run a command after the state change, I couldn´t find it. > But > I beleave this is not the best way to deal with the default route, because you will have a down > time > while starting a script. > > Is there another way to solve this issue without digging into the code, since im not a skilled > coder? > > > Regards, > Carlos > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Vrrpd-general mailing list > Vrr...@li... > https://lists.sourceforge.net/lists/listinfo/vrrpd-general > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Vrrpd-general mailing list Vrr...@li... https://lists.sourceforge.net/lists/listinfo/vrrpd-general |