Repository Reference

Templates

Templates for switch configurations.

In the base of this repository there should be one directory for each network operating system platform, like “eos”, “junos” or “iosxr”.

In each of these directories there needs to be a file called “mapping.yml”, this file defines what template files should be used for each device type. For example, in mapping.yml there might be a definition of templates for an access switch specified like this:

ACCESS:
    entrypoint: access.j2
    dependencies:
        - managed-full.j2

This indicates that the starting point for the template of access switches for this platform is deffined in the Jinja2 template file called “access.j2”. Additionally, this template file will depend on things defined in a file called “managed-full.j2”.

The template files themselves are written using the Jinja2 templating language. Variables that are exposed from CNaaS includes:

  • mgmt_ip: IPv4 management address (ex 192.168.0.10)

  • mgmt_ipif: IPv4 management address including prefix length (ex 192.168.0.10/24)

  • mgmt_prefixlen: Just the prefix length (ex 24)

  • mgmt_vlan_id: VLAN id for management (ex 10)

  • mgmt_gw: IPv4 address for the default gateway in the management network

  • uplinks: A list of uplink interfaces, each interface is a dictionary with these keys:

    • ifname: Name of the physical interface (ex Ethernet1)

  • access_auto: A list of access_auto interfacs. Using same keys as uplinks.

Additional variables available for distribution switches:

  • infra_ip: IPv4 infrastructure VRF address (ex 10.199.0.0)

  • infra_ipif: IPv4 infrastructure VRF address inc prefix (ex 10.199.0.0/32)

  • vrfs: A list of dictionaries with two keys: “name” and “rd” (rd as in Route Distinguisher). Populated from settings defined in routing.yml.

  • bgp_ipv4_peers: A list of dictionaries with the keys: “peer_hostname”, “peer_infra_lo”, “peer_ip” and “peer_asn”. Contains one entry per directly connected dist/core device, used to build an eBGP underlay for the fabric. Populated from the links database table.

  • bgp_evpn_peers: A list of dictionaries with the keys: “peer_hostname”, “peer_infra_lo”, “peer_asn”. Contains one entry per hostname specified in settings->evpn_spines. Used to build eBGP peering for EVPN between loopbacks.

  • mgmtdomains: A list of dictionaries with the keys: “ipv4_gw”, “vlan”, “description”, “esi_mac”. Populated from the mgmtdomains database table.

  • asn: A private unique Autonomous System number generated from the last two octets of the infra_lo IP address on the device.

All settings configured in the settings repository are also exposed to the templates.

settings

Settings are defined at different levels and inherited (possibly overridden) in several steps. For example, NTP servers might be defined in the “global” settings to impact the entire managed network, but then overridden for a specific device type that needs custom NTP servers. The inheritence is defined in these steps: Global -> Core/Dist/Access -> Device specific. The directory structure looks like this:

  • global

    • groups.yml: Definition of custom device groups

    • vxlans.yml: Definition of VXLAN/VLANs

    • routing.yml: Definition of global routing settings like fabric underlay and VRFs

    • base_system.yml: Base system settings

  • core

    • base_system.yml: Base system settings

  • dist

    • base_system.yml: Base system settings

  • access:

    • base_system.yml: Base system settings

  • devices:

    • <hostname>

      • base_system.yml

      • interfaces.yml

      • routing.yml

routing.yml:

Can contain the following dictionaries with specified keys:

  • underlay:

    • infra_link_net: A /16 of IPv4 addresses that CNaaS-NMS can use to automatically assign addresses for infrastructure links from (ex /31 between dist-core).

    • infra_lo_net: A /16 of IPv4 addresses that CNaaS-NMS can use to automatically assign addresses for infrastructure loopback interfaces from.

    • mgmt_lo_net: A subnet for management loopbacks for dist/core devices.

  • evpn_peers:

    • hostname: A hostname of a CORE (or DIST) device from the device database. The other DIST switches participating in the VXLAN/EVPN fabric will establish eBGP connections to these devices.

  • vrfs:

    • name: The name of the VRF. Should be one word (no spaces).

    • vrf_id: An integer between 1-65535. This ID can be used to generate unique VNI, RD and RT values for this VRF.

    • groups: A list of groups this VRF should be provisioned on.

  • extroute_static:

    • vrfs:

      • name: Name of the VRF

      • ipv4:

        • destination: IPv4 prefix

        • nexthop: IPv4 nexthop address

        • interface: Exiting interface (optional)

        • name: Name/description of route (optional, defaults to “undefined”)

        • cli_append_str: Custom configuration to append to this route (optional)

  • extroute_ospfv3:

    • vrfs:

      • name: Name of the VRF

      • ipv4_redist_routefilter: Name of a route filter (route-map) that filters what should be redistributed into OSPF

      • ipv6_redist_routefilter: Name of a route filter (route-map) that filters what should be redistributed into OSPF

      • cli_append_str: Custom configuration to add for this VRF (optional)

  • extroute_bgp:

    • vrfs:

      • name: Name of the VRF

      • local_as: AS number that CNaaS NMS devices will present themselves as

      • neighbor_v4:

        • peer_as: AS number the remote peer

        • peer_ipv4: IPv4 address of peer

        • route_map_in: Route-map to filter incoming routes

        • route_map_out: Route-map to filter outgoing routes

        • description: Description of remote peer (optional, defaults to “undefined”)

        • cli_append_str: Custom configuration to append to this peer (optional)

      • neighbor_v6:

        • peer_as: AS number the remote peer

        • peer_ipv6: IPv6 address of peer

        • route_map_in: Route-map to filter incoming routes

        • route_map_out: Route-map to filter outgoing routes

        • description: Description of remote peer (optional, defaults to “undefined”)

        • cli_append_str: Custom configuration to append to this peer (optional)

vxlans.yml:

Contains a dictinary called “vxlans”, which in turn has one dictinoary per vxlan, vxlan name is the dictionary key and dictionaly values are:

  • vni: VXLAN ID, 1-16777215

  • vrf: VRF name

  • vlan_id: VLAN ID, 1-4095

  • vlan_name: VLAN name, single word/no spaces, max 31 characters

  • ipv4_gw: IPv4 address with CIDR netmask, ex: 192.168.0.1/24

  • groups: List of group names where this VXLAN/VLAN should be provisioned. If you select an access switch the parent dist switch should be automatically provisioned.

etc

Configuration files for system daemons

Directory structure:

  • dhcpd/

    • dhcpd.conf: Used for ZTP DHCPd