associated public IP can not be pinged

Asked by josh

Hi,

I am able to allocate and associate a public IP address to a running VM. But I just cannot ping it from outside the VM host.

INSTANCE i-0000009c ami-00000045 192.55.50.173 192.168.0.2 running mykey (proj, ospc001) 0 m1.small 2012-01-18T04:29:35Z nova aki-00000035 ari-00000036

where 192.55.50.173 is a floating IP address I created and allocated to the VM which itself is spawned onto the controller node.

I followed the following procedure to alloacte and associate:

root@ospc001:~# nova-manage floating create 192.55.50.173/32
root@ospc001:~# euca-allocate-address 192.55.50.173
ADDRESS 192.55.50.173
root@ospc001:~# euca-associate-address -i i-0000009c 192.55.50.173
ADDRESS 192.55.50.173 i-0000009c

On my controller, I set network_manager and public_interface as follows

--network_manager=nova.network.manager.FlatDHCPManager
--flat_network_dhcp_start=192.168.0.2
--flat_network_bridge=br100
--public_interface=eth0
--flat_interface=eth1

The IP address table shows the associated floating address is added to eth0.

root@ospc001:~/euca# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 169.254.169.254/32 scope link lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:24:81:88:c0:76 brd ff:ff:ff:ff:ff:ff
    inet 192.55.50.172/24 brd 192.55.50.255 scope global eth0
    inet 192.55.50.173/32 scope global eth0
    inet6 fe80::224:81ff:fe88:c076/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:24:81:88:c0:74 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::224:81ff:fe88:c074/64 scope link
       valid_lft forever preferred_lft forever
4: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:24:81:88:c0:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global br100
    inet6 fe80::224:81ff:fe88:c074/64 scope link
       valid_lft forever preferred_lft forever
6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:16:3e:1c:13:da brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe1c:13da/64 scope link
       valid_lft forever preferred_lft forever

The NAT rule looks fine:

root@ospc001:~/euca# iptables-save | grep 173
-A nova-network-OUTPUT -d 192.55.50.173/32 -j DNAT --to-destination 192.168.0.2
-A nova-network-PREROUTING -d 192.55.50.173/32 -j DNAT --to-destination 192.168.0.2
-A nova-network-floating-snat -s 192.168.0.2/32 -j SNAT --to-source 192.55.50.173

root@ospc001:~/euca# euca-describe-groups
GROUP proj default default
PERMISSION proj default ALLOWS tcp 22 22 FROM CIDR 0.0.0.0/0
PERMISSION proj default ALLOWS icmp -1 -1 FROM CIDR 0.0.0.0/0

Then I ping the VM via its public IP from a different compute node, it did not reply.

localadmin@ospc003:~$ ping 192.55.50.173
PING 192.55.50.173 (192.55.50.173) 56(84) bytes of data.

^C
--- 192.55.50.173 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms

What am I setting incorrectly?

Thanks!
Josh

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Compute (nova) Edit question
Assignee:
No assignee Edit question
Solved by:
josh
Solved:
Last query:
Last reply:
Revision history for this message
Ryan Tidwell (ryan-tidwell) said :
#1

Try either

cat /proc/sys/net/ipv4/ip_forward

or

sysctl net.ipv4.ip_forward

I ran into a situation similar to this and the problem was that IPv4 forwarding was disabled in the kernel of the network node as a default setting. If the value of net.ipv4.ip_forward is 0, you can fix it by either

sysctl -w net.ipv4.ip_forward=1

or:

echo 1 > /proc/sys/net/ipv4/ip_forward

That's what got me around a similar issue. Hope it helps!

Revision history for this message
josh (shh-han) said :
#2

thank you! that solved my problem!

Revision history for this message
amitkhoth (amitkhoth) said :
#3

#euca-allocate-address
an unknown error has occurred.please try your request again.

 i am unable to solve this problem.
how can i resolve it?