Configuration and Customization¶

Connect can be configuration and customized using configuration files and templates:

Topologies
Hardware/vendors
Allocation Policies
UNI Resolvers
Naming conventions
Etc.

The connect module will load its configuration from a file named connect-config.yaml, which should be located in the files folder of the project using this module. The project’s structure is depicted as below:

connect-project/
├── files
│   └── connect-config.yaml
├── libs
│   └── connect/
├── main.cf
└── project.yml

General Structure¶

The configuration module hosts all the settings related to the connect module. These ever-expanding settings are:

NokiaConfig: Contains all the specific config for Nokia routers, E.g. use of SDP.
LabelDistributionProtocolConfig: Contains all the specific config for LDP.
ServiceIdConfig: Contains all the specific config for allocating an EVC service ID.
CarrierEthernetEvcConfig: Contains all the specific config for Ethernet Virtual Connections.
MainConfig: Contains elements transient to the whole module usage.
ConnectConfig: This is the root of the configuration. Each entry in the configuration file should correspond to one of the embedded Config objects. If called by its default method, it’ll return configuration with all default values.
Configuration: Operates on connect-config.yaml file.

Configuration File Content¶

The available configuration fields in connect-config.yaml file are:

main: The main config, it contains elements transient to the whole module usage. The available options are:

inventory_path: The path to the inventory file on the machine where the orchestrator runs.

carrier_ethernet_evc: The CarrierEthernetEvc config. The available options are:

service_id: EVC service ID. Determines range and allocation strategy.
- start: Start of the service id range. (Value included in the range)
- end: End of the service id range. (Value included in the range)
- strategy: Strategy to use to determine the next service_id to allocate.
  - next: Take the first available id in the range.
  - any: Take any available id in the range.
backend: The CarrierEthernetEvc backend config. Currently the available options are LDP and EVPN.
- default: The default backend to use if none is specified.
- enabled: The list of supported backends that can be selected.
If the backend type is not provided, LDP is selected as the default value. In case the provided backend value is not supported an exception will be raised.

label_distribution_protocol: The LDP config. The available options are:

TBD

nokia: The Nokia config. The available options are:

customer_id: Customer id or path to a template that allows to render the customer id with some parameters (service instance)
netconf_retry_count: Number of retries before a failure.
netconf_retry_interval: Interval time in seconds between retries.
epipe: Nokia’s Epipe configuration:

Please note that unless stated otherwise, all the elements below have an instance attribute that is the CarrierEthernetEvcEndPoint instance using this template, as a DynamicProxy. For the sake of brevity it has been omitted and replaced with takes instance: true.
- enable_sdp: Controls the creation of Epipe with SDP.
- service_name: Epipe service name or path to a template that allows to generate it. The values available to the template are:
  - takes instance: true
  - vcid: The service id of the Epipe, as an integer.
- qos_ingress: QoS configuration for Epipe (ingress):
  - policy_name: Epipe policy name or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - policer_id: Epipe policer id or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - cbs: Epipe cbs or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - mbs: Epipe mbs or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - pir: Epipe pir or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
- qos_egress: QoS configuration for Epipe (egress):
  - policy_name: Epipe policy name or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - queue_id: Epipe queue id or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - cbs: Epipe cbs or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - mbs: Epipe mbs or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
  - pir: Epipe pir or a path to a template that allows to generate it. The values available to the template are:
    - takes instance: true
- evpn: EVPN configuration for Nokia
  - bgp: BGP configuration for Nokia
    - resolution: Resolution method for tunnel selection
    - tagging: Enable/disable enforcement of strict tunnel tagging
    - filters: Resolution filters for auto-bind-tunnel
      - ldp: Enable/disable setting LDP type for auto-bind-tunnel
      - rsvp: Enable/disable setting RSVP-TE type for auto-bind-tunnel
      - sr_isis: Enable/disable setting SR-ISIS type for auto-bind-tunnel
      - sr_te: Enable/disable setting SR-TE type for auto-bind-tunnel

This is how the configuration looks like:

carrier_ethernet_evc:
  backend:
    default: LDP
    enabled:
    - LDP
    - EVPN
  service_id:
    start: 1
    end: 100
    strategy: next
label_distribution_protocol: {}
main:
  inventory_path: inmanta:///connect-inventory.yaml
