Manual Chapter : Network Settings

Applies To:

Show Versions

F5OS-A

1.8.0

Network Settings

Network settings overview

An administrator can configure L2 network settings for the

rSeries

system, such as port groups, LAGs, interfaces, VLANs, LACP, LLDP, and STP. You can configure these network settings from the webUI, the CLI, or REST APIs.

Port groups overview

The front-panel ports on

F5 r2000/r4000 and F5 r5000/r10000 platforms

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

rSeries

system uses port speeds of

100G, 25G, or 10G, depending on the port and the platform

. You can change them based on what optical transceiver module type you are using.

F5 r2000/r4000 platforms have pre-defined configuration modes. These port group options are 4x25GbE, 8x10GbE, and 4x10GbE+2x25GbE.

Before configuring any interfaces, VLANs, or LAGs, you can set up port groups so that physical interfaces on the

platform

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.

Changing the mode for a port group reboots the

system

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

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.

On the left, click

NETWORK SETTINGS

Port Groups

For a specific port group, select a

Mode

from the list.

For F5 r5000/r10000, you can choose one of these modes:

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

For F5 r2000/r4000, you can choose a pre-defined configuration as a mode:

Option	Description
4x25GbE	Creates four interfaces at 25G speed.
4x10GbE+2x25GbE	Creates four interfaces at 10G speed and two interfaces at 25G speed.
8x10GbE	Creates eight interfaces at 10G speed.

Click

Save

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

Configure the mode of a port group from the CLI

You can configure a port group for the interfaces on the system at either 100G or 40G speeds from the CLI..

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Configure port groups for a specific interface.

portgroups portgroup <interface-number> config mode {

MODE_100GB

MODE_40GB

MODE_4x10GB

}

In this example, you configure the port group mode on interface 2 to use the 100GB mode:

appliance-1(config)# portgroups portgroup 2 config mode MODE_100GB

Commit the configuration changes.

commit

Show the state of port groups from the CLI

You can show the state for port groups on the system from the CLI.

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

Show the current state for the port groups configuration.

show portgroups portgroup

A summary similar to this example displays:

appliance-1# show portgroups portgroup
portgroups portgroup 1
 state vendor-name      "F5 INC."
 state vendor-oui       009065
 state vendor-partnum   "OPT-0031        "
 state vendor-revision  A0
 state vendor-serialnum "A1B2C3D40         "
 state transmitter-technology "850 nm VCSEL"
 state media            100GBASE-SR4
 state optic-state      QUALIFIED
 state ddm rx-pwr low-threshold alarm -14.0
 state ddm rx-pwr low-threshold warn -11.0
 state ddm rx-pwr instant val-lane1 -1.96
 state ddm rx-pwr instant val-lane2 -0.95
 state ddm rx-pwr instant val-lane3 -1.06
 state ddm rx-pwr instant val-lane4 -1.98
 state ddm rx-pwr high-threshold alarm 3.4
 state ddm rx-pwr high-threshold warn 2.4
 state ddm tx-pwr low-threshold alarm -10.0
 state ddm tx-pwr low-threshold warn -8.0
 state ddm tx-pwr instant val-lane1 0.07
 state ddm tx-pwr instant val-lane2 0.67
 state ddm tx-pwr instant val-lane3 0.32
 state ddm tx-pwr instant val-lane4 0.45
 state ddm tx-pwr high-threshold alarm 5.0
 state ddm tx-pwr high-threshold warn 3.0
 state ddm temp low-threshold alarm -5.0
 state ddm temp low-threshold warn 0.0
 state ddm temp instant val 40.8046
 state ddm temp high-threshold alarm 75.0
 state ddm temp high-threshold warn 70.0
 state ddm bias low-threshold alarm 0.003
 state ddm bias low-threshold warn 0.005
 state ddm bias instant val-lane1 0.00753
 state ddm bias instant val-lane2 0.007448
 state ddm bias instant val-lane3 0.007536
 state ddm bias instant val-lane4 0.007504
 state ddm bias high-threshold alarm 0.013
 state ddm bias high-threshold warn 0.011
 state ddm vcc low-threshold alarm 2.97
 state ddm vcc low-threshold warn 3.135
 state ddm vcc instant val 3.3027
 state ddm vcc high-threshold alarm 3.63
 state ddm vcc high-threshold warn 3.465
