Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral


Questions and Answers

Loading... Loading...

I am running BNA for configuration backup. BNA logs in, TFTPs the files back, and saves them. If we needed to restore the LTM, I can have the LTM pull the config file back down. We have this working with the 3900 platform just fine. We have recently switched to the 4200v and now can not get the TFTP to work. We have the same config as far as the port lockdown. We are working with Support but I was wondering if anyone had some thoughts while waiting to get the answer.

Thanks


11 Answer(s):

Are there are specific error messages or more details you can share? Is there a difference in the TMOS versions being used on each platform?

BTW, TFTP is somewhat insecure, does BNA support SCP or SFTP at all?

Since I don't have access to the BNA tftp logs, I launched tftpd on my laptop and tried the connection and here are the logs.

Here is the what I see from the LTM side with verbose and trace enabled.
[root@LB-JP-SRV1-1:Active:In Sync] config # tftp 10.98.11.135
tftp> verbose
Verbose mode on.
tftp> trace
Packet tracing on.
tftp> put /var/local/scf/agent-160249.tmp agent-160249.tmp
putting /var/local/scf/agent-160249.tmp to 10.98.11.135:agent-160249.tmp [netascii]
sent WRQ <file=agent-160249.tmp, mode=netascii>
sent WRQ <file=agent-160249.tmp, mode=netascii>
sent WRQ <file=agent-160249.tmp, mode=netascii>
sent WRQ <file=agent-160249.tmp, mode=netascii>
sent WRQ <file=agent-160249.tmp, mode=netascii>
Transfer timed out.

Here is the tftp log files.
Connection received from 10.171.58.6 on port 59362 [21/10 09:42:40.842]
Write request for file <agent-160249.tmp>. Mode netascii [21/10 09:42:40.846]
File <agent-160249.tmp> : error 10054 in system call recv An existing connection was forcibly closed by the remote host. [21/10 09:42:41.029]

We are running 11.2.1 HF7 on both platforms. 

We are looking into what other options we have with BNA for the recovery process. 

Did your laptop have a connection/route back to the device or a firewall package enabled? Do you see the same behaviour when using BNA and is the file pushed in the same way (i.e. F5 is the client and sends to the server).

From what you posted, it doesn't look like your laptop responded to the WRQ request with an TFTP ACK.

It's odd that your laptop reports a forcible closure as this is UDP and therefore there is no such thing!

textYes, my laptop has a route back to the device.

C:\Users\sbmesse>ping 10.171.58.6

Pinging 10.171.58.6 with 32 bytes of data: Reply from 10.171.58.6: bytes=32 time=169ms TTL=247 Reply from 10.171.58.6: bytes=32 time=169ms TTL=247

Ping statistics for 10.171.58.6: Packets: Sent = 2, Received = 2, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 169ms, Maximum = 169ms, Average = 169ms

The file is pushed the same way. F5 is the client and BNA is the server.

I get the same thing when I try to send it to BNA. THe LTM can ping the BNA server.

[root@LB-JP-SRV1-1:Active:In Sync] config # tftp 161.173.59.48 tftp> verbose Verbose mode on. tftp> trace Packet tracing on. tftp> put /var/local/scf/agent-160249.tmp agent-160249.tmp putting /var/local/scf/agent-160249.tmp to 161.173.59.48:agent-160249.tmp [netascii] sent WRQ <file=agent-160249.tmp, mode=netascii> sent WRQ <file=agent-160249.tmp, mode=netascii> sent WRQ <file=agent-160249.tmp, mode=netascii> sent WRQ <file=agent-160249.tmp, mode=netascii> sent WRQ <file=agent-160249.tmp, mode=netascii> Transfer timed out.

tftp> quit [root@LB-JP-SRV1-1:Active:In Sync] config # ping 161.173.59.48 PING 161.173.59.48 (161.173.59.48) 56(84) bytes of data. 64 bytes from 161.173.59.48: icmp_seq=1 ttl=55 time=168 ms 64 bytes from 161.173.59.48: icmp_seq=2 ttl=55 time=168 ms 64 bytes from 161.173.59.48: icmp_seq=3 ttl=55 time=168 ms 64 bytes from 161.173.59.48: icmp_seq=4 ttl=55 time=168 ms ^C --- 161.173.59.48 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 168.228/168.717/168.922/0.405 ms