nokia:
  customer_id: '1'
  epipe:
    enable_sdp: true
    service_name: template://connect/nokia/epipe_service_name.j2
    qos_egress:
      policy_name: default-policy
      queue_id: 3
      cbs: auto
      mbs: auto
      pir: max
    qos_ingress:
      policy_name: default-policy
      policer_id: 3
      cbs: auto
      mbs: auto
      pir: max
    evpn:
      bgp:
        resolution: any
        tagging: True
        filters:
          ldp: False
          rsvp: False
          sr_isis: False
          sr_te: False
  netconf_retry_count: 5
  netconf_retry_interval: 5

Controlling the virtual circuit identifier (vcid) with service_id¶

Each deployment of a CarrierEthernetEvc using LDP backend will need to receive an unused vcid. This id is then used for configurations such as the Epipe and sdp id. This value is not passed on via the API, the model will receive it through allocation. The allocator is given a range of values that can be used, it is aware of the values it has already allocated and based on this and the allocation strategy (next, for sequential allocation, or any, for random allocation) will pick the allocated vcid.

The user of the module can influence the behavior of the allocator with three parameters in the configuration file:

carrier_ethernet_evc.service_id.start: The lowest value that can be allocated.
carrier_ethernet_evc.service_id.end: The highest value that can be allocated.
carrier_ethernet_evc.service_id.strategy: The strategy to use when selecting the next allocated value. Possible values are:
- next: Select the first free value in the range.
- any: Select any free value in the range.

Controlling the ethernet virtual interconnect (evi) with service_id¶

Each deployment of a CarrierEthernetEvc using EVPN backend will need to receive an unused evi. This id is then used for configs such as the Epipe and evi id. This value is not passed on via the API, the model will receive it through allocation. The allocator is given a range of values that can be used, it is aware of the values it has already allocated and based on this and the allocation strategy (next, for sequential allocation, or any, for random allocation) will pick the allocated evi.

The behavior of the allocator can be influenced similar to the vcid, by editing the carrier_ethernet_evc.service_id part of the configuration.

Generating A Default Configuration File¶

Running the following command will generate a default configuration file using the configuration plugin:

python connect/docs/configuration/new_conf.py <path_to_store_config_file>

For example:

python connect/docs/configuration/new_conf.py /home/user/connect-project/files/connect-config.yaml

Special values¶

Most of the configuration fields accept a specific primitive type while others have stricter requirements. Moreover, three additional types which are of primitive constraints are introduced:

InmantaPath: A string prefixed by inmanta://. The rest of the string should be a path to a file in an Inmanta module or project. NOTE: All files should be located in the files/ folder of the module or the project
SystemPath: A string prefixed by file://. The rest of the string should be an absolute path to a file on the system where the compiler is running.
TemplatePath: A string prefixed by template://. The rest of the string should be a path to a template in an inmanta module or project. (All templates should be located in the templates/ folder of the module or project)

In the specific case of InmantaPath and TemplatePath, the part past the prefix will be treated in this way:

If the path starts with /, the path is in the project’s files (or templates) folder. For example, inmanta:///example/inventory.yaml points to a file located in files/example/inventory.yaml at the root of the project using this module.
If the path doesn’t start with /, the part of the string before the first / is the name of the module in the files directory in which the inventory is located. For example, inmanta://example/inventory.yaml points to a file located in files/inventory.yaml at the root of the module named example.

Using templates¶

Some configuration fields accept a path to a template located in an inmanta module or project. Those fields accept a value of type TemplatePath, and can also accept a simpler value of a primitive type. In the former case, the path should point to a Jinja2 template (the extension of the file doesn’t matter, but the content does). This template will be rendered at compile time when calling one of the get_config_template_value plugins (there is one by primitive type of the inmanta language). The values used for the rendering are provided in the plugin parameters.

Example: A template has already been added to this module: nokia/epipe_service_name.j2.

The template path to reach it is: template://connect/nokia/epipe_service_name.j2. This is the default value of nokia.epipe_service_name in the configuration.
The template content is epipe-{{ vcid }}
This template is used to generate the name of the Epipe service, from the vcid.
In the model, the template is rendered and accessed like this:
```
connect::get_config_template_value_as_string(
    "nokia.epipe_service_name",
    instance=self,
    kwargs={
        "vcid": vc_id,
    },
),
```
The plugins takes three parameters:
- dict_path: The path to the configuration value in which the template path should be found.
- instance: (Optional) An inmanta instance, in this case the one in which implementation we call the plugin from.
- kwargs: (Optional) A dict, containing key-value pairs, values can only be inmanta primitive types (no entities).