...

Port mappings overview

Port mappings show how the front-panel interfaces on F5 r5000/r10000 systems are configured for capacity bandwidth and allocated bandwidth using

pipelines

and

pipeline groups

pipeline: Corresponds to a traffic-processing pipeline. There are eight virtual ports per pipeline. Each pipeline has 100Gb of throughput.
pipeline group: Contains two pipelines and corresponds to FPGA sockets. The system FPGAs are configured in the bitstream to support the different ports. No bitstream supports all ports simultaneously.

Display port mappings from the webUI

You can view how port mappings are configured from the webUI.

On the left, click

NETWORK SETTINGS

Port Mappings

The current configuration for port mappings displays.

Port profiles overview

The front-panel ports on F5 r2000/r4000 systems support port profile functionality. Port profiles enable you to change which mode, or port speed, that port uses. SFP28 ports operate at 25GbE by default, and SFP+ ports operate at 10GbE by default. Only these configurations are available:

8x10G: All eight 10G (SFP+) ports run at 10G speed. This is the default configuration.
2x25G - 4x10G: Two 25G (SFP28) ports run at 25G speed, and four 10G (SFP+) ports run at 10G.
4x25G: All four 25G (SFP28) ports run at 25G speed.

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

All tenants must be in “configured” state before you can change the port profile. You cannot change the profile while a tenant is in “deployed” state.

Configure a port profile from the CLI

You can configure port profiles for the interfaces on the system from the CLI.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Change the port profile configuration.

port-profiles config mode [

2x25G-4x10G

4x25G

8x10G

}

In this example, you configure the port profile to use the 4x25G mode:

appliance-1(config)# port-profiles config mode 4x25G

Commit the configuration changes.

commit

Interfaces overview

rSeries

systems include a set number of front-panel interfaces (or ports). The number of available interfaces varies depending on hardware model.

For the F5 r2000/r4000 platforms, you can now add same VLAN ID to multiple members. Adding the same VLAN ID to multiple members could result in L2 loops. Special considerations should be made to the network topology to avoid L2 loops.

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 a VLAN

You can configure interfaces from the webUI.

On the left, click

NETWORK SETTINGS

Interfaces

A table showing all interfaces displays.

Click an interface name.

For

Description

, enter text to describe the interface.

For

State

, select whether the interface is

Enabled

Disabled

These settings are informational, use set values, and cannot be changed: Operational Status, Speed, LACP State, MAC Address, and Interface Type.

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.

Changing the MTU at the platform level would affect all tenants, so this is configurable at the tenant level for greater control.

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

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.

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.

Click

Save & Close

Display and reset interface statistics from the webUI

You can view statistics for physical interfaces configured on the system from the 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.

On the left, click

SYSTEM SETTINGS

Management Interface

In the Interface Statistics area, change the way the statistics are displayed in the

Data Format

by selecting

Normalized

Unformatted

Selecting

Normalized

converts the byte representation to kilobytes, megabytes, or terabytes, depending on the size. This provides better data readability especially when there are massive amounts of traffic passing through the interfaces.

Set the

Auto Refresh

interval for refreshing the data displayed or click the refresh icon to update the data immediately.

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Configure settings for the specified interface.

interfaces interface <interface> config {

disabled

enabled

} description <interface-description> type <interface-type>

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

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

Changing the MTU at the platform level would affect all tenants, so this is configurable at the tenant level for greater control.

Commit the configuration changes.

commit

Show the state of a specific interface from the CLI

You can show the state of a specific interface on a platform from the CLI.

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

Display the current status of a specific interface.

show interface interface <interface-number>

When you specify a specific interface, a summary similar to this example displays:

appliance-1# show interfaces interface 5.0
interfaces interface 5.0
 state name               5.0
 state type               ethernetCsmacd
 state mtu                9600
 state enabled            true
 state ifindex            26
 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 auto
 state lacp_state         LACP_DEFAULTED
 ethernet state port-speed SPEED_25GB
 ethernet state hw-mac-address 00:12:a1:34:56:78
 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 on