Is there a firewall between the F5 device and the BNA server or your laptop?

BTW, I've managed to test this on my VE, attempting to transfer to a non-existent host. The output is the same. Surely something is being silently dropped somewhere. Have you tried a tcpdump in another terminal?

No. Also to note, this is happening on all of our 4200v's. 

Worth trying a tcpdump then? 

Here is the tcpdump from the 4200

[root@LB-JP-SRV1-1:Active:In Sync] config # tcpdump -nni 0.0 host 161.173.59.48
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
15:59:02.715107 IP 10.171.58.6.46281 &gt; 161.173.59.48.69:  28 WRQ "agent-160249.tmp" netascii
15:59:02.901345 IP 161.173.59.48.39795 &gt; 10.171.58.6.46281: UDP, length 19
15:59:02.902001 IP 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 46281 unreachable, length 36
15:59:07.715263 IP 10.171.58.6.46281 &gt; 161.173.59.48.69:  28 WRQ "agent-160249.tmp" netascii
15:59:07.904240 IP 161.173.59.48.39135 &gt; 10.171.58.6.46281: UDP, length 19
15:59:07.904962 IP 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 46281 unreachable, length 36
15:59:12.715289 IP 10.171.58.6.46281 &gt; 161.173.59.48.69:  28 WRQ "agent-160249.tmp" netascii
15:59:12.885430 IP 161.173.59.48.59497 &gt; 10.171.58.6.46281: UDP, length 19
15:59:12.886446 IP 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 46281 unreachable, length 36
15:59:17.715327 IP 10.171.58.6.46281 &gt; 161.173.59.48.69:  28 WRQ "agent-160249.tmp" netascii
15:59:17.885188 IP 161.173.59.48.43585 &gt; 10.171.58.6.46281: UDP, length 19
15:59:17.886054 IP 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 46281 unreachable, length 36
15:59:22.715444 IP 10.171.58.6.46281 &gt; 161.173.59.48.69:  28 WRQ "agent-160249.tmp" netascii
15:59:22.884091 IP 161.173.59.48.38007 &gt; 10.171.58.6.46281: UDP, length 19
15:59:22.885389 IP 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 46281 unreachable, length 36

Here is the tcpdump from the 3900
[root@LB-EDC-SRV2-1:Active:In Sync] config # tcpdump -nni 0.0 host 10.98.11.135
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
17:13:05.220018 IP 172.17.40.6.42927 &gt; 10.98.11.135.69:  28 WRQ "agent-579614.tmp" netascii
17:13:05.265878 IP 10.98.11.135.62508 &gt; 172.17.40.6.42927: UDP, length 4
17:13:05.266956 IP 172.17.40.6.42927 &gt; 10.98.11.135.62508: UDP, length 516
17:13:05.272177 IP 10.98.11.135.62508 &gt; 172.17.40.6.42927: UDP, length 4
17:13:05.272878 IP 172.17.40.6.42927 &gt; 10.98.11.135.62508: UDP, length 516
17:13:05.277888 IP 10.98.11.135.62508 &gt; 172.17.40.6.42927: UDP, length 4
17:13:05.278880 IP 172.17.40.6.42927 &gt; 10.98.11.135.62508: UDP, length 516
17:13:05.283374 IP 10.98.11.135.62508 &gt; 172.17.40.6.42927: UDP, length 4
17:13:05.283887 IP 172.17.40.6.42927 &gt; 10.98.11.135.62508: UDP, length 516
17:13:05.289118 IP 10.98.11.135.62508 &gt; 172.17.40.6.42927: UDP, length 4
17:13:05.289865 IP 172.17.40.6.42927 &gt; 10.98.11.135.62508: UDP, length 516
17:13:05.294381 IP 10.98.11.135.62508 &gt; 172.17.40.6.42927: UDP, length 4
17:13:05.294843 IP 172.17.40.6.42927 &gt; 10.98.11.135.62508: UDP, length 516

