Hi Ryan,
On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats <rmo...@us.ibm.com> wrote: > Jay Pipes <jaypi...@gmail.com> wrote on 08/06/2014 01:04:41 PM: > > [snip] > > > > AFAICT, there is nothing that can be done with the GBP API that cannot > > be done with the low-level regular Neutron API. > > I'll take you up on that, Jay :) > > How exactly do I specify behavior between two collections of ports > residing in the same IP subnet (an example of this is a bump-in-the-wire > network appliance). > > Would you mind explaining what behavior you want between the two collection of ports? > I've looked around regular Neutron and all I've come up with so far is: > (1) use security groups on the ports > (2) set allow_overlapping_ips to true, set up two networks with identical > CIDR block subnets and disjoint allocation pools and put a vRouter between > them. > > Now #1 only works for basic allow/deny access and adds the complexity of > needing to specify per-IP address security rules, which means you need the > ports to have IP addresses already and then manually add them into the > security groups, which doesn't seem particularly very orchestration > friendly. > I believe the referential security group rules solve this problem (unless I'm not understanding): neutron security-group-create group1 neutron security-group-create group2 # allow members of group1 to ssh into group2 (but not the other way around): neutron security-group-rule-create --direction ingress --port-range-min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2 # allow members of group2 to be able to access TCP 80 from members of group1 (but not the other way around): neutron security-group-rule-create --direction ingress --port-range-min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1 # Now when you create ports just place these in the desired security groups and neutron will automatically handle this orchestration for you (and you don't have to deal with ip_addresses and updates). neutron port-create --security-groups group1 network1 neutron port-create --security-groups group2 network1 > > Now #2 handles both allow/deny access as well as provides a potential > attachment point for other behaviors, *but* you have to know to set up the > disjoint allocation pools, and your depending on your drivers to handle the > case of a router that isn't really a router (i.e. it's got two interfaces > in the same subnet, possibly with the same address (unless you thought of > that when you set things up)). > > Are you talking about the firewall as a service stuff here? > You can say that both of these are *possible*, but they both look more > complex to me than just having two groups of ports and specifying a policy > between them. > Would you mind proposing how this is done in the Group policy api? From what I can tell in the new proposed api you'd need to map both of these groups to different endpoints i.e networks. > > > Ryan Moats > > > Best, Aaron > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
