EXOS TFTP put to Netsight failing due to incorrect forward slash


Userlevel 5
Whenever I submit the command:

tftp put xxx.xxx.xxx.xxx vr "VR-Default" internal-memory
show_tech.log.gz

It fails with the following response:

Uploading show_tech.log.gz to xxx.xxx.xxx.xxx ... failed!

Error: (2) unable open file

The message in Netsight syslog is as follows:

127.0.0.1 open() file=C:\tftpboot/show_tech.log.gz client
session: xxx.xxx.xxx.xxx:57941



So my guess is with Netsight being windows based using a \ (backslash) and EXOS being Linux based and using a / (Forward slash), this is where the problem comes in.

Can't see how to correct this in EXOS as specifying a forward slash gives an error, and I don't know if there is a way to correct within the TFTP server in Netsight.

Have also tried the following:

X460.2 # tftp xxx.xxx.xxx.xxx -v "VR-Default" -p -l internal-memory show_tech.log.gz

Uploading show_tech.log.gz to xxx.xxx.xxx.xxx... failed!
Error: (2) unable open file

...

X460.3 # tftp xxx.xxx.xxx.xxx -v "VR-Default" -p -l internal-memory show_tech.log.gz -r show_tech.log.gz

Uploading show_tech.log.gz to xxx.xxx.xxx.xxx... failed!

Error: (2) unable open file

...

X460.4 # tftp xxx.xxx.xxx.xxx -v "VR-Default" -p -l internal-memory show_tech.log.gz -r \show_tech.log.gz

Error: Illegal filename (\show_tech.log.gz)

ExtremeXOS version 15.3.1.4

Netsight version 6.2.0.199

29 replies

Userlevel 5
Martin,

You can also try the following... Should do what you are looking for....

upload debug [hostname | ipaddress] {{vr} vr_name} Description

Uploads debug information files to a tftp server. On a platform that has both primary and backup

MSMs/MMs, debug information files are uploaded from both the backup and primary MSMs/MMs.

Syntax Description

hostname Specifies the host name of the TFTP server to which the debug files will be

uploaded to.

ipaddress Specifies the IP address of the TFTP server to which the debug files will be

uploaded to.

vr_name Specifies the name of the virtual router.

Default

By default, the virtual router VR-Mgmt will be used.
Userlevel 5
Hi Bill,

Thanks for getting back to me and for the info.

Had unfortunately already tried that but it still didn't work, for the same reason........

If you look at my internal memory you can see the show_tech.log.gz file listed

X460.3 # ls internal-memory

-rwxr-xr-x 1 root 0 62357 Apr 22 10:51 show_tech.log.gz

-rwxr-xr-x 1 root 0 161911 Apr 22 10:51 trace.devmgr.1421

-rwxr-xr-x 1 root 0 592 Apr 22 10:51 trace.fdb.1443

-rwxr-xr-x 1 root 0 608 Apr 22 10:50 trace.mcmgr.1490

-rwxr-xr-x 1 root 0 143117 Apr 22 10:51 trace.nodemgr.1425

-rwxr-xr-x 1 root 0 600 Apr 22 10:51 trace.rip.1497

-rwxr-xr-x 1 root 0 608 Apr 22 10:51 trace.rtmgr.1482

-rwxr-xr-x 1 root 0 1034 Apr 22 10:45 trace.vlan.1441



If you run the upload debug command you get the following:



X460.2 # upload debug xxx.xxx.xxx.xxx vr "VR-Default"

Do you want to run show tech logto file first? (y/N) Yes

Upload debug cancelled. Please run show tech logto file now.



X460.4 # upload debug xxx.xxx.xxx.xxx vr "VR-Default"

Do you want to run show tech logto file first? (y/N) No

.......................................................................................................

Error: tftp: server error: (2) unable open file



Netsight gives the following error:



Upload Engineering to hostname ip address xxx.xxx.xxx.xxx VR VR-Default

