[Rdo-list] Problem with floating IP

Miguel Angel Ajo Pelayo mangelajo at redhat.com
Fri Apr 17 15:00:17 UTC 2015


So, the traces were on the ESXi?

or the traces were on bare metal node?


Your initial message had a diagram with ESXi,
so from your response, now I’m not sure if we fixed it for ESXi
and bare metal still doesn’t work, or, if we didn’t fix anything.

Best,
Miguel Ángel.

> On 17/4/2015, at 15:55, pauline phaure <phaurep at gmail.com> wrote:
> 
> Thank you Miguel, my openstack is working fine on ESXi. But when I try to do the same things with my openstack installation on real servers it doesn't work. I'm still stuck with br-ex problem and the vlans in which my interfaces are. br-ex can't reach the outside because eth0 is in a vlan. any idea
> 
> 2015-04-17 14:23 GMT+02:00 Miguel Angel Ajo Pelayo <mangelajo at redhat.com <mailto:mangelajo at redhat.com>>:
> 
> The traffic shows that neutron is doing the right thing,
> 
> Check that your ESX is not applying any MAC anti spoof on the 
> vmware vswitch, it looks like the ARP requests could be blocked at switch level
> since every qrouter is going to have it’s own MAC address (separate from your own
> VM one).
> 
> Otherwise connect other machine to the physical switch on vlan30 and check if
> the ARP requests (it’s broadcast traffic) are arriving to confirm my above theory.
> 
> 
> 
>> On 17/4/2015, at 13:51, pauline phaure <phaurep at gmail.com <mailto:phaurep at gmail.com>> wrote:
>> 
>> i found these lines on the input file of tcpdump -e -n -v -v -v -i eth0 
>> 
>> 192.168.2.72 > 10.0.0.4 <http://10.0.0.4/>: ICMP host 192.168.2.1 unreachable, length 92
>>     192.168.2.72 > 10.0.0.4 <http://10.0.0.4/>: ICMP host 192.168.2.1 unreachable, length 92
>>     192.168.2.72 > 10.0.0.4 <http://10.0.0.4/>: ICMP host 192.168.2.1 unreachable, length 92
>>     192.168.2.72 > 10.0.0.4 <http://10.0.0.4/>: ICMP host 192.168.2.1 unreachable, length 92
>> 11:41:46.661008 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:41:47.663307 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:41:48.665301 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 
>> 
>> 2015-04-17 11:52 GMT+02:00 pauline phaure <phaurep at gmail.com <mailto:phaurep at gmail.com>>:
>> hey Miguel, thank you for your response, plz found below the output of the commands:
>> 
>> 
>>  ip netns exec qrouter-f7194985-eb13-41bf-8158-f0e78fc932c4 ip a
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 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 <http://127.0.0.1/8> scope host lo
>>        valid_lft forever preferred_lft forever
>>     inet6 ::1/128 scope host
>>        valid_lft forever preferred_lft forever
>> 12: qr-207805ae-39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
>>     link/ether fa:16:3e:1c:62:a8 brd ff:ff:ff:ff:ff:ff
>>     inet 10.0.0.1/24 <http://10.0.0.1/24> brd 10.0.0.255 scope global qr-207805ae-39
>>        valid_lft forever preferred_lft forever
>>     inet6 fe80::f816:3eff:fe1c:62a8/64 scope link
>>        valid_lft forever preferred_lft forever
>> 13: qg-52b4d686-58: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
>>     link/ether fa:16:3e:34:d5:6e brd ff:ff:ff:ff:ff:ff
>>     inet 192.168.2.70/24 <http://192.168.2.70/24> brd 192.168.2.255 scope global qg-52b4d686-58
>>        valid_lft forever preferred_lft forever
>>     inet 192.168.2.72/32 <http://192.168.2.72/32> brd 192.168.2.72 scope global qg-52b4d686-58
>>        valid_lft forever preferred_lft forever
>>     inet6 fe80::f816:3eff:fe34:d56e/64 scope link
>>        valid_lft forever preferred_lft forever
>> 
>> 
>> ip netns exec qrouter-f7194985-eb13-41bf-8158-f0e78fc932c4 tcpdump -e -n -v -v -v -i qg-52b4d686-58
>> 
>> equest who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:19.705378 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:20.707292 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:22.706910 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:23.707412 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:24.709292 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:26.710264 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:27.711297 fa:16:3e:34:d5:6e > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.1 tell 192.168.2.72, length 28
>> 11:49:28.002005 00:23:48:9e:85:7c > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.42 (Broadcast) tell 192.168.2.1, length 46
>> 11:49:28.002064 fa:16:3e:34:d5:6e > 00:23:48:9e:85:7c, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 58298, offset 0, flags [DF], proto ICMP (1), length 84)
>>     192.168.2.72 > 192.168.2.1 <http://192.168.2.1/>: ICMP echo request, id 19201, seq 494, length 64
>> 11:49:28.002079 fa:16:3e:34:d5:6e > 00:23:48:9e:85:7c, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 58299, offset 0, flags [DF], proto ICMP (1), length 84)
>>     192.168.2.72 > 192.168.2.1 <http://192.168.2.1/>: ICMP echo request, id 19201, seq 495, length 64
>> 11:49:28.040439 00:23:48:9e:85:7c > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.5 (Broadcast) tell 192.168.2.1, length 46
>> 11:49:28.079105 00:23:48:9e:85:7c > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.20 (Broadcast) tell 192.168.2.1, length 46
>> 11:49:28.115671 00:23:48:9e:85:7c > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.34 (Broadcast) tell 192.168.2.1, length 46
>> 11:49:28.179014 00:23:48:9e:85:7c > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.22 (Broadcast) tell 192.168.2.1, length 46
>> 11:49:28.223391 00:23:48:9e:85:7c > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.240 (Broadcast) tell 192.168.2.1, length 46
>> 
>> 
>>  tcpdump -e -n -v -v -v -i eth0 
>> 
>> 11:41:44.953118 00:0c:29:56:d9:09 > 74:46:a0:9e:ff:a5, ethertype IPv4 (0x0800), length 166: (tos 0x10, ttl 64, id 10881, offset 0, flags [DF], proto TCP (6), length 152)
>>     192.168.2.19.ssh > 192.168.2.99.53021: Flags [P.], cksum 0x8651 (incorrect -> 0x9f53), seq 2550993953:2550994065, ack 2916435463, win 146, length 112
>> 11:41:44.953804 74:46:a0:9e:ff:a5 > 00:0c:29:56:d9:09, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 31471, offset 0, flags [DF], proto TCP (6), length 40)
>>     192.168.2.99.53021 > 192.168.2.19.ssh: Flags [.], cksum 0x7b65 (correct), seq 1, ack 112, win 16121, length 0
>> 11:41:45.017729 00:0c:29:91:4c:ea > 00:0c:29:56:d9:09, ethertype IPv4 (0x0800), length 99: (tos 0x0, ttl 64, id 17044, offset 0, flags [DF], proto TCP (6), length 85)
>>     192.168.2.22.45167 > 192.168.2.19.amqp: Flags [P.], cksum 0x7339 (correct), seq 2968653045:2968653078, ack 1461763310, win 123, options [nop,nop,TS val 222978 ecr 218783], length 33
>> 11:41:45.018242 00:0c:29:56:d9:09 > 00:0c:29:91:4c:ea, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 47485, offset 0, flags [DF], proto TCP (6), length 64)
>>     192.168.2.19.amqp > 192.168.2.22.45167: Flags [P.], cksum 0x85ac (incorrect -> 0x4c5d), seq 1:13, ack 33, win 330, options [nop,nop,TS val 223746 ecr 222978], length 12
>> 11:41:45.018453 00:0c:29:91:4c:ea > 00:0c:29:56:d9:09, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 17045, offset 0, flags [DF], proto TCP (6), length 52)
>>     192.168.2.22.45167 > 192.168.2.19.amqp: Flags [.], cksum 0x8701 (correct), seq 33, ack 13, win 123, options [nop,nop,TS val 222979 ecr 223746], length 0
>> 
>> 
>> 
>> 2015-04-17 10:42 GMT+02:00 Miguel Angel Ajo Pelayo <mangelajo at redhat.com <mailto:mangelajo at redhat.com>>:
>> To troubleshoot this I’d recommend you
>> 
>> 1) doing a tcpdump in the controller node, on the external interface attached to br-ex,
>> and find what’s going on,
>> 
>> tcpdump -e -n -v -v -v -i ethX
>> 
>> note: as per your schema you may use an “external flat network”
>> (no segmentation) from your network/controller node, so the packets going out from the router
>> should not be tagged in your tcpdump.
>> 
>> If you set the external network as vlan tagged, you may have to change it into flat. (such operation
>> may require removing the floating ips from instances, removing legs from router (External, and internal),
>> and then removing the router, then the external network/subnet).
>> 
>> 
>> In a separate terminal, it may help to ..
>> 2) look for the router netns:
>> 
>> # ip netns
>> qrouter-8f2f7e69-02c3-4b75-9b25-e23b64757935
>> 
>> note : this is the “virtual router”, it lives in a network namespace which is another isolated
>> instance of the linux networking stack., you will find the interfaces and IPs attached with
>> the following command:
>> 
>> # ip netns exec qrouter-8f2f7e69-02c3-4b75-9b25-e23b64757935 ip a
>> 
>> (here look for the external leg of the router, it will have the external router IP and the floating ip attached)
>> it should look like qg-xxxxxxxx-xx
>> 
>> 
>> # ip netns exec qrouter-8f2f7e69-02c3-4b75-9b25-e23b64757935 tcpdump -e -n -v -v -v -i qg-xxxxxxx-xx
>> 
>> 
>> Please tell us how is it going .
>> 
>> 
>> 
>> > On 17/4/2015, at 9:48, pauline phaure <phaurep at gmail.com <mailto:phaurep at gmail.com>> wrote:
>> >
>> > Hello everyone,
>> > I have some troubles making the floating IP work. When I associate a floating IP to my instance, the instance can reach the neutron-router and ping but cannot ping the external gateway. any ideas where to look?
>> >
>> >
>> > <image.png>
>> > _______________________________________________
>> > Rdo-list mailing list
>> > Rdo-list at redhat.com <mailto:Rdo-list at redhat.com>
>> > https://www.redhat.com/mailman/listinfo/rdo-list <https://www.redhat.com/mailman/listinfo/rdo-list>
>> >
>> > To unsubscribe: rdo-list-unsubscribe at redhat.com <mailto:rdo-list-unsubscribe at redhat.com>
>> 
>> Miguel Angel Ajo
>> 
>> 
>> 
>> 
>> 
> 
> Miguel Angel Ajo
> 
> 
> 
> 

Miguel Angel Ajo



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150417/b974d41d/attachment.html>


More information about the dev mailing list