General troubleshooting hints are included in the Aether OnRamp Guide, but some of the issues people report are due to the specifics of either their local environment or the hardware they are using. This page summarizes such issues and how they might be addressed.

...

Bottomline: You need to identify the least intrusive solution, which may be challenging if you end up mixing management directives between systemd.networkd and the Network Manager. The best approach is to start with Ubuntu Server in the first place.

Multiple Instantiations of Aether

As noted by the Troubleshooting hint in the QuickStart Section of the OnRamp Guide:

"Another possibility is that you have multiple SD-Cores running in the same broadcast domain. This causes ARP to behave in unexpected ways, which interferes with OnRamp’s ability to establish a route to the UPF pod." 

This is because each OnRamp-deployed instance of Aether (whether it runs in a single server, as is the case with QuickStart or is scaled across multiple servers) has a fixed pair of IP subnets allocated to the Core's UPF: 192.168.252.0/24 and 192.168.250.0/24, with the first of these associated with the server's physical NIC. Making this prefix configurable is on the Roadmap for OnRamp, but if you want to deploy multiple instances of Aether today, the easiest workaround is to manually edit those prefixes throughout OnRamp (i.e., for each instance of OnRamp you clone and plan to deploy). For example, you might change the subnets to 192.169.252.0/24 and 192.169.250.0/24 for the second instance. Be aware that these subnets are defined at multiple places throughout your cloned copy of OnRamp. (The plan is to define the per-Aether prefix just once in vars/main.yml and use templating to set all the uses.)