#CLIGAPFinder

This script helps in finding the CLI configs that do not have
equivalent yang model(s) in either Cisco Native or Openconfig.

Requirements:
    1.Script requires ncclient library. 
        Install using "pip install ncclient"        
        Verify using "pip list | grep ncclient" 
    
    2.Script requires a router to be connected.  
        Basic Config required on the router: telnet, management ip, netconf, ssh.
        Verify using "ssh [email protected] -p <netconf port> -s netconf" for ipv4 router.
                  "ssh -6 [email protected] -p <netconf port> -s netconf" for ipv6 router.
        Example: "ssh [email protected] -p 830 -s netconf"
      
Script Usage: 
   "python cli_to_model_coverage_gap.py --host [<host address>] --netconfport [<NetConf Port>] 
   --telnetport [<Telnet Port>] --clifile [<CLI Configuration File>] --username [<login username>]
   --password [<loging password>]  --models [<native | openconfig>]".

Input
    The input CLI Configuration to the script can be given in a file or  
    can be given interactively through the console. 
    For interactive mode, remove the "--clifile" argument.
    The CLI Config in a file/interactive should contain "commit" at the end.
   
    The argument "models" takes either "native" or "openconfig" as its value.
    "native" identifies the corresponding model in Cisco Native Models and
    similarly for "openconfig".
    
Webex recording - Demo:
    https://cisco.webex.com/ciscosales/ldr.php?RCID=55f36c48e535955462be7103f10e8e0e
    Password - yMjscat6
    
Output:
    The Yang Models corresponding to the CLI configurations along with 
    any uncovered configurations are displayed.      

    File: model_log.xml contains the XML request related to the CLI config.
    File: uncovered_cli.txt contains the CLI which doesnt have equivalent yang.
    
Working of the script: 
    1.Existing configuration on the router is retrieved using Netconf, 
    2.CLI configurations are applied on the router using telnet and response of 
      show running-config is stored, 
    3.Configuration is again retrieved using Netconf,
    4.Router is reverted to the original configuration,
    5.Netconf Request (which contains just the XML related to CLI configurations) 
      is sent and response of show running-config is stored, 
    6.Router is reverted to original configuration,
    7.Response obtained in 2,5 is validated.