You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2015/12/04 10:46:10 UTC
[jira] [Commented] (CLOUDSTACK-9097) Extra public ip addresses do
not work immediately
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15041353#comment-15041353 ]
ASF subversion and git services commented on CLOUDSTACK-9097:
-------------------------------------------------------------
Commit 90e01c95a2db3d9b7c6586b2b228e0a9c5b9e415 in cloudstack's branch refs/heads/4.6 from [~remibergsma]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=90e01c9 ]
CLOUDSTACK-9097 Make public ip work immediately
We 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.
> 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)