Brocade Communications Systems 53-1001763-02 用户手册

下载
页码 586
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 
 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.