Manual Chapter : Network Settings

Applies To:

  • F5OS-C

    2.0.0

back-action VELOS Systems: Administration and Configuration

Updated Date: 06/30/2026

Network Settings

The chassis administrator can perform general networking tasks for the system controllers, such as configuring management interfaces for the system controllers, enabling DHCP, and setting up DNS for the VELOS platform. You can configure network settings at the system controller level from the webUI, the CLI, or REST APIs.

Much of the L2 network configuration on VELOS systems is performed at the chassis partition level by a chassis partition administrator. The administrator logs into the chassis partition to view or configure port groups, interfaces, VLANs, and create LAGs for that chassis partition. You can configure network settings at the chassis partition level from the webUI, the CLI, or REST API.

The front-panel ports on VELOS blades support port group functionality. Port groups enable you to configure the mode of the physical port, which controls the port speed and whether the port is bundled or unbundled. Until configured, the VELOS system uses port speeds of 100G. You can change them based on what optical transceiver module type you are using.

Before configuring any interfaces, VLANs, or LAGs, you can set up port groups so that physical interfaces on the blade are configured for the proper speed and bundling. Depending on the port group mode, a different FPGA version is loaded, and the speed of the port is adjusted accordingly. The system creates the port group components, based on the type of blades installed.

Changing the mode for a port group reboots the blade, removes stale interfaces from your configuration, and removes any references to stale interfaces from your configuration. You will then need to reconfigure any previously-configured protocols to use the modified port group.

The VELOS BX520 blade supports homogeneous and limited mixed portgroup mode combinations per blade. You can configure the port groups using the specific port group combination. Available port groups combination for the interfaces on BX520:

Port group 1 (interface 1.0)

Port group 2 (interface 2.0)

100G

400G

4x100G

4x100G

Example: If the port group 1 is set 100G, then port group 2 must be set to 400G.

You can configure port groups to use a specific mode depending on how you are connecting your blades to an upstream switch from the chassis partition webUI.

Important: Changing the port group mode impacts the view of physical interfaces published by the system. The previous interfaces that corresponded to the previous port group mode are deleted, and new ones are created. All configuration associated with the deleted interfaces is also lost.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > Port Groups.

  3. For a specific slot (blade) and port (Port 1 or Port 2), select a Mode from the list.

    For BX110 blades, select one of these options:

    Option Description
    100GbE Creates one interface at 100G speed.
    40GbE Creates one interface at 40G speed.
    4 x 25GbE Creates four interfaces at 25G speed (requires the use of a breakout cable).
    4 x 10GbE Creates four interfaces at 10G speed (requires the use of a breakout cable).

    For BX520 blades, select one of these options:

    Port Group Option Description
    Port group 1 100GbE Creates one interface at 100G
    4 x 100GbE Creates four interfaces at 100G speed (requires the use of a breakout cable).
    Port group 2 400GbE Creates one interface at 400G
    4 x 100GbE Creates four interfaces at 100G speed (requires the use of a breakout cable).

    Note: The VELOS BX520 blade support homogeneous and limited mixed portgroup mode combinations per blade. You can configure the port groups using the specific port group combination.

    Depending on the port group mode, a different FPGA version is loaded and the speed of the port is adjusted accordingly.

  4. Click Save.

When you change the port group mode on ports for a specific blade, the blade reboots. The previous interfaces that corresponded to the previous port group mode are deleted, and the associated (underlying) configuration is also lost.

For BX110 blades, you can configure a port group for the interfaces on the blade at either 100GbE or 40GbE speeds from the chassis partition CLI. You can also break out the ports to either 4x25GbE or 4x10GbE.

For BX520 blades support homogeneous and limited mixed portgroup mode combinations per blade. You can configure the port groups using the specific port group combination.

Important: VELOS blades support homogeneous port groups per blade, which means that if you want to change the speed of a port group, you must change the mode for both port groups on a blade.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Configure port groups for a specific blade/interface pair.

    • For BX110 Blades:

      portgroups portgroup <*blade-number*>/<*interface-number*> config mode [ MODE\_100GB | MODE\_4x25GB | MODE\_40GB | MODE\_4x10GB \| MODE\_400GB]

      In this example, you configure the port group mode on a BX110 blade, on blade 1/interface 2 to use the 40GB mode:

      default-1(config)# portgroups portgroup 1/2 config mode MODE_40GB

    • For BX520 Blades:

      Note: You can configure the port groups using the specific port group combination.

      portgroups portgroup <*blade-number*>/<*interface-number*> config mode [ MODE\_100GB | MODE\_4x10GB]

      portgroups portgroup <*blade-number*>/<*interface-number*> config mode [ MODE\_400GB | MODE\_4x10GB]

      In this example, with the default running configuration donot allow changing the mode of only one of the portgourps.

      default-1# show running-config portgroups

portgroups portgroup 5/1

config mode MODE_100GB

config ddm ddm-poll-frequency 30

!

portgroups portgroup 5/2

config mode MODE_400GB

config ddm ddm-poll-frequency 30

!

default-1# config                                                                                                                                                                               

Entering configuration mode terminal

default-1(config)# portgroups portgroup 5/1 config mode MODE_4x100GB                     

default-1(config-portgroup-5/1)# commit

Aborted: 'portgroups portgroup': Homogeneous and limited mixed portgroup mode combinations are supported per blade. The portgroups from blade(s) 5 do not follow the constraint.

default-1(config-portgroup-5/1)

  5. Commit the configuration changes.

    commit

  6. Verify the port groups configuration.

    show portgroups portgroup

VELOS blades support two kinds of physical network interfaces:

  • Interfaces that correspond to the blade front-panel QSFP28 ports
  • Link aggregation groups (LAGs)

F5OS v2.0 now supports Q-in-Q VLAN tagging. Q-in-Q VLAN tagging (also known as IEEE 802.1ad or double tagging) lets you add a service tag (S-tag) to packets that already have a customer tag (C-tag). This feature is designed for service provider (SP) edge roles on F5 VELOS platforms running F5OS.

With the feature Q-in-Q VLAN tagging, you can:

Add an S-tag on ingress: A single-tagged packet arrives with a C-tag. The system adds an S-tag before it enters the SP backbone network. Remove an S-tag on egress: A double-tagged packet arrives from the SP backbone. The system strips the S-tag and forwards the packet with only its C-tag. Subinterfaces let you define multiple Q-in-Q tagging rules on a single physical interface. Each subinterface maps a specific C-tag to an S-tag, so you can handle multiple VLAN mappings on one port without dedicating separate physical interfaces to each. This keeps traffic logically isolated while reducing the number of ports you need.

Note: This feature supports with latest FPGA bitfiles that support the double tag handling.

Supported platforms

Q-in-Q tagging is supported on the following platforms:

  • F5 VELOS: CX410 chassis with BX110 blade

  • S-tag and C-tag mapping: A port or trunk cannot push different S-tags for the same C-tag. The S-tag you use must be included in the trunk VLANs configured on the interface, and the ingress and egress S-tag on the same subinterface must match.

  • Under a single interface one s-tag can be used for only one action.

  • FPGA constraints: The FPGA only supports 0x88A8 as the outer Tag Protocol Identifier (TPID) and allows a maximum of 16 S-tags per interface. If a subinterface configures a POP action for an S-tag, that action applies to all subinterfaces that share the same S-tag, because the FPGA uses only the S-tag to decide whether to delete the tag on egress.

  • Interface restrictions: An interface cannot use Q-in-Q while it is a Link Aggregation Group (LAG) member or a virtual-wire member. The same restriction applies to LAGs configured as virtual-wire members.

  • Supported actions: Ingress-mapping supports PUSH only; egress-mapping supports POP only.

  • Packet processing: If a port is configured for double-tagged packets, the system accepts any double-tagged packet that matches the S-tag but does not process it further unless you specify an action to add or remove tags.

  • Wildcard customer tags are not visible in the configuration. Quality of Service (QoS) settings for Q-in-Q are managed within the tenant and cannot be controlled at the platform level.

  • Modifying Q-in-Q tagged configurations requires you to reverse the original setup process. Follow the steps in reverse order to avoid service disruption.

Important:

  • Review your current Q-in-Q configuration before making changes. Reversing the process incorrectly can affect tenant traffic.
  • When configuring subinterfaces for Q-in-Q tagging, the inner VLAN IDs field corresponds to the C-tag, and the VLAN ID fields for ingress and egress correspond to the S-tag.

Before you begin, you must already have created the VLANs that you want to associate with the interface. If you intend to create LAGs, you should wait to associate VLANs with interfaces, because an interface cannot be used as a LAG member if it is associated with an interface.

You can configure interfaces from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > Interfaces.

    A table showing all interfaces displays.

  3. Click an interface name from the list. Edit interface screem displays.

  4. For Description, enter a description of the interface.

  5. For State, select whether the interface is Enabled or Disabled.

  6. The next few settings are informational and cannot be changed (for example, Operational Status, Speed, MAC Address, and Interface Type are set values).

  7. For MTU, the maximum transmissions unit is set to the default value of 9600 (read only).

    This is the largest size that the system allows for an IP datagram passing through a physical interface.

  8. Forward Error Correction can be set to Auto, Enabled, or Disabled. The default value is Auto, which detects and corrects a limited number of errors in transmitted data.

    Note: Since this setting is enabled automatically, your upstream switch must also support Forward Error Correction (FEC).

  9. For Native VLAN (Untagged), select the VLAN ID to use for untagged frames received on an interface (either a single interface or LAG).

    Note: An interface or LAG can have only one Native VLAN assigned to it. You can use a Native VLAN with multiple LAGs or interfaces. You cannot use a VLAN, however, as both a Native and Trunk VLAN for the same interface.

  10. For Trunk VLANs (Tagged), select one or more VLAN IDs, if available, and not a member of another LAG; this is used for tagged traffic.

    You can use the same VLAN ID as the Trunk VLAN across all interfaces or LAGs. You cannot use a VLAN, however, as both a Native and Trunk VLAN for the same interface.

    Note:

    • A Trunk VLAN or a Native VLAN is required to pass traffic. If you do not select either a Native VLAN or a Trunk VLAN, the port will not carry any traffic.

    • After configuring, click Save & Stay to proceed with subinterface configuration.

    • Subinterface configuration is not supported on interfaces that are part of a LAG. As a result, the subinterfaces card will not be available for these interfaces. To configure the subinterfaces, expand the section Subinterfaces: Click Add. To add new sub interface, configure the following fields:

  11. To configure the subinterfaces, expand the section Subinterfaces:

    1. Click Add. To add new sub interface, configure the following fields:

      Field Description Valid values
      Index Numeric identifier that uniquely distinguishes the subinterface from all others on the parent interface. —
      Description Free-text description for the subinterface. —
      VLAN ID or S-tag (ingress) VLAN identifier for ingress traffic. Values outside the valid range produce an inline error. 1–4094
      VLAN stack action (ingress) Operation to perform on the VLAN stack for ingress packets. POP, PUSH
      VLAN ID or S-tag (egress) VLAN identifier for egress traffic. Values outside the valid range produce an inline error. 1–4094
      VLAN stack action (egress) Operation to perform on the VLAN stack for egress packets. POP, PUSH
      Inner VLAN IDs List of VLAN identifiers used to match traffic. Enter a value and press Enter to add it to the list. Duplicates are discarded. 1–4094

    2. Click Save.

  12. Click Save, to save the confiugration.

