Brocade Communications Systems 53-1001763-02 Upgrade and downgrade considerations for bottleneck detection, Trunking considerations for bottleneck detection, Virtual Fabrics considerations for bottleneck detection, Access Gateway considerations for bottleneck detection

418 Fabric OS Administrator’s Guide

53-1001763-02

Bottleneck detection

Upgrade and downgrade considerations for bottleneck detection

The bottleneck detection configuration is persistent across firmware upgrades and downgrades.

If you downgrade to Fabric OS 6.3.x, bottleneck detection is supported; however, the bottleneck

configuration is not applied. You must re-apply the bottleneck configuration after the downgrade.

Additionally, you must use the 6.3.x version of the bottleneck detection commands. In v6.3.x, the

bottleneck commands control the feature on a per-port basis, whereas in 6.4.0 they control the

feature on a per-switch (or per-logical switch) basis, with per-port exclusions and overrides.

Bottleneck detection in v6.3.x does not support E_Ports, FCoE ports, and trunks.

If you downgrade to a firmware version earlier than Fabric OS v6.3.0, bottleneck detection is no

longer supported. If you later upgrade to Fabric OS 6.4.0, the switch attempts to enable the

bottleneck detection settings that were enabled before the downgrade.

A trunk behaves like a single port. Both latency and congestion bottlenecks are reported on the

master port only, but apply to the entire trunk.

For masterless trunking, if the master port goes offline, the new master acquires all the

configurations and bottleneck history of the old master and continues with bottleneck detection on

the trunk.

Bottleneck detection is supported in both VF and non-VF modes.

In VF mode, if a port on which bottleneck detection is enabled is moved out of a logical switch, any

per-port configurations are retained by the logical switch. The per-port configuration does not

propagate outside of the logical switch. If the port is returned to the logical switch, the previous

per-port configurations are automatically set for the port. See “Changing bottleneck alert

parameters” on page 420 for more information about changing per-port configurations.

In logical fabrics, bottleneck detection is not performed on logical ISLs.

Because a base fabric carries traffic from multiple logical fabrics, bottlenecks reported in the base

fabric can be caused by a mixture of traffic from multiple logical fabrics or by traffic from a single

logical fabric. It is not possible to attribute a base fabric bottleneck to the exact logical fabric

causing it. Dedicated ISLs are exclusive to one logical fabric, and any bottleneck on a dedicated ISL

E_Port pertains entirely to the traffic of that logical fabric.

If bottleneck detection is enabled on a logical switch with some F_Ports connected to an Access

Gateway, you do not get information about which device is causing a bottleneck, because devices

are not directly connected to this port. To detect bottlenecks on an Access Gateway, enable

bottleneck detection on the Access Gateway to which the devices are actually connected.