appliance-1# show interfaces interface 1.0
interfaces interface 1.0
 state name               1.0
 state type               ethernetCsmacd
 state mtu                9600
 state enabled            true
 state ifindex            19
 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 auto
 state lacp_state         LACP_DEFAULTED
 ethernet state port-speed SPEED_100GB
 ethernet state hw-mac-address 00:98:a1:76:54:0d
 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 on

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

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

Ethernet State Counters
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.

Configure Forward Error Correction for the interface from the CLI

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.

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.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Configure forward error correction state:

interfaces interface <interface> config forward-error-correction

A summary of this example displays:

appliance-1(config)# interfaces interface 3/1.0 config forward-error-correction enabled

Commit the configuration changes.

commit

Display the state of Forward Error Correction for the interface from the CLI

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

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

Display the current state Forward Error Correction for the interfaces.

show interfaces interface state forward-error-correction

A summary to this example displays:

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

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.

Create LAGs from the webUI

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

On the left, click

NETWORK SETTINGS

LAGs

The screen shows LAGs that are configured.

Click

Add

For

Name

, enter a name for the LAG.

For

Description

, enter text to describe the LAG.

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.

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

For

Configured Members

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

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 20 members to a LAG.

For

Native VLAN (Untagged)

, select the VLAN ID to use for untagged frames received on a trunk interface.

For

Trunk VLANs (Tagged)

, select one or more VLAN IDs, if available and not a member of another LAG.

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.

Click

Save & Close

The LAG is created and shown in the list. You can add up to 256 LAGs.

Modify LAGs from the webUI

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

On the left, click

NETWORK SETTINGS

LAGs

The screen shows LAGs that are configured.

Click a LAG name.

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.

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

For

Configured Members

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

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 20 members to a LAG.

For

Native VLAN (Untagged)

, select the VLAN ID to use for untagged frames received on a trunk interface.

For

Trunk VLANs (Tagged)

, select one or more VLAN IDs, if available and not a member of another LAG.

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.

Click

Save & Close

Display LACP details from the webUI

You can view the LACP details on the webUI to troubleshoot. For example, you can determine why an interface member of an LACP LAG on the system is not working as expected.

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.

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Create a LAG interface.

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

This example creates a LAG named lag-test with a description:

appliance-1(config)# interfaces interface lag-test config type ieee8023adLag 
  description "HA LAG"

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

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

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:

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

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Add interfaces to a LAG.

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

This example adds interface 1.0 to a LAG named lag-test:

appliance-1(config)# interfaces interface 1.0 ethernet config aggregate-id lag-test

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Create a LAG interface.

interfaces interface <lag-name> config type ieee8023adLag

This example creates a LAG named lag-test:

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

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

Commit the configuration changes.

commit

Return to user (operational) mode.

end

Verify that LACP is enabled on the interface.

show interfaces interface lag-test

A summary similar to this example displays:

appliance-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
 ethernet state flow-control rx on
 aggregation state lag-type LACP
 aggregation state lag-speed 100
 aggregation state distribution-hash src-dst-ipport
 aggregation state mac-address 00:94:a1:69:61:14
 aggregation state lagid 1

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Enable LACP on a LAG interface.

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

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

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

Commit the configuration changes.

commit

Return to user (operational) mode.

end

Verify that LACP is enabled on a specified LAG interface.

A summary similar to this example displays:

appliance-1# show interfaces interface lag-test
 state name               lag-test
 state type               ieee8023adLag
 state mtu                9600
 state oper-status        UP
 state forward-error-correction auto
 ethernet state flow-control rx on
 aggregation state lag-type LACP
 aggregation state lag-speed 100
 aggregation state distribution-hash src-dst-ipport
 aggregation state mac-address 00:94:a1:69:61:14
 aggregation state lagid 1

Display LACP state from the CLI

You can check the LACP state from the CLI.

Connect using SSH to the management IP address.

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

Display the LACP state.

show lacp

A summary similar to this example displays:

appliance-1# show lacp
lacp state system-id-mac 00:94:a1:69:34:23
lacp interfaces interface lag-test
 state name    lag-test
 state interval SLOW
 state lacp-mode ACTIVE
 state system-id-mac 00:94:a1:69:34:23
 members member 1.0
  state interface  1.0
  state activity   ACTIVE
  state timeout    LONG
  state synchronization IN_SYNC
  state aggregatable true
  state collecting true
  state distributing true
  state system-id  00:94:a1:69:34:23
  state oper-key   2
  state partner-id 2c:dd:e9:41:87:61
  state partner-key 4
  state port-num   1024
  state partner-port-num 266
  state counters lacp-in-pkts 2456
  state counters lacp-out-pkts 2458
  state counters lacp-rx-errors 0

Display LACP interface state from the CLI

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

Connect using SSH to the management IP address.

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

Display the state of LACP interfaces.

show interfaces interface state lacp_state

A summary similar to this example displays:

appliance-1# show interfaces interface state lacp_state
NAME  LACP STATE
----------------------
1.0   LACP_UP
2.0   LACP_DEFAULTED
3.0   LACP_DEFAULTED
4.0   LACP_DEFAULTED
5.0   LACP_DEFAULTED
6.0   LACP_DEFAULTED
7.0   LACP_DEFAULTED
8.0   LACP_DEFAULTED
9.0   LACP_DEFAULTED
10.0  LACP_DEFAULTED
11.0  LACP_DEFAULTED
12.0  LACP_DEFAULTED
13.0  LACP_DEFAULTED
14.0  LACP_DEFAULTED
15.0  LACP_DEFAULTED
16.0  LACP_DEFAULTED
17.0  LACP_DEFAULTED
18.0  LACP_DEFAULTED
19.0  LACP_DEFAULTED
20.0  LACP_DEFAULTED

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 an LACP LAG.
LACP_DOWN	LACPD has determined that this interface is not a working member of an 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/system/log/platform.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 CLI.

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

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

Connect using SSH to the management IP address.

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

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:

appliance-1# show running-config interfaces interface ethernet config aggregate-id lag-test
interfaces interface 1.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. You can see information about working members in a LAG from the CLI.

Connect using SSH to the management IP address.

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

Show the working members, including port statistics.

show lacp interfaces interface members member state counters

A summary similar to this example displays:

appliance-1# show lacp interfaces interface members member state counters
                    LACP  LACP  LACP    LACP    LACP
                    IN    OUT   RX      TX      UNKNOWN  LACP
NAME     INTERFACE  PKTS  PKTS  ERRORS  ERRORS  ERRORS   ERRORS
-----------------------------------------------------------------
lag-test 1.0        952   384   0       -       -        -
         2.0        844   384   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

rSeries

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 associate physical interfaces or LAGs with that VLAN. 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.

On the left, click

NETWORK SETTINGS

VLANs

The screen shows VLANs that are configured for the system.

Click

Add

For

Name

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

For

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.

Click

Add VLAN

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

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.

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

On the left, click

NETWORK SETTINGS

VLAN Listeners

The screen shows VLAN listeners that are active on the system.

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

Connect using SSH to the management IP address.

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

View configured VLAN listeners.

show vlan-listeners

A summary similar to this example displays:

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

rSeries

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.

F5 r5000/r10000

systems support these tunneling protocols:

GENEVE

GTP

GRE

IP in IP

EtherIP

NVGRE

VXLAN

By configuring IP tunneling protocols on

rSeries

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

rSeries

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 CLI

Configure GTP tunnels from the CLI

You can enable or disable GTP tunnels from the 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.

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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

}

Commit the configuration changes.

commit

Return to user (operational) mode.

end

Verify the DAG hashing configuration.

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

Commit the configuration changes.

commit

Configure NVGRE tunnels from the CLI

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

Commit the configuration changes.

commit

Configure VXLAN tunnels from the CLI

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

Commit the configuration changes.

commit

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

On the left, click

NETWORK SETTINGS

IP Tunnels

Set

GTP-U TEID Hash

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

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

On the left, click

NETWORK SETTINGS

