[Rdo-list] Rdo-list Digest, Vol 25, Issue 28
pauline phaure
phaurep at gmail.com
Fri Apr 17 14:41:03 UTC 2015
plz find attached the output of ovs-vsctl show
2015-04-17 16:21 GMT+02:00 Pedro Sousa <pgsousa at gmail.com>:
> Hi Pauline can you show how did you setup the bridges?
>
> # ovs-vsctl show
>
> Regards,
> Pedro Sousa
>
>
> On Fri, Apr 17, 2015 at 3:07 PM, pauline phaure <phaurep at gmail.com> wrote:
>
>> 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 at redhat.com>:
>>
>>> Send Rdo-list mailing list submissions to
>>> rdo-list at 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 at redhat.com
>>>
>>> You can reach the person managing the list at
>>> rdo-list-owner at 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 at gmail.com>
>>> To: Miguel Angel Ajo Pelayo <mangelajo at redhat.com>
>>> Cc: rdo-list at redhat.com
>>> Subject: Re: [Rdo-list] Problem with floating IP
>>> Message-ID:
>>> <
>>> CAJM-u-X51u8xgEp9FQj4tmSbvG0GnUc0taj1SUMrx7rjzVXqLQ at 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 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> 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 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 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 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> 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
>>> >>> > https://www.redhat.com/mailman/listinfo/rdo-list
>>> >>> >
>>> >>> > To unsubscribe: rdo-list-unsubscribe at 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/attachment.html
>>> >
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Fri, 17 Apr 2015 10:00:11 -0400
>>> From: Lars Kellogg-Stedman <lars at redhat.com>
>>> To: Omri Hochman <ohochman at redhat.com>
>>> Cc: rdo-list at redhat.com
>>> Subject: Re: [Rdo-list] Help getting started with rdo-manager
>>> Message-ID: <20150417140011.GF18285 at 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 at 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/attachment.bin
>>> >
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Rdo-list mailing list
>>> Rdo-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/rdo-list
>>>
>>>
>>> End of Rdo-list Digest, Vol 25, Issue 28
>>> ****************************************
>>>
>>
>>
>> _______________________________________________
>> Rdo-list mailing list
>> Rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150417/123af14e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 11855 bytes
Desc: not available
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150417/123af14e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20150417_163705.jpg
Type: image/jpeg
Size: 2295404 bytes
Desc: not available
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150417/123af14e/attachment.jpg>
More information about the dev
mailing list