Manual Chapter : Network Settings

Applies To:

Show Versions Show Versions

F5OS-C

  • 1.6.0
Manual Chapter

Network Settings

Network configuration for the system controllers

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.

Configure management interfaces from the webUI

You can view or change the configuration of management interfaces, prefix length (netmask), and gateway for the
VELOS
system at the chassis level.
  1. Log in to the VELOS system controller webUI using an account with admin access.
  2. On the left, click
    NETWORK SETTINGS
    Management Interfaces
    .
  3. For
    DHCP
    , select
    Enabled
    if the management port is getting addresses from a DHCP server or select
    Disabled
    to configure the addresses manually.
  4. From
    Address
    , select whether to configure only IPv4 addresses, only IPv6 addresses, or both IPv4 and IPv6 addresses.
  5. Configure IPv4 addresses:
    1. For
      System Controller 1
      ,
      System Controller 2
      , and
      Floating
      , enter IP addresses in IPv4 format.
    2. For
      Prefix Length
      , enter a number from 1-32 for the length of the prefix.
    3. For
      Gateway
      , type the gateway IP address.
  6. Configure IPv6 addresses:
    1. For
      System Controller 1
      ,
      System Controller 2
      , and
      Floating
      , enter IP addresses in IPv6 format.
    2. For
      Prefix Length
      , enter a number from 10-127 for the length of the prefix.
    3. For
      Gateway
      , type the gateway IP address.
  7. In the
    Link Aggregation
    area, select
    Enabled
    to enable aggregation for the management ports between the system controllers and an upstream switch.
    Enabling link aggregation increases the bandwidth between peers by load balancing traffic across both ports.
  8. From
    Type
    , select a link aggregation type:
    Type
    Description
    STATIC
    Use static link aggregation, where you manually configure links and link state is not updated dynamically.
    LACP
    Use Link Aggregation Control Protocol (LACP) to allow for automatic bundling of links.
  9. From
    Interval
    , select ​FAST (every second) or SLOW​ (every 30 seconds).
  10. From
    Mode
    ,​ select ​an aggregration mode​.
    Type
    Description
    ACTIVE
    Send link aggregation control protocol data unit (LACPDU) packets unconditionally.
    PASSIVE
    Send LACPDU packets only when an LACP device is detected.
  11. For
    Name
    , you can change the name from the default value (mgmt-aggr) when link aggregation is enabled.
  12. The
    Configured Members
    area displays interfaces configured with link aggregation.
  13. Click
    Save
    .

Why use link aggregation on management ports

Forwarding is enabled for both management ports when link aggregation is used. If one port of the aggregation goes down, traffic is seamlessly handled by the remaining management port. A health-driven HA switchover need not occur to activate the alternate management port as it does when the management ports are operating independently.
There is also a gain in overall management port throughput. Specifically, total management port bandwidth doubles to 20 Gbps when aggregated. When not aggregated, only one management link is active at a time, and total bandwidth is limited to 10 Gbps.
The downside of using management port aggregation is that the ports to which the management ports connect must also be aggregated.
There is no difference in IP configuration between aggregated and independent modes of operation. That is because aggregation (an L2 feature) is applied to the physical switch ports that physically connect to the management network, and IP addresses are applied to host interfaces at L3 connecting to entirely different physical switch ports.

Configure management IP addresses from the CLI

