Skip to content
Snippets Groups Projects

Architecture section

Merged Architecture section
architecture_section into develop
Merged Simone Spinelli requested to merge architecture_section into develop
Compare
and
34 files
+ 822
− 200
Compare changes
  • Side-by-side
  • Inline
Files
34
docs/admin_guide/WFO/iptrunks.md deleted 100644 → 0
+ 0
− 80
# IP trunks
IPtrunks are core links between two GÈANT routers.
IPtrunk 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 IPtrunk we do not use the canonical decomposition that leverages demarcation point.
## Modelling and attributes
The relevant attributes for an IPTrunk are the following|
| Attribute name | Attribute type | Description |
| -------------- | -------------- | ----------- |
| geant_s_sid| String | 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_sideA_node| DeviceBlock|The router that hosts the A side of the trunk.|
|iptrunk_sideA_ae_iface| str|The name of the interface on which the trunk connects.|
|iptrunk_sideA_ae_geant_a_sid| str|The service ID of the interface.|
|iptrunk_sideA_ae_members| list[str] = Field(default_factory=list)|A list of interface members that make up the aggregated Ethernet interface.|
|iptrunk_sideA_ae_members_description| list[str] = Field(default_factory=list)|The list of descriptions that describe the list of interface members.|
|iptrunk_sideB_node| DeviceBlock|The router that hosts the B side of the trunk. It possesses the same attributes as the A-side, including the interfaces and its descriptions.|
|iptrunk_sideB_ae_iface| str | Same as iptrunk_sideA_ae_iface but for B side|
|iptrunk_sideB_ae_geant_a_sid| str | Same as iptrunk_sideA_ae_geant_a_sid but for B side |
|iptrunk_sideB_ae_members| list[str] = Field(default_factory=list) | Same as iptrunk_sideA_ae_members but for B side|
|iptrunk_sideB_ae_members_description| list[str] = Field(default_factory=list) | Same as iptrunk_sideA_ae_members_description but for B side|
## 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 contains the subscription_id and the process_id. Included in this there is also 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.
### Undeployment
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 IPtrunks we have 2 different workflows:
- 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/Iface 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