3 switches won't back up config in xmc (File not found / missing)

[Keith9]

I have daily config backup configured for 7 am for two groups, core and access. I have all our switches sucessfully backing except 3 of them.  I have 11 switch stacks in our access switch group and 3 of these stacks have the this message

File Not Found/Missing -Error: Could not connect with TFTP server at 10.1.0.110

File Not Found/Missing -Error: Could not connect with TFTP server at 10.1.0.110

File Not Found/Missing - The device was unable to contact the TFTP server.  Check that the TFTP server is runinng and connectivity is okay.

So the question poses, why just 3 switch stacks showing this error?  I have an ACL on all fo them SSH-access.pol, and I put the netsight server IP in it (10.1.0.110/32) and verified it worked by opening a terminal session to every switch stack.  This resolved my issue with the bulk of them, besides changing the SSH account after that broke when I changed to radius authentication.

So I have 2 valid core switch stacks backing up and 8 access switch stacks backing up.  I’m not sure whats up with the last 3.  They can ping and log in from the XMC web GUI.  There’s nothing impeding their path to XMC.

Thanks for any helpful hints.

[Keith9 · Accepted solution]

Ok well talking this through in the thread here got me looking more closely at the routing tables.  Netsight VM traffic was exiting our 2nd core switch (all vm’s are mlag’d between 2 cores).  Some VM’s go out one core, some the other.

The second core had that transport network advertised in its OSFP configuration and an IP interface on it, however that WAN is not connected.  We were going to earmark a port on it to go “swing the cable” in the event something happened to our primary core switch, however we don’t have any ports for that right now and we have a different, alternative backup path should we need to reach those locations out core 2.

So the 192.168.100.x/24 transport network that 3 remote sites were on, were not making it through to the second core switch.  I mean you could ping and trace PAST that network, but the EXOS switch INSISTED (as Stefan K. shows some examples) to use the interface in that 192.168.100.x network.  So to end users and servers, traditionally they noticed no issue.  They live and work in different IP networks that are all in the routing table.

So I removed that VLAN from core 2’s OSPF configuration and now it traverses an OSPF link we have between both cores and out that WAN provider that is physically connected into our core 1 switch stack.

(Our core switch stacks are X690’s, our access stacks are X450G2’s or 5520’s depending on location).

So in actuality this was a routing issue and now I was able to retrieve configurations successfully.

Thanks for talking me through it.  Sometimes you don’t notice the mundane details until you start typing it out and having a casual conversation.

[Stefan_K_]

Aaah, Transfer-net? Didn’t expect that between Edge and Core Switches. The switch uses the ipaddress of the egress interface, so it uses 192.168.100.50 in this case. I had the exact same case many months ago.

How should the switch know which IP-Address to use… 🙂 On EOS you could define an mgmt IP-Address, but on EXOS that’s not possible.

You have to possibilities imo:

• configure a switch mgmt VLAN and create a new VR for this. Add the switch with this ip address to XMC and create a new TFTP script that uses the newly created VR. Might even work with the exisiting VR-Mgmt.
• Make the transfer-net reachable from XMC

[StephanH]

Hello Keith,

can you show your routing table to us, please?

[Keith9]

Ok so from a trouble switch when I just do a plain ping 10.1.0.110 its trying to source it from 192.168.100.50 which is the ip of the switch on our transport vlan.

If I source it from 10.50.0.100 (vlan 1 / Default) or 192.168.255.50 (loopback0) or from our vlan that has an ospf adjancency with a cisco router with LTE tunnel backup to HQ (10.200.1.17), all the pings succeed.

For some reason, by default the switch wants to use the vlan WAN IP of our 40/40mbps metro e transport IP and that does not return.

I’m not sure where in its brain it wants to source from that IP from default. I thought it would start at vlan 1 (the top of the list).  Not vlan 296 (our wan tranport out).