After you connect your system controllers to a management console or console server, you can configure a floating management IP address and individual management IP addresses for both system controllers from the system controller CLI. You can use either IPv4 or IPv6 format for these IP addresses.
  1. Connect to the system using a management console or console server.
    The default baud rate and serial port configuration is 19200/8-N-1.
  2. Log in to the command line interface (CLI) of the system controller 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 management IP address for controller-1.
    system mgmt-ip config [
    ipv4
    |
    ipv6
    ] controller-1 address <
    ip-address
    >
    This example assigns an IPv4 address:
    syscon-1-active(config)# system mgmt-ip config ipv4 controller-1 address 192.0.2.10
    This example assigns an IPv6 address:
    syscon-1-active(config)# system mgmt-ip config ipv6 controller-1 address 2001:db8:ffff:100::1
  5. Configure the management IP address for controller-2.
    system mgmt-ip config [
    ipv4
    |
    ipv6
    ] controller-2 address <
    ip-address
    >
    This example assigns an IPv4 address:
    syscon-1-active(config)# system mgmt-ip config ipv4 controller-2 address 192.0.2.11
    This example assigns an IPv6 address:
    syscon-1-active(config)# system mgmt-ip config ipv6 controller-2 address 2001:db8:ffff:101::1
  6. Configure the floating IP address for the system controllers.
    system mgmt-ip config [
    ipv4
    |
    ipv6
    ] floating <
    ip-address
    >
    This example assigns an IPv4 address:
    syscon-1-active(config)# system mgmt-ip config ipv4 floating 192.0.2.15
    This example assigns an IPv6 address:
    syscon-1-active(config)# system mgmt-ip config ipv6 floating 2001:db8:ffff:102::1
  7. Configure the default gateway, if not using DHCP.
    system mgmt-ip config [
    ipv4
    |
    ipv6
    ] gateway <
    gateway-ip
    >
    This example assigns an IPv4 gateway:
    syscon-1-active(config)# system mgmt-ip ipv4 gateway 192.0.2.254
    This example assigns an IPv6 gateway:
    syscon-1-active(config)# system mgmt-ip ipv6 gateway 2001:db8:ffff:100::fffe
  8. Configure the default CIDR prefix length.
    system mgmt-ip config [
    ipv4
    |
    ipv6
    ] prefix-length <
    prefix-length
    >
    This example assigns a prefix length for an IPv4a address:
    syscon-1-active(config)# system mgmt-ip ipv4 prefix-length 24
    This example assigns a prefix length for an IPv6 address:
    syscon-1-active(config)# system mgmt-ip ipv6 prefix-length 64
  9. Commit the configuration changes.
    commit
The system saves the new IP addresses and gateway address for your system controllers. You can now use the floating IP address that you assigned to access the system either over SSH or using the webUI. The floating IP address will always be available on the primary system controller.

Configure DNS from the webUI

You can configure DNS for the
VELOS
system at the chassis level from the system controller webUI. This is used for name resolution such as when setting up the system.
  1. Log in to the VELOS system controller webUI using an account with admin access.
  2. On the left, click
    NETWORK SETTINGS
    DNS
    .
  3. Under
    DNS Lookup Servers
    , specify the name servers that the system uses to validate DNS lookups, and resolve host names. For each name server you want to add:
    1. Click
      Add
      .
    2. For
      Lookup Server
      , enter the IP address of the name server that you want to add to the list.
    3. Click
      Save & Close
      .
  4. Under
    DNS Search Domains
    , specify the domains that the system searches for local domain lookups and to resolve local host names. For each domain you want to add:
    1. Click
      Add
      .
    2. For
      Search Domain
      , enter the domain name of the name server that you want to add to the list. For example, DNSsearch.com
    3. Click
      Save & Close
      .
DNS lookup servers and search domains are now specified for the
VELOS
system.

Configure DNS from the CLI

You can configure DNS for the
VELOS
system at the chassis level from the system controller CLI. This is used for name resolution such as when setting up 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 DNS lookup server.
    system dns servers server <
    ip-address
    > port <
    port
    >
    This example configures a DNS server at 192.0.2.20:
    syscon-1-active(config)# system dns servers server 192.0.2.20 port 53
  5. Commit the configuration changes.
    commit

Network configuration for the chassis partition

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.

Port groups overview

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.

Configure port groups from the webUI

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.
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.
    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).
    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.

Configure port group mode from the CLI