IP Tunnels

Under Type, select

GENEVE

Click

GENEVE

to edit the settings.

For

Enabled

, select

True

to enable GENEVE tunnels on the system or

False

to disable them.

For

Destination Port

, edit the port number.

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

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

On the left, click

NETWORK SETTINGS

IP Tunnels

Under Type, select

NVGRE

Click

NVGRE

to edit the settings.

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

Click

Save

Configure VXLAN tunnels from the webUI

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

On the left, click

NETWORK SETTINGS

IP Tunnels

Under Type, select

VXLAN

Click

VXLAN

to edit the settings.

For

Destination Port

, edit the port number.

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

For

GPE Enabled

, select

True

to enable support for the VXLAN GPE tunnel type on the system or

False

to disable it.

For

GPE Destination Port

, edit the port number.

The default value is 4790.

For

NSH Enabled

, select

True

to enable the VXLAN GPE NSH tunnel type on the system or

False

to disable it.

Click

Save

Reset IP tunnels to default values from the webUI

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

On the left, click

NETWORK SETTINGS

IP Tunnels

Under Type, select the check box next to the tunnel type.

Click

Reset

Link Layer Discovery Protocol (LLDP) overview

The

rSeries

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

rSeries

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.

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

On the left, click

NETWORK SETTINGS

LLDP Configuration

Set

Enable LLDP

Enabled

Type a

System Name

and optionally, a

System Description

For

TX Interval

, enter a number (0-65535) for the interval (in seconds) at which LLDP packets are sent to neighbors. The default value is 30 seconds.

For

TX Hold

, enter a number (0-65535).

The default value is 4 seconds.

For

Reinitiate Delay

, enter a number (0-65535) to specify the minimum time interval, in seconds, an LLDP port waits before re-initializing an LLDP transmission.

The default value is 2 seconds.

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.

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.

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:

Select

Enabled

For

TLV Advertisement State

, select

(Transmit only),

(Receive only), or

TXRX

(Transmit and Receive).

For

TLV Map

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

Click

Save

To remove an interface that has been enabled for LLDP:

In the

Interfaces

table, select the interface you want to remove.

Click

Remove

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

On the left, click

NETWORK SETTINGS

LLDP Configuration

In the

Interfaces

table, select the interfaces you want to remove.

For each interface selected:

Click

Remove

Click

Save

The LLDP interfaces are removed.

Display LLDP details from the webUI

LLDP enables a network device to advertise information about itself 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 on the system. When LLDP is enabled to receive data in a working network, any device information received from neighbors is included in a table.

On the left, click

NETWORK SETTINGS

LLDP Details

The screen shows LLDP state information for interfaces in the system (similar to information shown at the CLI using

show lldp

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

This information provides details useful for troubleshooting many configuration problems.

Set the

Auto Refresh

interval for refreshing the data displayed or click the refresh icon to update the data immediately.

Spanning tree protocol (STP) overview

The

rSeries

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.

Spanning tree protocols are supported only on F5 r5000/r10000 platforms.

The spanning tree protocols that the

rSeries

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

the system

from the webUI, CLI, or REST API. Only one spanning tree protocol can be configured 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

rSeries

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

rSeries

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 webUI. To disable the use of STP Modes, select

Disabled

Spanning tree protocols are only supported on F5 r5000/r10000 platforms.

On the left, click

NETWORK SETTINGS

STP Configuration

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

, the selected mode is enabled, and additional options for that mode display (with default values set).

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.

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

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

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.

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.

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

LAGs

screens.

Click

Save

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

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 webUI. To disable the use of STP Modes, select

Disabled

Spanning tree protocols are only supported on F5 r5000/r10000 platforms.

On the left, click

NETWORK SETTINGS

STP Configuration

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

, the selected mode is enabled, and additional options for that mode are displayed (with default values set).

For

Hello Time

, specify the time interval, in seconds, that the

rSeries

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)

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)

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)

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.

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.

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

LAGs

screens.

Click

Save

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

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 webUI. To disable the use of STP Modes, select

Disabled

Spanning tree protocols are only supported on F5 r5000/r10000 platforms.

