On Tue, Jun 02, 2020 at 01:25:05PM +0200, Slawek Kaplonski wrote: > Hi, > > I work in OpenStack Neutron mostly. We have there extension called > "vlan_transparent". See [1] for details. > Basically it allows to send traffic with vlan tags directly to the VMs. > > Recently I was testing if that extension will work with OVN backend used in > Neutron. And it seems that we have work to do to make it working. > From my test I found out that for each port I had rule like: > > cookie=0x0, duration=17.580s, table=8, n_packets=6, n_bytes=444, > idle_age=2, priority=100,metadata=0x2,vlan_tci=0x1000/0x1000 actions=drop > > which was dropping those tagged packets. After removal of this rule traffic > was > fine. > So we need to have some way to tell northd that it shouldn't match on vlan_tci > at all in case when neutron network has got vlan_transparency set to True. > > From the discussion with Daniel Alvarez he told me that somehow we can try to > leverage such columns to request transparency (for example: parent_name=none > and tag_request=0). With this, northd can enforce transparency per port. > > Another option could be to create an option in the “other_config” column in > the > logical switch to have the setting per Neutron network > (other_config:vlan_transparent) While this seems more natural, it may break > the > trunk/subport current feature. > > What do You, as ovn developers thinks about that? > Is that maybe possible somehow to do currently in northd? Or is one of the > options given above doable and acceptable for You?
This might be a place to consider using QinQ (at least, until Neutron introduces QinQ transparency). _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