You 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.
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.
    portgroups portgroup <
    blade-number
    >/<
    interface-number
    > config mode [
    MODE_100GB
    |
    MODE_4x25GB
    |
    MODE_40GB
    |
    MODE_4x10GB
    ]
    In this example, you configure the port group mode on blade 1/interface 2 to use the 40GB mode:
    default-1(config)# portgroups portgroup 1/2 config mode MODE_40GB
  5. Commit the configuration changes.
    commit
  6. Verify the port groups configuration.
    show portgroups portgroup

Interfaces overview

VELOS
blades support two kinds of physical network interfaces:
  • Interfaces that correspond to the blade front-panel QSFP28 ports
  • Link aggregation groups (LAGs)

Configure interfaces from the webUI

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.
  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
    is set to the default value of
    Auto
    (read only) and detects and corrects a limited number of errors in transmitted data.
    Since this setting is enabled automatically, your upstream switch must also support Forward Error Correction (FEC).
  9. RX Flow Control
    is set to
    Off
    , and it is not supported on any of the interfaces.
  10. For
    Native VLAN (Untagged)
    , select the VLAN ID to use for untagged frames received on an interface (either a single interface or LAG).
    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.
  11. 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.
    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.
  12. Click
    Save & Close
    .

Display and reset interface statistics from the webUI

You can view statistics for physical interfaces configured on the chassis partition you are logged in to from the chassis partition webUI. The table shows, for each interface, the amount of data that was input and output in multiple forms. You can also see in/out errors and frame check sequence (FCS) errors that occurred on each of the interfaces, and you can reset to clear the data.
  1. Log in to the VELOS chassis partition webUI using an account with admin access.
  2. On the left, click
    NETWORK SETTINGS
    Interface Statistics
    .
    A table showing all the statistics displays.
  3. Change the way the statistics are displayed in the
    Data Format
    by selecting
    Normalized
    or
    Unformatted
    .
    Selecting
    Normalized
    converts the byte representation to kilobytes, megabytes, or terabytes depending on the size. This provides better data readability especially when there is massive amounts of traffic passing through the interfaces.
  4. Set the
    Auto Refresh
    interval for refreshing the data displayed or click the refresh icon to update the data immediately.
  5. Select one or more interfaces, then click
    Reset
    to clear the data.

Configure an interface from the CLI

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

Show the state of a specified interface from the CLI

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:
    default-1# show interfaces interface 1/1.0 state state type ethernetCsmacd state mtu 9600 state enabled true state oper-status UP state forward-error-correction auto state lacp_state LACP_DEFAULTED

Link aggregation group (LAG) overview

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.

Display LACP details from the webUI

You can view the LACP details on the chassis partition webUI to troubleshoot. For example, to determine why an interface member of an LACP LAG on the chassis partition is not working as expected.
  1. Log in to the VELOS chassis partition webUI using an account with admin access.
  2. On the left, click
    NETWORK SETTINGS
    LACP Details
    .
    The screen shows state information about whether LACP is Up, Down, or Defaulted for LACP interfaces. The lower portion of the screen shows details that can be used for troubleshooting LACP issues.
  3. Set the
    Auto Refresh
    interval for refreshing the data displayed or click the refresh icon to update the data immediately.

Static LAG configuration from the CLI

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.
Configure a static LAG interface from the CLI
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
Add interfaces to LAG members from the CLI
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
Associate VLANs with LAG interfaces from the CLI
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

LACP configuration from the CLI

Create a LAG interface from the CLI
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
Create an LACP interface from the CLI
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
Enable LACP on a LAG interface from the CLI
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
Display LACP state from the CLI
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
Display LACP interface state from the CLI
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.
Configure LACP logging level from the CLI
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
Display configuration members from the CLI
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 !
Display working members from the CLI
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 - - -

VLAN overview

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.

Create VLANs from the webUI

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
    .
  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.
    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).

Create VLANs from the CLI

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).

VLAN listeners overview

