Route Table entries appear and disappear all together as a group randomly

When I look at my Route Table using HubIPaddress/hub/zigbee/getChildAndRouteInfo
At times my Route table is full, then if I refresh the page it sometimes is empty. Is it normal for 12 to 13 devices to all drop off the route table at the same time?

Thank you for any insights. I have C8 hub and am running .135

This phenomenon started when the format of the 'Child data' section got fixed in a recent firmware level to display proper device ID's and end device role types.

Actually more than just the display of the child section got changed; the 'Parent child parameters' line is no longer displayed. On older firmware, the first line of the getChildandRouteInfo page would display something like:

Parent child parameters
EzspGetParentChildParametersResponse [childCount=2, parentEui64=0000000000000000, parentNodeId=65535]

With the new Zigbee stack, the parent child parameters response acquired a additional 'node' parameter; this coincided with the issues displaying child device ID's and role types. With the 'fix' to
the format of the getChildandRouteInfo page to properly display child device ID's, this parameter line disappeared completely along with the more 'stable' view of the Route Table entries.

My speculation is that nothing really changed internally with regards to Route Table entry content or routing algorithims; newer firmware seems to have a quirk in how data from the 'getChildandRouteInfo' api call is being fetched, reformatted (to correct the previous issues) and displayed such that from time to time it's not capturing the Route Table entries.

This doesn't seem to have affected routing; just the probability of viewing an 'active' Zigbee route is much lower now (kind of a bummer since it helps with understanding which neighbors are actually being used for routing).

In any case, Zigbee route table entries aren't static so viewing any given route table entry has always been a hit or miss affair; unlike Z-Wave which retains static routes (and tries different ones only after multiple message delivery failures/retries), if a Zigbee route hasn't been used in more than 64 seconds, even if the mesh topology hasn't changed, it gets purged completely and new route discovery broadcast proactively gets initiated anyway.