ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

View Only

last person joined: 2 days ago

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution

Back to discussions

Expand all | Collapse all

ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

This thread has been viewed 13 times

1. ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

Kudos

MVP GURU

parnassus

Posted Nov 20, 2020 08:09 AM

Aruba 8320 recently upgraded to 10.05.0021 from 10.03.0090.

Error on copy running configuration to TFTP Server when using FQDN: curl: (45) bind failed with errno 99: Cannot assign requested address.

NO error if the copy to TFTP Server is executed using the IP address.

Before the update both methods (FQDN and IP) worked.

The same command executed pre/post upgrade:

Pre (10.03.0090):

vsx-1# copy running-configuration tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.03.0090-pre-upgrade cli vrf mgmt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19614    0     0  100 19614      0  6302k --:--:-- --:--:-- --:--:-- 6302k
100 19614    0     0  100 19614      0  5952k --:--:-- --:--:-- --:--:-- 5952k
Copying configuration: [Success]

Post (10.05.0021):

vsx-1(config)# copy running-config tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade cli vrf mgmt
curl: (45) bind failed with errno 99: Cannot assign requested address
Copying configuration: [Failure]
error uploading running-config

vsx-1(config)# copy running-config tftp://10.255.0.250/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade cli vrf mgmt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19189    0     0  100 19189      0   500k --:--:-- --:--:-- --:--:--  500k
100 19189    0     0  100 19189      0   495k --:--:-- --:--:-- --:--:--  495k
Copying configuration: [Success]

Note: OoBM interface should run a 1Gbps. Our TFTP server is connected with 4x1Gbps LACP.

Difference in upload speeds are due to the fact that on the case of copy to TFTP performed on ArubaOS-CX 10.05.0021 our NAS was heavily used so the free bandwidth was somewhat limited.

Nevertheless the upload happened successfully in both cases (on 10.03.0090 by using our nas01's FQDN and on 10.05.0021 only by using our nas01's IP).

Our internal NS(s) were always reachable since, in both cases (pre/post-upgrade) simple ping using both IP or FQDN worked:

Pre (10.03.0090):

vsx-1# ping 10.255.0.250 vrf mgmt
PING 10.255.0.250 (10.255.0.250) 100(128) bytes of data.
108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=0.105 ms
108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=0.112 ms
108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=0.119 ms
108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.105 ms
108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.118 ms

--- 10.255.0.250 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4087ms
rtt min/avg/max/mdev = 0.105/0.111/0.119/0.014 ms

vsx-1# ping 10.255.0.250 vrf mgmt
PING nas01.datafarm.local (10.255.0.250) 100(128) bytes of data.
108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=0.101 ms
108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=0.104 ms
108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=0.129 ms
108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.125 ms
108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.117 ms

--- nas01.datafarm.local ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4093ms
rtt min/avg/max/mdev = 0.101/0.115/0.129/0.013 ms

to prove that name resolution worked pre-upgrade and, see below, also post-upgrade.

Post (10.05.0021):

vsx-1# ping 10.255.0.250 vrf mgmt
PING 10.255.0.250 (10.255.0.250) 100(128) bytes of data.
108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=4.16 ms
108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=2.82 ms
108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=1.65 ms
108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=1.14 ms
108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.392 ms

--- 10.255.0.250 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.392/2.035/4.160/1.325 ms

vsx-1# ping nas01.datafarm.local vrf mgmt
PING nas01.datafarm.local (10.255.0.250) 100(128) bytes of data.
108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=2.56 ms
108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=4.19 ms
108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=2.12 ms
108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.412 ms
108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=1.45 ms

--- nas01.datafarm.local ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4056ms
rtt min/avg/max/mdev = 0.412/2.151/4.199/1.255 ms

Note that the average RTT measured when our VSX was on 10.05.0021 with respect to the average RTT of the same ping made when the VSX was on 10.03.0090 was higher due to the NAS01 usage at that time.

I retried few times and the the ping's RTT lowered on 10.05.0021 (being basically equal to RTT seen before the upgrade...notice that the upgrade happened hours before copy test to TFTP once in 10.05.0021) but the issue about copy to TFTP by using FQDN persisted.

