CISCO-COPY-CONIFG MIB / specifying tftp source interface

[stuartkendrick]

I use CISCO-COPY-CONFIG MIB variables to manipulate config files, e.g. saving them to a remote archive.

The work-flow looks something like this:

snmpset -c private {host name} ccCopyEntryRowStatus.12345 i 5 (createAndWait)

snmpset -c private {host name} ccCopyProtocol.12345 i 1 (tftp)

snmpset -c private {host name} ccCopySourceFileType.12345 i 4 (running-config)

snmpset -c private {host name} ccCopyDestFileType.12345 i 1 (networkFile)

snmpset -c private {host name} ccCopyServerAddress.12345 1 10.1.2.3

snmpset -c private {host name} ccCopyFileName.12345 s host-name-confg

snmpset -c private {host name} ccCopyEntryRowStatus.12345 i 1 (active)

This works fine ... except that I have some Nexus boxes on which the mgmt0 interface is not operational -- we haven't delivered a physical connection to the management port.  And on these boxes, the work-flow above fails, i..e

snmpget -c private {host name} ccCopyState.12345

'failed'

snmpget -c private {host name} ccCopyFailCause.12345

'unknown'

On investigation, I am beginning to believe that CISCO-COPY-CONFIG insists on using 'interface mgm0t' as the source of the tftp copy

Is there a way to instruct CISCO-COPY-CONFIG to use some interface other than 'interface mgmt0' as the source for the tftp transaction?

I have tried:

- administratively shutting down 'interface mgmt0'