Upload Engineering failed. Failed to tftp intern tarball to server



In order to find out more what is going on I enabled the debug mode on the TFTP server. This is done by editing the nstftpd.cfg file in the Netsight services file. The option you can have are as follows:

Usage : tftpd [-v][-c][-d dirname][-p pidfilename][-trace][-debug]

-v print version and exit

-c allow tftpd to create uploaded files if they do not already exist.

-d use the specified dirname as the base where tftpd will look to read/store files

-p use the specified pid file name to store the pid of the process

-fg run tftpd in the foreground rather than



So I changed the:

-d "c:\tftpboot"

to

-d "c:\tftpboot" -debug



Now the syslog on Netsight shows the following issue:

Netsight 127.0.0.1 open() file=C:\tftpboot/X460_I_04230955.tgz client session: xxx.xxx.xxx.xxx:38436

Netsight 127.0.0.1 Sending error (2) -- unable open file to client session: xxx.xxx.xxx.xxx:38436

Netsight 127.0.0.1 Retrieving session client session: xxx.xxx.xxx.xxx:38436

Upload Engineering failed. Failed to tftp intern tarball to server

Received write request file=X460_I_04230955.tgz mode=octet client session: xxx.xxx.xxx.xxx:38436

So two things about that don't seem right, the first is the slash is in the wrong direction again and the file is "X460_I_04230955.tgz", instead of" show_tech.log.gz" that was created by the show tech command?

Also if I run the following:

X460.6 # upload configuration xxx.xxx.xxx.xxx primary.cfg vr "VR-Default"

Uploading primary.cfg to xxx.xxx.xxx.xxx ... failed!

Error: (2) unable open file



Netsight reports the same problem with the slash in the wrong direction:



Netsight 127.0.0.1 open() file=C:\tftpboot/primary.cfg client session: xxx.xxx.xxx.xxx:51367



At first I thought the issue might be a firewall problem, but the permission for TFTP has been added and the firewall logs are not showing a deny.

The other thought was that there might be a permissions issue on the c:\tftpboot folder, which I am still looking into but at the moment the slash seems to be the most obvious issue.

So as you can see no matter what command I use the slash is always in the wrong direct for use on Netsight / windows tftp server?
Userlevel 6
Martin,

The problem must be in NetSight. A transfer to 3CDaemon TFTP server (which also runs under Windows) ended successfully.

I also did a capture of the transfer and the filename sent does not include a slash.



You should open a case in GTAC.
Userlevel 7
Hi Martin,
I think you're right - the slash seems to be causing the problem. It sounds like this one will need to come to GTAC so that engineering can take a look.
Are you able to open a case on this? You can link this thread in your problem description to help with the explanation.

Thanks,
-Drew
Userlevel 5
Martin,

Thanks for the information.. I have forwarded it directly to the project manager for Netsight... will let you know when I hear back.

Bill
Userlevel 5
Martin,

Your hunch was correct.. It is a permission issue, here is the fix: Give it a shot and let us know!

Edit /NetSight_Install_Path/NetSight/services/nstftpd.cfg

Add a –c to the line:



-c -d "c:\tftpboot"



Save and then restart the tftp service.
Userlevel 6
Yes, that solved the problem...
Userlevel 6
Martin,

Since you are using NetSight as your TFTP server, you might want to create a script in OneView that can be applied to any switch.

Here's a quick and dirty example:

#@MetaDataStart
#############################################################################################
# Define your user parameters in this section. For reference, see bundled scripts.
#############################################################################################
#@MetaDataEnd
# Enter all CLI commands from here
set var devIP $tcl(string map {. -} $deviceIP)
set var dat $tcl(string map {"-" ""} $date)
set var tim $tcl(string map {":" "" " " ""} $time)
show tech all detail logto file
tftp put $serverIP vr vr-mgmt internal-memory show_tech.log.gz support/$devIP-$dat$tim-show_tech.log.gz
[/code]
The script uses several variables provided by NetSight:
- $deviceIP: the address of the switch where the script is being run.
- $date: current date.
- $time: current time
- $serverIP: tftp server address (NetSight)

