[ovs-discuss] Vlan transparency in OVN

Daniel Alvarez Sanchez dalvarez at redhat.com
Thu Jun 4 08:56:45 UTC 2020


Hi Slawek

On Thu, Jun 4, 2020 at 9:53 AM Slawek Kaplonski <skaplons at redhat.com> 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
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200604/0d83b282/attachment-0001.html>


More information about the discuss mailing list