On the left, click

NETWORK SETTINGS

STP Configuration

For

STP Mode

, select

MSTP

(multiple instances, fast convergence).

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.

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.

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.

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.

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 1 to 255.

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

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.

To configure multiple instances for a region, adjust these settings for

MSTP Instances

Under

Instances

, click

In the Add MSTP Instance popup, for

Instance ID

, enter a positive integer and click

Add

Under

Instances

, select one of the instances.

Available interfaces are listed below.

Under

VLANs

, select the VLANs to map to this instance.

For

Bridge Priority

, configure this setting so that the

rSeries

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.

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

Continue to configure any other instances that you might need.

Click

Save

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

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Disable the current STP mode

no stp global config enabled-protocol STP

Commit the configuration changes.

commit

Remove the existing interface configuration for STP mode.

no stp stp interfaces interface

Remove the edge port and link type configuration.

no stp interfaces interface

Commit the configuration changes.

commit

Enable another STP mode.

stp global config enabled-protocol {

MSTP

RAPID_PVST

RSTP

STP

}

In this example, you enable RSTP:

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

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Enable STP.

stp global config enabled-protocol {

MSTP

RAPID_PVST

RSTP

STP

]

In this example, you enable STP mode:

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

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:

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

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 port number. 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 port 1.0, with an interface cost of 200 and a port priority of 128:

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

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

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.

appliance-1(config)# stp rstp config bridge-priority 32768

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.

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

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

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 port 2.0 to set the interface as an EDGE_AUTO port that uses point-to-point spanning tree links:

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

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

rSeries

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

rSeries

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

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Enable MSTP.

stp mstp config name <region-name> revision <revision>

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.

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

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

Configure VLANs for the MSTP instance.

vlans vlan <vlan-id>

The VLANs must already exist.

In this example, you create VLANs 300 and 301:

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

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

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

Exit to the top level of the configuration hierarchy.

top

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:

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

Exit to the top level of the configuration hierarchy.

top

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.

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

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

Exit to the top level of the configuration hierarchy.

top

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 port 2.0 to set the interface as an EDGE_AUTO port that uses point-to-point spanning tree links:

appliance-1(config)# stp interfaces interface 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.

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.

Virtual wire is supported only on F5 r5000/r10000 platforms.

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

Only STATIC LAGs (not LACP) support virtual networks.

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

Exit to the top level of the configuration hierarchy.

top

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:

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

Exit to the top level of the configuration hierarchy.

top

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

Associate an interface or STATIC LAG with a virtual network.

interfaces interface <interface-or-lag-name> {

ethernet

aggregation

} config virtual-networks <virtual-network>

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

appliance-1(config)# interfaces interface 1.0 ethernet config 
  virtual-networks vn1

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

appliance-1(config)# interfaces interface LAG-11 aggregation config 
  virtual-networks vn1

Exit to the top level of the configuration hierarchy.

top

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:

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

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

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

Exit to the top level of the configuration hierarchy.

top

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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.

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

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

Connect using SSH to the management IP address.

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

Change to config mode.

config

The CLI prompt changes to include

(config)

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:

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

Commit the configuration changes.

commit

Return to user (operational) mode.

end

Verify the tenant configuration.

A summary similar to this excerpt displays:

appliance-1# show tenants tenant bigip
tenants tenant bigip
 state unit-key-hash ab3yFvh6S/23DuLw6JQ1jaw72rZllkn734sgLOCAyU3ffr2JL9Y798E+AJdY8wTmV+auiNQ9amIy60KC/DALww==
 state type          BIG-IP
 state image         BIGIP-bigip15.1.x-europa-15.1.8-0.0.371.ALL-F5OS.qcow2.zip.bundle
 state mgmt-ip       192.0.2.75
 state prefix-length 24
 state gateway       192.0.2.254
 state vlans         [ 100 ]
 state cryptos       enabled
 state vcpu-cores-per-node 4
 state memory        14848
 state storage size 77
 state running-state deployed
 state appliance-mode disabled
 state status        Running
 state primary-slot  1
 state image-version "BIG-IP 15.1.8 0.0.371"
 state virtual-wires [ vwire ]
 state mac-data base-mac 00:94:a1:69:61:14
 state mac-data mac-pool-size 1
