Hi Carl, you can find a list of commands run for each commandType in the docs here https://fwd.app/docs/nqe/data-model/type_commandtype/. It doesn’t look like this is a command we associate with commandType, but you can add it as a custom command to reference it in NQE. 

Are you saying that there normal collection commands that we cannot use as a commandType?

I ask as the output is exactly like the syntax of ‘show ip nat statistics’ so the data is coming from somewhere in the normal collection.  I am actually not sure how you could infer some of the information without that specific command on a Cisco device.

I do not want to add custom command if at all possible for the 12k+ devices if we already have the information.  Also will have to wait for another cycle to get information - snapshots and processing takes too long and causes some organizational angst. 

​@CarlB Not all state files (think standard collection commands) are available as a CommandType. It is good to do a short query like this to check which CommandTypes are available for the device you are interested in.

foreach device in network.devices
where device.name == "{put device name here}"
foreach command in device.outputs.commands
select {
  Device: device.name,
  Commands: command.commandType
  }

it is confusing that the state files have names that do not match the show commands.  I believe that is to try and have a “normalized” state file name.  That what is represented would be the same no matter the vendor.

Some state files a explicitly not available to NQE for parsing, because the data is already parsed into the data model.

​@CarlB What data would you want out of that show command?  We can submit a plan to get that command added to CommandType.

​@Tyson Henrie - took a look at the Cisco show ip nat statistics, from the output:

Total active translations: 430 (77 static, 353 dynamic; 353 extended)
Outside interfaces:
  GigabitEthernet0/1/0, GigabitEthernet0/2/0.51
Inside interfaces: 
  GigabitEthernet0/0/0
Hits: 2147956779  Misses: 8687207
Expired translations: 8686854
Dynamic mappings:
-- Inside Source
eId: 0] route-map RM-CLIENT-2-DEST1
1Id: 0] route-map RM-CLIENT-2-DEST2
2Id: 0] route-map RM-DC-2-CUST 
�Id: 0] route-map RM_NAT2 
nat-limit statistics:
 max entry: max allowed 0, used 0, missed 0
In-to-out drops: 1  Out-to-in drops: 0
Pool stats drop: 0  Mapping stats drop: 0
Port block alloc fail: 0
IP alias add fail: 0
Limit entry add fail: 0

honestly pretty much every field/number above the dynamic mappings are important - currently on an issue that the misses/expired is the thumbprint of a lingering issue that we are suspecting is much larger than we thought.

The active/static/dynamic translations are really important for benchmarking as well as when we do maintenance/changes - the obvious drop to 0 is a bad sign however watching the ebb/flow is something we do normally in troubleshooting/implementations.

Nat-limit statistics /max/alowed/used is a fingerprint of a different issue ongoing - basically each chassis handled max translations differently, and we have seen systems go over the limit (and need manual upgrades).

in-out and out-in drops are also fingerprints of a problem so I can see a NQE looking at the enterprise to try to spot systems going south before the impact is too noticeable.

Thank you Carl.  This is great justification to add to a JIRA ticket.  I already created a PLAN to make this command available to NQE.