418 Fabric OS Administrator’s Guide
53-1001763-02
Bottleneck detection
18

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.

Trunking considerations for bottleneck detection

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.

Virtual Fabrics considerations for bottleneck detection

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.

Access Gateway considerations for bottleneck detection

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.