PT, Thanks for your attention to this, it is much appreciated. And yep... the theory of election criteria, its like a shell game. Ha. I am starting to think this is the path to the answer though, just need to prove it. I can as you suggest set the OS level of one of the DNS-321's to a higher level, but as they are configured that would only be a temporary fix since the 321s do not like retaining edits to the smb.conf file. I believe there are tricks to accomplish that, but have not explored that methodology. For the moment I would prefer to drill down on this first, not ruling out setting another NAS to a higher OS Level and/or designating one as preferred and OS Levlel 65?
At this point I believe additional progress/info will come from a capture of UDP 137/138/139 while watching the 868L force an election and take master. Prior to the recent addition of my 'new' 868L to the network, the DNS-321's had cooperated as master/backup browser since 2011 or so. 1 DNS-321 will routinely take master and the other takes backup. Since they are identically configured, I always felt it was simply one getting powered up slightly ahead of the other, nothing more.
To the shell game.. If there is a local master (LM) and local backup (LB) on line when anything happens, that can actually extend the typical 12 minute election period if a master 'disappears' less than graceful. (I believe this is what started my situation, i.e. the 321s were being tested with MTU tweaks for jumbo packets) With this 'lost master suddenly' condition 3 election cycles of about 11-12 minutes will go by while the others wait patiently for 'their master' to return. If there was also a backup, as in my case... you can add 15 minutes because of their update process. So worst on this network could be... 51 minutes. UGH. Perhaps... this is key?
I don't think I've ever been THAT patient...having thought shorter periods were seemingly my norm because elections were over in much shorter times. (As evidenced by restoration of client browsing and/or nbstat queries). But timing as observed and timing as computed by 'theory' should ultimately yield the same result for this to work. (hmmm wait 52 mins... ugh) The Dlink DNS-321's recover master browser in minutes if I just disconnect the 868L router by pulling its RJ45 feeding my first switch. That disconnect would seemingly (theory again) constitute a non-graceful departure of a master, but my Dlink-321's don't appear to wait around the theoretical 3 election cycles after a master disappears in that manner. They have their master (and occasionally one as backup) status back in just a few minutes.
In the absence of being able to see the smb.conf settings on the 868L, just judging by its past behavior it seems empowered to grab master and hold it... perhaps it has a 'Preferred Master' setting? Ugh. That would get the 868L another 8 'points' in the election criteria and put it as the winner. And since the Dlink-321's would have participated in that election and lost, they will disqualify themselves and not try to grab it back?
I am curious now... if perhaps the 868L has a 'preferred master' set in its configuration. Will have to capture some packets and watch. Just replaced all my switches with 4 Dlink DGS-1100 Smart Switches so perhaps a capture via a mirror'd port would make for a cleaner capture.
Using Wireshark looking at past UDP 138 captures, the content in the packet info section (so far) does not seem to be but so explicit relative to an election, perhaps I have missed it. Perhaps I need to filter 137 and 139 into the mix as well to see who chats to the 868L.
Cannot break the network with live efforts going on though....
CAVEAT: Dlink products have a growing place on my network. If I just
KNEW how the 868L is configured explicitly that might simplify my effort here. Any chance of obtaining
THAT information before wading through packet captures?
Thanks again!
Gerry-
Author
Topic: DIR-868 takes master browser and breaks NetBIOS (Read 18493 times)