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

Reply via email to