- This topic has 6 replies, 2 voices, and was last updated 1 year, 4 months ago by
.
-
Posts
-
Good morning – I am trying to develop a sort of canned approach to connectivity but VMs. I am used to hypervisor port groups, vswitches, etc. and so am trying to understand what it means when VMs are on the same site or aggregate. I read through the interface types (thanks Ilya) but and getting a mixed bag of results. Here are some issues I’m working through:
Initial testing with the Ubuntu, Fedora and CentOS VMs shows that installs via apt, yum or rpm do not always work because outside connectivity appears to be down. This seems especially true with CentOS.
Connectivity between VMs also does not work even when a shared NIC has been given an IP address and the interface is brought up. I suspect that I am still a little confused as to inter-VM connectivity.
However, what does appear to work is two Ubuntu VMs are connected via an L2B, given IP addresses and interfaces have been brought up. With this topology, installs, pings and tcpdump all work. Commands and the topology are below.
sudo ip addr add 192.168.1.1/24 dev ens7
sudo ifconfig ens7 up
sudo apt-get install net-tools
sudo tcpdump -i ens7
Follow up – trying to set up a three node topology using the most recent versions of the VM OS (Fedora 37, Ubuntu 22, CentOS Stream 9) on the WASH site. Received the following error:
N2-F37
failed lease update- all units failed priming: Exception during create for unit: 5ea92378-e95f-4455-a54c-4bf684586fbf NoneType object has no attribute get#all units failed priming: Exception during create for unit: 5ea92378-e95f-4455-a54c-4bf684586fbf NoneType object has no attribute get#L2B
TicketReviewPolicy: Closing reservation due to failure in slice#Tried the same thing but on PSC and just Ubuntu. Error code:
L2B
failed lease update- all units failed priming: Exception during create for unit: b08aa09c-1f23-4b98-8fa5-ee4542ed493d Playbook has failed tasks: NSO commit returned JSON-RPC error: type: rpc.method.failed, code: -32000, message: Method failed, data: message: Network Element Driver: device psc-data-sw: out of sync, internal: jsonrpc_tx_commit357#all units failed priming: Exception during create for unit: b08aa09c-1f23-4b98-8fa5-ee4542ed493d Playbook has failed tasks: NSO commit returned JSON-RPC error: type: rpc.method.failed, code: -32000, message: Method failed, data: message: Network Element Driver: device psc-data-sw: out of sync, internal: jsonrpc_tx_commit357#By far the easiest way to connect VMs between each other is to use FABNetv4 (or FABNetv6) services. These will not allow the VMs to see the outside world through those interfaces, but they will ‘just work’ regardless of which sites you are on. You really do not need to rely on L2 services as much as you did in GENI, as FABRIC L3 services require far less configuration.
You are showing the screenshot from the portal, but I am assuming you are using the notebooks to build your slices – working from the portal requires a lot of manual steps to get things running.
The connectivity to outside world problem you are referring to is most likely due to the fact that you are ending up on sites that have IPv6 management network connectivity – in this case many sites (like yum/deb repos, GitHub) are not reachable directly, in which case you need to modify your DNS to allow the use of NAT64 (there is a notebook about it and also this article discusses it).
Whelp, I’m going to disappoint you as I am using the portal for everything except SSH connectivity. I’ll work on switching to notebooks for configuration.
Your comment on IPv6 management makes total sense and seems consistent with all of the experiences I’ve had so far but perhaps getting IPv6 as the default should be examined as it might add to the configuration requirements.
PSC – ahh, OK
and I’ll play with the FABNetv4 services. Though I must say, L2Bridge makes more sense to my brain. For right now I will push the “I believe” button on FABNetv4 but I would love to chat about how this works under the hood some time.
We do not recommend using the portal for anything, but the simplest experiments and also for visualizing the topologies. The portal does not support the full workflow of the experiment – it only creates topologies, leaving everything else (i.e. experiment configuration) a manual step.
Regarding IPv6 – this was not a choice for us – the amount of available IPv4 space is extremely limited at the hosting locations. At many of them IPv6 was the only option. Our systems deal with this transparently, however communicating to the outside world can be sometimes problematic, because despite the fact it is 2023, GitHub still doesn’t have IPv6 presence. Most other larger sites/services do and as we go forward we expect to have fewer problems with this issue.
- You must be logged in to reply to this topic.