Forum Replies Created
-
Posts
-
VM management networks of the FABRIC nodes (used for ssh’ing into the VMs and for external connectivity to the public internet) are either IPv4 or IPv6. I’m not sure how/if this information can be found out, so I’m just adding below a list.
- Sites with IPv4 management network: TACC (will be changed to IPv6 in July), UCSD, FIU, SRI, BRIST, TOKY
- Sites with IPv6 management network: STAR, MAX, MICH, MASS, UTAH, NCSA, WASH, DALL, SALT, GPN, CLEM, GATECH, LOSA, NEWY, KANS, ATLA, SEAT, PRIN, INDI, PSC, RUTG, CERN, AMST, HAWI, EDUKY
I’m not sure specifically what errors you were getting, I will outline some info from my test slice.
On my trial (on an IPv6-based FABRIC node (PSC)), one mirror (mirrors.jevincanders.net) was causing download problems (their IPv6 address seemed not working). There may be some workarounds with pointing the IPv4 address of the mirror site to a NAT64 address in /etc/hosts. In order to overcome this problem, using an IPv4-based FABRIC node (eg. FIU) can be convenient. I could not find out if Debian 10 or Debian 11 should have been used for this conversion, I tried with Debian 11 on FABRIC-FIU and it worked fine with some issues. (I used kali-linux-default instead of kali-linux-everything, there was a conflict about a package that I did not have time to check further)
┏━(Message from Kali developers) ┃ ┃ This is a cloud installation of Kali Linux. Learn more about ┃ the specificities of the various cloud images: ┃ ⇒ https://www.kali.org/docs/troubleshooting/common-cloud-setup/ ┃ ┗━(Run: “touch ~/.hushlogin” to hide this message) debian@Node2:~$ cat /etc/os-release PRETTY_NAME="Kali GNU/Linux Rolling" NAME="Kali GNU/Linux" VERSION_ID="2024.2" VERSION="2024.2" VERSION_CODENAME=kali-rolling ID=kali ID_LIKE=debian HOME_URL="https://www.kali.org/" SUPPORT_URL="https://forums.kali.org/" BUG_REPORT_URL="https://bugs.kali.org/" ANSI_COLOR="1;31"
1 user thanked author for this post.
Some specific details may be useful to continue the discussion on this.
Having the 2 examples (working case and non-working case) in place and sharing the slice IDs with us can be convenient.
We will check, try how this works and get back on this.
In the mean time, it can be helpful to know on which sites you tried (and/or some details about the errors if you still have available).
Also, due to ongoing work for the general maintenance that we are preparing for as well as summer schedules, turn around may be slower than usual.
FABRIC-PSC is back online.
All VMs are recovered, they are online for ssh access and their PCI devices are re-attached. IP configuration of the dataplane interfaces should be checked and re-configured by experimenters. Please let us know if you have any issues.
This problem is resolved. on June 14th and newy-w2 has been online, with stopped VM slivers on it activated and dataplane interfaces recovered.
Dear Experimenters,
The issue is resolved and we are releasing the maintenance. FABRIC testbed is available for slices.
However, we will be following the status of the testbed in the next few hours to make sure if the problem is caused by a transient issue or a bug. This thread will remain open throughout the weekend and we will post a final confirmation.
Hello Nirmala,
We have been working on the problem that is causing instability and the end result you describe. Changes are partially deployed and we are expecting the problem is resolved. There will be one more maintenance to complete the deployment of the changes this week (tentatively on Thursday).
Maintenance on FABRIC-AMST is completed.
https://learn.fabric-testbed.net/forums/topic/maintenance-on-fabric-amst-between-april-28-may-1/#post-6958