The contents of the first three variables have to be "sanitized" to be used as part of the filename so you can run the scrip on multiple switches simultaneously and/or store multiple files from the same device at different days or times.

I also created a support subdirectory under /tftpboot to keep the saved files separate from the rest.

With this script all you have to do is select the switch(es) you want to get the show tech from and drink your coffee while NetSight does all the work... ;=)
Userlevel 5
Martin,

Since you are using NetSight as your TFTP server, you might want to create a script in OneView that can be applied to any switch.

Here's a quick and dirty example:

#@MetaDataStart
#############################################################################################
# Define your user parameters in this section. For reference, see bundled scripts.
#############################################################################################
#@MetaDataEnd
# Enter all CLI commands from here
set var devIP $tcl(string map {. -} $deviceIP)
set var dat $tcl(string map {"-" ""} $date)
set var tim $tcl(string map {":" "" " " ""} $time)
show tech all detail logto file
tftp put $serverIP vr vr-mgmt internal-memory show_tech.log.gz support/$devIP-$dat$tim-show_tech.log.gz
[/code]
The script uses several variables provided by NetSight:
- $deviceIP: the address of the switch where the script is being run.
- $date: current date.
- $time: current time
- $serverIP: tftp server address (NetSight)

The contents of the first three variables have to be "sanitized" to be used as part of the filename so you can run the scrip on multiple switches simultaneously and/or store multiple files from the same device at different days or times.

I also created a support subdirectory under /tftpboot to keep the saved files separate from the rest.

With this script all you have to do is select the switch(es) you want to get the show tech from and drink your coffee while NetSight does all the work... ;=)

Hi Daniel,

Thanks for taking the time to add that script, looks really useful. Have a question for you though, when running that script I'm getting a timeout error:

User: domain\martin.flammia

10.10.10.10 10.10.10.10 2015-04-27 at 09:58:28 BST

*** Error at line - 10 ***

Error: Command execution on server timed out. The command may still be running on device. Refresh results to see execution log.

If this is valid command and you would like to re-run, increase your request timeout.

My first thought was that its just timing out waiting for a command to complete. Line 10 is the command:

show tech all detail logto file

But when I run a ls internal-memory on the switch the file never appears. Running that command directly on the switch seems to work fine.

Below is the message reported by Netsight with verbose script logging on:

2015-04-27 09:58:28,187 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.beans.impl.DeviceCommunicatorUtil] getCommunicatorScript - 10.10.10.10: Using cache



2015-04-27 09:58:28,203 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.scriptInterpreter.ExecuteCLICommand] timeout for cli [CLI show tech all detail logto file] 58 seconds.



2015-04-27 09:58:28,203 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.session.DeviceSessionFactory] Creating session|CLI|10.10.10.10|



2015-04-27 09:58:28,203 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.session.cli.DeviceSshSession] Setting the timeOut for session Connection, inside the DeviceSshSession



2015-04-27 09:58:29,140 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:29,234 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.session.cli.DeviceCliSession] 10.10.10.10|Processing Command|show tech all detail logto file|



2015-04-27 09:58:29,234 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.session.cli.DeviceSshSession] 10.10.10.10|Send command and wait for a prompt|show tech all detail logto file|



2015-04-27 09:58:33,257 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.StatisticsMonitor] Setting stats for Script Executed to Current Rate = 0/min Max Rate: 1/min Total: 3



2015-04-27 09:58:33,632 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:37,953 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:42,332 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:46,691 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:50,988 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:55,285 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:58:59,566 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:03,863 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:08,175 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:12,456 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:16,769 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:21,081 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:25,394 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.ExpiringScriptCache] Expiring Script Cache:size=4] Found: 19



