I'm having issues with a client using BG on an AP350 on 6.1r3b.
I have to restart BG once a day to have all of the AppleTVs consistently able to be seen, and I'm trying to find a long-term solution. The threads here haven't shown a comprehensive solution yet, and a lot of them are many months old. I don't think restarting BG once a day is the final piece to the puzzle.
After restarting BG, everything's great. Then after some time passes (I'm dependent on the client notifying me, as there's nothing in HiveManager that shows me definitively that it has failed):
-Monitor->BG shows the services being shared from the correct VLAN and IP
-"show bonjour status" shows that the BDD is still attached to all denoted VLANs
-Yet the client cannot "see" some AppleTVs in the list
VLAN300 is the shared devices VLAN, with AppleTVs and printers statically assigned. AppleTVs are using wireless, I haven't been able to get the client to test them wired-in.
How many services are being advertised? you could always bring down you advertised services by allowing vlan group [appleTVs, printers etc..] to the user vlan group. Unless you want to advertise Sally's itunes etc...
there was a bug, but you have to check the release notes to see which version it was fixed.
If the bonjour gateway didn't hear from the bonjour device for awhile it would cleanse it from it's records.
you can always try this secret command from cli on the BDG
_test bgd show 7
In general the service advertisements and discovery query messages will increment
From RFC 6762
"Therefore, when retransmitting Multicast DNS queries to implement
this kind of continuous monitoring, the interval between the first
two queries MUST be at least one second, the intervals between
successive queries MUST increase by at least a factor of two, and the
querier MUST implement Known-Answer Suppression, as described below
The Known-Answer Suppression mechanism tells
responders which answers are already known to the querier, thereby
allowing responders to avoid wasting network capacity with pointless
repeated transmission of those answers. A querier retransmits its
question because it wishes to receive answers it may have missed the
first time, not because it wants additional duplicate copies of
answers it already received. Failure to implement Known-Answer
Suppression can result in unacceptable levels of network traffic.
When the interval between queries reaches or exceeds 60 minutes, a
querier MAY cap the interval to a maximum of 60 minutes, and perform
subsequent queries at a steady-state rate of one query per hour. To
avoid accidental synchronization when, for some reason, multiple
clients begin querying at exactly the same moment (e.g., because of
some common external trigger event), a Multicast DNS querier SHOULD
also delay the first query of the series by a randomly chosen amount
in the range 20-120 ms."
I see more issues with our Cisco equipment, macbooks need to kick start the bonjour process after being connected for several hours.
Here's part of "show bonjour status" as of now, about 22 hours after I last restarted it.
Total 4 Local Attached VLANs: 154 156 200 300
Total 0 Remote BDDs:
Bonjour VLAN range: 154 156 200 300
Total Services: 75; Total Self-Services: 0; Published Times: 102
I also ran "_test bgd show 7" and now local keepalive is enabled. Not 100% clear on that mechanism but that's OK for the moment.
I'm afraid I won't have much more to update until I hear one way or the other from the client, but I'll let you know.
Thanks for the input.
I'll update this thread if we encounter anything else related.
Steve Bateman, what is the current state for local keepalives in your environment? They are now enabled? And your environment seems to be more stable than from before making this change?
Other Folks contributing to this thread (or just here to lurk & learn),
This particular command, like all "_test ..." commands, was designed for Aerohive internal use only. It SHOULD NOT be used EXCEPT under the direction of Aerohive technical support. The lack of documentation is intentional as is the delay in fixing the typo (hey, WE know what it means, and if you'll never see it then the urgency of fixing a typo goes way down).
Back before the release of HiveOS 6.1r2 we had a theory that the presence of local keepalives was contributing to the problems of "losing services" so we extended an internal-use-only command to allow control over whether to do local keepalives or not and tested that at several customer sites.
This appeared to address their problems, so in HiveOS 6.1r2 we changed the behavior of the Bonjour Gateway to disable local keepalives by default. That's one of the times I (prematurely) declared success here. Since the _test command is hidden, we did not remove it from the codebase. The command is a toggle, executing it twice leave you in the original state.
So, for folks running 6.1r2 or later on their APs, executing this command does exactly the opposite of what we thought would make things better.
I am trying to find out if there is a need for us to create a persistent command to control whether local keepalives are enabled or disabled.
Thanks for the response. Anecdotally the issue seems to be better, but there was a point yesterday where the Apple TVs disappeared, and then showed up again after a reboot of an AP that was NOT the BDD. This was completed by the client to address a backup AP RADIUS server not joining AD properly. I'm reliant on the client feeding info to me, so I'm afraid I don't have anything more quantitative than that at this point.
I've run the command once. So presumably local keepalives are now enabled.
We have a different client that runs BG and has since last October without any need to reboot it. So tracking down the triggering behavior has been a struggle because so much of both Bonjour itself and Bonjour Gateway is intended to be relatively automatic.
With the upcoming changes to Bonjour Gateway, and the upcoming changes to Airplay in iOS 8 and presumably Yosemite this might get a whole lot better... in 3-6 months..
Does anyone have any more ideas for workarounds in the interim?
The Apple TVs are wireless currently, so there may be some benefit to wiring them via Ethernet. Other than that I'm out of ideas other than restarting their BG once a day for them.
Would this issue have anything to do with the PPSK reauthorization time being set to the default of 30 minutes?
It seems like if anything, forcing the Apple TV to generally reauthenticate so aggressively might be a major driver of this behavior, especially combined with the symptom of incrementing their hostnames. This is something I missed in the original config.