[ovs-dev] Testing OpenStack security groups with OVN ACLs

Russell Bryant rbryant at redhat.com
Thu Oct 8 18:58:24 UTC 2015


On 10/06/2015 08:00 PM, Russell Bryant wrote:
> On 10/07/2015 12:44 AM, Justin Pettit wrote:
>>
>>> On Sep 23, 2015, at 2:35 PM, Russell Bryant <rbryant at redhat.com> wrote:
>>>
>>> Joe and I discussed this some on IRC.  He replicated the key parts of my
>>> test in his environment and it seemed to behave correctly.  My test is
>>> also against a slightly older version of the ovs conntrack code, which
>>> *could* behave differently in some way.  Since the userspace patches
>>> seem so close to being merged, we decided I'd just revisit this test
>>> once the userspace support is merged and the rest can be rebased on
>>> that.  It seemed like a better use of time to just put it off a bit and
>>> all use the same code.
>>
>> Hi, Russell.  I pushed a rebased version of OVN ACL support with all of Joe's most recent changes here:
>>
>> 	https://github.com/justinpettit/ovs/tree/ovn-acl
>>
>> Can you give it a try?  It's the same location as before, so it was a
>> forced push.  If you did any local changes, you may want to keep that
>> in mind.
> 
> Yes, I'll give it a try this week.  I'm flying home tomorrow so it will
> probably be Thursday/Friday.
> 

I tried it and the short version is that I got the same result as
before.  I've set it up again on a VM in a public cloud that you or Joe
can log in to and take a look.  (I'll send a private mail with
connection details).

Once you're in, here's how to recreate my issue.

$ cd ~/devstack
$ source openrc

There's a single VM running.  Its IP address is 10.0.0.3.  Both of these
should work:

$ ping 10.0.0.3
$ ssh -i demo.key cirros at 10.0.0.3

This works because the Neutron port does not current have a security
group applied to it.  There is a security group named "default" that we
can apply to the port.  You can view the security group's details with
this command:

> $ neutron security-group-list
> +--------------------------------------+---------+----------------------------------------------------------------------+
> | id                                   | name    | security_group_rules                                                 |
> +--------------------------------------+---------+----------------------------------------------------------------------+
> | 62eb7e47-b973-4c00-83b8-d6e819e9d16a | default | egress, IPv4                                                         |
> |                                      |         | egress, IPv6                                                         |

Allow all outbound IP traffic.

> |                                      |         | ingress, IPv4, 22/tcp, remote_ip_prefix: 0.0.0.0/0                   |
> |                                      |         | ingress, IPv4, icmp, remote_ip_prefix: 0.0.0.0/0                     |

Allow inbound SSH and ICMP (and its return traffic) from any source.

> |                                      |         | ingress, IPv4, remote_group_id: 62eb7e47-b973-4c00-83b8-d6e819e9d16a |
> |                                      |         | ingress, IPv6, remote_group_id: 62eb7e47-b973-4c00-83b8-d6e819e9d16a |

Allow all inbound IP traffic from other ports using the same security
group (doesn't apply to this test, it was just part of the default rules).

> +--------------------------------------+---------+----------------------------------------------------------------------+

Now update the port with this security group:

$ neutron port-update --security-group default
da2fc639-38db-4b7c-b3c4-a69611b516be

At this point, ping and ssh don't work.  As far as I can tell, the
policy I've set up using OVN ACLs and the resulting OpenFlow flows
should allow it.  Based on earlier analysis, I think return traffic is
being dropped as invalid.

If you want to restore the port back to having no security group, run
this command:

$ neutron port-update --no-security-group
da2fc639-38db-4b7c-b3c4-a69611b516be

ping and ssh should now work again.

A bit more info on this setup ...

Connectivity into the OVN logical network on br-int is done through br-ex.

$ ip route list
...
10.0.0.0/24 via 172.24.4.2 dev br-ex

If you look at br-int, there are 4 ports:

> $ sudo ovs-ofctl show br-int
...
>  1(tapfff46033-e2): addr:00:00:00:00:00:00

This is created for the Neutron DHCP agent.  There's a dnsmasq process
on the other side providing DHCP services to our logical network.

>  2(qr-8d036142-73): addr:00:00:00:00:00:00
>  3(qr-12aa6cc9-d4): addr:00:00:00:00:00:00

These's two ports are created by Neutron's L3 agent.  They are router
ports.  You'll see IPv4 traffic coming into the network via one of them
and IPv6 via another.

>  4(tapda2fc639-38): addr:fe:16:3e:c4:92:25

This is for the VM.

So, the ping request should come in br-int via port 2 and go out port 4.
 The response should come in via port 4 and back out port 2.

-- 
Russell Bryant



More information about the dev mailing list