You can delete subinterfaces for an interface from the webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > Interfaces.

    A table showing all interfaces displays.

  3. Click an interface name.

  4. Expand the section Subinterfaces.

  5. Select the check box of each subinterface to be removed. Multiple selections are permitted.

  6. Click Delete.

    A confirmation dialog appears, listing the subinterfaces selected for deletion.

  7. Click Confirm to remove the selected subinterfaces or Cancel to abort the action.

You can configure front-panel interfaces from the chassis partition CLI.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Configure settings for the specified interface.

    interfaces interface <*blade-number*>/<*interface-number*> config { disabled | enabled } description <*interface-description*> type <*interface-type*>

    In this example, you enable and configure blade 1/interface 1.0 with a custom description:

    default-1(config)# interfaces interface 1/1.0 config enabled description 
  "Interface 1/1.0"

  4. Commit the configuration changes.

    commit

You can configure Q-in-Q on front-panel interfaces from the CLI. In a typical setup, one interface faces the Customer Edge (CE) and handles single-tagged packets, while the other interface faces the service provider backbone and handles double-tagged packets.

The customer-facing interface receives single-tagged packets from the Customer Edge. You configure subinterfaces to match customer VLAN tags (C-tags), then PUSH an S-tag on ingress and POP it on egress.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Configure the interface type and enable it.

    interfaces interface 1/1.0
config type ethernetCsmacd
config enabled
config forward-error-correction auto

  4. Add the S-tag VLANs to the trunk.

    ethernet switched-vlan config trunk-vlans [ 101 201 ]

  5. Create a subinterface for each C-tag. For each subinterface, match the inner VLAN ID (C-tag), then set the ingress action to PUSH the S-tag and the egress action to POP it.

    In this example, subinterface 1 matches C-tag 10 and maps it to S-tag 101. Subinterface 2 matches C-tag 20 and maps it to S-tag 201.

    subinterfaces subinterface 1
vlan match double-tagged-inner-list config inner-vlan-ids [ 10 ]
vlan ingress-mapping config vlan-stack-action PUSH
vlan ingress-mapping config vlan-id 101
vlan egress-mapping config vlan-stack-action POP
vlan egress-mapping config vlan-id 101
!
subinterfaces subinterface 2
vlan match double-tagged-inner-list config inner-vlan-ids [ 20 ]
vlan ingress-mapping config vlan-stack-action PUSH
vlan ingress-mapping config vlan-id 201
vlan egress-mapping config vlan-stack-action POP
vlan egress-mapping config vlan-id 201
!
!

  6. Commit the configuration changes.

    commit

  7. Verify the subinterface configuration

    show interfaces interface 1/1.0 subinterfaces

    Example:

    subinterfaces subinterface 1
state index 1
vlan match double-tagged-inner-list state inner-vlan-ids [ 10 ]
vlan ingress-mapping state vlan-stack-action PUSH
vlan ingress-mapping state vlan-id 101
vlan egress-mapping state vlan-stack-action POP
vlan egress-mapping state vlan-id 101
subinterfaces subinterface 2
state index 2
vlan match double-tagged-inner-list state inner-vlan-ids [ 20 ]
vlan ingress-mapping state vlan-stack-action PUSH
vlan ingress-mapping state vlan-id 201
vlan egress-mapping state vlan-stack-action POP
vlan egress-mapping state vlan-id 201


simulator-1# show interfaces interface 1/1.0 subinterfaces 
                        INNER  INNER   VLAN                       VLAN                       
                        VLAN   VLAN    STACK   VLAN               STACK   VLAN               
INDEX  INDEX  DESCRIPTION  ID     IDS     ACTION  ID    TPID         ACTION  ID    TPID         
------------------------------------------------------------------------------------------------
1      1      CE        -      [ 10 ]  PUSH    101   TPID_0X88A8  POP     101   TPID_0X88A8
2      2      CE          -      [ 20 ]  PUSH    201   TPID_0X88A8  PUSH    201   TPID_0X88A8

The service provider interface connects to the backbone network. Packets on this interface are already double-tagged, so you do not need to set a PUSH or POP action. You only need to match the inner VLAN ID and map it to the correct S-tag.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access. When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config`

    The CLI prompt changes to include (config).

  3. Configure the interface type and enable it.

    interfaces interface 1/2.0
config type ethernetCsmacd
config enabled
config forward-error-correction auto

  4. Add the S-tag VLANs to the trunk.

    ethernet switched-vlan config trunk-vlans [ 101 201 ]

  5. Create a subinterface for each C-tag. Match the inner VLAN ID and set the S-tag VLAN ID. Do not configure a vlan-stack-action because the packets are already double-tagged.

    In this example, subinterface 1 matches C-tag 10 with S-tag 101, and subinterface 2 matches C-tag 20 with S-tag 201.

    subinterfaces subinterface 1
config description SP-backbone
vlan match double-tagged-inner-list config inner-vlan-ids [ 10 ]
vlan ingress-mapping config vlan-id 101
subinterfaces subinterface 2
config description SP-backbone
vlan match double-tagged-inner-list config inner-vlan-ids [ 20 ]
vlan ingress-mapping config vlan-id 201
!
!

  6. Commit the configuration changes.

    commit

  7. Verify the subinterface configuration

show interfaces interface 1/2.0 subinterfaces

**Example:**

```
subinterfaces subinterface 1
state index 1
state description SP-backbone
vlan match double-tagged-inner-list state inner-vlan-ids [ 10 ]
vlan ingress-mapping state vlan-id 101
subinterfaces subinterface 2
state index 2
state description SP-backbone
vlan match double-tagged-inner-list state inner-vlan-ids [ 20 ]
vlan ingress-mapping state vlan-id 201


                        INNER             VLAN                       VLAN
                        VLAN   INNER      STACK   VLAN               STACK   VLAN
