Skip to content

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 or replace operations
  • apply merge or replace 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, choose universal-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 the Catalog
  • 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 the dev-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 to replace instead of merge
  • 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 ignored
  • napalm/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 Python json.dumps()
  • the second runs the get_interface_counters() and just prints the raw output