2015-04-27 09:59:28,003 DEBUG [com.extremenetworks.epicenter.server.scripting.common.ScriptingApi] ScriptTask Completed Successfully



2015-04-27 09:59:29,363 DEBUG [com.extremenetworks.epicenter.server.deviceCommunicator.beans.impl.DeviceCommunicatorManagerBean] Error||Exception



tcl.lang.TclException: Error: Command execution on server timed out. The command may still be running on device. Refresh results to see execution log.



If this is valid command and you would like to re-run, increase your request timeout.



at com.extremenetworks.epicenter.server.deviceCommunicator.scriptInterpreter.RunScriptTask.execute(RunScriptTask.java:170)



at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)



at com.extremenetworks.epicenter.server.deviceCommunicator.beans.impl.DeviceCommunicatorManagerBean.startChainCommand(DeviceCommunicatorManagerBean.java:2800)



at com.extremenetworks.epicenter.server.deviceCommunicator.beans.impl.DeviceCommunicatorManagerBean.handleRequest(DeviceCommunicatorManagerBean.java:2054)



at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)



at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)



at java.lang.reflect.Method.invoke(Method.java:606)



at com.extremenetworks.epicenter.server.common.beans.impl.AbstractManager.handleRequest(AbstractManager.java:348)



at com.extremenetworks.epicenter.server.common.beans.impl.RequestExecutor.executePureSyncRequest(RequestExecutor.java:424)



at com.extremenetworks.epicenter.server.common.beans.impl.RequestExecutor.executeSyncRequest(RequestExecutor.java:194)



at com.extremenetworks.epicenter.server.scripting.tasks.BatchAssemblyTask.execute(BatchAssemblyTask.java:247)



at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)



at com.extremenetworks.epicenter.server.scripting.beans.impl.ScriptingManagerBean.startRunScriptChain(ScriptingManagerBean.java:1164)



at com.extremenetworks.epicenter.server.scripting.beans.impl.ScriptingManagerBean.handleRequest(ScriptingManagerBean.java:559)



at com.extremenetworks.epicenter.server.scripting.beans.impl.ScriptingManagerBean.handleRequest(ScriptingManagerBean.java:134)



at com.extremenetworks.epicenter.server.scripting.beans.impl.ScriptingManagerMDB.handleRequest(ScriptingManagerMDB.java:95)



at com.extremenetworks.epicenter.server.common.beans.impl.AbstractMDB.doHandleMessage(AbstractMDB.java:130)



at com.extremenetworks.epicenter.server.common.beans.impl.AbstractMDB.handleMessage(AbstractMDB.java:101)



at com.extremenetworks.epicenter.server.scripting.beans.impl.ScriptingManagerMDB.onMessage(ScriptingManagerMDB.java:66)



at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)



at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)



at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)



at java.lang.reflect.Method.invoke(Method.java:606)



at org.jboss.invocation.Invocation.performCall(Invocation.java:359)



at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:495)



at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)



at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:116)



at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)



at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)



at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)



at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)



at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109)



at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)



at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)



at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402)



at org.jboss.ejb.Container.invoke(Container.java:954)



at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987)



at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287)



at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)



at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:905)



at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)



at org.jboss.mq.SpySession.run(SpySession.java:323)



at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)



at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)



at java.lang.Thread.run(Thread.java:745)



2015-04-27 09:59:29,363 INFO [com.extremenetworks.epicenter.server.scripting.common.ScriptingUtil] RunScript request: 19 | script id: 32 | size: 1 | took 61 secs.



2015-04-27 09:59:29,363 DEBUG [com.extremenetworks.epicenter.server.scripting.beans.impl.DbObjectCache] ScriptBean cache hit for key: 32



2015-04-27 09:59:29,363 DEBUG [com.extremenetworks.epicenter.server.scripting.common.ScriptingUtil]
Userlevel 6
Martin,

Since you are using NetSight as your TFTP server, you might want to create a script in OneView that can be applied to any switch.

