<html><head></head><body>Adam,<br>
<br>
depending on your current setup and what you are trying to do, there are different possibilities.<br>
<br>
The easiest would be if you want transparent VLANs, meaning that neither Neutron nor your VM guests know about VLANs. Then you would have one bridge (earlier: br-join) where all the tagging would take place. The external interfaace would be configured as trunk while each connectick interface is taggedn with the one VLAN ID for its network (from Neutrons view still "outside").<br>
<br>
If you want Neutron to manage VLANs than I'd have to think a bit more about the setup. But in this case, a bit more information about your setup would help, too.<br>
<br>
<br>
Regards,<br>
<br>
Uwe<br><br><div class="gmail_quote">Am 28. April 2015 04:44:33 MESZ, schrieb Adam Lawson <alawson@aqorn.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">So quickly since I'm working on a similar use case:<div><br /></div><div>What are the requirements to implement multiple external networks on the same NIC if we <b>can</b> use VLAN tags? Is it as simple as adding the external network to Neutron the same way we did with the existing external network and trunk that subnet via VLAN#nnn? Is there any special Neuton handlers for traffic on one VLAN versus another?</div></div><div class="gmail_extra"><br clear="all" /><div><div class="gmail_signature"><div dir="ltr"><div><font></font><div style="font-family:arial;font-size:small"><font><b><i><br />Adam Lawson</i></b></font></div><div><font><font color="#666666" size="1"></font></font><div style="font-family:arial"><font><font color="#666666" size="1"><br /></font></font></div><div style="font-family:arial;font-size:small">AQORN, Inc.</div><div style="font-family:arial;font-size:small">427 North Tatnall Street</div><div style="font-family:arial;font-size:small">Ste.
58461</div><div style="font-family:arial;font-size:small">Wilmington, Delaware 19801-2230</div><div style="font-family:arial;font-size:small">Toll-free: (844) 4-AQORN-NOW ext. 101</div><div style="font-family:arial;font-size:small">International: +1 302-387-4660</div><font color="#666666" size="1"></font><div style="font-family:arial;font-size:small"><font color="#666666" size="1">Direct: +1 916-246-2072</font></div></div></div><div style="font-family:arial;font-size:small"><img src="http://www.aqorn.com/images/logo.png" width="96" height="39" /><br /></div></div></div></div>
<br /><div class="gmail_quote">On Mon, Apr 27, 2015 at 10:22 AM, Uwe Sauter <span dir="ltr"><<a href="mailto:uwe.sauter.de@gmail.com" target="_blank">uwe.sauter.de@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 class="HOEnZb"><div class="h5"><br />
>><br />
>><br />
>> if I understood Georges answer correctly he suggested one bridge<br />
>> (br-join, either OVS or linux bridge) to connect other bridges<br />
>> via patch links, one for each external network you'd like to create.<br />
>> These second level bridges are then used for the Neutron<br />
>> configuration:<br />
>><br />
>> br-ext1 -> Neutron<br />
>> /<br />
>> patch-link<br />
>> /<br />
>> ethX –br-join<br />
>> \<br />
>> patch-link<br />
>> \<br />
>> br-ext2 -> Neutron<br />
>><br />
>><br />
>><br />
>> I suggested to use an OVS bridge because there it'd be possible to<br />
>> stay away from the performance-wise worse patch-links and Linux<br />
>> bridges and use "internal" interfaces to connect to Neutron directly<br />
>> – which on second thought won't work if Neutron expects a<br />
>> bridge in that place.<br />
>><br />
>> What I suggested later on is that you probably don't need any second<br />
>> level bridge at all. Just create a second/third external<br />
>> network with appropriate CIDR. As long as those networks are<br />
>> externally connected to your interface (and thus the bridge) you<br />
>> should be good to go.<br />
><br />
> In parallel emails we have established that I have to do what you have drawn. I need to do that the node(s) that run L3<br />
> agents. Do I need to modify the bridge_mappings, flat_networks, or network_vlan_ranges configuration statement on the<br />
> other nodes (compute hosts)?<br />
><br />
> Thanks,<br />
> Mike<br />
><br />
<br />
</div></div>I think you just need to create the cascading bridges with their inter-connects, then tell Neutron the association<br />
between secondary bridge (e.g. br-ext1, br-ext2) and external network. Then create (!) the external networks and restart<br />
Neutron.<br />
<br />
Concerning you intra-cloud networking I don't think you need to reconfigure anything as long as this is already working.<br />
Compute hosts shouldn't be affected as its not their business to know about external networks.<br />
<div class="HOEnZb"><div class="h5"><br />
<br />
Regards,<br />
<br />
Uwe<br />
<br />
_______________________________________________<br />
OpenStack-operators mailing list<br />
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br />
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br />
</div></div></blockquote></div><br /></div>
</blockquote></div><br>
-- <br>
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.</body></html>