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 <rbry...@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@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
