2:48 a.m.
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: Images intégrées 3]
3:42 a.m.
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
4:52 a.m.
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
3506
days inactive
3506
days old
2 comments
2 participants
participants (2)
-
Miguel Angel Ajo Pelayo -
pauline phaure