VLAN listeners are created and deleted by the system at runtime. They are used to program the destination for broadcast packets and L2 destination lookup failures (DLFs).
The system creates a listener when you configure a VLAN for a tenant.
VLAN Listener (listener)
Created when a VLAN is used by a single tenant or when a VLAN is not shared among tenants. VLAN listeners that are created for tenant VLANs that do not include any members are indicated with the value
0.host
for interface.
Rebroadcast Listener (rbcast-listener)
Created when a VLAN is used by multiple tenants, that is, when tenants share VLANs
in a chassis partition
.

Display VLAN listeners from the webUI

You can view VLAN listeners when you need to troubleshoot data path issues and check whether the correct VLANs are assigned to the tenants 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
    VLAN Listeners
    .
    The screen shows VLAN listeners that are active on the system.
  3. Set the
    Auto Refresh
    interval for refreshing the data displayed or click the refresh icon to update the data immediately.
You can see the VLAN listeners that are associated with specific interfaces, VLANs, and other related information. If something does not look correct, review the configuration for that object.

Display VLAN listeners from the CLI

Viewing the VLAN listeners is primarily used for troubleshooting data path issues. You can check whether the correct VLANs are assigned to the tenants 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. View configured VLAN listeners.
    show vlan-listeners
    A summary similar to this example displays:
    default-1# show vlan-listeners NDI INTERFACE VLAN ENTRY TYPE OWNER ID SVC VTC SEP DMS DID CMDS MIRRORING SERVICE IDS --------------------------------------------------------------------------------------------------------------------- 0.host 100 RBCAST-LISTENER rbcast 4095 5 32 15 - - - disabled [ 13 14 15 16 17 18 19 ] 0.host 101 VLAN-LISTENER t101100 4095 19 - 15 - - - disabled -
You can see the VLAN listeners that are associated with specific interfaces, VLANs, and other related information. If something does not look correct, review the configuration for that object.

IP tunnels overview

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
at techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-tmos-tunnels-ipsec-13-1-0.html.

IP tunnel configuration from the webUI

Configure GTP tunnels from the webUI
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.
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. 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
    .
  4. Click
    Save
    .
All tenants running on the system now use GTP tunnels.
Configure GENEVE tunnels from the webUI
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. Under Type, select
    GENEVE
    .
  4. Click
    GENEVE
    to edit the settings.
  5. For
    Enabled
    , select
    True
    to enable GENEVE tunnels on the system or
    False
    to disable them.
  6. For
    Destination Port
    , edit the port number.
    The range is from 0 to 65535. The default value is 6081.
  7. Click
    Save
    .
Configure NVGRE tunnels from the webUI
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. Under Type, select
    NVGRE
    .
  4. Click
    NVGRE
    to edit the settings.
  5. 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).
  6. Click
    Save
    .
Configure VXLAN tunnels from the webUI
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. Under Type, select
    VXLAN
    .
  4. Click
    VXLAN
    to edit the settings.
  5. For
    Destination Port
    , edit the port number.
    The range is from 0 to 65535. The default value is 4789.
  6. For
    GPE Enabled
    , select
    True
    to enable support for the VXLAN GPE tunnel type on the system or
    False
    to disable it.
  7. For
    GPE Destination Port
    , edit the port number.
    The default value is 4790.
  8. For
    NSH Enabled
    , select
    True
    to enable the VXLAN GPE NSH tunnel type on the system or
    False
    to disable it.
  9. Click
    Save
    .
Disable IP tunnels from the webUI
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
    .
Reset IP tunnels to default values from the webUI
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. Select a tunnel type.
  4. Click
    Reset
    .

IP tunnel configuration from the CLI

Configure GTP tunnels from the CLI
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.
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
Configure GENEVE tunnels from the CLI
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
Configure NVGRE tunnels from the CLI
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
Configure VXLAN tunnels from the CLI
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

Link Layer Discovery Protocol (LLDP) overview

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.

