<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#0050d0">
Sent: Mon Aug 29 2011 02:50:33 GMT-0600 (MST)<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:alexander.krauth@basf.com">alexander.krauth@basf.com</a><br>
To: The Pacemaker cluster resource manager
<a class="moz-txt-link-rfc2396E" href="mailto:pacemaker@oss.clusterlabs.org"><pacemaker@oss.clusterlabs.org></a> <br>
Subject: [Pacemaker] Antwort: IPaddr2 resource IP unavailable on
'lo' interface for brief period after start
<blockquote
cite="mid:OF37D1CC20.049D3306-ONC12578FB.00305EF9-C12578FB.00309262@basf-c-s.be"
type="cite">
<pre wrap="">"Patrick H." <a class="moz-txt-link-rfc2396E" href="mailto:pacemaker@feystorm.net"><pacemaker@feystorm.net></a> schrieb am 27.08.2011 10:22:08:
</pre>
<blockquote type="cite">
<pre wrap="">[Pacemaker] IPaddr2 resource IP unavailable on 'lo' interface for brief
</pre>
</blockquote>
<pre wrap="">period after start
</pre>
<blockquote type="cite">
<pre wrap="">
So the issue is that whenever I start up an IP with an IPaddr2 resource,
</pre>
</blockquote>
<pre wrap="">the IP is unavailable when attempting to connect via lo interface for
approximately 21 seconds after the resource is started.
</pre>
<blockquote type="cite">
<pre wrap="">
What I am doing is starting up the IP resource, and then I have another
</pre>
</blockquote>
<pre wrap="">resource that tries to start, but prior to starting it does a status check
by connecting to that IP on a TCP port to see if
</pre>
<blockquote type="cite">
<pre wrap="">the service is up. And if it isnt up, then it starts it. Well I should
</pre>
</blockquote>
<pre wrap="">immediately get a 'connection refused' message as the service isnt
running, however I dont. Instead the resource times out as I
</pre>
<blockquote type="cite">
<pre wrap="">have startup timeout set to 20 seconds, and connection attempts wont
</pre>
</blockquote>
<pre wrap="">give 'connection refused' until after 21 seconds. However I can try to
connect from another host on the network and I immediately
</pre>
<blockquote type="cite">
<pre wrap="">get 'connection refused' as expected, even while the box trying to
</pre>
</blockquote>
<pre wrap="">connect to itself is still not working.
</pre>
<blockquote type="cite">
<pre wrap="">
But it gets even more interesting. I did a tcpdump on eth0 interface
</pre>
</blockquote>
<pre wrap="">(the interface the IPaddr2 resource IP is on) the box running the
resources and I get the following when resources start up
</pre>
<blockquote type="cite">
<pre wrap="">(presumably triggered by the box trying to connect for the status
</pre>
</blockquote>
<pre wrap="">check):
</pre>
<blockquote type="cite">
<pre wrap=""> 01:12:21.423330 arp who-has 192.168.2.21 (Broadcast) tell 192.168.2.21
01:12:22.428523 arp who-has 192.168.2.21 (Broadcast) tell 192.168.2.21
01:12:23.429342 arp who-has 192.168.2.21 (Broadcast) tell 192.168.2.21
Notice as my box seems to be having a slight identity crisis
</pre>
</blockquote>
<pre wrap="">(192.168.2.21 is the IPaddr2 resource)
</pre>
<blockquote type="cite">
<pre wrap="">
Also when I tcpdump on the lo interface I get the following
01:15:41.837719 IP 192.168.2.11.37284 > 192.168.2.21.25565: S
</pre>
</blockquote>
<pre wrap="">1770941237:1770941237(0) win 32792 <mss 16396,sackOK,timestamp 190131056
0,nop,wscale 4>
</pre>
<blockquote type="cite">
<pre wrap=""> 01:15:44.845531 IP 192.168.2.11.37284 > 192.168.2.21.25565: S
</pre>
</blockquote>
<pre wrap="">1770941237:1770941237(0) win 32792 <mss 16396,sackOK,timestamp 190134064
0,nop,wscale 4>
</pre>
<blockquote type="cite">
<pre wrap="">Which indicates that the box clearly isnt responding (192.168.2.11 is
</pre>
</blockquote>
<pre wrap="">the box's normal ip)
</pre>
<blockquote type="cite">
<pre wrap="">
As mentioned earlier, after 21 seconds I start getting 'connection
</pre>
</blockquote>
<pre wrap="">refused' when attempting to connect. The packets are still going over the
lo interface at this point, so nothing changes.
</pre>
<blockquote type="cite">
<pre wrap="">Additionally an arp reply never does come back on eth0 or lo, it just
</pre>
</blockquote>
<pre wrap="">magically starts working.
</pre>
<blockquote type="cite">
<pre wrap="">I could bump up my timeout to something higher, but i would really
</pre>
</blockquote>
<pre wrap="">prefer to get this issue
solved._______________________________________________
Hm, just an idea. Did you try:
ip route flush cache
There is also the "flush_routes" parameter in ipaddr2, but this is only in
the "stop" method. Seams your issue is somehow different.
Regards
Alex
</pre>
</blockquote>
<br>
Tried `ip route flush cache`, had no effect.<br>
<br>
And I realized the weird arps in the tcpdump output were the
unsolicited arps sent by IPaddr2 when the interface comes up. Was
expecting to see arp announces, not queries :-)<br>
<br>
-Patrick<br>
</body>
</html>