[Rdo-list] no valid host was found: nova problem
by pauline phaure
hello guys ,
When I try to launch an instance, have this error, no valmid host was
found. I found these errors in the file logs of nova and rabbitmq but don't
know how to proceed:
*grep error nova-scheduler.log*
2015-04-17 15:41:25.119 1976 TRACE oslo.messaging._drivers.impl_rabbit
error: [Errno 110] Connection timed out
2015-04-17 16:34:37.163 1959 TRACE oslo.messaging._drivers.impl_rabbit
error: [Errno 110] Connection timed out
*grep error nova-api.log*
2015-04-20 01:13:52.005 4748 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
868d85f2de3d49878af5b6f79d80e8de", "code": 404, "title": "Not Found"}}
2015-04-20 02:13:52.022 4741 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
b309783b561b44ef904b3c4a6ab474bd", "code": 404, "title": "Not Found"}}
2015-04-20 03:13:52.004 4737 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
24eed0bb37b54445bd753359b234a0c4", "code": 404, "title": "Not Found"}}
2015-04-20 04:13:52.033 4741 ERROR nova.api.openstack
[req-b521803c-e80c-4e86-a30b-16e5c57da918 None] Caught error: auth_url was
not provided to the Neutron client
2015-04-20 04:23:52.044 4742 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
6d3e77f2cf75495297c34133bc765bd8", "code": 404, "title": "Not Found"}}
2015-04-20 05:23:52.047 4736 ERROR nova.api.openstack
[req-95702e17-0960-451a-b5c1-828172b27bc0 None] Caught error: auth_url was
not provided to the Neutron client
2015-04-20 05:33:52.024 4731 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
ccaee1e396614df5a753a331345e3e24", "code": 404, "title": "Not Found"}}
2015-04-20 06:33:52.013 4740 ERROR nova.api.openstack
[req-711d560d-e9c3-48f3-aabe-28e138ae06e1 None] Caught error: auth_url was
not provided to the Neutron client
2015-04-20 06:43:51.887 4737 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
6ad03759c8f446d09d4babde1aa7f63d", "code": 404, "title": "Not Found"}}
2015-04-20 07:43:52.178 4747 ERROR nova.api.openstack
[req-d0caca70-b960-4612-b99f-ca42292cb6b4 None] Caught error: auth_url was
not provided to the Neutron client
2015-04-20 07:53:52.037 4742 WARNING keystonemiddleware.auth_token [-]
Identity response: {"error": {"message": "Could not find token:
0bcaad841985487bbfe4bce038b49c9e", "code": 404, "title": "Not Found"}}
*grep error /var/log/rabbitmq/rabbit\(a)localhost.log*
AMQP connection <0.865.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1312.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.499.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1657.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9349.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.761.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.2801.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.4447.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1065.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.712.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.618.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.664.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9428.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1222.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9530.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9496.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.6746.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9479.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9280.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9295.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1203.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1420.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.9513.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1048.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.741.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1734.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1390.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1400.0> (running), channel 0 - error:
{amqp_error,connection_forced,
AMQP connection <0.1430.0> (running), channel 0 - error:
{amqp_error,connection_forced,
9 years
[Rdo-list] Heads up on Horizon changes in RDO for Kilo release
by Matthias Runge
Hello,
tl;dr: About packaging changes in Horizon.
If you did not change horizon and you're not packaging plugins for
Horizon, you don't need to change anything.
Kilo is nearing its release and I did some changes on horizons packaging.
* Static file location was on /static before, which is not consistent
with /dashboard. Since Kilo, Horizon now uses a config option to address
all files belonging to Horizon, in our case, everything is now under
/dashboard, and static files under /dashboard/static.
For reference, it used to be /dashboard and /static, which doesn't match
that well, when sharing a web server.
* Before last week, static files were compressed at package build time,
which required addons to do ugly hacks at install time. Further more, if
there was an issue with static files, one would have needed to run some
steps manually or to rebuild horizon as whole. Luckily that never
happened though.
Now I implemented a small hook into httpd systemd unit to rebuild
compressed files at httpd start time. No hacks needed any more, after an
update of static files, one needs to restart the web server (which would
be required anyways) and you're fine.
Matthias
9 years
[Rdo-list] openvswitch problem
by Vedsar Kushwaha
I installed openstack juno on centos7.
Then I updated centos7, using yum update.
Now when I restart centos7, I'm not able to ping any other computer on same
network. (Earlier I was able to ping). Packet is not going outside my
computer.
openvswitch status is "running". But when I restart openvswitch everything
starts working. The openvswitch status is still remains "running" after
restart.
Can someone explain me what is the problem?
--
Vedsar Kushwaha
M.Tech-Computational Science
Indian Institute of Science
9 years
[Rdo-list] RDO Juno + orchestration
by Hamid Noroozi
Hi all,
I'm trying RDO Juno on a single blade running RHEL7.1.After a fresh
install using packstack, I don't see the orchestration services like
heat to be installed. Am I doing it wrong? Do I need to enable something
to include all openstack services/projects in my installation?
--
Regards,
Hamid
9 years
[Rdo-list] DNS resolver problems w/ instack-virt-setup
by Lars Kellogg-Stedman
On the overcloud nodes deployed by instack-virt-setup,
/etc/resolv.conf looks like this:
search openstacklocal
nameserver 192.168.122.1
That's not a useful address for either of these nodes, on which
external connectivity -- at least on the controller -- is via
eth0/br-ex on the 192.0.2.0/24 network. Even worse, on the controller
"192.168.122.1" is actually the address of the local "virbr0"
interface configured by libvirt, so DNS requests aren't going to go
anywhere useful.
There are obviously a number of ways to fix this, including setting up
dnsmasq on the undercloud node and using that instead. How is this
supposed to work? Did the deployments script screw up, or did I miss
something in the docs?
--
Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
9 years
Re: [Rdo-list] Problem with floating IP
by Miguel Angel Ajo Pelayo
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
9 years
Re: [Rdo-list] Rdo-list Digest, Vol 25, Issue 28
by pauline phaure
this is my architecture , i don't know how to connecte br-ex to external
and ping the router. any ideas ?
[image: Images intégrées 2]
2015-04-17 16:00 GMT+02:00 <rdo-list-request(a)redhat.com>:
> Send Rdo-list mailing list submissions to
> rdo-list(a)redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/rdo-list
> or, via email, send a message with subject or body 'help' to
> rdo-list-request(a)redhat.com
>
> You can reach the person managing the list at
> rdo-list-owner(a)redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rdo-list digest..."
>
>
> Today's Topics:
>
> 1. Re: Problem with floating IP (pauline phaure)
> 2. Re: Help getting started with rdo-manager (Lars Kellogg-Stedman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 17 Apr 2015 15:55:08 +0200
> From: pauline phaure <phaurep(a)gmail.com>
> To: Miguel Angel Ajo Pelayo <mangelajo(a)redhat.com>
> Cc: rdo-list(a)redhat.com
> Subject: Re: [Rdo-list] Problem with floating IP
> Message-ID:
> <
> CAJM-u-X51u8xgEp9FQj4tmSbvG0GnUc0taj1SUMrx7rjzVXqLQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://www.redhat.com/archives/rdo-list/attachments/20150417/2f2d9cfd/at...
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 17 Apr 2015 10:00:11 -0400
> From: Lars Kellogg-Stedman <lars(a)redhat.com>
> To: Omri Hochman <ohochman(a)redhat.com>
> Cc: rdo-list(a)redhat.com
> Subject: Re: [Rdo-list] Help getting started with rdo-manager
> Message-ID: <20150417140011.GF18285(a)redhat.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > I think you should have check that in /etc/edeploy/state you have
> > --> : [('control', 1), ('compute', '*')]
>
> Omri,
>
> Thanks, that did get me one step closer.
>
> The deploy is still failing, but now it's due to the following
> resource:
>
> | ControllerNodesPostDeployment | 9a24f414-4e35-4d27-b550-77d47651f56a
> | OS::TripleO::ControllerPostDeployment | CREATE_FAILED |
> 2015-04-17T01:28:32Z |
>
> --
> Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @
> {freenode,twitter,github}
> Cloud Engineering / OpenStack | http://blog.oddbit.com/
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: not available
> URL: <
> https://www.redhat.com/archives/rdo-list/attachments/20150417/6e784186/at...
> >
>
> ------------------------------
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
>
> End of Rdo-list Digest, Vol 25, Issue 28
> ****************************************
>
9 years
