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 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. fbl > > -Vasu > > *Vasu Dasari* > > > On Fri, Jun 14, 2019 at 9:15 AM Flavio Leitner <f...@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 <vdas...@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 <f...@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@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@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 <b...@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 > > > > >> 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