Here's a quick and dirty example:

#@MetaDataStart
#############################################################################################
# Define your user parameters in this section. For reference, see bundled scripts.
#############################################################################################
#@MetaDataEnd
# Enter all CLI commands from here
set var devIP $tcl(string map {. -} $deviceIP)
set var dat $tcl(string map {"-" ""} $date)
set var tim $tcl(string map {":" "" " " ""} $time)
show tech all detail logto file
tftp put $serverIP vr vr-mgmt internal-memory show_tech.log.gz support/$devIP-$dat$tim-show_tech.log.gz
[/code]
The script uses several variables provided by NetSight:
- $deviceIP: the address of the switch where the script is being run.
- $date: current date.
- $time: current time
- $serverIP: tftp server address (NetSight)

The contents of the first three variables have to be "sanitized" to be used as part of the filename so you can run the scrip on multiple switches simultaneously and/or store multiple files from the same device at different days or times.

I also created a support subdirectory under /tftpboot to keep the saved files separate from the rest.

With this script all you have to do is select the switch(es) you want to get the show tech from and drink your coffee while NetSight does all the work... ;=)

The problem may be the detail keyword. If you have a large configuration it may take a while to capture all the info.

Try removing it and use
show tech all logto file[/code]
Userlevel 7
Martin,

Since you are using NetSight as your TFTP server, you might want to create a script in OneView that can be applied to any switch.

Here's a quick and dirty example:

#@MetaDataStart
#############################################################################################
# Define your user parameters in this section. For reference, see bundled scripts.
#############################################################################################
#@MetaDataEnd
# Enter all CLI commands from here
set var devIP $tcl(string map {. -} $deviceIP)
set var dat $tcl(string map {"-" ""} $date)
set var tim $tcl(string map {":" "" " " ""} $time)
show tech all detail logto file
tftp put $serverIP vr vr-mgmt internal-memory show_tech.log.gz support/$devIP-$dat$tim-show_tech.log.gz
[/code]
The script uses several variables provided by NetSight:
- $deviceIP: the address of the switch where the script is being run.
- $date: current date.
- $time: current time
- $serverIP: tftp server address (NetSight)

The contents of the first three variables have to be "sanitized" to be used as part of the filename so you can run the scrip on multiple switches simultaneously and/or store multiple files from the same device at different days or times.

I also created a support subdirectory under /tftpboot to keep the saved files separate from the rest.

With this script all you have to do is select the switch(es) you want to get the show tech from and drink your coffee while NetSight does all the work... ;=)

I'd strongly discourage the use of the
code:
detail
option. If you had to provide this file to GTAC, it actually contains information that is less useful in troubleshooting than the
code:
all
option.
Userlevel 5
Martin,

Since you are using NetSight as your TFTP server, you might want to create a script in OneView that can be applied to any switch.

Here's a quick and dirty example:

#@MetaDataStart
#############################################################################################
# Define your user parameters in this section. For reference, see bundled scripts.
#############################################################################################
#@MetaDataEnd
# Enter all CLI commands from here
set var devIP $tcl(string map {. -} $deviceIP)
set var dat $tcl(string map {"-" ""} $date)
set var tim $tcl(string map {":" "" " " ""} $time)
show tech all detail logto file
tftp put $serverIP vr vr-mgmt internal-memory show_tech.log.gz support/$devIP-$dat$tim-show_tech.log.gz
[/code]
The script uses several variables provided by NetSight:
- $deviceIP: the address of the switch where the script is being run.
- $date: current date.
- $time: current time
- $serverIP: tftp server address (NetSight)

The contents of the first three variables have to be "sanitized" to be used as part of the filename so you can run the scrip on multiple switches simultaneously and/or store multiple files from the same device at different days or times.

I also created a support subdirectory under /tftpboot to keep the saved files separate from the rest.

With this script all you have to do is select the switch(es) you want to get the show tech from and drink your coffee while NetSight does all the work... ;=)

