-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPT_LINKS incomplete node list #469
Comments
This is an interesting one. Let me confirm I understand what you've said here:
I looks like we generate the allstarlink data here: Line 3297 in e4dee90
And this apparently is generating the correct list of nodes. We then generate the Asterisk vars here: app_rpt/apps/app_rpt/rpt_link.c Line 524 in e4dee90
Generating the "same list" in a completely different way. I suspect Asterisk has a limit on the internal variable size which is truncating these values, but I've chased that a bit and don't see the limit. It appears you have |
Yes, and
To validate that it is a general issue, this is what I get when connecting to a completely different network - isolated from the network I am working with:
app_rpt is reporting ~70 nodes connected (at least 130 according to my hub node-counting script), and The back story to this is that I'd like to monitor which nodes are connected and raise an alert if certain nodes disconnect, so a precise understanding of who is connected is important. This is achievable by hammering the allstarlink.org API but I'd rather not do that :) |
Doesn't your node counting script aggregate the links from multiple nodes? Wouldn't you need to do the same if you are counting the info from RPT_LINKS? or are you thinking that RPT_LINKS includes the full tree? But, the truncated list is something that needs to be investigated. |
It does count links across multiple nodes, however they are all connected. I was thinking that
I can see a couple of interpretations here - through a node that is connected directly could imply that the node is adjacent to the directly connected node, or adjacent to an adjacent to an adjacent, etc. So are we saying that |
Is my first statement correct? stats.allstarlink.org has the correct node list. |
Also, can you share what is in the RPT_ALINKS and RPT_NUMALINKS registers along side the others. Trying to pin point where things maybe going wrong. |
And while we're asking for info, can you share your pystrix script that subscribes to the RPT_LINKS events. |
Sure, it is correct. I was hoping to find a way of observing the network state without hammering the stats API (rate limited) and to be able to capture links through nodes that aren't reporting. If that isn't possible with
Here is an example connected to one network:
And connected to another network for comparison:
The script is wrapped up with a bunch of other stuff, below is a minimal example that pulls out the LINKS and ALINKS events. To be clear, the info I posted above was extracted to directly from a local ASL node with
|
I’m working with a network which has around 90-100 nodes connected at any one time. I want to monitor which nodes are connected and have written a script to subscribe to the
RPT_LINKS
event (Python, via the excellent pystrix package).If I query the Allstarlink API and count the number of links connected to each of our hub nodes, I get:
However, the payload I receieve in the
RPT_LINKS
event has significantly fewer:I counted them, there are indeed 69, which corresponds with
RPT_NUMLINKS
. Also node the truncatedT5
at the end. To validate that it isn’t my script, I see the same list when I runrpt showvars NNNNNN
. The hub nodes are all connected according to our dashboards, at most 2 hops away from each other.The topology is
2167 - 2196 - 63061
In this case I am connected direct to 2167, but cannot see that 63061 or any of its adjacent nodes. If I connect direct to 63061 I will not see 2167 or any of its adjacent nodes. They are both connected to 2196. Both can see 2196 an its adjacent nodes in the list.
RPT_LINKS
seems to be emitted when there is activity, the network itself is quite busy with the usual flurry of kerchunks between QSOs, I have also tried poking the hub nodes to solicitRPT_LINKS
events between nodes, but the most I can see is around 70.Is there any limit to the number of nodes that will be emitted with
RPT_LINKS
? Is there some configuration that would prevent an intermediate node from sending node details from one side to another (looking at 2196)?Version information
I've observed this behavior on an ASL3 node:
Full asl-show-version 3.1.0 output
Also seeing it after upgrading to 3.2.0:
Full asl-show-version 3.2.0 output
Also seeing the same thing on an older node running
ASL Version 2.0.0-beta.6
.The text was updated successfully, but these errors were encountered: