<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro <span dir="ltr"><<a href="mailto:ivarlazzaro@gmail.com" target="_blank">ivarlazzaro@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Aaron,<div><br></div><div>Please note that the user using the current reference implementation doesn't need to create Networks, Ports, or anything else. As a matter of fact, the mapping is done implicitly.</div>
</div></blockquote><div><br></div><div><br></div><div>The user still needs to create an endpointgroup. What is being done implicitly here? I fail to see the difference.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br></div><div>Also, I agree with Kevin when he says that this is a whole different discussion.</div><div><br></div><div>Thanks,</div><div>Ivar.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 9:12 PM, Aaron Rosen <span dir="ltr"><<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ryan, <div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div>On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats <span dir="ltr"><<a href="mailto:rmoats@us.ibm.com" target="_blank">rmoats@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
<p><tt><font>Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote on 08/06/2014 01:04:41 PM:<br>
<br>
[snip]</font></tt></p><div><br>
<tt><font><br>
> AFAICT, there is nothing that can be done with the GBP API that cannot <br>
> be done with the low-level regular Neutron API.</font></tt><br>
<br>
</div><tt><font>I'll take you up on that, Jay :)</font></tt><br>
<br>
<tt><font>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).</font></tt><br>
<br></div></blockquote></div><div>Would you mind explaining what behavior you want between the two collection of ports? <br></div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<tt><font>I've looked around regular Neutron and all I've come up with so far is:</font></tt><br>
<tt><font> (1) use security groups on the ports</font></tt><br>
<tt><font> (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.</font></tt><br>
<br>
<tt><font>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.</font></tt></div>
</blockquote><div><br></div></div><div>I believe the referential security group rules solve this problem (unless I'm not understanding): </div><div><br></div><div>neutron security-group-create group1</div><div>neutron security-group-create group2</div>
<div><br></div><div># allow members of group1 to ssh into group2 (but not the other way around):</div><div>neutron security-group-rule-create --direction ingress --port-range-min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2</div>
<div><br></div><div># allow members of group2 to be able to access TCP 80 from members of group1 (but not the other way around): </div><div><div>neutron security-group-rule-create --direction ingress --port-range-min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1</div>
</div><div><br></div><div># 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). </div>
<div><br></div><div>neutron port-create --security-groups group1 network1</div><div>neutron port-create --security-groups group2 network1 </div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
<br>
<tt><font>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)).</font></tt><br>
<br></div></blockquote><div><br></div></div><div>Are you talking about the firewall as a service stuff here? </div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<tt><font>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.</font></tt></div></blockquote><div><br></div></div>
<div>
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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><span><font color="#888888"><br>
<br>
<tt><font>Ryan Moats</font></tt></font></span><p></p></div><br></blockquote><div>Best, </div><span><font color="#888888"><div><br>Aaron </div></font></span><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>