[ovs-discuss] Vlan transparency in OVN
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? [1] https://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html -- Slawek Kaplonski Senior software engineer Red Hat ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Vlan transparency in OVN
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
Re: [ovs-discuss] Vlan transparency in OVN
Hi, On Tue, Jun 02, 2020 at 05:37:37PM -0700, Ben Pfaff wrote: > 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). I'm not sure if I understand. For now Neutron don't supports QinQ - old RFE is postponed currently [1]. And my original use case is related to the Neutron tenant networks which is Geneve type. How QinQ can help with that? > [1] https://bugs.launchpad.net/neutron/+bug/1705719 -- Slawek Kaplonski Senior software engineer Red Hat ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Vlan transparency in OVN
Hi Slawek On Thu, Jun 4, 2020 at 9:53 AM Slawek Kaplonski wrote: > Hi, > > On Tue, Jun 02, 2020 at 05:37:37PM -0700, Ben Pfaff wrote: > > 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). > > I'm not sure if I understand. For now Neutron don't supports QinQ - old > RFE is > postponed currently [1]. > And my original use case is related to the Neutron tenant networks which is > Geneve type. How QinQ can help with that? > I think that Ben's suggestion could possibly allow you to achieve your goal while at the same time having QinQ in OVN:? On one hand, not matching on CFI bit (vlan_tci=0x1000/0x1000) based on some configuration of the Logical Switch, would achieve the VLAN transparency by allowing traffic tagged on a logical switch port that is originally untagged. While this is probably enough for your use case, it'll break the trunk/subport use case where we expect the traffic to be tagged. In this case we'll need to pop one VLAN tag (the one to achieve VLAN transparency) and match on the second tag to determine the logical port (subport). This could be solved in the general case by QinQ but looks more complex I believe. Thoughts? > > > [1] https://bugs.launchpad.net/neutron/+bug/1705719 > > -- > Slawek Kaplonski > Senior software engineer > Red Hat > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
