>Since I have seen a few ietf drafts for YANG models on this list I figured it would be good place to ask the following:
> Do we have any software that could convert a "show run" cli text file into a collection of yang data models (Both OpenConfig and Cisco provided models)?
> The use case:
> Cisco TAC analyzes 1000's of "show techs" from hundreds of customers and devices each day. We have an automated infrastructure that looks for misconfigurations, bugs, hardware issues etc. Each of theses checks is a 'module' and each module needs to take the text file and screen scrape out config and state. With that they can do an specific check for one thing (example "see if IPSec esp aes-gcm is configured on an asr1006 using ESP40, not supported") and generate an alert for this.
> It would be nice if we could take the cli and convert it to YANG data models such that each module doesn't have to do the text to data structure conversion. We did this kind of translation using a python module https://techzone.cisco.com/t5/BDB-App-Store-Scripts/IOS-Configuration-Library/ta-p/805705 but it is very limited, focused only on Cisco CLI and isn't super portable outside of our current automation infrastructure. Ideally it would be good to operate on these modules rather than on the text file itself.
> -Jay Young
> Hi Jay,
> I do not believe you should target to "convert" a cli configuration instances into a YANG model, these are two completely different spaces. The YANG model is the "schema" of the configuration. I believe what you want is to take a device configuration and convert it into some different encoding (such as XML or JSON) that corresponds to a set of YANG modules.
> The issue is that you need to create this translation of schemas between whatever you have for CLI and YANG. This is not easy unless you let the device to do it itself.
> So, what you can do is to take the "show running" and apply it to a device to then read it via NETCONF/RESTCONG using XML/ JSON encoding. This is basically what our NSO NED does but we use Tail-f modules and not the OpenConfig/Cisco modules.
Shouldn't you be able to use the Tail-F tools to do what you want ?
Not up to date on the state of confD in IOS-XE, but if you just use NSO, that should have CLI parsing and model representation of a subset of IOS config CLI. This is called the NID? if i remember correctly.
I am just not up to speed on the process of how this gets extended (who, when, and why), and whats the likelyhood that it would cover all of Cisco IOS-CLI to the extend that it would be useful for you.
I agree getting the actual router to do that conversion you ask for is the best way to go. It means changing the implementation of ‘show tech’ to get the netconf representation of the config as well.
However there is something that gets you part of the way to what you want without changing show tech. Instead of generating the parsed config based on openconfig+cisco models, you can parse based on the NSO model used to represent CLI config. These provide less abstraction, but you still get a good python API to traverse the config without any regexp/screen scraping code. (BTW I think this is what Toerless is suggesting). The coverage of the cli NEDs is quite extensive but I’m sure you will encounter commands you need that are not covered. Changing a NED to add a command is not very difficult or long.
To do the above you use netsim. This is a very small device simulator built using the models in the CLI NED, you can connect to it with ssh, and set its config from the show tech (it won’t complain about non existent interfaces). NSO can then connect to netsim via ssh and do sync-from, so the NED will convert the cli config into its model. You could create/destroy a netsim simulator for each ‘show tech’ and then keep the parsed results in the NSO database.
Thank you all for the replies.
1) I hadn’t thought about just having the xml (or even a compressed version of it) included in the show tech. This would make things much easier for devices supporting the netconf/restconf + yang models within our automation platform.. I’ll follow up with the other technical leads from within Services to see if we can get this integrated.
2) This ‘netsim’ program/service sounds pretty much what I was hinting at. Take a ‘show run’/‘show tech’ from a legacy box and get the xml/json data representation of the config. Do you have any pointers for more information?
3) From this discussion it sounds like these Tail-F NSO models were developed prior or parallel to the OpenConfig models but has better coverage over the CLI. Do you have any other pointers for information about NSO and NED.
Thank you all,
Tailf NSO or netsim will not allow you to receive show tech data formatted response data. You could extend the tailf “Network Element Driver” or ned model to implement the show tech CLI commands, and cause the commands to be sent to the device, but the response data would not be available in a form defined by an operational data YANG model. For example the ned model could be extended to allow executing the commands under here:
3850-48a#show tech ?
cef CEF related information
cft CFT related information
eigrp EIGRP related information
ethernet Ethernet protocols related information
evc EVC related information
fnf Flexible Netflow information
ipc IPC related information
ipmulticast IP multicast related information
ipsec IPSEC related information
isis CLNS and ISIS related information
mfib MFIB related information
mpls MPLS forwarding and application related information
msrp MSRP related information
nat NAT related information
nbar NBAR related information
onep ONEP related information
ospf OSPF related information
page Page through output
password Include passwords
rsvp IP RSVP related information
subscriber Subscriber related information
vrrp VRRP related information
wccp WCCP related information
wireless Wireless related information
| Output modifiers
This could allow you to send NETCONF or RESTCONF commands to the device to cause execution of the show tech operation, however the show tech output data would not be returned by the model-based interface.
In the current implementation of NETCONF in Polaris 16.3, to get the show tech response data returned as structured NETCONF or RESTCONF responses, you would have to write “show tech” operational data YANG model to define the structure for the show tech response data. You would also write a “show tech stream parser” which would execute the “show tech” command, e.g. “show tech cef” and would parse the response data into a JSON representation which is then loaded into the confd operational data cache. In effect, perform screen scraping inside the device.
NETCONF and RESTCONF management applications could then perform GET operations to read the show tech data in structured form defined by the YANG model. For example you would create a cisco-showtech-cef.yang” model to define the structure for the response data. You would create a “parse.showTechCef.sh” stream parser (awk/sed script) that would execute the show tech command, parse the response data, and put the data into the confd operational data cache.
At this time there are no plans to implement show tech operational data models for the current Polaris 16.3 or 16.4 model-based interfaces.
Going forward, the plan is that all feature code operational data processing will be re-written to put operational data into the Crimson data store. NETCONF and RESTCONF management applications would perform GET operations and the data would be accessed from the Crimson datastore instead of being provided using the current Polaris 16.3/16.4 operational data infrastructure.
I don’t believe there are plans at this time to implement show tech command data in future Polaris releases.
For information on commitments for implementation of operational data including show tech data and the plan for implementation of Crimson-based operational data, please contact Gabor.
/Peter Van Horne