Brocade Fabric OS Administrators Guide (Supporting Fabric OS v7.3.0) - Manual (Page 392)

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. Refer to
Changing bottleneck detection
parameters on page 397 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 the Access Gateway. To detect bottlenecks on an Access Gateway, enable
bottleneck detection on the Access Gateway to which the devices are actually connected.
Enabling bottleneck detection on a switch
Enabling bottleneck detection permits both latency and congestion detection. Bottleneck detection is
enabled on an individual switch basis. and Brocade recommends that you enable bottleneck detection
on every switch in the fabric. If you later add additional switches (including logical switches) to the
fabric, you should enable bottleneck detection on those switches as well. When you enable bottleneck
detection on a switch, the settings are applied to all eligible ports on that switch. If ineligible ports later
become eligible, or in the case of a logical switch, if ports are moved to the logical switch, bottleneck
detection is automatically applied to those ports. You can later override these settings on a per-port
basis, as described in
Changing bottleneck detection parameters on page 397.
To enable bottleneck detection, complete the following steps.
1. Connect to the switch and log in using an account with admin permissions.
2. Enter the bottleneckmon --enable command to enable bottleneck detection on all eligible ports on
the switch.
By default, alerts are not sent unless the -alert parameter is included; but you can view a history of
bottleneck conditions for the port. This is described in
Displaying bottleneck statistics on page 404.
3. Repeat step 1 and step 2 on every switch in the fabric.
NOTE
Best practice is to use the default values for the alerting and sub-second latency criterion
parameters.
Virtual Fabrics considerations for bottleneck detection
392 Fabric OS Administrators Guide
53-1003130-01