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@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@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@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: ICMP host 192.168.2.1 unreachable, length 92
    192.168.2.72 > 10.0.0.4: ICMP host 192.168.2.1 unreachable, length 92
    192.168.2.72 > 10.0.0.4: ICMP host 192.168.2.1 unreachable, length 92
    192.168.2.72 > 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@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 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 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 brd 192.168.2.255 scope global qg-52b4d686-58
       valid_lft forever preferred_lft forever
    inet 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: 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: 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@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@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@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe@redhat.com

Miguel Angel Ajo






Miguel Angel Ajo





Miguel Angel Ajo