[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <c234beeb-5511-f33c-1232-638e9c9a3ac2@ti.com>
Date: Fri, 13 Dec 2019 16:18:02 -0500
From: Murali Karicheri <m-karicheri2@...com>
To: <netdev@...r.kernel.org>, "Kwok, WingMan" <w-kwok2@...com>
Subject: RSTP with switchdev question
Hi Netdev experts,
We are working on a switchdev based switch driver with L2 and stp
offload. Implemented the driver based on
Documentation/networking/switchdev.txt
Currently seeing an issue with switch over of a link failure. So
wondering how this is supposed to work. So any help on this will
be highy appreciated.
0 1
|-------X---------- B ----------------------|
A C root
|-------------------------------------------|
Figure 1)
At the start, A, B and C nodes are brought up and mstpd is started
on all nodes and we get a toplogy as above with X marking the link
that breaks the loop. We run a Ping from C to A and it works fine
and takes the direct path from C to A. We then simulate a link
failure to trigger topology change by disconnecting of the link
A to C. Switch over happens and the topology gets updated quickly
and we get the one below in Figure 2).
Case 2)
0 1
|------------------ B ----------------------|
A C root
|-------------------X-----------------------|
Figure 2)
The ping stops and resume after about 30 seconds instead of right
away as expected in rstp case which should be in milliseconds. On
debug we found following happening.
1) In the steady state, the fdb dump at the firmware on B (This
implements the switch) shows that both A and C appears on port
1 as expected.
2 After switch over, Ping frame from C with A's MAC address gets
sent to B. However B's fdb entry is still showing it is at
port 1. Since the frame arrived from C, it drops the frame.
So the question is, in this scenario, how does the data path
restored quickly? Looks like for this to happen FDB at the nodes
needs to get flushed or re-learned so that it will show all nodes
at the correct port in the new topology. So in this case at node
B, A should appear on port 0 instead of port 1 so that L2
forwarding happens correctly? As expected, if another ping is
initiated from A to C, the other ping (C to A) starts working as
the FDB at B is updated. But if data path needs to be restored
quickly, these fdb update should happen immediately. How does
this happen?
Thanks
Murali
--
Murali Karicheri
Texas Instruments
Powered by blists - more mailing lists