We have a 7206 router in our network.
We are unable to do a "wr net" to our TFTP server. It times out.
The TFTP server is in the same LAN and we can ping it without any oacket loss but just cannot wr net to it.
Here are the debug logs on that router-
May 14 07:42:19.293 EDT: TFTP: Sending write request (retry 0), socket_id 0x672DF4D8
May 14 07:42:22.293 EDT: TFTP: Sending write request (retry 1), socket_id 0x672DF4D8
May 14 07:42:26.293 EDT: TFTP: Sending write request (retry 2), socket_id 0x672DF4D8
May 14 07:42:31.293 EDT: TFTP: Sending write request (retry 3), socket_id 0x672DF4D8
May 14 07:42:37.293 EDT: TFTP: Sending write request (retry 4), socket_id 0x672DF4D8
Its Windows Server 2003 R2.
PS- I can wr net to the same TFTP server from another Cisco 7206 router in the same network with the same IOS.
Appreciate your help,
Is there anything in the logs on your TFTP server about the attempts to write from the router with the problem? It would be helpful to verify whether the write request gets to the server.
If write net from another router works ok then I wonder if there is possibly an access list that is preventing the TFTP. I agree that seeing the complete config of the router would be helpful. I am wondering about the possibility of there being an ip tftp source-interface command which could impact operation of tftp. So seeing the router config may be quite helpful.
Clearly Imran I am seeing ip tftp source-interface Loopback0 command in your configuration file.
The loopback 0 Ip addres as given is 10.5.254.254, So check first it is reachable from TFTP server itself.
Also confirm the TFTP server IP address you are using.
Normally I would agree with your suggestion about checking and verifying the address being used for the TFTP server. But in his previous post Imran says that the logs of the TFTP server are showing timeouts. So that does verify that the server address is correct and that TFTP requests are being received.
I would suggest that the easiest way to test would be to use extended ping on the router that has the problem. In the extended ping specify the TFTP server as the destination address and using the extended commands in ping specify the loopback address as the source. I am guessing that the extended ping may fail and if it does that says that the TFTP server does not have a return path to the TFTP source, which explains the problem. If that is the case I would suggest that you check the TFTP server and see what is its default gateway, and then check on that default gateway to see if it has a route to the address of the loopback interface.
Thanks for your response.
Here is what I tried,
1) I did a ping test from the TFTP server(10.3.240.100) to the lo0 interface of our router and here are the results-Ping was successful.
C:\Documents and Settings\Default User>ping 10.5.254.254
Pinging 10.5.254.254 with 32 bytes of data:
Reply from 10.5.254.254: bytes=32 time=26ms TTL=246
Reply from 10.5.254.254: bytes=32 time=27ms TTL=246
Reply from 10.5.254.254: bytes=32 time=43ms TTL=246
Reply from 10.5.254.254: bytes=32 time=27ms TTL=246
Ping statistics for 10.5.254.254:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 43ms, Average = 30ms
C:\Documents and Settings\Default User>tracert 10.5.254.254
Tracing route to 10.5.254.254 over a maximum of 30 hops
1 1 ms <1 ms <1 ms pcba-v240.tru.com [10.3.240.251]
2 <1 ms <1 ms <1 ms pstore.tru.com [10.3.93.252]
3 <1 ms <1 ms <1 ms pcvpnstore.tru.com [18.104.22.168]
4 1 ms <1 ms <1 ms 22.214.171.124
5 2 ms 3 ms 3 ms parperwan.tru.com [10.3.254.6]
6 27 ms 27 ms 26 ms 10.5.254.254
However, when I do an extended ping from the router with the source interface as lo0 it fails!
Target IP address: 10.3.240.100
Repeat count :
Datagram size :
Timeout in seconds :
Extended commands [n]: y
Source address or interface: Loopback0
Type of service :
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.240.100, timeout is 2 seconds:
Packet sent with a source address of 10.5.254.254
Success rate is 0 percent (0/5)
Hope I am not sounding silly. Please advise.
Everything seems to be ok . What I Suspect something wrong in between the router and server, As from you trace route details there are many devices in between, can you plz share exact diagram of how TFTP server is connected to the router and what are devices in between.
Thank you for the additional information. It may shed some light on the issue.
If standard ping works from the router to the TFTP server then it demonstrates that the router does have working routes to the server. And if ping from the server to the loopback of the router then it demonstrates that there are working routes from the server to the loopback of the router. So it seems to rule out the possibility that the problem is a routing issue.
When an application (like ping) works in one direction but not in the other direction, my experence suggests that there may be an access list somewhere along the way that is filtering the traffic and denying some of the traffic. Using the traceroute results to identify the layer 3 devices along the path, can you check each of the layer 3 devices for the presence of an access list which might be filtering the TFTP traffic?
Also as a curiosity, can you do a traceroute from the router to the server and see if it shows the same layer 3 devices (in reverse order)?
Sounds silly but this used to crop up when using a unix system as the tftp server.
make sure the file exists, even if its empty.
make sure your permissions for read/write are set correctly.