LLDP configuration from the webUI

Configure LLDP from the webUI
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 Configuration
    .
  3. Set
    Enable LLDP
    to
    Enabled
    .
  4. Type a
    System Name
    and optionally, a
    System Description
    .
  5. 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.
  6. For
    TX Hold
    , enter a number (0-65535) to specify the hold time for LLDP transmissions.
    The default value is 4 seconds.
  7. 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.
  8. 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.
  9. 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.
  10. 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:
    1. Select
      Enabled
      .
    2. For the
      TLV Advertisement State
      , select
      TX
      (transmit only),
      RX
      (receive only), or
      TXRX
      (transmit and receive).
      The default value is
      txrx
      .
    3. 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.
  11. Click
    Save
    .
LLDP is configured on the system for the specified interfaces and LAGs.
Remove LLDP interfaces from the webUI
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 Configuration
    .
  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.
Display LLDP details from the webUI
LLDP enables a network device to advertise information about themselves to other devices on the network and enables network devices to receive information from neighboring devices. If using LLDP, you can display state information for the LLDP-enabled interfaces and LAGs in the chassis partition. When LLDP is enabled to receive data in a working network, any device information received from neighbors is included in a table.
  1. Log in to the VELOS chassis partition webUI using an account with admin access.
  2. On the left, click
    NETWORK SETTINGS
    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. Set the
    Auto Refresh
    interval for refreshing the data displayed or click the refresh icon to update the data immediately.

LLDP configuration from the CLI

Configure LLDP on a chassis partition from the CLI
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
Configure LLDP on an interface from the CLI
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 !

Quality of Service (QoS) configuration overview

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.

Spanning tree protocol (STP) overview

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 partition
at 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.
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.
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.
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.

STP/RSTP/MSTP configuration from the webUI

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
.
Configure STP from the webUI
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 Configuration
    .
  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).
  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.
  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.
  8. 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.
  9. 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).
    For more information on the available interfaces and LAGs, see the
    NETWORK SETTINGS
    Interfaces
    or
    LAGs
    screens.
  10. Click
    Save
    .
STP is now set up for use on the system.
Configure RSTP from the webUI
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 Configuration
    .
  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 are displayed (with default values set).
  4. 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)
  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. 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)
  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. For RSTP, maintain these relationships between the Maximum Age and Forward Delay options:
    Max Age <= 2 * (Forward Delay - 1)
  7. For
    Interfaces
    , select (one at a time) the interfaces and LAGs, if any, for which you want to configure RSTP 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).
    For more information on the available interfaces and LAGs, see the
    NETWORK SETTINGS
    Interfaces
    or
    LAGs
    screens.
  8. Click
    Save
    .
RSTP is now set up for use on the system.
Configure MSTP from the webUI
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 Configuration
    .
  3. For
    STP Mode
    , select
    MSTP
    (multiple instances, fast convergence).
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. To configure multiple instances for a region, adjust these settings for
    MSTP Instances
    :
    1. Under
      Instances
      , click
      +
      .
    2. In the Add MSTP Instance popup, 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:
    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).
  11. Continue to configure any other instances that you might need.
  12. Click
    Save
    .
    The system displays a confirmation dialog confirming whether to update the system controllers.
MSTP is set up for use on the system.

STP/RSTP/MSTP configuration from the CLI

Change STP modes from the CLI
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
Configure STP from the CLI
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
    >
    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
Configure RSTP from the CLI
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
    >
    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
    ]
    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
Configure MSTP from the CLI
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.
    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
    >
    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
    }
    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

Virtual wire overview

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.
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.
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.

Virtual wire configuration from the CLI

Configure virtual networks from the CLI
You can configure virtual networks with a specified mode from the chassis partition CLI.
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.
    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).
    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.
Configure the interface/LAG for virtual networks from the CLI
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.
Configure a virtual wire from the CLI
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.
Add a virtual wire to a tenant from the CLI
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 ] ...