Brilliant - that sorted the problem. Thanks.

Just changed the script to use vr vr-default for use in my particular setup.

Many thanks again.
Userlevel 5
The fix worked for me also, thanks Bill.
Userlevel 3
By default the NetSight TFTP server runs in a secure mode in that it will only write files to the server if that file already exists. Inventory Manager will first create an empty file as part of the archive process before it tells the device to TFTP the config to the server.

Adding the -c option removes this security and allows any user/system to write to the TFTP server rootdir. The security prevents malicious users from filling up the hard drive.
Userlevel 1
By default the NetSight TFTP server runs in a secure mode in that it will only write files to the server if that file already exists. Inventory Manager will first create an empty file as part of the archive process before it tells the device to TFTP the config to the server.

Adding the -c option removes this security and allows any user/system to write to the TFTP server rootdir. The security prevents malicious users from filling up the hard drive.
Hello Bob, we haven't spoken in a while.

I'm installing the latest version of Management Center, and am having the exact problem in this thread.

Why would I want to disable that standard TFTP security feature by allowing any host to put files into the tftp root directory?

Here's the details of the error I'm getting when trying to stamp a new archive version:

Saving configuration to script nms.xsf on master .... done! Saving script on Standbys (Slots: 2). on master .... done! Script saved on Standby (Slot-2): done! Slot-1 X440Stack.3 # tftp 10.1.1.16 -v "VR-Default" -p -l primary.cfg -r /configs/tmp/10_20_36_2/primary.cfg Uploading primary.cfg to 10.1.1.16 ... failed! Error: (2) unable open file Slot-1 X440Stack.4 # tftp 10.1.1.16 -v "VR-Default" -p -l nms.xsf -r /configs/tmp/10_20_36_2/nms.xsf Uploading nms.xsf to 10.1.1.16 ... failed! Error: (2) unable open file
I'm trying to get Command Center up and fully integrated with our Extreme network, to build a business case to buy it. The product not working is not a good pitch.

Thanks,

Jesse
Userlevel 7
If you use inventory manager that shouldn't be a problem - only if you load files directly from a system to the TFTP directory...

"Inventory Manager will first create an empty file as part of the archive process before it tells the device to TFTP the config to the server."

You might want to take a look into this post...
https://community.extremenetworks.com/extreme/topics/am-using-netsight-to-backup-the-extreme-switch-...
Userlevel 1
If you use inventory manager that shouldn't be a problem - only if you load files directly from a system to the TFTP directory...

"Inventory Manager will first create an empty file as part of the archive process before it tells the device to TFTP the config to the server."

You might want to take a look into this post...
https://community.extremenetworks.com/extreme/topics/am-using-netsight-to-backup-the-extreme-switch-...
Not so, Ronald. That error above was from Command Center. I wasn't asking about how to use the legacy application called Inventory Manager, which is a Java app. I don't want to use those old Java based legacy applications.

I can watch the folder on my Command Center server b:/tftpboot/configs/tmp/10_20_30_40/, and I can see Command Center create the files: nms.xsf, and primary.cfg, with filesize zero, as I'd expect to happen.

That's as far as it gets, until the archive fails, and I see another copy of the above error.
Userlevel 7
OK I also run EMC 7.0 - could you please share the error description from the archive window...

Userlevel 1
Hi Ronald,

It's what I posted above: https://community.extremenetworks.com/extreme/topics/exos-tftp-put-to-netsight-failing-due-to-file-s...



Here's what the Inventory server log recorded:

Userlevel 5
Hi Jesse,

I wonder if the switch is having trouble communicating with NetSight rather than a permissions issue.

For example I've seen something a bit similar to this before when NetSight has 2 interfaces with different IP's and it was communicating with the wrong one, or access to NetSight is via Vr-Mgmt instead Vr-Default.