- deleting 'vrf context management' (the CLI won't let me)

- removing 'interface mgmt0' from 'vrf context management' (the CLI won't let me)

- specifying "ip tftp source-interface loopback0" and "ip tftp source-interface {some vlan interface}"

- poking through CISCO-CONFIG-COPY MIB, looking for a way to specify a source VRF (I would specify 'vrf default') -- I don't see such a variable.

--sk

[Palani Mohan]

Hi Stuart

Specifying which source interface is usually outside the scope of the SNMP part of the code, I feel. Which interface to use, for outgoing pkts is a decision of the routing infrastructure code within the OS, I feel. I say so because if the IP/routing code is going to let SNMP code to decide which interface to use, it would be ad-hoc (sorta like using static routing rather than use a dynamic routing protocol) and does not scale.

From a NMS server viewpoint, being a end-host, I don't see it capable of understanding VRFs.

I feel that specifying which source interface to use for TFTP should do it but then, you mentioned that you tried and it is not working. Please consider copying config file using TFTP from CLI. If successful, capture pkts to see what source interface is being used for this session. Now, proceed to specify source-interface explicitly. If it works, validate if the selected interface is indeed the source interface in the packet capture.

If CLI is successful and copy via SNMP is failing, to me, it looks like a bug. What OS version are you using?

Kind regards ... Palani

[stuartkendrick]

Here is additional information.

From the CLI, I see the following.

dc-b-rtr# copy running-config tftp://config-server//cisco/dc-b-rtr-confg vrf default
Trying to connect to tftp server......
Connection to Server Established.
                                                                                
TFTP put operation was successful
Copy complete.
dc-b-rtr#

A pcap take on config-server shows the tftp transaction sourced from the IP address of the interface on dc-b-rtr which is 'closest' routing-wise to config-server.

dc-b-rtr# copy running-config tftp://config-server//cisco/dc-b-rtr-config vrf management
Trying to connect to tftp server......
Could not connect to tftp server:No route to host
dc-b-rtr#

A pcap taken on config-server shows zero 'tftp' frames

==> These results are unsurprising.

When I use the SNMP Set method as described above, dc-b-rtr logs the following:

2017-02-24T09:33:41.868438-08:00 dc-b-rtr : 2017 Feb 24 09:33:35.846 pst: %AAA-6-AAA_ACCOUNTING_MESSAGE: update:snmp_38087_a.b.c.d:********:copy running-config tftp://{a.b.c.d}:69/cisco/dc-b-rtr-auto-save-5366rUva vrf management (FAILURE)

The file name & path are unsurprising -- I set those.  What is suggestive though ... is the 'vrf management' string.  I did not set this.  And I see no way to set it, using variables in CISCO-COPY-MIB.

This is why I believe that, for the purposes of CISCO-COPY-MIB, operations live entirely within the 'management vrf' context.  Or, minimally, that the SNMP agent adds 'vrf management' to any copy config operation.

Would you concur?  Or do you see a hole in my reasoning?

--sk

[Palani Mohan]

Hi Stuart

Citing below the snippet of what you observed:

A pcap take on config-server shows the tftp transaction sourced from the IP address of the interface on dc-b-rtr which is 'closest' routing-wise to config-server.

Given this, if you were to specify ip tftp source-interface where the variable is the interface name associated with the source ipAddress closest to the config-server, I expect the TFTP to be successful.

If not, that would point to a bug in your release. The MIB predates the wide-spread use of VRFs and so, I don't expect the MIB to change. Cisco's direction seem to be pointing towards using ip <controlPlanProtocolName> source-interface. These are what I observed, to suggest using an explicit ip tftp source-interface cmd.

Sincerely .... Palani

[stuartkendrick]

Ah, I see, I hadn't grasped your initial comment completely.

dc-b-rtr# sh run | include tftp
ip tftp source-interface loopback0
dc-b-rtr#sh run int loopback0

interface loopback0
  ip address a.b.c.d/32
  ip router ospf xx area 0.0.0.0

dc-b-rtr#

Interestingly, when I then try the SNMP Set, I see the same log message.

2017-02-24T10:51:11.626657-08:00 dc-b-rtr : 2017 Feb 24 10:51:05.596 pst: %AAA-6-AAA_ACCOUNTING_MESSAGE: update:snmp_55925_a.b.c.d:********:copy running-config tftp://a.b.c.d:69/cisco/dc-b-rtr-auto-save-xBDpwE7e vrf management (FAILURE)

That surprises me -- at this point, I would have predicted as you did, that this would succeed.

I have tried:

* Specifying the tftp source interface as the same interface used when I successfully copy via the CLI

* Shutting down mgmt0

Same results, i.e. "vrf management (FAILURE)" in syslog

I am headed toward filing a bug with TAC.  Let me know if you have other direction to offer.

--sk

[Palani Mohan · Accepted solution]

Hi Stuart

Refreshed the original post and realized you have a Nexus box. From what I am finding, you need to do either of the following:

Few more things to give it a shot:
!
ip tftp source-interface Loopback0 vrf default
!

The cmd reference guide does not mention anything about configurable options after interface name. So, please consider issuing

ip tftp source-interface Loopback0 ?

and share what you see.

The other possible answer is either of the following two config. These are unique to Nexus-OS implementation alone.

snmp-server context TEST vrf default
snmp-server community copyconfig rw
snmp-server mib community-map copyconfig context TEST

OR

snmp-server context TEST vrf default

NOTE: If you choose to go this route, then you need to specify the context along with the community string.
snmpset -v 2c -c copyconfig@TEST 10.10.10.1 ccCopyEntryRowStatus.507 i 5

NOTE
In all of the above, I attempted to use default as the VRF that has IP connectivity to the TFTP-Server. If the name is different, please replace

Sincerely ... Palani

[stuartkendrick]

ip tftp source-interface loopback0 vrf default

Same failure:

2017-02-24T14:06:48.443386-08:00 dc-b-rtr : 2017 Feb 24 14:06:42.389 pst: %AAA-6-AAA_ACCOUNTING_MESSAGE: update:snmp_57844_a.b.c.d:********:copy running-config tftp://a.b.c.d:69/Cisco/dc-b-rtr-auto-save-DddLgP_b vrf management (FAILURE)

The snmp-server approach will take me longer to test, haven't tried it yet.

--sk

[Michal Mihaly]

Hello Palani, Stuart,

thank you for this post, it helped me clarify the issue I was facing. However my question is if Cisco is considering allowing different L3 interface as a tftp source rather than a loopback. Reason why I need that is that we have many occasions when the nexus is L2 only (ergo trunk to the uplink switches) and the mgmt must be provided via VLAN SVI as inbound manner.

We run: 5.2(1)N1(8b) at this moment

Thank you

Michal