1. yoursunny

yoursunny

Forum Replies Created

Viewing 15 posts - 31 through 45 (of 67 total)
  • Author
    Posts
  • in reply to: STAR site power loss, connectivity losses #5347
    yoursunny
    Participant

      The STAR outage seems to be affecting the creation of FABNetv4Ext networks. It seems that the control software is trying to access the STAR switch and it times out. This occurs even if the node is in WASH site where the FABNetv4Ext peering connection exists.

      Slice Exception: Slice Name: v4gateway@1695137544, Slice ID: f20f1cff-11b0-4db9-9ffb-5b265c3653b6: Slice Exception: Slice Name: v4gateway@1695137544, Slice ID: f20f1cff-11b0-4db9-9ffb-5b265c3653b6: Node: gateway, Site: PSC, State: Active,
      Slice Exception: Slice Name: v4gateway@1695137544, Slice ID: f20f1cff-11b0-4db9-9ffb-5b265c3653b6: Slice Exception: Slice Name: v4gateway@1695137544, Slice ID: f20f1cff-11b0-4db9-9ffb-5b265c3653b6: Node: gateway, Site: PSC, State: Active,

      failed lease update- all units failed priming: Exception during modify for unit: 5a8383f3-30aa-41d8-9874-46b61ebbe621 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 star-data-sw: connection refused: NEDCOM CONNECT: The kexTimeout (20000 ms) expired. in new state, internal: jsonrpc_tx_commit357#all units failed priming: Exception during modify for unit: 5a8383f3-30aa-41d8-9874-46b61ebbe621 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 star-data-sw: connection refused: NEDCOM CONNECT: The kexTimeout (20000 ms) expired. in new state, internal: jsonrpc_tx_commit357#

      The control software should choose alternate paths to reach the peering port. The control software should skip switches in maintenance, and attempt to re-apply the configuration when the maintenance mode is lifted.

      yoursunny
      Participant

        Instead of having users add hosts entry (which would require changes in every level including inside containers), can the DNS64 server be configured to return this IP?

        • This reply was modified 2 years, 8 months ago by yoursunny.
        yoursunny
        Participant

          I’m seeing “Unable to establish SSL connection” error when trying to download from GitHub releases:

          ubuntu@N0:~$ wget --timeout=10s -v https://github.com/TomWright/dasel/releases/download/v2.3.4/dasel_linux_amd64
          --2023-09-06 17:24:18-- https://github.com/TomWright/dasel/releases/download/v2.3.4/dasel_linux_amd64
          Resolving github.com (github.com)... 2600:2701:5000:5001::8c52:7104, 140.82.113.4
          Connecting to github.com (github.com)|2600:2701:5000:5001::8c52:7104|:443... connected.
          HTTP request sent, awaiting response... 302 Found
          Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/297615696/dfe35302-5ee7-42cf-939d-345b67a2091d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230906%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230906T172418Z&X-Amz-Expires=300&X-Amz-Signature=cdb822adb0af2026b86b8fae886e28358b27bb48551182c5ee95e03a946b4353&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=297615696&response-content-disposition=attachment%3B%20filename%3Ddasel_linux_amd64&response-content-type=application%2Foctet-stream [following]
          --2023-09-06 17:24:18-- https://objects.githubusercontent.com/github-production-release-asset-2e65be/297615696/dfe35302-5ee7-42cf-939d-345b67a2091d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230906%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230906T172418Z&X-Amz-Expires=300&X-Amz-Signature=cdb822adb0af2026b86b8fae886e28358b27bb48551182c5ee95e03a946b4353&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=297615696&response-content-disposition=attachment%3B%20filename%3Ddasel_linux_amd64&response-content-type=application%2Foctet-stream
          Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 2600:2701:5000:5001::b9c7:6d85, 2600:2701:5000:5001::b9c7:6e85, 2600:2701:5000:5001::b9c7:6c85, ...
          Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|2600:2701:5000:5001::b9c7:6d85|:443... connected.
          Unable to establish SSL connection.

          Is the NAT64 gateway being blocked by GitHub releases download server?

          tcpdump of the transaction: https://cdn1.frocdn.ch/JTeh94VJIxkXv6P.pcap

          • This reply was modified 2 years, 8 months ago by yoursunny.
          yoursunny
          Participant

            I found an unintended consequence of enabling NAT64:

            1. I sometimes want multiple slices to communicate with each other, while each slice can be re-deployed independently.
            2. To do so, I’m using FABNetv4 network service, paired with an external domain name that supports dynamic updates.
            3. When a “server” slice is re-deployed, it updates the domain name to point to its new FABNetv4 IP address.
            4. Previously, this works well: the “client” slice can find the “server” slice by resolving the domain name.
            5. Since NAT64 is deployed, the “client” slice would resolve both A and AAAA records on the domain name.
            6. If the “client” software tries to connect to the IPv6 address in the AAAA records, it cannot reach the FABNetv4 destination.

            My suggestion is to configure the DNS64 server so that it does not return AAAA records if the domain name resolves to an IPv4 address that is part of FABNetv4 or other RFC1918 address.

            yoursunny
            Participant

              Please post your experiment script or notebook, as well as any commands you typed into SSH console.

              Please describe what you expect to happen in a certain operation, and what actually happened.

              Please post commands, outputs, error messages in textual format, not as pictures.

              in reply to: A public IP for the Fabric node #4601
              yoursunny
              Participant

                Yes, you can request public IPv4/IPv6 address with FABNetv4Ext/FABNetv6Ext network service:

                Network Services in FABRIC

                There are some examples in my FABRIC scripts repository:

                https://github.com/yoursunny/fabric

                in reply to: Why is NDN packets not going through my network #4598
                yoursunny
                Participant

                  If you think OpenVSwitch is causing problem, do not enable it.

                  NFD alone is capable of forwarding traffic between different nodes.

                  in reply to: Why is NDN packets not going through my network #4596
                  yoursunny
                  Participant

                    You are using persistent face in NFD:

                    face-created id=264 local=dev://ens7 remote=ether://[e8:eb:d3:81:b7:fe] persistency=persistent reliability=off congestion-marking=off congestion-marking-interval=100ms default-congestion-threshold=65536B mtu=1500

                    This kind of face would auto-close upon socket error.

                    My guess is that, the face experienced a socket error and thus automatically closed. You can confirm or reject the hypothesis by looking at nfdc face list command output and checking whether the face has disappeared.

                    in reply to: Why is NDN packets not going through my network #4593
                    yoursunny
                    Participant

                      Please upload your experiment notebook.

                      If you typed commands into the SSH terminals to set up NDN software, please also describe exactly which commands were typed, and paste the output of each command.

                      in reply to: FABNetv4Ext in non-Jupyter script #4267
                      yoursunny
                      Participant

                        The infrastructure problem seems to be resolving.
                        The second error (“actual result 2”) is no longer occurring.

                        The first error (“actual result 1”) seems to be a fablib bug and it still occurs.

                        in reply to: Authentication failure while enabling public IPv4 #4210
                        yoursunny
                        Participant

                          paramiko.ssh_exception.AuthenticationException: Authentication failed.

                          This suggests that fablib cannot connect to either the bastion or the node via SSH.
                          It has nothing to do with FABNetv4Ext.

                          ssh ${Username}@${Management IP}

                          This suggests that your fabric_rc file is outdated.
                          You need to rerun the configure.ipynb notebook.

                          See also: https://learn.fabric-testbed.net/forums/topic/broken-get_ssh_command/#post-3693

                          • This reply was modified 3 years ago by yoursunny.
                          in reply to: Authentication failure while enabling public IPv4 #4195
                          yoursunny
                          Participant

                            I tried my usual script of acquiring public IPv4 address, operating on behalf of a project that has the Net.FABNetv4Ext permission.
                            https://github.com/yoursunny/fabric/tree/5d434c3117314730a9ab38ffd4eefcab70f13779/ipv4 , see v4pub.py and demo-v4pub.py.
                            It works correctly and can acquire public IPv4 addresses for nodes that need it.

                            However, I’m having trouble with FABRIC’s jupyter-examples.
                            https://github.com/fabric-testbed/jupyter-examples/blob/rel1.4.5/fabric_examples/beta_functionality/rel1.4/create_l3network_fabnet_ext.ipynb
                            (I commented out the UKY line)

                            For both networks defined in the notebook, get_subnet() returns None.
                            Consequently, “Update Network Service – Enable/Disable Public IP Addresses” failed with error:

                            TypeError: 'NoneType' object is not subscriptable
                            in reply to: IPv6 on FABRIC: A hop with a low MTU #4183
                            yoursunny
                            Participant

                              We need to do some more testing for all the links in the network to see if we can find a single value that works everywhere.

                              Use my script:

                              https://github.com/yoursunny/fabric/blob/5d434c3117314730a9ab38ffd4eefcab70f13779/util/mtu.py

                              in reply to: Enable DPDK on Fabric Nodes #4182
                              yoursunny
                              Participant

                                On nodes created some time ago using Debian OS 10 it was possible to check the active DPDK service (sudo service dpdk status). Which is currently not possible.

                                This just means that DPDK isn’t preinstalled, which arguably is a good thing as there are many compile-time options that can optimize for performance. You can install it yourself from DPDK source code.

                                in reply to: Authentication failure while enabling public IPv4 #4181
                                yoursunny
                                Participant

                                  FABNetv4Ext network service requires Net.FABNetv4Ext permission.

                                  If your project doesn’t have this permission, you’ll need to request it via ticket.

                                Viewing 15 posts - 31 through 45 (of 67 total)