Skip to content

IP trunks

IP trunks are core links between two GÉANT routers. The IP trunk is a special service since on the interfaces at the end of the trunk, no VLAN multiplexing is allowed. For this reason, in case of an IP trunk, we do not use the canonical decomposition that leverages a demarcation point.

Modelling and attributes

The relevant attributes for an IPTrunk are the following:

Attribute name Attribute type Description
geant_s_sid str GÉANT service ID associated with this trunk.
iptrunk_description str A human-readable description of this trunk.
iptrunk_type IptrunkType The type of trunk, can be either dark fibre or leased capacity.
iptrunk_speed str should be of PhyPortCapacity type The speed of the trunk, measured per interface associated with it.
iptrunk_minimum_links int The minimum amount of links the trunk should consist of.
iptrunk_isis_metric int The IS-IS metric of this link
iptrunk_ipv4_network IPv4Network The IPv4 network used for this trunk.
iptrunk_ipv6_network IPv6Network The IPv6 network used for this trunk.
iptrunk_side_node DeviceBlock The router that hosts the A side of the trunk.
iptrunk_side_ae_iface str The name of the interface on which the trunk connects.
iptrunk_side_ae_geant_a_sid str The service ID of the interface.
iptrunk_side_ae_members list[str] A list of interface members that make up the aggregated Ethernet interface.
iptrunk_side_ae_members_description list[str] The list of descriptions that describe the list of interface members.

Workflows

Deployment

This the workflow that brings the subscription from INACTIVE to PROVISIONING and finally to ACTIVE. The deployment of a new IPtrunk consist in the following steps:

  • Fill the form with the necessary fields:
    • SID
    • Type
    • Speed
    • Nodes
    • LAG interfaces with description
    • LAG members with description
  • WFO will query IPAM to retrieve the IPv4/IPv6 Networks necessary for the trunk. The container to use is specified in oss-params.json
  • The configuration necessary to deploy the LAG is generated and applied to the destination nodes using the Ansible playbook iptrunks.yaml This is done first in a dry mode (without committing) and then in a real mode committing the configuration. The commit message has the subscription_id and the process_id. Included in this, is the configuration necessary to enable LLDP on the physical interfaces.
  • Once the LAG interface is deployed, another Ansible playbook is called to verify that IP traffic can actually flow over the trunk ( iptrunk_checks.yaml)
  • Once the check is passed, the ISIS configuration will take place using the same iptrunks.yaml. Also in this case first there is a dry run and then a commit.
  • After this step the ISIS adjacency gets checked using again iptrunks_checks.yaml

The trunk is deployed with an initial ISIS metric of 9000 to prevent traffic to pass.

Termination

This workflow deletes all the configuration related with an IPtrunk from the network and brings the subscription from ACTIVE to TERMINATED. The steps are the following:

  • Modify the ISIS metric of the trunks so to evacuate traffic - and wait confirmation from an operator.
  • Delete all the configuration (first dry then actual deletion):
    • LAG and members of the LAG
    • reference in LLDP protocol (if juniper)
    • reference in ISIS protocol
  • Delete the IPv4/IPv6 networks from IPAM

Modification

To modify IP Trunks, have 2 different workflows exist:

  • Modify ISIS metric - modifies protocols/ISIS/interface
  • Modify Trunk interface - modifies lag interfaces and members. This is used to increase capacity or to change SID/interface descriptions.

In both cases, the strategy is to re-apply the necessary template to the configuration construct: using a "replace" strategy only the necessary modifications will be applied.

At the time of writing, the deletion of members from an existing IPtrunk is not supported.

Migration

TBA