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 thesubscription_id
and theprocess_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