Inventory¶

Connect requires one or more inventories to function. The purpose of this document is to describe what the inventory is used for, which integrations are available and how to add additional integrations.

Purpose¶

The purpose of the inventory integration can be threefold:

A resource inventory to resolve a provided UNI reference to one or more ports in the network. This results in the port, the device, router ip, management ip, credentials, … Without this information Inmanta Connect will not be able to orchestrate any services.
Allocate identifiers for resources such as VLANs, service identifiers, … By default Inmanta Connect requires a range it can manage and allocate identifiers from. However, Inmanta Connect can also allocate them based on the inventory.
Document the orchestrated services in an external service inventory. All services are always available in the built-in service inventory of Inmanta Connect.

Resource inventory¶

Inmanta Connect uses the MEF reference model for requesting new services such as carrier ethernet services. This reference model uses the concept of a UNI (User Network Interface) reference. A UNI is an abstract concept to model the attachment of a customer (user) to the provider network. There can be a one-to-one mapping between a UNI and a port on a router or it could also model a LAG implemented using multi-homing in an EVPN network.

Inmanta Connect expects a reference to a UNI that it can resolve in a resource inventory to one or more ports in the network. This reference is a URI that points to the corresponding resource in the resource inventory. Example of a such a reference are:

UNI 123-852-456 in the built-in inventory of connect: inmanta:123-852-456
UNI 1234 in Netbox: netbox:1234
UNI with name customer1 in a TMF639 compliant inventory: tmf639://192.0.2.42/api/resource/?@type=type$UNI$&name=customer1

The inventory integration will provide Inmanta Connect with parameters such as:

The name of the port
The name of the router
The mgmt ip
…

Identifier allocation¶

Inmanta Connect requires unique identifiers to work correctly. For example a circuit id, which needs to be unique within the network. The default mode of operation is assigning a range of identifiers to Inmanta Connect. Connect allocates an available identifier from the provided range. See the configuration settings for more details. By default only service ids are allocated from a range. Identifiers such as VLANs have to be provided when the a service instance is created.

This behaviour can be customized by developing a custom allocator. This allocator can then use an external inventory to find an available VLAN, service id or other identifier.

Service inventory¶

Inmanta Connect can integrate with external service inventories to document the created services. Inmanta Connect currently does not offer out of the box integrations. The orchestration model behind Inmanta Connect has been built to easily add service documentation.

Inventory integration¶

Inmanta Connect can integrate with any inventory that has an external API. The default settings enable the built-in resource inventory. Other inventories can be enabled or integrated. Multiple inventories can be enabled at the same time.

Built-in resource inventory¶

The built-in resource inventory loads the inventory from a yaml file. Inmanta Connect also contains the topologies to work with the connect reference labs. The inventory contains only the data required for Connect to orchestrate new services.

The inventory models Device, Network Element (NE) and User Network Interface (UNI) resources in a yaml file. The default location for this file is /files/connect-inventory.yaml, in the inmanta project. The inventory path can be modified using the main.inventory_path attribute of the configuration.

The snippet below shows an example of the contents in an inventory file:

devices:
  dev-2:
    mgmt_ip: 172.20.20.12
    mgmt_port: 830
    vendor: Nokia
    model: 7750 SR
    os: TiMos
    version: "20.10"
    username_env: NETCONF_DEVICE_USER
    password_env: NETCONF_DEVICE_PASSWORD
  dev-4:
    mgmt_ip: 172.20.20.14
    mgmt_port: 830
    vendor: Nokia
    model: 7750 SR
    os: TiMos
    version: "20.10"
    username_env: NETCONF_DEVICE_USER
    password_env: NETCONF_DEVICE_PASSWORD

ne:
  - id: "2"
    name: router-east
    router_ip: 10.255.255.2
    device: ref#devices.dev-2
  - id: "4"
    name: router-west
    router_ip: 10.255.255.4
    device: ref#devices.dev-4

port:
  - id: "3"
    name: 1/1/c2/1
    network_element: ref#ne[id=2]
  - id: "4"
    name: 1/1/c3/1
    network_element: ref#ne[id=2]
  - id: "7"
    name: 1/1/c2/1
    network_element: ref#ne[id=4]
  - id: "8"
    name: 1/1/c3/1
    network_element: ref#ne[id=4]

uni:
  - id: inmanta:456-852-789
    ports:
      - ref#port[id=3]
  - id: inmanta:456-985-752
    ports:
      - ref#port[id=4]
  - id: inmanta:123-852-456
    ports:
      - ref#port[id=8]
  - id: inmanta:456-852-798
    ports:
      - ref#port[id=7]

Built-in resources¶

Below are the built-in resources that the built-in inventory models:

devices: The network devices in the inventory. Its attributes are:
- mgmt_ip: the ip address Inmanta Connect should use to access the netconf/yang interface of this device
- mgmt_port: the port the netconf/yang interface is running
- vendor: the name of the vendor. Inmanta Connect uses this to determine what vendor a device is. Currently Cisco, Nokia and Juniper are supported.
- model: the router model to which is begin deployed. For example: ASR9001 or MX480. This value is currently not used and is only there for reference.
- os: the operating system running on the device. For example Junos, SR-OS, … This value is currently not used and is only there for reference.
- version: the version of the os running on the device. This is used for version specific work arounds.
- username_env: The environment variable on the orchestrator to fetch the device username from.
- password_env: The environment variable on the orchestrator to fetch the device password from.
ne: The network elements in the inventory. This represents the logical router running on the device. Its attributes are:
- id: A reference for the network element that is used internaly in the inventory
- name: The name of the network element.
- router_ip: The loopback ip of the router. This ip is used for example for LDP configuration.
- device: A reference to a device device resource.
port: A port on a network element. A customer can connect to one or more ports (see uni):
- id: An identifier used in the inventory to reference the port.
- name: The name of the port on a device. The orchestrator uses this value to reference the port.
- network_element: A reference to the network element this port belongs to.
uni: A user network interface models how a user is connected to the network. Its attributes are:
- id: An identifier used to reference this UNI. The built-in resolver will use this identifer when used as a uni reference. The resolver is used when the URI scheme is inmanta:.
- ports: A list of references to the ports that make up this UNI.
- [lag_id]: An optional attribute (combined with es_id). When multi-homing is used with EVPN, it is important to configure ethernet segments lag association. When this is enabled in the configuration, this value is used.
- [es_name]: An optional attribute (combined with es_id). When multi-homing is used with EVPN, it is important to configure ethernet segments. When this is enabled in the configuration, this value is used.
- [es_id]: See es_name

The inventory supports internal references to other resources. These references start with ref#. After that a dictpath expression is used.