Cleary our TFTP service running on our NAS01 didn't changed in between.

Reversed output of show events (related to copy attempts to TFTP Server):

2020-11-20T12:46:28.213335+01:00 vsx-1 hpe-config[6141]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://10.255.0.250/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt
2020-11-20T12:45:58.678713+01:00 vsx-1 hpe-config[6057]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer
2020-11-20T12:45:58.451339+01:00 vsx-1 hpe-config[6057]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt
2020-11-20T12:44:14.551064+01:00 vsx-1 hpe-config[5785]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer
2020-11-20T12:44:14.319726+01:00 vsx-1 hpe-config[5785]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt
2020-11-20T12:43:38.746978+01:00 vsx-1 hpe-config[5677]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer
2020-11-20T12:43:38.522513+01:00 vsx-1 hpe-config[5677]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt

The same happens on the other Aruba 8320 (VSX Secondary node, vsx-2).

OoBM interfaces were/are clearly connected at 1000FDx to our LAN infrastructure.

Side Note: the copy support-files all tftp://nas01.datafarm.local/support-file.tar.gz vrf mgmt command, as example, works flawlessly even with FQDN, as expected!

------------------------------
Davide Poletto
------------------------------

2. RE: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

Kudos

EMPLOYEE

vincent.giles

Posted Nov 20, 2020 02:02 PM

I would recommend to open a case to support.

------------------------------
Vincent Giles
------------------------------

Original Message

Original Message:
Sent: Nov 20, 2020 08:08 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

Aruba 8320 recently upgraded to 10.05.0021 from 10.03.0090.

Error on copy running configuration to TFTP Server when using FQDN: curl: (45) bind failed with errno 99: Cannot assign requested address.

NO error if the copy to TFTP Server is executed using the IP address.

Before the update both methods (FQDN and IP) worked.

The same command executed pre/post upgrade:

Pre (10.03.0090):

vsx-1# copy running-configuration tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.03.0090-pre-upgrade cli vrf mgmt  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed100 19614    0     0  100 19614      0  6302k --:--:-- --:--:-- --:--:-- 6302k100 19614    0     0  100 19614      0  5952k --:--:-- --:--:-- --:--:-- 5952kCopying configuration: [Success]

Post (10.05.0021):

vsx-1(config)# copy running-config tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade cli vrf mgmtcurl: (45) bind failed with errno 99: Cannot assign requested addressCopying configuration: [Failure]error uploading running-configvsx-1(config)# copy running-config tftp://10.255.0.250/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade cli vrf mgmt  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed100 19189    0     0  100 19189      0   500k --:--:-- --:--:-- --:--:--  500k100 19189    0     0  100 19189      0   495k --:--:-- --:--:-- --:--:--  495kCopying configuration: [Success]

Note: OoBM interface should run a 1Gbps. Our TFTP server is connected with 4x1Gbps LACP.

Difference in upload speeds are due to the fact that on the case of copy to TFTP performed on ArubaOS-CX 10.05.0021 our NAS was heavily used so the free bandwidth was somewhat limited.

Nevertheless the upload happened successfully in both cases (on 10.03.0090 by using our nas01's FQDN and on 10.05.0021 only by using our nas01's IP).

Our internal NS(s) were always reachable since, in both cases (pre/post-upgrade) simple ping using both IP or FQDN worked:

Pre (10.03.0090):

vsx-1# ping 10.255.0.250 vrf mgmtPING 10.255.0.250 (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=0.105 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=0.112 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=0.119 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.105 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.118 ms--- 10.255.0.250 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4087msrtt min/avg/max/mdev = 0.105/0.111/0.119/0.014 msvsx-1# ping 10.255.0.250 vrf mgmtPING nas01.datafarm.local (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=0.101 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=0.104 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=0.129 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.125 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.117 ms--- nas01.datafarm.local ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4093msrtt min/avg/max/mdev = 0.101/0.115/0.129/0.013 ms

to prove that name resolution worked pre-upgrade and, see below, also post-upgrade.

Post (10.05.0021):

