[Openstack-operators] floatin ip issue
Paras pradhan
pradhanparas at gmail.com
Mon Nov 3 16:26:13 UTC 2014
George,
My issue has been resolved. The conflict was created by the local virbr0
interface's nat rules. After removing this interface from my compute node
all looks good now.
Thanks for your help
Paras.
On Mon, Nov 3, 2014 at 10:01 AM, Paras pradhan <pradhanparas at gmail.com>
wrote:
> George,
>
> Disabled nat on the compute node and now I can ping/ssh to the instance
> using the floating. Do you see anything wrong the nat rules here
> http://paste.openstack.org/show/128754/ ?
>
> Thanks
> Paras.
>
> On Fri, Oct 31, 2014 at 6:20 AM, George Shuklin <george.shuklin at gmail.com>
> wrote:
>
>> I was wrong, sorry. Floatings assigned as /32 on external interface
>> inside network namespace. The signle idea I have now - is try to remove all
>> iptables with NAT (it's destructive up to moment of network node reboot or
>> router delete/create), and check out if address will reply to ping.
>>
>> If 'yes' - means problems in routing/nat
>> If 'no' - means problem are outside openstack router (external net,
>> provider routing, etc).
>>
>>
>> On 10/29/2014 06:23 PM, Paras pradhan wrote:
>>
>> Hi George,
>>
>>
>> You mean .193 and .194 should be in the different subnets?
>> 192.168.122.193/24 reserved from the allocation pool and
>> 192.168.122.194/32 is the floating ip.
>>
>> Here are the outputs for the commands
>>
>>
>> *neutron port-list --device-id=8725dd16-8831-4a09-ae98-6c5342ea501f *
>>
>>
>> +--------------------------------------+------+-------------------+----------------------------------------------------------------------------------------+
>>
>> | id | name | mac_address |
>> fixed_ips
>> |
>>
>>
>> +--------------------------------------+------+-------------------+----------------------------------------------------------------------------------------+
>>
>> | 6f835de4-c15b-44b8-9002-160ff4870643 | | fa:16:3e:85:dc:ee |
>> {"subnet_id": "0189699c-8ffc-44cb-aebc-054c8d6001ee", "ip_address":
>> "192.168.122.193"} |
>>
>> | be3c4294-5f16-45b6-8c21-44b35247d102 | | fa:16:3e:72:ae:da |
>> {"subnet_id": "d01a6522-063d-40ba-b4dc-5843177aab51", "ip_address":
>> "10.10.0.1"} |
>>
>>
>> +--------------------------------------+------+-------------------+----------------------------------------------------------------------------------------+
>>
>> *neutron floatingip-list*
>>
>>
>> +--------------------------------------+------------------+---------------------+--------------------------------------+
>>
>> | id | fixed_ip_address |
>> floating_ip_address | port_id |
>>
>>
>> +--------------------------------------+------------------+---------------------+--------------------------------------+
>>
>> | 55b00e9c-5b79-4553-956b-e342ae0a430a | 10.10.0.9 |
>> 192.168.122.194 | 82bcbb91-827a-41aa-9dd9-cb7a4f8e7166 |
>>
>>
>> +--------------------------------------+------------------+---------------------+--------------------------------------+
>>
>> *neutron net-list*
>>
>>
>> +--------------------------------------+----------+-------------------------------------------------------+
>>
>> | id | name | subnets
>> |
>>
>>
>> +--------------------------------------+----------+-------------------------------------------------------+
>>
>> | dabc2c18-da64-467b-a2ba-373e460444a7 | demo-net |
>> d01a6522-063d-40ba-b4dc-5843177aab51 10.10.0.0/24 |
>>
>> | ceaaf189-5b6f-4215-8686-fbdeae87c12d | ext-net |
>> 0189699c-8ffc-44cb-aebc-054c8d6001ee 192.168.122.0/24 |
>>
>>
>> +--------------------------------------+----------+-------------------------------------------------------+
>>
>>
>> *neutron subnet-list*
>>
>>
>> +--------------------------------------+-------------+------------------+--------------------------------------------------------+
>>
>> | id | name | cidr |
>> allocation_pools |
>>
>>
>> +--------------------------------------+-------------+------------------+--------------------------------------------------------+
>>
>> | d01a6522-063d-40ba-b4dc-5843177aab51 | demo-subnet | 10.10.0.0/24
>> | {"start": "10.10.0.2", "end": "10.10.0.254"} |
>>
>> | 0189699c-8ffc-44cb-aebc-054c8d6001ee | ext-subnet | 192.168.122.0/24
>> | {"start": "192.168.122.193", "end": "192.168.122.222"} |
>>
>>
>> +--------------------------------------+-------------+------------------+--------------------------------------------------------+
>>
>>
>> P.S: External subnet is 192.168.122.0/24 and internal vm instance's
>> subnet is 10.10.0.0/24
>>
>>
>> Thanks
>>
>> Paras.
>>
>> On Mon, Oct 27, 2014 at 5:51 PM, George Shuklin <george.shuklin at gmail.com
>> > wrote:
>>
>>>
>>> I don't like this:
>>>
>>> 15: qg-d351f21a-08: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>>> UNKNOWN group default
>>> inet 192.168.122.193/24 brd 192.168.122.255 scope global
>>> qg-d351f21a-08
>>> valid_lft forever preferred_lft forever
>>> inet 192.168.122.194/32 brd 192.168.122.194 scope global
>>> qg-d351f21a-08
>>> valid_lft forever preferred_lft forever
>>>
>>> Why you got two IPs on same interface with different netmasks?
>>>
>>> I just rechecked it on our installations - it should not be happens.
>>>
>>> Next: or this is a bug, or this is uncleaned network node (lesser bug),
>>> or someone messing with neutron.
>>>
>>> Starts from neutron:
>>>
>>> show ports for router:
>>>
>>> neutron port-list --device-id=router-uuid-here
>>> neutron floatingips-list
>>> neutron net-list
>>> neutron subnet-list
>>> (trim to related only)
>>>
>>> (and please mark again who is 'internet' and who is 'internal' ips, i'm
>>> kinda loosing in '192.168.*'.
>>>
>>>
>>>
>>> On 10/27/2014 04:47 PM, Paras pradhan wrote:
>>>
>>> *Yes it got its ip which is 192.168.122.194 in the paste below.*
>>>
>>> --
>>>
>>> root at juno2:~# ip netns exec
>>> qrouter-34f3b828-b7b8-4f44-b430-14d9c5bd0d0c ip -4 a
>>>
>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>>> group default
>>>
>>> inet 127.0.0.1/8 scope host lo
>>>
>>> valid_lft forever preferred_lft forever
>>>
>>> 14: qr-ac50d700-29: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>>> UNKNOWN group default
>>>
>>> inet 50.50.50.1/24 brd 50.50.50.255 scope global qr-ac50d700-29
>>>
>>> valid_lft forever preferred_lft forever
>>>
>>> 15: qg-d351f21a-08: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>>> UNKNOWN group default
>>>
>>> inet 192.168.122.193/24 brd 192.168.122.255 scope global
>>> qg-d351f21a-08
>>>
>>> valid_lft forever preferred_lft forever
>>>
>>> inet 192.168.122.194/32 brd 192.168.122.194 scope global
>>> qg-d351f21a-08
>>>
>>> valid_lft forever preferred_lft forever
>>>
>>> ---
>>>
>>>
>>> *stdbuf -e0 -o0 ip net exec qrouter... /bin/bash give me the following *
>>>
>>>
>>> --
>>>
>>>
>>> root at juno2:~# ifconfig
>>>
>>> lo Link encap:Local Loopback
>>>
>>> inet addr:127.0.0.1 Mask:255.0.0.0
>>>
>>> inet6 addr: ::1/128 Scope:Host
>>>
>>> UP LOOPBACK RUNNING MTU:65536 Metric:1
>>>
>>> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
>>>
>>> TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
>>>
>>> collisions:0 txqueuelen:0
>>>
>>> RX bytes:168 (168.0 B) TX bytes:168 (168.0 B)
>>>
>>>
>>> qg-d351f21a-08 Link encap:Ethernet HWaddr fa:16:3e:79:0f:a2
>>>
>>> inet addr:192.168.122.193 Bcast:192.168.122.255
>>> Mask:255.255.255.0
>>>
>>> inet6 addr: fe80::f816:3eff:fe79:fa2/64 Scope:Link
>>>
>>> UP BROADCAST RUNNING MTU:1500 Metric:1
>>>
>>> RX packets:2673 errors:0 dropped:0 overruns:0 frame:0
>>>
>>> TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
>>>
>>> collisions:0 txqueuelen:0
>>>
>>> RX bytes:205377 (205.3 KB) TX bytes:6537 (6.5 KB)
>>>
>>>
>>> qr-ac50d700-29 Link encap:Ethernet HWaddr fa:16:3e:7e:6d:f3
>>>
>>> inet addr:50.50.50.1 Bcast:50.50.50.255 Mask:255.255.255.0
>>>
>>> inet6 addr: fe80::f816:3eff:fe7e:6df3/64 Scope:Link
>>>
>>> UP BROADCAST RUNNING MTU:1500 Metric:1
>>>
>>> RX packets:345 errors:0 dropped:0 overruns:0 frame:0
>>>
>>> TX packets:1719 errors:0 dropped:0 overruns:0 carrier:0
>>>
>>> collisions:0 txqueuelen:0
>>>
>>> RX bytes:27377 (27.3 KB) TX bytes:164541 (164.5 KB)
>>>
>>> --
>>>
>>>
>>> Thanks
>>>
>>> Paras.
>>>
>>>
>>>
>>> On Sat, Oct 25, 2014 at 3:18 AM, George Shuklin <
>>> george.shuklin at gmail.com> wrote:
>>>
>>>> Check out if qrouter got floating inside network namespace (ip net
>>>> exec qrouter... ip -4 a), or just bash in to it (stdbuf -e0 -o0 ip net exec
>>>> qrouter... /bin/bash) and play with it like with normal server.
>>>>
>>>>
>>>>
>>>> On 10/24/2014 07:38 PM, Paras pradhan wrote:
>>>>
>>>> Hello,
>>>>
>>>> Assigned a floating ip to an instance. But I can't ping the instance.
>>>> This instance can reach internet with no problem. But I can't ssh or icmp
>>>> to this instance. Its not a security group issue.
>>>>
>>>> On my network node that runs l3, I can see qrouter. The extenel
>>>> subnet looks like this:
>>>>
>>>> allocation-pool start=192.168.122.193,end=192.168.122.222
>>>> --disable-dhcp --gateway 192.168.122.1 192.168.122.0/24
>>>>
>>>> I can ping 192.168.122.193 using: ip netns exec
>>>> qrouter-34f3b828-b7b8-4f44-b430-14d9c5bd0d0c ping 192.168.122.193
>>>>
>>>> but not 192.168.122.194 (which is the floating ip)
>>>>
>>>> Doing tcp dump on the interace that connects to the external world, I
>>>> can see ICMP request but not reply from the interface :
>>>>
>>>>
>>>> 11:36:40.360255 IP 192.168.122.1 > 192.168.122.194: ICMP echo
>>>> request, id 2589, seq 312, length 64
>>>>
>>>> 11:36:41.360222 IP 192.168.122.1 > 192.168.122.194: ICMP echo
>>>> request, id 2589, seq 313, length 64
>>>>
>>>>
>>>> Ideas?
>>>>
>>>> Thanks
>>>>
>>>> Paras.
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing listOpenStack-operators at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141103/f93f1e61/attachment.html>
More information about the OpenStack-operators
mailing list