7:23 a.m.
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(a)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(a)gmail.com
<mailto: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 <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(a)redhat.com
<mailto: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(a)gmail.com
<mailto: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(a)redhat.com <mailto:Rdo-list@redhat.com>
> https://www.redhat.com/mailman/listinfo/rdo-list
<https://www.redhat.com/mailman/listinfo/rdo-list>
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
<mailto:rdo-list-unsubscribe@redhat.com>
Miguel Angel Ajo
Miguel Angel Ajo
8:55 a.m.
New subject: [Rdo-list] Problem with floating IP
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(a)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(a)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(a)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 <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: 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(a)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(a)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(a)redhat.com
>> > https://www.redhat.com/mailman/listinfo/rdo-list
>> >
>> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
>>
>> Miguel Angel Ajo
>>
>>
>>
>>
>
Miguel Angel Ajo
10 a.m.
New subject: [Rdo-list] Problem with floating IP
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(a)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(a)redhat.com
<mailto: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(a)gmail.com
<mailto: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 <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(a)gmail.com
<mailto: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 <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(a)redhat.com
<mailto: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(a)gmail.com
<mailto: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(a)redhat.com <mailto:Rdo-list@redhat.com>
> > https://www.redhat.com/mailman/listinfo/rdo-list
<https://www.redhat.com/mailman/listinfo/rdo-list>
> >
> > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
<mailto:rdo-list-unsubscribe@redhat.com>
>
> Miguel Angel Ajo
>
>
>
>
>
Miguel Angel Ajo
Miguel Angel Ajo
3506
days inactive
3506
days old
2 comments
2 participants
participants (2)
-
Miguel Angel Ajo Pelayo -
pauline phaure