Not saying its one of those but wonder if its worth adding the -c option in the nstftp.cfg file and running the following command directly on the X440's, taken from the script and see what the switch says the problem is:

tftp 10.1.1.16 -v "VR-Default" -p -l primary.cfg -r /configs/tmp/10_20_36_2/primary.cfg

It might also be worth running tcpdump on NetSight at the same time or before making the change to check that you are receiving the TFTP communication from the switch as you would expect.

Many thanks.
Userlevel 1
I tend to think that VR-Default switch in that command might be the problem. I have no idea where the script that set it resides. I'd think the configs I want would be from the VR-Mgmt, no?
Userlevel 7
If you do a "show vlan" on the switch please check what vr is used - for example IP 172.24.24.151 uses VR-Default (last column in the line).



But even if you use the wrong VR in my experience that should get you the error message something like... wrong vr used instead what you see.

As far as I know you'd only set the script in inventory manager (or I don't find it in EMC).
Here you'd see some screenshots of the script settings for a device...
https://community.extremenetworks.com/extreme/topics/am-using-netsight-to-backup-the-extreme-switch-...
Userlevel 1
However, I tried adding that -c switch to the tftpd config file and restarting the service:

Before the -c switch added:

Slot-1 46EAGX440Stack.1 # tftp 10.1.1.16 -v "VR-Default" -p -l primary.cfg -r /configs/tmp/10_20_36_2/primary.cfg
Uploading primary.cfg to 10.1.1.16 ... failed!
Error: (2) unable open file
Slot-1 46EAGX440Stack.2 # ping 10.1.1.16
Ping(ICMP) 10.1.1.16: 4 packets, 8 data bytes, interval 1 second(s).
16 bytes from 10.1.1.16: icmp_seq=0 ttl=126 time=2.748 ms
16 bytes from 10.1.1.16: icmp_seq=1 ttl=126 time=13 ms
16 bytes from 10.1.1.16: icmp_seq=2 ttl=126 time=14 ms
16 bytes from 10.1.1.16: icmp_seq=3 ttl=126 time=12 ms

--- 10.1.1.16 ping statistics ---
4 packets transmitted, 4 packets received, 0% loss
round-trip min/avg/max = 2/10/14 ms
Slot-1 46EAGX440Stack.3 # traceroute 10.1.1.16
traceroute to 10.1.1.16, 30 hops max
1 10.20.36.1 15 ms 1 ms 1 ms
2 10.1.230.1 3 ms 2 ms 12 ms
3 10.1.1.16 19 ms * 2 ms

--- Packet Response/Error Flags ---
(*) No response, (!N) ICMP network unreachable, (!H) ICMP host unreachable,
(!P) ICMP protocol unreachable, (!F) ICMP fragmentation needed,
(!S) ICMP source route failed, (!u) Transmit error, network unreachable,
(!f) Transmit error, fragmentation needed, (!t) General transmit error

And, after adding the -c. No change.

Slot-1 46EAGX440Stack.4 # tftp 10.1.1.16 -v "VR-Default" -p -l primary.cfg -r /configs/tmp/10_20_36_2/primary.cfg
Uploading primary.cfg to 10.1.1.16 ... failed!
Error: (2) unable open file
Slot-1 46EAGX440Stack.5 #
Userlevel 5
Ok... I know how to change the script to use Vr-mgmt using legacy mode in inventory manager, but funny enough I was trying to find the same thing in V7 oneview today but couldn't find it. Ill try and get a screenshot for you where and what to change in inventory manager.

In the meantime, what happens when you change the vr to vr-mgmt in the command you entered above?

Also not sure without trying if you might have to remove "-r /configs/tmp/10_20_36_2/primary.cfg" as it might not work if that directory doesn't currently exist in NetSight.

Sorry, having to experiment a bit without being in front of the kit to test.

Thanks.
Userlevel 5
Here is where to change the script to use vr-mgmt in inventory manager:



Let me know how the results above and the tcpdump on TFTP traffic goes.

Reply