# Managing network profiles Network profiles expand the default behavior of the network provisioning process to include more complicated scenarios such as configuring a list of VLANs to be terminated on the ports, which external connections to use, which VLANs should be the default VLAN on the ports etc. This allows customers to bridge infrastructures, connect them to on-premises networks and much more. ## Creating a new network profile Network profiles are created at the data-center level and are used by users. Unless given `network_profiles_write` permission regular users will not be able to create such profiles given the security risk this might generate but they can use the profiles. Note that the network profile feature must be enabled at the environment level via the Global Configuration tab in order for it to be active. :::{warning} Do not use in environments where end customers could be malicious as there is no mechanism to restrict which network profile is available to which customer at the moment. (Version 4.10.1) ::: A network profile of type WAN will change the behavior of the WAN provisioning process. Each network profile can have one or more VLAN entries. These VLAN entries control which VLANs (and in the case of the eVPN provisioner VNIs ) get terminated on the WAN port and how. Each VLAN entry has the following properties: 1. **vlanID** - int/null (Required) Defines which VLAN ID to use. A value of Null (or auto) means the system will automatically allocate a VLAN from the allowed WAN VLAN ranges configured in the data center configuration page. 2. **portMode** - string (Required) Defines how to terminate the VLAN: * `access` Only when no trunk mode VLANs are configured. It will be the VLAN of the physical port or ports of more than one is configured. * `native` This will be the VLAN ID of the physical port or ports of more than one is configured for untagged traffic. If traffic is received on the port the traffic will be tagged with this VLAN id before it is sent on the rest of the network. * `trunk` This will be a VLAN ID that will be `allowed` on the port. This means that if the server sends traffic tagged with this VLAN ID the switch port(s) will accept it and allow it to be forwarded in the rest of the network. 3. **provisionSubnetGateways** boolean If set, a SVI (switch virtual interface or vlan L3 interface(s)) will be created to act as gateway for the respective VLAN. All IPs marked as gateway IPs on the subnets will be configured on the respective VLAN interface. 4. **subnetPools** - Zero or more subnet pools defining what IP space will be assigned to the VLAN on the SVIs (if present) or on the server's associated interface. * subnetPoolID - int/null (required) Id of the subnet pool as defined by MetalSoft. If set to null the subnet pool will be automatically allocated from the WAN subnet pools matching `subnetPoolType` * subnetPoolType - string (required) one of `ipv4` and `ipv6` 5. **extConnectionIDs** - int List of external connection ids to which this VLAN id will be terminated. If set, the VLAN will be added as a `trunk` VLAN on the respective external connection ports on the border devices. 6. **provisionVXLAN** - Only applied to the eVPN provisioner, If set, will provision a VNI for the respective VLAN using the convention configured. Currently for VLAN 123 the VNI created will be VNI 10123. ### Configuring a custom access mode VLAN for the switch ports To configure a specific VLAN instead of allowing the default system create a VLAN entry with a VLAN ID with portMode `access`: ```yaml label: internal-network dc: test-datacenter networkType: wan vlans: - vlanID: 200 portMode: access provisionSubnetGateways: false provisionVXLAN: false extConnectionIDs: [] subnetPools: [] ``` ### Allowing a VLAN ID to be trunked on the port To allow a specific VLAN id to be trunked on the port from the server add a VLAN id entry with the custom VLAN, in addition to the `native` vlan. Note the use of `native` instead of `access` and null for the default vlan, signaling that the system should behave as normal for the access mode port but also allow traffic with tagged VLAN 200 to be sent to the switch interface. Create a file for the network profile: `network-profile.yaml`: ```yaml label: internal-network dc: test-datacenter networkType: wan vlans: - vlanID: null portMode: native provisionSubnetGateways: false provisionVXLAN: false extConnectionIDs: [] subnetPools: [] - vlanID: 200 portMode: trunk provisionSubnetGateways: false provisionVXLAN: false extConnectionIDs: [] subnetPools: [] ``` Create the network profile using the CLI: ``` metalcloud-cli network-profile create -datacenter test-datacenter -format yaml -raw-config ./network-profile.yaml ``` Note that in order for the associated Virtual Interface to be configured in the operating system, the unattended install process can use the variables defined in the [variables glossary](/content/configuration/os_templates/legacy_variables_glossary) to determine if there are secondary VLANs configured in the network profile and create the virtual interfaces. ### Specifying a custom subnet for a trunked VLAN To configure a specific subnet to be used on the trunked VLAN, create the subnet and use the subnetPools entry. For example create a file for the subnet: `subnet.yaml`: ```yaml datacenter: test-datacenter prefix: 172.16.200.0 netmask: 255.255.255.0 size: 24 type: ipv4 routable: false destination: WAN manualAllocationOnly: true ``` Note the `manualAllocationOnly` that disables automatic allocation to avoid accidental allocation to a user using the automatic settings. The `routable` flag controls if the IP allocated can be used by the system to check if the OS is installed, to configure the firewall or to SSH into the OS to install applications such as Kubernetes. Create the subnet using the CLI: ``` metalcloud-cli subnet-pool create -config ./subnet.yaml --return-id ``` Create a file for the network profile: `network-profile.yaml`: ```yaml label: internal-network dc: test-datacenter networkType: wan vlans: - vlanID: null portMode: native provisionSubnetGateways: false provisionVXLAN: false - vlanID: 200 portMode: trunk subnetPools: - subnetPoolID: 12 subnetPoolType: ipv4 provisionSubnetGateways: false provisionVXLAN: false ``` Create the network profile using the CLI: ``` metalcloud-cli network-profile create -datacenter test-datacenter -format yaml -raw-config ./network-profile.yaml ``` ### Extending a VLAN id to an External Connection on a border device To terminate a VLAN on an [external connection](/content/configuration/network/adding_an_external_connection) set the external connection id on the list of external connection ids. For example create a file for the network profile: `network-profile.yaml`: ```yaml label: internal-network dc: test-datacenter networkType: wan vlans: - vlanID: null portMode: native provisionSubnetGateways: false provisionVXLAN: false - vlanID: 200 portMode: trunk subnetPools: - subnetPoolID: 12 subnetPoolType: ipv4 provisionSubnetGateways: false provisionVXLAN: false extConnectionIDs: - 10 ``` Create the network profile using the CLI: ``` metalcloud-cli network-profile create -datacenter test-datacenter -format yaml -raw-config ./network-profile.yaml ``` ### Aggregating links into M-LAG or LAG groups If additional server interfaces are added to the WAN network, and if the "Link aggregation" option is enabled on the network profile, the behavior of the provisioning system changes to accommodate this scenario. 1. **Multiple interfaces in the SAME switch or with virtual chassis configurations (stacking)** * The VLAN configuration behavior is the same as with a single interface but applies to all interfaces in the link aggregation group * If `provisionSubnetGateways` is set to true, a single SVI is created on the common switch. * A link aggregation group is created and all interfaces are added to the group. 2. **Multiple interfaces in the different switches (using multi-chassis link aggregation - M-LAG or VLT)** * The VLAN configuration behavior is the same as with a single interface but applies to all interfaces in the multi-chassis link aggregation group on all involved switches * If `provisionSubnetGateways` is set to true, multiple SVIs are created on all switches. The gateway IP (.1) from each configured subnet in the `subnetPools` will be configured as movable IP (VRRP) between interfaces and additional IPs (.2, .3...) will be configured on the SVI interfaces. * A link aggregation group is created and all interfaces are added to the group. ### Using a member of a link aggregation without link aggregation configured Sometimes using a member of a link aggregation without bringing up the bond is needed such as with VMWare ESXI installations where vCenter is required for LACP based link aggregation to work but not available at the time of install. In order to determine which interface to configure in the operating system use compare the switch hostnames lexicografically and the switch with higher priority will be the one with the active interface. For example, if a server is connected to two switches: `aswitch` and `bswitch` then if link aggregation (bonding) is NOT configured on the Operating System, then link that will be active will always be the one connected to the switch named `aswitch` and the other one will be disabled. ### Example configuration Given the following setup: ![](/assets/guides/add_network_profile_5.svg) The server A will use network profile A: ```yaml label: internal-network dc: test-datacenter networkType: wan vlans: - vlanID: 2000 portMode: native provisionSubnetGateways: false provisionVXLAN: false - vlanID: 100 portMode: trunk subnetPools: - subnetPoolID: 12 subnetPoolType: ipv4 provisionSubnetGateways: false provisionVXLAN: true extConnectionIDs: - 10 ``` And server B will use network profile B: ```yaml label: internal-network dc: test-datacenter networkType: wan vlans: - vlanID: null portMode: 2000 provisionSubnetGateways: false provisionVXLAN: true ``` ## Adding a network profile using the Admin UI To add a new network profile: 1. go to the data center page and select the network profiles tab: ![](/assets/guides/add_network_profile_1.png) 2. Add a label, select the network type, set the default vlan for the port (or port group) and the range of allowed vlans in trunk mode. ![](/assets/guides/add_network_profile_2.png) 3. To modify a VLAN configuration and add an external connection for example go to the *Configuration* tab and click edit on the respective VLAN ![](/assets/guides/add_network_profile_3.png) ![](/assets/guides/add_network_profile_4.png) ### Creating a network profile with the cli: 1. Create a file `~/network-profile.yml`: ``` label: internet03 dc: us02-chi-qts01-dc networkType: wan vlans: - vlanID: 3207 portMode: "trunk" provisionSubnetGateways: false subnetPools: - subnetPoolID: 12 subnetPoolType: ipv4 extConnectionIDs: - 1 vlanID: null portMode: "native" extConnectionIDs: [] ``` 2. Create the network profile: ``` metalcloud-cli network-profile create --datacenter us02-chi-qts01-dc --format yaml --raw-config ~/network-profile.yml ``` ### Listing the existing network profiles: To list the network profiles: ``` % metalcloud-cli network-profile list --datacenter us02-chi-qts01-dc +-------+-----------------------------------+-------------------------------+-------------------------------+-----------+-----------+ | ID | LABEL | NETWORK TYPE | VLANs | CREATED | UPDATED | +-------+-----------------------------------+-------------------------------+-------------------------------+-----------+-----------+ | 6 | internet01 | wan | 3205 | | | | 7 | internet02 | wan | 3206 | | | | 9 | internet03 | wan | 3207 | | | | 10 | sdk-2022-06-08-21-46-u-hjpj5ae2zi | wan | 2644 | | | | 11 | sdk-2022-06-08-21-46-u-kt47zkbwiu | wan | 3598 | | | | 12 | sdk-2022-06-08-21-47-u-hxnvlzbi6c | wan | 3348 | | | | 13 | sdk-2022-06-08-21-48-u-xeoaphqweq | wan | 3838 | | | | 15 | sdk-2022-06-08-21-51-u-1t98fjo20m | wan | 1386 | | | +-------+-----------------------------------+-------------------------------+-------------------------------+-----------+-----------+ Total: 8 Network Profiles ``` To get details of a network profile: ``` % metalcloud-cli network-profile get -id 9 +-------+-------+---------------------+--------------------------------------------------------------------------------------+ | ID | LABEL | DATACENTER | DETAILS | +-------+-------+---------------------+--------------------------------------------------------------------------------------+ | #9 | inside| test-datacenter | VLAN ID: 201 (access) no GW EC:[metalsoft-demo (#1)] Subnets:[172.16.201.0/24 (#13)] | +-------+-------+---------------------+--------------------------------------------------------------------------------------+ Total: 1 ``` To retrieve a VLAN in raw format: ``` metalcloud-cli network-profile get -id 9 --format yaml --raw id: 9 label: inside dc: test-datacenter networkType: wan vlans: - vlanID: 201 portMode: access provisionSubnetGateways: false provisionVXLAN: false extConnectionIDs: - 1 subnetPools: - subnetPoolID: 13 subnetPoolType: ipv4 ``` ## Network profiles permissions Version 4.10.2 introduced support for restricting access to network profiles. Network profiles can now be private or public: 1. **Public** network profiles can be used by any user that provisions a server in a particular datacenter. 2. **Private** network profiles can only be used by users that have them listed in their allowed network profile user limit. By default network profiles are private to avoid accidents and need to be explicitly made public. Users with no network_profile_* permission (the default user role doesn't have these) can list and use only public network profiles and the allowed network profiles. They cannot create network profiles. The following permissions, along with user limits control the various functions of network profiles: * **network_profile_read** Allows the user that has it to list private network profiles along with public ones. * **network_profile_write** Allows the user to create a network profile. * **network_profile_allowed_for_user_read** Allows the user to read the profiles allowed for a particular user. * **network_profile_allowed_for_user_write** Allows the user to set the profiles allowed for a particular user. * **network_profile_allow_specific_vlan_ids** Allows the user to configure a specific VLAN id rather than auto-allocated. * **network_profile_mark_as_public** Allows the user to configure a specific network profile as public. ## Auto-allocation VLAN IDs > Available since: version 6.3 This mechanism allows the users to refer to VLAN IDs that were auto-allocated instead of referring to their ID. This allows users for example to "request" additional L2 networks and also use them across infrastructures by referring to a specific auto-allocated VLAN index instead of the VLAN ID. ## VRFs > Available since: version 6.3 VRFs can now be configured on a network profile. By default all network profile VLAN interfaces will be allocated to the default VRF. To specify which specific VRF to use when creating the gateway interface for the respective Overlay network (VLAN) either manually specify a VRF (which first needs to be created) or let the system auto-allocate from the available VRFs.