Forum Replies Created
-
Posts
-
Is this slice still active? If so, could you please let us know which rack it is on ?. Also it would be good if you can also send us your MFlib log file which should be in /tmp/mflib/* on your jupyterhub session.
This is just a guess, but in your commands to delete IPs, you are deleting the IP/interface that you SSH into thus killing your SSH connection to the VM.
Hello,
TACC being our of IP is out of our hands for now due to the limited IPv4 space available. Hopefully, by Fall, the rack will be converted to using IPv6 which would resolve this issue.
BRIST had a data plane outage today (07:00 BST and 09:00 BST Tuesday 4th June 2024.). Apart from these, we are unaware of any other issues. We will need more details about the nature of the error to investigate further.
Hello vaiden,
Firstly you no longer need to run any script for NAT64. FABRIC DNS servers provided to your VMS now can do NAT64. With that said, the other is misunderstanding of how NAT64 service works. Most of the time when they say NAT64, it is meant to work in conjunction with DNS64.
When a hostname (with an IPv4-only address) is resolved for an IP at the DNS servers and the DNS server does a DNS64, it will create a fake IPV6 address for that host which will be sent to your application. Your application then uses that fake IPv6 address which is an IP that is managed by the NAT64/DNS64 server. The server will then route your traffic by converting from IPv6 to ipv4 and then back in reverse.
In your case, you are directly trying the IPv4 address which will not work. If you don’t have a hostname that was resolved to that IPv4 address, there is a complex workaround for this issue. You must create your own fake IPv6 address using the NAT64 server’s IPv6 prefix. If this is really needed, I can provide more details on how to do it.
This is a reminder to all FABRIC Users that the FABRIC MASS Rack will be shut down tomorrow by 11:00am Eastern. We have noticed many users still have slices on the rack. If they are set to expire within the downtime timeframe, those nodes may not be recoverable after the maintenance ends. Please plan your work accordingly.
Your VMs should be working again. The physical workers had crashed. We just recovered them and restarted all the VMs on those nodes.
The physical node has crashed again. I am working on restoring it now. Please restore your data plane IPs in about 2 hrs and check and let me know.
Can you check now. The VM had crashed. We restored it, but it may be missing its IP config on the data plane NICS that you may have to restore.
Can you please provide us some details about your slice and VM ? WHat is the IP of the node you are trying to ssh into ?
Just to follow up, this issue may take a while to resolve as it involves working with upstream campus network providers too.
Thank you for reporting this. It seems this may be a campus issue. We have notified the local campus to investigate and report back to us. We will inform you when its resolved.
