Configuring and Managing AVB

AVB is not enabled in the default configuration, and must be enabled both globally on the switch and on the ports where you want to use it. In the simplest case, when starting with a blank configuration, AVB may be enabled by executing the following two commands:

# enable avb

enable avb ports all

The status of AVB can be seen by using the following command:

# show avb   
gPTP status         : Enabled   
gPTP enabled ports  : *1s     *2m    *10m    *11m    *12m                            
                     *13m    *14m    *15m    *16m    *17m                            
                     *18m    *19m    *20m    *21m           

MSRP status         : Enabled   
MSRP enabled ports  : *1ab    *2ab   *10ab   *11ab   *12ab                           
                     *13ab   *14ab   *15ab   *16ab   *17ab                           
                     *18ab   *19ab   *20ab   *21ab          

MVRP status         : Enabled   
MVRP enabled ports  : *1      *2     *10     *11     *12                             
                     *13     *14     *15     *16     *17    
                     *18     *19     *20     *21            

Flags:        (*) Active,                  (!) Administratively disabled,                 
              (a) SR Class A allowed,      (b) SR Class B allowed,                  
              (d) Disabled gPTP port role, (m) Master gPTP port role,                 
              (p) Passive gPTP port role,  (s) Slave gPTP port role

The show avb command displays high level information about each of the three main protocols (gPTP, MSRP, and MVRP). Each protocol section indicates that all three protocols are enabled both globally, and on ports 1,2 and 11-21. The “*” indicates that we have link on each of the ports.

The gPTP status indicates that port 1 is a slave port, which means that the Grand Master Clock (GMC) is reachable through port 1. The gPTP status also indicates that the rest of the ports are master ports. Furthermore, the fact that no ports are shown to be in the Disabled role means that gPTP is operational on all the ports.

ExtremeXOS provides static AVB configuration with the exception of of Best Master Clock Algorithm (BMCA), which runs as part of gPTP. The BMCA feature adds the ability to disable BMCA and to specify a slave port if desired. When BMCA functionality is on, BMCA is executed normally as described in IEEE 802.1AS. When BMCA is off, BMCA is not executed. In disabled mode, a port can be configured to be the slave-port. If no ports are configured to be slave-port, then the switch will become the Grandmaster Clock and all network-gptp enabled ports will be master ports. The show network-gptp command displays whether BMCA is on or off.

The "ab" on the MSRP status indicates that all ports are members of both the class A and class B domain domains. The MVRP status simply shows which ports are enabled and active.

The user interface for AVB includes the following five protocols:

gPTP
MRP
MVRP
MSRP
FQTSS

The "avb" commands shown above are part of a set of AVB macro commands provided to simplify the process of enabling and disabling AVB. The AVB macro commands have the form:

[ enable | disable | unconfigure ] avb { ports [ all | port_list ] }

Using one of the macro commands is the same as executing the following three commands:

[ enable | disable | unconfigure ] network-clock gptp { ports [ all | port_list ]}

[ enable | disable | unconfigure ] mvrp { ports [ all | port_list ]}

[ enable | disable | unconfigure ] msrp { ports [ all | port_list ]}

MRP does not need to be enabled or disabled, and the only MRP properties that may be configured are timer values. The defaults should be sufficient for most deployments, though it may be necessary to increase the leave-all and leave time values when supporting a large number of streams.

Multiple Registration Protocol/Multiple VLAN Registration Protocol is used for dynamically creating VLANs and/or dynamically adding ports to VLANs. As per IEEE Std 802.1Q-2011, some VLANs can be marked as forbidden VLANs on some ports so that when MVRP PDU is received on the port with the particular forbidden VLAN Id, the VLAN is not created and if the VLAN is already there, the port is not added to the VLAN. This functionality was added in 15.3.2.

Link aggregation allows an increased bandwidth and resilience by using a group of ports to carry traffic in parallel between switches. Multiple ports can be aggregated into one logical port. MVRP can be enabled on the logical port. The MVRP control packets will be transmitted on any available physical port of the LAG. The peer on the other side will receive the packet and process as if being received on the logical port. MVRP supports both dynamic (LACP) as well as static load sharing. Some restrictions that apply are:

The individual ports of the LAG, including the master port, should not have MVRP configuration prior to grouping.
MVRP can be enabled / disabled only on master port. The individual links cannot be configured.
Once sharing is disabled, MVRP configuration of the master port will be lost (default will be disabled).
The statistics and counters shown on the MVRP show commands will be a cumulative counter for all links added together. We do not maintain per link counters.
The actual load sharing of the traffic is beyond MVRP's domain and should take place as per the configured LAG setting. MVRP just adds the LAG port to the VLAN(s).
MVRP only works with Rapid Spanning Tree Protocol [RSTP} and the Default VLAN.User-created STPD instances cannot be associated with the Default VLAN. The Default VLAN is always associated to STPD s0.

MVRP data structure is based on port Instance. All dynamic VLANs created or propagated for a given port will be stored for each port Instance. For normal ports, the port Instance will correspond to the PIF port instance, and for LAG ports, the port Instance will correspond to the LIF port Instance. The port instance is not shown in any of the standard CLI show commands, though it is available as a part of the debug commands. Once MVRP is enabled on the master port, addition / deletion of individual links is supported. MVRP packets received on the newly added link will be accounted instantaneously.

MVRP LAG configuration examples:

enable sharing 13 grouping 13,14,15
enable mvrp port 13
enable sharing 13 grouping 13,14
enable mvrp port 13
configure sharing 13 add ports 15

The VLAN registration is of three types:

Forbidden—Port is forbidden to be added to the VLAN
Normal—Port is allowed to be added to the VLAN
Fixed—Port is statically added to the VLAN

The forbidden / normal setting is only for dynamic addition of ports to VLANs. Any static addition of ports to the VLANs, overrides this setting and marks the status as fixed. The forbidden setting can be used to control MSRP advertisements, in typical scaling scenarios. In addition to support for forbidden VLANs, support for periodic timer and extended-refresh timer has been added in 15.3.2.

The FQTSS settings are managed by MSRP, and may not be configured directly.

The disable commands disable the AVB protocols globally or per port without changing any other configured settings, while the unconfigure commands reset all AVB settings to the initial states, and release all switch resources that were allocated when the protocols were enabled.

More detailed configuration options are provided on a per-protocol basis using the corresponding configure commands:

configure network-clock gptp
configure mvrp 
configure msrp 
configure mrp

If a topology contains redundant connections, ELRP with dynamic VLAN feature should be enabled to prevent data loops in VLANs created by MVRP (see ELRP with Dynamic VLANs). The ELRP with dynamic VLANs feature is supported starting with ExtremeXOS 22.2. In a MVRP-only environment, STP-based loop prevention method is not supported.