NAPALM Network Automation¶
The Digital Rebar Platform (DRP) NAPALM (Network Automation and Programmability Abstraction Layer with Multi-vendor support) content pack provides network automation for any network device supported by NAPALM. For more information and documentation specifically on NAPALM, please see their documentation site:
Note
This content is currently marked experimental
by RackN, and is not
yet fully supported. If you are interested in helping shape the
network automation capabilities in DRP, please contact RackN at
https://rackn.com/about/contact-rackn/
The NAPALM supported platforms are defined by the RackN maintained
napalm-runner
context Dockerfile build definitions. The most up to
date version of installed drivers can be found at:
Check your installed napalm
context definition for napalm-runner
to determine which version of the RackN napalm-runner
you have installed.
This Content Bundle enables use of the NAPALM libraries. Each Switch Network
Operating System (NOS) utilizes the vendor specified language and methods
for making Switch changes. This content and the NAPALM tools do not change
that, you must craft merge
and replace
operations in the correct
syntax and format for the given NOS platform you are working with.
How it Works in DRP¶
Digital Rebar Platform (DRP) utilizes a context container which contains the NAPALM python libraries and tools, along with a Runner service. The context container allows Workflow and Workorders automation elements to execute NAPALM calls against network devices.
The current features that have been implemented are fairly basic, and can be found
in the individual Tasks
documentation section. Some of the capabilities
include:
- device configuration
merge
requests (napalm-load
stage or blueprint) - device configuration
replace
requests (napalm-load
stage or blueprint) - show config differences of
merge
orreplace
operations - apply
merge
orreplace
operations - execute arbitrary device commands (
napalm-commands
blueprint)
Future capabilities and operating models will be made to this content pack as more advanced use cases are incorporated in to the automation.
Within DRP, each network Switch that will be managed should have a Machine object created to represent the switch for long term state tracking and management. This will require a Machine license for each Network device be available in the License (either a Virtual entity or Physical entity type license).
Setup the NAPALM tooling in DRP¶
Currently the following steps should be followed to manage one or more switches:
- ensure you have all v4.11.x and newer DRP and content
- install the
napalm
content pack - ensure you have the
napalm-runner
context container installed (*) - for each network device to be managed, create a Machine object with the device name
- set the Base Context of the machine to
napalm-runner
- set the Context of the machine to
napalm-runner
- if you are forced to set a
Workflow
, chooseuniversal-start
- ensure the DRP Endpoint has API or SSH access to the network device
Operating Workflow / Stages or Workorders / Blueprints should be done against
each Machine context that represents the network device being managed. The
task
will be executed in the container with the napalm-runner
context,
and API or SSH control will occur from the context container to the network device.
Note (*)
For Self bootstrap setup (assumes DRP Endpoint has outbound internet connectivity to the RackN package repository in S3):
- set the
bootstrap-napalm
Profile on the Self-Runner Machine - apply the
rebootstrap-drp
Workorder / Blueprint on the Self-Runner
To manually install the context container do the following:
# get current Context version (eg. napalm-runner_v1.2.8)
CTX="$(drpcli contexts show napalm-runner | jq -r '.Image')"
SRC="$CTX.tar.gz"
# should be "https://s3.us-west-2.amazonaws.com/get.rebar.digital/containers" plus "/$CTX"
URL="$(drpcli contexts show napalm-runner | jq -r '.Meta.downloadable')"
drpcli files upload ${URL}/${SRC} as contexts/docker-context/${CTX}
drpcli plugins runaction docker-context imageUpload \
context/image-path files/contexts/docker-context/${CTX} \
context/image-name ${CTX}
Warning
Versions v4.1.0 through v4.2.0 of Podman have a bug that do not
support GZip compressed containers. Upgrade to Podman v4.3.0 or
newer. Error message indicating this in the Job Logs is
"Error: INVOKE: plugin/unknown: Error loading image: exit status 125
".
Example Usage - "merge" a change¶
Once the above setup steps have been completed - verify that your context container is running workflow correctly. Perform the following:
- ensure that
dev-library
is installed via theCatalog
- select the network device Machine in the
machines
menu that you created - click on the Machine name
- remove the current Workflow set on the machine
- set the
hello-world
Workflow on the network device Machine (hello-world
is in thedev-library
content bundle)
This should run in the napalm-runner
context and the workflow should
succeed. Verify the operation from the Machines Activity details panel.
You must have a Template that contains the replace or merge operation changes to your network device. The following example sets an Interface with some values. To create it do the following:
- go to Templates
- create a new Template
- set the ID to the name of the template (eg
napalm-switch-int-merge
) - In the
contents
input add your changes - example:
# example napalm "merge" change for Eth1
interface Ethernet1
description vmbr201 - configured by DRP {{.ApiURL }}
no shutdown
no switchport
ip address 192.168.201.2/24
Note that you can use template language constructs to customize the template.
Note
The contents of the Template must match the Network Operating System (NOS) configuration command constructs. It is different for each Switch NOS. The above example is for an Arista EOS switch.
Save the template.
Return to the Machines page, and select the network device Machine object (click on it's Name). Add the following Params - as an example:
# these MUST be customized for your environment/device
# MOST of these SHOULD be contained in a Profile
napalm/commit-config: false
napalm/load-operation: merge
napalm/config-driver: eos
napalm/config-hostname: 10.10.1.8
napalm/config-username: rebar
napalm/config-password: RocketSkates
napalm/config-template: napalm-switch-int-merge
Note
The above will attempt to provide a DIFF of the changes necessary (when run), but will NOT apply the changes.
The Param napalm/commit-config
controls this behavior; by default it
is set to false
.
To operate the above changes:
- Remove the Workflow from the machine object
- Set the Machine in
Workorder
mode - Set the Workorder --> Blueprint
napalm-load
on the machine object
The Activity log should contain the Blueprint's job log output, which will show the proposed Change differences.
To execute/apply the changes - set the Param napalm/commit-config
to true
. Set the Workorder --> Blueprint napalm-load
on the
machine again. The changes should now be enacted on the network
device.
Example Usage - "replace" config¶
The replace
operation is handled exactly like the described merge
operation with the following notes and exceptions:
- set
napalm/load-operation
toreplace
instead ofmerge
- the ENTIRE Switch configuration will be replaced with the config
defined in the
napalm/config-template
Example Usage - Interface change while performing a Pipeline OS Installation¶
It is relatively easy to utilize the NAPALM tooling to update a Switch interface configuration during an OS Provisioning operation via a Universal Pipeline. All Universal workflows utilize extensible Pre and Post sections in each Workflow that allow dynamic runtime injection of Tasks.
This scenario assumes the following:
- the goal is to utilize the Napalm content to update a Switch configuration
- the assumed goal is to change a Switch interface as part of OS provisioning
- the Napalm content is installed
- the
napalm-runner
has been set up and tested - the appropriate configuration Params (or Profile carrying the Params) is
on the Machine running the Universal pipeline for the NAPALM
merge
operation - switch configuration will occur during the
universal-linux-install-during-install-flexiflow
task
To effect a Switch interface change during the Linux install; simply add the following Param configuration to the Machine being provisioned:
universal/linux-install-during-install-flexiflow:
- "context:napalm-runner"
- "napalm-load"
- "context:"
The Workflow Stage universal-linux-install-during-install-flexiflow
will
switch context to the napalm-runner
, run the napalm-load
Task (which
utilizes the config Params/Profile details from the provisioning Machine),
then return back to the original Context (the provisioning Machine).
Running Arbitrary Commands on the Network Device¶
The Blueprint named napalm-commands
can be used to run commands on
the network device. All of the above Params apply, with the following
exceptions:
napalm/config-template
is ignorednapalm/command-sequences
is an Array of commands to run- Use the
napalm-commands
Workorder --> Blueprint to execute the commands
Note that the commands are currently Python code, amended with appropriate NAPALM directives. This may change in the future.
Example usage configuration for the napalm/command-sequences
Param:
napalm/command-sequences
- "json.dumps(print(device.get_facts()))",
- "print(device.get_interfaces_counters())"
This will run two commands in sequence:
- the first runs the NAPALM
get_facts()
function, and transforms it to JSON via Pythonjson.dumps()
- the second runs the
get_interface_counters()
and just prints the raw output