...

Virtual wire configuration from the webUI

Configure virtual networks from the webUI

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

Only STATIC LAGs (not LACP) support virtual networks.

On the left, click

NETWORK SETTINGS

Virtual Wire

In the Virtual Networks area, click

Add

For

Name

, enter a name for the virtual network.

For

Mode

, select

virtual-wire

You cannot create a virtual wire using this virtual network if you select

default

For

Member

, select from available interface members and STATIC LAGs.

Click

Save & Close

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

Configure virtual wires from the webUI

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

On the left, click

NETWORK SETTINGS

Virtual Wire

In the Virtual Wires area, click

Add

For

Name

, enter a name for the virtual network.

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

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.

Click

Save & Close

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

Add a virtual wire to a tenant from the webUI

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

On the left, click

TENANT MANAGEMENT

Tenant Deployments

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

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

The Tenant Deployment screen displays.

For

Virtual Wires

, select configured virtual wires to be used by the tenant.

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

Click

Save & Close

The tenant is reconfigured to use the selected virtual wires.

Network utilization and diagnostics

You can monitor the amount of data being transmitted across a network over a given period. These statistics are crucial for maintaining optical performance, preventing congestion, and ensuring fair usage.

The network diagnostics help in troubleshooting by providing a range of network utilities to detect and solve network-related problems.

Display network utilization from the webUI

To see the network utilization, follow the steps below:

On the left, click

NETWORK SETTINGS

Network Details

You can now see the following network details.

Network Utilization

: Displays the amount of data being transmitted across an interface currently by default. However, if multiple interfaces are available, you can select an interface, data type and change the time series to view the historical data and analyze the data transmission.

Interface Counters

: To view data unformatted/formatted, use

Data Format

dropdown. To auto-refresh data at specific intervals, use the

Auto Refresh

dropdown. Selecting an interface and clicking on

Reset

will reset the counters and restart the current graph for that interface.

Run network diagnostics from the CLI

To diagnose various network utilities, follow the steps below:

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

Run the network diagnostic command.

system diagnostics net-utils <command>

Below are the list of possible diagnostic commands for the network functionalities:


    dig           Run dig
    ping          Run ping
    ping6         Run ping6
    shell         Run the diagnostic shell tool
    tracepath     Run tracepath
    tracepath6    Run tracepath6
    traceroute    Run traceroute
    traceroute6   Run traceroute6

This example shows running the network diagnostics for ping:

appliance-1# system diagnostics net-utils ping -
 
Possible completions:
  -C: Stop after sending count ECHO_REQUEST packets.
  -i: Wait interval seconds between sending each packet.
  -n: Numeric output only. No attempt will be made to lookup symbolic names for host addresses.
appliance-1# system diagnostics net-utils ping -c 4 www.google.com
 
