Smarts NCM - MDS iNet 900 Devices Pulling Partial Configs;TFTP Timeout
Article ID: 330885
Updated On:
Products
VMware Smart Assurance
Issue/Introduction
Symptoms:
MDS iNet 900 devices pull partial configuration files in NCM, however, NCM pull config job shows complete/success.
MDS iNet 900 devices pull partial configuration files in NCM, however, NCM pull config job shows complete/success.
Environment
VMware Smart Assurance - NCM
Cause
The reason for this issue is commonly down to a timeout from the TFTP server.
NCM does not ship or install TFTP server software as part of the Smarts NCM product and thus has no control of the configuration of the TFTP server.
In some cases, NCM will report pull config jobs as complete even though the config viewable in NCM is not complete. This can be seen where there is a final entry in the config file, 'meout' (timedout):
The logs however show that NCM received a 'Complete' response from the pull config job ($VOYENCE_HOME/logs/commmgr.log):
5012/pull(10625311)#4: DASL: 02: Configuration Scripts Menu
5012/pull(10625311)#4: DASL: 03: ==========================================================================
5012/pull(10625311)#4: DASL: 04:
5012/pull(10625311)#4: DASL: 05: A) TFTP Host Address 10.11.12.13
5012/pull(10625311)#4: DASL: 06:
5012/pull(10625311)#4: DASL: 07: B) Filename 12345_config.pull
5012/pull(10625311)#4: DASL: 08:
5012/pull(10625311)#4: DASL: 09: C) TFTP Timeout 30 sec
5012/pull(10625311)#4: DASL: 10:
5012/pull(10625311)#4: DASL: 11: D) Retrieve File
5012/pull(10625311)#4: DASL: 12:
5012/pull(10625311)#4: DASL: 13: E) Send File Error: TFTP error
5012/pull(10625311)#4: DASL: 14:
5012/pull(10625311)#4: DASL: 15:
5012/pull(10625311)#4: DASL: 16:
5012/pull(10625311)#4: DASL: 17:
5012/pull(10625311)#4: DASL: 18:
5012/pull(10625311)#4: DASL: 19:
5012/pull(10625311)#4: DASL: 20:
Completed successfully **********************************************************
4508/ssh#1: RCV-6551>6fD) Retrieve File[13;6fE) Send File[5;28f146.32.139.39[7;28f12345_config.pul
4508/ssh#1: RCV-6551>[9;28f30 sec[11;28f[13;28fComplete
4508/ssh#1: RCV-6551>[23;41f[2K[22;41f[2K[25;80f
4508/ssh#1: ::getCurrentState - State match:[6551][(Complete)][Complete]
In this case, NCM is behaving as expected as a 'Complete' was received from the device. The partial config is down to a timeout from the TFTP server which fails to send all blocks of data.
NCM does not ship or install TFTP server software as part of the Smarts NCM product and thus has no control of the configuration of the TFTP server.
In some cases, NCM will report pull config jobs as complete even though the config viewable in NCM is not complete. This can be seen where there is a final entry in the config file, 'meout' (timedout):
The logs however show that NCM received a 'Complete' response from the pull config job ($VOYENCE_HOME/logs/commmgr.log):
5012/pull(10625311)#4: DASL: 02: Configuration Scripts Menu
5012/pull(10625311)#4: DASL: 03: ==========================================================================
5012/pull(10625311)#4: DASL: 04:
5012/pull(10625311)#4: DASL: 05: A) TFTP Host Address 10.11.12.13
5012/pull(10625311)#4: DASL: 06:
5012/pull(10625311)#4: DASL: 07: B) Filename 12345_config.pull
5012/pull(10625311)#4: DASL: 08:
5012/pull(10625311)#4: DASL: 09: C) TFTP Timeout 30 sec
5012/pull(10625311)#4: DASL: 10:
5012/pull(10625311)#4: DASL: 11: D) Retrieve File
5012/pull(10625311)#4: DASL: 12:
5012/pull(10625311)#4: DASL: 13: E) Send File Error: TFTP error
5012/pull(10625311)#4: DASL: 14:
5012/pull(10625311)#4: DASL: 15:
5012/pull(10625311)#4: DASL: 16:
5012/pull(10625311)#4: DASL: 17:
5012/pull(10625311)#4: DASL: 18:
5012/pull(10625311)#4: DASL: 19:
5012/pull(10625311)#4: DASL: 20:
Completed successfully **********************************************************
4508/ssh#1: RCV-6551>6fD) Retrieve File[13;6fE) Send File[5;28f146.32.139.39[7;28f12345_config.pul
4508/ssh#1: RCV-6551>[9;28f30 sec[11;28f[13;28fComplete
4508/ssh#1: RCV-6551>[23;41f[2K[22;41f[2K[25;80f
4508/ssh#1: ::getCurrentState - State match:[6551][(Complete)][Complete]
In this case, NCM is behaving as expected as a 'Complete' was received from the device. The partial config is down to a timeout from the TFTP server which fails to send all blocks of data.
Resolution
There are various TFTP considerations with this device type.
The MDS iNet 900 device is a radio/wireless device. The config files must be pulled through wireless and depending on setup, configuration of these devices normally prioritizes normal traffic above TFTP traffic. This means that it is not always a reliable connection for pulling configs from this device type. Because of this, TFTP timeout settings are important.
The device itself has its own configurable TFTP timeout settings, for example:
07:46:18 5012/pull(10625311)#4: DASL: 05: A) TFTP Host Address 10.11.12.13
07:46:18 5012/pull(10625311)#4: DASL: 06:
07:46:18 5012/pull(10625311)#4: DASL: 07: B) Filename 12345_config.pull
07:46:18 5012/pull(10625311)#4: DASL: 08:
07:46:18 5012/pull(10625311)#4: DASL: 09: C) TFTP Timeout 30 sec
07:46:18 5012/pull(10625311)#4: DASL: 10:
07:46:18 5012/pull(10625311)#4: DASL: 11: D) Retrieve File
07:46:18 5012/pull(10625311)#4: DASL: 12:
07:46:18 5012/pull(10625311)#4: DASL: 13: E) Send File Error: TFTP error
This can be changed as required by the device owner/admin and is outside of NCM.
Similarly, the NCM driver for this device has a 120 second timeout which is quite long to accomodate the fact that it is a wireless/radio device. This has been tested extensively and is hardcoded to the driver. This should not be a factor in this scenario.
The only other consideration is the TFTP timeout settings of the TFTP server itself. Some TFTP server packages have limited configurability and because of this, timeouts may occur.
To avoid this issue, it is recommended to review the timeout settings of your TFTP server. For instance, a TFTP server timeout of 10 seconds is not recommended. A longer timeout will most likely be required. If you encounter this type of issue, it is recommened to use packet captures (during an NCM pull config job) to review the actual timeouts so you can ammend the TFTP server settings as required.
This is not an NCM issue and must be investigated on the device itself or through the TFTP server settings.
The MDS iNet 900 device is a radio/wireless device. The config files must be pulled through wireless and depending on setup, configuration of these devices normally prioritizes normal traffic above TFTP traffic. This means that it is not always a reliable connection for pulling configs from this device type. Because of this, TFTP timeout settings are important.
The device itself has its own configurable TFTP timeout settings, for example:
07:46:18 5012/pull(10625311)#4: DASL: 05: A) TFTP Host Address 10.11.12.13
07:46:18 5012/pull(10625311)#4: DASL: 06:
07:46:18 5012/pull(10625311)#4: DASL: 07: B) Filename 12345_config.pull
07:46:18 5012/pull(10625311)#4: DASL: 08:
07:46:18 5012/pull(10625311)#4: DASL: 09: C) TFTP Timeout 30 sec
07:46:18 5012/pull(10625311)#4: DASL: 10:
07:46:18 5012/pull(10625311)#4: DASL: 11: D) Retrieve File
07:46:18 5012/pull(10625311)#4: DASL: 12:
07:46:18 5012/pull(10625311)#4: DASL: 13: E) Send File Error: TFTP error
This can be changed as required by the device owner/admin and is outside of NCM.
Similarly, the NCM driver for this device has a 120 second timeout which is quite long to accomodate the fact that it is a wireless/radio device. This has been tested extensively and is hardcoded to the driver. This should not be a factor in this scenario.
The only other consideration is the TFTP timeout settings of the TFTP server itself. Some TFTP server packages have limited configurability and because of this, timeouts may occur.
To avoid this issue, it is recommended to review the timeout settings of your TFTP server. For instance, a TFTP server timeout of 10 seconds is not recommended. A longer timeout will most likely be required. If you encounter this type of issue, it is recommened to use packet captures (during an NCM pull config job) to review the actual timeouts so you can ammend the TFTP server settings as required.
This is not an NCM issue and must be investigated on the device itself or through the TFTP server settings.
Feedback
Yes
No
Powered by