vsx-1# ping 10.255.0.250 vrf mgmtPING 10.255.0.250 (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=4.16 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=2.82 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=1.65 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=1.14 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.392 ms--- 10.255.0.250 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4003msrtt min/avg/max/mdev = 0.392/2.035/4.160/1.325 msvsx-1# ping nas01.datafarm.local vrf mgmtPING nas01.datafarm.local (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=2.56 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=4.19 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=2.12 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.412 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=1.45 ms--- nas01.datafarm.local ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4056msrtt min/avg/max/mdev = 0.412/2.151/4.199/1.255 ms

Note that the average RTT measured when our VSX was on 10.05.0021 with respect to the average RTT of the same ping made when the VSX was on 10.03.0090 was higher due to the NAS01 usage at that time.

I retried few times and the the ping's RTT lowered on 10.05.0021 (being basically equal to RTT seen before the upgrade...notice that the upgrade happened hours before copy test to TFTP once in 10.05.0021) but the issue about copy to TFTP by using FQDN persisted.

Cleary our TFTP service running on our NAS01 didn't changed in between.

Reversed output of show events (related to copy attempts to TFTP Server):

2020-11-20T12:46:28.213335+01:00 vsx-1 hpe-config[6141]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://10.255.0.250/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt2020-11-20T12:45:58.678713+01:00 vsx-1 hpe-config[6057]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer2020-11-20T12:45:58.451339+01:00 vsx-1 hpe-config[6057]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt2020-11-20T12:44:14.551064+01:00 vsx-1 hpe-config[5785]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer2020-11-20T12:44:14.319726+01:00 vsx-1 hpe-config[5785]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt2020-11-20T12:43:38.746978+01:00 vsx-1 hpe-config[5677]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer2020-11-20T12:43:38.522513+01:00 vsx-1 hpe-config[5677]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt

The same happens on the other Aruba 8320 (VSX Secondary node, vsx-2).

OoBM interfaces were/are clearly connected at 1000FDx to our LAN infrastructure.

Side Note: the copy support-files all tftp://nas01.datafarm.local/support-file.tar.gz vrf mgmt command, as example, works flawlessly even with FQDN, as expected!

------------------------------
Davide Poletto
------------------------------

3. RE: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

Kudos

MVP GURU

parnassus

Posted Nov 20, 2020 07:26 PM

Thanks Vincent, support case opened (Case 5351719813).

------------------------------
Davide Poletto
------------------------------

Original Message

Original Message:
Sent: Nov 20, 2020 02:01 PM
From: Vincent Giles
Subject: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

I would recommend to open a case to support.

------------------------------
Vincent Giles

Original Message:
Sent: Nov 20, 2020 08:08 AM
From: Davide Poletto
Subject: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

Aruba 8320 recently upgraded to 10.05.0021 from 10.03.0090.

Error on copy running configuration to TFTP Server when using FQDN: curl: (45) bind failed with errno 99: Cannot assign requested address.

NO error if the copy to TFTP Server is executed using the IP address.

Before the update both methods (FQDN and IP) worked.

The same command executed pre/post upgrade:

Pre (10.03.0090):

vsx-1# copy running-configuration tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.03.0090-pre-upgrade cli vrf mgmt  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed100 19614    0     0  100 19614      0  6302k --:--:-- --:--:-- --:--:-- 6302k100 19614    0     0  100 19614      0  5952k --:--:-- --:--:-- --:--:-- 5952kCopying configuration: [Success]

Post (10.05.0021):

vsx-1(config)# copy running-config tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade cli vrf mgmtcurl: (45) bind failed with errno 99: Cannot assign requested addressCopying configuration: [Failure]error uploading running-configvsx-1(config)# copy running-config tftp://10.255.0.250/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade cli vrf mgmt  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed100 19189    0     0  100 19189      0   500k --:--:-- --:--:-- --:--:--  500k100 19189    0     0  100 19189      0   495k --:--:-- --:--:-- --:--:--  495kCopying configuration: [Success]

Note: OoBM interface should run a 1Gbps. Our TFTP server is connected with 4x1Gbps LACP.

Difference in upload speeds are due to the fact that on the case of copy to TFTP performed on ArubaOS-CX 10.05.0021 our NAS was heavily used so the free bandwidth was somewhat limited.

