-
Notifications
You must be signed in to change notification settings - Fork 167
tutorial: topology source host missing causes scion-router@br.service to crash #4619
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Reviewed 6 of 6 files at r1, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @thomasgruebl)
This is a it odd that two core ASes alone cannot talk. I see no reason for it. Does it start working as soon as you bring one or more of the others? |
Hi, thanks for your response! Yes it's odd indeed. I have now configured scion03 as well (so all three core ASes are up and running). In Wireshark, I can even see path propagation packets being sent (and received) between all 3 ASes via UDP ports 50012, 50013, 50023, however, scion ping, showpaths and traceroute are still not working and outputting:
I was wondering if you'd be available for a quick remote discussion sometime - then I could show you the setup? Thanks, Thomas |
Hi @jiceatscion , I've now installed the SCION protocol dissector for Wireshark and I'm seeing the following messages being exchanged between the two ASes. This is a request from scion01 -> scion02: This is a response from scion02 -> scion01 Can you infer something from the BFD control messages? Thanks! Thomas |
Not sure if we can learn much from the BFD messages. Those don't call for a response; they're just mutual keep-alive packets. If they weren't there, then we would have a hint of why paths aren't available. Recently we found that Go v1.23 was including a ~bug in timers behavior that was breaking the control service RPCs. If you're building the last release, you shouldn't be affected. But if you're building from head, then make sure you've pulled past the fix that downgrades Go to 1.22.7 |
Hi @jiceatscion , Thanks for your reply! Unfortunately, that's not the case because I'm building the last release v0.11.0. |
Hi,
I've tried to setup the freestanding SCION network as per the tutorial and ran into a few issues:
Using the default topology files from the website, the scion-router service always crashes because of an invalid source IP (see screenshot below):
@tobiasmoldan realized that this can be resolved by adding the source IP (or host name) to the local field in the topology:
"underlay": { "local": "scion01:50012", "remote": "scion02:50012" },
Secondly, I was wondering if all ASes need to be up and running for the network to be fully functional? I have set up and configured scion01 and scion02 as per the tutorial. All services (daemon, router, control, dispatcher) are active and there is a direct link between the two VMs. The machines are pingable (via normal ICMP), however, there is no reachability via SCMP. I assume that, even without scion03-05, they should have connectivity?
I got scion addresses for scion01 and scion02 respectively,
42-ffaa:1:1,127.0.0.1
42-ffaa:1:2,127.0.0.1
and I have generated the certificate material on scion01 and shared it with scion02. Is there anything I'm missing - e.g., does path exploration need to be triggered somehow or should it happen automatically?
Thanks a lot for your help on this!
Best regards,
Thomas