Problem with two Cisco switches to save the configuration by tftp

I can't ping the tftp server, but I can ping other servers in the same network segment as the tftp server. I can ping the tftp server from all other switches. The tftp server debugging shows no connection from these two switches.

If you can't ping the TFTP server then there's not going to be any attempt to transfer data.  Assuming that no ACL's are in place.

So the first task is to determine the connectivity problem.  Is the switch management interface on the same network as the TFTP server?  Or do you have to get routed between the two?

Hi Don,
the management interfaces are in a 192.168.50.0/24 subnet. The servers are in a 10.91.200.0/22 subnet. The core switch has routing functionality. I can ping servers in the server subnet but not the tftp server. I checked also the firewall. No difference if switched on or off. The core switch has no vlan ACLs.

Thanks for your help.

Olaf

If no ACL is involved, my first thought is physical connection, then ARP cache.

I wouldn't rule out ACL though

When being connected to these two switches, I can't ping the tftp server,

I need more clarity here. Is it the TFTP server that is connected to the switch or PC. Please sketch a simple topology diagram and post

There could be an ACL on the core switch.  
There could be a firewall on the server blocking the traffic.

Can the server ping its default gateway?
Can the the server ping core switch SVI on the 192.168.50.0 network?

Hi,
I attach a scheme to explain more in detail, what I mean. My tftp server can ping everything except Switch202 and 203. TS1 can ping all switches. Both TFTP and TS1 reside on the same ESX host using the same distributed vSwitch. Switch202/203 can't ping TFTP but can ping TS1 and all the switches on the path. Same with tftp client. There must be something special with TS1 or with Switch202/203? But what?

Regards

Olaf

enssw203-tftp-problem.pdf

Ok
We're getting closer.
I'm suspecting a route issue or connection issue on Switch 201.

Post the result of show ip route on the core switch
you may need to configure single host routes on the core switch or switch 201 for 202 and 203, but let's identify the bottleneck first.
Also, are switches 202 and 203 connected to trunk ports on 201?

On 202 and 203, run both traceroute 10.91.200.2 and traceroute 10.91.200.2

My tftp server can ping everything except Switch202 and 203. TS1 can ping all switches

This would indicate that traffic can flow from the server network to all switches.

So I'm going with an ACL either on the core switch, switch 201 or the switch between the core and the vswtch.

Hi,
that's what I can do from TS1:

C:\Users\TEMP>tracert switch203
Tracing route to switch203.domain [192.168.50.x] over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.91.203.254 (that's the core switch)
  2     2 ms     1 ms     1 ms  switch203.domain [192.168.50.x]

Trace complete.

From TFTP it looks like:
C:\Users\administrator.ENAS>tracert switch203
Tracing route to switch203.domain [192.168.50.x] over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.91.203.254 (that's the core switch)
  2    *    *     ^C  --> time out

I switched on the ICMP debugging at switch201. But I can see only packet with the switch itself as destination, like:

4005173: Dec 18 13:24:41: ICMP: echo reply sent, src 192.168.91.65, dst 192.168.91.85
:
4005177: Dec 18 13:24:41: ICMP: echo reply sent, src 192.168.91.65, dst 192.168.91.85

There are no ACLs between the VLANs at the core switch and no ACLs on the other switches.

Is it possible to use RSPAN to watch the packet going through the switches?

Thanks
Olaf

It looks like ACL but it could still be route related.
I'm suspecting a NULL route issue if it is not ACL or firewall related

How about the route info from the core switch and a traceroute from the switches to the tftp

Post the result of show ip route on the core switch
On 202 and 203, run both traceroute 10.91.200.1 and traceroute 10.91.200.2

Here it is:

Switch203#traceroute ts1
Translating "ts1"...domain server (10.91.200.10) [OK]
i
Type escape sequence to abort.
Tracing the route to ts1.domain (10.91.200.1)
VRF info: (vrf in name/id, vrf out name/id)
  1 coreswitch.domain (192.168.50.254) 8 msec 9 msec 0 msec
  2  *  *  *
  3  *

Switch203#ping ts1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.91.200.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/9 ms

Switch203#traceroute tftp
Translating "tftp".domain server (10.91.200.2) [OK]
i
Type escape sequence to abort.
Tracing the route to tftp.domain (10.91.200.2)
VRF info: (vrf in name/id, vrf out name/id)
  1  *  *  *
  2  *
Switch203#ping tftp
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.91.200.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Core Switch#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
:
Gateway of last resort is 153.x.x.x to network 0.0.0.0
     153.96.0.0/24 is subnetted, 1 subnets
:
C    192.168.50.0/24 is directly connected, Vlan200
     10.0.0.0/8 is variably subnetted, 16 subnets, 3 masks
:
C       10.91.200.0/22 is directly connected, Vlan208
S*   0.0.0.0/0 [1/0] via 153.x.x.x

To be honest, it makes no sense to me ... A bit to odd.

Behaves just like it would if there was an ACL somewhere in between.

The core switch only has two routes??? How is your default route working if you don't have a connection to the 153.x.x.x?

I shortened the output of the routing table. I left the routes to the considered networks and the default route. The default route points to a perimeter router/firewall. If this connection is down, we have no internet access but the internal networks are still reachable.

Is there a way to debug the ping or tftp packets on their way across the network? We are using Cisco IOS switches. One should see on which switch the packets will be blocked, shouldn't one?

A packet capture like Wireshark may be helpful.

The route seem okay, meaning there is some filtering happening somewhere.
If possible, swap the cable connections between the TFTP servers (either on the switch or the NIC if the servers are close to each other). Let's see if the problem travels with the connection