[ovs-discuss] VxLAN in Userspace

Vasu Dasari vdasari at gmail.com
Tue Jun 18 19:12:51 UTC 2019


On Tue, Jun 18, 2019 at 12:21 PM Flavio Leitner <fbl at sysclose.org> wrote:

> On Tue, Jun 18, 2019 at 10:41:16AM -0400, Vasu Dasari wrote:
> > Flavio,
> >
> > The device(could be a regular interface) should have been added to OVS
> with
> > "add-port" and when it is removed, ARP entries learnt on it well be
> removed
> > as well.
>
> Not necessarily. You could have a regular kernel interface with the
> tunnel endpoint address which is not part of an OVS bridge.
>

The code being added should cover that as well. Probably you can comment on
this after you look at my code.

>
> > The code is ready. Regarding, testing the code I am planning on extending
> > already existing case where tests are performed to check ARP entry
> > existence, like for example, "tunnel_push_pop - underlay bridge match" in
> > tunnel-push-pop.at. I hope that is fine, or should I be writing a
> separate
> > unit test case?
>
> Usually we just add more tests to the file to cover additional
> use-cases.
>
> Ok. Will add a new test case then.

On another note, I see ARP neighbor add and show commands. This covers L3
side. For L2 side, I see fdb show command, but there is no set command. I
would like to add that one also. Any comments?

Current fdb show:
ovs-appctl fdb/show s1

Proposed CLI for fdb/set operation would look like:
ovs-appctl fdb/set <bridge> <port> <vlan> <Mac>
ovs-appctl fdb/set s1 2 0 00:00:01:00:00:02

What do you think?

Thanks
-Vasu

fbl
>
> >
> > -Vasu
> >
> > *Vasu Dasari*
> >
> >
> > On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner <fbl at sysclose.org> wrote:
> >
> > > On Thu, Jun 13, 2019 at 10:58:21PM -0400, Vasu Dasari wrote:
> > > > Flavio,
> > > >
> > > > tnl_neigh_cache_flush(), flushes entire tunnel ARP table. When a
> bridge
> > > is
> > > > removed, ARP entries learnt on that bridge alone have to be removed.
> > > > Entries from other bridges have to be in tact.
> > > >
> > > > I am thinking of doing the following:
> > > >
> > > > 1. Write a new API in lib/tnl-neigh-cache.c: tnl_neigh_flush(const
> char*
> > > > br_name) which purges all neighbor entries on bridge br_name.
> > >
> > > That's better, indeed.
> > >
> > >
> > > > 2. From ofproto/ofproto-dpif-xlate.c: xlate_xbridge_remove() invoke
> the
> > > > function tnl_neigh_flush () to flush the entries.
> > > >
> > > > til_neigh_xxx() functions are getting called from
> ofproto-dpif-xlate.c,
> > > and
> > > > hence thinking that xlate_xbridge_remove() is a right place to do the
> > > job.
> > > >
> > > > What do you think?
> > >
> > > The device with the IP address can be any regular interface, so
> > > do you think it would work if you remove a device that is out of
> > > OVS?
> > >
> > > fbl
> > >
> > > >
> > > > -Vasu
> > > >
> > > >
> > > > On Thu, Jun 13, 2019 at 7:27 PM Vasu Dasari <vdasari at gmail.com>
> wrote:
> > > >
> > > > > Yes Flavio. Looking at code to fix this. Will send fix for review
> soon.
> > > > >
> > > > > Vasu
> > > > >
> > > > > > On Jun 13, 2019, at 7:15 PM, Flavio Leitner <fbl at sysclose.org>
> > > wrote:
> > > > > >
> > > > > >> On Wed, Jun 12, 2019 at 07:18:27PM -0400, Vasu Dasari wrote:
> > > > > >> Thanks Ben. Meanwhile I think I found an bug in OVS 2.9.0 with
> > > stale ARP
> > > > > >> entries after a bridge is deleted.
> > > > > >>
> > > > > >> I ran my tunneling experiment successfully. Used mininet to
> > > simulate the
> > > > > >> environment. After quitting the mininet, switch s1 is deleted.
> But,
> > > I
> > > > > still
> > > > > >> see the ARP entries in OVS.
> > > > > >
> > > > > > Looks like when route_table_valid is false we also need to
> > > > > > call tnl_neigh_cache_flush() otherwise you will need to wait
> > > > > > the ARP entry in the cache to expire (15min?) which is quite
> > > > > > a long time.
> > > > > >
> > > > > > Do you think you can work on a patch?
> > > > > >
> > > > > >> root at mn1:~# ovs-vsctl show
> > > > > >> f6af5f1c-a11c-435f-9b03-7317f364ae48
> > > > > >>    Manager "ptcp:6640"
> > > > > >>    ovs_version: "2.9.0"
> > > > > >>
> > > > > >> Even thought there is no s1, I still see entries here.
> > > > > >> root at mn1:~# ovs-appctl tnl/arp/show
> > > > > >> IP                                            MAC
> > >  Bridge
> > > > > >>
> > > > >
> > >
> ==========================================================================
> > > > > >> 172.168.1.1
>  02:42:ac:14:00:02   s1
> > > > > >> 172.168.1.2
>  02:42:ac:14:00:03   s1
> > > > > >> 10.0.0.10
>  82:ec:29:c0:bc:ef   s1
> > > > > >> 10.0.0.1
> d2:54:11:f0:95:df   s1
> > > > > >>
> > > > > >>
> > > > > >> Just for completeness, this is what I had to do to fix my
> > > configuration.
> > > > > >>
> > > > > >> Figured out what was wrong with my configuration.
> > > > > >>
> > > > > >> Modify my bridge s1 to be:
> > > > > >>
> > > > > >> ovs-vsctl --may-exist add-br s1 \
> > > > > >>    -- set Bridge s1 datapath_type=netdev \
> > > > > >>    -- set bridge s1 fail-mode=standalone \
> > > > > >>         other_config:hwaddr=$(cat /sys/class/net/eth1/address)
> > > > > >>
> > > > > >> Add the flows:
> > > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=s1-eth1 actions=vxlan"
> > > > > >> ovs-ofctl add-flow s1 "priority=1,in_port=vxlan actions=s1-eth1"
> > > > > >> ovs-ofctl add-flow s1 "priority=0 actions=NORMAL"
> > > > > >>
> > > > > >> ip addr add 1.1.1.1/24 dev s1
> > > > > >> ip link set s1 up
> > > > > >> ip addr flush dev eth1 2>/dev/null
> > > > > >> ip link set eth1 up
> > > > > >>
> > > > > >> ovs-appctl tnl/arp/set s1 1.1.1.2 00:00:01:00:00:02
> > > > > >
> > > > > > Yeah, that will replace the old entry with the new one.
> > > > > >
> > > > > > fbl
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> *Vasu Dasari*
> > > > > >>
> > > > > >>
> > > > > >>> On Tue, Jun 11, 2019 at 6:22 PM Ben Pfaff <blp at ovn.org> wrote:
> > > > > >>>
> > > > > >>>> On Tue, Jun 11, 2019 at 03:17:24PM -0400, Vasu Dasari wrote:
> > > > > >>>> I am running into an issue which sounds pretty basic,
> probably I
> > > > > might be
> > > > > >>>> missing something.
> > > > > >>>
> > > > > >>> I think you're trying to use kernel tools to configure
> userspace
> > > > > >>> tunnels.  Did you read
> Documentation/howto/userspace-tunneling.rst?
> > > > > >>>
> > > > > >
> > > > > >> _______________________________________________
> > > > > >> 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/20190618/c15b95d0/attachment.html>


More information about the discuss mailing list