├── .gitignore ├── .virlrc ├── 01-installing-nso.md ├── 02-connecting-to-network.md ├── 03-exploring-with-cli.md ├── 04a-mvu.md ├── 04b-mvu.md ├── 04c-mvu.md ├── 99-cleanup.md ├── LICENSE ├── README.md ├── example-network-sm.jpeg ├── example-network.jpg ├── nso-instance ├── .gitignore ├── Makefile └── lab-configs │ ├── device-groups.cfg │ └── nso-inventory.cfg ├── sbx-reserve-1.jpg └── topology.virl /.gitignore: -------------------------------------------------------------------------------- 1 | .virl/ 2 | scratch* 3 | nso-network-prep/ 4 | .vscode/ 5 | *.code-workspace 6 | 7 | # NSO 8 | logs/ 9 | ncs-cdb/ 10 | packages/ 11 | scripts/ 12 | state/ 13 | test/ 14 | ncs.conf 15 | README.ncs 16 | cisco-asa* 17 | cisco-nx* 18 | cisco-ios* 19 | cisco-ucs* 20 | storedstate 21 | 22 | netsim/ 23 | 24 | 25 | # Byte-compiled / optimized / DLL files 26 | __pycache__/ 27 | *.py[cod] 28 | *$py.class 29 | 30 | # C extensions 31 | *.so 32 | 33 | # Distribution / packaging 34 | .Python 35 | build/ 36 | develop-eggs/ 37 | dist/ 38 | downloads/ 39 | eggs/ 40 | .eggs/ 41 | lib/ 42 | lib64/ 43 | parts/ 44 | sdist/ 45 | var/ 46 | wheels/ 47 | pip-wheel-metadata/ 48 | share/python-wheels/ 49 | *.egg-info/ 50 | .installed.cfg 51 | *.egg 52 | MANIFEST 53 | 54 | # PyInstaller 55 | # Usually these files are written by a python script from a template 56 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 57 | *.manifest 58 | *.spec 59 | 60 | # Installer logs 61 | pip-log.txt 62 | pip-delete-this-directory.txt 63 | 64 | # Unit test / coverage reports 65 | htmlcov/ 66 | .tox/ 67 | .nox/ 68 | .coverage 69 | .coverage.* 70 | .cache 71 | nosetests.xml 72 | coverage.xml 73 | *.cover 74 | *.py,cover 75 | .hypothesis/ 76 | .pytest_cache/ 77 | 78 | # Translations 79 | *.mo 80 | *.pot 81 | 82 | # Django stuff: 83 | *.log 84 | local_settings.py 85 | db.sqlite3 86 | db.sqlite3-journal 87 | 88 | # Flask stuff: 89 | instance/ 90 | .webassets-cache 91 | 92 | # Scrapy stuff: 93 | .scrapy 94 | 95 | # Sphinx documentation 96 | docs/_build/ 97 | 98 | # PyBuilder 99 | target/ 100 | 101 | # Jupyter Notebook 102 | .ipynb_checkpoints 103 | 104 | # IPython 105 | profile_default/ 106 | ipython_config.py 107 | 108 | # pyenv 109 | .python-version 110 | 111 | # pipenv 112 | # According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. 113 | # However, in case of collaboration, if having platform-specific dependencies or dependencies 114 | # having no cross-platform support, pipenv may install dependencies that don't work, or not 115 | # install all needed dependencies. 116 | #Pipfile.lock 117 | 118 | # PEP 582; used by e.g. github.com/David-OConnor/pyflow 119 | __pypackages__/ 120 | 121 | # Celery stuff 122 | celerybeat-schedule 123 | celerybeat.pid 124 | 125 | # SageMath parsed files 126 | *.sage.py 127 | 128 | # Environments 129 | .env 130 | .venv 131 | env/ 132 | venv/ 133 | ENV/ 134 | env.bak/ 135 | venv.bak/ 136 | 137 | # Spyder project settings 138 | .spyderproject 139 | .spyproject 140 | 141 | # Rope project settings 142 | .ropeproject 143 | 144 | # mkdocs documentation 145 | /site 146 | 147 | # mypy 148 | .mypy_cache/ 149 | .dmypy.json 150 | dmypy.json 151 | 152 | # Pyre type checker 153 | .pyre/ 154 | -------------------------------------------------------------------------------- /.virlrc: -------------------------------------------------------------------------------- 1 | VIRL_HOST=10.10.20.160 2 | VIRL_USERNAME=guest 3 | VIRL_PASSWORD=guest 4 | -------------------------------------------------------------------------------- /01-installing-nso.md: -------------------------------------------------------------------------------- 1 | # Installing Cisco NSO 2 | As with any piece of software, before you can use it, you must install it. Let's run through what that takes! 3 | 4 | ## Where to get the code? 5 | Cisco makes NSO available for anyone to use and try in a non-production use completely free on [DevNet](https://developer.cisco.com). Head on over to [https://developer.cisco.com/docs/nso/#!getting-nso](https://developer.cisco.com/docs/nso/#!getting-nso) and download the version you need. 6 | 7 | ## Pre-requisites 8 | ### Operating System 9 | Cisco NSO can run on macOS or on Linux systems. If you are a Window's user (or if you don't wish to install it natively on your laptop), you can install NSO on a Linux virtual machine. For small lab networks you'll only need a single vCPU and 2-4 GB of RAM. If you use Vagrant to manager local Linux virtual machines, there is a NSO Vagrant file as well: [https://github.com/NSO-developer/nso-vagrant](https://github.com/NSO-developer/nso-vagrant). 10 | 11 | NSO also runs quite well within Docker Containers, and you can find resources for that at [gitlab.com/nso-developer/nso-docker](https://gitlab.com/nso-developer/nso-docker). 12 | 13 | ### Java 14 | NSO requires Java to be installed to function. Any method of installing Java should work, but here are some simple methods. 15 | 16 | * macOS 17 | * [Homebrew](https://formulae.brew.sh/cask/java#default) - `brew cask install java` 18 | * Linux 19 | * With `apt` - `apt install default-jre` 20 | * With `yum` - `yum install java-1.8.0-openjdk` 21 | 22 | ### Apache Ant 23 | [Apache Ant](https://ant.apache.org/) is a Java library and tool for building files and other dependencies. You'll need to install it as well. Here are some ways to do so. 24 | 25 | * macOS 26 | * [Homebrew](https://formulae.brew.sh/formula/ant#default) - `brew install ant` 27 | * Linux 28 | * With `apt` - `apt install ante` 29 | * With `yum` - `yum install ant` 30 | 31 | 32 | ## Local vs System Installation 33 | Before you install NSO onto your system, you need to decide whether to do a "System" or "Local" installation. Here's a simple breakdown of the two. 34 | 35 | * **System Install** is used when installing NSO for a centralized, "always-on", production grade purpose. Is configured as a system daemon that would start and end with the underlying operating system. 36 | * **Local Install** is used for development, lab, and evaluation purposes. It unpacks all the application components, including docs and examples, and allows the user to instantiate and start instances of NSO on demand. A Local Install on a single workstation can be used by the engineer to run multiple, unrelated instances of NSO for different labs and demos. 37 | 38 | As we are just getting started, we'll be using a "Local Installation" of NSO. 39 | 40 | ## Performing a Local Installation 41 | Once you've installed the pre-reqs and downloaded the NSO installation file for your operating system, you are ready to do your installation. 42 | 43 | 1. Open up a terminal and navigate to the directory where you downloaded the installer. 44 | 45 | ```bash 46 | cd ~/Downloads 47 | ll nso*.bin 48 | -rw-r--r--@ 1 hapresto staff 199M Dec 15 11:45 nso-5.3.darwin.x86_64.installer.bin 49 | -rw-r--r--@ 1 hapresto staff 199M Dec 15 11:45 nso-5.3.darwin.x86_64.signed.bin 50 | ``` 51 | 52 | > If your file is a `signed.bin` file, this means that the file you downloaded has been digitally signed by Cisco, and when you execute it you'll verify the signature and unpack the `installer.bin`. If you have the `installer.bin` skip down past the `signed` steps. 53 | 54 | 1. First step, you need to make the file you downloaded "executable". 55 | * *Your file name may be different, just update appropriately.* 56 | 57 | ```bash 58 | chmod +x nso-5.3.darwin.x86_64.signed.bin 59 | 60 | ll nso-5.3.darwin.x86_64.signed.bin 61 | -rwxr-xr-x@ 1 hapresto staff 199M Dec 15 11:45 nso-5.3.darwin.x86_64.signed.bin 62 | ``` 63 | 64 | 1. Now go ahead and "run" the `signed.bin` to verify the certificate and extract the files. 65 | 66 | ```bash 67 | ./nso-5.3.darwin.x86_64.signed.bin 68 | 69 | # Output 70 | Unpacking... 71 | Verifying signature... 72 | Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ... 73 | Successfully downloaded and verified crcam2.cer. 74 | Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ... 75 | Successfully downloaded and verified innerspace.cer. 76 | Successfully verified root, subca and end-entity certificate chain. 77 | Successfully fetched a public key from tailf.cer. 78 | Successfully verified the signature of nso-5.3.darwin.x86_64.installer.bin using tailf.cer 79 | ``` 80 | 81 | 1. If it all comes back green, you're in good shape and ready to install. First let's see what was unpacked. 82 | 83 | ```bash 84 | ll 85 | 86 | # Output 87 | -rw-r--r-- 1 hapresto staff 1.8K Nov 29 06:05 README.signature 88 | -rw-r--r-- 1 hapresto staff 12K Nov 29 06:05 cisco_x509_verify_release.py 89 | -rwxr-xr-x 1 hapresto staff 199M Nov 29 05:55 nso-5.3.darwin.x86_64.installer.bin 90 | -rw-r--r-- 1 hapresto staff 256B Nov 29 06:05 nso-5.3.darwin.x86_64.installer.bin.signature 91 | -rwxr-xr-x@ 1 hapresto staff 199M Dec 15 11:45 nso-5.3.darwin.x86_64.signed.bin 92 | -rw-r--r-- 1 hapresto staff 1.4K Nov 29 06:05 tailf.cer 93 | ``` 94 | 95 | 1. In addition to the `signed.bin` file you started with, you'll now have: 96 | * `README.signature` - details on the verification 97 | * `cisco_x509_verify_release.py` - Python script to verify the file 98 | * `nso-5.3.darwin.x86_64.installer.bin` - the NSO installation file 99 | * `nso-5.3.darwin.x86_64.installer.bin.signature` - the signature file for the installer 100 | * `tailf.cer` - public cert for verification 101 | 102 | 1. First, checkout the `--help` on the installer. Notice the two options for `--local-install` or `--system-install` 103 | 104 | ```bash 105 | ./nso-5.3.darwin.x86_64.installer.bin --help 106 | 107 | # Output 108 | This is the NCS installation script. 109 | 110 | Usage: ./nso-5.3.darwin.x86_64.installer.bin [--local-install] LocalInstallDir 111 | 112 | Installs NCS in the LocalInstallDir directory only. 113 | This is convenient for test and development purposes. 114 | 115 | Usage: ./nso-5.3.darwin.x86_64.installer.bin --system-install [--install-dir InstallDir] 116 | [--config-dir ConfigDir] [--run-dir RunDir] [--log-dir LogDir] 117 | [--run-as-user User] [--keep-ncs-setup] [--non-interactive] 118 | 119 | Does a system install of NCS, suitable for deployment. 120 | Static files are installed in InstallDir/ncs-. 121 | The first time --system-install is used, the ConfigDir, 122 | RunDir, and LogDir directories are also created and 123 | populated for config files, run-time state files, and log files, 124 | respectively, and an init script for start of NCS at system boot 125 | and user profile scripts are installed. Defaults are: 126 | 127 | InstallDir - /opt/ncs 128 | ConfigDir - /etc/ncs 129 | RunDir - /var/opt/ncs 130 | LogDir - /var/log/ncs 131 | 132 | By default, the system install will run NCS as the root user. 133 | If the --run-as-user option is given, the system install will 134 | instead run NCS as the given user. The user will be created if 135 | it does not already exist. 136 | 137 | If the --non-interactive option is given, the installer will 138 | proceed with potentially disruptive changes (e.g. modifying or 139 | removing existing files) without asking for confirmation. 140 | ``` 141 | 142 | 1. For the installation directory or `LocalInstallDir`, the recommendation is to install it into your $HOME directory into a folder called `~/nso-VERSION`. So if our version is `5.3`, our directory will be `~/nso-5.3`. 143 | 1. Run the installer with this directory. 144 | 145 | ```bash 146 | ./nso-5.3.darwin.x86_64.installer.bin --local-install ~/nso-5.3 147 | 148 | # Output 149 | INFO Using temporary directory /var/folders/90/n5sbctr922336_0jrzhb54400000gn/T//ncs_installer.93831 to stage NCS installation bundle 150 | INFO Unpacked ncs-5.3 in /Users/hapresto/nso-5.3 151 | INFO Found and unpacked corresponding DOCUMENTATION_PACKAGE 152 | INFO Found and unpacked corresponding EXAMPLE_PACKAGE 153 | INFO Found and unpacked corresponding JAVA_PACKAGE 154 | INFO Generating default SSH hostkey (this may take some time) 155 | INFO SSH hostkey generated 156 | INFO Environment set-up generated in /Users/hapresto/nso-5.3/ncsrc 157 | INFO NSO installation script finished 158 | INFO Found and unpacked corresponding NETSIM_PACKAGE 159 | INFO NCS installation complete 160 | ``` 161 | 162 | 1. That's it, you're installed. 163 | 164 | ## Exploring the Installation 165 | Before we startup NSO, let's just look at what we have. 166 | 167 | Go ahead and `cd` into the new installation directory. 168 | 169 | ```bash 170 | cd ~/nso-5.3 171 | ``` 172 | 173 | ### Documentation 174 | Along with the binaries, NSO installs a full set of documentation available in the `doc/` folder. 175 | 176 | ```bash 177 | ll doc/ 178 | drwxr-xr-x 5 hapresto staff 160B Nov 29 05:19 api/ 179 | drwxr-xr-x 14 hapresto staff 448B Nov 29 05:19 html/ 180 | -rw-r--r-- 1 hapresto staff 202B Nov 29 05:19 index.html 181 | drwxr-xr-x 17 hapresto staff 544B Nov 29 05:19 pdf/ 182 | ``` 183 | 184 | Feel free to open up the `index.html` file in your favorite browser and poke around. You'll find installation, admin, user, development, and more guides available for you to jump right into. 185 | 186 | ### Examples 187 | An NSO Local Install also comes with **A LOT** of examples of a variety of different types of ways you can use NSO. Many of these touch on advanced topics, but there are plenty of basic ones as well. 188 | 189 | ```bash 190 | ll examples.ncs/ 191 | 192 | # Output 193 | -rw-r--r-- 1 hapresto staff 1.0K Nov 29 05:17 README 194 | drwxr-xr-x 4 hapresto staff 128B Nov 29 04:50 datacenter/ 195 | drwxr-xr-x 3 hapresto staff 96B Nov 29 04:50 generic-ned/ 196 | drwxr-xr-x 4 hapresto staff 128B Nov 29 04:50 getting-started/ 197 | drwxr-xr-x 7 hapresto staff 224B Nov 29 04:50 service-provider/ 198 | drwxr-xr-x 3 hapresto staff 96B Nov 29 04:50 snmp-ned/ 199 | drwxr-xr-x 11 hapresto staff 352B Nov 29 05:17 snmp-notification-receiver/ 200 | drwxr-xr-x 5 hapresto staff 160B Nov 29 04:50 web-server-farm/``` 201 | ``` 202 | 203 | ### NEDs or Network Element Drivers 204 | In order to "talk to" the network, NSO uses NEDs. Cisco has NEDs for hundreds of different devices available for customers, and several are included in the installer. Let's see what they are. 205 | 206 | ```bash 207 | ll 208 | 209 | # Output 210 | drwxr-xr-x 13 hapresto staff 416B Nov 29 05:17 a10-acos-cli-3.0/ 211 | drwxr-xr-x 12 hapresto staff 384B Nov 29 05:17 alu-sr-cli-3.4/ 212 | drwxr-xr-x 13 hapresto staff 416B Nov 29 05:17 cisco-asa-cli-6.6/ 213 | drwxr-xr-x 12 hapresto staff 384B Nov 29 05:17 cisco-ios-cli-3.0/ 214 | drwxr-xr-x 12 hapresto staff 384B Nov 29 05:17 cisco-ios-cli-3.8/ 215 | drwxr-xr-x 13 hapresto staff 416B Nov 29 05:17 cisco-iosxr-cli-3.0/ 216 | drwxr-xr-x 13 hapresto staff 416B Nov 29 05:17 cisco-iosxr-cli-3.5/ 217 | drwxr-xr-x 13 hapresto staff 416B Nov 29 05:17 cisco-nx-cli-3.0/ 218 | drwxr-xr-x 13 hapresto staff 416B Nov 29 05:17 dell-ftos-cli-3.0/ 219 | drwxr-xr-x 10 hapresto staff 320B Nov 29 05:17 juniper-junos-nc-3.0/ 220 | ``` 221 | 222 | Here you can see there are NEDs for Cisco ASA, IOS, IOS XR, and NX-OS. Also included are NEDs for other vendors including Juniper JunOS, A10, ALU and Dell. 223 | 224 | > Note: The NEDs included in the installer are intended for evaluation, demonstration, and used with the included `examples.ncs` that are also included. These are not the latest versions available, and often don't have all the features available in production NEDs. 225 | 226 | #### Installing New NED Versions 227 | Cisco also makes additional versions of some NEDs available on DevNet for evaluation and non-production use. You can find them with the NSO downloads [here](https://developer.cisco.com/docs/nso/#!getting-nso). 228 | 229 | For this getting started lab we'll be leveraging Cisco IOS, NX-OS and ASA devices. Go ahead and download the updated NEDs from DevNet and we'll install them now! 230 | 231 | > NOTE: the specific file names and versions you download maybe different from this guide. Update the paths appropriately. 232 | 233 | 1. Like the NSO installer, the NEDs are signed bin files that need to be run to validate the download and extract the new code. 234 | 235 | 1. First, let's see the downloaded files - update the path for where your downloads are 236 | 237 | ```bash 238 | cd ~/Downloads/ 239 | ls -l ncs*.bin 240 | 241 | # Output 242 | -rw-r--r--@ 1 hapresto staff 9708091 Dec 18 12:05 ncs-5.3-cisco-asa-6.7.7.signed.bin 243 | -rw-r--r--@ 1 hapresto staff 51233042 Dec 18 12:06 ncs-5.3-cisco-ios-6.42.1.signed.bin 244 | -rw-r--r--@ 1 hapresto staff 8400190 Dec 18 12:05 ncs-5.3-cisco-nx-5.13.1.1.signed.bin 245 | ``` 246 | 247 | 1. Now make them "executable" 248 | 249 | ```bash 250 | chmod +x ncs*.bin 251 | ls -l ncs*.bin 252 | ``` 253 | 254 |
Output - now executable 255 | 256 | ```bash 257 | -rwxr-xr-x@ 1 hapresto staff 9708091 Dec 18 12:05 ncs-5.3-cisco-asa-6.7.7.signed.bin 258 | -rwxr-xr-x@ 1 hapresto staff 51233042 Dec 18 12:06 ncs-5.3-cisco-ios-6.42.1.signed.bin 259 | -rwxr-xr-x@ 1 hapresto staff 8400190 Dec 18 12:05 ncs-5.3-cisco-nx-5.13.1.1.signed.bin 260 | ``` 261 | 262 |
263 | 264 | 1. Run each file. 265 | 266 | ```bash 267 | ./ncs-5.3-cisco-nx-5.13.1.1.signed.bin 268 | ``` 269 | 270 |
Output 271 | 272 | ```bash 273 | Unpacking... 274 | Verifying signature... 275 | Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ... 276 | Successfully downloaded and verified crcam2.cer. 277 | Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ... 278 | Successfully downloaded and verified innerspace.cer. 279 | Successfully verified root, subca and end-entity certificate chain. 280 | Successfully fetched a public key from tailf.cer. 281 | Successfully verified the signature of ncs-5.3-cisco-nx-5.13.1.1.tar.gz using tailf.cer 282 | ``` 283 | 284 |
285 | 286 | > Repeat for all three files 287 | 288 | 1. You now have 3 tarballs (.tar.gz) files. These are compressed versions of the NEDs. 289 | 290 | ```bash 291 | ls -l ncs*.tar.gz 292 | ``` 293 | 294 |
Output 295 | 296 | ```bash 297 | -rw-r--r-- 1 hapresto staff 9704896 Dec 12 21:11 ncs-5.3-cisco-asa-6.7.7.tar.gz 298 | -rw-r--r-- 1 hapresto staff 51260488 Dec 13 22:58 ncs-5.3-cisco-ios-6.42.1.tar.gz 299 | -rw-r--r-- 1 hapresto staff 8409288 Dec 18 09:09 ncs-5.3-cisco-nx-5.13.1.1.tar.gz 300 | ``` 301 | 302 |
303 | 304 | 1. Navigate to the `packages/neds` directory for your local-install. 305 | 306 | ```bash 307 | cd ~/nso-5.3/packages/neds 308 | ``` 309 | 310 | 1. All we need to do now is extract the tarballs into this directory. 311 | 312 | > Update the path and file name for the NED versions you downloaded 313 | 314 | ```bash 315 | tar -zxvf ~/Downloads/ncs-5.3-cisco-nx-5.13.1.1.tar.gz 316 | tar -zxvf ~/Downloads/ncs-5.3-cisco-ios-6.42.1.tar.gz 317 | tar -zxvf ~/Downloads/ncs-5.3-cisco-asa-6.7.7.tar.gz 318 | 319 | ls -l 320 | ``` 321 | 322 |
Output 323 | 324 | ```bash 325 | drwxr-xr-x 13 hapresto staff 416 Nov 29 05:17 a10-acos-cli-3.0 326 | drwxr-xr-x 12 hapresto staff 384 Nov 29 05:17 alu-sr-cli-3.4 327 | drwxr-xr-x 13 hapresto staff 416 Nov 29 05:17 cisco-asa-cli-6.6 328 | drwxr-xr-x 13 hapresto staff 416 Dec 12 21:11 cisco-asa-cli-6.7 329 | drwxr-xr-x 12 hapresto staff 384 Nov 29 05:17 cisco-ios-cli-3.0 330 | drwxr-xr-x 12 hapresto staff 384 Nov 29 05:17 cisco-ios-cli-3.8 331 | drwxr-xr-x 13 hapresto staff 416 Dec 13 22:58 cisco-ios-cli-6.42 332 | drwxr-xr-x 13 hapresto staff 416 Nov 29 05:17 cisco-iosxr-cli-3.0 333 | drwxr-xr-x 13 hapresto staff 416 Nov 29 05:17 cisco-iosxr-cli-3.5 334 | drwxr-xr-x 13 hapresto staff 416 Nov 29 05:17 cisco-nx-cli-3.0 335 | drwxr-xr-x 14 hapresto staff 448 Dec 18 09:09 cisco-nx-cli-5.13 336 | drwxr-xr-x 13 hapresto staff 416 Nov 29 05:17 dell-ftos-cli-3.0 337 | drwxr-xr-x 10 hapresto staff 320 Nov 29 05:17 juniper-junos-nc-3.0 338 | ``` 339 | 340 |
341 | 342 | 1. And now you have the newer NED versions available, as well as the demo/evaluation versions included with NSO itself! 343 | 344 | 345 | ### `ncsrc` 346 | The last thing we want to notice are the files `ncsrc` and `ncsrc.tsch`. These are shell scripts for bash and tsch that setup your `PATH` and other environment variables for NSO. Depending on your shell, you'll `source` this file before starting your NSO work. 347 | 348 | Many users will update their `~/.bash_profile` files to automatically `source ~/nso-5.3/ncsrc` for every terminal, or you can just do it manually when you want it. Once it has been "sourced", you now have access to all the NSO executables - which start with `ncs` 349 | 350 | ```bash 351 | ncs {TAB} {TAB} 352 | 353 | # Output 354 | ncs ncs-maapi ncs-project ncs-start-python-vm ncs_cmd ncs_load 355 | ncs-backup ncs-make-package ncs-setup ncs-uninstall ncs_conf_tool ncsc 356 | ncs-collect-tech-report ncs-netsim ncs-start-java-vm ncs_cli ncs_crypto_keys 357 | ``` 358 | 359 | We'll make use of some of these in our lab, but many of these are used for advanced topics and can be ignored for now. 360 | 361 | ## Resources 362 | Here are some handy links to resources related to getting started with Cisco NSO. 363 | 364 | * https://developer.cisco.com/site/nso/ 365 | * https://developer.cisco.com/docs/nso/#!getting-nso 366 | * https://developer.cisco.com/docs/nso/#!an-nso-lab 367 | * The "NSO Installation Guide" available in ${NCS_DIR}/doc 368 | -------------------------------------------------------------------------------- /02-connecting-to-network.md: -------------------------------------------------------------------------------- 1 | # Connecting to the Network for the First Time 2 | You've now got NSO installed and you are ready to dive in and use it on your network, but what network? 3 | 4 | If you have a lab ready to go, feel free to use that - but we've included a [VIRL topology file](topology.virl) with this lab that we will use for our examples. Feel free to fire, up your own instance of this VIRL network either using your own VIRL server, or go reserve one from [DevNet Sandbox - Multi-IOS Test Network](https://devnetsandbox.cisco.com/RM/Diagram/Index/6b023525-4e7f-4755-81ae-05ac500d464a?diagramType=Topology) 5 | 6 | ![](example-network-sm.jpeg) 7 | 8 | > The exmaple network provides a basic data center network of Nexus 9000 switches with multiple VRFs and VLANs, connected to a DMZ through an ASA firewall, where IOS XE routers handle a bit or routing, before an Edge ASAv firewall provides access to a simulated "Internet". Also included are several different servers that can be used for testing network functionality. 9 | 10 |
Devices Details 11 | 12 | ```bash 13 | ╒═══════════════════╤═════════════╤═════════╤═════════════╤════════════╤══════════════════════╤════════════════════╕ 14 | │ Node │ Type │ State │ Reachable │ Protocol │ Management Address │ External Address │ 15 | ╞═══════════════════╪═════════════╪═════════╪═════════════╪════════════╪══════════════════════╪════════════════════╡ 16 | │ admin-mgmt01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.167 │ N/A │ 17 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 18 | │ admin-systems01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.151 │ N/A │ 19 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 20 | │ dev-app01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.154 │ N/A │ 21 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 22 | │ dev-data01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.153 │ N/A │ 23 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 24 | │ dev-web01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.161 │ N/A │ 25 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 26 | │ dmz-fw01-1 │ ASAv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.133 │ N/A │ 27 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 28 | │ dmz-rtr02-1 │ CSR1000v │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.135 │ N/A │ 29 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 30 | │ dmz-rtr02-2 │ CSR1000v │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.136 │ N/A │ 31 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 32 | │ dmz-sw01-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.107 │ N/A │ 33 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 34 | │ dmz-sw01-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.108 │ N/A │ 35 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 36 | │ dmz-sw02-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.109 │ N/A │ 37 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 38 | │ dmz-sw02-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.110 │ N/A │ 39 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 40 | │ fw-inside-sw01 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.122 │ N/A │ 41 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 42 | │ fw-outside-sw01 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.123 │ N/A │ 43 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 44 | │ fw01 │ ASAv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.145 │ N/A │ 45 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 46 | │ fw02 │ ASAv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.146 │ N/A │ 47 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 48 | │ guest-01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.164 │ N/A │ 49 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 50 | │ internet-rtr │ CSR1000v │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.171 │ N/A │ 51 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 52 | │ internet-server01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.175 │ N/A │ 53 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 54 | │ internet-server02 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.176 │ N/A │ 55 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 56 | │ leaf01-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.103 │ N/A │ 57 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 58 | │ leaf01-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.104 │ N/A │ 59 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 60 | │ leaf02-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.105 │ N/A │ 61 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 62 | │ leaf02-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.106 │ N/A │ 63 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 64 | │ prod-app01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.155 │ N/A │ 65 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 66 | │ prod-data01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.162 │ N/A │ 67 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 68 | │ prod-web01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.152 │ N/A │ 69 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 70 | │ spine01-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.101 │ N/A │ 71 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 72 | │ spine01-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.102 │ N/A │ 73 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 74 | │ vm-sw01 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.121 │ N/A │ 75 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 76 | │ vm-sw02 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.115 │ N/A │ 77 | ╘═══════════════════╧═════════════╧═════════╧═════════════╧════════════╧══════════════════════╧════════════════════╛ 78 | ``` 79 | 80 |
81 | 82 | ## Starting the sample VIRL Network 83 | Follow these steps to start the sample network. 84 | 85 | 1. Reserve an instance of [DevNet Sandbox - Multi-IOS Test Network](https://devnetsandbox.cisco.com/RM/Diagram/Index/6b023525-4e7f-4755-81ae-05ac500d464a?diagramType=Topology). Pick **None** as the `Virl Simulation` before reserving. This will start the lab with NO topology loaded in VIRL, we'll be starting our own. 86 | 87 | ![](sbx-reserve-1.jpg) 88 | 89 | > It will take about 10 minutes for the lab to fully spin up. 90 | 91 | 1. Once your lab is ready, use the VPN credentials you recieve via email, or find in the **OUTPUT** box in the Sandbox portal to connect to your lab. 92 | 1. If you haven't already, clone down this repository to your local workstation. 93 | 94 | ```bash 95 | git clone https://github.com/hpreston/nso-getting-started.git 96 | ``` 97 | 98 | 1. Change into the code repository directory. 99 | 100 | ```bash 101 | cd nso-getting-started 102 | ``` 103 | 104 | 1. We will use the Python package `virlutils` to start the lab. If you don't have it installed already, go ahead and do so now. 105 | 106 | > Note: This guide assumes a basic knowledge of Python and doesn't explicitly state to use a virtual environment, or a version of Python to use. Any recent version of Python and common working environment should work. 107 | 108 | ```bash 109 | pip install virlutils 110 | ``` 111 | 112 | 1. Verify that your lab and virlutils is working. 113 | 114 | ```bash 115 | # Check what version of VIRL is loaded (verify you can talk to server) 116 | virl version 117 | 118 | # Check if any simulations are running 119 | virl ls --all 120 | ``` 121 | 122 |
Output 123 | 124 | ``` 125 | $virl version 126 | virlutils Version: 0.8.8 127 | VIRL Core Version: 0.10.37.32 128 | 129 | $ virl ls --all 130 | Running Simulations 131 | ╒══════════════╤══════════╤════════════════════════════╤═══════════╕ 132 | │ Simulation │ Status │ Launched │ Expires │ 133 | ╞══════════════╪══════════╪════════════════════════════╪═══════════╡ 134 | │ ~jumphost │ ACTIVE │ 2019-12-15T16:27:42.567768 │ │ 135 | ╘══════════════╧══════════╧════════════════════════════╧═══════════╛ 136 | ``` 137 | 138 |
139 | 140 | 141 | * If any simulation other than `~jumphost` is running, stop it with the following command. 142 | 143 | ```bash 144 | virl down --sim-name {SIMULATION_NAME} 145 | ``` 146 | 147 | 1. Start a simulation for this lab. 148 | 149 | ```bash 150 | virl up 151 | ``` 152 | 153 |
Output 154 | 155 | ``` 156 | Creating default environment from topology.virl 157 | ``` 158 | 159 |
160 | 161 | 1. It will take several minutes for the simulation to fully start, you can monitor it with the following command - waiting for all devices to show `REACHABLE` 162 | 163 | ```bash 164 | virl nodes 165 | ``` 166 | 167 |
Devices Details 168 | 169 | ```bash 170 | ╒═══════════════════╤═════════════╤═════════╤═════════════╤════════════╤══════════════════════╤════════════════════╕ 171 | │ Node │ Type │ State │ Reachable │ Protocol │ Management Address │ External Address │ 172 | ╞═══════════════════╪═════════════╪═════════╪═════════════╪════════════╪══════════════════════╪════════════════════╡ 173 | │ admin-mgmt01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.167 │ N/A │ 174 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 175 | │ admin-systems01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.151 │ N/A │ 176 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 177 | │ dev-app01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.154 │ N/A │ 178 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 179 | │ dev-data01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.153 │ N/A │ 180 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 181 | │ dev-web01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.161 │ N/A │ 182 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 183 | │ dmz-fw01-1 │ ASAv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.133 │ N/A │ 184 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 185 | │ dmz-rtr02-1 │ CSR1000v │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.135 │ N/A │ 186 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 187 | │ dmz-rtr02-2 │ CSR1000v │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.136 │ N/A │ 188 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 189 | │ dmz-sw01-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.107 │ N/A │ 190 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 191 | │ dmz-sw01-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.108 │ N/A │ 192 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 193 | │ dmz-sw02-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.109 │ N/A │ 194 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 195 | │ dmz-sw02-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.110 │ N/A │ 196 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 197 | │ fw-inside-sw01 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.122 │ N/A │ 198 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 199 | │ fw-outside-sw01 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.123 │ N/A │ 200 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 201 | │ fw01 │ ASAv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.145 │ N/A │ 202 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 203 | │ fw02 │ ASAv │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.146 │ N/A │ 204 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 205 | │ guest-01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.164 │ N/A │ 206 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 207 | │ internet-rtr │ CSR1000v │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.171 │ N/A │ 208 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 209 | │ internet-server01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.175 │ N/A │ 210 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 211 | │ internet-server02 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.176 │ N/A │ 212 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 213 | │ leaf01-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.103 │ N/A │ 214 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 215 | │ leaf01-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.104 │ N/A │ 216 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 217 | │ leaf02-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.105 │ N/A │ 218 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 219 | │ leaf02-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.106 │ N/A │ 220 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 221 | │ prod-app01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.155 │ N/A │ 222 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 223 | │ prod-data01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.162 │ N/A │ 224 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 225 | │ prod-web01 │ server │ ACTIVE │ REACHABLE │ ssh │ 172.16.30.152 │ N/A │ 226 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 227 | │ spine01-1 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.101 │ N/A │ 228 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 229 | │ spine01-2 │ NX-OSv 9000 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.102 │ N/A │ 230 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 231 | │ vm-sw01 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.121 │ N/A │ 232 | ├───────────────────┼─────────────┼─────────┼─────────────┼────────────┼──────────────────────┼────────────────────┤ 233 | │ vm-sw02 │ IOSvL2 │ ACTIVE │ REACHABLE │ telnet │ 172.16.30.115 │ N/A │ 234 | ╘═══════════════════╧═════════════╧═════════╧═════════════╧════════════╧══════════════════════╧════════════════════╛ 235 | ``` 236 | 237 |
238 | 239 | 240 | ## Setting up and Starting NSO 241 | As you learned during the installation step, a Local Install unpacks and prepares your system to run NSO, but doesn't actually start it up. A Local Install allows the engineer to create an NSO "instance" tied to a project. If you've done much work with Python, you can think of this like creating a Python virtual environment after installing Python. Within this NSO instance, you will have different inventory, configuration, and code. 242 | 243 | 1. First up, navigate to a directory where you'll want to setup this new NSO instance. The lab's code repository includes a folder called `nso-instance` - this is a great place 244 | 245 | ```bash 246 | cd ~/code/nso-getting-started/nso-instance/ 247 | ``` 248 | 249 | > This folder has a `.gitignore` and `Makefile` contained within. The ignore file is there to prevent committing NSO files to the repository, and the `Makefile` provides some helpful shortcuts and targets that you'll see shortly. The folder `lab-configs/` contains a few NSO configuration files for reference or use in the lab. 250 | 251 | 1. If you haven't already, be sure to "source" the `ncsrc` file. 252 | 1. One of the included scripts with an NSO installation is `ncs-setup` which makes it very easy to create instances of NSO from a Local Install. You can look at the `--help` for full details, but the two options we need to know are 253 | * `--dest` - the directory where you want to setup NSO 254 | * `--package` - the NEDs you want to this NSO instance to have installed. You can specify this option multiple times. 255 | 1. Go ahead and run this command to setup an NSO instance in the current directory with the IOS, NX-OS, and ASA NEDs. 256 | 257 | > You will want to use the name of the NED folder in `${NCS_DIR}/packages/neds` for the latest NED version you've got installed for the target platform. 258 | 259 | ```bash 260 | ncs-setup --package cisco-ios-cli-6.42 \ 261 | --package cisco-nx-cli-5.13 \ 262 | --package cisco-asa-cli-6.7 \ 263 | --dest . 264 | ``` 265 | 266 | 1. If you checkout the directory now you'll find several new files and folders have been created. We won't go through them all in detail now, but a couple are handy to know about. 267 | * `ncs.conf` - the NSO configuration file. Used to customize aspects of the NSO instance. The defaults are often perfect for projects like this. 268 | * `packages/` - this directory will have symlinks to the NEDs that we referenced in the `--package` arguments at setup. 269 | * `logs/` - this directory contains all the logs from NSO. When troubleshooting, this is a handy directory. 270 | 271 | 1. Last step is to "start" NSO. Simply type the command `ncs`. It will take a few seconds to run - and you won't get any explicit output unless there is a problem. 272 | 273 | ```bash 274 | ncs 275 | ``` 276 | 277 | 278 | 1. Jump into your NSO instance using the `ncs_cli` command. This command takes several options - we'll use `-C` to specify we'd like a "Cisco style" command line interface (the default is a Juniper style), and `-u admin` to login as the "admin" user. 279 | 280 | ```bash 281 | ncs_cli -C -u admin 282 | ``` 283 | 284 |
Output 285 | 286 | ``` 287 | admin connected from 127.0.0.1 using console on HAPRESTO-M-Q0Y6 288 | admin@ncs# 289 | ``` 290 | 291 |
292 | 293 | ## Setting up Device Authentication 294 | With NSO running, we now need to add our devices into it's "inventory" so that it can read and write data. NSO uses "authgroups" to setup credentials for device access. We'll setup a simple `authgroup` for our network. 295 | 296 | 1. If not already, start the NSO CLI with `ncs_cli -C -u admin`. 297 | 1. Enter into "config mode". 298 | 299 | ```text 300 | config 301 | ``` 302 | 303 |
OUTPUT 304 | 305 | ``` 306 | Entering configuration mode terminal 307 | admin@ncs(config)# 308 | ``` 309 | 310 |
311 | 312 | 1. We will setup a new authgroup called "labadmin". This group will use a default username/password combination of `cisco / cisco` for devices, with a "secondary" (ie 'enable') password also of `cisco`. These commands will set this up. 313 | 314 | ```text 315 | devices authgroups group labadmin 316 | default-map remote-name cisco 317 | default-map remote-password cisco 318 | default-map remote-secondary-password cisco 319 | ``` 320 | 321 | 1. Entering this configuration into NSO "stages" it, but it isn't committed to the system until you use the command `commit`. Before we do so, jump back ot the `top` of config mode, and look at the currently staged `config` with `show config`. 322 | 323 | ```text 324 | top 325 | show config 326 | ``` 327 | 328 |
OUTPUT 329 | 330 | ``` 331 | devices authgroups group labadmin 332 | default-map remote-name cisco 333 | default-map remote-password $9$gGBuW7qSU5faSS/gkuyB1PXmh0Q2Da+gWPazNMq1SW8= 334 | default-map remote-secondary-password $9$gJEos3QbeiJsJe0xnZ3EoDv7r3eX3fXBhc0szTM2D64= 335 | ``` 336 | 337 |
338 | 339 | > This is a very handy way to see what configuration is ready to be committed before you finalize it. Also, note that NSO uses a local encryption model to store the credentials in it's database. 340 | 341 | 1. Now `commit` this to lock in the changes. 342 | 343 | > You can create as many `authgroups` as you need to for the different variations of authentication used across your network. authgroups also can leverage SNMP or certificates in addition to traditional username/passwords . Furthermore, NSO supports very powerful methods of RBAC for identifying and leveraging different authentication and authorization levels depending on the user logged into NSO. These features are beyond scope for this introduction. 344 | 345 | ## Adding Devices to Cisco NSO 346 | With our authgroup setup, let's go ahead and add our devices to the inventory. To add a device you'll need the following information: 347 | 348 | * The device's address - IP or FQDN. 349 | * The protocol (ssh/telnet) and port (if non-standard) to connect to the device. 350 | * The device's authgroup to use (see above). 351 | * The NED you'll use to connect to the device. 352 | 353 | > We'll walk through the first device step by step, then bulk add the rest of them. 354 | 355 | 1. Start out back in `config` mode in NSO. 356 | 1. We will first add `dmz-rtr02-1` using this information 357 | * Address: `172.16.30.135` 358 | * Protocol: SSH 359 | * We will disable SSH host-key-verification (in production systems you can configure the host-key or just "fetch" to learn) 360 | * NED: `cisco-ios-cli-6.42` 361 | 1. Enter this configuration into NSO. 362 | 363 | ```text 364 | devices device dmz-rtr01-1 365 | address 172.16.30.135 366 | authgroup labadmin 367 | device-type cli ned-id cisco-ios-cli-6.42 368 | device-type cli protocol ssh 369 | ssh host-key-verification none 370 | ``` 371 | 372 | 1. Now `commit` this to NSO to lock it in. 373 | 1. You should still be in the CLI context for the device, evident by the `prompt` or checking with `pwd` 374 | 375 | ```text 376 | admin@ncs(config-device-dmz-rtr01-1)# pwd 377 | Current submode path: 378 | devices device dmz-rtr01-1 379 | ``` 380 | 381 | 1. Let's see if we can connect to the device with NSO. 382 | 383 | ```text 384 | connect 385 | ``` 386 | 387 |
OUTPUT 388 | 389 | ``` 390 | result false 391 | info Device dmz-rtr01-1 is southbound locked 392 | ``` 393 | 394 |
395 | 396 | 1. Uh oh... we are currently "locked". NSO's default mode for devices is a "locked state". This prevents NSO from manipulating a device before the network admin is ready. This is also a handy ability to "disable" a device that is currently in maintenance to prevent NSO from acting on it. "Unlock" it by changing it's `admin-state` and `commit` the change. 397 | 398 | ``` 399 | state admin-state unlocked 400 | commit 401 | ``` 402 | 403 | 1. Now try to `connect` again. 404 | 405 | ```text 406 | connect 407 | ``` 408 | 409 |
OUTPUT 410 | 411 | ``` 412 | result true 413 | info (admin) Connected to dmz-rtr01-1 - 172.16.30.135:22 414 | ``` 415 | 416 |
417 | 418 | 1. Excellent! Now you just need to repeat the process for the remaining devices, and there are a few options. 419 | 1. You can manually type the commands for each device - great practice but a bit boring. 420 | 1. You can open up the file [`nso-inventory.cfg`](nso-instance/lab-configs/nso-inventory.cfg) from the `nso-instance` directory that has the configuration needed all ready for you and copy/paste it. A bit faster, but not the best option. 421 | 1. You can use the `load merge` command from NSO to read the file into NSO and stage it for committing. 422 | 423 | 1. Let's assume you want to use this third option, though do take a look at the file to see what commands are being ran. The only major difference between device types is the `ned-id` value being used. 424 | 425 | ```text 426 | top 427 | load merge lab-configs/nso-inventory.cfg 428 | ``` 429 | 430 | > Don't forget to use `show configuration` after `load merge` to verify what has been staged. 431 | 432 | 1. Now just `commit` to complete adding these devices to NSO. 433 | 434 | ```text 435 | commit 436 | ``` 437 | 438 | 1. Now use `end` to exit from `config` mode. 439 | 1. Verify the devices have been added to NSO. 440 | 441 | ```text 442 | show devices list 443 | ``` 444 | 445 |
OUTPUT 446 | 447 | ``` 448 | NAME ADDRESS DESCRIPTION NED ID ADMIN STATE 449 | --------------------------------------------------------------------------- 450 | dmz-fw01-1 172.16.30.133 - cisco-asa-cli-6.7 unlocked 451 | dmz-rtr01-1 172.16.30.135 - cisco-ios-cli-6.42 unlocked 452 | dmz-rtr02-1 172.16.30.135 - cisco-ios-cli-6.42 unlocked 453 | dmz-rtr02-2 172.16.30.136 - cisco-ios-cli-6.42 unlocked 454 | dmz-sw01-1 172.16.30.107 - cisco-nx-cli-5.13 unlocked 455 | dmz-sw01-2 172.16.30.108 - cisco-nx-cli-5.13 unlocked 456 | dmz-sw02-1 172.16.30.109 - cisco-nx-cli-5.13 unlocked 457 | dmz-sw02-2 172.16.30.110 - cisco-nx-cli-5.13 unlocked 458 | fw-inside-sw01 172.16.30.122 - cisco-ios-cli-6.42 unlocked 459 | fw-outside-sw01 172.16.30.123 - cisco-ios-cli-6.42 unlocked 460 | fw01 172.16.30.145 - cisco-asa-cli-6.7 unlocked 461 | fw02 172.16.30.146 - cisco-asa-cli-6.7 unlocked 462 | internet-rtr 172.16.30.171 - cisco-ios-cli-6.42 unlocked 463 | leaf01-1 172.16.30.103 - cisco-nx-cli-5.13 unlocked 464 | leaf01-2 172.16.30.104 - cisco-nx-cli-5.13 unlocked 465 | leaf02-1 172.16.30.105 - cisco-nx-cli-5.13 unlocked 466 | leaf02-2 172.16.30.106 - cisco-nx-cli-5.13 unlocked 467 | spine01-1 172.16.30.101 - cisco-nx-cli-5.13 unlocked 468 | spine01-2 172.16.30.102 - cisco-nx-cli-5.13 unlocked 469 | vm-sw01 172.16.30.121 - cisco-ios-cli-6.42 unlocked 470 | vm-sw02 172.16.30.115 - cisco-ios-cli-6.42 unlocked 471 | ``` 472 | 473 |
474 | 475 | 1. Finally, make sure NSO can communicate with these devices by attempting to `connect` to them all. You can do this to all devices very easily like this. 476 | 477 | ```text 478 | devices connect 479 | ``` 480 | 481 |
OUTPUT 482 | 483 | ``` 484 | connect-result { 485 | device dmz-fw01-1 486 | result true 487 | info (admin) Connected to dmz-fw01-1 - 172.16.30.133:22 488 | } 489 | connect-result { 490 | device dmz-rtr01-1 491 | result true 492 | info (admin) Connected to dmz-rtr01-1 - 172.16.30.135:22 493 | } 494 | connect-result { 495 | device dmz-rtr02-1 496 | result true 497 | info (admin) Connected to dmz-rtr02-1 - 172.16.30.135:22 498 | } 499 | connect-result { 500 | device dmz-rtr02-2 501 | result true 502 | info (admin) Connected to dmz-rtr02-2 - 172.16.30.136:22 503 | } 504 | connect-result { 505 | device dmz-sw01-1 506 | result true 507 | info (admin) Connected to dmz-sw01-1 - 172.16.30.107:22 508 | } 509 | connect-result { 510 | device dmz-sw01-2 511 | result true 512 | info (admin) Connected to dmz-sw01-2 - 172.16.30.108:22 513 | } 514 | connect-result { 515 | device dmz-sw02-1 516 | result true 517 | info (admin) Connected to dmz-sw02-1 - 172.16.30.109:22 518 | } 519 | connect-result { 520 | device dmz-sw02-2 521 | result true 522 | info (admin) Connected to dmz-sw02-2 - 172.16.30.110:22 523 | } 524 | connect-result { 525 | device fw-inside-sw01 526 | result true 527 | info (admin) Connected to fw-inside-sw01 - 172.16.30.122:22 528 | } 529 | connect-result { 530 | device fw-outside-sw01 531 | result true 532 | info (admin) Connected to fw-outside-sw01 - 172.16.30.123:22 533 | } 534 | connect-result { 535 | device fw01 536 | result true 537 | info (admin) Connected to fw01 - 172.16.30.145:22 538 | } 539 | connect-result { 540 | device fw02 541 | result true 542 | info (admin) Connected to fw02 - 172.16.30.146:22 543 | } 544 | connect-result { 545 | device internet-rtr 546 | result true 547 | info (admin) Connected to internet-rtr - 172.16.30.171:22 548 | } 549 | connect-result { 550 | device leaf01-1 551 | result true 552 | info (admin) Connected to leaf01-1 - 172.16.30.103:22 553 | } 554 | connect-result { 555 | device leaf01-2 556 | result true 557 | info (admin) Connected to leaf01-2 - 172.16.30.104:22 558 | } 559 | connect-result { 560 | device leaf02-1 561 | result true 562 | info (admin) Connected to leaf02-1 - 172.16.30.105:22 563 | } 564 | connect-result { 565 | device leaf02-2 566 | result true 567 | info (admin) Connected to leaf02-2 - 172.16.30.106:22 568 | } 569 | connect-result { 570 | device spine01-1 571 | result true 572 | info (admin) Connected to spine01-1 - 172.16.30.101:22 573 | } 574 | connect-result { 575 | device spine01-2 576 | result true 577 | info (admin) Connected to spine01-2 - 172.16.30.102:22 578 | } 579 | connect-result { 580 | device vm-sw01 581 | result true 582 | info (admin) Connected to vm-sw01 - 172.16.30.121:22 583 | } 584 | connect-result { 585 | device vm-sw02 586 | result true 587 | info (admin) Connected to vm-sw02 - 172.16.30.115:22 588 | } 589 | ``` 590 | 591 |
592 | 593 | ## "Learning" Current Network State (sync-from) 594 | Now NSO can successfully connect to the network, but it hasn't "learned" the current network configuration deployed to the devices. Let's fix that. 595 | 596 | 1. First, see for yourself that there is no real device level configuration within NSO yet by looking at a device. 597 | 598 | ```text 599 | show running-config devices device leaf01-1 config 600 | ``` 601 | 602 |
OUTPUT 603 | 604 | ``` 605 | config 606 | no feature ssh 607 | no feature telnet 608 | ``` 609 | 610 |
611 | 612 | > Checkout a few other devices. Different NEDs have different "default states". 613 | 614 | 1. NSO makes it easy to `sync-from` the network devices to "learn" the current configuration. Go ahead and do that to all devices. 615 | 616 | > **NOTE: Be sure you do *NOT* enter `devices sync-to` by mistake. This will have NSO attempt to overwrite the configuration on the devices with the "blank" configuration that NSO currently has for the devices. This will be bad.** 617 | 618 | ```text 619 | devices sync-from 620 | ``` 621 | 622 |
OUTPUT 623 | 624 | ``` 625 | sync-result { 626 | device dmz-fw01-1 627 | result true 628 | } 629 | sync-result { 630 | device dmz-rtr01-1 631 | result true 632 | } 633 | sync-result { 634 | device dmz-rtr02-1 635 | result true 636 | } 637 | sync-result { 638 | device dmz-rtr02-2 639 | result true 640 | } 641 | sync-result { 642 | device dmz-sw01-1 643 | result true 644 | } 645 | sync-result { 646 | device dmz-sw01-2 647 | result true 648 | } 649 | sync-result { 650 | device dmz-sw02-1 651 | result true 652 | } 653 | sync-result { 654 | device dmz-sw02-2 655 | result true 656 | } 657 | sync-result { 658 | device fw-inside-sw01 659 | result true 660 | } 661 | sync-result { 662 | device fw-outside-sw01 663 | result true 664 | } 665 | sync-result { 666 | device fw01 667 | result true 668 | } 669 | sync-result { 670 | device fw02 671 | result true 672 | } 673 | sync-result { 674 | device internet-rtr 675 | result true 676 | } 677 | sync-result { 678 | device leaf01-1 679 | result true 680 | } 681 | sync-result { 682 | device leaf01-2 683 | result true 684 | } 685 | sync-result { 686 | device leaf02-1 687 | result true 688 | } 689 | sync-result { 690 | device leaf02-2 691 | result true 692 | } 693 | sync-result { 694 | device spine01-1 695 | result true 696 | } 697 | sync-result { 698 | device spine01-2 699 | result true 700 | } 701 | sync-result { 702 | device vm-sw01 703 | result true 704 | } 705 | sync-result { 706 | device vm-sw02 707 | result true 708 | } 709 | ``` 710 | 711 |
712 | 713 | 1. Now re-check the NSO `running-configuration` of the devices. 714 | 715 | ```text 716 | show running-config devices device leaf01-1 config 717 | ``` 718 | 719 |
OUTPUT 720 | 721 | ``` 722 | show running-config devices device leaf01-1 config 723 | devices device leaf01-1 724 | config 725 | ! Command: show running-config Running configuration last done at: Sun Dec 15 17:21:37 2019 Time: Mon Dec 16 02:03:17 2019 726 | hostname leaf01-1 727 | cfs eth distribute 728 | feature hsrp 729 | feature ospf 730 | feature vpc 731 | feature interface-vlan 732 | feature lacp 733 | no feature ssh 734 | feature telnet 735 | username admin password 5 $1$KuOSBsvW$Cy0TSD..gEBGBPjzpDgf51 role network-admin 736 | username cisco password 5 $1$Nk7ZkwH0$fyiRmMMfIheqE3BqvcL0C1 role network-admin 737 | no password strength-check 738 | vlan 1 739 | ! 740 | vlan 10 741 | name trusted-transit 742 | ! 743 | vlan 11 744 | name admin-systems 745 | ! 746 | vlan 12 747 | name mgmt 748 | ! 749 | vlan 100 750 | name dmz-transit 751 | ! 752 | vlan 101 753 | name prod-web 754 | ! 755 | vlan 102 756 | name prod-app 757 | ! 758 | vlan 103 759 | name prod-data 760 | ! 761 | vlan 201 762 | name dev-web 763 | ! 764 | vlan 202 765 | name dev-app 766 | ! 767 | vlan 203 768 | name dev-data 769 | ! 770 | vlan 900 771 | name guest-transit 772 | ! 773 | vlan 901 774 | name hotspot 775 | ! 776 | vlan 3001 777 | name backdoor-temp 778 | ! 779 | vrf context backdoor 780 | ! 781 | vrf context dmz 782 | ip route 0.0.0.0/0 10.225.250.4 783 | ! 784 | vrf context guest 785 | ! 786 | vrf context management 787 | ip route 0.0.0.0/0 172.16.30.254 788 | ! 789 | vrf context trusted 790 | ip route 0.0.0.0/0 10.225.250.4 791 | ! 792 | vpc domain 10 793 | peer-gateway 794 | peer-switch 795 | ! 796 | vdc leaf01-1 id 1 797 | limit-resource vlan minimum 16 maximum 4094 798 | limit-resource port-channel minimum 0 maximum 511 799 | limit-resource u4route-mem minimum 128 maximum 128 800 | limit-resource u6route-mem minimum 96 maximum 96 801 | limit-resource m4route-mem minimum 58 maximum 58 802 | limit-resource m6route-mem minimum 8 maximum 8 803 | ! 804 | interface Ethernet1/1 805 | description VPC Peer Link 806 | channel-group 1 mode active 807 | switchport mode trunk 808 | ! 809 | interface Ethernet1/10 810 | ! 811 | interface Ethernet1/100 812 | ! 813 | interface Ethernet1/101 814 | ! 815 | interface Ethernet1/102 816 | ! 817 | interface Ethernet1/103 818 | ! 819 | interface Ethernet1/104 820 | ! 821 | interface Ethernet1/105 822 | ! 823 | interface Ethernet1/106 824 | ! 825 | interface Ethernet1/107 826 | ! 827 | interface Ethernet1/108 828 | ! 829 | interface Ethernet1/109 830 | ! 831 | interface Ethernet1/11 832 | description Interswitch Fabric Link 833 | channel-group 3 mode active 834 | switchport mode trunk 835 | ! 836 | interface Ethernet1/110 837 | ! 838 | interface Ethernet1/111 839 | ! 840 | interface Ethernet1/112 841 | ! 842 | interface Ethernet1/113 843 | ! 844 | interface Ethernet1/114 845 | ! 846 | interface Ethernet1/115 847 | ! 848 | interface Ethernet1/116 849 | ! 850 | interface Ethernet1/117 851 | ! 852 | interface Ethernet1/118 853 | ! 854 | interface Ethernet1/119 855 | ! 856 | interface Ethernet1/12 857 | ! 858 | interface Ethernet1/120 859 | ! 860 | interface Ethernet1/121 861 | ! 862 | interface Ethernet1/122 863 | ! 864 | interface Ethernet1/123 865 | ! 866 | interface Ethernet1/124 867 | ! 868 | interface Ethernet1/125 869 | ! 870 | interface Ethernet1/126 871 | ! 872 | interface Ethernet1/127 873 | ! 874 | interface Ethernet1/128 875 | ! 876 | interface Ethernet1/13 877 | ! 878 | interface Ethernet1/14 879 | ! 880 | interface Ethernet1/15 881 | ! 882 | interface Ethernet1/16 883 | ! 884 | interface Ethernet1/17 885 | ! 886 | interface Ethernet1/18 887 | ! 888 | interface Ethernet1/19 889 | ! 890 | interface Ethernet1/2 891 | description VPC Peer Link 892 | channel-group 1 mode active 893 | switchport mode trunk 894 | ! 895 | interface Ethernet1/20 896 | ! 897 | interface Ethernet1/21 898 | ! 899 | interface Ethernet1/22 900 | ! 901 | interface Ethernet1/23 902 | ! 903 | interface Ethernet1/24 904 | ! 905 | interface Ethernet1/25 906 | ! 907 | interface Ethernet1/26 908 | ! 909 | interface Ethernet1/27 910 | ! 911 | interface Ethernet1/28 912 | ! 913 | interface Ethernet1/29 914 | ! 915 | interface Ethernet1/3 916 | description Interswitch Fabric Link 917 | channel-group 2 mode active 918 | switchport mode trunk 919 | ! 920 | interface Ethernet1/30 921 | ! 922 | interface Ethernet1/31 923 | ! 924 | interface Ethernet1/32 925 | ! 926 | interface Ethernet1/33 927 | ! 928 | interface Ethernet1/34 929 | ! 930 | interface Ethernet1/35 931 | ! 932 | interface Ethernet1/36 933 | ! 934 | interface Ethernet1/37 935 | ! 936 | interface Ethernet1/38 937 | ! 938 | interface Ethernet1/39 939 | ! 940 | interface Ethernet1/4 941 | description Interswitch Fabric Link 942 | channel-group 2 mode active 943 | switchport mode trunk 944 | ! 945 | interface Ethernet1/40 946 | ! 947 | interface Ethernet1/41 948 | ! 949 | interface Ethernet1/42 950 | ! 951 | interface Ethernet1/43 952 | ! 953 | interface Ethernet1/44 954 | ! 955 | interface Ethernet1/45 956 | ! 957 | interface Ethernet1/46 958 | ! 959 | interface Ethernet1/47 960 | ! 961 | interface Ethernet1/48 962 | ! 963 | interface Ethernet1/49 964 | ! 965 | interface Ethernet1/5 966 | ! 967 | interface Ethernet1/50 968 | ! 969 | interface Ethernet1/51 970 | ! 971 | interface Ethernet1/52 972 | ! 973 | interface Ethernet1/53 974 | ! 975 | interface Ethernet1/54 976 | ! 977 | interface Ethernet1/55 978 | ! 979 | interface Ethernet1/56 980 | ! 981 | interface Ethernet1/57 982 | ! 983 | interface Ethernet1/58 984 | ! 985 | interface Ethernet1/59 986 | ! 987 | interface Ethernet1/6 988 | ! 989 | interface Ethernet1/60 990 | ! 991 | interface Ethernet1/61 992 | ! 993 | interface Ethernet1/62 994 | ! 995 | interface Ethernet1/63 996 | ! 997 | interface Ethernet1/64 998 | ! 999 | interface Ethernet1/65 1000 | ! 1001 | interface Ethernet1/66 1002 | ! 1003 | interface Ethernet1/67 1004 | ! 1005 | interface Ethernet1/68 1006 | ! 1007 | interface Ethernet1/69 1008 | ! 1009 | interface Ethernet1/7 1010 | ! 1011 | interface Ethernet1/70 1012 | ! 1013 | interface Ethernet1/71 1014 | ! 1015 | interface Ethernet1/72 1016 | ! 1017 | interface Ethernet1/73 1018 | ! 1019 | interface Ethernet1/74 1020 | ! 1021 | interface Ethernet1/75 1022 | ! 1023 | interface Ethernet1/76 1024 | ! 1025 | interface Ethernet1/77 1026 | ! 1027 | interface Ethernet1/78 1028 | ! 1029 | interface Ethernet1/79 1030 | ! 1031 | interface Ethernet1/8 1032 | ! 1033 | interface Ethernet1/80 1034 | ! 1035 | interface Ethernet1/81 1036 | ! 1037 | interface Ethernet1/82 1038 | ! 1039 | interface Ethernet1/83 1040 | ! 1041 | interface Ethernet1/84 1042 | ! 1043 | interface Ethernet1/85 1044 | ! 1045 | interface Ethernet1/86 1046 | ! 1047 | interface Ethernet1/87 1048 | ! 1049 | interface Ethernet1/88 1050 | ! 1051 | interface Ethernet1/89 1052 | ! 1053 | interface Ethernet1/9 1054 | ! 1055 | interface Ethernet1/90 1056 | ! 1057 | interface Ethernet1/91 1058 | ! 1059 | interface Ethernet1/92 1060 | ! 1061 | interface Ethernet1/93 1062 | ! 1063 | interface Ethernet1/94 1064 | ! 1065 | interface Ethernet1/95 1066 | ! 1067 | interface Ethernet1/96 1068 | ! 1069 | interface Ethernet1/97 1070 | ! 1071 | interface Ethernet1/98 1072 | ! 1073 | interface Ethernet1/99 1074 | ! 1075 | interface mgmt0 1076 | description OOB Management 1077 | ip address 172.16.30.103/24 1078 | ip redirects 1079 | vrf member management 1080 | ! 1081 | interface port-channel1 1082 | spanning-tree port type network 1083 | switchport mode trunk 1084 | vpc peer-link 1085 | ! 1086 | interface port-channel2 1087 | description Interswitch Fabric Link 1088 | switchport mode trunk 1089 | vpc 2 1090 | ! 1091 | interface port-channel3 1092 | description Interswitch Fabric Link 1093 | switchport mode trunk 1094 | vpc 3 1095 | ! 1096 | interface Vlan1 1097 | no ip redirects 1098 | ! 1099 | interface Vlan10 1100 | ip address 10.225.250.2/29 1101 | no ip redirects 1102 | ip router ospf 1 area 0.0.0.0 1103 | no shutdown 1104 | vrf member trusted 1105 | hsrp version 2 1106 | hsrp 1 1107 | ip 10.225.250.1 1108 | preempt 1109 | priority 110 1110 | ! 1111 | ! 1112 | interface Vlan11 1113 | ip address 10.225.1.2/24 1114 | no ip redirects 1115 | ip router ospf 1 area 0.0.0.0 1116 | no shutdown 1117 | vrf member trusted 1118 | hsrp version 2 1119 | hsrp 1 1120 | ip 10.225.1.1 1121 | preempt 1122 | priority 110 1123 | ! 1124 | ! 1125 | interface Vlan12 1126 | ip address 10.225.2.2/24 1127 | no ip redirects 1128 | ip router ospf 1 area 0.0.0.0 1129 | no shutdown 1130 | vrf member trusted 1131 | hsrp version 2 1132 | hsrp 1 1133 | ip 10.225.2.1 1134 | preempt 1135 | priority 110 1136 | ! 1137 | ! 1138 | interface Vlan100 1139 | ip address 10.225.250.34/29 1140 | no ip redirects 1141 | ip router ospf 1 area 0.0.0.0 1142 | no shutdown 1143 | vrf member dmz 1144 | hsrp version 2 1145 | hsrp 1 1146 | ip 10.225.250.33 1147 | preempt 1148 | priority 110 1149 | ! 1150 | ! 1151 | interface Vlan101 1152 | ip address 10.225.9.2/24 1153 | no ip redirects 1154 | ip router ospf 1 area 0.0.0.0 1155 | no shutdown 1156 | vrf member dmz 1157 | hsrp version 2 1158 | hsrp 1 1159 | ip 10.225.9.1 1160 | preempt 1161 | priority 110 1162 | ! 1163 | ! 1164 | interface Vlan102 1165 | ip address 10.225.10.2/24 1166 | no ip redirects 1167 | ip router ospf 1 area 0.0.0.0 1168 | no shutdown 1169 | vrf member trusted 1170 | hsrp version 2 1171 | hsrp 1 1172 | ip 10.225.10.1 1173 | preempt 1174 | priority 110 1175 | ! 1176 | ! 1177 | interface Vlan103 1178 | ip address 10.225.11.2/24 1179 | no ip redirects 1180 | ip router ospf 1 area 0.0.0.0 1181 | no shutdown 1182 | vrf member trusted 1183 | hsrp version 2 1184 | hsrp 1 1185 | ip 10.225.11.1 1186 | preempt 1187 | priority 110 1188 | ! 1189 | ! 1190 | interface Vlan201 1191 | ip address 10.225.17.2/24 1192 | no ip redirects 1193 | ip router ospf 1 area 0.0.0.0 1194 | no shutdown 1195 | vrf member dmz 1196 | hsrp version 2 1197 | hsrp 1 1198 | ip 10.225.17.1 1199 | preempt 1200 | priority 110 1201 | ! 1202 | ! 1203 | interface Vlan202 1204 | ip address 10.225.18.2/24 1205 | no ip redirects 1206 | ip router ospf 1 area 0.0.0.0 1207 | no shutdown 1208 | vrf member trusted 1209 | hsrp version 2 1210 | hsrp 1 1211 | ip 10.225.18.1 1212 | preempt 1213 | priority 110 1214 | ! 1215 | ! 1216 | interface Vlan203 1217 | ip address 10.225.19.2/24 1218 | no ip redirects 1219 | ip router ospf 1 area 0.0.0.0 1220 | no shutdown 1221 | vrf member trusted 1222 | hsrp version 2 1223 | hsrp 1 1224 | ip 10.225.19.1 1225 | preempt 1226 | priority 110 1227 | ! 1228 | ! 1229 | interface Vlan900 1230 | ip address 10.225.250.50/29 1231 | no ip redirects 1232 | ip router ospf 1 area 0.0.0.0 1233 | no shutdown 1234 | vrf member guest 1235 | hsrp version 2 1236 | hsrp 1 1237 | ip 10.225.250.49 1238 | preempt 1239 | priority 110 1240 | ! 1241 | ! 1242 | interface Vlan901 1243 | ip address 10.225.49.2/24 1244 | no ip redirects 1245 | ip router ospf 1 area 0.0.0.0 1246 | no shutdown 1247 | vrf member guest 1248 | hsrp version 2 1249 | hsrp 1 1250 | ip 10.225.49.1 1251 | preempt 1252 | priority 110 1253 | ! 1254 | ! 1255 | interface Vlan3001 1256 | ip address 172.16.30.2/24 1257 | no ip redirects 1258 | ip router ospf 1 area 0.0.0.0 1259 | no shutdown 1260 | vrf member backdoor 1261 | hsrp version 2 1262 | hsrp 1 1263 | ip 172.16.30.1 1264 | preempt 1265 | priority 110 1266 | ! 1267 | ! 1268 | router ospf 1 1269 | vrf backdoor 1270 | passive-interface default 1271 | ! 1272 | vrf dmz 1273 | passive-interface default 1274 | ! 1275 | vrf guest 1276 | passive-interface default 1277 | ! 1278 | vrf trusted 1279 | passive-interface default 1280 | ``` 1281 | 1282 |
1283 | 1284 | > Explore the configs of other devices. 1285 | 1286 | ## Grouping Devices Together 1287 | This final step in connecting to the network isn't required, but will make working with the network simpler. What we will do is create `device-groups` to organize our devices into logical groups that we may want to apply similar configuration, or take similar action upon. 1288 | 1289 | Let's create the following groups 1290 | 1291 | * Network Operating System Based Groups 1292 | * `IOS-DEVICES` 1293 | * `NXOS-DEVICES` 1294 | * `ASA-DEVICES` 1295 | * Point in Network Based Groups 1296 | * `INTERNAL-DEVICES` 1297 | * `DMZ-DEVICES` 1298 | * `OUTSIDE-DEVICES` 1299 | 1300 | > You have full flexibility to create as many groups as you want. And groups can contain other groups for nesting. 1301 | 1302 | 1. Enter config mode. 1303 | 1. Groups are very easy to create, here's the `IOS-DEVICES` group. 1304 | 1305 | ```text 1306 | devices device-group IOS-DEVICES 1307 | device-name dmz-rtr02-1 1308 | device-name dmz-rtr02-2 1309 | device-name internet-rtr 1310 | device-name fw-inside-sw01 1311 | device-name fw-outside-sw01 1312 | device-name vm-sw01 1313 | device-name vm-sw02 1314 | ``` 1315 | 1316 | 1. And the `NXOS-DEVICES` group. 1317 | 1318 | ```text 1319 | devices device-group NXOS-DEVICES 1320 | device-name dmz-sw01-1 1321 | device-name dmz-sw01-2 1322 | device-name dmz-sw02-1 1323 | device-name dmz-sw02-2 1324 | device-name leaf01-1 1325 | device-name leaf01-2 1326 | device-name leaf02-1 1327 | device-name leaf02-2 1328 | device-name spine01-1 1329 | device-name spine01-2 1330 | ``` 1331 | 1332 | 1. And the `ASA-DEVICES` group. 1333 | 1334 | ```text 1335 | devices device-group ASA-DEVICES 1336 | device-name dmz-fw01-1 1337 | device-name fw01 1338 | device-name fw02 1339 | ``` 1340 | 1341 | 1. And here are all the Point in Network Groups 1342 | 1343 | ```text 1344 | devices device-group INTERNAL-DEVICES 1345 | device-name fw-inside-sw01 1346 | device-name vm-sw01 1347 | device-name vm-sw02 1348 | device-name leaf01-1 1349 | device-name leaf01-2 1350 | device-name leaf02-1 1351 | device-name leaf02-2 1352 | device-name spine01-1 1353 | device-name spine01-2 1354 | 1355 | devices device-group DMZ-DEVICES 1356 | device-name dmz-rtr02-1 1357 | device-name dmz-rtr02-2 1358 | device-name fw-outside-sw01 1359 | device-name dmz-sw01-1 1360 | device-name dmz-sw01-2 1361 | device-name dmz-sw02-1 1362 | device-name dmz-sw02-2 1363 | device-name dmz-fw01-1 1364 | device-name fw01 1365 | device-name fw02 1366 | 1367 | devices device-group OUTSIDE-DEVICES 1368 | device-name internet-rtr 1369 | ``` 1370 | 1371 | 1. And one last group that will include `ALL` our devices. 1372 | 1373 | ``` 1374 | devices device-group ALL 1375 | device-group ASA-DEVICES 1376 | device-group IOS-DEVICES 1377 | device-group NXOS-DEVICES 1378 | ``` 1379 | 1380 | 1. And now `commit` them to save the changes. 1381 | 1382 | ``` 1383 | commit 1384 | end 1385 | ``` 1386 | 1387 | 1. We'll use these groups more later in the lab, but here's an example of using them to quickly check the sync status of all internal devices. 1388 | 1389 | ``` 1390 | devices device-group INTERNAL-DEVICES check-sync 1391 | ``` 1392 | 1393 |
Output 1394 | 1395 | ``` 1396 | sync-result { 1397 | device fw-inside-sw01 1398 | result in-sync 1399 | } 1400 | sync-result { 1401 | device leaf01-1 1402 | result in-sync 1403 | } 1404 | sync-result { 1405 | device leaf01-2 1406 | result in-sync 1407 | } 1408 | sync-result { 1409 | device leaf02-1 1410 | result in-sync 1411 | } 1412 | sync-result { 1413 | device leaf02-2 1414 | result in-sync 1415 | } 1416 | sync-result { 1417 | device spine01-1 1418 | result in-sync 1419 | } 1420 | sync-result { 1421 | device spine01-2 1422 | result in-sync 1423 | } 1424 | sync-result { 1425 | device vm-sw01 1426 | result in-sync 1427 | } 1428 | sync-result { 1429 | device vm-sw02 1430 | result in-sync 1431 | } 1432 | ``` 1433 | 1434 |
1435 | -------------------------------------------------------------------------------- /03-exploring-with-cli.md: -------------------------------------------------------------------------------- 1 | # Exploring the Network with the NSO CLI 2 | Now that NSO is installed, we have a running instance, and it's connected to our network, let's see what we can do with it. 3 | 4 | ## Device Configuration 5 | These first exercises will explore device configuration through NSO. We'll look at how NSO can tell you about the current configuration, as well as how you can update the configuration across your network with ease. 6 | 7 | ### Reading Device Configuration 8 | When you did the initial `sync-from` the network NSO retrieved all the current configurations of the devices and stored them in the "CDB". This is NSO's Configuration Database, and the heart of the "magic" that makes NSO so powerful. With the CDB, you now have access to the entire network's configuration from a single point through the NSO CLI, web ui, or through the variety of APIs NSO makes available. 9 | 10 | Even more exciting, this configuration isn't just another text file backup, but rather a fully modeled configuration. All of your network devices, even old legacy CLI devices, now have a fully parsed local snapshot of the configuration. If that didn't **WOW** you, just wait! 11 | 12 | 1. Start out by accessing the `ncs_cli` 13 | 14 | ```bash 15 | ncs_cli -C -u admin 16 | ``` 17 | 18 | 1. Like many CLI's, the NSO CLI allows for TAB completion, so as you enter commands make copious use of the TAB key. 19 | 1. We'll start out simple, just looking at the full running configuration for a single device `leaf01-1`. 20 | 21 | ```text 22 | show running-config devices device leaf01-1 config 23 | ``` 24 | 25 |
Partial Output 26 | 27 | ``` 28 | devices device leaf01-1 29 | config 30 | tailfned default-lacp-suspend-individual true 31 | version 9.2(2) Bios:version 32 | hostname leaf01-1 33 | feature hsrp 34 | feature ospf 35 | feature vpc 36 | feature interface-vlan 37 | feature lacp 38 | no feature ssh 39 | feature telnet 40 | cfs eth distribute 41 | username admin password 5 $1$KuOSBsvW$Cy0TSD..gEBGBPjzpDgf51 role network-admin 42 | username cisco password 5 $1$Nk7ZkwH0$fyiRmMMfIheqE3BqvcL0C1 role network-operator 43 | username cisco role network-admin 44 | no ip domain-lookup 45 | mac address-table notification mac-move 46 | rmon event 1 description FATAL(1) owner PMON@FATAL 47 | rmon event 2 description CRITICAL(2) owner PMON@CRITICAL 48 | rmon event 3 description ERROR(3) owner PMON@ERROR 49 | rmon event 4 description WARNING(4) owner PMON@WARNING 50 | rmon event 5 description INFORMATION(5) owner PMON@INFO 51 | no password strength-check 52 | vlan 1 53 | ! 54 | vlan 10 55 | name trusted-transit 56 | ! 57 | vlan 11 58 | name admin-systems 59 | ! 60 | vlan 12 61 | name mgmt 62 | ! 63 | vlan 100 64 | name dmz-transit 65 | ! 66 | vlan 101 67 | name prod-web 68 | ! 69 | vlan 102 70 | name prod-app 71 | ! 72 | vlan 103 73 | name prod-data 74 | ! 75 | vlan 201 76 | name dev-web 77 | ! 78 | vlan 202 79 | name dev-app 80 | ! 81 | vlan 203 82 | name dev-data 83 | ! 84 | vlan 900 85 | name guest-transit 86 | ! 87 | vlan 901 88 | name hotspot 89 | ! 90 | vlan 3001 91 | name backdoor-temp 92 | ! 93 | vrf context management 94 | ip route 0.0.0.0/0 172.16.30.254 95 | exit 96 | vrf context backdoor 97 | exit 98 | vrf context dmz 99 | ip route 0.0.0.0/0 10.225.250.4 100 | exit 101 | . 102 | . 103 | . 104 | ``` 105 |
106 | 107 | 1. This command should seem very familiar to any network engineer. Let's look at a couple of key details about the command. 108 | * `show` - you're looking to "see" some info about the system. No surprise here. 109 | * `running-config` - you're interested in the current "running configuration" from the CDB within NSO. This includes details about devices, but also about NSO itself. 110 | * `devices device leaf01-1` - we don't want the full running-configuration, but rather we are interested in a specific device. Each command following `running-config` drills into NSO's configuration, scoping the returned results. 111 | * `devices` - we are looking for details about devices. 112 | * `device` - we are looking for details about a specific device. 113 | * *Note: device `authgroups` also are under the `devices` keyword.* 114 | * `leaf01-1` is the device we want details on. 115 | * `config` - this is likely the most confusing bit to think about. This tells NSO that we want information about the devices configuration, but you might wonder what else there is. The answer is the details about how NSO connects to and communicates with the device. The `address`, `authgroup`, `ned-settings` all are part of NSO's details for a device. 116 | 117 | 1. That last point deserves a moment to explore. Run this command and see what else NSO has for a device. 118 | 119 | ``` 120 | show running-config devices device leaf01-1 | de-select config 121 | ``` 122 | 123 | > Note: the `de-select` keyword is a great way to remove unneeded elements of returned data. 124 | 125 |
Output 126 | 127 | ``` 128 | devices device leaf01-1 129 | address 172.16.30.103 130 | ssh host-key-verification none 131 | authgroup labadmin 132 | device-type cli ned-id cisco-nx-cli-5.13 133 | device-type cli protocol ssh 134 | state admin-state unlocked 135 | ! 136 | ``` 137 |
138 | 139 | 1. What you should see is the same configuration that we used to add this device into the NSO inventory, pretty neat huh! 140 | 141 | 1. Let's use the power of the modeled config a bit more with these next exercises. 142 | * Retrieve the list of vlans configured on the device 143 | 144 | ``` 145 | show running-config devices device leaf01-1 config nx:vlan 146 | ``` 147 | 148 |
Output 149 | 150 | ``` 151 | devices device leaf01-1 152 | config 153 | vlan 1 154 | ! 155 | vlan 10 156 | name trusted-transit 157 | ! 158 | vlan 11 159 | name admin-systems 160 | ! 161 | vlan 12 162 | name mgmt 163 | ! 164 | vlan 100 165 | name dmz-transit 166 | ! 167 | vlan 101 168 | name prod-web 169 | ! 170 | vlan 102 171 | name prod-app 172 | ! 173 | vlan 103 174 | name prod-data 175 | ! 176 | vlan 201 177 | name dev-web 178 | ! 179 | vlan 202 180 | name dev-app 181 | ! 182 | vlan 203 183 | name dev-data 184 | ! 185 | vlan 900 186 | name guest-transit 187 | ! 188 | vlan 901 189 | name hotspot 190 | ! 191 | vlan 3001 192 | name backdoor-temp 193 | ``` 194 |
195 | 196 | > The `nx:vlan` highlights the use of NEDs to interact with the devices. Each type of device, and therefore NED, has it's own data model for configuration and operational data. The `nx:` indicates the NED, or specifically the YANG model, that is used for the data. 197 | 198 | * What if you wanted the data in a format better for programmability.. let's say JSON. 199 | 200 | ``` 201 | show running-config devices device leaf01-1 config nx:vlan | display json 202 | ``` 203 | 204 |
Output 205 | 206 | ``` 207 | { 208 | "data": { 209 | "tailf-ncs:devices": { 210 | "device": [ 211 | { 212 | "name": "leaf01-1", 213 | "config": { 214 | "tailf-ned-cisco-nx:vlan": { 215 | "vlan-list": [ 216 | { 217 | "id": 1 218 | }, 219 | { 220 | "id": 10, 221 | "name": "trusted-transit" 222 | }, 223 | { 224 | "id": 11, 225 | "name": "admin-systems" 226 | }, 227 | { 228 | "id": 12, 229 | "name": "mgmt" 230 | }, 231 | { 232 | "id": 100, 233 | "name": "dmz-transit" 234 | }, 235 | { 236 | "id": 101, 237 | "name": "prod-web" 238 | }, 239 | { 240 | "id": 102, 241 | "name": "prod-app" 242 | }, 243 | { 244 | "id": 103, 245 | "name": "prod-data" 246 | }, 247 | { 248 | "id": 201, 249 | "name": "dev-web" 250 | }, 251 | { 252 | "id": 202, 253 | "name": "dev-app" 254 | }, 255 | { 256 | "id": 203, 257 | "name": "dev-data" 258 | }, 259 | { 260 | "id": 900, 261 | "name": "guest-transit" 262 | }, 263 | { 264 | "id": 901, 265 | "name": "hotspot" 266 | }, 267 | { 268 | "id": 3001, 269 | "name": "backdoor-temp" 270 | } 271 | ] 272 | } 273 | } 274 | } 275 | ] 276 | } 277 | } 278 | } 279 | ``` 280 |
281 | 282 | > `display xml` also works! 283 | 284 | * What about the VLAN interfaces? 285 | 286 | ``` 287 | show running-config devices device leaf01-1 config nx:interface Vlan 288 | ``` 289 | 290 |
Partial Output 291 | 292 | ``` 293 | devices device leaf01-1 294 | config 295 | interface Vlan1 296 | no shutdown 297 | no ip redirects 298 | no ipv6 redirects 299 | exit 300 | interface Vlan10 301 | no shutdown 302 | vrf member trusted 303 | ip address 10.225.250.2/29 304 | ip ospf passive-interface false 305 | no ip redirects 306 | ip router ospf 1 area 0.0.0.0 307 | no ipv6 redirects 308 | hsrp version 2 309 | hsrp 1 ipv4 310 | ip 10.225.250.1 311 | preempt 312 | priority 110 313 | exit 314 | exit 315 | interface Vlan11 316 | no shutdown 317 | vrf member trusted 318 | ip address 10.225.1.2/24 319 | no ip redirects 320 | ip router ospf 1 area 0.0.0.0 321 | no ipv6 redirects 322 | hsrp version 2 323 | hsrp 1 ipv4 324 | ip 10.225.1.1 325 | preempt 326 | priority 110 327 | exit 328 | exit 329 | interface Vlan12 330 | no shutdown 331 | vrf member trusted 332 | ip address 10.225.2.2/24 333 | no ip redirects 334 | ip router ospf 1 area 0.0.0.0 335 | no ipv6 redirects 336 | hsrp version 2 337 | hsrp 1 ipv4 338 | ip 10.225.2.1 339 | preempt 340 | priority 110 341 | exit 342 | exit 343 | . 344 | . 345 | ``` 346 |
347 | 348 | * This one should wow you... what about just the IP addresses for all SVIs. 349 | 350 | ``` 351 | show running-config devices device leaf01-1 config nx:interface Vlan * ip address 352 | ``` 353 | 354 |
Output 355 | 356 | ``` 357 | devices device leaf01-1 358 | config 359 | interface Vlan10 360 | ip address 10.225.250.2/29 361 | exit 362 | interface Vlan11 363 | ip address 10.225.1.2/24 364 | exit 365 | interface Vlan12 366 | ip address 10.225.2.2/24 367 | exit 368 | interface Vlan100 369 | ip address 10.225.250.34/29 370 | exit 371 | interface Vlan101 372 | ip address 10.225.9.2/24 373 | exit 374 | interface Vlan102 375 | ip address 10.225.10.2/24 376 | exit 377 | interface Vlan103 378 | ip address 10.225.11.2/24 379 | exit 380 | interface Vlan201 381 | ip address 10.225.17.2/24 382 | exit 383 | interface Vlan202 384 | ip address 10.225.18.2/24 385 | exit 386 | interface Vlan203 387 | ip address 10.225.19.2/24 388 | exit 389 | interface Vlan900 390 | ip address 10.225.250.50/29 391 | exit 392 | interface Vlan901 393 | ip address 10.225.49.2/24 394 | exit 395 | interface Vlan3001 396 | ip address 172.16.30.2/24 397 | exit 398 | ``` 399 |
400 | 401 | > NSO allows the use of wildcards in commands. We'll use this more later. 402 | 403 | ### Updating Device Configuration 404 | Now that you've seen how NSO can be used to read the current network configuration, let's see how we can update it. 405 | 406 | 1. As always, start out at the `ncs_cli`. 407 | 408 | ``` 409 | ncs_cli -C -u admin 410 | ``` 411 | 412 | 1. Since we'll be updating the configuration, we need to go into `config` mode. 413 | 414 | ``` 415 | config 416 | ``` 417 | 418 | 1. Notice that the prompt changes in an expected way to indicate our new mode. 419 | 420 | ``` 421 | Entering configuration mode terminal 422 | admin@ncs(config)# 423 | ``` 424 | 425 | 1. From here we can change the configuration for anything in NSO, but we want to update a devices configuration so we'll need to move into that device. 426 | 427 | ``` 428 | devices device leaf01-1 429 | ``` 430 | 431 | 1. Again, look at the prompt. It will help you understand where you are in context. 432 | 433 | ``` 434 | admin@ncs(config-device-leaf01-1)# 435 | ``` 436 | 437 | 1. Remember from our prior exercise that the device configuration is under the `config` section in the device model. So we'll enter another `config` to indicate we'll be configuring the device. 438 | 439 | ``` 440 | config 441 | ``` 442 | 443 | 1. The prompt once again changes (this is the last time I'll mention it, but it's important to keep an eye on it for clues as to where you're current working.) 444 | 445 | ``` 446 | admin@ncs(config-config)# 447 | ``` 448 | 449 | 1. Rather than continuing to add additional keywords to the prompt, NSO shortens it here to just `config-config` to indicate a nested config mode. This is to keep the prompt reasonable in size. But if you ever want to know "where" you are, NSO takes inspiration from the "print working directory" `pwd` command from Linux. Use it to see where you are. 450 | 451 | ``` 452 | pwd 453 | ``` 454 | 455 |
Output 456 | 457 | ``` 458 | Current submode path: 459 | devices device leaf01-1 \ config 460 | ``` 461 |
462 | 463 | > This is a VERY handy way to assist with navigation. 464 | 465 | 1. Okay, let's get to that configuration change. And what's better for a configuration change in the network than adding a new VLAN and interface! Enter these commands. 466 | 467 | > Don't forget you can use TAB completion. And notice the use of `nx:` in the configuration to indicate the NED or device type we are working with. Also note that the tab completion is **case sensitive** for that first letter. Common mistakes are nx:interface vlan instead of nx:interface Vlan. 468 | 469 | ``` 470 | nx:vlan 42 471 | name TheAnswer 472 | exit 473 | nx:interface Vlan 42 474 | description "Answer to the Ultimate Question of Life, the Universe, and Everything" 475 | ip address 10.42.42.42/24 476 | exit 477 | ``` 478 | 479 | 1. What we've done is stage some new configuration within NSO, but it isn't actually "live" yet. To make it live we need to `commit` it to the CDB, which will then push the updates out to the network. Before we do that, let's checkout another very handy feature of NSO. 480 | 481 | 1. First jump to the `top` of `config` mode. 482 | 483 | ``` 484 | top 485 | ``` 486 | 487 | > You could just type `exit` over and over again, but `top` is so much faster. 488 | 489 | 1. Now let's look at the current configuration that is waiting to be committed. 490 | 491 | ``` 492 | show configuration 493 | ``` 494 | 495 |
Output 496 | 497 | ``` 498 | devices device leaf01-1 499 | config 500 | vlan 42 501 | name TheAnswer 502 | ! 503 | interface Vlan42 504 | no shutdown 505 | description Answer to the Ultimate Question of Life, the Universe, and Everything 506 | ip address 10.42.42.42/24 507 | exit 508 | ``` 509 |
510 | 511 | 1. This is a very handy way to check your work before you commit it. And suppose you were doing some work to prepare for a larger automation project where you wanted to make this change using the NETCONF or RESTCONF API for NSO... you can see what the XML version of this new configuration is using the `display xml` option and see the complete payload for an RPC `` 512 | 513 | ``` 514 | show configuration | display xml 515 | ``` 516 | 517 |
Output 518 | 519 | ```xml 520 | 521 | 522 | leaf01-1 523 | 524 | 525 | 526 | 42 527 | TheAnswer 528 | 529 | 530 | 531 | 532 | 42 533 | Answer to the Ultimate Question of Life, the Universe, and Everything 534 | 535 |
536 | 10.42.42.42/24 537 |
538 | 539 | 540 | 541 | 542 | 543 | 544 | ``` 545 |
546 | 547 | 1. One last question you might have before you're ready to `commit` this to the network, is what will NSO actually SEND to your device? NSO lets you do a `dry-run` before committing, and it has a handy `native` format that shows you exactly what will be sent away. 548 | 549 | ``` 550 | commit dry-run outformat native 551 | ``` 552 | 553 |
Output 554 | 555 | ``` 556 | native { 557 | device { 558 | name leaf01-1 559 | data vlan 42 560 | name TheAnswer 561 | ! 562 | interface Vlan42 563 | no shutdown 564 | description Answer to the Ultimate Question of Life, the Universe, and Everything 565 | ip address 10.42.42.42/24 566 | exit 567 | } 568 | } 569 | ``` 570 |
571 | 572 | 1. And now we are ready to make the change. 573 | 574 | ``` 575 | commit 576 | ``` 577 | 578 |
Output 579 | 580 | ``` 581 | Commit complete. 582 | ``` 583 |
584 | 585 | 1. You can see that all staged changes have been completed with another look. 586 | 587 | ``` 588 | show configuration 589 | ``` 590 | 591 |
Output 592 | 593 | ``` 594 | % No configuration changes found. 595 | ``` 596 |
597 | 598 | #### Bonus: Rolling back configurations 599 | We've all been there... you make a network change and then immediately realize you made a mistake and need to undo it... but some changes are HUGE. How do you roll it all back? With NSO it's super easy. 600 | 601 | 1. Let's see what it would take to rollback the latest change made. 602 | 603 | ``` 604 | show configuration rollback changes 605 | ``` 606 | 607 |
Output 608 | 609 | ``` 610 | devices device leaf01-1 611 | config 612 | no vlan 42 613 | no interface Vlan42 614 | ``` 615 |
616 | 617 | 1. Now let's load up these changes. Jump into config mode and setup the rollback. 618 | 619 | ``` 620 | rollback configuration 621 | ``` 622 | 623 | 1. This "stages" those changes like any network change. You can see it with `show configuration`. 624 | 625 |
Output 626 | 627 | ``` 628 | devices device leaf01-1 629 | config 630 | no vlan 42 631 | no interface Vlan42 632 | ``` 633 |
634 | 635 | 1. And you can checkout what commands will be run on the device to accomplish this before committing. 636 | 637 | ``` 638 | commit dry-run outformat native 639 | ``` 640 | 641 |
Output 642 | 643 | ``` 644 | native { 645 | device { 646 | name leaf01-1 647 | data vlan 42 648 | no name 649 | ! 650 | no vlan 42 651 | no interface Vlan42 652 | } 653 | } 654 | ``` 655 |
656 | 657 | 1. And complete the rollback 658 | 659 | ``` 660 | commit 661 | ``` 662 | 663 | Pretty nice right! A couple of key points about rollback. 664 | 665 | * NSO stores rollback files for every change, and you can load up a specific change by referencing the ID number of a change. 666 | * Each `commit` is a rollback. So if a single commit updates 10 devices, and 30 configuration lines on each device, a rollback will undo all that configuration. 667 | * Depending on what has changed in the network since the commit you are trying to rollback, NSO may NOT be able to execute the rollback. It will notify you of conflicts. 668 | 669 | ### Device Templates 670 | In the previous example we looked at managing the configuration of devices, per device. But what about when you want to configure something on many devices? There are several ways NSO can help with this, but the simplest way to get started is using Device Templates. 671 | 672 | In this exercise we'll build a simple device template that can be used to configure the DNS server on network devices. 673 | 674 | 1. Go ahead and jump into `ncs_cli` like before, and enter `config` mode. 675 | 1. We'll iterate on our device template a couple times, making it more powerful, but for now we'll give a basic template. 676 | 677 | ``` 678 | devices template SET-DNS-SERVER 679 | ned-id cisco-nx-cli-5.13 680 | config 681 | ip name-server servers 208.67.222.222 682 | ip name-server servers 208.67.220.220 683 | ``` 684 | 685 | 1. Let's see what this looks like to NSO. 686 | 687 | ``` 688 | show configuration 689 | ``` 690 | 691 |
Output 692 | 693 | ``` 694 | devices template SET-DNS-SERVER 695 | ned-id cisco-nx-cli-5.13 696 | config 697 | ip name-server servers [ 208.67.222.222 208.67.220.220 ] 698 | ``` 699 |
700 | 701 | > One thing to notice here is how NSO takes the input of 2 different name servers and combines them into a list object within the CDB. 702 | 703 | 1. The first version of our template only addresses NX-OS devices (based on the `ned-id` block). We'll circle back to add other network devices in a moment, but let's test this first version. 704 | 1. Commit the new template to NSO. 705 | 706 | ``` 707 | commit 708 | ``` 709 | 710 | 1. Jump back to the `top` and let's test out the template. 711 | 712 | ``` 713 | top 714 | devices device leaf01-1 apply-template template-name SET-DNS-SERVER 715 | ``` 716 | 717 |
Output 718 | 719 | ``` 720 | apply-template-result { 721 | device leaf01-1 722 | result ok 723 | } 724 | ``` 725 |
726 | 727 | 1. Like other configuration changes, this simply stages a configuration to be pushed. Look at what is staged. 728 | 729 | ``` 730 | show configuration 731 | ``` 732 | 733 |
Output 734 | 735 | ``` 736 | devices device leaf01-1 737 | config 738 | ip name-server 208.67.220.220 208.67.222.222 739 | ``` 740 |
741 | 742 | 1. Looks good, but we aren't done yet... let's un-stage these changes. 743 | 744 | ``` 745 | revert 746 | ``` 747 | 748 | 1. At the prompt, enter `yes` to confirm. 749 | 750 | ``` 751 | ! EXAMPLE 752 | All configuration changes will be lost. Proceed? [yes, NO] yes 753 | ``` 754 | 755 | 1. We're now going to update the template to support IOS and ASA devices as well. Enter this configuration into NSO. 756 | 757 | ``` 758 | devices template SET-DNS-SERVER 759 | ned-id cisco-ios-cli-6.42 760 | config 761 | ip name-server name-server-list 208.67.222.222 762 | ip name-server name-server-list 208.67.220.220 763 | exit 764 | exit 765 | 766 | ! 2 exits to return back to the 'config-template-SET-DNS-SERVER' context 767 | ned-id cisco-asa-cli-6.7 768 | config 769 | dns domain-lookup mgmt 770 | dns server-group DefaultDNS 771 | name-server 208.67.220.220 772 | name-server 208.67.222.222 773 | ``` 774 | 775 | > Now our template knows how to configure the DNS Servers on all three of our network types. 776 | 777 | 1. Save the changes to the template and return to `top` 778 | 779 | ``` 780 | commit 781 | top 782 | ``` 783 | 784 | 1. Now we'll use the `device-groups` that we setup initially to push this change out to the entire network with super ease. 785 | 786 | ``` 787 | devices device-group ALL apply-template template-name SET-DNS-SERVER 788 | ``` 789 | 790 | 791 |
Output 792 | 793 | ``` 794 | apply-template-result { 795 | device dmz-fw01-1 796 | result ok 797 | } 798 | apply-template-result { 799 | device dmz-rtr02-1 800 | result ok 801 | } 802 | apply-template-result { 803 | device dmz-rtr02-2 804 | result ok 805 | } 806 | apply-template-result { 807 | device dmz-sw01-1 808 | result ok 809 | } 810 | apply-template-result { 811 | device dmz-sw01-2 812 | result ok 813 | } 814 | apply-template-result { 815 | device dmz-sw02-1 816 | result ok 817 | } 818 | apply-template-result { 819 | device dmz-sw02-2 820 | result ok 821 | } 822 | apply-template-result { 823 | device fw-inside-sw01 824 | result ok 825 | } 826 | apply-template-result { 827 | device fw-outside-sw01 828 | result ok 829 | } 830 | apply-template-result { 831 | device fw01 832 | result ok 833 | } 834 | apply-template-result { 835 | device fw02 836 | result ok 837 | } 838 | apply-template-result { 839 | device internet-rtr 840 | result ok 841 | } 842 | apply-template-result { 843 | device leaf01-1 844 | result ok 845 | } 846 | apply-template-result { 847 | device leaf01-2 848 | result ok 849 | } 850 | apply-template-result { 851 | device leaf02-1 852 | result ok 853 | } 854 | apply-template-result { 855 | device leaf02-2 856 | result ok 857 | } 858 | apply-template-result { 859 | device spine01-1 860 | result ok 861 | } 862 | apply-template-result { 863 | device spine01-2 864 | result ok 865 | } 866 | apply-template-result { 867 | device vm-sw01 868 | result ok 869 | } 870 | apply-template-result { 871 | device vm-sw02 872 | result ok 873 | } 874 | ``` 875 |
876 | 877 | > Pretty awesome right? One simple command and you've updated every device all at once. That's AUTOMATION! 878 | 879 | 1. And let's see what configuration is ready to be sent to the devices. You can look at `show configuration` if you'd like, but we'll look at the native configuration. 880 | 881 | ``` 882 | commit dry-run outformat native 883 | ``` 884 | 885 |
Output 886 | 887 | ``` 888 | native { 889 | device { 890 | name dmz-rtr02-1 891 | data ip name-server 208.67.222.222 892 | ip name-server 208.67.220.220 893 | } 894 | device { 895 | name dmz-rtr02-2 896 | data ip name-server 208.67.222.222 897 | ip name-server 208.67.220.220 898 | } 899 | device { 900 | name dmz-sw01-1 901 | data ip name-server 208.67.220.220 208.67.222.222 902 | } 903 | device { 904 | name dmz-sw01-2 905 | data ip name-server 208.67.220.220 208.67.222.222 906 | } 907 | device { 908 | name dmz-sw02-1 909 | data ip name-server 208.67.220.220 208.67.222.222 910 | } 911 | device { 912 | name dmz-sw02-2 913 | data ip name-server 208.67.220.220 208.67.222.222 914 | } 915 | device { 916 | name fw-inside-sw01 917 | data ip name-server 208.67.222.222 918 | ip name-server 208.67.220.220 919 | } 920 | device { 921 | name fw-outside-sw01 922 | data ip name-server 208.67.222.222 923 | ip name-server 208.67.220.220 924 | } 925 | device { 926 | name fw01 927 | data dns domain-lookup mgmt 928 | dns server-group DefaultDNS 929 | name-server 208.67.220.220 930 | name-server 208.67.222.222 931 | exit 932 | } 933 | device { 934 | name fw02 935 | data dns domain-lookup mgmt 936 | dns server-group DefaultDNS 937 | name-server 208.67.220.220 938 | name-server 208.67.222.222 939 | exit 940 | } 941 | device { 942 | name internet-rtr 943 | data ip name-server 208.67.222.222 944 | ip name-server 208.67.220.220 945 | } 946 | device { 947 | name leaf01-1 948 | data ip name-server 208.67.220.220 208.67.222.222 949 | } 950 | device { 951 | name leaf01-2 952 | data ip name-server 208.67.220.220 208.67.222.222 953 | } 954 | device { 955 | name leaf02-1 956 | data ip name-server 208.67.220.220 208.67.222.222 957 | } 958 | device { 959 | name leaf02-2 960 | data ip name-server 208.67.220.220 208.67.222.222 961 | } 962 | device { 963 | name spine01-1 964 | data ip name-server 208.67.220.220 208.67.222.222 965 | } 966 | device { 967 | name spine01-2 968 | data ip name-server 208.67.220.220 208.67.222.222 969 | } 970 | device { 971 | name vm-sw01 972 | data ip name-server 208.67.222.222 973 | ip name-server 208.67.220.220 974 | } 975 | device { 976 | name vm-sw02 977 | data ip name-server 208.67.222.222 978 | ip name-server 208.67.220.220 979 | } 980 | } 981 | ``` 982 |
983 | 984 | 1. Finally, push it out to the devices. 985 | 986 | ``` 987 | commit 988 | ``` 989 | 990 | This is just a quick introduction to templates. Templates have many other uses and features, we'll see more in later exercises. 991 | 992 | ## Device Operational State 993 | We'll leave device configuration behind for a little bit and see what NSO offers from an operational state view. 994 | 995 | Much of network automation, particularly the early projects relate not to updating configuration, but rather gathering details about the current state of the network for visibility and troubleshooting. 996 | 997 | Along with modeling out the device configuration, NEDs will often include the ability to read current operational state from the network - similar to running `show` commands on a device. We'll checkout some of them now. 998 | 999 | 1. Go ahead and launch `ncs_cli`, but **don't** go into `config` mode. 1000 | 1001 | ### Platform Info 1002 | Here's one that has saved me all sorts of time - basic platform information. As part of the initial connection to a device, NSO queries the device for it's model, serial, version, etc. 1003 | 1004 | 1. Take a look at what is gathered. 1005 | 1006 | ``` 1007 | show devices device leaf01-1 platform 1008 | ``` 1009 | 1010 |
Output 1011 | 1012 | ``` 1013 | platform name NX-OS 1014 | platform version 9.2(2) 1015 | platform model "cisco Nexus9000 9000v Chassis " 1016 | platform serial-number 9EMO859VJOO 1017 | ``` 1018 |
1019 | 1020 | 1. Of if you just want the serial number, you can of course... 1021 | 1022 | ``` 1023 | show devices device leaf01-1 platform serial-number 1024 | ``` 1025 | 1026 | 1. And to go even bigger... what if you want **ALL** serial numbers? 1027 | 1028 | ``` 1029 | show devices device * platform serial-number 1030 | ``` 1031 | 1032 |
Output 1033 | 1034 | ``` 1035 | SERIAL 1036 | NAME NUMBER 1037 | ------------------------------ 1038 | dmz-fw01-1 9AHFCCB49J1 1039 | dmz-rtr01-1 97DHMECAG7T 1040 | dmz-rtr02-1 97DHMECAG7T 1041 | dmz-rtr02-2 9X83MITDMNZ 1042 | dmz-sw01-1 9TJ2V92YN1J 1043 | dmz-sw01-2 9I95731WUFD 1044 | dmz-sw02-1 9S151GTQ5EX 1045 | dmz-sw02-2 9SH0ETX3AU3 1046 | fw-inside-sw01 9YSYIAS6DX5 1047 | fw-outside-sw01 947MPGL9D9W 1048 | fw01 9AFK2A2QF29 1049 | fw02 9ALWBDLW2L6 1050 | internet-rtr 9AXL4JQRMM6 1051 | leaf01-1 9EMO859VJOO 1052 | leaf01-2 97HPIKZ4FFI 1053 | leaf02-1 9I6F9OKAEOY 1054 | leaf02-2 9DMNLYGAICX 1055 | spine01-1 957MQP34EU4 1056 | spine01-2 9HLJ93K3214 1057 | vm-sw01 9PF0O7C0LZE 1058 | vm-sw02 9YKKIHL53I5 1059 | ``` 1060 |
1061 | 1062 | > That wildcard is super handy huh?!? 1063 | 1064 | #### Live Status 1065 | Devices have a `live-status` part of the model that indicates details that NSO will read from the device at the time of execution, rather than pulled from the CDB. 1066 | 1067 | 1. Let's check on the current status of the port-channels on a device. 1068 | 1069 | ``` 1070 | show devices device leaf01-1 live-status port-channel 1071 | ``` 1072 | 1073 |
Output 1074 | 1075 | ``` 1076 | PORT 1077 | GROUP PORT CHANNEL LAYER STATUS TYPE PRTCL PORT STATUS 1078 | ------------------------------------------------------------------------ 1079 | 1 port-channel1 S U Eth LACP Ethernet1/1 P 1080 | Ethernet1/2 P 1081 | 2 port-channel2 S U Eth LACP Ethernet1/3 P 1082 | Ethernet1/4 P 1083 | 3 port-channel3 S U Eth LACP Ethernet1/11 P 1084 | ``` 1085 |
1086 | 1087 | 1. Or maybe the routing table. 1088 | 1089 | ``` 1090 | show devices device leaf01-1 live-status ip route 1091 | ``` 1092 | 1093 |
Partial Output 1094 | 1095 | ``` 1096 | live-status ip route vrf backdoor 1097 | prefix 172.16.30.0/24 1098 | ucast-nhops 1 1099 | mcast-nhops 0 1100 | attached true 1101 | path 172.16.30.2 1102 | uptime P4DT2H41M12S 1103 | ifname Vlan3001 1104 | pref 0 1105 | metric 0 1106 | clientname direct 1107 | ubest true 1108 | prefix 172.16.30.1/32 1109 | ucast-nhops 1 1110 | mcast-nhops 0 1111 | attached true 1112 | path 172.16.30.1 1113 | uptime P4DT2H40M50S 1114 | ifname Vlan3001 1115 | pref 0 1116 | metric 0 1117 | clientname hsrp 1118 | ubest true 1119 | prefix 172.16.30.2/32 1120 | ucast-nhops 1 1121 | mcast-nhops 0 1122 | attached true 1123 | path 172.16.30.2 1124 | uptime P4DT2H41M12S 1125 | ifname Vlan3001 1126 | pref 0 1127 | metric 0 1128 | clientname local 1129 | ubest true 1130 | live-status ip route vrf default 1131 | live-status ip route vrf dmz 1132 | prefix 0.0.0.0/0 1133 | ucast-nhops 1 1134 | mcast-nhops 0 1135 | attached false 1136 | path 10.225.250.4 1137 | uptime P4DT2H39M6S 1138 | pref 1 1139 | metric 0 1140 | clientname static 1141 | ubest true 1142 | prefix 10.225.1.0/24 1143 | ucast-nhops 1 1144 | mcast-nhops 0 1145 | attached false 1146 | path 10.225.250.36 1147 | uptime P4DT2H38M58S 1148 | ifname Vlan100 1149 | pref 110 1150 | metric 90 1151 | clientname ospf-1 1152 | ubest true 1153 | . 1154 | . 1155 | ``` 1156 |
1157 | 1158 | * Uh, oh... the default formating isn't super friendly to the human reader. Luckily NSO can force a table format for output. 1159 | 1160 | ``` 1161 | show devices device leaf01-1 live-status ip route | tab 1162 | ``` 1163 | 1164 |
Partial Output 1165 | 1166 | ``` 1167 | UCAST MCAST 1168 | NAME IPPREFIX NHOPS NHOPS ATTACHED IPNEXTHOP UPTIME IFNAME PREF METRIC CLIENTNAME UBEST 1169 | ------------------------------------------------------------------------------------------------------------------------------ 1170 | backdoor 172.16.30.0/24 1 0 true 172.16.30.2 P4DT2H44M33S Vlan3001 0 0 direct true 1171 | 172.16.30.1/32 1 0 true 172.16.30.1 P4DT2H44M11S Vlan3001 0 0 hsrp true 1172 | 172.16.30.2/32 1 0 true 172.16.30.2 P4DT2H44M33S Vlan3001 0 0 local true 1173 | default 1174 | dmz 0.0.0.0/0 1 0 false 10.225.250.4 P4DT2H42M27S - 1 0 static true 1175 | 10.225.1.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1176 | 10.225.10.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1177 | 10.225.11.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1178 | 10.225.17.0/24 1 0 true 10.225.17.2 P4DT2H44M49S Vlan201 0 0 direct true 1179 | 10.225.17.1/32 1 0 true 10.225.17.1 P4DT2H44M26S Vlan201 0 0 hsrp true 1180 | 10.225.17.2/32 1 0 true 10.225.17.2 P4DT2H44M49S Vlan201 0 0 local true 1181 | 10.225.18.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1182 | 10.225.19.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1183 | 10.225.2.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1184 | 10.225.250.0/29 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 50 ospf-1 true 1185 | 10.225.250.16/29 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 51 ospf-1 true 1186 | 10.225.250.24/29 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 51 ospf-1 true 1187 | 10.225.250.32/29 1 0 true 10.225.250.34 P4DT2H45M1S Vlan100 0 0 direct true 1188 | 10.225.250.33/32 1 0 true 10.225.250.33 P4DT2H44M39S Vlan100 0 0 hsrp true 1189 | 10.225.250.34/32 1 0 true 10.225.250.34 P4DT2H45M1S Vlan100 0 0 local true 1190 | 10.225.250.48/29 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 50 ospf-1 true 1191 | 10.225.250.8/29 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 50 ospf-1 true 1192 | 10.225.49.0/24 1 0 false 10.225.250.36 P4DT2H42M19S Vlan100 110 90 ospf-1 true 1193 | 10.225.64.0/24 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 20 ospf-1 true 1194 | 10.225.64.0/27 1 0 false 10.225.250.36 P4DT2H42M27S Vlan100 110 20 ospf-1 true 1195 | 10.225.9.0/24 1 0 true 10.225.9.2 P4DT2H44M58S Vlan101 0 0 direct true 1196 | 1197 | ``` 1198 |
1199 | 1200 | There is a lot of information available through `live-status` feel free to poke around and explore. 1201 | 1202 | ## Live Status and Arbitrary Commands 1203 | NSO is great, but occasionally the NED may not support the specific configuration bit, or operational data that you're looking for. Now when this happens for a customer, they can easily open a support ticket with the Cisco NSO team explaining what is missing, and the NEDs can be updated to support what is needed. These updates often only take a few days to be vetted, tested, and implemented by Cisco and updated NEDs made available to the customer. 1204 | 1205 | > Note: Once you become familiar with the more advanced topics around NSO development, you could even build your own packages and code to add these features yourself. 1206 | 1207 | However, for immediate needs, `live-status` supports sending arbitrary commands to a network device and returning the result. Let's see a quick example of this in action. 1208 | 1209 | 1. Suppose you needed to check the license usage on all your Nexus switches. This isn't data that the NED currently supports (though I probably should open a request to have it added), so we'll use `live-status` to gather the info. 1210 | 1211 | 1. First, let's check the status on a single device. 1212 | 1213 | ``` 1214 | devices device leaf01-1 live-status exec show license usage 1215 | ``` 1216 | 1217 |
Output 1218 | 1219 | ``` 1220 | result 1221 | Feature Ins Lic Status Expiry Date Comments 1222 | Count 1223 | -------------------------------------------------------------------------------- 1224 | N9K_LIC_1G No - Unused - 1225 | VPN_FABRIC No - Unused - 1226 | NXOS_OE_PKG No - Unused - 1227 | FCOE_NPV_PKG No - Unused - 1228 | SECURITY_PKG No 0 Unused - 1229 | N9K_UPG_EX_10G No - Unused - 1230 | TP_SERVICES_PKG No - Unused - 1231 | NXOS_ADVANTAGE_GF No - Unused - 1232 | NXOS_ADVANTAGE_M4 No - Unused - 1233 | NXOS_ADVANTAGE_XF No - Unused - 1234 | NXOS_ESSENTIALS_GF No - Unused - 1235 | NXOS_ESSENTIALS_M4 No - Unused - 1236 | NXOS_ESSENTIALS_XF No - Unused - 1237 | SAN_ENTERPRISE_PKG No - Unused - 1238 | PORT_ACTIVATION_PKG No 0 Unused - 1239 | NETWORK_SERVICES_PKG No - Unused - 1240 | NXOS_ADVANTAGE_M8-16 No - Unused - 1241 | NXOS_ESSENTIALS_M8-16 No - Unused - 1242 | FC_PORT_ACTIVATION_PKG No 0 Unused - 1243 | LAN_ENTERPRISE_SERVICES_PKG No - Unused - 1244 | -------------------------------------------------------------------------------- 1245 | ``` 1246 |
1247 | 1248 | > Notice that this isn't a `show` command. 1249 | 1250 | 1. Now we'll use wild-card commands to run the same against all the `leaf` switches. 1251 | 1252 | > Note: You can't use `live-status` with `device-groups` because a group of device could leverage different NEDs. 1253 | 1254 | ``` 1255 | devices device leaf* live-status exec show license usage 1256 | ``` 1257 | 1258 |
Partial Output 1259 | 1260 | ``` 1261 | devices device leaf01-1 live-status exec show 1262 | result 1263 | Feature Ins Lic Status Expiry Date Comments 1264 | Count 1265 | -------------------------------------------------------------------------------- 1266 | N9K_LIC_1G No - Unused - 1267 | VPN_FABRIC No - Unused - 1268 | NXOS_OE_PKG No - Unused - 1269 | FCOE_NPV_PKG No - Unused - 1270 | SECURITY_PKG No 0 Unused - 1271 | N9K_UPG_EX_10G No - Unused - 1272 | TP_SERVICES_PKG No - Unused - 1273 | NXOS_ADVANTAGE_GF No - Unused - 1274 | NXOS_ADVANTAGE_M4 No - Unused - 1275 | NXOS_ADVANTAGE_XF No - Unused - 1276 | NXOS_ESSENTIALS_GF No - Unused - 1277 | NXOS_ESSENTIALS_M4 No - Unused - 1278 | NXOS_ESSENTIALS_XF No - Unused - 1279 | SAN_ENTERPRISE_PKG No - Unused - 1280 | PORT_ACTIVATION_PKG No 0 Unused - 1281 | NETWORK_SERVICES_PKG No - Unused - 1282 | NXOS_ADVANTAGE_M8-16 No - Unused - 1283 | NXOS_ESSENTIALS_M8-16 No - Unused - 1284 | FC_PORT_ACTIVATION_PKG No 0 Unused - 1285 | LAN_ENTERPRISE_SERVICES_PKG No - Unused - 1286 | -------------------------------------------------------------------------------- 1287 | 1288 | devices device leaf01-2 live-status exec show 1289 | result 1290 | Feature Ins Lic Status Expiry Date Comments 1291 | Count 1292 | -------------------------------------------------------------------------------- 1293 | N9K_LIC_1G No - Unused - 1294 | VPN_FABRIC No - Unused - 1295 | NXOS_OE_PKG No - Unused - 1296 | FCOE_NPV_PKG No - Unused - 1297 | SECURITY_PKG No 0 Unused - 1298 | N9K_UPG_EX_10G No - Unused - 1299 | TP_SERVICES_PKG No - Unused - 1300 | NXOS_ADVANTAGE_GF No - Unused - 1301 | NXOS_ADVANTAGE_M4 No - Unused - 1302 | NXOS_ADVANTAGE_XF No - Unused - 1303 | NXOS_ESSENTIALS_GF No - Unused - 1304 | NXOS_ESSENTIALS_M4 No - Unused - 1305 | NXOS_ESSENTIALS_XF No - Unused - 1306 | SAN_ENTERPRISE_PKG No - Unused - 1307 | PORT_ACTIVATION_PKG No 0 Unused - 1308 | NETWORK_SERVICES_PKG No - Unused - 1309 | NXOS_ADVANTAGE_M8-16 No - Unused - 1310 | NXOS_ESSENTIALS_M8-16 No - Unused - 1311 | FC_PORT_ACTIVATION_PKG No 0 Unused - 1312 | LAN_ENTERPRISE_SERVICES_PKG No - Unused - 1313 | -------------------------------------------------------------------------------- 1314 | 1315 | devices device leaf02-1 live-status exec show 1316 | result 1317 | Feature Ins Lic Status Expiry Date Comments 1318 | Count 1319 | -------------------------------------------------------------------------------- 1320 | N9K_LIC_1G No - Unused - 1321 | VPN_FABRIC No - Unused - 1322 | NXOS_OE_PKG No - Unused - 1323 | FCOE_NPV_PKG No - Unused - 1324 | SECURITY_PKG No 0 Unused - 1325 | N9K_UPG_EX_10G No - Unused - 1326 | TP_SERVICES_PKG No - Unused - 1327 | NXOS_ADVANTAGE_GF No - Unused - 1328 | NXOS_ADVANTAGE_M4 No - Unused - 1329 | NXOS_ADVANTAGE_XF No - Unused - 1330 | NXOS_ESSENTIALS_GF No - Unused - 1331 | NXOS_ESSENTIALS_M4 No - Unused - 1332 | NXOS_ESSENTIALS_XF No - Unused - 1333 | SAN_ENTERPRISE_PKG No - Unused - 1334 | PORT_ACTIVATION_PKG No 0 Unused - 1335 | NETWORK_SERVICES_PKG No - Unused - 1336 | NXOS_ADVANTAGE_M8-16 No - Unused - 1337 | NXOS_ESSENTIALS_M8-16 No - Unused - 1338 | FC_PORT_ACTIVATION_PKG No 0 Unused - 1339 | LAN_ENTERPRISE_SERVICES_PKG No - Unused - 1340 | -------------------------------------------------------------------------------- 1341 | 1342 | devices device leaf02-2 live-status exec show 1343 | result 1344 | Feature Ins Lic Status Expiry Date Comments 1345 | Count 1346 | -------------------------------------------------------------------------------- 1347 | N9K_LIC_1G No - Unused - 1348 | VPN_FABRIC No - Unused - 1349 | NXOS_OE_PKG No - Unused - 1350 | . 1351 | . 1352 | ``` 1353 |
1354 | 1355 | 1. Many times you need to gather data like this for later processing, or to share with someone. For any command, NSO allows you to `save` the output to a file. 1356 | 1357 | ``` 1358 | devices device leaf* live-status exec show license usage | save leaf-license-usage.txt 1359 | ``` 1360 | 1361 | 1. If you exit from NSO, you'll find a new file in your current directory with this data. 1362 | 1363 | ```bash 1364 | ll leaf-license-usage.txt 1365 | -rw-r--r-- 1 hapresto staff 6.2K Dec 19 15:22 leaf-license-usage.txt 1366 | ``` 1367 | -------------------------------------------------------------------------------- /04a-mvu.md: -------------------------------------------------------------------------------- 1 | # Minimum Viable Use Case: Update SNMP Configuration Across the Network 2 | My go-to example for a first network automation project has long been the updating of SNMP community strings because it is commonly used and has a limited blast radius if something goes wrong as you are learning. Let's see how NSO can make it super easy. 3 | 4 | ## Use Case Description 5 | Our goal is to update the SNMP community string configuration on all our network devices. This includes: 6 | 7 | * NX-OS switches 8 | * IOS switches and routers 9 | * ASA firewalls 10 | 11 | ## Cisco NSO Features Used 12 | * Device Templates with Variables and Tags 13 | * Device Groups 14 | 15 | ## Building the Use Case 16 | ### Step 1: Create the Template 17 | 1. Log into NSO with `ncs_cli -C -u admin` and enter `config` mode. 18 | 19 | 1. Let's setup the device template that covers the three device-types in question. 20 | 21 | ``` 22 | devices template UPDATE-SNMP-COMMUNITY 23 | ned-id cisco-ios-cli-6.42 24 | config 25 | snmp-server community {$READ_ONLY_COMMUNITY} RO 26 | snmp-server community {$READ_WRITE_COMMUNITY} RW 27 | exit 28 | exit 29 | exit 30 | 31 | ned-id cisco-nx-cli-5.13 32 | config 33 | snmp-server community {$READ_ONLY_COMMUNITY} group network-operator 34 | snmp-server community {$READ_WRITE_COMMUNITY} group network-admin 35 | exit 36 | exit 37 | exit 38 | 39 | ned-id cisco-asa-cli-6.7 40 | config 41 | snmp-server community secret {$READ_ONLY_COMMUNITY} 42 | snmp-server enable-conf enable true 43 | exit 44 | exit 45 | ``` 46 | 47 | * NSO device templates can use variables for values to make them more dynamic and re-usable. The variable syntax is {$VAR_NAME}, though the variable name does not have to be in all caps, we do that to make it more readable. 48 | * The syntax of the template configuration may differ slightly from what a native device CLI configuration is. That is because the template is a bit more verbose of a representation of the NED data model. 49 | 50 | 1. Return to `top` and checkout the configuration with `show configuration` 51 | 1. Go ahead and save this new template. 52 | 53 | ``` 54 | commit 55 | ``` 56 | 57 | ### Step 2: Testing the Template 58 | You always need to test your automation before pushing it out to the whole network. Let's verify that it works as expected on our three platforms. 59 | 60 | 1. First let's see what SNMP configuration exists on our test platforms. We'll do this from the NSO CLI "enable" mode. 61 | > Note: From `config` mode you can use `show full-configuration` to look at the device configuration. This will display both the `running-config` as well as any staged configuration that NSO is planning on sending to the device. 62 | 63 | ``` 64 | ! "end" will exit config mode 65 | end 66 | show running-config devices device dmz-rtr02-1 config snmp-server 67 | show running-config devices device leaf01-1 config snmp-server 68 | show running-config devices device fw01 config snmp-server 69 | ``` 70 | 71 |
Output 72 | 73 | ``` 74 | admin@ncs# show running-config devices device dmz-rtr02-2 config snmp-server 75 | % No entries found. 76 | admin@ncs# show running-config devices device leaf01-1 config snmp-server 77 | % No entries found. 78 | admin@ncs# show running-config devices device fw01 config snmp-server 79 | ! 2 exits to return back to the 'config-template-SET-DNS-SERVER' context 80 | devices device fw01 81 | config 82 | no snmp-server contact 83 | no snmp-server location 84 | ``` 85 |
86 | 87 | 1. Next up, let's test it on these three devices. 88 | > Note: The syntax to input the variable values for a particular device is `devices device DEVICE-NAME apply-template template-name TEMPLATE-NAME variable { name VARIABLE-NAME1 value 'value-in-template1' } variable { name VARIABLE-NAME2 value 'value-in-template2' }`. 89 | ``` 90 | config 91 | 92 | devices device dmz-rtr02-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_1' } variable { name READ_WRITE_COMMUNITY value 'WRITE_1' } 93 | 94 | devices device leaf01-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_1' } variable { name READ_WRITE_COMMUNITY value 'WRITE_1' } 95 | 96 | devices device fw01 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_1' } variable { name READ_WRITE_COMMUNITY value 'WRITE_1' } 97 | ``` 98 | 99 | > Note: String values for variables need to be surrounded by single quotes. 100 | 101 | 102 |
Output 103 | 104 | ``` 105 | admin@ncs(config)# devices device dmz-rtr02-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_1' } variable { name READ_WRITE_COMMUNITY value 'WRITE_1' } 106 | apply-template-result { 107 | device dmz-rtr02-1 108 | result ok 109 | } 110 | admin@ncs(config)# devices device leaf01-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_1' } variable { name READ_WRITE_COMMUNITY value 'WRITE_1' } 111 | apply-template-result { 112 | device leaf01-1 113 | result ok 114 | } 115 | admin@ncs(config)# devices device fw01 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_1' } variable { name READ_WRITE_COMMUNITY value 'WRITE_1' } 116 | apply-template-result { 117 | device fw01 118 | result ok 119 | } 120 | ``` 121 |
122 | 123 | 1. Now that NSO has the template applied with variable values defined, it can compare the intended configuration from the template to the actual configuration stored in the NSO CDB, and calculate what configuration needs to be sent to make the device be in compliance. Since there is no pre-existing SNMP configuration, all the commands would be sent, but in a brownfield network device, it would send only the minimal amount of commands needed. 124 | 125 | To view the resulting pending configuration to be applied from the templates use the following command: 126 | 127 | ``` 128 | show configuration 129 | ``` 130 | 131 |
Output 132 | 133 | ``` 134 | devices device dmz-rtr02-1 135 | config 136 | snmp-server community READ_1 RO 137 | snmp-server community WRITE_1 RW 138 | ! 139 | ! 140 | devices device fw01 141 | config 142 | snmp-server community READ_1 143 | snmp-server enable 144 | ! 145 | ! 146 | devices device leaf01-1 147 | config 148 | snmp-server community READ_1 group network-operator 149 | snmp-server community WRITE_1 group network-admin 150 | ``` 151 |
152 | 153 | ``` 154 | commit dry-run outformat native 155 | ``` 156 | 157 |
Output 158 | 159 | ``` 160 | native { 161 | device { 162 | name dmz-rtr02-1 163 | data snmp-server community READ_1 RO 164 | snmp-server community WRITE_1 RW 165 | } 166 | device { 167 | name fw01 168 | data snmp-server community READ_1 169 | snmp-server enable 170 | } 171 | device { 172 | name leaf01-1 173 | data snmp-server community READ_1 group network-operator 174 | snmp-server community WRITE_1 group network-admin 175 | } 176 | } 177 | ``` 178 |
179 | 180 | 1. It all looks good, let's commit it, so NSO will apply the pending configuration to the devices. 181 | 182 | ``` 183 | commit 184 | ``` 185 | 186 | 187 | ### Step 3: Deeper Testing and a Reference to a Classic Dinosaur Movie 188 | 189 | 1. Now the goal of this use case is to replace/update the community string. Let's see what happens when we run the templates again to change the string. 190 | 191 | ``` 192 | devices device dmz-rtr02-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_2' } variable { name READ_WRITE_COMMUNITY value 'WRITE_2' } 193 | 194 | devices device leaf01-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_2' } variable { name READ_WRITE_COMMUNITY value 'WRITE_2' } 195 | 196 | devices device fw01 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_2' } variable { name READ_WRITE_COMMUNITY value 'WRITE_2' } 197 | ``` 198 | 199 | > **IMPORTANT PART** - Let's spend a bit of time exploring what's going on to uncover a big challenge with many network automation projects. Something I like to call the "Unexpected Raptors Problem". 200 | 201 | 1. Let's look at our normal verification before committing. 202 | 203 | ``` 204 | show configuration 205 | ``` 206 | 207 |
Output 208 | 209 | ``` 210 | devices device dmz-rtr02-1 211 | config 212 | snmp-server community READ_2 RO 213 | snmp-server community WRITE_2 RW 214 | ! 215 | ! 216 | devices device fw01 217 | config 218 | snmp-server community READ_2 219 | ! 220 | ! 221 | devices device leaf01-1 222 | config 223 | snmp-server community READ_2 group network-operator 224 | snmp-server community WRITE_2 group network-admin 225 | ``` 226 |
227 | 228 | 1. This looks like exactly what we'd want. But let's dig a bit deeper and look at the `full-configuration` for these devices (for just the `snmp-server` part of the device). 229 | 230 | ``` 231 | show full-configuration devices device dmz-rtr02-1 config snmp-server 232 | show full-configuration devices device leaf01-1 config snmp-server 233 | show full-configuration devices device fw01 config snmp-server 234 | ``` 235 | 236 |
Output 237 | 238 | ``` 239 | admin@ncs(config)# show full-configuration devices device dmz-rtr02-1 config snmp-server 240 | ! 2 exits to return back to the 'config-template-SET-DNS-SERVER' context 241 | devices device dmz-rtr02-1 242 | config 243 | snmp-server community READ_1 RO 244 | snmp-server community READ_2 RO 245 | snmp-server community WRITE_1 RW 246 | snmp-server community WRITE_2 RW 247 | ! 248 | ! 249 | admin@ncs(config)# show full-configuration devices device leaf01-1 config snmp-server 250 | ! 2 exits to return back to the 'config-template-SET-DNS-SERVER' context 251 | devices device leaf01-1 252 | config 253 | snmp-server community READ_1 group network-operator 254 | snmp-server community READ_2 group network-operator 255 | snmp-server community WRITE_1 group network-admin 256 | snmp-server community WRITE_2 group network-admin 257 | ! 258 | ! 259 | admin@ncs(config)# show full-configuration devices device fw01 config snmp-server 260 | ! 2 exits to return back to the 'config-template-SET-DNS-SERVER' context 261 | devices device fw01 262 | config 263 | snmp-server community READ_2 264 | no snmp-server contact 265 | snmp-server enable 266 | no snmp-server location 267 | ``` 268 |
269 | 270 | > Well look at that... the IOS and NX devices have both community strings, while the ASA only has the new one. This is because communities on IOS and NX are lists, the devices support having many configured simultaneously, while ASA only supports one. This is why it is important to test your configuration before deploying because different network OS platforms behave differently, even for similar configuration changes. 271 | 272 | 1. Go ahead and commit this change, and we'll tackle fixing this in our next step. 273 | 274 | ``` 275 | commit 276 | ``` 277 | 278 | ### Step 4: Getting Rid of the Extra Dinosaurs with Tags! 279 | The default behavior of NSO templates is to `merge` data into the current configuration. This is often what you want to happen, but not always. 280 | 281 | In these cases, you can tell NSO to take one of the following alternative actions: 282 | 283 | * `merge`: Merge with a node if it exists, otherwise create the node. *This is the default operation if no operation is explicitly set.* 284 | * `replace`: Replace a node if it exists, otherwise create the node. 285 | * `create`: Creates a node. The node can not already exist. 286 | * `nocreate`: Merge with a node if it exists. If it does not exist, it will not be created. 287 | 288 | 1. Start out by looking at the full-configuration of the template we are using. 289 | 290 | ``` 291 | show full-configuration devices template UPDATE-SNMP-COMMUNITY 292 | ``` 293 | 294 | ``` 295 | devices template UPDATE-SNMP-COMMUNITY 296 | ned-id cisco-ios-cli-6.42 297 | config 298 | snmp-server community {$READ_ONLY_COMMUNITY} 299 | RO 300 | ! 301 | snmp-server community {$READ_WRITE_COMMUNITY} 302 | RW 303 | ! 304 | ! 305 | ! 306 | ned-id cisco-nx-cli-5.13 307 | config 308 | snmp-server community {$READ_ONLY_COMMUNITY} 309 | group network-operator 310 | ! 311 | snmp-server community {$READ_WRITE_COMMUNITY} 312 | group network-admin 313 | ! 314 | ! 315 | ! 316 | ned-id cisco-asa-cli-6.7 317 | config 318 | snmp-server community secret {$READ_ONLY_COMMUNITY} 319 | snmp-server enable-conf enable true 320 | ``` 321 | 322 | 1. Within NSO templates, you can change the behavior of templates being applied by leveraging `tags` attached to parts of the configuration. These can be tactical, for just one little portion of the configuration, or be applied to the whole template. A `tag` will apply to all sub-nodes from the point it is added,. The meaning of that makes far more sense when you look at the configuration in the XML format, since it is a hierarchical data format. 323 | 324 | ``` 325 | show full-configuration devices template UPDATE-SNMP-COMMUNITY | display xml 326 | ``` 327 | 328 |
Full Output 329 | 330 | ```xml 331 | 332 | 333 | 379 | 380 | 381 | ``` 382 |
383 | 384 | > Note: XML is a hierarchical language, with each opening tag (``). Indentation helps see the hierarchical relationships of XML, but the indentation does not affect the processing of XML. 385 | 386 | 1. What we want to do is `replace` everything within the `` parts of the configuration. Here's an example. 387 | 388 | ```text 389 | 390 | <--| 391 | | 392 | {$READ_ONLY_COMMUNITY} | 393 | | 394 | | 395 | | 396 | {$READ_WRITE_COMMUNITY} | 397 | | 398 | | 399 | <--| 400 | 401 | ``` 402 | 403 | > We want to replace **ALL** the communities within the `` block. 404 | 405 | 1. To do that, we'll `add` the `replace` tag to each of the `snmp-server` elements of the configuration in the template. 406 | 407 | ``` 408 | devices template UPDATE-SNMP-COMMUNITY 409 | ned-id cisco-ios-cli-6.42 410 | config 411 | tag add snmp-server replace 412 | 413 | ned-id cisco-nx-cli-5.13 414 | config 415 | tag add snmp-server replace 416 | 417 | ned-id cisco-asa-cli-6.7 418 | config 419 | tag add snmp-server replace 420 | exit 421 | exit 422 | ``` 423 | 424 | 1. Take a look at the `full-configuration` now to see what it looks like. 425 | 426 | ``` 427 | top 428 | show full-configuration devices template UPDATE-SNMP-COMMUNITY 429 | ``` 430 | 431 |
Output 432 | 433 | ``` 434 | devices template UPDATE-SNMP-COMMUNITY 435 | ned-id cisco-ios-cli-6.42 436 | config 437 | ! Tags: replace (/devices/template{UPDATE-SNMP-COMMUNITY}/ned-id{cisco-ios-cli-6.42:cisco-ios-cli-6.42}/config/ios:snmp-server) 438 | snmp-server community {$READ_ONLY_COMMUNITY} 439 | RO 440 | ! 441 | ! Tags: replace (/devices/template{UPDATE-SNMP-COMMUNITY}/ned-id{cisco-ios-cli-6.42:cisco-ios-cli-6.42}/config/ios:snmp-server) 442 | snmp-server community {$READ_WRITE_COMMUNITY} 443 | RW 444 | ! 445 | ! 446 | ! 447 | ned-id cisco-nx-cli-5.13 448 | config 449 | ! Tags: replace (/devices/template{UPDATE-SNMP-COMMUNITY}/ned-id{cisco-nx-cli-5.13:cisco-nx-cli-5.13}/config/nx:snmp-server) 450 | snmp-server community {$READ_ONLY_COMMUNITY} 451 | group network-operator 452 | ! 453 | ! Tags: replace (/devices/template{UPDATE-SNMP-COMMUNITY}/ned-id{cisco-nx-cli-5.13:cisco-nx-cli-5.13}/config/nx:snmp-server) 454 | snmp-server community {$READ_WRITE_COMMUNITY} 455 | group network-admin 456 | ! 457 | ! 458 | ! 459 | ned-id cisco-asa-cli-6.7 460 | config 461 | ! Tags: replace (/devices/template{UPDATE-SNMP-COMMUNITY}/ned-id{cisco-asa-cli-6.7:cisco-asa-cli-6.7}/config/asa:snmp-server) 462 | snmp-server community secret {$READ_ONLY_COMMUNITY} 463 | ! Tags: replace (/devices/template{UPDATE-SNMP-COMMUNITY}/ned-id{cisco-asa-cli-6.7:cisco-asa-cli-6.7}/config/asa:snmp-server) 464 | snmp-server enable-conf enable true 465 | ``` 466 | 467 |
468 | 469 | > The tags make the display in CLI format a bit messy, but you can see where the new `Tags: replace` have been added. What is shown is the XPATH to the point for the relevant tag. XPATH is a navigation structure for XML. 470 | 471 | 1. If you look at the XML version of the config, the placement of the tags is a bit easier to see and understand how they work. In the following output look for the XML meta-data tag `tags=" replace "`. This indicates any existing device configuration below this level will be replaced when the template is applied, rather than the default action of merging configuration. 472 | 473 | ``` 474 | show full-configuration devices template UPDATE-SNMP-COMMUNITY | display xml 475 | ``` 476 | 477 |
Full Output 478 | 479 | ```xml 480 | 481 | 482 | 528 | 529 | 530 | ``` 531 |
532 | 533 | 1. Save these changes. 534 | 535 | ``` 536 | commit 537 | ``` 538 | 539 | ### Step 5: Another test 540 | 541 | 1. Now let's test and see if the `tags` worked as expected. 542 | 543 | ``` 544 | devices device dmz-rtr02-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_NO_RAPTOR' } variable { name READ_WRITE_COMMUNITY value 'WRITE_NO_RAPTOR' } 545 | 546 | devices device leaf01-1 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_NO_RAPTOR' } variable { name READ_WRITE_COMMUNITY value 'WRITE_NO_RAPTOR' } 547 | 548 | devices device fw01 apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'READ_NO_RAPTOR' } variable { name READ_WRITE_COMMUNITY value 'WRITE_NO_RAPTOR' } 549 | ``` 550 | 551 | 1. And look at the resulting configuration. 552 | 553 | ``` 554 | show configuration 555 | ``` 556 | 557 |
Output 558 | 559 | ``` 560 | devices device dmz-rtr02-1 561 | config 562 | no snmp-server community READ_1 RO 563 | no snmp-server community READ_2 RO 564 | no snmp-server community WRITE_1 RW 565 | no snmp-server community WRITE_2 RW 566 | snmp-server community READ_NO_RAPTOR RO 567 | snmp-server community WRITE_NO_RAPTOR RW 568 | ! 569 | ! 570 | devices device fw01 571 | config 572 | snmp-server community READ_NO_RAPTOR 573 | ! 574 | ! 575 | devices device leaf01-1 576 | config 577 | no snmp-server community READ_1 group network-operator 578 | no snmp-server community READ_2 group network-operator 579 | no snmp-server community WRITE_1 group network-admin 580 | no snmp-server community WRITE_2 group network-admin 581 | snmp-server community READ_NO_RAPTOR group network-operator 582 | snmp-server community WRITE_NO_RAPTOR group network-admin 583 | ``` 584 |
585 | 586 | > Perfect.. you can see that NSO will remove the old raptors and just keep our good communities. 587 | 588 | ## Executing the Use Case 589 | With our template built and tested, let's put it to work across the network. Rather than applying variable inputs per device, you can also apply templates to a group of devices. 590 | 591 | 1. We want to setup SNMP across the entire network, so we'll use the `ALL` group we setup. This would apply the appropriate template per device type, with the same variable inputs, across all the devices in the device-group. 592 | 593 | ``` 594 | devices device-group ALL apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'INITIAL_READ' } variable { name READ_WRITE_COMMUNITY value 'INITIAL_WRITE' } 595 | ``` 596 | 597 |
Output 598 | 599 | ``` 600 | apply-template-result { 601 | device dmz-fw01-1 602 | result ok 603 | } 604 | apply-template-result { 605 | device dmz-rtr02-1 606 | result ok 607 | } 608 | apply-template-result { 609 | device dmz-rtr02-2 610 | result ok 611 | } 612 | apply-template-result { 613 | device dmz-sw01-1 614 | result ok 615 | } 616 | apply-template-result { 617 | device dmz-sw01-2 618 | result ok 619 | } 620 | apply-template-result { 621 | device dmz-sw02-1 622 | result ok 623 | } 624 | apply-template-result { 625 | device dmz-sw02-2 626 | result ok 627 | } 628 | apply-template-result { 629 | device fw-inside-sw01 630 | result ok 631 | } 632 | apply-template-result { 633 | device fw-outside-sw01 634 | result ok 635 | } 636 | apply-template-result { 637 | device fw01 638 | result ok 639 | } 640 | apply-template-result { 641 | device fw02 642 | result ok 643 | } 644 | apply-template-result { 645 | device internet-rtr 646 | result ok 647 | } 648 | apply-template-result { 649 | device leaf01-1 650 | result ok 651 | } 652 | apply-template-result { 653 | device leaf01-2 654 | result ok 655 | } 656 | apply-template-result { 657 | device leaf02-1 658 | result ok 659 | } 660 | apply-template-result { 661 | device leaf02-2 662 | result ok 663 | } 664 | apply-template-result { 665 | device spine01-1 666 | result ok 667 | } 668 | apply-template-result { 669 | device spine01-2 670 | result ok 671 | } 672 | apply-template-result { 673 | device vm-sw01 674 | result ok 675 | } 676 | apply-template-result { 677 | device vm-sw02 678 | result ok 679 | } 680 | ``` 681 |
682 | 683 | 1. And now verify the pending configuration to be sent to the network devices. 684 | 685 | 686 | > Note: For devices which already have SNMP configuration, like `dmz-rtr02-1`, NSO applies the template to replace the configuration, removing existing SNMP lines. For devices which do not have any configuration to replace, no additional commands are sent. 687 | 688 | ``` 689 | show configuration 690 | ``` 691 | 692 |
Output 693 | 694 | ``` 695 | devices device dmz-fw01-1 696 | config 697 | snmp-server community INITIAL_READ 698 | snmp-server enable 699 | ! 700 | ! 701 | devices device dmz-rtr02-1 702 | config 703 | no snmp-server community READ_1 RO 704 | no snmp-server community READ_2 RO 705 | no snmp-server community WRITE_1 RW 706 | no snmp-server community WRITE_2 RW 707 | snmp-server community INITIAL_READ RO 708 | snmp-server community INITIAL_WRITE RW 709 | ! 710 | ! 711 | devices device dmz-rtr02-2 712 | config 713 | snmp-server community INITIAL_READ RO 714 | snmp-server community INITIAL_WRITE RW 715 | ! 716 | ! 717 | devices device dmz-sw01-1 718 | config 719 | snmp-server community INITIAL_READ group network-operator 720 | snmp-server community INITIAL_WRITE group network-admin 721 | ! 722 | ! 723 | devices device dmz-sw01-2 724 | config 725 | snmp-server community INITIAL_READ group network-operator 726 | snmp-server community INITIAL_WRITE group network-admin 727 | ! 728 | ! 729 | devices device dmz-sw02-1 730 | config 731 | snmp-server community INITIAL_READ group network-operator 732 | snmp-server community INITIAL_WRITE group network-admin 733 | ! 734 | ! 735 | devices device dmz-sw02-2 736 | config 737 | snmp-server community INITIAL_READ group network-operator 738 | snmp-server community INITIAL_WRITE group network-admin 739 | ! 740 | ! 741 | devices device fw-inside-sw01 742 | config 743 | snmp-server community INITIAL_READ RO 744 | snmp-server community INITIAL_WRITE RW 745 | ! 746 | ! 747 | devices device fw-outside-sw01 748 | config 749 | snmp-server community INITIAL_READ RO 750 | snmp-server community INITIAL_WRITE RW 751 | ! 752 | ! 753 | devices device fw01 754 | config 755 | snmp-server community INITIAL_READ 756 | ! 757 | ! 758 | devices device fw02 759 | config 760 | snmp-server community INITIAL_READ 761 | snmp-server enable 762 | ! 763 | ! 764 | devices device internet-rtr 765 | config 766 | snmp-server community INITIAL_READ RO 767 | snmp-server community INITIAL_WRITE RW 768 | ! 769 | ! 770 | devices device leaf01-1 771 | config 772 | no snmp-server community READ_1 group network-operator 773 | no snmp-server community READ_2 group network-operator 774 | no snmp-server community WRITE_1 group network-admin 775 | no snmp-server community WRITE_2 group network-admin 776 | snmp-server community INITIAL_READ group network-operator 777 | snmp-server community INITIAL_WRITE group network-admin 778 | ! 779 | ! 780 | devices device leaf01-2 781 | config 782 | snmp-server community INITIAL_READ group network-operator 783 | snmp-server community INITIAL_WRITE group network-admin 784 | ! 785 | ! 786 | devices device leaf02-1 787 | config 788 | snmp-server community INITIAL_READ group network-operator 789 | snmp-server community INITIAL_WRITE group network-admin 790 | ! 791 | ! 792 | devices device leaf02-2 793 | config 794 | snmp-server community INITIAL_READ group network-operator 795 | snmp-server community INITIAL_WRITE group network-admin 796 | ! 797 | ! 798 | devices device spine01-1 799 | config 800 | snmp-server community INITIAL_READ group network-operator 801 | snmp-server community INITIAL_WRITE group network-admin 802 | ! 803 | ! 804 | devices device spine01-2 805 | config 806 | snmp-server community INITIAL_READ group network-operator 807 | snmp-server community INITIAL_WRITE group network-admin 808 | ! 809 | ! 810 | devices device vm-sw01 811 | config 812 | snmp-server community INITIAL_READ RO 813 | snmp-server community INITIAL_WRITE RW 814 | ! 815 | ! 816 | devices device vm-sw02 817 | config 818 | snmp-server community INITIAL_READ RO 819 | snmp-server community INITIAL_WRITE RW 820 | ``` 821 |
822 | 823 | 1. Go ahead and commit the change. 824 | 825 | ``` 826 | commit 827 | ``` 828 | 829 | 1. And to make sure there aren't any raptors...we test with a new set of inputs to make sure the templates behave as expected. 830 | 831 | ``` 832 | devices device-group ALL apply-template template-name UPDATE-SNMP-COMMUNITY variable { name READ_ONLY_COMMUNITY value 'NEW_READ' } variable { name READ_WRITE_COMMUNITY value 'NEW_WRITE' } 833 | ``` 834 | 835 | 1. Verify... 836 | 837 | ``` 838 | show configuration 839 | ``` 840 | 841 |
Output 842 | 843 | ``` 844 | devices device dmz-fw01-1 845 | config 846 | snmp-server community NEW_READ 847 | ! 848 | ! 849 | devices device dmz-rtr02-1 850 | config 851 | no snmp-server community INITIAL_READ RO 852 | no snmp-server community INITIAL_WRITE RW 853 | snmp-server community NEW_READ RO 854 | snmp-server community NEW_WRITE RW 855 | ! 856 | ! 857 | devices device dmz-rtr02-2 858 | config 859 | no snmp-server community INITIAL_READ RO 860 | no snmp-server community INITIAL_WRITE RW 861 | snmp-server community NEW_READ RO 862 | snmp-server community NEW_WRITE RW 863 | ! 864 | ! 865 | devices device dmz-sw01-1 866 | config 867 | no snmp-server community INITIAL_READ group network-operator 868 | no snmp-server community INITIAL_WRITE group network-admin 869 | snmp-server community NEW_READ group network-operator 870 | snmp-server community NEW_WRITE group network-admin 871 | ! 872 | ! 873 | devices device dmz-sw01-2 874 | config 875 | no snmp-server community INITIAL_READ group network-operator 876 | no snmp-server community INITIAL_WRITE group network-admin 877 | snmp-server community NEW_READ group network-operator 878 | snmp-server community NEW_WRITE group network-admin 879 | ! 880 | ! 881 | devices device dmz-sw02-1 882 | config 883 | no snmp-server community INITIAL_READ group network-operator 884 | no snmp-server community INITIAL_WRITE group network-admin 885 | snmp-server community NEW_READ group network-operator 886 | snmp-server community NEW_WRITE group network-admin 887 | ! 888 | ! 889 | devices device dmz-sw02-2 890 | config 891 | no snmp-server community INITIAL_READ group network-operator 892 | no snmp-server community INITIAL_WRITE group network-admin 893 | snmp-server community NEW_READ group network-operator 894 | snmp-server community NEW_WRITE group network-admin 895 | ! 896 | ! 897 | devices device fw-inside-sw01 898 | config 899 | no snmp-server community INITIAL_READ RO 900 | no snmp-server community INITIAL_WRITE RW 901 | snmp-server community NEW_READ RO 902 | snmp-server community NEW_WRITE RW 903 | ! 904 | ! 905 | devices device fw-outside-sw01 906 | config 907 | no snmp-server community INITIAL_READ RO 908 | no snmp-server community INITIAL_WRITE RW 909 | snmp-server community NEW_READ RO 910 | snmp-server community NEW_WRITE RW 911 | ! 912 | ! 913 | devices device fw01 914 | config 915 | snmp-server community NEW_READ 916 | ! 917 | ! 918 | devices device fw02 919 | config 920 | snmp-server community NEW_READ 921 | ! 922 | ! 923 | devices device internet-rtr 924 | config 925 | no snmp-server community INITIAL_READ RO 926 | no snmp-server community INITIAL_WRITE RW 927 | snmp-server community NEW_READ RO 928 | snmp-server community NEW_WRITE RW 929 | ! 930 | ! 931 | devices device leaf01-1 932 | config 933 | no snmp-server community INITIAL_READ group network-operator 934 | no snmp-server community INITIAL_WRITE group network-admin 935 | snmp-server community NEW_READ group network-operator 936 | snmp-server community NEW_WRITE group network-admin 937 | ! 938 | ! 939 | devices device leaf01-2 940 | config 941 | no snmp-server community INITIAL_READ group network-operator 942 | no snmp-server community INITIAL_WRITE group network-admin 943 | snmp-server community NEW_READ group network-operator 944 | snmp-server community NEW_WRITE group network-admin 945 | ! 946 | ! 947 | devices device leaf02-1 948 | config 949 | no snmp-server community INITIAL_READ group network-operator 950 | no snmp-server community INITIAL_WRITE group network-admin 951 | snmp-server community NEW_READ group network-operator 952 | snmp-server community NEW_WRITE group network-admin 953 | ! 954 | ! 955 | devices device leaf02-2 956 | config 957 | no snmp-server community INITIAL_READ group network-operator 958 | no snmp-server community INITIAL_WRITE group network-admin 959 | snmp-server community NEW_READ group network-operator 960 | snmp-server community NEW_WRITE group network-admin 961 | ! 962 | ! 963 | devices device spine01-1 964 | config 965 | no snmp-server community INITIAL_READ group network-operator 966 | no snmp-server community INITIAL_WRITE group network-admin 967 | snmp-server community NEW_READ group network-operator 968 | snmp-server community NEW_WRITE group network-admin 969 | ! 970 | ! 971 | devices device spine01-2 972 | config 973 | no snmp-server community INITIAL_READ group network-operator 974 | no snmp-server community INITIAL_WRITE group network-admin 975 | snmp-server community NEW_READ group network-operator 976 | snmp-server community NEW_WRITE group network-admin 977 | ! 978 | ! 979 | devices device vm-sw01 980 | config 981 | no snmp-server community INITIAL_READ RO 982 | no snmp-server community INITIAL_WRITE RW 983 | snmp-server community NEW_READ RO 984 | snmp-server community NEW_WRITE RW 985 | ! 986 | ! 987 | devices device vm-sw02 988 | config 989 | no snmp-server community INITIAL_READ RO 990 | no snmp-server community INITIAL_WRITE RW 991 | snmp-server community NEW_READ RO 992 | snmp-server community NEW_WRITE RW 993 | ``` 994 |
995 | 996 | ## All done! 997 | And that's it... you can now update community strings with ease! 998 | -------------------------------------------------------------------------------- /04c-mvu.md: -------------------------------------------------------------------------------- 1 | # Minimum Viable Use Case: Network Configuration Compliance 2 | A common request from network engineers and leadership is an easy way to verify configuration compliance. This could be just for internal reasons, or to support an audit. Whatever the reason, it can be a very challenging and time-consuming task to undertake. Let's see how NSO can help. 3 | 4 | ## Use Case Description 5 | We would like to ensure that the following network features are configured as desired across all devices in our network. 6 | 7 | * DNS server configuration 8 | * Syslog server configuration 9 | * NTP configuration 10 | 11 | > Note: The technique used in this example could be extended to any aspect of the configuration. For this demonstration we scoped it down to a set of features. 12 | 13 | ## Cisco NSO Features Used 14 | * Device templates 15 | * Compliance reports 16 | 17 | ## Building the Use Case 18 | This use case has two parts. 19 | 1. Building a device template that contains the desired configuration to test. 20 | 2. Building a compliance report to will check the configuration of a group of devices against a template 21 | 22 | ### Step 1: Building the Device Template 23 | 24 | 1. Log into NSO with `ncs_cli -C -u admin` and enter `config` mode. 25 | 1. Create the device template with the desired configuration for features. 26 | 27 | ``` 28 | devices template COMPLIANCE-CHECK 29 | ned-id cisco-ios-cli-6.42 30 | config 31 | 32 | ip name-server name-server-list 208.67.222.222 33 | ip name-server name-server-list 208.67.220.220 34 | exit 35 | 36 | service timestamps log datetime localtime show-timezone year 37 | logging host ipv4 10.225.1.11 38 | exit 39 | 40 | ntp server peer-list 10.225.1.11 41 | exit 42 | 43 | exit 44 | exit 45 | 46 | 47 | ned-id cisco-nx-cli-5.13 48 | config 49 | 50 | ip name-server servers 208.67.222.222 51 | ip name-server servers 208.67.220.220 52 | 53 | logging timestamp milliseconds 54 | logging server 10.225.1.11 level 5 55 | exit 56 | 57 | ntp server 10.225.1.11 58 | exit 59 | 60 | exit 61 | exit 62 | 63 | ned-id cisco-asa-cli-6.7 64 | config 65 | dns domain-lookup mgmt 66 | dns server-group DefaultDNS 67 | name-server 208.67.222.222 68 | name-server 208.67.220.220 69 | exit 70 | 71 | logging timestamp 72 | logging host mgmt 10.225.1.11 73 | exit 74 | 75 | ntp server 10.225.1.11 76 | exit 77 | 78 | exit 79 | exit 80 | ``` 81 | 82 | 1. Return to `top` and review the `configuration` you've staged for this template. 83 | 84 | ``` 85 | top 86 | show configuration 87 | ``` 88 | 89 |
Output 90 | 91 | ``` 92 | devices template COMPLIANCE-CHECK 93 | ned-id cisco-ios-cli-6.42 94 | config 95 | service timestamps log datetime localtime 96 | service timestamps log datetime show-timezone 97 | service timestamps log datetime year 98 | ip name-server name-server-list 208.67.222.222 99 | ! 100 | ip name-server name-server-list 208.67.220.220 101 | ! 102 | logging host ipv4 10.225.1.11 103 | ! 104 | ntp server peer-list 10.225.1.11 105 | ! 106 | ! 107 | ! 108 | ned-id cisco-nx-cli-5.13 109 | config 110 | ip name-server servers [ 208.67.222.222 208.67.220.220 ] 111 | ntp server 10.225.1.11 112 | ! 113 | logging server 10.225.1.11 114 | level 5 115 | ! 116 | logging timestamp milliseconds 117 | ! 118 | ! 119 | ned-id cisco-asa-cli-6.7 120 | config 121 | logging timestamp 122 | logging host mgmt 10.225.1.11 123 | ! 124 | ntp server 10.225.1.11 125 | ! 126 | dns domain-lookup mgmt 127 | ! 128 | dns server-group DefaultDNS 129 | name-server [ 208.67.222.222 208.67.220.220 ] 130 | ``` 131 |
132 | 133 | 1. Commit this new template to NSO. 134 | 135 | ``` 136 | commit 137 | ``` 138 | 139 | ### Step 2: Building the Compliance Report 140 | 1. Compliance reports simply compare a given template to a group of devices. So the configuration is pretty simple. Go ahead and enter this in. 141 | 142 | ``` 143 | compliance reports report COMPLIANCE-CHECK 144 | compare-template COMPLIANCE-CHECK ALL 145 | ``` 146 | 147 | 1. Commit this into NSO. 148 | 149 | ``` 150 | commit 151 | ``` 152 | 153 | 1. Exit `config` mode. 154 | 155 | ``` 156 | end 157 | ``` 158 | 159 | ## Executing the Use Case 160 | Everything we need is ready for us to test the network for compliance. 161 | 162 | 1. From the "enable mode" of NSO, go ahead and run the compliance report. 163 | 164 | ``` 165 | compliance reports report COMPLIANCE-CHECK run 166 | ``` 167 | 168 |
Output 169 | 170 | ``` 171 | id 1 172 | compliance-status violations 173 | info Checking 20 devices and no services 174 | location http://localhost:8080/compliance-reports/report_1_admin_1_2019-12-20T14:46:34:0.xml 175 | ``` 176 |
177 | 178 | 1. Okay, so we see there are `violations` and a URL to the report. Some things about compliance reports. 179 | * Results can come in in `html`, `text`, or `xml` format - `xml` is the default 180 | * Because the results are likely very "verbose" and not something the engineer likely wants to just see at the CLI, they are saved as a file located in the folder `state/compliance-reports` 181 | * NSO runs a web-server so these reports are available by navigating to the given URL, or you can find them by navigating the folders on your server 182 | 1. Let's generate the `text` and `html` versions of the report as well. 183 | 184 | ``` 185 | compliance reports report COMPLIANCE-CHECK run outformat text 186 | compliance reports report COMPLIANCE-CHECK run outformat html 187 | ``` 188 | 189 | 1. We'll start out by looking at the `text` version of the file. Use whatever method you like to open up the `text` version of the report located within the `state/compliance-reports` directory. 190 | 191 | ```bash 192 | (std) ~/code/nso-getting-started/nso-instance $ ll state/compliance-reports/ 193 | 194 | total 56 195 | -rw-r--r-- 1 hapresto staff 8.8K Dec 20 14:46 report_1_admin_1_2019-12-20T14:46:34:0.xml 196 | -rw-r--r-- 1 hapresto staff 6.4K Dec 20 14:49 report_2_admin_1_2019-12-20T14:49:41:0.text 197 | -rw-r--r-- 1 hapresto staff 7.2K Dec 20 14:49 report_3_admin_1_2019-12-20T14:49:54:0.html 198 | ``` 199 | 200 | 1. The top of the report provides some details about the report instance, then you'll get a list of devices and their compliance status. Here you can see that there are `Discrepancies` found in all our devices. 201 | 202 | ```text 203 | Template discrepancies 204 | 205 | COMPLIANCE-CHECK 206 | 207 | Discrepancies in device 208 | dmz-fw01-1 209 | dmz-rtr02-1 210 | dmz-rtr02-2 211 | dmz-sw01-1 212 | dmz-sw01-2 213 | dmz-sw02-1 214 | dmz-sw02-2 215 | fw-inside-sw01 216 | fw-outside-sw01 217 | fw01 218 | fw02 219 | internet-rtr 220 | leaf01-1 221 | leaf01-2 222 | leaf02-1 223 | leaf02-2 224 | spine01-1 225 | spine01-2 226 | vm-sw01 227 | vm-sw02 228 | ``` 229 | 230 | 1. In the `Details` section, you'll find a device by device breakdown of what the problems are. This is shown in a `diff` format, where lines with a `+` indicate missing configuration. If there were configurations on the devices that should **not** be there, they'd be indicated with `-`. 231 | 232 | > Note: Even though there are different CLI device types being evaluated (IOS, NX, ASA), NSO standardizes the "native" configuration into a uniform data model, in Junos curly-bracket style, when showing the diff. 233 | 234 | ```diff 235 | Device dmz-rtr02-1 236 | 237 | config { 238 | service { 239 | timestamps { 240 | log { 241 | datetime { 242 | + localtime; 243 | + show-timezone; 244 | + year; 245 | } 246 | } 247 | } 248 | } 249 | logging { 250 | host { 251 | + ipv4 10.225.1.11 { 252 | + } 253 | } 254 | } 255 | ntp { 256 | server { 257 | + peer-list 10.225.1.11 { 258 | + } 259 | } 260 | } 261 | } 262 | ``` 263 | 264 | 1. Go ahead and open up the XML and HTML versions of the report and take a look. The data is the same, just formated differently. 265 | 266 | ## Bonus: Resolving Compliance Problems 267 | An obvious next step after running a compliance report would be to resolve any problems. NSO makes this very simple as you've already done all the work you need to do! 268 | 269 | 1. Enter `config` mode. 270 | 271 | 1. Apply the template to your devices. 272 | 273 | ``` 274 | devices device-group ALL apply-template template-name COMPLIANCE-CHECK 275 | ``` 276 | 277 |
Output 278 | 279 | ``` 280 | apply-template-result { 281 | device dmz-fw01-1 282 | result ok 283 | } 284 | apply-template-result { 285 | device dmz-rtr02-1 286 | result ok 287 | } 288 | apply-template-result { 289 | device dmz-rtr02-2 290 | result ok 291 | } 292 | apply-template-result { 293 | device dmz-sw01-1 294 | result ok 295 | } 296 | apply-template-result { 297 | device dmz-sw01-2 298 | result ok 299 | } 300 | apply-template-result { 301 | device dmz-sw02-1 302 | result ok 303 | } 304 | apply-template-result { 305 | device dmz-sw02-2 306 | result ok 307 | } 308 | apply-template-result { 309 | device fw-inside-sw01 310 | result ok 311 | } 312 | apply-template-result { 313 | device fw-outside-sw01 314 | result ok 315 | } 316 | apply-template-result { 317 | device fw01 318 | result ok 319 | } 320 | apply-template-result { 321 | device fw02 322 | result ok 323 | } 324 | apply-template-result { 325 | device internet-rtr 326 | result ok 327 | } 328 | apply-template-result { 329 | device leaf01-1 330 | result ok 331 | } 332 | apply-template-result { 333 | device leaf01-2 334 | result ok 335 | } 336 | apply-template-result { 337 | device leaf02-1 338 | result ok 339 | } 340 | apply-template-result { 341 | device leaf02-2 342 | result ok 343 | } 344 | apply-template-result { 345 | device spine01-1 346 | result ok 347 | } 348 | apply-template-result { 349 | device spine01-2 350 | result ok 351 | } 352 | apply-template-result { 353 | device vm-sw01 354 | result ok 355 | } 356 | apply-template-result { 357 | device vm-sw02 358 | result ok 359 | } 360 | ``` 361 |
362 | 363 | 1. Use these commands to see the proposed changes to the network to bring the devices in compliance using the "native" device-type CLI. 364 | 365 | ``` 366 | show configuration 367 | commit dry-run outformat native 368 | ``` 369 | 370 | 1. Commit the configuration, which will have NSO send the commands to the devices and make them compliant. 371 | 372 | ``` 373 | commit 374 | ``` 375 | 376 | 1. Exit config mode and re-run the compliance report, so NSO verifies that what is on the device is in compliance with the defined template. 377 | 378 | ``` 379 | end 380 | compliance reports report COMPLIANCE-CHECK run outformat text 381 | ``` 382 | 383 |
Output 384 | 385 | ``` 386 | id 4 387 | compliance-status no-violation < --- Woot! 388 | info Checking 20 devices and no services 389 | location http://localhost:8080/compliance-reports/report_4_admin_0_2019-12-20T15:4:27:0.text 390 | ``` 391 |
392 | 393 | 1. Now we have `no-violations` and are in good shape. A report file is generated that you can submit for audits. 394 | -------------------------------------------------------------------------------- /99-cleanup.md: -------------------------------------------------------------------------------- 1 | # Cleaning Up Your Environment 2 | So you've finished up the exercises, and want to cleanup the lab. It's super easy, let's get to it! 3 | 4 | ## Stopping and Deleting the NSO Instance 5 | 6 | > **Super Simple Shortcut**: In the [Makefile](nso-instance/Makefile), there is a target for `make clean` that will stop and delete the NSO instance for you by running the same commands we describe below. 7 | 8 | 1. Jump into the `nso-instance` directory if you aren't already there. 9 | 1. First step is to stop the running instance of NSO. 10 | 11 | ``` 12 | ncs --stop 13 | ``` 14 | 15 | > There won't be any output, but the command takes a few seconds to complete. 16 | 17 | 1. Now you just need to delete the files in the directory for NSO. Unfortunately there isn't a `ncs-cleanup` command so we need to do it manually. 18 | 19 | ``` 20 | rm -Rf README.ncs \ 21 | state/ \ 22 | logs/ \ 23 | ncs-cdb/ \ 24 | target/ \ 25 | packages/ \ 26 | scripts/ \ 27 | ncs.conf \ 28 | storedstate \ 29 | SAEventRegular* 30 | ``` 31 | 32 | * The above directories and files hold the running configuration, logs, and CDB for the NSO instance we've been using. Here are some highlights on them. 33 | * `state/` - directory holding active "state" for the NSO application. Things like compliance reports, active NEDs and code, events, etc. 34 | * `logs/` - big shocker here, but this directory holds most of the log files for NSO. As you work with NSO more and need to troubleshoot something this directory will become a gold mine. 35 | * `ncs-cdb\` - the Configuration Database for NSO. The files are an internal format so you can't read them directly. 36 | * `packages\` - the NEDs and other packages/services that are loaded up when NSO starts. *Often this will be symlinks to the NSO installation directory.* 37 | * `ncs.conf` - the XML based configuration file for NSO. This file controls things like how authentication is handled, directory locations for key files nad logs, and more. As you progress with NSO more, you'll use this file to make NSO more "your own". 38 | * `SAEventRegular*` - log files that are NOT put into `logs\` related to licensing checks. 39 | 40 | That's it... you've now flushed out and cleared the lab instance of NSO and can start over again if you like. 41 | 42 | And next time around, rather than running the commands manually like that, you can be a super skilled programmer and simply do this... 43 | 44 | ```bash 45 | make clean 46 | 47 | # Output 48 | Stopping and Clearing NSO Instance... 49 | ``` 50 | 51 | ## Tearing Down the Sample VIRL Network 52 | If you've been using the included VIRL topology and DevNet Sandbox (and why wouldn't you be), you just need to stop the simulation. Here we'll shut it down using the same `virlutils` tool we used to start it. 53 | 54 | 1. Jump back up to the root of the `nso-getting-started` directory, and verify that your simulation is active. 55 | 56 | ```bash 57 | # assuming you're in the 'nso-instance' directory 58 | cd .. 59 | 60 | virl ls 61 | ``` 62 | 63 |
Output 64 | 65 | ``` 66 | Running Simulations 67 | ╒════════════════════════════════════╤══════════╤════════════════════════════╤═══════════╕ 68 | │ Simulation │ Status │ Launched │ Expires │ 69 | ╞════════════════════════════════════╪══════════╪════════════════════════════╪═══════════╡ 70 | │ nso-getting-started_default_S034t6 │ ACTIVE │ 2019-12-15T16:27:40.253312 │ │ 71 | ╘════════════════════════════════════╧══════════╧════════════════════════════╧═══════════╛ 72 | ``` 73 | 74 |
75 | 76 | 1. Shutdown the simulation. 77 | 78 | ```bash 79 | virl down 80 | ``` 81 | 82 |
Output 83 | 84 | ```bash 85 | Removing ./.virl/default 86 | Shutting Down Simulation nso-getting-started_default_S034t6..... 87 | SUCCESS 88 | ``` 89 | 90 |
-------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Hank Preston 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # NSO Getting Started Lab 2 | This repository contains resources and labs designed to help engineers get started using [Cisco NSO](https://developer.cisco.com/nso). 3 | 4 | ## Sample Network 5 | 6 | If you have a lab network ready to go, feel free to use that - but we've included a [VIRL topology file](topology.virl) with this lab that we will use for our examples. Feel free to fire ,up your own instance of this VIRL network either using your own VIRL server, or go reserve one from [DevNet Sandbox - Multi-IOS Test Network](https://devnetsandbox.cisco.com/RM/Diagram/Index/6b023525-4e7f-4755-81ae-05ac500d464a?diagramType=Topology) 7 | 8 | ![](example-network-sm.jpeg) 9 | 10 | ## NSO 101: Your first afternoon 11 | These labs will help you go from zero to NSO hero. 12 | 13 | 1. [Learn how to install NSO](01-installing-nso.md) 14 | 1. [Connect NSO to your network](02-connecting-to-network.md) 15 | 1. [Explore the NSO CLI](03-exploring-with-cli.md) 16 | 1. [Cleaning Up Your Environment](99-cleanup.md) 17 | 18 | ## Minimum Viable Use Cases 19 | Here are a few example real-world use cases that every network engineer can relate to solved with NSO. 20 | 21 | 1. [Gather the MAC Addresses from the Network](04b-mvu.md) 22 | 1. [Verify Network Configuration Compliance](04c-mvu.md) 23 | 1. [Update SNMP Community Strings Across the Network](04a-mvu.md) 24 | 25 | ## References 26 | Here are some handy links to resources related to getting started with Cisco NSO. 27 | 28 | * [NSO on DevNet](https://developer.cisco.com/site/nso/) 29 | * [Getting NSO!](https://developer.cisco.com/docs/nso/#!getting-nso) 30 | * [NSO Developer on GitHub](http://github.com/nso-developer) 31 | * [NSO Community](https://community.cisco.com/t5/nso-developer-hub/ct-p/5672j-dev-nso) 32 | * [Learning Lab: NSO usage for different users](https://developer.cisco.com/learning/modules/nso) 33 | * [Learning Lab: NSO Basics by Cisco IT](https://developer.cisco.com/learning/modules/nso-basics) 34 | * [NSO 5 Day Training](https://github.com/NSO-developer/nso-5-day-training) -------------------------------------------------------------------------------- /example-network-sm.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hpreston/nso-getting-started/d0ddea9301a7bcb096cbb0d9efacd50ed1c076fa/example-network-sm.jpeg -------------------------------------------------------------------------------- /example-network.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hpreston/nso-getting-started/d0ddea9301a7bcb096cbb0d9efacd50ed1c076fa/example-network.jpg -------------------------------------------------------------------------------- /nso-instance/.gitignore: -------------------------------------------------------------------------------- 1 | * 2 | !.gitignore 3 | !Makefile 4 | !lab-configs/nso-inventory.cfg 5 | -------------------------------------------------------------------------------- /nso-instance/Makefile: -------------------------------------------------------------------------------- 1 | clean: 2 | -@echo "Stopping and Clearing NSO Instance..." 3 | -@ncs --stop 4 | -@rm -Rf README.ncs agentStore state.yml logs/ ncs-cdb/ ncs-java-vm.log ncs-python-vm.log ncs.conf state/ storedstate target/ packages/ scripts/ SAEventRegular* 5 | -------------------------------------------------------------------------------- /nso-instance/lab-configs/device-groups.cfg: -------------------------------------------------------------------------------- 1 | devices device-group ASA-DEVICES 2 | device-name [ dmz-fw01-1 fw01 fw02 ] 3 | ! 4 | devices device-group DMZ-DEVICES 5 | device-name [ dmz-fw01-1 dmz-rtr02-1 dmz-rtr02-2 dmz-sw01-1 dmz-sw01-2 dmz-sw02-1 dmz-sw02-2 fw-outside-sw01 fw01 fw02 ] 6 | ! 7 | devices device-group INTERNAL-DEVICES 8 | device-name [ fw-inside-sw01 leaf01-1 leaf01-2 leaf02-1 leaf02-2 spine01-1 spine01-2 vm-sw01 vm-sw02 ] 9 | ! 10 | devices device-group IOS-DEVICES 11 | device-name [ dmz-rtr02-1 dmz-rtr02-2 fw-inside-sw01 fw-outside-sw01 internet-rtr vm-sw01 vm-sw02 ] 12 | ! 13 | devices device-group NXOS-DEVICES 14 | device-name [ dmz-sw01-1 dmz-sw01-2 dmz-sw02-1 dmz-sw02-2 leaf01-1 leaf01-2 leaf02-1 leaf02-2 spine01-1 spine01-2 ] 15 | ! 16 | devices device-group OUTSIDE-DEVICES 17 | device-name [ internet-rtr ] 18 | ! 19 | -------------------------------------------------------------------------------- /nso-instance/lab-configs/nso-inventory.cfg: -------------------------------------------------------------------------------- 1 | devices device dmz-fw01-1 2 | address 172.16.30.133 3 | ssh host-key-verification none 4 | authgroup labadmin 5 | device-type cli ned-id cisco-asa-cli-6.7 6 | device-type cli protocol ssh 7 | state admin-state unlocked 8 | ! 9 | ! 10 | devices device dmz-rtr02-1 11 | address 172.16.30.135 12 | ssh host-key-verification none 13 | authgroup labadmin 14 | device-type cli ned-id cisco-ios-cli-6.42 15 | device-type cli protocol ssh 16 | state admin-state unlocked 17 | ! 18 | ! 19 | devices device dmz-rtr02-2 20 | address 172.16.30.136 21 | ssh host-key-verification none 22 | authgroup labadmin 23 | device-type cli ned-id cisco-ios-cli-6.42 24 | device-type cli protocol ssh 25 | state admin-state unlocked 26 | ! 27 | ! 28 | devices device dmz-sw01-1 29 | address 172.16.30.107 30 | ssh host-key-verification none 31 | authgroup labadmin 32 | device-type cli ned-id cisco-nx-cli-5.13 33 | device-type cli protocol ssh 34 | state admin-state unlocked 35 | ! 36 | ! 37 | devices device dmz-sw01-2 38 | address 172.16.30.108 39 | ssh host-key-verification none 40 | authgroup labadmin 41 | device-type cli ned-id cisco-nx-cli-5.13 42 | device-type cli protocol ssh 43 | state admin-state unlocked 44 | ! 45 | ! 46 | devices device dmz-sw02-1 47 | address 172.16.30.109 48 | ssh host-key-verification none 49 | authgroup labadmin 50 | device-type cli ned-id cisco-nx-cli-5.13 51 | device-type cli protocol ssh 52 | state admin-state unlocked 53 | ! 54 | ! 55 | devices device dmz-sw02-2 56 | address 172.16.30.110 57 | ssh host-key-verification none 58 | authgroup labadmin 59 | device-type cli ned-id cisco-nx-cli-5.13 60 | device-type cli protocol ssh 61 | state admin-state unlocked 62 | ! 63 | ! 64 | devices device fw-inside-sw01 65 | address 172.16.30.122 66 | ssh host-key-verification none 67 | authgroup labadmin 68 | device-type cli ned-id cisco-ios-cli-6.42 69 | device-type cli protocol ssh 70 | state admin-state unlocked 71 | ! 72 | ! 73 | devices device fw-outside-sw01 74 | address 172.16.30.123 75 | ssh host-key-verification none 76 | authgroup labadmin 77 | device-type cli ned-id cisco-ios-cli-6.42 78 | device-type cli protocol ssh 79 | state admin-state unlocked 80 | ! 81 | ! 82 | devices device fw01 83 | address 172.16.30.145 84 | ssh host-key-verification none 85 | authgroup labadmin 86 | device-type cli ned-id cisco-asa-cli-6.7 87 | device-type cli protocol ssh 88 | state admin-state unlocked 89 | ! 90 | ! 91 | devices device fw02 92 | address 172.16.30.146 93 | ssh host-key-verification none 94 | authgroup labadmin 95 | device-type cli ned-id cisco-asa-cli-6.7 96 | device-type cli protocol ssh 97 | state admin-state unlocked 98 | ! 99 | ! 100 | devices device internet-rtr 101 | address 172.16.30.171 102 | ssh host-key-verification none 103 | authgroup labadmin 104 | device-type cli ned-id cisco-ios-cli-6.42 105 | device-type cli protocol ssh 106 | state admin-state unlocked 107 | ! 108 | ! 109 | devices device leaf01-1 110 | address 172.16.30.103 111 | ssh host-key-verification none 112 | authgroup labadmin 113 | device-type cli ned-id cisco-nx-cli-5.13 114 | device-type cli protocol ssh 115 | state admin-state unlocked 116 | ! 117 | ! 118 | devices device leaf01-2 119 | address 172.16.30.104 120 | ssh host-key-verification none 121 | authgroup labadmin 122 | device-type cli ned-id cisco-nx-cli-5.13 123 | device-type cli protocol ssh 124 | state admin-state unlocked 125 | ! 126 | ! 127 | devices device leaf02-1 128 | address 172.16.30.105 129 | ssh host-key-verification none 130 | authgroup labadmin 131 | device-type cli ned-id cisco-nx-cli-5.13 132 | device-type cli protocol ssh 133 | state admin-state unlocked 134 | ! 135 | ! 136 | devices device leaf02-2 137 | address 172.16.30.106 138 | ssh host-key-verification none 139 | authgroup labadmin 140 | device-type cli ned-id cisco-nx-cli-5.13 141 | device-type cli protocol ssh 142 | state admin-state unlocked 143 | ! 144 | ! 145 | devices device spine01-1 146 | address 172.16.30.101 147 | ssh host-key-verification none 148 | authgroup labadmin 149 | device-type cli ned-id cisco-nx-cli-5.13 150 | device-type cli protocol ssh 151 | state admin-state unlocked 152 | ! 153 | ! 154 | devices device spine01-2 155 | address 172.16.30.102 156 | ssh host-key-verification none 157 | authgroup labadmin 158 | device-type cli ned-id cisco-nx-cli-5.13 159 | device-type cli protocol ssh 160 | state admin-state unlocked 161 | ! 162 | ! 163 | devices device vm-sw01 164 | address 172.16.30.121 165 | ssh host-key-verification none 166 | authgroup labadmin 167 | device-type cli ned-id cisco-ios-cli-6.42 168 | device-type cli protocol ssh 169 | state admin-state unlocked 170 | ! 171 | ! 172 | devices device vm-sw02 173 | address 172.16.30.115 174 | ssh host-key-verification none 175 | authgroup labadmin 176 | device-type cli ned-id cisco-ios-cli-6.42 177 | device-type cli protocol ssh 178 | state admin-state unlocked 179 | ! 180 | ! 181 | -------------------------------------------------------------------------------- /sbx-reserve-1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/hpreston/nso-getting-started/d0ddea9301a7bcb096cbb0d9efacd50ed1c076fa/sbx-reserve-1.jpg --------------------------------------------------------------------------------