<div dir="ltr">That's quite how it's supposed to work; however, I'm just now working on getting full scenario testing for that implementation in the gate so it's possible there may be bugs with it. <div><br></div><div>There is an open patch here to fix some forwarding issues caused by the MAC address: <a href="https://review.openstack.org/#/c/436541/">https://review.openstack.org/#/c/436541/</a></div><div>And this patch was just recently back-ported to Newton so you will need to make sure you have it included or else the port won't be attached into the bridge, which is what you may be seeing: <a href="https://review.openstack.org/#/c/434442/">https://review.openstack.org/#/c/434442/</a></div><div><br></div><div>Once you have that latter patch installed, you should see something like the following:</div><div><br></div><div>[tap-parentdevice] -> [bridge-for-net1]</div><div><br></div><div>[tap-subport] -> [bridge-for-net2]</div><div><br></div><div><br></div><div>Then if you run "ip -d link show", you should see an entry showing tap-subport is a child of tap-parentdevice with some output like the following (tap182c5831-5b is the child, tapd84f2134-06 is the parent, and VLAN 10 is the subport segmentation ID):</div><div><br></div><div><div>46: tap182c5831-5b@tapd84f2134-06: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master brq0b3b6476-3b state UP mode DEFAULT group default qlen 1000</div><div>    link/ether fa:16:3e:f3:e5:a6 brd ff:ff:ff:ff:ff:ff promiscuity 1</div><div>    vlan protocol 802.1Q id 10 <REORDER_HDR></div><div>    bridge_slave state forwarding priority 32 cost 100 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64</div></div><div><br></div><div><br></div><div><br></div><div>If you run tcpdump on bridge-for-net2 or bridge-for-net1 you shouldn't ever see the VLAN segmentation ID for the subport. The only place you should see it is if you run tcpdump on the parent port itself.</div><div><br></div><div><br></div><div>Let me know if any of that needs clarification.</div><div><br></div><div>Cheers,</div><div>Kevin Benton</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 7:14 AM, Charles 'Boyo <span dir="ltr"><<a href="mailto:charlesboyo@gmail.com" target="_blank">charlesboyo@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">Hello all.<div><br></div><div>I recently setup the trunk-port plugin in a Newton environment using ML2 LinuxBridge and VLAN segmentation.</div><div><br></div><div>In my setup, the parent-port is a VLAN network (net1) with VLAN-ID 104 while the child-port is attached to another network (net2) with VLAN-ID 50. The physnet (br-vlan) is attached to eth1 on the compute host.</div><div><br></div><div>On starting an instance with the parent-port, I observe that the child-port in plumbed atop the parent such that traffic through it is double-tagged 104 + 50 as observed from the underlying host physical network (eth1) even though there is another bridge setup for net2 with VLAN-ID 50.</div><div><br></div><div>The above description matches how VLAN sub-interfaces are usually setup with Linux bridging but it isn't what I want to achieve here. My requirement is that the child-port is attached in such a way as to have it's traffic exit the physnet with a single VLAN tag of 50. Is that even possible with the current approach to implementing trunk-port on Linux bridges?</div><div><br></div><div>In my understanding, having created a VLAN 50 sub-interface on the physnet (br-vlan) for the net2 bridge, all VLAN 50 traffic is shunted to net2 by the Linux bridging code so communication with the external VLAN 50 network must be via the net2 bridge. Would that mean the parent-port must be attached to a flat network directly connected to the br-vlan physnet?</div><div><br></div><div>Regards,</div><div><br></div><div>Charles</div></div>
<br>______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br></blockquote></div><br></div>