Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Fri, 4 Dec 2015 09:46:10 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12917249.1448977568000.270651.1449222370997@Atlassian.JIRA>
In-Reply-To: <JIRA.12917249.1448977568000@Atlassian.JIRA>
References: <JIRA.12917249.1448977568000@Atlassian.JIRA>
 <JIRA.12917249.1448977568607@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9097) Extra public ip addresses do
 not work immediately
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041354#comment-15041354 ] 

ASF subversion and git services commented on CLOUDSTACK-9097:
-------------------------------------------------------------

Commit 4f6ff6ca0835b322d0ddcbb0e4687f8e7c826c47 in cloudstack's branch refs/heads/4.6 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4f6ff6c ]

Merge pull request #1163 from remibergsma/arping-to-gw

Send arping to the gateway instead of our own addressWe need to send an Unsolicited ARP to the gateway, instead of our own address. We now encounter problems when people deploy/destroy/deploy and get the same public ip.

Packets arrive, but with incorrect / cached mac and are ignored by the routervm kernel.
Run arping manually to update the arp-cache on the gateway and things start to work.

Then we discovered the `arping` is actually done, but sent to its own address. Therefore the gateway doesn't pick it up. We only saw this happening when rapid deploy tools are used, like Terraform that do deploy/destroy/deploy and might get the same ip but on a new router having a new mac.

```
2015-12-03 18:07:25,589  CsHelper.py execute:160 Executing: arping -c 1 -I eth1 -A -U -s 192.168.23.8 192.168.23.1
```

The integration tests seem happy, although the full run is still ongoing:

```
=== TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : SUCCESS ===
```

Thanks @sspans for helping trouble shoot this. Ping @wilderrodrigues can you review please?

* pr/1163:
  CLOUDSTACK-9097 Make public ip work immediately

Signed-off-by: Remi Bergsma <github@remi.nl>


> Extra public ip addresses do not work immediately
> -------------------------------------------------
>
>                 Key: CLOUDSTACK-9097
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9097
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: SystemVM
>    Affects Versions: 4.6.0, 4.6.1
>            Reporter: Remi Bergsma
>            Assignee: Remi Bergsma
>            Priority: Critical
>
> Sometimes public ip addresses do not work immediately, this is in case they are used as a secondary ip on an interface.
> Service on secondary ip which is recently used by other routervm and therefore cached on the gateway:
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:27.709762 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui Unknown), ethertype IPv4 (0x0800), length 98: 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 10107, seq 1127, length 64
> 13:23:28.701694 5c:5e:ab:29:bf:ca (oui Unknown) > 06:0e:ee:00:00:24 (oui Unknown), ethertype IPv4 (0x0800), length 98: 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.y.237.226: ICMP echo request, id 10107, seq 1128, length 64
> ^C
> Packets arrive, but with incorrect / cached mac and are ignored by the routervm kernel.
> Run arping to update the arp-cache on the gateway and things start to work:
> root@r-547-VM:~# arping -S x.y.237.226 x.y.237.129
> ARPING x.y.237.129
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=0 time=1.372 msec
> 60 bytes from 00:00:5e:00:01:a0 (x.y.237.129): index=1 time=893.665 usec
> ^C
> --- x.y.237.129 statistics ---
> 2 packets transmitted, 2 packets received,   0% unanswered (0 extra)
> root@r-547-VM:~# tcpdump -e -i eth1 icmp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> 13:23:51.922328 5c:5e:ab:29:bf:ca (oui Unknown) > 06:47:88:00:00:24 (oui Unknown), ethertype IPv4 (0x0800), length 98: 52D9557D.cm-11-1b.dynamic.ziggo.nl > x.yy.237.226: ICMP echo request, id 8422, seq 9, length 64
> 13:23:51.922368 06:47:88:00:00:24 (oui Unknown) > 00:00:5e:00:01:a0 (oui Unknown), ethertype IPv4 (0x0800), length 98: x.y.237.226 > 52D9557D.cm-11-1b.dynamic.ziggo.nl: ICMP echo reply, id 8422, seq 9, length 64
> Suggested solution: update routervm scripting to run arping when adding a secondary ip.
> Ping [~wilder.rodrigues]


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)