PING www.google.com (142.250.217.681 56(84) bytes of data.
 
64 bytes from sea09s29-in-f4.1e100.net (142.250.217.68) : icmp_seq=1 tt1=54 time=73.4 ms
 
64 bytes from sea09s29-in-f4.1100.net (142.250.217.68) : icmp_seq=2 tt1=54 time=74.3 ms
 
64 bytes from sea09s29-in-f4.14100.net (142.250.217.68) : icmp_seq=3 tt1=54 time=72.1 ms
 
64 bytes from sea09s29-in-£4.1100.net (142.250.217.68): icmp seq-4 tt1=54 time=72.6 ms
 
 
--- www.google.com ping statistics ---
 
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
 
rtt min/avg/max/mdev = 72.167/73.169/74.388/0.877 ms

Run network diagnostics commands using shell

The ‘shell’ option allows you to execute network diagnostics commands from the shell without going back to the original prompt. It provides an interactive interface to execute multiple commands.

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

Access shell to run the network diagnostic commands.

system diagnostics net-utils shell

This example shows accessing shell to run the network diagnostic commands:

appliance-1# system diagnostics net-utils shell

Enter command.

Enter command: ping

Below are the list of possible commands that can be executed from shell:


    dig           
    ping          
    ping6         
    tracepath     
    tracepath6    
    traceroute    
    traceroute6

This example shows running a command from shell:

appliance-1# system diagnostics net-utils shell
 
Please use any of listed commands : ['ping', 'ping6', 'traceroute', 'traceroute6', 'tracepath', 'tracepath6', 'dig'].
 
Enter exit to return to CLI.
 
For detailed help enter command -h. Example: ping -h
 
Enter command: ping -c 4 www.google.com
 
PING www.google.com (142.250.217.681 56(84) bytes of data.
 
64 bytes from sea09s29-in-f4.1e100.net (142.250.217.68): icmp_seq=1 tt1=54 time=72.6 ms
 
64 bytes from sea09s29-in-£4.1100.net (142.250.217.68) : icmp_seq=2 tt1=54 time=72.7 ms
 
64 bytes from sea09s29-in-f4.1100.net (142.250.217.68) : icmp_seq=3 tt1=54 time=72.3 ms
 
64 bytes from sea09s29-in-f4.1e100.net (142.250.217.68): icmp_seq=4 tt1=54 time=72.1 ms
 
 
 
--- www.google.com ping statistics ---
 
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
 
rtt min/ava/max/mdev = 72.116/72.467/72.733/0.361 ms

Enter 'ctrl+c
' to exit the shell after executing the command in “system diagnostics net-utils shell”. This ensures you go back to the CLI instead of canceling the executing command.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

F5OS-A

Network Settings

Network settings overview

Port groups overview

Configure port groups from the webUI

Configure the mode of a port group from the CLI

Show the state of port groups from the CLI

Port mappings overview

Display port mappings from the webUI

Port profiles overview

Configure a port profile from the CLI

Interfaces overview

Configure interfaces from the webUI

Display and reset interface statistics from the webUI

Configure an interface from the CLI

Show the state of a specific interface from the CLI

Configure Forward Error Correction for the interface from the CLI

Display the state of Forward Error Correction for the interface from the CLI

Link aggregation group (LAG) overview

Create LAGs from the webUI

Modify LAGs from the webUI

Display LACP details from the webUI

Static LAG configuration from the CLI

Configure a static LAG interface from the CLI

Add interfaces to LAG members from the CLI

Associate VLANs with LAG interfaces from the CLI

LACP configuration from the CLI

Create a LAG interface from the CLI

Create an LACP interface from the CLI

Enable LACP on a LAG interface from the CLI

Display LACP state from the CLI

Display LACP interface state from the CLI

Configure LACP logging level from the CLI

Display configuration members from the CLI

Display working members from the CLI

VLAN overview

Create VLANs from the webUI

VLAN listeners overview

Display VLAN listeners from the webUI

Display VLAN listeners from the CLI

IP tunnels overview

IP tunnel configuration from the CLI

Configure GTP tunnels from the CLI

Configure GENEVE tunnels from the CLI

Configure NVGRE tunnels from the CLI

Configure VXLAN tunnels from the CLI

IP tunnel configuration from the webUI

Configure GTP tunnels from the webUI

Configure GENEVE tunnels from the webUI

Configure NVGRE tunnels from the webUI

Configure VXLAN tunnels from the webUI

Reset IP tunnels to default values from the webUI

Link Layer Discovery Protocol (LLDP) overview

Configure LLDP from the webUI

Remove LLDP interfaces from the webUI

Display LLDP details from the webUI

Spanning tree protocol (STP) overview

STP/RSTP/MSTP configuration from the webUI

Configure STP from the webUI

Configure RSTP from the webUI

Configure MSTP from the webUI

STP/RSTP/MSTP configuration from the CLI

Change STP modes from the CLI

Configure STP from the CLI

Configure RSTP from the CLI

Configure MSTP from the CLI

Virtual wire overview

Virtual wire configuration from the CLI

Configure virtual networks from the CLI

Configure the interface/LAG for virtual networks from the CLI

Configure a virtual wire from the CLI

Add a virtual wire to a tenant from the CLI

Virtual wire configuration from the webUI

Configure virtual networks from the webUI