Trunking Considerations For Bottleneck Detection; Virtual Fabrics Considerations For Bottleneck Detection; Access Gateway Considerations For Bottleneck Detection; Advanced Bottleneck Detection Settings - HP SN3000B Administrator's Manual

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
on page 305 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.

Advanced bottleneck detection settings

Bottleneck detection uses the concept of an affected second when determining whether a
bottleneck exists on a port. Each second is marked as being affected or unaffected by a latency or
congestion bottleneck, based on certain criteria.
You can use the sub-second latency criterion parameters to refine the criterion for determining
whether a second is marked as affected by latency bottlenecks. For example, you might want to use
the sub-second latency criterion parameters in the following cases:
•
•
•
•
Fabric OS Administrator's Guide
53-1002446-01
You notice an under-performing application, but do not see any latency bottlenecks detected.
You can temporarily increase the sub-second sensitivity of latency bottleneck detection on the
specific F_Ports for this application.
You want greater-than-default (sub-second) latency sensitivity on your fabric, so you set
sub-second latency criterion parameters at the time you enable bottleneck detection.
You want to reduce the number of alerts you are receiving about known latency bottlenecks in
the fabric, so you temporarily decrease the sub-second latency sensitivity on these ports.
You have a latency bottleneck on an ISL that is not at the edge of the fabric.

Advanced bottleneck detection settings

"Changing bottleneck parameters"
13
301