Forum Replies Created
-
AuthorPosts
-
Sharing the SSH and SCP commands again, due to an error in the above:
ssh -i /path/to/vm/private/key -J bastion.fabric-testbed.net [username]@[VM_IP]
scp -i /path/to/vm/private/key -o "ProxyJump bastion.fabric-testbed.net" [username]@[VM_IP]:file.txt .
scp -i /path/to/vm/private/key -o "ProxyJump bastion.fabric-testbed.net" ubuntu@[2001:400:a100:3030:f816:3eff:fe93:a1a0]:file.txt .
- This reply was modified 3 months, 1 week ago by Komal Thareja.
Hi Prateek,
The
/home/fabric/work
directory in the JupyterHub environment serves as persistent storage for code, notebooks, scripts, and other materials related to configuring and running experiments, including the addition of extra Python modules. However, it is not designed to handle large datasets.**Transfer via the Bastion Host**
All virtual machines (VMs) are connected to a management network that you use for SSH access. You may have noticed that accessing your VMs requires jumping through a bastion host for enhanced security.
The simplest method for transferring data to and from a VM is by usingscp
(or a similar tool). However, you must still route through the bastion host. To do this, you will need to configure your external machine (such as your laptop) to use the bastion host for standard SSH connections.
You can find SSH configuration details here: [Logging into FABRIC VMs](https://learn.fabric-testbed.net/knowledge-base/logging-into-fabric-vms/).
The key takeaway from that document is to create (or modify) your~/.ssh/config
file to include the bastion host configuration. A basic setup might look like this:
#### Bastion
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
ServerAliveInterval 120
Host bastion-?.fabric-testbed.net
User
ForwardAgent yes
Hostname %h
IdentityFile /path/to/bastion/private/key
IdentitiesOnly yes
Host bastion-*.fabric-testbed.net
User
IdentityFile /path/to/bastion/private/key
After configuring, you should be able to SSH with the following command:
ssh -i /path/to/vm/private/key [username]@[VM_IP]
For SCP, you can use the command:
scp -i /path/to/vm/private/key [username]@[VM_IP]:file.txt .
Keep in mind that if the VM IP address uses IPv6, colons can interfere with parsing. In this case, you need to escape the characters (escaping is necessary on macOS but not in Bash; however, using escapes works in both environments). Here’s an example:
scp -i /path/to/vm/private/key ubuntu@[2001:400:a100:3030:f816:3eff:fe93:a1a0]:file.txt .Thanks,
KomalAugust 12, 2024 at 3:13 pm in reply to: Maintenance Network AM – 08/12/2024 – 1:00 pm – 2:00 pm #7411Maintenance has been completed!
Thanks,
KomalAugust 12, 2024 at 11:08 am in reply to: Unable to (consistently) reach FABNetv4Ext addresses from outside FABRIC #7409Hi Sunjay,
We did have an dataplane outage at SALT since Friday. It has been resolved now. FabNetv4Ext service on SALT should pass traffic. Thank you for sharing your observations and helping us address this quickly.
Thanks,
KomalAugust 9, 2024 at 5:17 pm in reply to: Unable to (consistently) reach FABNetv4Ext addresses from outside FABRIC #7406Apologies, you are right that sliver is definitely
Active
I did notice dataplane issue for SALT, I will reach out to Tom and share updates.
Reservation ID: 7dafe47e-3058-4282-9d09-66fe74588e1c Slice ID: 1c057890-bc44-450f-b109-995fef665216
Resource Type: FABNetv4Ext Notices: Reservation 7dafe47e-3058-4282-9d09-66fe74588e1c (Slice qbss-tester(1c057890-bc44-450f-b109-995fef665216) Graph Id:b097687e-9cd9-45ac-89bb-d12a73c2da46 Owner:scauligi@icsi.berkeley.edu) is in state (Active,None_)
Start: 2024-08-09 19:42:09 +0000 End: 2025-02-04 20:38:01 +0000 Requested End: 2025-02-04 20:38:01 +0000
Units: 1 State: Active Pending State: None_
August 9, 2024 at 5:05 pm in reply to: Unable to (consistently) reach FABNetv4Ext addresses from outside FABRIC #7404Hi Sunjay,
Looks like the FabNetv4Ext service requested on SALT failed to provision. You should be able to see the error on the Portal or via
slice-commander
"sliver_id": "0240c714-fc7f-4f6d-a1b9-7b60a8948f1a",
"slice_id": "1c057890-bc44-450f-b109-995fef665216",
"type": "FABNetv4Ext",
"notices": "Reservation 0240c714-fc7f-4f6d-a1b9-7b60a8948f1a (Slice qbss-tester(1c057890-bc44-450f-b109-995fef665216) Graph Id:b097687e-9cd9-45ac-89bb-d12a73c2da46 Owner:scauligi@icsi.berkeley.edu) is in state (Closed,None_), err=failed lease update- all units failed priming: Exception during modify for unit: 0240c714-fc7f-4f6d-a1b9-7b60a8948f1a Playbook has failed tasks: NSO commit returned JSON-RPC error: {'type': 'rpc.method.failed', 'code': -32000, 'message': 'Method failed', 'data': {'message': 'Failed to connect to device salt-data-sw: connection refused: NEDCOM CONNECT: Connect timed out in new state'}, 'internal': 'jsonrpc_tx_commit395'} (Last lease update: all units failed priming: Exception during modify for unit: 0240c714-fc7f-4f6d-a1b9-7b60a8948f1a Playbook has failed tasks: NSO commit returned JSON-RPC error: {'type': 'rpc.method.failed', 'code': -32000, 'message': 'Method failed', 'data': {'message': 'Failed to connect to device salt-data-sw: connection refused: NEDCOM CONNECT: Connect timed out in new state'}, 'internal': 'jsonrpc_tx_commit395'})",
"start": "2024-08-06 20:31:17 +0000",
"end": "2025-02-04 20:38:01 +0000",
"requested_end": "2025-02-04 20:38:01 +0000",
"units": 1,
"state": 6,
"pending_state": 11,
"sliver": {
"Name": "netSALT",
"Type": "FABNetv4Ext",
"Labels": "{\"ipv4\": [\"23.134.232.196\", \"23.134.232.194\", \"23.134.232.195\"]}",
"ReservationInfo": "{\"error_message\": \"\", \"reservation_id\": \"0240c714-fc7f-4f6d-a1b9-7b60a8948f1a\", \"reservation_state\": \"Closed\"}",
"NodeMap": "[\"bbf6a0a7-8981-4613-b797-0960e7e8ea9d\", \"node+salt-data-sw:ip+192.168.23.3-ipv4ext-ns\"]",
"StitchNode": "false",
"UserData": "{\"fablib_data\": {\"instantiated\": \"True\", \"mode\": \"manual\", \"subnet\": {\"subnet\": \"23.134.232.192/28\", \"allocated_ips\": [\"23.134.232.193\"], \"gateway\": \"23.134.232.193\"}}}",
"Layer": "L3",
"Site": "SALT",
"Gateway": "{\"ipv4\": \"23.134.232.193\", \"ipv4_subnet\": \"23.134.232.192/28\"}",
Thanks,
Komal
Hi Sunjay,
Currently, that’s not possible. Even if you could query the allocated public IPs, you would still need to invoke the
make_ip_publicly_routable
followed bymodify
orsubmit
. Since FabNetv4Ext has a limited number of IPs available, we only enable it when explicitly requested via themodify
orsubmit
operation.Without this step, the service exists but won’t pass traffic. I hope this clarifies things! I’ll note this as a potential enhancement to allow querying the allocated IPs.
Please note this should be done only at the slice setup time.
Thanks,
Komal
- This reply was modified 3 months, 2 weeks ago by Komal Thareja.
Hi Sunjay,
I apologize for not clarifying this earlier. Please note that when using
FabNetv4Ext
, IP allocation is managed by the Control Framework, not the user. While users can request a public IP starting with the first IP from the allocated subnet, the Control Framework assigns an available FabNetv4Ext IP based on the available options. This assigned IP is what gets returned to the user and can be accessed throughnet.get_public_ips()
. Since the Control Framework updates this information, it’s recommended to retrieve the latest slice topology after the slice reaches a stable state.So for
FabNetv4Ext
, please useget_public_ips()
as opposed toget_allocated_ips()
.NOTE: The example notebook uses
get_public_ips()
after requesting Publicly Routable IP.Thanks,
Komal
Hi Sunjay,
That Modify error was a bug and a patch has been deployed for that. There is also an issue in the notebook. For FabNetv4Ext service, IP allocations can be updated by the Control Framework as the FabNetv4Ext subnet is shared across the slices on a site. Collisions are handled for FabNetv4Ext by ControlFramework instead of the Fablib.
Getting the latest slice topology and retrieving the networks would ensure you have the actual IPs allocated. This should ensure correct IPs are configured on the VMs. The following steps are missing on the example notebook. Will work to update that.
slice = fablib.get_slice(slice_name)
network1 = slice.get_network(network1_name)
network2 = slice.get_network(network2_name)
print(network1.get_public_ips())
print(network2.get_public_ips())
Please try your slice again with above suggestions and let me know if you still see the same issue.
Thanks,
Komal
Hi Sunjay,
Thank you for reporting this. The collision shouldn’t occur, I will look at this and will share updates on this soon.
Thanks,
Komal
August 6, 2024 at 10:24 am in reply to: Maintenance Jupyter Hub – 08/06/2024 – 10:00 am – 11:00 am #7374Maintenance is complete and Jupyer Hub has been updated.
Hi Prateek,
We currently do not support guaranteed Quality of Service (QoS), but we do offer best-effort QoS. You can request bandwidth by setting it on your interfaces using a command like
iface.set_bandwidth(10)
.Please note that Basic NICs are essentially Virtual Functions, and the underlying dedicated NIC is shared, so guaranteed bandwidth may not be achievable. However, you should see better performance with
ConnectX_6
orConnectX_5
NICs.Here’s an example slice request for your reference:
#Create Slice
slice = fablib.new_slice(name=slice_name)
# Network
net1 = slice.add_l2network(name=network_name, subnet=IPv4Network("192.168.1.0/24"))
# Node1
node1 = slice.add_node(name=node1_name, site=site)
iface1 = node1.add_component(model='NIC_Basic', name='nic1').get_interfaces()[0]
iface1.set_mode('auto')
iface1.set_bandwidth(10)
net1.add_interface(iface1)
# Node2
node2 = slice.add_node(name=node2_name, site=site)
iface2 = node2.add_component(model='NIC_Basic', name='nic1').get_interfaces()[0]
iface2.set_mode('auto')
iface2.set_bandwidth(10)
net1.add_interface(iface2)
#Submit Slice Request
slice.submit();
Thanks,
KomalThank you, Prateek, for sharing your slice ID and observations! If you encounter this issue again, please let us know and refrain from deleting the slice. This will greatly assist us in debugging and identifying the problem.
Unfortunately, we can’t do much with a deleted slice. We appreciate your cooperation with this!
Thanks,
KomalHi Sunjay,
Are you still facing this issue? I tried a slice on TOKY and didn’t run into any access issues.
Please let us know.
Thanks,
KomalJuly 31, 2024 at 9:23 am in reply to: Unable to (consistently) reach FABNetv4Ext addresses from outside FABRIC #7335Hi Sunjay,
I just checked all the VMs on your slice. I can ping all FabNetv4Ext IPs from my laptop. I’ll check with Network Team and share more details if we see any issues.
Thanks,
Komal -
AuthorPosts