So it looks to me that the 4200 is saying that the port is not available after he said that was the port he was going to use.

Thanks but unless you can format the output I'm not going to be able to read it I'm afraid.If you select it all and click the 'button' with the grey strip on it's left that should do it. Cheers

Sorry. I have fixed it. I am new to devcentral. I was wondering how to make it look correct. Thanks for the tip.

Indeed it does. Does the traffic route out of the management interface or a TMM interface? Any chance you have AFM installed?

I do not have a management interface configured. The default gateway is out TMM interface. The only thing I have provisioned is LTM.

OK, interesting. So, a few more things;

1) Can you run the tcpdump on the 4200 device adding -vv (that's v twice, not w) so it provides more verbose output

2) can you try using netcat to test too, I'm not sure from memory if it's installed but try nc, ncat or netcat at the CLI

3) can you post the port lockdown settings for the self ip in question please and finally

4) can you try adding a specific route in LTM for the BNA host or the subnet it's on please.

Here is the tcpdump -vv

    [root@LB-JP-SRV1-1:Active:In Sync] config # tcpdump -vv -nni 0.0 host 161.173.59.48
    tcpdump: listening on 0.0, link-type EN10MB (Ethernet), capture size 96 bytes
    09:35:15.860124 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17891 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:35:16.039529 IP (tos 0x0, ttl  55, id 53558, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.35817 &gt; 10.171.58.6.17891: [udp sum ok] UDP, length 19
    09:35:16.039904 IP (tos 0x0, ttl 255, id 6763, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17891 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53558, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.35817 &gt; 10.171.58.6.17891: UDP, length 19
    09:35:20.860201 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17891 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:35:21.028248 IP (tos 0x0, ttl  55, id 53559, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.41953 &gt; 10.171.58.6.17891: [udp sum ok] UDP, length 19
    09:35:21.029110 IP (tos 0x0, ttl 255, id 23118, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17891 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53559, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.41953 &gt; 10.171.58.6.17891: UDP, length 19
    09:35:25.860243 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17891 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:35:26.028611 IP (tos 0x0, ttl  55, id 53560, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.51623 &gt; 10.171.58.6.17891: [udp sum ok] UDP, length 19
    09:35:26.029099 IP (tos 0x0, ttl 255, id 63946, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17891 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53560, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.51623 &gt; 10.171.58.6.17891: UDP, length 19
    09:35:30.860316 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17891 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:35:31.029024 IP (tos 0x0, ttl  55, id 53561, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.44508 &gt; 10.171.58.6.17891: [udp sum ok] UDP, length 19
    09:35:31.030415 IP (tos 0x0, ttl 255, id 56690, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17891 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53561, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.44508 &gt; 10.171.58.6.17891: UDP, length 19
    09:35:35.860369 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17891 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:35:36.028675 IP (tos 0x0, ttl  55, id 53562, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.35585 &gt; 10.171.58.6.17891: [udp sum ok] UDP, length 19
    09:35:36.029332 IP (tos 0x0, ttl 255, id 64237, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17891 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53562, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.35585 &gt; 10.171.58.6.17891: UDP, length 19

    Here is the tcpdump after the route added,

    09:50:43.681132 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17552 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:50:43.890132 IP (tos 0x0, ttl  55, id 53563, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.47085 &gt; 10.171.58.6.17552: [udp sum ok] UDP, length 19
    09:50:43.891040 IP (tos 0x0, ttl 255, id 28279, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17552 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53563, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.47085 &gt; 10.171.58.6.17552: UDP, length 19
    09:50:48.681209 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17552 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:50:48.851267 IP (tos 0x0, ttl  55, id 53564, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.49750 &gt; 10.171.58.6.17552: [udp sum ok] UDP, length 19
    09:50:48.852292 IP (tos 0x0, ttl 255, id 59943, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17552 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53564, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.49750 &gt; 10.171.58.6.17552: UDP, length 19
    09:50:53.681291 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17552 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:50:53.849545 IP (tos 0x0, ttl  55, id 53565, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.49688 &gt; 10.171.58.6.17552: [udp sum ok] UDP, length 19
    09:50:53.850043 IP (tos 0x0, ttl 255, id 20784, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17552 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53565, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.49688 &gt; 10.171.58.6.17552: UDP, length 19
    09:50:58.681309 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17552 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:50:58.849741 IP (tos 0x0, ttl  55, id 53566, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.38342 &gt; 10.171.58.6.17552: [udp sum ok] UDP, length 19
    09:50:58.850212 IP (tos 0x0, ttl 255, id 59996, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17552 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53566, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.38342 &gt; 10.171.58.6.17552: UDP, length 19
    09:51:03.681392 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 56) 10.171.58.6.17552 &gt; 161.173.59.48.69: [udp sum ok]  28 WRQ "agent-160249.tmp" netascii
    09:51:03.849714 IP (tos 0x0, ttl  55, id 53567, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.36877 &gt; 10.171.58.6.17552: [udp sum ok] UDP, length 19
    09:51:03.850384 IP (tos 0x0, ttl 255, id 20822, offset 0, flags [DF], proto: ICMP (1), length: 56) 10.171.58.6 &gt; 161.173.59.48: ICMP 10.171.58.6 udp port 17552 unreachable, length 36
            IP (tos 0x0, ttl  55, id 53567, offset 0, flags [none], proto: UDP (17), length: 47) 161.173.59.48.36877 &gt; 10.171.58.6.17552: UDP, length 19

As far as port lockdown, I have it set to Allow All on both the floater and the self-IP.

I am still working on the netcat, but I wanted to the post the other information.
We are able to copy a small file across port 7000. the real backup file we get about 10 lines and then a write error.

LTM netcat
[root@LB-JP-SRV1-1:Active:In Sync] config # cat /var/local/scf/lb-jp-srv1-1 | nc -u 161.173.59.48 7000
nc: Write error: Connection refused

Server netcat
    [root@bbna-agent-e01 tftpboot]# nc -l -u -w 3600 7000
    cli admin-partitions {
        update-partition Common
    }
    cm cert /Common/dtca-bundle.crt {
        cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtca-bundle.crt_14
        checksum SHA1:2201:3e50cd3f97366f326e394f995c35a4df5dc16721
        revision 14
    }
    cm cert /Common/dtca.crt {
        cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtca.crt_8
        checksum SHA1:1265:f6e270fe7d2fb02c3462969f5a07150972fd51a3
        revision 8
    }
    cm cert /Common/dtdi.crt {
        cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtdi.crt_8
        checksum SHA1:1261:c52e425d5bf32b30f12654d2bdc104fa5941f852
        revision 8
    }
    cm device /Common/LB-JP-SRV1-1.homeoffice.jp.wal-mart.com {
        active-modules { "GTM-DNS, RL, LO, BIG-IP|QZSFXZE-GARKFMS|DNS Rate Fallback, 50|GTM Rate Fallback, 8|DNS Licensed Objects, 0|GTM Rate, 8|DNS Rate Limit, 50 QPS|GTM Licensed Objects, 0" "LTM, Base, 4200V|HAGNHPH-CBFMNTM|SSL, Max TPS|Max Compression|Application Acceleration Manager, Core|IPV6 Gateway|

You sure what you've posted is correct? Lot's of config there!

Why port 7000?

So with netcat we could not use port 69 because BNA was already using it so we just picked a random port. Also it was in the example we saw on how to use netcat. Also looking on the amount of data that was able to be sent across, it was 1024 characters and then we get the error. 

Here is the update we have received from support.

I have spoken with the escalation engineer and at this point we have confirmed that the issue with TFTP connectivity exists in v11.2.x but does not in v11.4.1 so we are sifting through any known issues that may cause this intermittent behavior.

From the tcpdumps, we see that the initial RRQ(get) / WRQ (put) communication on port 69 is fine. It's the data flow over the ephemeral port that isn't recognized by BIG-IP causing an ICMP port unreachable response.

Thanks for the update.

Your answer:

You must be logged in to reply. You can login here.