[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keepalived-devel
Subject:    Re: [Keepalived-devel] saddr in vrrp structure already in network
From:       "Vonlanthen, Elmar" <Elmar.Vonlanthen () united-security-providers ! ch>
Date:       2009-10-19 5:47:44
Message-ID: 98D8B015D09D1241A15FD54BA7EAFF15038386AB () ttsrv02 ! tetrade ! ch
[Download RAW message or body]

This is an S/MIME signed message

[Attachment #2 (multipart/signed)]
This is an S/MIME signed message

------A9AE03C0C109998BB79FCDD49D510176
Content-class: urn:content-classes:message
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA507F.EBD53DB4"

This is a multi-part message in MIME format.


Hello

The attached patch keepalived-1.1.19-ntohl.patch.gz is solving the
problem, when both hosts are sending advertisments with the same
priority.
The host with the higher ip address becomes master.

I'm not sure if this is the correct way to solve the problem. Maybe
netlink is using the wrong byte order.

The second patch keepalived-1.1.19-log-prio.patch.gz is logging the
local and vrrp prio value and the ip addresses (string and integer), if
die prio values are equal.

Best regards
Elmar

> -----Original Message-----
> From: Vonlanthen, Elmar 
> [mailto:Elmar.Vonlanthen@united-security-providers.ch] 
> Sent: Thursday, October 15, 2009 3:03 PM
> To: keepalived-devel@lists.sourceforge.net
> Subject: [Keepalived-devel] saddr in vrrp structure already 
> in network byte order?
> 
> Hello
> 
> I have a problem with failovers, when the priority value of host1 and
> host2 is equal.
> 
> host1: eth0 172.16.101.2
> host2: eth0 172.16.101.3
> 
> In my case host2 is master and is sending advertisment over eth0.
> 
> Then there is a short network failure on eth0 at host1, but 
> too short to
> go into fault state.
> (I can simulate it with "ip link set eth0 down; sleep 0.9; ip link set
> eth0 up" on host1)
> 
> So host1 is sending an advertisment.
> 
> host2 is receiving the advertisment and goes to the following 
> statement
> in function vrrp_state_master_rx (vrrp.c):
> int vrrp_state_master_rx(vrrp_rt * vrrp, char *buf, int buflen)
> {
>     ...     
>     ...
>     } else if (hd->priority > vrrp->effective_priority ||
>               (hd->priority == vrrp->effective_priority &&
>                   ntohl(iph->saddr) > VRRP_PKT_SADDR(vrrp))) {
> <== this is true!
>                   log_message(LOG_INFO, "VRRP_Instance(%s) Received
> higher prio advert",
>                       vrrp->iname);
>     ...
> }
> 
> Now, the problem is, that host2 with ip 172.16.101.3 is going 
> the backup
> state. But the ip of host1 (172.16.101.2) is lower than the 
> ip of host2.
> So I think that is not correct.
> 
> if I do this:
> - ntohl(iph->saddr) > VRRP_PKT_SADDR(vrrp))) {
> + ntohl(iph->saddr) > ntohl(VRRP_PKT_SADDR(vrrp)))) {
> everything is fine.
> 
> Could it be, that the source ip address in the vrrp structure 
> (local) is
> saved in network byte order?
> I don't use the option "mcast_src_ip".
> 
> Thanks for any help.
> 
> OS: Gentoo Linux, Kernel 2.6.29.2
> Keepalived: 1.1.19
> 
> /etc/keepalived/keepalived.conf:
> vrrp_instance VI_eth0 {
>   interface eth0
>   state BACKUP
>   virtual_router_id 1
>   priority 100
>   advert_int 1
>   authentication {
>     auth_type PASS
>     auth_pass "mypass"
>   }
>   virtual_ipaddress_excluded {
>     172.16.101.1/24
>   }
> }
> 
> 
> Best regards
> Elmar        
> 

["keepalived-1.1.19-log-prio.patch.gz" (application/x-gzip)]
["keepalived-1.1.19-ntohl.patch.gz" (application/x-gzip)]
["smime.p7s" (smime.p7s)]

0n	*H
 _0[10	+0	*H
 00 2b `^0
	*H
0U10	UCH10U
SwissSign AG1/0-U&SwissSign Personal Silver CA 2008 - G20
090911114141Z
100911114141Z010	UCH1%0#U
United Security Providers AG10UElmar von Lanthen1<0:	*H
	-elmar.vonlanthen@united-security-providers.ch0"0
	*H
0
>v[E)󫕥}S	34lED^w):jy>90Ah>d@2\<a)eH%rTF \
ۨ,<]H!_ATQDe	xoVEdRG?JNW4:d^RW<n;̻!@^ec~~ع_v&yv	Z"Lv \
X>Fj nGDr$U+Tl昕_eb0^08U10/-elmar.vonlanthen@united-security-providers.ch0U0U%0
 +0U#05Vm`X"Fe0U00G E \
CAhttp://crl.swisssign.net/EB35B1566D156058F4E122CD1C461CAED00400650  \
ldap://directory.swisssign.net/CN=EB35B1566D156058F4E122CD1C461CAED0040065%2CO=Sw \
issSign%2CC=CH?certificateRevocationList?base?objectClass=cRLDistributionPoint0dU \
]0[0Y	`tY0L0J+>http://repository.swisssign.com/SwissSign-Silver-CP-C \
PS-R3.pdf0t+h0f0d+0Xhttp://swisssign.net/cgi-bin/authority/download/EB35B1566D156058F4E122CD1C461CAED00400650
 	*H
VQ&1t?Z?h麖sjs/Udd5Dw[ݧ>}v9BՎ5y"6M\U={(՘Ne?VPUJv~aKev~j \
n](ju%5Fwj+Dj;k}ZΪuE	ovLKyw<1.9$V :8k \
Mi8e(C#ׂoüQ[3.L3֘҄ 1)*0g0O 	VSkvX0 	*H
0G10	UCH10U
SwissSign AG1!0USwissSign Silver CA - G20
080709111109Z
230709111109Z0U10	UCH10U
SwissSign AG1/0-U&SwissSign Personal Silver CA 2008 - G20"0
	*H
0
S^Im'!`v?!@63*rakzIX=;AkV=c1~rFhׅO \
{9щ5ghv_	:? Cu \
49hfRG9)M*a1C+4lb'D1<!hthJ;	e.zzDotX%̈"'1/(qrNnz!?
 Zfğ3
]F0B0U0U00U5Vm`X"Fe0U#0 \
A:[;E X0U00G E \
CAhttp://crl.swisssign.net/17A0CDC1E441B63A5B3BCB459DBD1CC298FA86580  \
ldap://directory.swisssign.net/CN=17A0CDC1E441B63A5B3BCB459DBD1CC298FA8658%2CO=Sw \
issSign%2CC=CH?certificateRevocationList?base?objectClass=cRLDistributionPoint0dU \
]0[0Y	`tY0L0J+>http://repository.swisssign.com/SwissSign-Silver-CP-C \
PS-R3.pdf0t+h0f0d+0Xhttp://swisssign.net/cgi-bin/authority/download/17A0CDC1E441B63A5B3BCB459DBD1CC298FA86580
 	*H
.*vڗLd'[-U.۸	e1@K|qS5,tWWP%{]Dx3AFy}r8PhZ]gi	Z.j9#sZ6 \
Gd79yPEF/9 U&$Qk|i=XՁ5<hGW*jE/N=9Ja \
#vC8^8.Ɋ(]#lNfc \
bGrm~=]Ehۘ首n5`G4`(n<I:e8a!u(5^R`/:1 \
{Hp<b˴BDq$!c[Қp'T"^ЙC9RNg2Z6SzwnPD0ʋ \
-sT(א##)OI3yJ^af]шo.![eDvIƶ~6)x$] t
d
yaHUF۪00 O/T/K0
	*H
0G10	UCH10U
SwissSign AG1!0USwissSign Silver CA - G20
061025083246Z
361025083246Z0G10	UCH10U
SwissSign AG1!0USwissSign Silver CA - G20"0
	*H
0
x18ÙC7NqKs\nW87C/=hx+,yhUD9M'a{a>l^ \
5[I >Oܕ725":N'2a
GM`BGZPX銋]ݙJ6gH䃶7H:gj1q{gdJB{e.0j͂١JKEmx.m61d*5
 xUAG0a(z_88s;H*!̨5Ä>i:xV~[9,	2`* \
~IJF/&<GsQpd/G0lD)7hf8{9.P^`'ArtJgTHdߌnqLإGtQ \
#@sKs YF/qFm8yEH]9" \
XCqH.00U0U00U A:[;E \
X0U#0 A:[;E X0FU ?0=0;	`tY0.0,+ \
http://repository.swisssign.com/0 	*H
sƁ'-0AP,__bajitI]ARoXPV \
jƽ(iXܑ5:`Ei~xr*Ώpa 9)V2N=*rQ"Aqcb^Wu \
]yP1{p_حo`@K"=:zGy32inKqgr \
\"DŽ#?%eaZA"Z],[mx`VZhiy~$Q^KS#Z6eA0 \
Feձ[xuzmY*{ÇIsx=Q5t*~i*;%Z=rafMtjUWJˮ[#1S8-j?j^Atn~)`?8W
 0/ǥA ڮ elL	ӹ0kNgbV>f6}>ԀNzjbr	O#|l%c*gؚj
 *L	`9b.n1<080a0U10	UCH10U
SwissSign AG1/0-U&SwissSign Personal Silver CA 2008 - G22b `^0	+ \
0	*H 	1	*H
0	*H
	1
091019054929Z0#	*H
	1֭9,ck}*z 0R	*H
	1E0C0
*H
0*H
0
*H
@0+0
*H
(0
	*H
gmzX=ȱv\"
pUY~ϊX-BPnY$e.MeO\/:.EflTMCQ</}'yWIql}+o51JL-adn[5ʼ"CQVwV^$in-ʌј
  qSv]*'_@CJMWz^YØ
xvɮ |9i<joד



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference

_______________________________________________
Keepalived-devel mailing list
Keepalived-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel


[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic