[rdo-list] Issue with IPsec ESP packets dropped even if the security-groups and port security are disabled (using openstack-mitaka release on CentO7.2 system)
by Chinmaya Dwibedy
Hi All,
I have installed openstack-mitaka release on CentO7.2 system.I have
disabled the security-groups and port security for all the neutron
ports/all VMs using below stated.
ML2 port security is enabled in /etc/neutron/plugins/ml2/ml2_conf.ini:
extension_drivers
= port_security
#!/bin/bash
for port in $(neutron port-list -c id -c port_security_enabled -c fixed_ips
| grep True | cut -d '|' -f2); do
echo "Removing security-groups and port_security for port: $port"
neutron port-update --no-security-groups
--port_security_enabled=False $port
done
echo "Completed"
Thereafter when I send IPsec ESP traffic from One VM1 to another VM2, it is
being received and captured (by tcpdump) by the corresponding tap device
but the same is not being received on Linux bridge (qbrxxx) and qvbxxx (of
VM1). Note that, if I send UDP traffic then I do not find any issue. It is
being carried forwarded to VM2.
The VM1's eth0 interface is connected to a Linux tap device tap2caa3b0e-e3
which is plugged into a Linux bridge, qbr2caa3b0e-e3. There are no iptables
filtering applied when packets passing into or out of the Linux bridge. Can
anyone please suggest what might the issue and its solution? Thank you in
advance for your time and support. Here goes the configurations. Please
feel free to let me know if you need any additional information.
[root@stag48 ~(keystone_admin)]# brctl show
bridge name bridge id STP enabled interfaces
qbr2caa3b0e-e3 8000.1ec72d90a310 no qvb2caa3b0e-e3
tap2caa3b0e-e3
qbr408fa3a3-b4 8000.e6f0e680f28f no qvb408fa3a3-b4
tap408fa3a3-b4
qbr5fa991b5-de 8000.02c32f416df0 no qvb5fa991b5-de
tap5fa991b5-de
qbraf134785-23 8000.46e43737b69f no qvbaf134785-23
tapaf134785-23
qbre698fa07-9c 8000.5ea17f458f55 no qvbe698fa07-9c
tape698fa07-9c
qbrf6756f4d-08 8000.b2f79fe90f20 no qvbf6756f4d-08
tapf6756f4d-08
[root@stag48 ~(keystone_admin)]# iptables -S | grep tap2caa3b0e-e3
[root@stag48 ~(keystone_admin)]#
[root@stag48 ~(keystone_admin)]# neutron security-group-rule-list
+--------------------------------------+----------------+-----------+-----------+---------------+------------------+
| id | security_group | direction |
ethertype | port/protocol | remote |
+--------------------------------------+----------------+-----------+-----------+---------------+------------------+
| 16c2d8c8-a286-4b71-8045-94cd303b5c02 | default | ingress |
IPv4 | 22/tcp | 0.0.0.0/0 (CIDR) |
| 2332057f-8c66-4aa6-8700-561b26a5b906 | default | ingress |
IPv4 | any | default (group) |
| 4798772b-561f-4960-85b2-2453613d527e | default | ingress |
IPv6 | any | default (group) |
| 5142e3b2-d2ff-40c5-87eb-5d646852f2d4 | default | ingress |
IPv4 | icmp | 0.0.0.0/0 (CIDR) |
| 7179fc0a-5533-433a-8cc9-3099eeff5a4b | default | egress |
IPv4 | any | any |
| 7cb2f140-6c97-499a-b5f7-6bcc16f6c9a3 | default | ingress |
IPv6 | any | default (group) |
| 829e7607-463a-4c7a-b162-8357f47924d1 | default | ingress |
IPv4 | 1-65535/udp | 0.0.0.0/0 (CIDR) |
| 9f1b8571-3c46-4f53-ac80-835d2186a3c0 | default | egress |
IPv6 | any | any |
| bd46535b-6311-46f6-9b5c-cda78194ac01 | default | egress |
IPv4 | any | any |
| e1b7ab35-8426-4c07-b5bc-d5760b291520 | default | ingress |
IPv4 | any | default (group) |
| e82da2bf-f2e1-4d33-916b-ecb90b5db857 | default | egress |
IPv6 | any | any |
+--------------------------------------+----------------+-----------+-----------+---------------+------------------+
[root@stag48 ~(keystone_admin)]# nova secgroup-list-rules default
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| | | | | default |
| icmp | -1 | -1 | 0.0.0.0/0 | |
| udp | 1 | 65535 | 0.0.0.0/0 | |
| tcp | 22 | 22 | 0.0.0.0/0 | |
| | | | | default |
+-------------+-----------+---------+-----------+--------------+
[root@stag48 ~(keystone_admin)]#
[root@stag48 ~(keystone_admin)]# nova list
+--------------------------------------+-------------+--------+------------+-------------+-------------------------------------------------------------------------+
| ID | Name | Status | Task State
| Power State |
Networks |
+--------------------------------------+-------------+--------+------------+-------------+-------------------------------------------------------------------------+
| 38207997-25af-4113-bc40-109b2745412c | VM2 | ACTIVE | - |
Running | private1=11.0.151.13, 172.19.208.25; private=10.0.151.50,
172.19.208.15 |
| 302f90eb-2d0a-4a74-8e95-92ac8c7e2b71 | VM1 | ACTIVE | - |
Running | private1=11.0.151.14, 172.19.208.26; private=10.0.151.51,
172.19.208.16 |
+--------------------------------------+-------------+--------+------------+-------------+-------------------------------------------------------------------------+
[root@stag48 ~(keystone_admin)]#
Regards,
Chinmaya
8 years, 4 months
[rdo-list] Redeploying UnderCloud
by Gunjan, Milind [CTO]
Hi All,
Greeting.
This is my first post and I am fairly new to RDO OpenStack. I am working on RDO Triple-O deployment on baremetal. Due to incorrect values in undercloud.conf file , my undercloud deployment failed. I would like to redeploy undercloud and I am trying to understand what steps has to be taken before redeploying undercloud. All the deployment was under stack user . So first step will be to delete stack user. I am not sure what has to be done regarding the networking configuration autogenerated by os-net-config during the older install.
Please advise.
Best Regards,
Milind
________________________________
Learn more on how to switch to Sprint and save 50% on most Verizon, AT&T or T-Mobile rates. See sprint.com/50off<http://sprint.com/50off> for details.
________________________________
This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
8 years, 4 months
[rdo-list] python-keystoneclient (2.3.1-2) make wrong URI call for keystone api V3
by Soputhi Sea
Hi,
I'm using Mitaka release (the very latest public release one from Jun-02), and i'm having issue with List Project in Horizon. In my case i have multiple projects created and when i login to Horizon the drop down list of project (on the top left corner) doesn't list properly, it only list one project only. And as I use Apache wsgi as a service instead of keystone python web service, i checked apache log and here is what i found
[23/Jun/2016:17:09:37 +0700] "GET /v3/tenants HTTP/1.1" 404 93 "-" "python-keystoneclient"
[23/Jun/2016:18:47:18 +0700] "POST /v3/tokens HTTP/1.1" 404 93 "-" "keystoneauth1/2.4.1 python-requests/2.10.0 CPython/2.7.5"
You can see here the URI "/v3/tenants" should be "/v2.0/tenants" or "/v3/projects" (i think)
and /v3/tokens should be "/v2.0/tokens" or "/v3/auth/tokens"
So i wonder if this is a bug in the python-keystoneclient or is there any configuration i can do to force the client/keystone/horizon to use a proper URI call?
As a side, i applied a workaround to fix this issue by creating a redirect rule in apache as follow
RewriteEngine on
Redirect /v3/tenants /v2.0/tenants
Redirect /v3/tokens /v2.0/tokens
Thanks in advance for any help.
Puthi
8 years, 4 months
[rdo-list] Grub timing out too quickly on default CentOS 7 Openstack images.
by Jean-Philippe Methot
Hi,
I am using the default CentOS7 image on my Openstack setup. When a VM
boots, I would like to have at least a 20 seconds to choose the kernel
or boot into single user mode. To do so, I have modified the
grub_timeout value in /etc/default/grub . Then, when I run
grub2-mkconfig -o /boot/grub2/grub.cfg, the VM reboots right away and my
changes do not seem to be taken into account. Is there anything I am
missing here?
8 years, 5 months
[rdo-list] dashboards.rdoproject.org is live
by Michael Scherer
Hi,
so Fred found my hideout in the office and did ask me if I could move
the RDO dashboard (https://github.com/rdo-infra/rdo-dashboards) to a
different infra.
So I worked yesterday night and today to produce that:
https://github.com/rdo-infra/ansible-role-rdo_dashboards
and deployed that:
https://dashboards.rdoproject.org
Now, that's the good news.
On the topic of what need to be done:
- fred asked for auto updat eof the code. I am on it, will do tomorow.
- people want to change the domain (as it was decided by fiat by myself)
That should be easy to do, just need to agree on something.
So if people can discuss and decide, be my guest :)
- Alan said he would prefer to have that as a subdirectory rather than a
subdomain, which i would prefer to keep, for technical reasons (as the
whole playbook is done on using different domain names), and since i
want to place that outside of the current server.
The reason for wanting to use another server is there:
https://github.com/rdo-infra/ansible-role-rdo_dashboards/blob/master/task...
since we use gem, we need gcc, ruby, and node. I am not that happy to
have that on the server, so i was looking at moving to openshift v3 (I
got a preview access). That's a long term solution, so for now, let's
keep this way.
Finally, before we decide on the name, please do not publish it around,
I do not want to carry redirection for too long :)
--
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS
8 years, 5 months
[rdo-list] [DLRN] Options to pin packages when needed
by Javier Pena
Hi all,
RDO Trunk repos are meant to package the latest upstream commits, but in some rare cases we may need to pin a specific package to a non-latest commit to temporarily fix a breakage.
This week, we had one of those cases with keystonemiddleware, but the procedure used to do it caused some disruption because some commits were rebuilt, breaking the current-passed-ci and current-tripleo repos for centos-master.
Looking for alternatives, my first idea was the following:
- Temporarily take that package out of rdoinfo using a specific tag (e.g. tag: to-fix)
- And add a working package to an "overrides" repo, included as part of delorean-deps.repo
This avoids any DLRN db hacks, but stops processing updates for the package until the breakage is fixed.
What do you think? Any alternative ideas?
Thanks,
Javier
8 years, 5 months
[rdo-list] Fwd: [openstack-dev] [all][oslo] pbr potential breaking change coming
by Haïkel
We might experience documentation build failures in RDO master in the
near-future.
---------- Forwarded message ----------
From: Doug Hellmann <doug(a)doughellmann.com>
Date: 2016-06-21 15:01 GMT+02:00
Subject: [openstack-dev] [all][oslo] pbr potential breaking change coming
To: openstack-dev <openstack-dev(a)lists.openstack.org>
A while back pbr had a feature that let projects pass "warnerror"
through to Sphinx during documentation builds, causing any warnings in
that build to be treated as an error and fail the build. This lets us
avoid things like links to places that don't exist in the docs, bad but
renderable rst, typos in directive or role names, etc.
Somewhat more recently, but still a while ago, that feature "broke"
with a Sphinx release that was not API compatible. Sachi King has
fixed this issue within pbr, and so the next release of pbr will
fix the broken behavior and start correctly passing warnerror again.
That may result in doc builds breaking where they didn't before.
The short-term solution is to turn of warnerrors (look in your
setup.cfg), then fix the issues and turn it back on. Or you could
preemptively fix any existing warnings in your doc builds before the
release, but it's simple enough to turn off the feature if there isn't
time.
Josh, Sachi, & other Oslo folks, I think we should hold off on
releasing until next week to give folks time. Is that OK?
Doug
PS - Thanks, Sachi, I know that bug wasn't a ton of fun to fix!
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
8 years, 5 months
