Interesting, it sounds similar to what we experienced. We could also ping the client from the router it was connected to, but not from any other routers on the mesh. We logged in to a bunch of routers and roamed around between them, the FDB entry would appear on each router when the roaming occurred, but never disappear off the other routers. We also tested with "external-fdb" enabled, but with no success. I collected a fair bit of info on it, logged a ticket with Mikrotik, and got the answer from them that other projects had priority so they did not have capacity to investigate it, which lead to me working around the problem exactly the same way you did. I will follow up, since they are working on wireless-fp/capsman this type of thing will be front of mind. Regards, Andrew On Mon, Jul 14, 2014 at 2:32 PM, Mike Everest <mike@duxtel.com> wrote:
Hi!
I wasn't aware of that specific behaviour - the problem I was addressing by using the eoip tunnel method is that client devices connected to Ethernet ports would become offline even though the local router could ping both connected device and mesh portal.
The problem happened because of FDB of individual nodes were not consistent throughout the mesh - so would end up with a situation that node A has node B as next-hop, and node B has node A as nexthop. Duh!
I even spent a whole lot of time analysing and documenting, sent it to MT who promptly did nothing about it.
OR, maybe they /did/ do something about it but never bothered to mention it to me or anyone else - I'm not willing to take the time to find out, so eoip scheme continues to be my standard approach to mesh design ;-)
Cheers!
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Andrew Thrift Sent: Monday, 14 July 2014 12:22 PM To: MikroTik Australia Public List Subject: Re: [MT-AU Public] WDS disconnects
Further to Mike's post above regarding dynamic mesh, the reason his solution works is that it bypasses the FDB (Forwarding Database aka MAC database) of HWMP+ by using EoIP tunnels.
There is a long standing issue with HWMP+ where if a client connects on a non- mesh interface that is bridged onto the HWMP+ bridge, the FDB will not be updated when that client leaves. That means if a client connects to AP-1 then roams to AP-2 the MAC address of the client will remain in the FDB of AP-1 seemingly forever...
On Fri, Jul 11, 2014 at 1:50 AM, Andrew Cox <andrew.cox@bigair.net.au> wrote:
I know this isn't a solution to the main problem, but just remember you can set a minimum "wait" time on the watchdog after boot to ensure it doesn't continue to cycle.
- Andrew
On 8 July 2014 21:12, Matt Chipman <mrbc42@gmail.com> wrote:
Hi Mike, we are using dynamic (as opposed to dynamic mesh) and non static (in the MT forums dynamic mesh gets a bad rap). I agree about the loss of connectivity on the ethernet ports as that is what happens on the device connected via ethernet. We have got around this using watchdog and it seems fine as the routers reboot so quick the users dont really notice.
I am considering using watchdog on all the other devices but am concerned about the "perfect storm" scenario where all the devices continually reboot :(
We are already using RTSP on the bridges but maybe I need to investigate your suggestion furthur but the only device with ethernet is the first device so I am not sure if its exactly the same scenario you are describing. but will monitor what you are suggesting
cheers
-Matt
On Tue, Jul 8, 2014 at 8:38 PM, Mike Everest <mike@duxtel.com> wrote:
Hi Matt,
Are you using WDS or Mesh? Also, is the WDS dynamic, or configured static?
We've had some good success using the routerOS proprietary HWMP+ mesh protocol but have definitely seen some problems similar to what (I think) you are describing.
What I have seen is that the mesh devices themselves are stable and stay online without missing a ping, but devices connected to Ethernet port of those mesh APs lose connectivity at apparently random intervals.
The solution we discovered after giving up on trying to diagnose and fix the underlying problem is to overlay a star topology on the underlying mesh.
Essentally, we took out all of the physical Wlan and Ethernet interfaces from the mesh and leave only the wds dynamic interfaces as part of the mesh. Then putting IP address on the mesh bridges, we use those as endpoints for eoip tunnels between those mesh nodes and the mesh portal node. Then use standard bridge (with STP or RSTP) to connect the Ethernet interfaces and wlans.
It's a fair bit of work to set up, but the end result is a solid and very efficient network that still exhibits all of the benefit of dynamic mesh with self learning and repairing mesh.
Maybe an approach that will work for you?
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Matt Chipman Sent: Tuesday, 8 July 2014 8:29 PM To: MikroTik Australia Public List Subject: [MT-AU Public] WDS disconnects
Hi all, does anyone have any issues with WDS?
We have a single RB951G-2HnD connected via ethernet cable to a snapgear which supplies internet. Connected to the 951 are "7" RB9512n via WDS in a rectangular shape (office space) to cover all the users.
This is essentially a guest network and works well most of the time. The problem we have is each device will drop off once in a while and cause outages for the users connected to that device and it either wont reconnect within a reasonable time or will need to be rebooted.
On each router, a bridge is configured and then WDS selected on it. Each wifi signal can connect to at least 2 others so the mesh topology works but I want to get the stability up for the users.
Its not the same device that loses connectivity, its rather random.
any pointers greatly appreciated.
cheers
-Matt _______________________________________________ Public mailing list Public@talk.mikrotik.com.au
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au
http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au