Brocade Communications Systems 53-1001763-02 사용자 설명서
Fabric OS Administrator’s Guide
427
53-1001763-02
Supported hardware
19
Supported hardware
Trunking is supported on the FC ports of all Brocade platforms and blades supported in Fabric OS
v6.4.0.
v6.4.0.
Recommendations for trunking groups
To identify the most useful trunking groups, consider the following recommendations along with the
standard guidelines for SAN design:
standard guidelines for SAN design:
•
Evaluate the traffic patterns within the fabric.
•
Place trunking-capable switches adjacent to each other.
This maximizes the number of trunking groups that can form. If you are using a core and edge
topology, place trunking-capable switches at the core of the fabric and any switches that are
not trunking-capable at the edge of the fabric.
This maximizes the number of trunking groups that can form. If you are using a core and edge
topology, place trunking-capable switches at the core of the fabric and any switches that are
not trunking-capable at the edge of the fabric.
•
When connecting two switches with two or more ISLs, ensure that all trunking requirements
are met to allow a trunking group to form.
are met to allow a trunking group to form.
•
Determine the optimal number of trunking groups between each set of linked switches,
depending on traffic patterns and port availability.
The goal is to avoid traffic congestion without unnecessarily using ports that could be used to
attach other switches or devices. Consider these points:
depending on traffic patterns and port availability.
The goal is to avoid traffic congestion without unnecessarily using ports that could be used to
attach other switches or devices. Consider these points:
-
Each physical ISL uses two ports that could otherwise be used to attach node devices or
other switches.
other switches.
-
Trunking groups can be used to resolve ISL oversubscription if the total capability of the
trunking group is not exceeded.
trunking group is not exceeded.
•
Consider how the addition of a new path will affect existing traffic patterns:
-
A trunking group has the same link cost as the master ISL of the group, regardless of the
number of ISLs in the group. This allows slave ISLs to be added or removed without
causing data to be rerouted, because the link cost remains constant.
number of ISLs in the group. This allows slave ISLs to be added or removed without
causing data to be rerouted, because the link cost remains constant.
-
The addition of a path that is shorter than existing paths causes traffic to be rerouted
through that path.
through that path.
-
The addition of a path that is longer than existing paths may not be useful because the
traffic will choose the shorter paths first.
traffic will choose the shorter paths first.
•
Plan for future bandwidth addition to accommodate increased traffic.
For trunking groups over which traffic is likely to increase as business requirements grow,
consider leaving one or two ports in the group available for future nondisruptive addition of
bandwidth.
For trunking groups over which traffic is likely to increase as business requirements grow,
consider leaving one or two ports in the group available for future nondisruptive addition of
bandwidth.
•
Consider creating redundant trunking groups where additional ports are available or paths are
particularly critical.
This helps to protect against oversubscription of trunking groups, multiple ISL failures in the
same group, and the rare occurrence of an ASIC failure.
particularly critical.
This helps to protect against oversubscription of trunking groups, multiple ISL failures in the
same group, and the rare occurrence of an ASIC failure.
•
To provide the highest level of reliability, deploy trunking groups in redundant fabrics to further
ensure that ISL failures do not disrupt business operations.
ensure that ISL failures do not disrupt business operations.