Skip to content

Latest commit

 

History

History
73 lines (55 loc) · 3.71 KB

README.md

File metadata and controls

73 lines (55 loc) · 3.71 KB
Raw

This project contains two libs:

  • apstra - python lib which is dedicated to standardising API calls to the Juniper Apstra system (tested with 4.1.2).
  • boarding - python lib which is using 'apstra' as a backend for executing commands based on YAML configuration

Othere content

  • apstra-jupyter_docs - docs in Jupyter standard which can be used to get some base knowledge how to use 'apstra' lib
  • config - contains configuration YAML file / or folders - which are used by "onboarding.py" script
  • schemas - contains Draft7 json schema for validate YAML config files
  • templates - contains 'apstra' lib jinja template dedicated to having an easy way of generating the content of commands sent to Apstra API service.

onboarding.py

Description: 
# python3 onboarding.py  -h
usage: onboarding.py [-h] [-c CONFIG] [-d DEBUG]

options:
  -h, --help            show this help message and exit
  -c CONFIG, --config CONFIG
                        YAML File (or dir) with configuration
  -d DEBUG, --debug DEBUG
                        Debug Screen Output Level [default: INFO]

How to run:

onboarding.py -c ApstraDemo

What it will do?

  • run validation of config file: check Draft7 validation, merge yaml file (if you are using folder content)
    [if you use dir: anchorn should be ALWAYS extracted to seperate file]
  • run sync process which will take config elements for compare between:
            YAML config file <--and--> Apstra server
    (configuration elements: routing_policies, nodes, connectivity_template, virtual_network, self.routing_zones)
  • if under blueprint 'sync' option would be set as True - config elements which not exist in configu YAML, and exist on Apstra server -> would be removed from Apstra server
  • next would be trigere bording process: (routing_zones, virtual_network, connectivity_template, nodes, nodes_interface_speed, nodes_connectivity_template_assign)

What it will NOT do?

  • this is just Day-2 provisioning script - if you modyfie some parameters like name or vlan id - it will not be "sync" (will not update config on Apstra)
  • if you use sync=True - please be aware that element not listed in configuration would be removed from Apstra

Main Features:

  • YAML config validate by Draft7 schema
  • YAML will not use element IDs but only names/labels
  • configuration can be stored in multiple YAML files with anachors references (ie. same vlan for multiple blueprints)
  • create resource (asn/ip/vni)
  • create blueprints sub elements of Day2 configuration across multiple Bluprints on multiple Apstra Controllers
  • create blueprint -> routing-policies
  • create blueprint -> routing-zones
  • create blueprint -> virtual-networks (bound to name of phisical swtich (leaf and access) which are translate to redundancy-groups)
  • create blueprint -> connectivity-templates (single vlan / multivlan / bgp L3 peering / any othere predefined in jinja template file)
  • create blueprint -> nodes (generic or external + links to leaf [Physical or LAG])
  • create blueprint -> nodes (change speed interface if needed)
  • assign tags to CT/NODEs/RESOURCEs
  • assign node interfaces to assign connectivity-templates to Physical or LAG interface (pointing server interface and then CT provision on Leaf interface side)
  • store logging for each run of script in seperate log file

Todo:

  • 'sync=True' option will allow to remove elements on Apstra which are not defined in YAML file
  • 'sync=True' will not remove elements from Apstra server (tagged as 'protect' will be keep on apstra side)
  • add option -commit for script which will Commit Configuration only if blueprint not repors any errors