INDEX  INDEX  DESCRIPTION  ID     VLAN IDS   ACTION  ID    TPID         ACTION  ID    TPID
---------------------------------------------------------------------------------------------------
1      1      SP-backbone  -      [  10   ]  -       101   TPID_0X88A8  -       -     TPID_0X88A8
2      2      SP-backbone  -      [  20   ]  -       201   TPID_0X88A8  -       -     TPID_0X88A8
```

You can show the state of a specified front-panel interface from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Show the state of a specified interface.

    show interfaces interface <*blade-number*>/<*interface-number*> state

    In this example, you show information about blade 1/interface 1.0:

    default-1# show interfaces interface 1/1.0
interfaces interface 1/1.0
 state type               ethernetCsmacd
 state mtu                9600
 state enabled            true
 state oper-status        DOWN
 state counters in-octets 0
 state counters in-unicast-pkts 0
 state counters in-broadcast-pkts 0
 state counters in-multicast-pkts 0
 state counters in-discards 0
 state counters in-errors 0
 state counters in-fcs-errors 0
 state counters out-octets 0
 state counters out-unicast-pkts 0
 state counters out-broadcast-pkts 0
 state counters out-multicast-pkts 0
 state counters out-discards 0
 state counters out-errors 0
 state forward-error-correction not_supported
 state lacp_state         LACP_DEFAULTED
 ethernet state port-speed SPEED_40GB
 ethernet state hw-mac-address f4:15:63:fc:58:00
 ethernet state counters in-mac-control-frames 0
 ethernet state counters in-mac-pause-frames 0
 ethernet state counters in-oversize-frames 0
 ethernet state counters in-jabber-frames 0
 ethernet state counters in-fragment-frames 0
 ethernet state counters in-8021q-frames 0
 ethernet state counters in-crc-errors 0
 ethernet state counters out-mac-control-frames 0
 ethernet state counters out-mac-pause-frames 0
 ethernet state counters out-8021q-frames 0
 ethernet state flow-control rx off

    ​​​​​​The below tables describe various state and ethernet state counters that you may come across when viewing the status of a specific interface.​​​​

    Counter name

    Description

    ​​​​​​in-octets​​​​

    ​​​​​​Refers to the number of inbound data packets, measured in octets (bytes), received by a network interface. It helps you to track the volume of data entering a specific port or interface.​​​​

    ​​​​​​in-unicast-pkts​​​​

    ​​​​​​Refers to the number of inbound unicast packets received by a network interface. It provides insight into the volume of direct, one-to-one communications traversing the interface, which can help identify trends, optimise performance, or troubleshoot connectivity issues.​​​​

    ​​​​​​in-broadcast-pkts​​​​

    ​​​​​​Refers to the number of inbound broadcast packets received by a network interface. Tracking broadcast packet volumes helps network administrators ensure efficient communication and quickly address anomalies.​​​​

    ​​​​​​in-multicast-pkts​​​​

    ​​​​​​Refers to the number of inbound multicast packets received by a network interface. Tracking multicast packet volumes, administrators can assess network efficiency, detect potential issues, and optimise multicast traffic handling.​​​​

    ​​​​​​in-discard​​​​

    ​​​​​​Refers to the number of inbound packets received by a network interface that were discarded before being processed or forwarded. Monitoring “in-discard” is essential for identifying misconfigurations and performance issues in a network. A high number of discarded packets often indicates the need for troubleshooting or resource adjustments to ensure smooth network operation.​​​​

    ​​​​​​in-errors​​​​

    ​​​​​​Refers to the number of inbound packets received by a network interface that encountered errors, preventing them from being processed successfully. Monitoring “in-errors” helps network administrators identify and resolve underlying problems affecting data integrity or performance, ensuring reliable communication across the network.​​​​

    ​​​​​​in-fcs-errors​​​​

    ​​​​​​Refers to the number of inbound packets that failed the ​​​​​​Frame Check Sequence (FCS)​​​​ verification. A high count of FCS errors suggests issues with the physical network infrastructure or transmission quality. Monitoring and addressing these errors is crucial to maintaining reliable and error-free communication.​​​​

    ​​​​​​out-octets​​​​

    ​​​​​​Refers to the number of outbound data packets, measured in octets (bytes), transmitted by a network interface. Monitoring “out-octets” helps:​​​​​​​​​​- ​​​​​​Analyze traffic patterns.​​​​

    • ​​​​​​Measure bandwidth usage.​​​​

    ​​​​​​​​​​Detect unusual activity, such as spikes in outgoing data, which may indicate potential issues like data leaks or malicious activity.​​​​

    ​​​​​​out-unicast-pkts​​​​

    ​​​​​​Refers to the number of outbound unicast packets transmitted by a network interface. Monitoring “out-unicast-pkts” helps ensure optimal network efficiency and detect any anomalies, such as unexpected surges or drops in unicast traffic.​​​​

    ​​​​​​out-broadcast-pkts​​​​

    ​​​​​​Refers to the number of outbound broadcast packets transmitted by a network interface. Excessive broadcast traffic can strain the network, so monitoring “out-broadcast-pkts” is critical for identifying potential issues like misconfigured devices, network loops, or overuse of broadcast communication.​​​​

    ​​​​​​out-multicast-pkts​​​​

    ​​​​​​Refers to the number of outbound multicast packets transmitted by a network interface. Tracking “out-multicast-pkts” helps ensure multicast traffic is effectively managed to optimise network performance and minimize congestion.​​​​

    ​​​​​​out-discards​​​​

    ​​​​​​Refers to the number of outbound packets that a network interface discarded before transmission. Monitoring “out-discards” is crucial for diagnosing network bottlenecks, optimising configurations, and ensuring efficient data flow. A high number of discards often indicates that the network requires tuning or scaling to handle traffic demands.​​​​

    ​​​​​​out-errors​​​​

    ​​​​​​Refers to the number of outbound packets that encountered errors during transmission by a network interface, preventing them from being successfully sent. Monitoring “out-errors” helps identify and address issues impacting network reliability. Persistent or high error counts may require troubleshooting hardware, optimising configurations, or inspecting the physical network environment for faults.​​​​

    Counter name

    Description

    ​​​​​​in-mac-control-frames​​​​

    ​​​​​​Refers to the number of inbound ​​​​​​MAC control frames​​​​ received by a network interface. Monitoring “in-mac-control-frames” helps network administrators understand and manage flow control events and ensure that network devices handle congestion and prioritisation effectively. A high volume of these frames could indicate congestion or misconfigured flow control settings.​​​​

    ​​​​​​in-mac-pause-frames​​​​

    ​​​​​​Refers to the number of inbound ​​​​​​MAC pause frames​​​​ received by a network interface. Monitoring “in-mac-pause-frames” is crucial for understanding the flow control dynamics in a network. A high count of pause frames could indicate network congestion suggesting the need to optimise traffic flow.​​​​

    ​​​​​​in-oversize-frames​​​​

    ​​​​​​Refers to the number of inbound frames that exceed the maximum allowed size for Ethernet frames. Monitoring “in-oversize-frames” is important for diagnosing network issues, misconfigurations, or potential security concerns. A high count of oversized frames may indicate the need for adjustments in network settings or further investigation into the cause.​​​​

    ​​​​​​in-jabber-frames​​​​

    ​​​​​​Jabber frames are Ethernet frames that exceed the maximum allowable frame size due to a malfunction or error during transmission. Monitoring “in-jabber-frames” is crucial for identifying potential hardware or network issues. A high count of jabber frames may indicate a need to replace or troubleshoot the network equipment responsible for generating them.​​​​

    ​​​​​​in-fragment-frames​​​​

    ​​​​​​Fragmented frames refer to Ethernet frames that are smaller than the minimum allowed size for a valid Ethernet frame. Monitoring “in-fragment-frames” helps identify potential issues with packet fragmentation, MTU mismatches, or excessive fragmentation in network traffic, which may indicate underlying network problems that need to be addressed.​​​​

    ​​​​​​in-8021q-frames​​​​

    ​​​​​​Refers to the number of inbound ​​​​​​802.1Q frames​​​​ received by a network interface. A high count of 802.1Q frames indicates active VLAN usage on the interface and can help ensure that VLAN configurations are functioning as intended.​​​​

    ​​​​​​in-crc-errors​​​​

    ​​​​​​Refers to the number of inbound packets that failed the ​​​​​​Cyclic Redundancy Check (CRC)​​​​, which is a method used to detect errors in data transmission. Monitoring “in-crc-errors” is important for diagnosing hardware failures, poor signal quality, or network infrastructure problems. A high number of CRC errors often signals that physical layer issues need to be addressed.​​​​

    ​​​​​​out-mac-control-frames​​​​

    ​​​​​​Refers to the number of outbound ​​​​​​MAC control frames​​​​ transmitted by a network interface. Monitoring “out-mac-control-frames” helps network administrators understand and manage flow control, ensuring that devices communicate effectively under heavy load or congestion. A high number of these frames may indicate traffic issues, such as congestion or the need for better flow control configuration.​​​​

    ​​​​​​out-mac-pause-frames​​​​

    ​​​​​​Refers to the number of outbound ​​​​​​MAC pause frames​​​​ transmitted by a network interface. Monitoring “out-mac-pause-frames” is important for:​​​​​​​​​​- ​​​​​​​​​​​​Flow control management​​​​, ensuring that devices do not become overwhelmed with data.​​​​

    • ​​​​​​​​​​​​Detecting network congestion​​​​ or performance issues that may require optimisation, such as adjusting buffer sizes or traffic patterns.​​​​
    • ​​​​​​​​​​​​Troubleshooting excessive pause frame transmission​​​​, which can indicate issues like network bottlenecks or misconfigured devices.​​​​

    ​​​​​​​​​​A high number of pause frames could suggest congestion on the network or that devices are frequently pausing traffic to prevent packet loss.​​​​

    ​​​​​​out-8021q-frames​​​​

    ​​​​​​Refers to the number of outbound ​​​​​​802.1Q frames​​​​ transmitted by a network interface. Monitoring “out-8021q-frames” is useful for:​​​​​​​​​​- ​​​​​​​​​​​​VLAN traffic analysis​​​​: Understanding how traffic is being segregated and routed across VLANs.​​​​

    • ​​​​​​​​​​​​Troubleshooting VLAN misconfigurations​​​​: Ensuring that the correct VLAN tags are being added and that traffic is being sent to the right VLANs.​​​​

    ​​​​​​​​​​​​​​​​Performance optimisation​​​​: Ensuring that VLAN tagging does not introduce unnecessary overhead or cause issues with traffic segregation.​​​​

Based on the optical interfaces, F5OS automatically sets the Forward Error Correction (FEC) mode. You can configure the Forward Error Correction (FEC) state from the CLI. By default, FEC is set to auto.

Note: The 10GB optical interfaces do not support FEC. By default, for a 10GB interface, the configuration is set to auto and the state is displayed as not supported.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Configure forward error correction state:

    interfaces interface <*interface*> config forward-error-correction
Possible completions:
auto  disabled  enabled

    A summary of this example displays:

    default-1(config)# interfaces interface 3/1.0 config forward-error-correction       
Possible completions:
  auto  disabled  enabled
default-1(config)# interfaces interface 3/1.0 config forward-error-correction enabled

  4. Commit the configuration changes.

    commit

You can view the state of the Forward Error Correction for the interfaces that are configured on the system.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Display the current state Forward Error Correction for the interfaces.

    show interfaces interface state forward-error-correction

    A summary to this example displays:

    default-1#show interfaces interface state forward-error-correction
       FORWARD ERROR 
NAME   CORRECTION    
----------------------
7/1.1  enabled 
7/1.2  not_supported 
7/1.3  not_supported 
7/1.4  not_supported 
7/2.1  disabled 
7/2.2  not_supported 
7/2.3  not_supported 
7/2.4  not_supported

A link aggregation group (LAG) is a logical group of interfaces that function as a single interface. The LAG (like a trunk on tenant systems) distributes traffic across multiple links, which increases the bandwidth by adding the bandwidth of multiple links together. For example, four fast Ethernet (100 Mbps) links, if aggregated, create a single 400 Mbps link. LAGs also enhance connection reliability by providing link failover if a member link becomes unavailable.

There are two types of LAGs:

Static Ports in the LAG are manually configured, and the group of ports assigned to a static LAG is always made up of active members. This is the default type of LAG.

Link Aggregation Control Protocol (LACP) When LACP is enabled on a LAG, the ports configure automatically into groups without manual configuration. The LACP protocol detects error conditions on member links and redistributes traffic to other member links, thus preventing any loss of traffic on a failed link.

You can create a link aggregation group (LAG) from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > LAGs.

    The screen shows LAGs that are configured.

    1. Click Add. The Add LAG screen displays.

    2. For Name, enter a name for the LAG interface (up to 63 characters). The first character in the name cannot be a number.

    3. For Description, enter a description for the LAG.

    4. For LAG Type, select one of these options:

      Option Description
      STATIC Manually configure the links. The link state of LAG members is not dynamically updated. This is the default value for LAGs.
      LACP Automatically bundle links.

    5. If you select LACP, configure these additional settings:

      Option

      Description

      LACP Interval

      Specify an interval at which interfaces send LACP packets. Select FAST (transmit packets every second) or SLOW (transmit packets every 30 seconds).

      LACP Mode

      Specify the negotiation state for LACP. Select ACTIVE (in an active negotiating state) or PASSIVE (do not initiate negotiation until peer contacts first).

  3. For Distribution Hash, select the supported load balancing hash values.

    Option Description
    DST-MAC Distribute on the destination MAC address.
    SRC-DST-IPPORT Distribute on the source destination IP address and the TCP or UDP port.
    SRC-DST_MAC Distribute on the source destination MAC address.

  4. For Configured Members, select one or more interfaces (not members of another LAG) to assign to the LAG.

    Note: Only interfaces that are configured with the same speeds can be members of the LAG. The interfaces cannot be associated with VLANs.

    You can add up to 32 members to a LAG.

  5. For Native VLAN (Untagged), select the VLAN ID to use for untagged frames received on a trunk interface.

  6. For Trunk VLANs (Tagged), select one or more VLAN IDs, if available and not a member of another LAG.

    Note: A Trunk VLAN or a Native VLAN is required to pass traffic. If you do not select either a Native VLAN or a Trunk VLAN, the port will not carry any traffic.

  7. Click Save.

You can edit the properties of an existing link aggregation group (LAG) from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > LAGs.

    The screen shows LAGs that are configured.

  3. Click a LAG name.

  4. For Description, enter a description for the LAG.

  5. For LAG Type, select one of these options:

    Option Description
    STATIC Manually configure the links. The link state of LAG members is not dynamically updated. This is the default value for LAGs.
    LACP Automatically bundle links.

  6. If you select LACP, configure these additional settings:

    Option

    Description

    LACP Interval

    Specify an interval at which interfaces send LACP packets. Select FAST (transmit packets every second) or SLOW (transmit packets every 30 seconds).

    LACP Mode

    Specify the negotiation state for LACP. Select ACTIVE (in an active negotiating state) or PASSIVE (do not initiate negotiation until peer contacts first).

  7. For Configured Members, select one or more interfaces (not members of another LAG) to assign to the LAG.

    Note: Only interfaces that are configured with the same speeds can be members of the LAG. The interfaces cannot be associated with VLANs.

    You can add up to 32 members to a LAG.

  8. For Native VLAN (Untagged), select the VLAN ID to use for untagged frames received on a trunk interface.

  9. For Trunk VLANs (Tagged), select one or more VLAN IDs, if available, and not a member of another LAG.

    Note:

    • A Trunk VLAN or a Native VLAN is required to pass traffic. If you do not select either a Native VLAN or a Trunk VLAN, the port will not carry any traffic.

    • After configuring, click Save & Stay to proceed with subinterface configuration.

    • Subinterface configuration is not supported on interfaces that are part of a LAG. As a result, the subinterfaces card will not be available for these interfaces. To configure the subinterfaces, expand the section Subinterfaces: Click Add. To add new sub interface, configure the following fields:

  10. To configure the subinterfaces, expand the section Subinterfaces:

    1. Click Add. To add new sub interface, configure the following fields:

      Field Description Valid values
      Index Numeric identifier that uniquely distinguishes the subinterface from all others on the parent interface. —
      Description Free-text description for the subinterface. —
      VLAN ID (ingress) VLAN identifier for ingress traffic. Values outside the valid range produce an inline error. 1–4094
      VLAN stack action (ingress) Operation to perform on the VLAN stack for ingress packets. POP, PUSH
      VLAN ID (egress) VLAN identifier for egress traffic. Values outside the valid range produce an inline error. 1–4094
      VLAN stack action (egress) Operation to perform on the VLAN stack for egress packets. POP, PUSH
      Inner VLAN IDs List of VLAN identifiers used to match traffic. Enter a value and press Enter to add it to the list. Duplicates are discarded. 1–4094

    2. Click Save.

  11. Click Save, to save the confiugration.

To configure a static LAG, you first configure the status LAG interface, then add interfaces to LAG members, and then associate VLANs with the LAG interfaces.

You can configure a LAG interface type as static from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Create a LAG interface.

    interfaces interface <*lag-name*> config type ieee8023adLag

    This example creates a LAG named lag-test:

    default-1# interfaces interface lag-test config type ieee8023adLag

    The system prompt updates to show that you are in configuration mode for the interface:

    default-1(config-interface-lag-test)#

  5. Set the type of LAG interface to STATIC (this is the default setting).

    aggregation config lag-type STATIC

    This example shows the interface named lag-test in configuration mode and configures it as a static LAG:

    default-1(config-interface-lag-test)# aggregation config lag-type STATIC

  6. Commit the configuration changes.

    commit

You can add interfaces, or member ports, to a LAG interface from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Add interfaces to a LAG.

    interfaces interface <*interface*> ethernet config aggregate-id <*lag-name*>

    This example adds two interfaces to a LAG named lag-test:

    default-1(config)# interfaces interface <1/1.0> ethernet config aggregate-id lag-test
default-1(config)# interfaces interface <1/2.0> ethernet config aggregate-id lag-test

  5. Commit the configuration changes.

    commit

Before you can pass user traffic, you need to associate VLANs with LAG interfaces from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Associate VLANs with the LAG interface.

    interfaces interface <*lag-name*> aggregation switched-vlan config trunk-vlans { <*vlan-IDs*> }

    This example associates VLANs 1037 and 1038 with a LAG named lag-test:

    default-1(config)# interfaces interface lag-test aggregation switched-vlan 
  config trunk-vlans [ 1037 1038 ]

  5. Commit the configuration changes.

    commit

You can create a LAG interface from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Create a LAG interface.

    interfaces interface <*lag-name*> config type ieee8023adLag

    This example creates a LAG named lag-test:

    default-1(config)# interfaces interface lag-test config type ieee8023adLag

  5. Commit the configuration changes.

    commit

Before LACP can manage a LAG interface, you need to create a LAG interface of type LACP from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Create a LAG interface of type LACP.

    interfaces interface <*lag-name*> aggregation config lag-type LACP

    This example creates a LAG of type LACP named lag-test:

    default-1(config)# interfaces interface lag-test aggregation config lag-type LACP

  5. Commit the configuration changes.

    commit

  6. Return to user (operational) mode.

    end

  7. Verify that LACP is enabled on the interface.

    show interfaces interface lag-test

    A summary similar to this example displays:

    default-1# show interfaces interface lag-test
interfaces interface lag-test
 state type               ieee8023adLag
 state mtu                9600
 state oper-status        UP
 state forward-error-correction auto
 aggregation state lag-type LACP
 aggregation state lag-speed 100
 aggregation state distribution-hash src-dst-ipport
 aggregation state mac-address 00:94:a1:8e:70:0a
 aggregation state lagid 4

By default, a LAG interface is in a static mode, which means that the member links do not initiate or process any of the LACP packets received. You can enable LACP on the LAG interface from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Enable LACP on a LAG interface.

    lacp interfaces interface <*lag-name*> aggregation config lag-type LACP

    This example enables LACP on a LAG interface named lag-test:

    default-1(config)# lacp interfaces interface lag-test aggregation config lag-type LACP

  5. Commit the configuration changes.

    commit

  6. Return to user (operational) mode.

    end

  7. Verify that LACP is enabled on a specified LAG interface.

    A summary similar to this example displays:

    default-1# show interfaces interface lag-test
interfaces interface lag-test
 state type               ieee8023adLag
 state mtu                9600
 state oper-status        DOWN
 state forward-error-correction auto
 aggregation state lag-type LACP
 aggregation state lag-speed 0
 aggregation state distribution-hash src-dst-ipport
 aggregation state mac-address 00:94:a1:8e:70:0a
 aggregation state lagid 4

You can check the LACP state from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Display the LACP state.

    show lacp

    A summary similar to this example displays:

    default-1# show lacp
lacp state system-id-mac 00:94:a1:8c:f4:08
lacp interfaces interface lag-test
 state name    lag-test
 state interval FAST
 state lacp-mode ACTIVE
 state system-id-mac 0:94:a1:8c:f4:8
                                                                                                                                                            PARTNER  LACP  LACP  LACP    LACP    LACP
                                                                                                                   OPER                     PARTNER  PORT   PORT     IN    OUT   RX      TX      UNKNOWN  LACP
INTERFACE  INTERFACE  ACTIVITY  TIMEOUT  SYNCHRONIZATION  AGGREGATABLE  COLLECTING  DISTRIBUTING  SYSTEM ID        KEY   PARTNER ID         KEY      NUM    NUM      PKTS  PKTS  ERRORS  ERRORS  ERRORS   ERRORS
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1/1.0      -          ACTIVE    SHORT    IN_SYNC          true          true        true          0:94:a1:8c:f4:8  2     44:4c:a8:fc:cb:9d  1        4224   69       588   21    0       0       0        0
2/1.0      -          ACTIVE    SHORT    IN_SYNC          true          true        true          0:94:a1:8c:f4:8  2     44:4c:a8:fc:cb:9d  1        8320   81       566   21    0       0       0        0
3/1.0      -          ACTIVE    SHORT    IN_SYNC          true          true        true          0:94:a1:8c:f4:8  2     44:4c:a8:fc:cb:9d  1        12416  29       560   21    0       0       0        0

You can view the state of LACP interfaces from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Display the state of LACP interfaces.

    show interfaces interface state lacp_state

    A summary similar to this example displays:

    default-1# show interfaces interface state lacp_state
       LACP
NAME   STATE
------------------
1/1.0  LACP_DOWN
1/2.0  LACP_UP

    These are the available LACP states:

    Option Description
    LACP_DEFAULTED Initial lacp_state value.
    LACP_UP LACPD has determined that this interface is a working member of a LACP LAG.
    LACP_DOWN LACPD has determined that this interface is not a working member of a LACP LAG, and it should not receive or transmit user traffic.

LACP errors are collected into the standard /var/F5/partition1/log/velos.log file. LACP errors run at the log level INFORMATIONAL by default. If you want to change the severity level for logged information, you can enable a different log level from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Configure the logging level for LACP.

    system logging sw-components sw-component lacpd config severity { ALERT | CRITICAL | DEBUG | EMERGENCY | ERROR | INFORMATIONAL | NOTICE | WARNING }

    This example enables DEBUG level logging for LACP:

    `default-1(config)# system logging sw-components sw-component lacpd config 
  severity DEBUG`

  5. Commit the configuration changes.

    commit

Configured members are interfaces in an LACP LAG that listen for and/or send LACPDUs that are attempting to establish that the peer is configured. You can check each physical interface’s aggregated ID from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Show the configuration members.

    show running-config interfaces interface ethernet config aggregate-id <*lag-name*>

    This example shows information about three members for a LAG named lag-test:

    default-1# show running-config interfaces interface ethernet config aggregate-id lag-test
interfaces interface 1/1.0
 config type ethernetCsmacd
 config enabled
 ethernet config aggregate-id lag-test
!
interfaces interface 1/2.0
 config type ethernetCsmacd
 config enabled
 ethernet config aggregate-id lag-test
!

Working members are a subset of configuration members. These members are added and removed dynamically by LACPD.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Show the working members.

    show lacp

    A summary similar to this example displays:

    default-1# show lacp
lacp state system-id-mac 00:94:a1:8d:18:08
lacp interfaces interface lag-test
 state name    lag-test
 state interval FAST
 state lacp-mode ACTIVE
 state system-id-mac 00:94:a1:8d:18:08
                                                                                                                                                             PARTNER  LACP  LACP  LACP    LACP    LACP
                                                                                                                     OPER                     PARTNER  PORT  PORT     IN    OUT   RX      TX      UNKNOWN  LACP
INTERFACE  INTERFACE  ACTIVITY  TIMEOUT  SYNCHRONIZATION  AGGREGATABLE  COLLECTING  DISTRIBUTING  SYSTEM ID          KEY   PARTNER ID         KEY      NUM   NUM      PKTS  PKTS  ERRORS  ERRORS  ERRORS   ERRORS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1/2.0      1/2.0      ACTIVE    SHORT    IN_SYNC          true          true        true          00:94:a1:8d:18:08  13    00:be:75:ae:1b:31  100      4352  289      848   847   0       -       -        -
2/1.0      2/1.0      ACTIVE    SHORT    IN_SYNC          true          true        true          00:94:a1:8d:18:08  13    00:be:75:ae:1b:31  100      8320  293      8     7     0       -       -        -

A VLAN is a logical subset of hosts on a local area network (LAN) that operates in the same IP address space. Grouping hosts together in a VLAN has distinct advantages. For example, with VLANs, you can:

  • Reduce the size of broadcast domains, thereby enhancing overall network performance.
  • Reduce system and network maintenance tasks substantially. Functionally related hosts do not need to physically reside together to achieve optimal network performance.
  • Enhance security on your network by segmenting hosts that must transmit sensitive data.

For the most basic VELOS system configurations, you might create multiple VLANs. That is, you create a VLAN for each of the internal and external networks, as well as a VLAN for high availability communications. You then associate each VLAN with the relevant interfaces or LAGs.

You can create a VLAN and then later associate physical interfaces or LAGs with that VLAN from the chassis partition webUI. In this way, any host that sends traffic to an interface is logically a member of the VLAN or VLANs to which that interface or LAG belongs.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > VLANs.

    The screen shows VLANs that are configured for that chassis partition.

  3. Click Add. The Add LAG screen displays.

  4. In the VLAN ID, enter a number between 1-4094 for the VLAN.

    The VLAN ID identifies the traffic from hosts in the associated VLAN for an associated interface or LAG.

  5. In the Name field, enter a name for the VLAN.

    Note: VLAN names must follow these rules:

    • Start with an alphabetic character (Aa-Zz).
    • Can be up to 56 characters in length.
    • After the first character, can contain alphanumeric characters, periods (.), hyphens (-) and underscores (_).
    • VLAN names must be unique.

  6. Click Save & Close to create the VLAN.

The VLAN is created and displayed in the VLAN list. You can use the VLANs when configuring interfaces, creating LAGs, and deploying tenants (one VLAN can be shared by more than one tenant within a chassis partition).

You can create a VLAN and then later associate physical interfaces or LAGs with that VLAN from the chassis partition CLI. In this way, any host that sends traffic to an interface is logically a member of the VLAN or VLANs to which that interface or LAG belongs.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Create a VLAN.

    vlans vlan { <*vlan-id*> | range <*range-of-vlan-ids*> }

    This example creates a VLAN with the range 100-101:

    default-1(config)# vlans vlan range 100-101

The VLAN is created and displayed in the VLAN list. You can use the VLANs when configuring interfaces, creating LAGs, and deploying tenants (one VLAN can be shared by more than one tenant within a chassis partition).

When you configure VELOS systems for network virtualization, the system represents the connection as a tunnel, which provides a Layer 2 interface on the virtual network. You can use the tunnel interface in both layer 2 and layer 3 configurations. After you create the network virtualization tunnels, you can use the tunnels like you use VLANs.

VELOS systems support these tunneling protocols:

  • GENEVE
  • GTP
  • GRE
  • IP in IP
  • EtherIP
  • NVGRE
  • VXLAN

By configuring IP tunneling protocols on VELOS systems, you provide tenants with custom configuration details needed to even out traffic load balancing across Traffic Management Microkernels (TMMs) inside the tenant.

You can configure these tunneling protocols on the VELOS system:

GENEVE (Generic Network Virtualization Encapsulation) Uses a compact tunnel header encapsulated in UDP over IP.

GTP (GPRS tunneling protocol) Uses a new disaggregation (DAG) mode for GTP-U traffic that assigns a unique tunnel endpoint identifier (TEID) to each GTP control connection to the peers. This enables a BIG-IP tenant to redistribute the GTP-U traffic among all TMMs.

NVGRE (Network Virtualization using Generic Routing Encapsulation) Uses Generic Routing Encapsulation (GRE) to tunnel layer 2 packets over layer 3 networks.

VXLAN (Virtual Extensible Local Area Network) Uses IP plus UDP to encapsulate layer 2 Ethernet frames within layer 4 UDP datagrams, using 4789 as the default UDP port number.

For information on configuring tunneling protocols on BIG-IP tenants, see BIG-IP TMOS: ​Tunneling and IPsec.

You can enable the GTP (GPRS Tunnelling Protocol) TEID (tunnel endpoint identifier) hash from the chassis partition webUI. This enables the system to use the TEID instead of the default L4 port mode for DAG hashing.

Important: This setting applies to all tenants running on the system.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > IP Tunnels.

  3. On the GTP-U tile, click the edit icon.

  4. Set GTP-U TEID Hash to Enabled to indicate that TEID is extracted and L4 Ports are overloaded with TEID values instead of L4 port values, or Disabled to indicate that there is no change to packet parsing.

    The default value is Disabled.

  5. Click Save.

All tenants running on the system now use GTP tunnels.

You can configure the default settings for GENEVE (Generic Network Virtualization Encapsulation) tunnels from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > IP Tunnels.

  3. On the GENEVE tile, click the edit icon.

  4. For Enabled, select True to enable GENEVE tunnels on the system or False to disable them.

  5. For Destination Port, edit the port number.

    The range is from 0 to 65535. The default value is 6081.

  6. Click Save.

You can configure the default settings for NVGRE (Network Virtualization using Generic Routing Encapsulation) tunnels from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > IP Tunnels.

  3. In the NVGRE tile, click the edit icon.

  4. For EtherType, edit the EtherType for NVGRE tunnel traffic.

    Allowed values are a hexadecimal value, with a leading “0x” followed by 4 digits. The default value is 0x6558 (Transparent Ethernet Bridging).

  5. Click Save.

You can configure the default settings for VXLAN (Virtual Extensible LAN) tunnels from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > IP Tunnels.

  3. On the VXLAN tile, click the edit icon.

  4. For Destination Port, edit the port number.

    The range is from 0 to 65535. The default value is 4789.

  5. For GPE Enabled, select True to enable support for the VXLAN GPE tunnel type on the system or False to disable it.

  6. For GPE Destination Port, edit the port number.

    The default value is 4790.

  7. For NSH Enabled, select True to enable the VXLAN GPE NSH tunnel type on the system or False to disable it.

  8. Click Save.

You can disable IP tunnels from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > IP Tunnels.

  3. Under Type, clear the check box next to the tunnel type.

  4. Click Save.

You can reset IP tunnels to their default values from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > IP Tunnels.

  3. Click the Reset button on the respective protocol that you need to reset.

You can enable or disable GTP tunnels from the chassis partition CLI. This enables the use of TEID (tunnel endpoint identifier) instead of the default L4 port mode for DAG hashing.

Important: This setting applies to all tenants running on the system.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Configure a GPE tunnel.

    Set to enabled to indicate that TEID is extracted and L4 ports are overloaded with TEID values instead of L4 port values, or disabled to indicate that there is no change to packet parsing. The default value is disabled.

    system settings dag config gtp-u teid-hash { enabled | disabled }

  5. Commit the configuration changes.

    commit

  6. Return to user (operational) mode.

    end

  7. Verify the DAG hashing configuration.

    default-1# show system settings dag system settings dag state gtp-u teid-hash enabled

You can configure GENEVE (Generic Network Virtualization Encapsulation) tunnels from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Create a GENEVE tunnel.

    iptunnels iptunnel geneve config { disabled | enabled } dport <*port*>

    Allowed values for dport (destination port) are in the range of 0 to 65535. The default value is 6081.

    In this example, you create a tunnel that is enabled with the destination port of 6081:

    default-1(config)# iptunnels iptunnel geneve config enabled dport 6081

  4. Commit the configuration changes.

    commit

You can configure NVGRE (Network Virtualization using Generic Routing Encapsulation) tunnels from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Create an NVGRE tunnel.

    iptunnels iptunnel nvgre config ethertype <*hex-value*>

    Allowed values for ethertype are a hexadecimal value, with a leading “0x” followed by 4 digits.

    In this example, you create an NVGRE tunnel:

    default-1(config)# iptunnels iptunnel nvgre config ethertype 0x1234

  4. Commit the configuration changes.

    commit

You can configure VXLAN (Virtual Extensible LAN) tunnels from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Create a VXLAN tunnel.

    iptunnels iptunnel vxlan dport <*port*> gpe { disabled | enabled } dport <*port*> nsh { disabled | enabled }

    Allowed values for dport (destination port) are in the range of 0 to 65535. The default value for the VXLAN destination port is 4789, and the default value for the GPE destination port is 4790.

    In this example, you create a tunnel with GPE enabled and NSH disabled:

    default-1(config)# iptunnels iptunnel vxlan dport 4789 gpe enabled dport 4790 nsh disabled

  4. Commit the configuration changes.

    commit

The VELOS system supports Link Layer Discovery Protocol (LLDP), which is a Layer 2 industry-standard protocol (IEEE 802.1AB) that enables a network device to advertise its identity and capabilities to multi-vendor neighbor devices on a network. The protocol also enables a network device to receive information from neighbor devices. LLDP transmits device information in LLDP frames using the TLV (Type-Length-Value) format.

In general, this protocol:

  • Advertises connectivity and management information about the local VELOS device to neighbor devices on the same IEEE 802 LAN.
  • Receives network management information from neighbor devices on the same IEEE 802 LAN.
  • Operates with all IEEE 802 access protocols and network media.

Before you can configure LLDP, make sure that the interfaces you will use are up and running with VLANs configured.

You can configure LLDP from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > LLDP.

  3. On the Configuration tile, click edit icon.

    1. Set Enable LLDP to Enabled.

    2. Type a System Name and optionally, a System Description.

    3. For TX Interval, enter a number (5-65535) for the interval (in seconds) at which LLDP packets are sent to neighbors.

      The default value is 30 seconds.

    4. For TX Hold, enter a number (0-65535) to specify the hold time for LLDP transmissions.

      The default value is 4 seconds.

    5. For Reinitiate Delay, type a number (0-65535) to specify the minimum time interval an LLDP interface waits before re-initializing an LLDP transmission.

      The default value is 2 seconds.

    6. For TX Delay, enter a number (0-65535) to specify the minimum time delay, in seconds, between successive LLDP frame transmissions.

      The default value is 2 seconds.

    7. For Max Neighbors Per Port, enter a number to specify the maximum number of LLDP neighbors for which LLDP data is retained.

      The default value is 10.

    8. Click Save.

  4. On the Interfaces tile, click Configure.

    1. In the Interfaces table, select the interface and LAG (if any) for which you want to enable LLDP. Interfaces must be configured one at a time. For each one selected:

    2. Select Enabled.

    3. For the TLV Advertisement State, select TX (transmit only), RX (receive only), or TXRX (transmit and receive).

      The default value is txrx.

    4. From the TLV Map, select the TLV device information that you want to transmit and/or receive, such as chassis ID (if using link aggregation), MAC Phy configuration, management address, MFS (maximum frame size), port description, port ID, and power MDI.

    5. Click Save.

LLDP is configured on the system for the specified interfaces and LAGs.

You can remove LLDP interfaces from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > LLDP.

  3. In the Interfaces table, select the interfaces you want to remove.

    For each interface selected:

    1. Click Remove.

  4. Click Save.

The LLDP interfaces are removed.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Status & Details > LLDP Details.

    The screen shows LLDP state information for interfaces in this chassis partition (similar to info shown at the CLI using show lldp).

  3. In the Neighbors table, examine the identification, configuration, and capabilities of neighboring devices.

    This information provides details useful for troubleshooting many configuration problems.

  4. On the top right, set the Auto Refresh interval for refreshing the data displayed or click the refresh icon to update the data immediately.

Before you can configure LLDP on a chassis partition, make sure that the interfaces you will use are up and running with VLANs configured.

You can configure LLDP from the chassis partition CLI.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Configure LLDP.

    lldp config { disabled | enabled } max-neighbors-per-port <*neighbors*> reinit-delay <*time*> system-description <*description*> system-name <*name*> tx-delay <*time*> tx-hold <*time*> tx-interval <*interval*>

    These are the available options:

    Option Description
    disabled Disable LLDP on the system.
    enabled Enable LLDP on the system.
    max-neighbors-per-port Specify a maximum number of LLDP neighbors per port. The default value is 10.
    reinit-delay Specify a minimum delay time to re-initialize LLDP data unit (LLDPDU). The default value is 2.
    system-description Specify a description for LLDP. The minimum length is 0 characters, and the maximum length is 255 characters.
    system-name Specify a name for LLDP. The minimum length is 0 characters, and the maximum length is 255 characters.
    tx-delay Specify a delay time to transmit LLDPDU. The default value is 2.
    tx-hold Specify a hold time to transmit LLDPDU. The default value is 4.
    tx-interval Specify an interval to transmit LLDPDU. The range is from 5 to 32768. The default value is 30.

    This example enables LLDP on the chassis partition:

    default-1(config)# lldp config enabled

  4. Commit the configuration changes.

    commit

You can configure LLDP on an interface from the chassis partition CLI.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Configure LLDP on an interface.

    lldp interfaces interface <*blade*>/<*interface*> config { disabled | enabled } name <*name*> tlv-advertisement-state { none | rxonly | txonly | txrx } tlvmap <*device-info*> tx-interval <*interval*>

    These are the available options:

    Option

    Description

    disabled

    Disable LLDP on the interface.

    enabled

    Enable LLDP on the interface.

    name

    Specify a name for the LLDP interface. The minimum length is 1 character, and the maximum length is 63 characters.

    tlv-advertisement-state

    Specify the LLDP PDU direction for LLDP Type-Length-Value (TLV) advertisement. Options include tx (transmit only), rx (receive only), or txrx (transmit and receive). The default value is txrx.

    tlvmap

    Specify the TLV device information that you want to transmit and/or receive, such as chassis ID (if using link aggregation), MAC Phy configuration, management address, MFS (maximum frame size), port description, port ID, and power MDI.

    This example configures a tlv-advertisement-state for LLDP interface 1.0 on blade-1:

    default-1(config)# lldp interfaces interface 1/1.0 config tlv-advertisement-state txrx

  4. Commit the configuration changes.

    commit

  5. Return to user (operational) mode.

    end

  6. Verify the LLDP interface configuration.

    show running-config lldp interfaces <*blade*>/<*interface*>

    A summary similar to this example displays:

    default-1# show running-config lldp interfaces interface 1/1.0
lldp interfaces interface 1/1.0
 config name             1/1.0
 config enabled
 config tlv-advertisement-state txrx
 config tlvmap           chassis-id,port-id,ttl,port-description,system-name,system-description,system-capabilities,pvid,ppvid,vlan-name,protocol-identity,macphy,link-aggregation,power-mdi,mfs,product-model
!

To minimize the chance that higher priority traffic is dropped when traffic congestion occurs, you can configure the system to prioritize higher priority traffic over other types of traffic. The Quality of Service (QoS) feature enables you to configure the weight of packet types, according to the 802.1p or DSCP standards, to guarantee that a percentage of a given type of traffic is transmitted and not dropped when there is a high volume of traffic.

For more information, see VELOS Systems: Prioritizing Traffic using QoS at the F5OS Knowledge Center.

The VELOS system supports a set of industry-standard, Layer 2 protocols known as spanning tree protocols. A spanning tree is a logical tree-like depiction of the bridges on a network and the paths that connect them. Spanning tree protocols block redundant paths on a network, preventing bridging loops. If a blocked, redundant path is needed later because another path has failed, the spanning tree protocols clear the path again for traffic.

The spanning tree protocols that the VELOS system supports are:

  • Spanning Tree Protocol (STP) - 802.1d
  • Rapid Spanning Tree Protocol (RSTP) - 802.1w
  • Multiple Spanning Tree Protocol (MSTP) - 802.1s

You can configure spanning tree protocols on a chassis partition from the webUI, CLI, or REST API. Only one spanning tree protocol can be configured on a chassis partitionat a time.

Central to the way that spanning tree protocols work is the use of bridge protocol data units (BPDUs). When you enable spanning tree protocols on Layer 2 devices on a network, the devices send BPDUs to each other, for the purpose of learning the redundant paths and updating their L2 forwarding tables accordingly, electing a root bridge, building a spanning tree, and notifying each other about changes in interface status.

Note: The term bridge refers to a Layer 2 device such as a switch, bridge, or hub.

When you configure spanning tree on the VELOS system, you must first decide which protocol, or mode, you want to enable. Because MSTP recognizes VLANs, using MSTP is preferable. All bridges in a network environment that you want to use spanning tree must run the same spanning tree protocol. If a legacy bridge running RSTP or STP is added to the network, the VELOS system must switch and also use that same protocol.

Note: You cannot enable STP on individual LAG members. Live upgrades will not work if STP is not configured correctly; resolve any configuration issues before upgrading.

Note: You cannot enable STP on interfaces that are configured as virtual networks. For more information on configuring virtual wire and virtual networks, see Virtual wire overview.

You can configure Spanning Tree Protocol (STP), Rapid Spanning Tree Protocol (RSTP), and Multiple Spanning Tree Protocol (MSTP) from the webUI by selecting the desired protocol from the STP Configuration page under Network Settings. You can also disable STP functionality by selecting Disabled.

You can configure Spanning Tree Protocol (STP) from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > STP.

  3. For STP Mode, select STP (single instance, best on networks with legacy systems).

    A message warns you that changing modes deletes any existing STP configuration settings. When you click OK, the selected mode is enabled, and additional options for that mode display (with default values set).

    On the right, click edit icon:

    1. For Hello Time, specify the time interval, in seconds, that the system transmits spanning tree information (through BPDUs) to adjacent bridges in the network.

      The default value is 2.

    2. For Max Age, specify the length of time, in seconds, that spanning tree information received from other bridges is considered valid.

      The default value is 20, and the valid range is from 6 to 40.

    3. For Forwarding Delay, specify the amount of time, in seconds, that the system blocks an interface from forwarding network traffic when the spanning tree algorithm reconfigures a spanning tree.

      The default value is 15, and the valid range is from 4 to 30. This has no effect when running in RSTP or MSTP unless using an added legacy STP bridge.

    4. For Hold Count, specify the maximum number of spanning tree frames (BPDUs) that the system can transmit on a port within the Hello Time interval.

      This ensures that spanning tree frames do not overload the network. The default value is 6, and the valid range is from 1 to 10.

    5. For Bridge Priority, specify the bridge in the spanning tree with the lowest relative priority becomes the root bridge, which is responsible for managing loop resolution on the network.

      Configure this setting so that the system never becomes the root bridge. The default value is 32768. The valid range is from 0 to 61440 in multiples of 4096.

    6. Click Save.

      The system displays a confirmation dialog confirming whether to change the STP mode.

  4. In the Interfaces, click Configure, to configure the STP for the interfaces and LAGs.

    1. For Interfaces, select (one at a time) the interfaces and LAGs, if any, for which you want to configure STP and specify these fields:

      Option

      Description

      Cost

      Used to calculate the cost of sending spanning tree traffic through the interface to an adjacent bridge or spanning tree region. Based on the speed of the interface. The default value is 0, and the valid range is from 0 (lowest) to 200,000,000 (highest).

      Port Priority

      Used as the port identifier together with the slot/port numbers. The default value is 128 (when an interface is selected), and the valid range is from 0 (highest) to 240 (lowest) in multiples of 16.

      Edge Port

      Needed only for RSTP or MSTP. When enabled, indicates the interface or LAG is an edge port that does not receive any BPDU frames. Set to EDGE-AUTO, EDGE-ENABLE, or EDGE-DISABLE. If you enable EDGE-ENABLE, and the interface later receives BPDUs, the system disables the setting automatically, because only non-edge interfaces can receive BPDUs.

      Link Type

      Specifies the type of optimization:- P2P: Optimizes for point-to-point spanning tree links (connects two spanning tree bridges only). Note that P2P is the only valid STP link type for a LAG.

      • Shared: Optimizes for shared spanning tree links (connecting two or more spanning tree bridges).

    Note: For more information on the available interfaces and LAGs, see the Network Settings > Interfaces or LAGs screens.

    1. Click Save.

STP is now set up for use on the system.

You can configure Rapid Spanning Tree Protocol (RSTP) from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > STP.

  3. For STP Mode, select RSTP (single instance, fast convergence).

    A message warns you that changing modes deletes any existing STP configuration settings. When you click OK, the selected mode is enabled, and additional options for that mode display (with default values set).

    On the right, click edit icon:

    1. For Hello Time, specify the time interval, in seconds, that the VELOS system transmits spanning tree information (through BPDUs) to adjacent bridges in the network.

      The default value is 2. For RSTP, maintain this relationship between the Maximum Age and Hello Time options:

      Max Age >= 2 * (Hello Time + 1)

    2. For Max Age, specify the length of time, in seconds, that spanning tree information received from other bridges is considered valid.

      The default value is 20, and the valid range is from 6 to 40. For RSTP, maintain these relationships between the Maximum Age and the Hello Time and Forward Delay options:

      Max Age >= 2 * (Hello Time + 1)

      Max Age <= 2 * (Forward Delay - 1)

    3. For Forwarding Delay, specify the amount of time, in seconds, that the system blocks an interface from forwarding network traffic when the spanning tree algorithm reconfigures a spanning tree.

      The default value is 15, and the valid range is from 4 to 30. This has no effect when running in RSTP or MSTP unless using an added legacy STP bridge. For RSTP, maintain these relationships between the Maximum Age and Forward Delay options:

      Max Age <= 2 * (Forward Delay - 1)

    4. For Hold Count, specify the maximum number of spanning tree frames (BPDUs) that the system can transmit on a port within the Hello Time interval.

      This ensures that spanning tree frames do not overload the network. The default value is 6, and the valid range is from 1 to 10.

    5. For Bridge Priority, specify the bridge in the spanning tree with the lowest relative priority becomes the root bridge, which is responsible for managing loop resolution on the network.

      Configure this setting so that the system never becomes the root bridge. The default value is 32768. The valid range is from 0 to 61440 in multiples of 4096.

    6. Click Save.

  4. In the Interfaces, click Configure, to configure the STP for the interfaces and LAGs.

    1. For Interfaces, select (one at a time) the interfaces and LAGs, if any, for which you want to configure STP and specify these fields:

      Option

      Description

      Cost

      Used to calculate the cost of sending spanning tree traffic through the interface to an adjacent bridge or spanning tree region. Based on the speed of the interface. The default value is 0, and the valid range is from 0 (lowest) to 200,000,000 (highest).

      Port Priority

      Used as the port identifier together with the slot/port numbers. The default value is 128 (when an interface is selected), and the valid range is from 0 (highest) to 240 (lowest) in multiples of 16.

      Edge Port

      Needed only for RSTP or MSTP. When enabled, indicates the interface or LAG is an edge port that does not receive any BPDU frames. Set to EDGE-AUTO, EDGE-ENABLE, or EDGE-DISABLE. If you enable EDGE-ENABLE, and the interface later receives BPDUs, the system disables the setting automatically, because only non-edge interfaces can receive BPDUs.

      Link Type

      Specifies the type of optimization:- P2P: Optimizes for point-to-point spanning tree links (connects two spanning tree bridges only). Note that P2P is the only valid STP link type for a LAG.

      • Shared: Optimizes for shared spanning tree links (connecting two or more spanning tree bridges).

    Note: For more information on the available interfaces and LAGs, see the Network Settings > Interfaces or LAGs screens.

    1. Click Save.

RSTP is now set up for use on the system.

If you want to use Multiple Spanning Tree Protocol (MSTP) to define a region, you can configure it from the chassis partition webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > STP.

  3. For STP Mode, select MSTP (multiple instances, fast convergence).

    A message warns you that changing modes deletes any existing STP configuration settings. When you click OK, the selected mode is enabled, and additional options for that mode display (with default values set).

    On the right, click edit icon:

    1. For Region Name, enter a name (string with 1 to 32 characters) that you assign to all bridges in a spanning tree region.

      A spanning tree region is a group of bridges with identical region names and MSTP revision numbers, as well as identical assignment of VLANs to spanning tree instances. The default value is the bridge MAC address. A region can have multiple members with the same MSTP configuration.

    2. For Revision, specify a global revision number that you assign to all bridges in a spanning tree region.

      The default value is 0, and the valid range is 0 to 65535. All bridges in the same region must have this same configuration revision number.

    3. For Max Hop, specify The maximum number of hops that a spanning tree frame (BPDU) can traverse before it is discarded.

      The default value is 20, and the valid range is from 1 to 255.

    4. For Hello Time, specify the time interval, in seconds, that the system transmits spanning tree information (through BPDUs) to adjacent bridges in the network.

      The default value is 2 and the valid range is from 1 to 10.

    5. For Max Age, specify the length of time, in seconds, that spanning tree information received from other bridges is considered valid.

      The default value is 20, and the valid range is from 6 to 40.

    6. For Forwarding Delay, specify the amount of time, in seconds, that the system blocks an interface from forwarding network traffic when the spanning tree algorithm reconfigures a spanning tree.

      The default value is 15, and the valid range is from 4 to 30. This has no effect when running in RSTP or MSTP unless using an added legacy STP bridge.

    7. For Hold Count, specify the maximum number of spanning tree frames (BPDUs) that the system can transmit on a port within the Hello Time interval.

      This ensures that spanning tree frames do not overload the network. The default value is 6, and the valid range is from 1 to 10.

  4. To configure multiple instances for a region, click Configure and adjust these settings for MSTP Instances:

    1. Under MSTP Instances, click Add.

    2. For Instance ID, enter a positive integer and click Add.

    3. Under Instances, select one of the instances.

      Available interfaces are listed below.

    4. Under VLANs, select the VLANs to map to this instance.

    5. For Bridge Priority, configure this setting so that the VELOS system never becomes the root bridge.

      The default value is 32768, and the valid range is from 0 to 61440 in multiples of 4096. Each MSTP instance can have its own bridge priority.

    6. For Interfaces, select the interfaces (one at a time) that traffic for this instance can use and specify these fields:

  5. Continue to configure any other instances that you might need.

MSTP is set up for use on the system.

If you want to change STP modes, you must first remove the existing STP configuration by deleting the existing mode and configuration from the chassis partition CLI.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Disable the current STP mode.

    no stp global config enabled-protocol STP

  4. Commit the configuration changes.

    commit

  5. Remove the existing interface configuration for STP mode.

    no stp stp interfaces interface

  6. Remove the edge port and link type configuration.

    no stp interfaces interface

  7. Commit the configuration changes.

    commit

  8. Enable another STP mode.

    stp global config enabled-protocol { MSTP | RAPID\_PVST | RSTP | STP }

    In this example, you enable RSTP:

    default-1(config)# stp global config enabled-protocol RSTP

  9. Commit the configuration changes.

    commit

STP is the original spanning tree protocol, but it is not recommended in VLAN-rich environments due to poor performance unless required by your configuration. STP can create only one spanning tree (instance 0) for the entire network, and therefore cannot take VLANs into account when managing redundant paths. You can configure STP from the chassis partition CLI.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Enable STP.

    stp global config enabled-protocol { MSTP | RAPID\_PVST | RSTP | STP ]

    In this example, you enable STP mode:

    default-1(config)# stp global config enabled-protocol STP

  4. Configure the bridge-priority so that it is not selected as the root bridge.

    stp stp config bridge-priority <*priority*>

    The priority is used together with the address as a bridge identifier. The range is from 0 (highest) to 61440 (lowest), in increments of 4096. The default value is 32768.

    In this example, you set the bridge priority to 32768:

    default-1(config)# stp stp config bridge-priority 32768

  5. Configure interface cost and port priority.

    stp { global | interfaces | mstp | rstp | stp } interfaces interface <*interface*> config cost <*cost*> port-priority <*priority*>

    Note: You must configure all interfaces that will be included in STP.

    The priority is used as the port identifier together with the slot/port numbers. The port priority range is from 0 (highest) to 240 (lowest) in increments of 16. The default value is 128. The port path cost range is from 0 (lowest) to 20,000,000,000 in increments of 1. The default port path cost is assigned dynamically (cost = 20,000,000,000 / port speed in kbits).

    In this example, you configure the RSTP to use slot 1/port 1.0, with an interface cost of 200 and a port priority of 128:

    default-1(config)# stp stp interfaces interface 1/1.0 config cost 200 
  port-priority 128

  6. Commit the configuration changes.

    commit

RSTP is an enhancement to STP that improves spanning tree performance. RSTP can create only one spanning tree (instance 0) for the entire network, and therefore cannot take VLANs into account when managing redundant paths. You can configure RSTP from the chassis partition CLI.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Enable RSTP.

    stp global config enabled-protocol { MSTP | RAPID\_PVST | RSTP | STP ]

    The bridge-priority, forwarding-delay, hello-time, hold-count, and max-age have default values, which are recommended for use.

    In this example, you enable RSTP mode:

    default-1(config)# stp global config enabled-protocol RSTP

  4. Configure the bridge-priority so that it is not selected as the root bridge.

    stp { global | interfaces | mstp | rstp | stp } config bridge-priority <*priority*>

    The priority is used together with the address as a bridge identifier. The range is from 0 (highest) to 61440 (lowest), in increments of 4096. The default value is 32768.

    default-1(config)# stp rstp config bridge-priority <*integer*>

  5. Configure interface cost and port priority.

    stp { global | interfaces | mstp | rstp | stp } interfaces interface <*interface*> config cost <*cost*> port-priority <*priority*>

    Note: You must configure all interfaces that will be included in STP.

    The priority is used as the port identifier together with the slot/port numbers. The port priority range is from 0 (highest) to 240 (lowest) in increments of 16. The default value is 128. The port path cost range is from 0 (lowest) to 20,000,000,000 in increments of 1. The default port path cost is assigned dynamically (cost = 20,000,000,000 / port speed in kbits).

    In this example, you configure the RSTP to use slot 1/port 1.0, with an interface cost of 200 and a port priority of 128:

    default-1(config)# stp rstp interfaces interface 1/1.0 config cost 200 
  port-priority 128

  6. Configure interface edge-port and link-type.

    stp interfaces interface <*interface*> config edge-port { EDGE\_AUTO | EDGE\_DISABLE | EDGE\_ENABLE } link-type { P2P | SHARED ]

    Note: You must configure all interfaces that will be included in STP.

    In this example, you configure slot 1/port 2.0 to set the interface as an EDGE_AUTO port that uses point-to-point spanning tree links:

    default-1(config)# stp interfaces interface 1/2.0 config 
  edge-port EDGE_AUTO link-type P2P

  7. Commit the configuration changes.

    commit

MSTP is an enhancement to RSTP and is the preferred spanning tree protocol (STP) for the VELOS system. MSTP is specifically designed to understand VLANs and VLAN tagging (specified in IEEE 802.1q). MSTP allows for multiple spanning tree instances. Each instance corresponds to a spanning tree and can control one or more VLANs that you specify when you create the instance. Thus, for any VELOS system interface that you assigned to multiple VLANs, MSTP can block a path on one VLAN, while still keeping a path in another VLAN open for traffic.

You can configure MSTP from the chassis partition CLI. The spanning tree algorithm automatically groups bridges into regions, based on the values you assign to the MSTP configuration name, revision number, instance numbers, and instance members.

  1. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  2. Change to config mode.

    config

    The CLI prompt changes to include (config).

  3. Enable MSTP.

    stp mstp config name <region-name> revision [0-65535]

    The name option is a string <= 32 characters, and the default value is the bridge MAC address. The revision option is a range from 0 to 65535, and the default value is 0. The forwarding-delay, hello-time, hold-count, max-age, and max-hop options have default values, which are recommended for use.

    Important: The name and revision options together form the common identifier of the BPDUs within the region. They must be identical on all bridges in the region.

  4. Create an MSTP instance.

    stp mstp mst-instances mst-instance <*integer*> config mst-id <*integer*>

    In this example, you create an instance named test with the default revision level (0):

    default-1(config)# stp mstp config name test revision 0

  5. Configure VLANs for the MSTP instance.

    vlans vlan <*vlan-id*>

    The VLANs must already exist.

    In this example, you create VLANs 300 and 301:

    default-1(config)# vlans vlan 300
default-1(config-vlan-300)# vlans vlan 301

    In this example, you assign VLANs 300 and 301 to MSTP instance 1:

    default-1(config)# stp mstp mst-instances mst-instance 1 
  config vlan [ 300 301 ]

  6. Exit to the top level of the configuration hierarchy.

    top

  7. Configure bridge priority for the MSTP instance.

    stp mstp mst-instances mst-instance <*instance*> config bridge-priority <*priority*>

    Each MSTP instance can have its own priority. The priority is used together with the address as a bridge identifier. The default value is 32768, and the range is from 0 (highest) to 61440 (lowest) in multiples of 4096.

    In this example, you configure MTSP instance 1 with a bridge priority of 32768:

    default-1(config)# stp mstp mst-instances mst-instance 1 config 
  bridge-priority 32768

  8. Exit to the top level of the configuration hierarchy.

    top

  9. Configure interface cost and port priority.

    stp mstp mst-instances mst-instance <*instance*> interface interface <*interface*> config cost <*cost*> port-priority <*priority*>

    Note: You must configure all interfaces that will be included in STP.

    The priority is used as the port identifier together with the slot/port numbers. The port priority range is from 0 (highest) to 240 (lowest) in increments of 16. The default value is 128. The port path cost range is from 0 (lowest) to 20,000,000,000 in increments of 1. The default port path cost is assigned dynamically (cost = 20,000,000,000 / port speed in kbits).

    In this example, you configure MSTP instance 1 to use slot 1/port 1.0, with an interface cost of 200 and a port priority of 128:

    default-1(config)# stp mstp mst-instances mst-instance 1 interfaces 
  interface 1/1.0 config cost 200 port-priority 128

  10. Exit to the top level of the configuration hierarchy.

    top

  11. Configure interface edge-port and link-type.

    stp interfaces interface <*blade*>/<*interface*> config edge-port { EDGE\_AUTO | EDGE\_DISABLE | EDGE\_ENABLE } link-type { P2P | SHARED }

    Note: You must configure all interfaces that will be included in STP.

    In this example, you configure blade 1/port 2.0 to set the interface as an EDGE_AUTO port that uses point-to-point spanning tree links:

    default-1(config)# stp interfaces interface 1/2.0 config 
  edge-port EDGE_AUTO link-type P2P

    These settings speed up convergence time by eliminating the learning state on ports that do not receive BPDUs. This configuration is cancelled automatically upon reception of a BPDU.

  12. Commit the configuration changes.

    commit

A virtual wire (also known as L2 inline service) logically connects either two interfaces/physical ports or two LAGs, to each other. This enables the system to forward traffic from one interface to another, in either direction. Packets received on a virtual-wire interface are forwarded to the other endpoint of the virtual wire.

Important: The endpoints of a virtual wire must be of the same type. For example, you cannot mix an interface and a LAG in a virtual wire.

A virtual network forms an internal virtual L2/L3 network in the system. Each virtual network has its own set of external network endpoints and can be configured using one of two modes: default and virtual-wire.

After you create a virtual wire, you can attach it to a tenant. A single tenant can use multiple virtual networks.

Note: You cannot enable spanning tree protocol (STP) on interfaces that are configured as virtual networks. For more information on configuring STP, see Spanning tree protocol (STP) overview.

You can configure virtual networks with a specified mode from the chassis partition CLI.

Note: Only STATIC LAGs (not LACP) support virtual networks.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Create a virtual network.

    Important: You cannot create a virtual wire using this virtual network if you specify default for the mode option.

    virtual-networks virtual-network <*name*> config mode { default | virtual-wire }

    This example creates a virtual network named vn1:

    default-1(config)# virtual-networks virtual-network vn1 config mode virtual-wire

  5. Exit to the top level of the configuration hierarchy.

    top

  6. Create a second virtual network if you plan to configure a virtual wire (a virtual wire must include exactly two virtual networks).

    Important: You cannot create a virtual wire using this virtual network if you specify default for the mode option.

    virtual-networks virtual-network <*name*> config mode { default | virtual-wire }

    This example creates a virtual network named vn2:

    default-1(config)# virtual-networks virtual-network vn2 config mode virtual-wire

  7. Exit to the top level of the configuration hierarchy.

    top

  8. Commit the configuration changes.

    commit

After you have configured two virtual networks, you can associate these networks with an interface or STATIC LAG.

You can configure the interface or STATIC LAG to associate with two previously-configured virtual networks from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Associate an interface or STATIC LAG with a virtual network.

    interfaces interface <*interface-or-lag-name*> { ethernet | aggregation } config virtual-network <*virtual-network*>

    This example associates interface 1.0 with a virtual network named vn1:

    default-1(config)# interfaces interface 1.0 ethernet config 
  virtual-network vn1

    This example associates LAG-11 with a virtual network named vn1:

    default-1(config)# interfaces interface LAG-11 aggregation config 
  virtual-network vn1

  5. Exit to the top level of the configuration hierarchy.

    top

  6. Associate a different interface or STATIC LAG with the other virtual network.

    interfaces interface <*interface-or-lag*> ethernet config virtual-networks <*virtual-network*>

    This example associates interface 2.0 with a virtual network named vn2:

    default-1(config)# interfaces interface 2.0 ethernet config 
  virtual-networks vn2

    This example associates LAG-12 with a virtual network named vn12:

    default-1(config)# interfaces interface LAG-12 aggregation config 
  virtual-networks vn2

  7. Exit to the top level of the configuration hierarchy.

    top

  8. Commit the configuration changes.

    commit

After you have associated the virtual networks with an interface or LAG, you can create a virtual wire that uses these virtual networks.

You can configure a virtual wire from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Create a virtual wire.

    virtual-wires virtual-wire <*name*> config virtual-networks [ <*virtual-networks*> ] vwire-propagate-linkstatus { false | true }

    This example creates a virtual wire named vwire that includes virtual networks named vn1 and vn2. It also specifies that link status is propagated, which means that if one interface in the virtual wire loses its connection (link down), that state propagates to the other interface in the virtual wire.

    default-1(config)# virtual-wires virtual-wire vwire config 
  virtual-networks [ vn1 vn2 ] vwire-propagate-linkstatus true

  5. Commit the configuration changes.

    commit

After you have created virtual networks and a virtual wire, you can add a virtual wire to a tenant.

You can add a virtual wire to a configured tenant from the chassis partition CLI.

  1. Connect using SSH to the chassis partition management IP address.

  2. Log in to the command line interface (CLI) of the chassis partition using an account with admin access.

    When you log in to the system, you are in user (operational) mode.

  3. Change to config mode.

    config

    The CLI prompt changes to include (config).

  4. Add a virtual wire to a tenant.

    tenants tenant <*tenant-name*> config virtual-wires <*virtual-wire-name*>

    This example adds a virtual wire named vwire to a tenant named bigip:

    default-1(config)# tenants tenant bigip config virtual-wires vwire

  5. Commit the configuration changes.

    commit

  6. Return to user (operational) mode.

    end

  7. Verify the tenant configuration.

    A summary similar to this excerpt displays:

    default-1# show tenants tenant bigip
tenants tenant bigip
 state unit-key-hash 123QLBL3xzfMHFvhYNeLmB/Hks/v/z17Zd5FxVYhwdBLQIR2yVFrzD/FMn8cbCtmoXeYMkl+ZLXP+zZXV/DMDA==
 state type          BIG-IP
 state image         BIGIP-15.1.8-0.0.7.ALL-F5OS.qcow2.zip.bundle
 state nodes         [ 1 2 ]
 state mgmt-ip       192.0.2.6
 state prefix-length 23
 state gateway       192.0.6.254
 state cryptos       enabled
 state tenant-auth-support disabled
 state vcpu-cores-per-node 6
 state memory        22016
 state storage size 77
 state running-state deployed
 state mac-data base-mac 00:0a:12:ff:34:56
 state mac-data mac-pool-size 1
 state appliance-mode disabled
 state status        Running
 state virtual-wires [ vwire ]
...

You can create a virtual network with a specified mode and interface members or link aggregation groups (LAGs).

Note: Only STATIC LAGs (not LACP) support virtual networks.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > Virtual Wire.

  3. In the Virtual Networks area, click Add.

  4. For Name, enter a name for the virtual network.

  5. For Mode, select virtual-wire.

    Important: You cannot create a virtual wire using this virtual network if you select default.

  6. For Member, select from available interface members and STATIC LAGs.

  7. Click Save.

After you have configured virtual networks, you can create virtual wires that use these virtual networks.

You can create a virtual wire that includes exactly two virtual networks.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Network Settings > Virtual Wire.

  3. In the Virtual Wires area, click Add.

  4. For Name, enter a name for the virtual network.

  5. For Propagate Link Status, select either whether to specify that if one interface in the virtual wire loses its connection (link is own), that state propagates to the other interface in the virtual wire.

    The default value is False.

  6. For Virtual Networks, select exactly two existing virtual networks to add to this virtual wire.

    The virtual wire networks must have the same member type (either interface or LAG). Mixing types is not supported. Also, each virtual network must have the same number of configured members.

  7. Click Save.

After you have configured virtual networks and virtual wires, you can assign virtual wires to a tenant.

You can add a virtual wire to a configured tenant from the webUI.

  1. Log in to the VELOS chassis partition webUI using an account with admin access.

  2. On the left, click Tenant Management > Tenant Deployments.

    The Tenant Deployment screen displays showing the existing tenant deployments and associated details.

  3. Click the name of the tenant deployment you want to modify.

    A drawer appears that displays the Tenant’s state information. Click on the edit icon on the drawer.

  4. For Virtual Wires, select configured virtual wires to be used by the tenant.

    Note: This field displays only when virtual wires are configured on the system.

  5. Click Save.

The tenant is reconfigured to use the selected virtual wires.