High Availability Considerations For Bottleneck Detection; Detection; Trunking Considerations For Bottleneck Detection; Virtual Fabrics Considerations For Bottleneck Detection - HP StoreFabric SN6500B Administrator's Manual

13
Supported configurations for bottleneck detection

High availability considerations for bottleneck detection

The bottleneck detection configuration is maintained across a failover or reboot; however,
bottleneck statistics collected are lost.
Upgrade and downgrade considerations for bottleneck detection
The bottleneck detection configuration is persistent across firmware upgrades and downgrades.
The sub-second latency criterion parameter settings are not preserved on downgrade to firmware
versions earlier than Fabric OS 7.0.0. If you downgrade and then upgrade back to Fabric OS 7.0.0,
the settings revert to their default values.

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 detection
parameters" on page 384 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.
378 Fabric OS Administrator's Guide
53-1002745-02