could not access vms thru floating IP

rknarayan

added ICMP and ssh ingress rules to default security group as demo user

created instance VM1 and 

after associating floating IP to VM, could not do ssh/ping the VM through floating IP.

 

[root@rdo-cc ~(keystone_demo)]# ip netns list

qrouter-b22708f6-ce45-4d81-ba7e-6879fc85bb47

qdhcp-7750e74b-cf0f-41f1-a683-883148b3a577

[root@rdo-cc ~(keystone_demo)]# openstack server show vm1

+--------------------------------------+----------------------------------------------------------+

| Field                                | Value                                                    |

+--------------------------------------+----------------------------------------------------------+

| OS-DCF:diskConfig                    | AUTO                                                     |

| OS-EXT-AZ:availability_zone          | nova                                                     |

| OS-EXT-STS:power_state               | Running                                                  |

| OS-EXT-STS:task_state                | None                                                     |

| OS-EXT-STS:vm_state                  | active                                                   |

| OS-SRV-USG:launched_at               | 2017-09-08T14:32:57.000000                               |

| OS-SRV-USG:terminated_at             | None                                                     |

| accessIPv4                           |                                                          |

| accessIPv6                           |                                                          |

| addresses                            | demo_int=10.0.0.3, 172.24.4.231                          |

| config_drive                         |                                                          |

| created                              | 2017-09-08T14:32:43Z                                     |

| flavor                               | m1.tiny (1)                                              |

| hostId                               | e1baaf681fa7a822dad2bee0a626514894fa3dd08407804abbb643e7 

 

[root@rdo-cc ~(keystone_demo)]# ip netns exec qrouter-b22708f6-ce45-4d81-ba7e-6879fc85bb47 ping 10.0.0.3

PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.

64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=16.8 ms

64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=6.31 ms

64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.859 ms

 

could not ping 172.24.4.231 or do ssh 

 

what I am missing?

 

[root@rdo-cc ~(keystone_demo)]# ip -4 a s

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

    inet 104.239.240.72/24 brd 104.239.240.255 scope global eth0

       valid_lft forever preferred_lft forever

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

    inet 10.100.32.89/20 brd 10.100.47.255 scope global eth1

       valid_lft forever preferred_lft forever

4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

    inet 192.168.98.1/24 brd 192.168.98.255 scope global eth2

       valid_lft forever preferred_lft forever

[root@rdo-cc ~(keystone_demo)]# ip r

default via 104.239.240.1 dev eth0 

10.100.32.0/20 dev eth1  proto kernel  scope link  src 10.100.32.89 

104.239.240.0/24 dev eth0  proto kernel  scope link  src 104.239.240.72 

192.168.98.0/24 dev eth2  proto kernel  scope link  src 192.168.98.1 

 

thank you in advance

Ramesh

 

serewicz

Hello Ramesh,

There are a few things I would look at. First would be if the routing is working such that the 172. network would be understood and packets could move both directions. Toward that you would need an interface that has a 172 IP configured properly. In this case that may be hampered by the lab provider firewall. In order to get to that IP range, you may need for a packet to leave the system and then return to be put into the proper namespace. This could be hampered by the provider routing and/or a firewall that blocks unknown traffic. 

When you snoop the ports and trace the packets which interfaces are send out the pings and SSH requests? Then look for routing rules which may affect that interface.

Best regards,