Nevertheless the upload happened successfully in both cases (on 10.03.0090 by using our nas01's FQDN and on 10.05.0021 only by using our nas01's IP).

Our internal NS(s) were always reachable since, in both cases (pre/post-upgrade) simple ping using both IP or FQDN worked:

Pre (10.03.0090):

vsx-1# ping 10.255.0.250 vrf mgmtPING 10.255.0.250 (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=0.105 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=0.112 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=0.119 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.105 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.118 ms--- 10.255.0.250 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4087msrtt min/avg/max/mdev = 0.105/0.111/0.119/0.014 msvsx-1# ping 10.255.0.250 vrf mgmtPING nas01.datafarm.local (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=0.101 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=0.104 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=0.129 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.125 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.117 ms--- nas01.datafarm.local ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4093msrtt min/avg/max/mdev = 0.101/0.115/0.129/0.013 ms

to prove that name resolution worked pre-upgrade and, see below, also post-upgrade.

Post (10.05.0021):

vsx-1# ping 10.255.0.250 vrf mgmtPING 10.255.0.250 (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=4.16 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=2.82 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=1.65 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=1.14 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=0.392 ms--- 10.255.0.250 ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4003msrtt min/avg/max/mdev = 0.392/2.035/4.160/1.325 msvsx-1# ping nas01.datafarm.local vrf mgmtPING nas01.datafarm.local (10.255.0.250) 100(128) bytes of data.108 bytes from 10.255.0.250: icmp_seq=1 ttl=63 time=2.56 ms108 bytes from 10.255.0.250: icmp_seq=2 ttl=63 time=4.19 ms108 bytes from 10.255.0.250: icmp_seq=3 ttl=63 time=2.12 ms108 bytes from 10.255.0.250: icmp_seq=4 ttl=63 time=0.412 ms108 bytes from 10.255.0.250: icmp_seq=5 ttl=63 time=1.45 ms--- nas01.datafarm.local ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 4056msrtt min/avg/max/mdev = 0.412/2.151/4.199/1.255 ms

Note that the average RTT measured when our VSX was on 10.05.0021 with respect to the average RTT of the same ping made when the VSX was on 10.03.0090 was higher due to the NAS01 usage at that time.

I retried few times and the the ping's RTT lowered on 10.05.0021 (being basically equal to RTT seen before the upgrade...notice that the upgrade happened hours before copy test to TFTP once in 10.05.0021) but the issue about copy to TFTP by using FQDN persisted.

Cleary our TFTP service running on our NAS01 didn't changed in between.

Reversed output of show events (related to copy attempts to TFTP Server):

2020-11-20T12:46:28.213335+01:00 vsx-1 hpe-config[6141]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://10.255.0.250/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt2020-11-20T12:45:58.678713+01:00 vsx-1 hpe-config[6057]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer2020-11-20T12:45:58.451339+01:00 vsx-1 hpe-config[6057]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt2020-11-20T12:44:14.551064+01:00 vsx-1 hpe-config[5785]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer2020-11-20T12:44:14.319726+01:00 vsx-1 hpe-config[5785]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt2020-11-20T12:43:38.746978+01:00 vsx-1 hpe-config[5677]: Event|6802|LOG_ERR|AMM|-|Error while copying configs. Error: error in remote file transfer2020-11-20T12:43:38.522513+01:00 vsx-1 hpe-config[5677]: Event|6801|LOG_INFO|AMM|-|Copying configs from: running-config to: URL: tftp://nas01.datafarm.local/aruba-8320-vsx-1-running-config-cli-10.05.0021-post-upgrade, in format: cli, using vrf: mgmt

The same happens on the other Aruba 8320 (VSX Secondary node, vsx-2).

OoBM interfaces were/are clearly connected at 1000FDx to our LAN infrastructure.

Side Note: the copy support-files all tftp://nas01.datafarm.local/support-file.tar.gz vrf mgmt command, as example, works flawlessly even with FQDN, as expected!

------------------------------
Davide Poletto
------------------------------

Wired Intelligent Edge

ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

1. ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

2. RE: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.

3. RE: ArubaOS-CX 10.05.0021: strange "Cannot assign requested address" when trying to copy running config via TFTP using an FQDN.