Modulos de 1 Al 5 BPSA300 PDF

BPSA 300
Brocade Professional SAN

Administrator
Student Guide
Revision 0816
Brocade Professional SAN Administrator
Corporate Headquarters - San Jose, CA USA

T: (408) 333-8000
info@brocade.com
European Headquarters - Geneva, Switzerland

T: +41 22 799 56 40
emea-info@brocade.com
Asia Pacific Headquarters - Singapore

T: +65-6538-4700
apac-info@brocade.com
© 2016 Brocade Communications Systems, Inc. All Rights Reserved.
ADX, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, HyperEdge,
ICX, MLX, MyBrocade, OpenScript, The Effortless Network, VCS, VDX, Vplane, and
Vyatta are registered trademarks, and Fabric Vision and vADX are trademarks of Brocade
Communications Systems, Inc., in the United States and/or in other countries. Other
brands, products, or service names mentioned may be trademarks of others.
Notice: This document is for informational purposes only and does not set forth any
warranty, expressed or implied, concerning any equipment, equipment feature, or service
offered or to be offered by Brocade. Brocade reserves the right to make changes to this
document at any time, without notice, and assumes no responsibility for its use. This
informational document describes features that may not be currently available. Contact a
Brocade sales office for information on feature and product availability. Export of technical
data contained in this document may require an export license from the United States
government.
Revision: August, 2016

BPSA 300 Course Introduction
Revision 0816 1–1

Revision 0816 1–2

Revision 0816 1–3

Revision 0816 1–4

Revision 0816 1–5

Revision 0816 1–6

Revision 0816 1–7

Revision 0816 1–8

Facebook — Brocade Certified

http://www.facebook.com/brocadecertified
LinkedIn — Brocade Certified

http://www.linkedin.com/groups?gid=3752161&trk=hb_side_g
MyBrocade Brocade University Community

http://community.brocade.com/community/forums/education
MyBrocade Certification Community

http://community.brocade.com/community/forums/education/certification
MyBrocade Education Alumni Community

http://community.brocade.com/community/forums/education/alumni
Revision 0816 1–9

Revision 0816 1 – 10
BPSA 300 FC-FC Routing Theory
Revision 0816 2–1

Revision 0816 2–2

Footnote 1: FC-FC routing supports the following configurations:

• FC router connected to a Fabric OS nonsecured edge fabric.
• FC router connected to a Fabric OS secured edge fabric.
• FC router connected to a Brocade Network OS VCS edge fabric (Fabric OS v7.0.1 and
Network OS v2.1.1 or later). For more information on the VCS Fabric refer to the EFSA-300
course.
Revision 0816 2–3

FC-FC routing is also known as FCRS (Fibre Channel Routing Service), FC-to-FC routing,
FCR, FC routing, and routed SANs.
Footnote 1: Includes implementing and configuring the underlying physical connectivity
between the fabrics that share devices using EX_Ports or Inter Fabric Links (IFL).
The FC router in effect enforces an implied “DENY_ALL”, and the administrator must
configure the “PERMIT” entries (ACLs) through LSAN zoning.
Revision 0816 2–4

Footnote1: Interopmode is no longer supported on E_Ports beginning with Fabric OS v7.0,

but is allowed on EX_Ports. Beginning with Fabric OS 7.1, EX_Ports only support the
following modes:
• Brocade Native Mode (IM0)
• Brocade NOS Fabric Mode (IM5)
Revision 0816 2–5

Footnote 1: In an FC-FC routed environment, when an RSCN is generated regarding a

member of the LSAN zones (for example, RSCN in edge FID1), the FCR sends an RSCN to
edge FID 2 LSAN members regarding the proxy (imported) device.
Revision 0816 2–6

Revision 0816 2–7

The diagram on this slide illustrates each router representing a simple backbone fabric in
the routed fabric. There is no E_Port to E_Port connectivity between the two routers.
Revision 0816 2–8

Revision 0816 2–9

The diagram on this slides illustrates each router representing a simple backbone fabric in the
routed fabric. There is no E_Port to E_Port connectivity between the two routers.
Footnote 1: In the backbone fabric, FC routing and Virtual Fabrics (VF) share the same pool
of FIDs. When VF is enabled on the FC router, the FC router backbone fabric and Virtual
Fabric base switch configured in the backbone fabric share the same FID, all other logical
switches within the backbone fabric must not reuse FIDs assigned by the FC routing service.
Edge fabrics use separate FIDs for VF and FC routing. The FC router in the backbone
assigns an edge fabric FID with the edge fabric having no awareness of the FC routing FID
assigned to it. This allows FIDs used for VF in an edge fabric to overlap with FIDs used in the
backbone fabric or other edge fabrics
Footnote 2: Backbone FIDs can be administratively configured using the fcrconfigure

command. It is necessary to use the fosconfig --disable fcr command prior to using
the fcrconfigure command. Note - The switch must be disabled using the
switchdisable command in order to run fosconfig --disable fcr.
Edge fabric FID values can only be viewed from the switchshow output of the router (not on
the edge fabric). Each EX_Port displays the assigned FID value.
Virtual Fabrics is covered in a separate module in this class.
Footnote 1: In the backbone fabric, FC routing and Virtual Fabrics (VF) share the same pool
of FIDs. When VF is enabled on the FC router, the FC router backbone fabric and Virtual
Fabric base switch configured in the backbone fabric share the same FID, all other logical
switches within the backbone fabric must not reuse FIDs assigned by the FC routing service.
Edge fabrics use separate FIDs for VF and FC routing. The FC router in the backbone
assigns an edge fabric FID with the edge fabric having no awareness of the FC routing FID
assigned to it. This allows FIDs used for VF in an edge fabric to overlap with FIDs used in the
backbone fabric or other edge fabrics.
Footnote 2: Router ports can connect to a logical switch that is in the same chassis or in a
different chassis. However, the following configuration rules apply:
• If the logical switch is on the same chassis, the EX_Port FID (the FID assigned by the
routing service to the edge fabric) must be set to a different value than the FID of the logical
switch to which it is connecting.
• If the logical switch is on a different chassis, no FID for any logical switch in the FC router
backbone fabric can be the same as the FID of the logical switch to which the EX_Port is
connecting.
From the point of view of a switch in an edge fabric, an EX_Port is virtually indistinguishable
from any other Brocade E_Port. It follows all applicable Fibre Channel E_Port standards,
therefore a switch connecting to an EX_Port runs in standard E_Port mode.
Recall that nothing is required to change in the existing edge fabric (SAN islands) to allow FC
routing to occur. Commands such as fabricshow display all domains participating in the
edge fabric.
Footnote 1:
router:admin> portcfgexport
Usage: portcfgexport [SlotNumber/]PortNumber
[-a 1-enable 2-disable] [-f fid(1..128)]
[-r r_a_tov] [-e e_d_tov] [-d domain]
[-p 0-native 1-core 2-extended edge]
[-m 0-Brocade 5-Brocade NOS fabric]
[-t 1-Enable 2-Disable]
The portcfgexport command is used to configure a FC port as an EX_Port. The command
has a single required argument – the port on which the command is to operate – and several
optional parameters:
-a: Sets the port to be enabled (1) or disabled (2).
-f: Fabric ID (1-128) for the edge fabric attached to this port; default value is
the port number divided by 3 plus 2 rounded down.
-r: R_A_TOV used for port negotiation, in msecs (2000 - 12000). Default:
10000.
-e: E_D_TOV used for port negotiation, in msecs (1000 - 60000). Default:
2000.
-d: Preferred front domain ID (1-239). Default: 160.
-p: Port ID format of the edge fabric (1-core, 2-extended edge, 3-native).
Default: Core PID.
-t: Auto-negotiate fabric parameters (1-enable, 2-disable). Default: enabled.
-m Port mode - The -m option enforces the same port mode for all the ports
connected to the same edge fabric.
-i Enables or disables Insistent Domain Id (IDID) for the specified EX_Port
The command displays the currently configured values for the specified port when no optional
parameters are specified.
Footnote 2:
• The addition of an IFL (creation of an EX_Port) between the router and the edge fabric
does not cause the fabrics to merge.
• When all IFLs are removed, FOS detects this condition and forwards an RSCN to the
applicable remote fabrics.
• The removal of an IFL does not introduce a fabric reconfiguration on the edge fabric.
• The owner IFL has a special role: It is the IFL that performs the RDI (request domain ID)
for the translate domain when it comes online. The owner IFL can be viewed through the
OwnerDid field using the fcrxlateconfig command.
• All exported devices from one remote routed fabric are “hanging off” just one translate
domain (xd) on the local fabric. For each remote routed fabric that shares (imports)
physical devices, a separate and distinct translate (xlate) domain (virtual domain) is
created in the local fabric.
An LSAN is implemented using LSAN zoning which includes devices from two or more routed
fabrics.
An LSAN zone defines device communication between autonomous SANs, but only allows
designated devices in those SANs to communicate. They are defined in each fabric, edge or
backbone, that will share devices (devices that will be exported and imported).
Zone names are not case sensitive, e.g. “LSAN_”, or “lsan_”, or “LSan_”. LSANs are
configured in the same way as standard zones and are subject to normal zoning enforcement.
LSAN zones are compatible with Fabric OS and Network OS environments. FC router uses
LSAN defined zones to determine which devices need to be imported into which routed
fabrics. LSAN zones must be configured in fabrics where the physical devices exist. The
router performs zoning enforcement for edge fabrics at the ingress router EX_Port.
Footnote 1: A front domain represents the router in an edge fabric. Front domains are not
created in a backbone fabric. Instead, they are a tier domain between the translate domains
(xd) and the edge fabric. Imported devices are not attached to front domains, they are
attached to translate domains . FDs do not have a scalability effect. Virtual links between front
and translate domains do not count as hops in hop-count limitations.
Footnote 2: Translate Domain is a logical domain created in routed fabrics that share
devices. They are created in edge or backbone fabrics, but only created when physical
devices in both fabrics requiring an xd are online and are part of an LSAN zone in two or more
fabrics. Only one xd exists for each remote routed fabric. Xds exist in the backbone when
devices from an edge fabric are imported into the backbone fabric (backbone-to-edge
routing). FC-NAT is used to logically attach imported devices to the xd. A preferred domain ID
(DID) is the requested DID, but not an insistent domain ID (IDID). The standard Request
Domain ID (RDI) process occurs and if the preferred (xlate) domain ID is not already assigned
to some other domain, the principal switch assigns the requested domain ID. Otherwise, the
principal switch replies with the next available domain ID. It is recommended to configure a
preferred translate domain ID that is the same value as the FID value of the remote edge
fabric that the domain ID is representing. This would require planning, and is more readily
achievable in new installations.
Once a translate domain is created, it remains in the fabric until the associated EX_Ports are
disabled or enabled, even after the devices are no longer shared. In larger environments this
may consume unwanted DIDs.
The terms export and import are based on the view of the edge fabric. Physical devices in a
fabric need to be exported out of a fabric; and the logical device representing the physical
device needs to be imported to the remote fabric.
BB_G620:admin> lsanzoneshow -s
Fabric ID: 1 Zone Name: LSAN_Edge1
10:00:00:05:1e:57:7c:79 EXIST
22:00:00:20:37:dd:d9:29 Imported
Fabric ID: 2 Zone Name: lsan_edge2
10:00:00:05:1e:57:7c:79 Imported
22:00:00:20:37:dd:d9:29 EXIST
Note: EXIST = local physical device to be exported and
Imported = remote fabric device that was imported.
Fibre Channel Router Protocol (FCRP): A Brocade-authored Layer 3 routing protocol with
two distinct components:
• FCRP Edge Fabric Protocol
• Forms EX_Ports
• FCRP Backbone Fabric Protocol
• Forms NR (Node Router) Ports
In addition to FC routers being able to communicate using FCRP within the backbone fabric,
EX_Port on the router enable FCRP Edge Fabric protocol communication across the EX_Port
IFLs, e.g. the Brocade routers communicate through Layer 3 FCRP protocol through the edge
fabrics IFLs.
The FC Router receives the frames addressed to the local FID1 fabric PID representing the
storage and translates the local PID to the remote address FID2 PID and forwards the traffic.
In FID1, the logical storage device appears in the fabric local to the host. The host addresses
frames to a local fabric PID which represents the storage.
In FID2, the logical host device appears in the fabric local to the storage. The storage
addresses frames to a local fabric PID which represents the host.
DPR = Destination Router Port

Footnote 1: A VE_Port (Virtual E_Port) is a Fibre Channel over IP (FCIP) ISL. A VEX_Port is
an FCIP router port. FCIP is discussed in a later modules
Footnote 2: In this example, all three EX_Ports have a router port cost of 1000, even though
EX_3 is on the other side of an FCIP link. This is because router port cost is based on the
type of router port (EX vs VEX) and does not take into consideration the FSPF link costs in-
between the router ports. In this case traffic from Fabric 1 to Fabric 2 will be load shared
between router ports EX_2 and EX_3.
Footnote 3: The FC router port cost is set automatically. You can modify the cost for a port if
you want to change the default value.
The FC router port cost settings are 0, 1,000, or 10,000. If the cost is set to 0, the default cost
will be used for that IFL. The FC router port cost is persistent and is saved in the existing port
configuration file.
FC router port cost is passed to other routers in the same backbone. Link costs from the front
domain to the translate (xlate) domain remain at 10,000. You can use the lsDbShow and
urouteshow command from the edge fabric to display these link costs.
Notes continued on next page
The router port cost has the following considerations:

• Router port sets are defined as follows:
o 0-7 and FCIP Tunnel 16-23
o 8-15 and FCIP Tunnel 24-31
• The router port cost does not help distinguish one IFL (or EX_ and VEX_Port link) from
another, if all the IFLs are connected to the same port set. Therefore, if you connect IFL1
and IFL2 to the same edge fabric in port set 0-7 and then configure them to different router
port costs, traffic is still balanced across all the IFLs in the same port set.
• Use proper SAN design guidelines to connect the IFLs to different port sets for effective
router port cost use. For example, if both a low-speed IFL and a high-speed IFL are going
to the same edge fabric, connect the lower router cost IFL to a separate port group (for
example, ports 0-7) than the higher router cost IFL (for example, ports 8-15). For
VEX_Ports, you would use ports in the range of 16-23 or 24-31.
Footnote 1: The router port cost value for an EX_Port is set automatically when the EX_Port
is created. You can modify the cost for that port to force a path to have a higher or lower cost.
You can configure the EX_Port or VEX_Port with values of either 1,000 or 10,000. For
example, if you want to differentiate between two EX_Port links with different speeds, you can
assign 1,000 to one link and 10,000 to the other link.
Footnote 2: Routing decisions are made in each local fabric. Edge Fabric 2 uses its local
FSPF link state database to build routes to the front domain and translate domains presented
into the edge fabric.
Footnote1: The Shortest IFL Selection feature is disabled by default.

Footnote2: A domain in an edge fabric can choose any equal cost path to reach the translate
domain, frames can be transmitted on FCIP links even though FC links are present in the
backbone fabric.
In this example, the devices that are present in Edge Fabric 1 Domain 1 are Host 12 and 13, if
they want to talk to Edge fabric 3 Domain 3, target 2, the traffic will be sprayed on all the front
domains that are available in the edge fabric. That is, the traffic may take front domain 160 to
reach target 2 or it can take front domain 150 to reach target 2. This is because, in previous
releases, we have advertised that the cost between the front domain and the translate domain
as 10,000.
In v7.2.0, the traffic will use the path with the fewest hops through the backbone fabric..
The cost between FCR 1 and FCR 2 is 5000 and the link cost between FCR 2 and FCR 3 is
5000. If the cost is maintained to be equal or greater than 10000, that path will not be used for
sending the traffic because of the advertised cost between the front domain 160 and the
translate domain 3. This is dependent upon the cumulative cost between FCR 1 and FCR 3
which is 10K. If you have the total cumulative cost as 10K, then your cost between the front
domain and the translate domain will be 10001. In this scenario, the other front domain 150 to
the translate domain 3 is still with 10000 and the traffic will be routed from FCR 4 through
FCR 3 and then it will reach target 2. In this example, it is the base switch alone. If the
shortest IFL is fully utilized, the traffic will not go on any other IFL.
The links FCR 1, 2, 3, and 4 can be connected using either ISL or ICLs: all are in the
backbone.
Footnote 1:
Integrated Routing: Allows any ports in Brocade 6510, 6520, and 7840 switches, and DCX
8510 and Brocade G620 switch family platforms to be configured as an EX_Port supporting
FC-FC routing.
Integrated Routing Ports on Demand: On Brocade X6 Director family, allows any port, within
the license capacity limit, to be configured as an EX_Port supporting FC-FC routing. If the
maximum limit of EX_Ports that can be enabled is reached, enabling a new EX_Port will fail
with the warning message "Ex_Port IR POD License Limit Exceeded" and the port will be
disabled. NOTE Applies to Brocade Gen X6 Directors only with Fabric OS 8.0.1..
Footnote 2: Not supported on:
• FC10-6 10 Gbps blade
• Brocade 6505
• All 4 Gbps switches and blades except the Brocade 7500 and FR4-18i
• All embedded switches both 8, 16 and 32 Gbps
• Copper (8 Gbps) ICL ports, optical ICL ports require Fabric OS v7.2.0 or later
Footnote 3: Check corresponding Release Notes for latest information
Footnote 4: FC8 are 8G port blades, FC16 are 16 Gbps port blades, FC32 are 32G port
blades. FC routing over FCIP ports, VEX_Ports , is supported on the FX8-24 blade and
Brocade 7840 switch.
Notes continued on next page
• 8-Gbps port blades (FC8-16, FC8-32, FC8-32E, FC8-48, FC8-48E,

FC8-64, FX8-24)
• 16-Gbps port blades (FC16-32, FC16-48)
• 32-GBPS port blades ???
Footnote 5: Use the fosconfig –-enable fcr to enable FC-FC routing.

FX8-24: When an FX8-24 blade is inserted, all of its Fibre Channel ports are persistently
disabled by default.
Footnote 1: Lowest back-end port number becomes new master port, not the lowest front-
end switch port number (normal user port). The back-end port number is used by the ASIC
for the associated front-end switch port number and are different (may be higher or lower).
Fabric OS v6.1 and v6.2 use master port trunking of EX_Ports. When a master port goes
offline, slave ports in the trunk go offline and online to select the new master port.
Footnote 1: EX-Port on ICL is supported only when all the port blades in the chassis belong
to one of these blade types: FC16-32, FC16-48, FC32-48).
Footnote 2: All four ports in same QSFP must be disabled prior to EX_port configuration.
Configuring an EX_Port (enable/disable) on one ICL QSFP port will replicate the configuration
to remaining QSFP ports.
Footnote 3: A symmetric topology has to be maintained between two switches with
redundant links from each core blade to each of the neighbor switch core blades. All of the
user ports in an ICL cable must be connected to the same logical switch. QSFP ports should
not be split across logical switches and connect to different edge switches.
Additional Considerations:
• ICL license is required for ICL and ICL EX_port support.
• The FCR must be in Brocade native mode.
• It is not possible to configure an VEX_Port on an ICL.
• Both the active and standby CP must be running Fabric OS 7.2.0 or later.
With LSAN zone binding, FC Router 1 will process all LSAN zones for Edge Fabric 1, 2, and
3, but not 4. FC Router 2 will process all LSAN zones for Edge Fabric 1, 3, and 4, but not 2.
Footnote 1: The size of this database limits the number of FC routers and devices. Without
LSAN zone binding, the maximum number of LSAN devices is 10,000. With LSAN zone
binding the FC-FC routed fabric can import more than 10,000 devices, the backbone fabric
can support more FC routers, and CPU consumption by an FC router is lower.
Footnote 2: LSAN zone binding uses an FC router matrix that specifies pairs of FC routers in
the backbone fabric that can access each other, and an LSAN fabric matrix that specifies
pairs of edge fabrics that can access each other.
You set up LSAN zone binding using the fcrLsanMatrix command. This command has two
options: -fcr and -lsan. The -fcr option is for creating and updating the FC router matrix,
and the -lsan option is used for creating and updating the LSAN fabric matrix. The FC router
and LSAN fabric matrix databases are automatically distributed to all FC routers in the
backbone fabric.
fcrlsanmatrix --add -fcr <WWN1> <WWN2>
fcrlsanmatrix --add -lsan <FID1> <FID2>
fcrlsanmatrix --apply –all
FC Routers running Fabric OS v6.1 and later perform automatic distribution. Prior to Fabric
OS v6.1 the matrix is local only and requires each router to be manually set to the same
matrix.
Footnote 1: Supported on both 4Gbps and 8Gbps router platforms running Fabric OS v6.2 or
later.
Footnote 2: LSAN tags are added, removed, and viewed from the FC router using the
fcrlsan command:
router:admin> fcrlsan --help
Usage: fcrlsan [--add -enforce | -speed <tag>]
[--remove -enforce | -speed <tag>]
[--show -enforce | -speed | -all]
[--help]
Create an enforce LSAN tag: fcrlsan --add –enforce <tag>
Create a speed LSAN tag: fcrlsan --add –speed <tag>
Display the current enhancement/speed LSAN tags:

fcrlsan –-show –enforce | speed <tag>
Delete an enhancement or speed LSAN tag:

fcrlsan –-delete –enforce | speed <tag>
Delete all enhancement or speed LSAN tags:

fcrlsan –-delete –enforce | speed
FC Router 1 has enforce tags Enf1, Enf2 and Enf3 defined and will only process LSAN zones
that use the Enf1, Enf2 or Enf3 tag. FC Router 1 will only process a subset of LSAN zones
from Edge Fabric 3 and 4. FC Router 2 has enforce tags Enf2, Enf3 and Enf4 defined and will
only processes LSANs that use the Enf2, Enf3 or Enf4 tag. FC Router 2 will only process a
subset of LSAN zones from Edge Fabric 1 and no LSAN zones from Edge Fabric 2.
Steps to set up this configuration:
1. On Router 1 create three enforce tags; in this example they are called Enf1, Enf2, and
Enf3.
2. On Router 2 create three enforce tags; in this example they are called Enf2, Enf3, and
Enf4.
3. In Edge Fabric 1 create LSAN zones using the three enforce tags Enf1, Enf2, and Enf3, in
this example they are LSAN_Enf1_F1-F2, LSAN_Enf2_F1-F3, and LSAN_Enf3_F1-F4.
4. In Edge Fabric 2 create an LSAN zone using the enforce tag Enf1 only; in this example it
is LSAN_Enf1_F1-F2.
5. In Edge Fabric 3 create LSAN zones using the two enforce tags Enf2 and Enf4; in this
example they are LSAN_Enf2_F1-F3 and LSAN_Enf4_F3-F4.
6. In Edge Fabric 4 create LSAN zones using the two enforce tags Enf3 and Enf4; in this
example they are LSAN_Enf3_F1-F4 and LSAN_Enf4_F3-F4.
Footnote 1: Speed tags: Certain hosts are very sensitive to timeout and retry during target
discovery process. FC router tends to take a long time, more than five seconds, to present
proxy devices and setup path for proxy devices. Due to hardware and protocol constraints,
the FC router is unable to improve the import and export process to satisfy those sensitive
hosts. FC router treats speed tagged LSANs differently by always importing these targets to
the hosts. The status of these targets in the speed tagged LSANs remains Imported and the
name server in the host fabric will always retain a PID for them. This allows sensitive hosts to
do discovery faster for these targets.
Steps to set up this configuration:
1. Create a speed tag on the FC router, in this example FAST.
2. In Edge Fabric 1 create an LSAN zone containing the host and target, in this example
LSAN_zone1.
3. In Edge Fabric 2 create an LSAN speed tag zone containing the host and target, in this
example LSAN_FAST_zone1 (target, host).
When the target comes online in Fabric 2, the proxy target is immediately imported into
Edge Fabric 1, no matter the host state.
Footnote 2: Speed and Enforce tags cannot be used simultaneously on the same router.
When Enforce tags are defined on a switch, normal lsan zones (non-tagged lsan zones) are
ignored. If an Enforce tag is defined on the router, only Enforce tagged LSAN zones and
Speed tagged LSAN zones are imported by the router. If an Enforce tag is not defined on the
router, only normal LSAN zones and speed tag LSAN zones are imported by the router. A
router will never import both normal untagged LSAN zones and Enforce tagged LSAN zones;
it’s one or the other, but Speed tags can be used with both.
BPSA 300 FC-FC Routing Administration
Revision 0816 3–1

Revision 0816 3–2

Revision 0816 3–3

In this example FC routing service is disabled (default setting) and Virtual Fabrics is disabled.
Revision 0816 3–4

Revision 0816 3–5

Use the fddcfg (Fabric Data Distribution configuration) command to verify and specify the
fabric-wide consistency policies:
BB_G620:admin> fddcfg --showall

Local Switch Configuration for all Databases:-
DATABASE - Accept/Reject
---------------------------------
SCC - accept
DCC - accept • Tolerant policies display: "SCC; DCC“
PWD - accept • Strict policies display: "SCC:S; DCC:S“
FCS - accept • A strict SCC and a tolerant DCC policy
output displays: "SCC:S; DCC"
AUTH - accept
IPFILTER - accept
Fabric Wide Consistency Policy:- ""
Revision 0816 3–6

Preparing Fabrics for Routing (cont.)

To manage the consistency of the SCC and DCC databases across the fabric, there is a
Fabric Wide Consistency Policy. This policy defines whether the Switch Connection Control
(SCC) and Device Connection Control (DCC) databases are distributed automatically or
manually when a database changes or a new switch joins a fabric. The SCC database
determines which switches will be allowed to join the fabric. The DCC database determines
which devices will be allowed to attach to a switch. These databases are called ACL
databases.
There are three levels of fabric-wide consistency that can be specified for the SCC and DCC
databases:
1. Not defined (absent): Fabric-wide consistency policy is not defined (default). A switch that
has an absent fabric-wide policy can have ACL databases. These ACL databases can be
changed by a manual distribution from another switch.
2. Tolerant: Switches are not required to have the same ACL databases. Switches with
absent and tolerant policies can be part of the same fabric. This provides greater flexibility
for pre-Fabric OS v5.2 and non-Fabric OS switches. Switches can have the same,
different, or no ACL databases. The switch SCC policies in each fabric must contain all
switches in the combined fabric. The switch DCC policies in each fabric must contain all
the devices attached to expected switches in each fabric. Given the above—If a switch has
a different database from the rest of the fabric, it remains in the fabric. SCC and DCC
database distribution is automatic; when a database is changed on any switch, that
database is automatically distributed to the rest of the fabric.
3. Strict: Switches in the fabric always have the same ACL databases/ Ensures that SCC
and DCC policies are consistent on all switches in a fabric. To join a fabric, a new switch
must have exactly the same SCC and DCC databases as the rest of the fabric – or no
database at all. SCC and DCC database distribution is automatic. If a new switch joins the
fabric with no database, the ACL database in the existing fabric is automatically written to
the new switch. When a database is changed on any switch, that database is automatically
distributed to the rest of the fabric. If one switch in a fabric has a strict policy, all switches
in the fabric must also have a strict policy.
Revision 0816 3–7

Footnote 1: Before setting the fabric ID in the backbone fabric, the FC routing service must
be disabled if it was previously enabled. The fosconfig --disable fcr command
disables the upper layer FC Routing Service in Fabric OS while the Layer 2 switching remains
enabled. The command has no arguments or optional parameters. In the example above, the
FC routing service was in the default disabled state.
When using the fosconfig --disable fcr command, keep these considerations in
mind:
• All EX_Ports on the switch must first be disabled (portdisable or bladedisable).
• The switchdisable command must also be run before the FC routing service can be
disabled.
• Display the current state of the FC Routing service with the familiar switchshow
command.
The fcrconfigure command configures the fabric ID of the backbone Fabric. The
command is menu-driven, and has no arguments or optional parameters. The Fabric OS
default fabric ID value is 1; as shown above, the fabric ID has been set to 100.
The fosconfig --enable fcr command enables the FC Routing Service in Fabric OS.
With VF enabled, the backbone fabric and default switch use the same FID.
Revision 0816 3–8

Footnote 1: The example on this slide persistently disables port 3 and then configures it as
an EX_Port. Use the portcfgvexport command to configure routing over an FCIP tunnel.
Footnote 2: The portdisable command can also be used, but is not recommended. All
FC ports on the Brocade FR4-18i and Brocade 7500 are persistently disabled at the factory.
Footnote 3: Port modes include interoperability modes. See -m portmode parameter
below.
Footnote 4: If the front domain ID is not specified the default domain ID assigned to the first
FD in an edge fabric is 160.
Revision 0816 3–9

The portcfgexport command is used to place an FC port into EX_Port mode

portcfgexport [slotnumber/]portnumber [-a admin] [-f fabricid] [-r
ratov] [-e edtov] [-d domainid] [-p pidformat] [-t fabric_parameter]
[-m portmode]
Required argument: slotnumber/portnumber.
Optional arguments:
-a admin Specify whether to (1-enable, 2-disable) this port as an EX_Port. If 2 is
specified, the port will not be disabled, but will no longer be configured as an EX_Port.
portcfgdefault can also be used to disable EX_Port mode.
-f fabricid Specify the fabric ID. Valid values are 1-128.
-r ratov Specify the R_A_TOV used for port negotiation. Valid values are 2000 -
120000.
-e edtov Specify the E_D_TOV used for port negotiation. Valid values are 1000 - 60000.
-t fabric_parameter Specify whether to (1-enable, 2-disable) negotiation of
the fabric parameters RA_TOV and ED_TOV.
-d domainid Specify the preferred domain ID. Valid values are 1-239.
-p pidformat Specify the Port ID format. (0-native, 1-core, 2-extended
edge). This operand is applicable only when port mode is set to 0 (Brocade Native mode).
-m portmode Specify the Port mode (0: Brocade Native mode, 5: Brocade Network OS)
If no optional arguments are specified, the current port configuration will be displayed.
Note: The portcfglongdistance command may be used to place an EX_Port in long-
distance mode. An Extended Fabrics license is required.
In the example above, port 3 on the Brocade 5100 is configured with the following settings:
EX_Port Mode: Enabled
Fabric ID: 10
Front Phantom:
State: OK WWN is assigned from a pool of
Current Domain ID: 120 WWNs by the FC router to
WWN: 50:00:51:e7:e2:62:ee:0a represent the EX_Port front
domain
Fabric parameters:
R_A_TOV: 10000
E_D_TOV: 2000
PID format: core
Footnote 1: EX_Port trunks appear as E_Port trunks in the edge fabric. E_Port trunking is
implemented using the switchshow, trunkshow, portcfgtrunkport, and
switchcfgtrunk commands. Trunking is enabled by default.
Footnote 2: Although multiple IFLs may link a single router to an edge switch, only one front
domain is presented to the edge fabric on behalf of that router.
Footnote 3: The number 5 in the first nibble of the WWN shows that this is a logical device
and does not physically exist. The following 00:05:1e is Brocade’s OUI.
Footnote 1: The tools used to configure LSAN zoning are irrelevant - use your favorite tool.
The important point is that the LSAN zones exist in each fabric, and are being enforced within
the fabric as part of the effective configuration (Fabric OS).
The lsanzoneshow command will display all currently-active LSAN zones that the backbone
fabric is enforcing.
lsanzoneshow [-s] [-f fabricID] [-w wwn] [-z zonename] [-d | -
deviceinfo] [-o | -sort]
Search parameters -f, -w, and -z allow searching for LSAN zones based on fabric ID, WWN of
an LSAN zone member, or LSAN zone name.
-f fabricID: Display LSAN zones in the specified fabric.
-w wwn: Display LSAN zones containing the specified port
WWN. (Format XX:XX:XX:XX:XX:XX:XX:XX)
-z zonename: Display LSAN zones with the specified zone name.
-s state: Display state information for the device, valid states include:
Configured Device is configured to be in an LSAN, but the device is not imported nor
does it exist in this fabric.
EXIST Device exists in this fabric (the fabric of the zone entry).
Initializing Device is in an intermediate state. It is not yet imported into the fabric.
Imported Device has been imported (proxy created) into this fabric.
-d | -deviceinfo: Displays the fabric IDs of the LSAN devices. This command displays
fabric IDs for Imported and EXIST devices. The devices that do
not exist in the corresponding edge fabrics are displayed as configured.
In this example, you can see which devices actually exist in the fabric listed (EXIST) and
which ones are projected into that fabric (Imported), and switch fabric the device was
imported from.
The translate and front domains do not have an Enet IP Addr assigned. This is always the
case since they are logical, not physical, domains.
Footnote 1: When devices are shared with the edge fabric using LSAN zones a translate
domain is added to the local backbone fabric representing the remote edge fabric, but front
domains are not needed as the backbone fabric is router port aware.
In the example on the next page, the switchshow command output includes the following
information related to FC Routing functionality and the newly-created EX_Port:
• The switch is a Brocade G620 (switchType: 162.0).
• The FC router service is enabled (FC router: ON).
• The fabric ID for the backbone (FC router backbone Fabric ID: 100).
• Port 3 is online and configured as an EX_Port connection to the edge fabric
(10:00:00:05:1e:0b:96:8f "Edge_6510" fabric id = 10).
• Because devices are shared between the backbone and the edge a translate domain
(XD) is created in the backbone fabric to display the shared (imported) devices from this
edge fabric. (E-Port 50:00:51:e7:e2:64:ef:02 "fcr_xd_1_10")
To create a trunk, additionally configure and enable ports as EX_Ports to the edge fabric
following all normal trunking requirements. Again verify output using the switchshow
command.
EX_Port Trunking is administered using the same commands as E_Port trunking:
switchshow, trunkshow, portcfgtrunkport, and switchcfgtrunk.
Verify Connectivity – Backbone (cont,)
BB_G620:admin> switchshow
switchName: BB_G620
switchType: 162.0
switchState: Online
switchMode: Native
switchRole: Principal
switchDomain: 98
switchId: fffc62
switchWwn: 10:00:c4:f5:7c:0e:c0:7c
zoning: ON (BB_CFG)
switchBeacon: OFF
FC Router: ON
FC Router BB Fabric ID: 100
Index Port Address Media Speed State Proto

==============================================
0 0 620000 -- N32 No_Module FC
1 1 620100 id N32 No_Module FC
2 2 620200 id N32 No_Module FC
3 3 620300 id N16 Online FC EX-Port 10:00:00:05:1e:0b:96:8f
"Edge_6510" (fabric id = 10 ) E-Port 50:00:51:e7:e2:64:ef:02 "fcr_xd_1_10“
<Truncated Output>
FOS commands beginning with fcr are only accepted in the backbone fabric by a router-
capable product.
In the example above, the fcrfabricshow command output indicates that the backbone
fabric includes one router, with the following information:
• WWN = 10:00:c4:f5:7c:0e:c0:7c
• Domain ID = 98
• IP address = 10.255.240.33
• Switch name = BB_G620
This router has one EX_Port with the following information:
• EX_Port Number = 3
• FID = 10
• IP address = 10.255.240.31
• WWN = 10:00:00:05:1e:0b:96:8f
• Switch name = Edge_6510
If the Fabric name was set using the fabricname command the fcrfabricshow
--fabricname command will display the EX-port, FID, switch name and fabric name of
each edge fabric switch. Fabric name learning (first introduced in FOS v7.0) is supported for
FC-FC Routing starting with FOS v7.1.
In the fcrproxydevshow command output above, we see the two proxy devices that are
currently being shared across the backbone fabric:
• In the edge fabric (Fabric ID 10), there is one proxy device (WWN -
22:00:00:20:37:dd:d9:29), matching the physical device attached to the backbone fabric
(Fabric ID 100). The FC address of the proxy device (0x01f001) confirms that it is the
first proxy device connected to translate domain 1.
• In the backbone fabric (Fabric ID 100), there is one proxy device (WWN -
10:00:00:05:1e:57:7c:79), matching the physical device attached to the edge fabric
(Fabric ID 10).
Note: Besides using CLI commands to verify devices, ports, zones, proxies, etc., verification
can be achieved using SAN Health and Network Advisor.
Footnote 1: The YYY portion of the PID numbering increments as follows: 001, 101, 201,
301, 401, …, f01, 002, 102, 202, 302, 402, … This incrementing scheme is used to better
utilize the VCs when the frame traverses an ISL in the edge fabric. Note, the device area field
begins with “f” and node address field is not 00, if using core PID.
You can identify imported proxy devices in nsallshow output by their 24-bit address:
• The Domain ID will be the Domain ID of the translate (xlate) domain used for
representing the remote Fabric ID where the imported device physically exists.
• The Area (port #) will be in the range of 0xf0 - 0xff.
• The node address will be non-zero, starting at 01 and ending at FF. Examples: 08f003,
03fd22, 47fe17
Footnote 1: The nscamshow command displays the Name Server Cache Manager output.
The Name Server Cache Manager contains a cache of the Name Server information for all
other switches in the fabric including the logical front and translate domains. If you had other
physical switches in the fabric the output would be the same.
Footnoote 1: After an EX ports IFL cost has been changed from 1000
to 10000, it will be marked as the remote DRP and will not be used
until all IFLs with a lower IFL cost are offline.
In this example, there are two routers attached to the same edge
fabric using FID 2, Router1 and Rotuer2. You do not want routed
traffic to use EX_Port 8 on Router2 unless the EX_Port on Router1 is
offline. To do this, change the IFL cost on Router2 for EX_Port 8
from its default value of 1000 to 10000.
Router2:admin> fcrrouterportcost 8 10000
Command syntax:
fcrrouterportcost [[slot/]port] [cost
To enable Fibre Channel Routing Services for a switch:

1. In the Network Advisor navigation tree, right-click the switch and select Element Manager
> Router Admin. The FC Router window is displayed.
2. If you want to set a specific Fabric ID, first disable the switch, click Enable FCR, and click
Yes at the prompt.
a) Enable the switch after making the change.
3. On the General tab click Set Fabric ID.
a) Select the Backbone Fabric ID from the pull-down menu and click OK. In this example,
the backbone FID 1 was not changed.
Note: The switch must be disabled to change the backbone fabric ID, valid range for
backbone fabric IDs is 1-128.
Disable FCR and the switch before attempting to change the BB FID. This can be done from
BNA by right clicking the switch and selecting Actions > Enable/Disable
To configure an EX port:
1. In the FC Router window, click the EX_Ports folder tab.
2. Click New to launch the Port Configuration Wizard.
3. Select the port from the list and click Add.
4. Click Next.
It is a best practice to first disable the port before configuring it as an Ex_port.
Specify the port parameters:

5. Select the Fabric ID of the port from the pull-down menu.
6. Set the Interop Mode for the EX_Port.
7. Click Next.
Interop Mode: Specify the Port mode:

• Brocade Native mode
• Brocade NOS Fabric
The following fabric settings cannot be configured from the wizard: preferred front and
translate domain ID, PID Format, R_A_TOV and E_D_TOV.
The “Enable Port after configuration” check box will be greyed out unless the port is already
disabled.
Specify the FC parameters:

8. Specify FC parameters using the Speed, Long Distance Mode, Desired Distance,
Frame Size, Buffers Needed, Recommended Buffer, VC Link Init, and Max Auto Neg.
Speed drop-down menus.
9. Click Next.
Confirm the new configuration:

10. On the Confirmation page review the settings and verify everything is correct.
11. Click Save to continue to the Report page.
Confirm the new configuration (cont.):

12. Verify that there are no errors and click Close.
Enable the EX_Port:

• The new EX_Port is now displayed
13. To enable the EX_Port select it from the list and select Actions > Enable.
Within Network Advisor, if not done already, the edge fabric will need to be discovered.
Once Fibre Channel Routing is configured Network Advisor automatically creates a scope
specifically for LSAN zoning in the Zoning window.
Configuring LSAN Zoning:

1. Highlight the fabric and then click Configure > Zoning > LSAN Zoning (Device
Sharing).
2. In the Zoning Scope drop-down menu, select LSAN_xxx, where xxx is the fabric name.
Adding devices to the zone:

3. Click New Zone and select either New Zone (traditional zone) or New Peer Zone. In this
example New Zone was selected.
4. Set the zone name, Network Advisor automatically prepend LSAN_ to the zone name. To
change the name of the zone, double click on the field and type in the new name
5. Select the devices you want to add to the zone, you can select multiple entries using
CTRL+Click. You can select from the Host/Storage Groups or from one of the switches. In
this example, Storage Group was used in the Backbone Fabric (note, the same storage
device is also available under G620_Core) and a host listed under 6510_Edge.
6. Click the right-arrow to move the devices into the new zone.
7. Click Activate to save the zone to the fabrics.
Activating LSAN zones

8. Click Ok to save the configuration to the switches, note that the LSAN_NewZone has been
added to both the edge fabric and backbone fabric.
9. At the Network Advisor Message dialog, click Yes.
• Note: The LSAN zones will be added to the active configuration of each fabric involved
in the zone. If there is no active zoning configuration in the fabric one will be created
and made active. If you are running a fabric with no zones you will lose device
connectivity when BNA creates and activates the LSAN zone config.
10. Click Ok on the LSAN activation confirmation. This will close all dialog boxes.
Note: To refresh the Zoning dialog click Ok to close the window, then reopen by going to
Configure > Zoning
11. Change the Zoning Scope to one of the routed fabrics.

12. Refresh the Zone DB.
13. Accept the message that the Network Advisor DB will be overwritten with the one currently
active in the fabric.
14. Verify that the LSAN_ zone is now in the Zone Configuration.
LSAN zones can be manipulated like any other zone.

If a zoning config does not already exist, one is created to hold the new LSAN zone.
LSAN zones can be added to existing zoning configurations. If the fabric already has an
active zone configuration place the new LSAN zone into that configuration and write the
changes to the fabric.
- Indicates the zone or configuration is active in the fabric.
To configure front domains on an edge fabric:

1. From the main Network Advisor window, click Configure > Routing > Domain IDs.
To configure front domain IDs on an edge fabric use the Configure Routing Domain IDs
dialog (cont.):
2. Select the domain in the edge fabric you wish to change. (Note: The FD must be online
before you can change it.)
3. Click the right arrow to add it to the Selected Switches list.
4. In the Domain ID column use the pull-down menu to select the new domain ID.
5. Click OK and then OK again at the Domain ID Configuration dialog.
To access EX_Port and E_Port properties, select Element Manager > Ports:
Open the FC Router window and click the LSAN Fabrics tab
• From here you can view switches involved in LSANs.
• Selecting a switch from the navigation pane displays the LSAN specific information for
that switch:
• LSAN zones
• Physical LSAN devices
• Proxy LSAN devices
Click the Manage LSAN Fabric to launch Element Manager for the selected switch
The LSAN Zones folder tab provides a condensed view of LSAN zones configured for
managed switches.
Selecting a zone from the navigation pane displays information for that zone display:
• General
• Zone name
• Fabric ID
• Switch name
• Fabric type
• Physical LSAN devices
• Proxy LSAN devices
The LSAN Devices tab shows a list of physical and proxy devices. Properties can be viewed
for any device by selecting it from the navigation tree.
Physical device properties
• Port WWN, Node WWN, Physical PID
• Vendor
• Which fabrics contain proxies for the device
Proxy device properties:

• Proxy PID
• Port and Node WWN
• Which fabric the device exists in physically
• Physical PID
• Vendor
• Fabric type
• Which LSAN zones the device is a member of
Footnote 1: Example output when both devices are online and correctly configured.
BB_G620:admin> lsanzoneshow -s
Fabric ID: 10 Zone Name: LSAN_Backbone1_Edge1
10:00:00:05:1e:57:7c:79 EXIST
22:00:00:20:37:dd:d9:29 Imported
Fabric ID: 100 Zone Name: lsan_backbone1_edge1
10:00:00:05:1e:57:7c:79 Imported
22:00:00:20:37:dd:d9:29 EXIST
BB_G620:admin> fcrproxydevshow
Proxy WWN Proxy Device Physical State
Created PID Exists PID
in Fabric in Fabric
-------------------------------------------------------------------------
10 22:00:00:20:37:dd:d9:29 01f001 100 010100 Imported
100 10:00:00:05:1e:57:7c:79 01f001 10 030100 Imported
Total devices displayed: 2
Footnote 2: CONFIGURED may also be displayed if LSAN zones are not configured in both
fabrics.
The lsanzoneshow command will display all currently-active LSAN zones that the backbone
fabric is enforcing.
lsanzoneshow [-s] [-f fabricID] [-w wwn] [-z zonename]
Search parameters -f, -w, and -z allow searching for LSAN zones based on fabric ID, WWN
of an LSAN zone member, or LSAN zone name.
-f fabricID: Display LSAN zones in the specified fabric.
-w wwn: Display LSAN zones containing the specified port
WWN. (Format XX:XX:XX:XX:XX:XX:XX:XX)
-z zonename: Display LSAN zones with the specified zone name.
-s state: Display state information for the device, valid states include:
Configured: Device is configured to be in an LSAN, but the device is not imported
nor does it exist in this fabric.
EXIST - Device exists in this fabric (the fabric of the zone entry).
Initializing: Device is in an intermediate state. It is not yet imported into the fabric.
Imported - Device has been imported (proxy created) into this fabric.
In this example, you can see which devices actually exist in the fabric listed (EXIST) and
which ones are projected into that fabric (Imported).
In the fcrproxydevshow command output above, we see the two proxy devices that are
currently being shared across the backbone fabric:
• In the edge fabric (Fabric ID 10), there is one proxy device (WWN -
22:00:00:20:37:dd:d9:29), matching the physical device attached to the backbone fabric
(Fabric ID 100). The FC address of the proxy device (0x01f001) confirms that it is the
first proxy device connected to translate domain 1.
• In the backbone fabric (Fabric ID 100), there is one proxy device (WWN -
10:00:00:05:1e:57:7c:79), matching the physical device attached to the edge fabric
(Fabric ID 10).
Note: Besides using CLI commands to verify devices, ports, zones, proxies, etc., verification
can be achieved using SAN Health and Network Advisor.
The fcrproxyconfig command is sometimes used to define a proxy device whose PID
does not change. Similarly, the fcrxlateconfig command is sometimes used to define a
xlate domain ID that does not change.
FCRP cost
The FC Router protocol cost (for routing decisions) for this NR_Port. The FCRP cost is the
same (1000) for all NR_Ports.
Command Syntax:
fcrxlateconfig <importedFID> <exportedFID> <preferredDomainID>
Footnote 1: Used for routing through the backbone in edge-edge routing. What EX_Port do I
need to send the frame to get to the destination edge fabric?
When troubleshooting routed SANs note that some commands relate specifically to switches
and others relate specifically to routers. Switch centric commands would include all the normal
Fabric OS commands, some of which have been updated to include pertinent edge fabric
information. For example, the fabricshow command displays all front and translate domains
in the edge fabric. Router centric commands typically start with “fcr”, like fcrresourceshow,
and display information specific to the routers and the backbone fabric.
In the fcrresourceshow command output, you can see the per-backbone and per-port
maximums for the following FC Routing resources:
• LSAN zones
• LSAN devices (proxy or physical devices)
• Proxy device slots (device-to-node address mappings
• Phantom node WWNs
• Phantom port WWNs (includes ports connecting front and translate domains (virtual
ISLs), translate domain ports for proxy devices, and EX_Ports)
• NR_Ports (stored at every physical port for routing decision purposes)
The scalability limits always override the maximum values in this command output.
In the example above, the error message indicates that a FC router port 4 changed from a
non FCR port to an FCR port.
The FCR-* error messages are documented in the System Error Message Reference
Manual.
Footnote 1: The zoneshow command gives the same information in slightly different format.
FC-FC routing connectivity can also be verified with the fcping command
An example edge fabric topologyshow command output:

Brocade:admin> topologyshow
3 domains in the fabric; Local Domain ID: 10
Domain: 1
Metric: 10500
Name: fcr_xd_1_100
Path Count: 1
Hops: 2
Out Port: 10/4
In Ports: 1/12 1/15
Total Bandwidth: 6.000 Gbps
Bandwidth Demand: 100 %
Flags: D
<Truncated Output>
The SSHOW_ISWITCH.tx file from a supportsave includes information from the following
FC routing-related CLI commands: fcrproxydevshow, fcrphydevshow,
portcfgexport, fcrxlateconfig, fcrrouteshow, lsanzoneshow, and
fcrfabricshow.
BB_G620:admin> switchdisable
BB_G620:admin> fcrlsan --add –enforce local
Lsan Tag set successfully.
BB_G620:admin> fcrlsan --add -enforce BRCD
BB_G620:admin> fcrlsan --add -enforce remote
BB_G620:admin> fcrlsan --remove -enforce BRCD
BB_G620:admin> fcrlsan --show -enforce
Total lsan Tags : 2
enf : local
enf : remote
BB_G620:admin> fcrlsan --add -speed super
BB_G620:admin> fcrlsan --show -speed
speed : super
BPSA 300 Fibre Channel over IP Theory
Revision 0816 4–1

Revision 0816 4–2

Until recently, business-continuance and disaster-recovery plans that transfer critical data to
diverse locations have been feasible only for the largest enterprises. The costly
WAN connections and equipment-transferring storage area network (SAN) traffic across
significant distances have traditionally been accomplished with technology that puts the SAN
traffic directly on a SONET system, directly onto dense wavelength-division multiplexing
(DWDM) systems, or even onto dark fibers. FCIP technology avoids all these expensive
alternatives and makes use of the low-cost and ubiquitous IP network to transfer SAN data.
This one technology brings true business continuance and disaster recovery within reach of
the small-business and midsized-business (SMB) customer. It also provides a much lower-
cost alternative for the large enterprise.
Revision 0816 4–3

Footnote 1: Distances that use native Fibre Channel can span 500km; these solutions
incorporate dark fiber, C/DWDM, and form a single fabric.
For additional FCIP details, reference RFC 3821 – Fibre Channel Over TCP/IP (FCIP).
Brocade does not recommend FCIP for use in every distance extension scenario: no technical
solution can be all things to all people. FCIP has inherent performance, reliability, data
integrity, and manageability limitations when compared to native FC solutions. Delay and
packet loss may create bottlenecks in IP networks. FCIP can support very long distances, as
long as the carrier network is extremely high performance and reliable. FCIP is typically
deployed when long-haul applications are not business critical, and do not need especially
high performance. FCIP may not be suitable for tape, since tape usage will often fail if packets
are dropped. In addition to its performance limitations, FCIP troubleshooting and performance
analysis requires evaluating all aspects of the IP LAN and WAN networks in addition to all FC
nodes, switches, and routers, which can make it more complex to manage than other
extension options.
Revision 0816 4–4

Revision 0816 4–5

Footnote 1: In FC-FC routed fabrics, this could be an Inter-Fabric Link (IFL).

FC traffic over an IP network:
• Interconnection of islands of Fibre Channel SANs over IP-based networks
• Distance extension over IP LAN/WAN/MAN
Revision 0816 4–6

After FC frames destined for devices at the remote side are encapsulated into TCP packets, a
standard IP header is added to each packet. The packet is then sent to the next hop (usually
an Ethernet router).
FCIP Encapsulation
Before an FC frame is sent out through FCIP over an Ethernet link, the transmitting FCIP port
encapsulates the FC frame in the payload of each of the four protocols in the stack: FCIP,
TCP, IP, and Ethernet
The receiving FCIP port de-encapsulates the Ethernet, IP, TCP, and FCIP headers;
reassembles the FC frame (if it was fragmented); and forwards the FC frame into the FC
fabric
MAC Address IP Address TCP Port Tunnel ID VE_Port
Revision 0816 4–7

Revision 0816 4–8

7840 switch
• Rack-mountable 2U chassis
Retired products:
• 7800
• FX8-24 blade (DCX 8510-4/8510-8 and DCX/DCX4-S)
• 7500 switch
• 7500E switch
• FR4-18i blade (DCX, DCX-4S and 48000 director chassis)
Revision 0816 4–9

Footnote 1: An Upgrade License is required to enable all 16 FC ports and 2 x 40 GbE ports.
Footnote 2: DP=Data Processor. There are two DP which help to provide Hot Code Load
(HCL) functionality. During a firmware download 1 DP controls all the tunnels while the other
is being updated.
To use the Integrated Routing feature you will need to configure the FC EX_Ports because
VEX_Ports are not supported
Footnote 1: Compatible with short wavelength(SWL), long wavelength (LWL) and extended
long wavelength (ELWL) SFP+ transceivers
Footnote 2: Compatible with copper, ultra short reach (USR), short reach (SR) and long
reach (LR) SFP/SFP+ transceivers
Footnote 3: Compatible with short reach (SR) and long reach (LR) QSFP transceivers
Note: QSFPs used in the FC16-64 blades (and 8510 core blades) are not compatible with the
Brocade 7840
Note: VEX_Ports are not supported on the Brocade 7840 switch
There are three management connections (one RS-232 RJ45, one Ethernet RJ45,and one
USB port):
The RS-232 RJ45port connection provides a serial port interface for setting the switch’s IP
address and to restore the switch to factory defaults
The Ethernet RJ45 port connection provides a 10/100/1000BaseT port for a full system
management console interface.
One USB port that provides storage for firmware updates, output of the supportSave
command, and storage for configuration uploads and downloads.
Footnote 1: The Brocade 7840 shares the same power supply and fan FRU with the Brocade
6520
The power supply meets the following requirements:
• Maximum Power: 1100 Watts
• Input Voltage: 90 to 264 VAC nominal
• Input Line Freq.: 47to 64 Hz
• Inrush Current: 40A Max
• Maximum Current: 13A at 12V DC
Both the PSU and fan FRUs are labeled with the I airflow symbol to indicate that they take in
air. The orange I symbol indicates an intake unit. This unit pulls air in from the non port side of
the device
and exhausts it out the port side. This is also called back-to-front airflow or reverse airflow.
This symbol should appear on FRUs with part numbers ending with -R.
Footnote 2:. The Brocade 7840 uses three DC port side exhaust Fan FRUs to provide
necessary airflow to cool the system. Hardware discrete fan speed control logic sets the fan
speed, which is continuously measured by the peripheral hardware. In the event of one FAN
FRU failure, the remaining two fans will switch into high speed to compensate for the reduced
cooling capability. Hot-swappable. Each power supply and fan unit has a status LED.
Please refer to the Release Notes for the most up-to-date information.
.
Footnote 1: Following are the requirements for forming trunk groups:

All ports in a trunk group must belong to the same port group. For example, to form an 8-port trunk
select all eight ports from port group 0 or port group 1
You cannot use ports from each port group for the trunk.
You can use from 1-8 ports in a port group to form a trunk.
Ports must be running at the same speed.
Ports must be configured for the same distance
SX6 Port layout:
40 GbE port 0
40 GbE port 1
10/1 GbE ports 2-9 (right to left)
10/1 GbE ports 10-17 (right to left)
FC ports 0-7 (right to left)
FC ports 8-15 (right to left)
Port blades have the following LED indicators:
∙ Green blade power LED
∙ Bicolor green/amber 40 GbE and 10 GbE port status LEDs
∙ Bicolor green/amber FC port status LEDs
The Brocade 7840 combines three major subsystems in the design into a fixed configuration 2
U package: a single-chip ASIC FC switch, an FCIP subsystem for the data path and a CPU
complex that processes control path data.
Each Brocade 7840 supports two data processor (DP) complexes. DP complexes are
synonymous with FCIP complexes or FCIP engines. Each DP complex contains a data
processor (DP) attached to traditional Brocade's switching ASICs, and consists of special
purpose hardware for FCIP functions and multicore network processors. Two CN6880
system-on-chip processors, each with 32 MIPS64 cores running at 1.2GHz, is used for data
path processing such as protocol translation, TCP/IP stack processing and application
emulation (FastWrite, Tape Pipelining, Advanced Accelerator for FICON) functions.
Blitzer FPGA is used for FC compression, IPSec functionality, offloads like chksum
generation/checks, etc. Blitzer sits in the core of the FCIP subsystem. It connects to Condor3
over 6 FC(10G) links on the FC side and to Trident Ethernet switch over 4 10GbE links on the
IP side.
FCIP, IP extension blade.

IO ports: 16 FC SFP+ (8/10/16/32G); 16 IP SFP+ (1/10G); 2 IP QSFP (40G).
Major HW components:
Condor4: Fibre Channel switch providing 64-port 4/8G/10G/16G/32G.
Cavium CN6880: Networking processor with 32 cnMIPS II cores @1.2GHz.
Blitzer: FPGA designed for FC bridging, Advanced Compression Assist and WAN IPSec
functionality.
Trident+: ETH/IP switch with 10G/40G interfaces
The Brocade 7840 uses common licenses similar to other midrange products (e.g. Brocade
6510) for IR and CUP.
A new SKU for Advanced Acceleration for FICON license on the Brocade 7840 is introduced.
All ports and interfaces on the switch are active except for the 40GE interfaces. The 40GE
interfaces are enabled as part of WAN Rate Upgrade 2 license.
Licenseshow output:
WAN Rate Upgrade 1 license
WAN Rate Upgrade 2 license
Advanced FICON Acceleration (FTR_AFA) license
Advanced Extension (FTR_AE) license
.
FCIP Tunnels:
7840 and SX6 - up to 20 VE_Ports
FCIP Trunking:
7840 and SX6 – up to 8 circuits per trunk
FCIP QoS support:
Marking DSCP
Marking 802.1P – VLAN tagging
Enforcement 802.1P -VLAN tagging
The legacy fixed port 7800 extension platform is not supported with the 8.0.1 release
FX8-24 (extension blade) running 8.0.1 is not supported with 7800
FX8-24 is the only Condor 2 based blade supported in Gen5 chassis from 8.0.1
Footnote 1: There is no configurable limit for the number of circuits that you can configure on
an Ethernet port. There is a practical limit based on the expected bandwidth usage of each
configured circuit and actual bandwidth limit of the Ethernet interface. Each circuit requires a
unique IP address pair. Multiple circuits typically supporting different tunnels can reside on
one physical GbE port.
Footnote 1: This diagram depicts a single tunnel (VE_Port) comprised of 4 separate circuits
(each circuit assigned using an IP address on a different GbE interface).
Footnote 2: FCIP does not care what physical port you use, as long as you have a matching
configuration on the other side
The Gbe interface number which is associated with a circuit is actually configured by
prepending a DP (Data processor) number 0 or 1 with GbE interface number (ge2.dp0). More
details to follow later in this module
Footnote 1: FC flow control mechanisms include R_RDYs and ACKs. FC communications

also utilize long distance modes, BB credits, and VC channels.
VE_Ports can be used as XISLs (VF enabled)
Footnote 1: There are actually two VE_Port groups in 10VE mode. DP0 controls VE_Ports
24-28 and DP1 controls VE_Ports 34-38. The remaining VE_Ports 29-33 and 39-43 are
disabled. Each port group can share 20 Gbps.
Foonote 2: There are actually four VE_Port grouping in 20VE mode. DP0 controls VE_Ports
24-28 and VE_Ports 29-33. DP1 controls VE_Ports 34-38 and VE_Ports 39-43. Each of the 4
port grouping can share 10 Gbps. This means that any single VE_Port can have a maximum
bandwidth of 10 Gbps. The total supported bandwidth is the same as 10VE mode but an
individual VE can only support up to 10 Gbps.
VE_Ports are not associated with a particular Ethernet port.
With compression, total bandwidth cannot exceed 80 Gbps (40 Gbps per DP) on the Fibre
Channel side.
When the switch operates in hybrid mode, 20 VE mode is not supported

Footnote 1: Each DP can supports up to 10Gbps of FCIP traffic (post fast-deflate) and up to 20Gbps
with fast-deflate enabled
This diagram depicts a single tunnel comprised of 4 separate circuits (using 4 different GbE
interfaces).
GbE interfaces get linked to a DP during Ip address assignment of GbE port interface
In 10VE mode if the chosen VE # is between 24-28 then dp0 must be specified
In 10VE mode if the chosen VE # is between 34-38 then dp1 must be specified
VE_Ports cannot connect in parallel to the same domain at the same time as Fibre Channel
E_Ports or EX_Ports
Footnote 1: Maximum FCIP tunnel bandwidth of 20 Gbps on the 7840 is double what the
available maximum tunnel bandwidth was on the previous 7800 platform.
Footnote 1: Adaptive Rate Limiting (ARL) applies a minimum and maximum traffic rate, and
allows the traffic demand and WAN connection quality to determine the rate dynamically. If
traffic is flowing error-free over the WAN, the rate grows towards the maximum rate. If TCP
reports an increase in retransmissions, the rate reduces towards the minimum. ARL never
attempts to exceed the maximum configured value and reserves at least the minimum
configured value.
Footnote 2: The difference between the guaranteed (minimum) and maximum bandwidth for
a tunnel cannot exceed the 5:1 ratio
This is true whether configured on a 10 GbE or 40 GbE port in 10VE mode.
In 10VE mode:
The minimum (aggregate) committed rate for all VE_Ports in one DP complex cannot exceed
20 Gbps. The maximum (aggregate) rate for all VE_Ports in one DP complex cannot exceed
40 Gbps.
In 20VE mode:
For a VE_Port group, the sum of the minimum committed rates of that group's circuits cannot
exceed 10 Gbps and the maximum is 20Gbps.
Example tunnel/circuit creation:

A tunnel using VE_Port 24 is created with an initial circuit 0 with a maximum rate of 10 Gbps,
metric of 0.
• IPPM_LINK_UP.bandwidth = 10 Gbps
• Circuit 1 is added to Tunnel 24 with a max rate of 10 Gbps, metric 0.
• TUNNEL_UPDATE.bandwidth = 20 Gbps
Circuit 2 is added to Tunnel 24 with a max rate of 10 Gbps, metric 1.
• Since this is a higher metric, it is considered a standby and no TUNNEL_UPDATE is
generated.
Circuit 3 is added to Tunnel 24 with a max rate of 155 Mbps, metric 1.
• Since this is a higher metric, it is considered a standby and no TUNNEL_UPDATE is
generated.
The original design of FCIP circuit and metrics provided for a primary/secondary relationship
between the circuits in a tunnel in which one had metric 0 and one had metric 1. If the metric
0 circuit failed then the metric 1 circuit would be used.
In cases where customers had more than two circuits in a tunnel using metric 0 and metric 1,
gave them four circuits: two of metric 0 and two of metric 1. When one of their metric 0 circuits
failed a metric 1 circuit was not put to use (the metric 1 circuit would not be utilized unless
both metric 0 circuits failed).
The failover group feature was designed to define a relationship between the different metric 0
and metric 1 circuits and group them together so that you can identify a metric 1 circuit is a
secondary circuit for its associated metric 0 circuit.
When load-leveling across multiple circuits, the difference between the ARL minimum data
rate set on the slowest circuit in the trunk and the fastest circuit should be no greater than a
factor of four
Without Failover Groups

With a 4 FCIP Circuit Tunnel
Circuit 0 Metric 0, Circuit 1 Metric 0
Circuit 2 Metric 1, Circuit 3 Metric 1
• If Circuit 0 fails, configuration would continue to run over the remaining metric 0 circuit
• Circuits 2 and 3 will not be used until both Circuits 0 and 1 have failed.
With Failover Group
Circuit 0 Metric 0 Group 1 and Circuit 2 Metric 1 Group 1
Circuit 1 Metric 0 Group 2 and Circuit 3 Metric 1 Group 2
• If Circuit 0 fails, Circuit 2 will be used
• If Circuit 1 fails, Circuit 3 will be used
Failover is the default mode

End to end configuration mismatch results in negotiation
Tunnel ends will negotiate down to failover
Failover groups are ignored for spillover

Spillover is activated after 15-20 seconds of bandwidth usage of 96%+ range
The failover behavior of a tunnel remains intact with regard to the lower metric circuits. If a
tunnel is configured for spillover and the lower metric circuits become unavailable, the higher
metric circuits function as the backup circuits. Metric 1 circuits always behave as backup
circuits whether configured for spillover or failover.
Circuit failover groups can still be configured and will behave as before, however, only the
metric value determines whether a circuit is considered a spillover circuit or a primary circuit.
For example, if a tunnel is configured with four circuits, with two metric 0 and two metric 1
circuits in two separate failover groups, both metric 0 circuits are used, and only when they
become saturated are the metric 1 circuits used. The failover grouping is used for failover
scenarios only
Footnote 1: Configuring a tunnel with more than one circuit requires an Advanced Extension
license. Without a license present, a second circuit cannot be configured and the
administrator will receive a message stating as such.
Timeout values:
• Default FICON is 1 sec
• Default FC is 4 sec
• Depending on the solution being extended, the timeout values might need to be changed
from the default.
Footnote 1: FCIP HCL supports mainframes by not causing an Interface Control Check
(IFCC).
Footnote 1: Actually created on a per circuit basis

Footnote 2: Primary tunnel (circuit). Only tunnel used in non-upgrade timeframes.
Footnote 3: This tunnel is not utilized during non-FCIP HCL operations and is created
automatically on the local DP1
Footnote 4: This tunnel is not utilized during non-FCIP HCL operations and is created
automatically on the remote DP1
The main tunnel (MT) is what you normally configure to create an extension tunnel from a
VE_Port using the portcfg fciptunnel command and appropriate tunnel and circuit parameters.
The MT carries traffic through the extension tunnel to the remote switch. The LBT is created
upon specifying the local HA IP address for the circuit, and the RBT is created upon specifying
the remote HA IP address for the circuit. All three tunnel groups (MT, LBT, and RBT) are
associated with the same VE_Port
Footnote 1: Notice in this example on VE_Port 24 circuit 0 has been configured for HCL
operations. (circuit 1 was not)
With compression, total bandwidth cannot exceed 80 Gbps (40 Gbps per DP) on the Fibre
Channel side.
Typical deflate compression may achieve different compression ratios. Brocade makes no
promises as to the achievable compression ratios for customer-specific data
If a 4:1 compression ratio is achieved using fast deflate compression, then 80 Gbps is
available to external FC ports
Hardware compression is performed at FC ingress and de-compression is performed at FC

egress.
Compression before encapsulation allows the TCP and FCIP headers to be visible on the
network.
Typical deflate compression may achieve different compression ratios. Brocade makes no
promises as to the achievable compression ratios for customer-specific data.
The following compression options are available for the Brocade 7840 Extension switch and
Brocade SX6 Extension blade.
None: no compression.
Fast deflate: Hardware-based compression. This mode initiates a deflate-based algorithm to
compress data before it enters the DP and decompresses the data after it leaves the DP. It
provides the highest throughput at 40 Gbps per DP before compression, but the least amount
of compression.
Deflate: Processor-based compression. This mode initiates the processor compression
engine in deflate mode with preference on speed at 16 Gbps total per DP before
compression. It provides a lower speed than fast-deflate, but a faster speed than aggressive
deflate. Deflate compression provides more compression than fast deflate, but is typically not
as much compression as aggressive deflate.
Aggressive deflate: Processor-based compression. Initiates the processor engine in deflate
mode with preference on compression. This mode is the slowest at 10 Gbps before
compression, but typically provides the highest level of compression:
For example, it would not be wise to be paying for a 20 Gbps WAN pipe if the Deflate
compression option was chosen. The expected throughput would only be between 2-4 Gbps
per DP.
If a 4:1 compression ratio is achieved using fast deflate compression, then 80 Gbps is
available to external FC ports (both DP’s)
For 1 GbE, 10 GbE, and 40 GbE ports, the ratio between the minimum committed rate and
the maximum committed rate for a single circuit cannot exceed five times the minimum. For
example, if the minimum is set to 1 Gbps, the maximum for that circuit cannot exceed 5 Gbps.
This is enforced in software.
The ratio between any two circuits on the same tunnel should not exceed four times the lower
circuit. For example, if one circuit is configured to 1 Gbps, any other circuit in that same tunnel
should not exceed 4 Gbps. This limit is not enforced in software, but is strongly
recommended.
As a best practice, the aggregate of the minimum rate bandwidth settings through a VE_Port
tunnel should not exceed the bandwidth of the WAN link. For example, if the WAN link is 2
Gbps, the aggregate of the ARL maximum rates connected to that WAN link can be no more
than 2 Gbps. For ingress rates, there is no limit because the FC flow control (BBC) rate limits
the incoming data.
Footnote 1: The 7840 / SX6 blade in 10 VE mode supports a 20 Gbps max tunnel size.
Best practice is to use a commit rate that uses 90% of the bandwidth allocated to the FCIP
traffic. In this example, both devices are configured for 100% of the total bandwidth of the
WAN gateway, which means that the router is oversubscribed 2:1. This configuration can lead
to many dropped frames and errors.
The configuration above is a better solution than the previous slide, but still has shortcomings.
While the router is not oversubscribed, the bandwidth available for the WAN is not fully utilized
when there is either a failure of one of the devices, or a simple case of a device needing less
bandwidth than what is configured. This can leave the link underutilized during certain times.
Footnote 1: Best practice dictates setting maximum commit rates to 90% of physical
connection.
The best solution would to use Adaptive Rate Limiting (ARL) to better utilize the available
WAN bandwidth. By configuring each device with a minimum commit rate of 50% of the
allocated bandwidth, each device is then guaranteed a minimum amount of bandwidth at all
times. If an outage occurs in one of the devices, or a device is not using all of its minimum
committed rate bandwidth, the other active device can utilize the extra bandwidth up to its
configured maximum commit rate.
Footnote 1: 1 network RTT must pass before ARL will determine to take an additional step down. This
approach allows ARL to take some time to find the new available rate by decrease instead of resetting to
the min and then growing again.
Footnote 2: ARL determines the number of steps by dividing the RTT in to 1 second. Essentially
guarantees the time from current to minimum when errors are encountered is 1s
Adaptive Rate Limiting (eARL) behavior is selectable based on consideration of WAN RTT
and application sensitivity to latency introduced by ARL
More rapid rate reduction is needed for long RTT WAN to avoid lengthy convergence period with
re-transmits and for applications sensitive to latency caused by re-transmits
More gradual rate reduction would maximize WAN utilization for deployments with shorter RTT
All algorithms implement the same growth algorithm. (ramp up time is 1 second)
Provider infrastructure should be geographically diverse (not having multiple provider links
physically close to one another in case of physical link damage caused by accident)
RDR = Remote Data Replication
RDR/S = Synchronous
RDR/A = Asynchronous
RDR applications include, but are not limited to:
EMC SRDF
EMC MirrorView and SANcopy
HDS Universal Replicator (aka HUR, RDR/A)
HDS TrueCopy (RDR/S)
HP Continuous Access for EVA
IBM Global Mirror (RDR/A) and Metro Mirror (RDR/S
Diagram depicts one of the supported IP Extension topologies (Direct Attached Topology for IP
Storage Replication) for connecting the IP Storage to the 7840 or SX6 blade.
IP replication traffic is typically configured to be terminated at the 7840/SX6 blade and accelerated
over the WAN. There is an option to pass through management traffic (between arrays) non
terminated and un-accelerated. (non-terminated TCP (NT TCP)). Non terminated TCP connections
should not carry heavy duty data bearing TCP traffic and are designed to carry control type TCP traffic
from IP storage
TCP Handling:
Data is batched together on a connection
Batch size is 32 kB
If a batch is not filled in 2 ms, the batch is packaged and sent
TCL (Traffic Control List) Configurations are used to help manage IP Extension flows and how
to treat LAN traffic. (Map LAN side traffic to tunnels)
•The portcfgtcl command can be used to manage the TCLs.
•There are three main parts to the TCL rule.
Priority -A unique priority ID that is used to give order of precedence to the specified TCL. Integer
value between 1 -65534 with 1 being highest priority.
Input Filter -A set of input filters to uniquely identify a type of LAN traffic. Ex. Match all traffic from
source IP address 192.168.42.0/24.
Target -Specify to allow / deny the matching traffic, and if set to allow then specify which VE-Port
(and optionally which priority) to forward the traffic to.
Direct Attached Topology for IP Storage Replication. IP Storage connected directly to the
configured LAN GbE ports.
Direct Attached through L2 switch with LAG topology
L3 PBR Deployment details:

IP Storage
IP Storage should be connected to L3 gateway directly or via switched configuration
Storage array should be configured with L3 IP address as next hop gateway
L3 Router (Router 1)
Router can be used as LAN gateway
Router needs to configured with redirect protocol (i.e. PBR or Policy Based Routing) to redirect IP
LAN traffic to 7840 or redirect to SVI address
Normal traffic flow would have the storage traffic go directly from Router 1 to the WAN but because
of the policies set on Router 1 using PBR, redirection of traffic flows takes place sending the
storage traffic to the 7840 or the SX6 blade.
7840 or Gen6 Extension blade

LAN GE ports are connected to L3 router
WAN ports are connected to WAN gateway
At least one SVI IP address is configured for each DP
7840 or Gen6 Extension blade shall be configured with L3 router IP address as next hop gateway
for LAN egress
IP LAN Deployment supported on a per site basis

i.e. Site 1 can have PBR configuration while Site 2 uses Direct Attach
Footnote 1: Tunnel Configuration

portcfg fciptunnel command updated to include a --ipext enable|disable option
This allows IP Extension traffic to be sent over this tunnel
Enabling IP Extension for a tunnel will create 3 new IP priorities for the tunnel (IP-High, IP-Medium,
IP-Low)
All circuit options will be inherited for the new IP priorities with the exception of HA IP addresses (IP-
Extension does not support HCL)
Minimum commit rate will be recomputed and modified as needed for the current configuration
Tunnel bandwidth distribution will be split between FC priorities and IP priorities to allow for hierarchal
QoS distribution
The tunnel compression configuration can be controlled independently for FC and IP protocols
TCL (Traffic Control List) Configurations can be used to help manage IP Extension flows and how to
treat LAN traffic
The new portcfg tcl command can be used to manage the TCLs
There are three main parts to the TCL rule
Priority - A unique priority ID that is used to give order of precedence to the specified TCL
Input Filter - A set of input filters to uniquely identify a type of LAN traffic
Target - Specify to allow / deny the matching traffic, and if set to allow then specify which VE-Port
(and optionally which priority) to forward the traffic to
Footnote 1: When in 10VE mode, all the unused VE_Ports must be in the default switch,
VE_Ports 29-33 and 39-43. If the unused VE_Ports are not in the default switch, the VE-Mode
cannot be set to 10VE mode. Unused VE_Ports cannot be moved to other logical switches
while in 10VE mode.
Up to four logical switches will support FICON CUP; however, refer to your system
qualification letter-specific limits
To learn more about Brocade Virtual Fabrics, please refer to the Brocade AFS141 web-based
training course.
Note: This feature enables multiple logical fabrics to share a single base fabric while providing
fabric-level isolation. Specifically, it will enable logical connectivity over FCIP between
otherwise disconnected segments of a fabric.
This feature is of particular significance in the FCIP distance-extension platforms as long-
distance GE links are expensive and the ability to share the GE link across multiple fabrics
can become a necessity. The Base fabric will provide the physical connectivity across which
logical connectivity will be established.
Packet loss re-transmissions are compounded when errors are bursty. Selective
Acknowledgement (SACK) is an extension to a protocol which allows the acknowledge
reception of specific packets or messages.
The SACK option RFC 2883 [18] allows the receiver to acknowledge multiple lost packets in a
single ACK, enabling faster recovery. An FCIP Entity may negotiate use of TCP SACK and
use it for faster recovery from lost packets and holes in TCP sequence number space.
Footnote 1: SACK improves loss detection, retransmission techniques, and enables faster
recovery.
Original Virtual Channel Model
VC # Assigned to
0 Class F
1 Class 2 Ack/Link Control
2 Data
3 Data All Data
4 Data Traffic
5 Data
6 Class 3 Multicast
7 Broadcast/Multicast
Brocade’s original virtual channel model (pre-Condor2/GoldenEye2) divides an ISL into 8

virtual channels to insure that traffic of multiple priorities can travel across the link at the same
time, without being disrupted, or disrupting other traffic.
The QoS feature only comes into play if there is contention on the link. If there is no
congestion on the link QoS will not engage.
The order of operations during congestion is as follows and repeats as necessary:
1. VC0 then,
2. Six frames of High priority traffic then,
3. Three frames of Medium priority traffic then,
4. One frame of Low priority traffic
Results of QoS on a congested link:
Footnote 1: This feature allows for configuration of percentages assigned to each QoS
priority and have these values adhered to when all QoS classes of traffic are active. If
bandwidth assigned to a particular QoS priority is unused, it will be proportionately assigned
to the flows associated with the other priorities.
Assumptions and Dependencies
• Symmetric percentages must be configured on each side of the tunnel
• Minimum setting is 10% for any of the QoS priorities, maximum is 80%
• Configurable in 1% increments
• The three QoS values must add up to 100%
• The High priority value must be greater than or equal to Medium and the Medium priority
value must be greater than or equal to Low priority value
• Modification of any QoS value on an active tunnel is disruptive
Backward Compatibility
Platforms running with older versions of FOS will be allowed to configure circuits in a manner
supported for that software version. However, if connecting a platform with Fabric OS v7.0 to
a platform running an older version of firmware, the QoS percentages configured on the
platform running FOS v7.0 must match that of the older platform. In other words, the default
values must be used.
Footnote 1: TCP port used is 3225 and 3226.
BPSA 300 Fibre Channel over IP Administration
Revision 0816 5–1

Revision 0816 5–2

Revision 0816 5–3

Revision 0816 5–4

Remember, an FCIP tunnel requires two endpoints.

Footnote 1: Supported MTU values are between 1280 and 9216.
Revision 0816 5–5

Footnote 1: Hybrid mode—In this mode, FCIP traffic and IP traffic can be sent over the
extension tunnels.
You can configure the following VE modes:
• 10VE mode: In this mode 10 of the 20 total VE_Ports on the switch are enabled. A single
VE_Port on a DP complex can use all Fibre Channel 20 Gbps bandwidth available to the DP
complex. In 10VE mode, VE_Ports 29-33 and 39-43 are disabled.
• 20VE mode: This VE mode is available when the switch is in FCIP mode. In this mode, all
20VE_Ports are enabled. A single VE_Port on a DP complex can use half of the available
Fibre Channel bandwidth available to the DP complex, a maximum of 10 Gbps. This option
allows use of more VE_ports, but at a lower maximum bandwidth.
Note: 10VE mode will accommodate nearly all environments and is the default
Revision 0816 5–6

Usage: extncfg <action> [options]

action:
--ve-mode 10VE|20VE - Set VE-Mode to 10VE or 20VE mode.
--app-mode fcip|hybrid - Set APP-Mode to FCIP or HYBRID (FCIP with IPEXT).
--show - Display APP & VE mode details.
--config -default - Default the Extension configuration.
--config -clear - Clear the Config for Extension configuration.
-h,--help - Print this usage statement.
Example: Gen 6 director with SX6 blades
Gen6_director:admin> extncfg –show
slot 3:
APP Mode is FCIP
VE-Mode: configured for 10VE mode.
slot 5:
APP Mode is FCIP
VE-Mode: configured for 10VE mode.
Revision 0816 5–7

Use the portcfgge command to configure a GbE port as a LAN port used when
configuring IPEXT functionality. More details will be provide on this
feature later in this module.
7840:admin> portcfgge ge10 --set -lan
Operation Succeeded.
7840:admin> portcfgge --show
Port Speed Flags LAG-ID
-----------------------------------------
ge0 40G A---- -
ge1 40G A---- -
...
ge9 10G A---- -
ge10 10G A-L-- -
ge11 10G A---- -
ge12 10G A---- -
ge13 10G A---- -
ge14 10G A---- -
...
------------------------------------------
Flags: A:Auto-Negotiation Enabled C:Copper Media Type L:LAN Port
Revision 0816 5–8

There is also a –config –clear [-slot <slot>|-all] option:

Clears the configuration database only for extension configurations on specified slot / all slots
in all logical switches.
Can only be used on powered off / empty / removed slot to remove latent or inactive
configurations
Revision 0816 5–9

Footnote 1: While disabling the port is supported, it is recommended that the port be
persistently disabled during the tunnel configuration.
Enter the portCfgShow command to verify which ports are persistently disabled
Footnote 1: For MTU the auto option can be used instead of a value which will cause any
circuits using this IP address to use PTMU discovery to set the desired IP MTU
To create an IP interface on the tunnel.
Each IP interface requires:
• A static IP address
• GbE port number and DP complex value (0 or 1).
• MTU size specification
• TCP port (3225 and 3226)
Note: This port is automatically assigned (not configurable). On the Brocade 7840 and
Brocade SX6 blade, the Brocade WO-TCP implementation selects a port between 49152 and
65535 as the ephemeral (or initiating) port to open up to port 3225 and 3226. On the Brocade
7840 switch and the Brocade SX6 blade, the TCP URG flag is frequently set
You can specify a VLAN ID (optional). Note that this is the only method to set the VLAN for
the IP address. All traffic using that IP address will be tagged automatically
DSCP markings and 802.1Q L2CoS settings are still applied on the FCIP circuit configuration
Limit of 60 IP addresses per DP:
Mix of IPv6 and IPv4 addresses does not matter
Limit of 120 IP addresses
The FCIP circuit must be made up of a unique IP pair across circuits:

7840 and SX6 only requires either the source or destination IP address to be unique between
configured circuits (e.g. the same source can be used with different destination IP’s)
The portshow ipif [slot/ port] command displays the interface ID, IP address,
netmask, and MTU slide for each IP interface.
The command portshow ipif all displays all interfaces.
All ports will display in the same table sorted by port number
FCIP_Local:admin> portshow ipif
Port IP Address / Pfx MTU VLAN Flags

-----------------------------------------------------------
ge2.dp0 192.168.1.2 / 24 1500 0 U R M
-----------------------------------------------------------
Flags: U=Up B=Broadcast D=Debug L=Loopback P=Point2Point R=Running
N=NoArp PR=Promisc M=Multicast S=StaticArp LU=LinkUp X=Crossport
FCIP_Remote:admin> portshow ipif
Port IP Address / Pfx MTU VLAN Flags

-----------------------------------------------------------
ge2.dp0 192.168.5.2 / 24 1500 0 U R M
-----------------------------------------------------------
Flags: U=Up B=Broadcast D=Debug L=Loopback P=Point2Point R=Running
N=NoArp PR=Promisc M=Multicast S=StaticArp LU=LinkUp X=Crossport
Footnote 1: The IP interface must be configured before adding a destination route on an

interface. A maximum of 128 routes can be added on one GbE port. However, you can only
define 120 IP routes per DP.
For example, you can configure 64 IP routes defined on ge2.dp0 and another 64 IP routes
defined on ge2.dp1.
The portcfg iproute [slot]/port create command configures an IP route from an

local IP address to a gateway IP address over an GbE port. The command has the following
required arguments:
• [slot]/port: The port on which the command is to operate. For an SX6 blade in slot
8: portcfg iproute 8/ge2.dp0 create 192.168.5.0/24 192.168.1.1
• ipaddr: The IP address of the route
• netmask: The IP netmask
• gateway_router: The IP address of the gateway router
In the example above, IP routes are configured at each end of the link because the two IP
interfaces that were configured are in different subnets.
Full command output for a single defined route on a GbE interface. Using the command
syntax portshow iproute ge2 will provide you all IP routes associated with the ge2
interface otherwise you can specify an individual interface / dp combination and only get
details for the specific IP interface. (ex. portshow iproute ge2.dp0)
IPv6 Link-Local entries are now omitted by default. To view link-local entries, use --link-local
option when displaying the route table.
FCIP_Local:admin> portshow iproute ge2
Port IP Address / Pfx Gateway Flags
------------------------------------------------------------------
ge2.dp0 192.168.1.0 / 24 * U C
ge2.dp0 192.168.1.1 / 32 * U H L
ge2.dp0 192.168.5.0 / 24 192.168.1.1 U G S
Flags: U=Usable G=Gateway H=Host C=Created(Interface)
S=Static L=LinkLayer X=Crossport
The portcmd --ping [slot]/port command validates end-to-end IP connectivity over

an GbE port. The command has the following required arguments:
[slot]/port]: The port on which the command is to operate (here, ge2.dp0 on 7840).
-s: The source IP address for an IP interface on a local GbE port.
-d: The destination IP address for an IP interface on a remote GbE port.
The command also has several optional parameters:

-n num_requests: Specifies the number of ping requests. The default is 3.
-q service_type: Specifies the type of service in the ping request. The default is 0 and
service_type must be an integer from 0 to 255.
-t ttl: Specifies the time to live. The default is 100.
-w wait_time: Specifies the time to wait for the response of each ping request. The default is 5000
milliseconds and the maximum wait time is 9000.
-z: Specifies the default packet size to a fixed size in bytes. The default is 64 bytes. The total
size, including ICMP/IP headers (28 bytes without IP options) cannot be greater than the IP
MTU configured on the interface.
If no optional parameters are specified, the command displays the currently configured values
for the specified port.
In the example above, a ping command is issued from the new IP interfaces on the Brocade
7840, to the new IP interface on the remote 7840. The command output shows that the ping
messages are received and returned by the Brocade remote 7840, verifying IP connectivity
between the IP interfaces.
Only 1 ICMP request can be active for a unique IP address pair at a time.
portcmd --traceroute [slot/]geport -s src_ip -d dst_ip [-h

max_hops] [-f first_ttl][-q type_of_service][-w timeout] [-z size]
Traces the IP router hops used to reach the host dst_ip from one of the source
IP interfaces on the GbE port. Valid arguments include:
• -s src_ip: Specifies the local IP address to use for sourcing the probe packets.
• -d dst_ip: Specifies the destination IP address to which to probe the IP router path.
• -h max_hops: Specifies the maximum hop limited used in the outgoing probe
packets.
The default of probing a maximum of 30 IP router hops. This operand is optional.
• -f first_ttl: Specifies the starting time to live value to first_ttl. The default is 1.
Traceroute skips processing for those intermediate gateways that are less than the
first_ttl hops. This operand is optional.
• -q service_type: Specifies the type of service in the ping request. The default is 0
and service_type must be an integer from 0 to 255. This operand is optional.
• -w timeout: Sets the time, in seconds, to wait for a response to a probe. The default is
5 seconds.
• -z size: Specifies the size, in bytes, of the trace route packet to use. The default is 64
bytes. The total size, including ICMP/IP headers (28 bytes without IP options) cannot be
greater than the IP MTU configured on the interface. This operand is optional.
Optional tunnel_arguments for fciptunnel create and modify include:

-f |--fastwrite 0|1] Enables (1) or disables (0) FastWrite on the specified FCIP tunnel.
-t |--tape-pipelining 0|1 Enables (1) or disables (0) Tape Pipelining on the specified FCIP
tunnel. If Tape Pipelining is enabled, FastWrite should also be enabled.
-c |--compression <mode> Configures compression on the specified FCIP tunnel. By
default, compression is disabled (0). Specify one of the following values:
• none Compression disabled.
• fast-deflate Enable fast-deflate compression.
• deflate Enable deflate compression.
• aggr-deflate Enable aggressive deflate compression level
-L | --load-leveling [default | failover | spillover] Configures spillover or failover load-
balancing method. -n |--remote-wwn remote-wwn Specifies the WWN of the remote FC
entity.
-d |--description string Specifies a description for the specified tunnel.
-F |--ficon 0|1 Enables (1) or disables (0) FICON emulation on the specified FCIP tunnel.
.<<truncated option list>>
For a complete circuit configuration a value must be set for a minimum and a maximum
committed rate to configure the tunnel for Adaptive Rate Limiting (ARL), which allows for a
more effective sharing of bandwidth between applications.
For the Brocade 7840 switch and SX6 blade, the valid range for -min-comm-rate to –max-
comm-rate is 20,000 Kbps through 10,000,000 Kbps for 10 GbE or 40 GbE ports. Both sides
of the tunnel must have matching configurations. The maximum committed rate can be no
larger than five times the minimum committed rate
-b | --min-comm-rate minimum
Modifies the minimum committed traffic rate on the FCIP circuit 0 in Kbps.
-B | --max-comm-rate maximum
Modifies the maximum committed traffic rate on the FCIP circuit 0 in Kbps
An incomplete circuit configuration can be configured for the SX6 blade and 7840 if some of
the parameters are not specified. The circuit will not be usable and will show an operational
status of ‘Incomplete’
FCIP_Local:admin> portshow fcipcircuit
Tunnel Circuit OpStatus Flags Uptime TxMBps RxMBps ConnCnt CommRt
Met/G
24 0 ge2 Up ---a---4 1d19h22m 0.00 0.00 1 500/500 0/-
24 1 ge3 InComp---a---4 0s 0.00 0.00 0 0/0 0/-
Flags (circuit): h=HA-Configured v=VLAN-Tagged p=PMTU
portcfg fcipcircuit <ve-port> <create|modify|delete> <circuitId>

[<parameters>]
Create parameters:
<remoteIp> <localIp> <commitedRate> [<optional args>]
or
<remoteIp> <localIp> --min-comm-rate <kbps> --max-comm-rate <kbps> [<optargs>]
Optional circuit args:

-a, --admin-status <0|1> - enable/disable the circuit
-s, --sack - turn sack off
-k, --keepalive-timeout <ms> - set the keepalive timeout in ms
-x, --metric <metric> - set the circuit metric
-b, --min-comm-rate <kbps> - set min comm rate value in kbps
-B, --max-comm-rate <kbps> - set max comm rate value in kbps
-m, --min-retrans-time <ms> - set min retrasmit time in ms
-r, --max-retransmits <rtx> - set maximum number of retransmits
-v, --vlan-tagging <vlan-id> - set the vlan-id for the circuit
--l2cos-f-class <l2cos> - set the L2CoS value for F-Class Traffic
--l2cos-high <l2cos> - set the L2CoS value for High Priority
--l2cos-medium <l2cos> - set the L2CoS value for Medium Priority
--l2cos-low <l2cos> - set the L2CoS value for Low Priority
--dscp-f-class <dscp> - set the DSCP value for F-Class Traffic
--dscp-high <dscp> - set the DSCP value for High Priority
--dscp-medium <dscp> - set the DSCP value for Medium Priority
--dscp-low <dscp> - set the DSCP value for Low Priority
Footnote 1: Although all ethernet ports can be assigned to each of the Data Processors
(DP0 or DP1) once you have one circuit within a tunnel linked to a specific DP all other active
circuits (main) within that tunnel must be linked to the same DP.
Footnote 2: The gigabit ethernet port (ge3) on 7840 FCIP_Local is connected to a routed
interface with the IP address 192.168.2.1
Footnote 3: The gigabit ethernet port (ge3) on 7840 FCIP_Remote is connected to a routed
interface with the IP address 192.168.6.1
Footnote 1: Remember on the 7840 platform the IP Interface configuration is tied to ge#.dp#
designation. Although all ethernet ports can be assigned to each of the Data Processors (DP0
or DP1) once you have one circuit within a tunnel linked to a specific DP all other active
circuits (main) within that tunnel must be linked to the same .
The following command outputs shows the error message that is displayed when attempting
to assign an IP interface assigned to DP1 to a VE controlled by DP0.
FCIP_Local:admin> portcfg fcipcircuit 24 create 2 --local-ip
192.168.4.2 --remote-ip 192.168.8.2 -b 500000 -B 1000000
IP Address does not exist on required DP context.
Local IP address 192.168.4.2 exists on DP:1
Footnote 2: When trunking across multiple FCIP circuits, the delta in bandwidth between the
circuits should be no greater than a factor of four. (same)
Trunking between a circuit running on an OC3 (155 Mbps) and another running on an OC12 (622
Mbps) is allowed
Trunking between a 10 Mbps circuit and a 500 Mbps circuit is not recommended
Footnote 1: VE_Ports are virtual E_Ports established over a FCIP tunnel. Some of the
parameters that cause VE_Ports to segment include domain overlap, zoning, and
incompatible fabric parameters. Note that these are the same parameters that will cause
E_Ports to segment (see fabstatsshow help information).
FCIP_Local:admin> fabstatsshow
Description Count
-----------------------------------------
Domain ID forcibly changed: 0
E_Port offline transitions: 0
Reconfigurations: 0
Segmentations due to:
Loopback: 0
Incompatibility: 0
Overlap: 0
Zoning: 0
E_Port Segment: 0
Licensing: 0
Disabled E_Port: 0
Platform DB: 0
Sec Incompatibility: 0
Sec Violation: 0
ECP Error: 0
Duplicate WWN:
Eport IsolatedAD header conflict: 0
Footnote 2: In the switchshow output above, VE_Port 24 is persistently disabled.
Footnote 1: The fabricshow output associated with establishing VE_Port connections is

no different than a fabricshow output established over E_Ports.
FCIP_Local:admin> topologyshow
2 domain(s) in the fabric; Local Domain ID: 1
Domain: 3
Metric: 1800
Name: FCIP_Local
Path Count: 1
Hops: 1
Out Port: 24
In Ports: 1/0
Total Bandwidth: 0.256 Gbps (adjusted)
Bandwidth Demand: 390 %
Flags: D
FCIP_Remote:admin> fabricshow
Switch ID Worldwide Name Enet IP Addr FC IP Addr Name
-------------------------------------------------------------------------
1: fffc01 10:00:00:05:1e:92:db:00 10.255.248.15 0.0.0.0 “FCIP_REmote"
3: fffc03 10:00:00:05:1e:55:a1:80 10.255.248.19 0.0.0.0 ”FCIP_Local"
The Fabric has 2 switches

The metric is derived from two paths at 100 Mbps, subtracted from 2000 = 1800.
Total bandwidth is derived from .128 Gbps per 100 Mbps. 200 x .128 = 0.256 Gbps.
Footnote 1: Using the portshow fciptunnel / fcipcircuit command without any

options will list all the fcip tunnels or circuits created.
The --detail option now automatically assumes the --perf option (if not using the --
config flag).
When not configured for FICON, the FICON emulation options are not displayed.
Continuation of the –detail output:
Receiver Stats : 4423272 bytes / 25939 pkts / 11.00 Bps Avg
Sender Stats : 4453508 bytes / 25937 pkts / 13.00 Bps Avg
TCP Bytes In/Out : 356663440 / 633964356 ReTx/OOO/SloSt/DupAck: 36
/ 2 / 33 / 0
RTT (min/avg/max) : 1 / 1 / 87 ms
Footnote 1: IP connectivity must be available between the local IP and the remote ha IP. For
example in the diagram, IP connectivity must exist between 192.168.1.2 and 192.168.5.12 for
the LBT to be created.
Footnote 1: A tunnel is considered protected if only 1 of its circuits if configured for HCL.
This process would need to be repeated for all circuits desired to stay up during a firmware
update (configured for HCL).
It is also possible to add the 2 additional HCL IP’s after the tunnel has been initially
configured. You would use the “modify” option.
FCIP_Local:admin> portcfg fciptunnel 24 modify --local-ha-ip
192.168.1.12 --remote-ha-ip 192.168.5.12
!!!! WARNING !!!!
Delayed modify operation will disrupt traffic on the fcip tunnel
specified. This operation will bring the existing tunnel down (if
tunnel is up) for about 10 seconds before applying the new
configuration.
Continue with delayed modification (Y,y,N,n): [ n] y
Footnote1: Tunnel 26 was added to show what this command would report for a tunnel
which was not configured for HA.
Footnote 1: Entering the same value in both fields is effectively setting a committed rate
without using Adaptive Rate Limiting (ARL).
The new tunnel is now created and active with status on each VE_Port being ‘Up’.
Test session configs do not persist across reboots

Up to 4 sessions can be configured on a DP at a time
Limit of 8 total sessions per 7840
Test sessions run in the background

This is opposite of TPERF on the 7800 where the console session would be controlled by TPERF
while it was running
Status and statistics can be dumped from the CLI
Allows for multiple test sessions to be managed from a single console/telnet session
Also allows the user to disconnect while the test continues to run
Footnote 1: Each side would need to be started independently or use the –b flag which starts
bi-directional traffic
Each configured test session consists of a sub-session that handles traffic in one direction
i.e. one sub-session for traffic from IP A to IP B and one sub-session for traffic from IP B to IP A
These sub-sessions can operate independently (each side must be started) or they can both
be started at the same time from one side
Therefore each side of the network will house the local sub-session’s transmit statistics and
the peer sub-session’s receive statistics
Once a session’s time has expired, the session will automatically stop
Statistics can still be displayed for that session
The session can be restarted at any time

When a session is restarted, the previous run’s results are stored for historical reference
Only one previous run is stored
WTOOL Stats Fields
If the IP interface is configured with a IP MTU of ‘auto’ then PMTU-Discovery will be used to
determine what MTU to use. Otherwise the configured IP MTU will be used.
The local session statistics will show the stats from the session started on this side.
The remote session statistics will show the stats for sessions that were started on the remote
side
Tool pulls configs from the circuit to build a test session

i.e. IP address, rate limit, VLAN, etc…
Minimum committed rate is used for the rate limit – aka no ARL
Example description:
The SLA named networkA is created with a packet-loss limit of 0.5%. It will run for the default
5 minutes and never timeout.
The SLA named networkB is created with a packet-loss limit of 1%. It will run for 10 minutes
and timeout after 30 minutes
Use the portcfg fcipcircuit command to assign an SLA to a circuit. The following
command modifies a circuit and assigns the SLA “networkA” to the circuit. Remember to
configure the other end of the circuit with a matching SLA.
Configured SLA’s can be shown via portshow command:
• FCIP_Local:admin> portshow sla
Name PktLoss Runtime Timeout

--------------------------------------------
sla1 1.00 2m0s 4m0s
--------------------------------------------

Modulos de 1 Al 5 BPSA300 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Modulos de 1 Al 5 BPSA300 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

BPSA 300

Brocade Professional SAN

Corporate Headquarters - San Jose, CA USA

European Headquarters - Geneva, Switzerland

Asia Pacific Headquarters - Singapore

© 2016 Brocade Communications Systems, Inc. All Rights Reserved.

Revision: August, 2016

Revision 0816 1–1

Revision 0816 1–2

Revision 0816 1–3

Revision 0816 1–4

Revision 0816 1–5

Revision 0816 1–6

Revision 0816 1–7

Revision 0816 1–8

Facebook — Brocade Certified

LinkedIn — Brocade Certified

MyBrocade Brocade University Community

MyBrocade Certification Community

MyBrocade Education Alumni Community

Revision 0816 1–9

Revision 0816 2–1

Revision 0816 2–2

Footnote 1: FC-FC routing supports the following configurations:

Revision 0816 2–3

Revision 0816 2–4

Footnote1: Interopmode is no longer supported on E_Ports beginning with Fabric OS v7.0,

Revision 0816 2–5

Footnote 1: In an FC-FC routed environment, when an RSCN is generated regarding a

Revision 0816 2–6

Revision 0816 2–7

Revision 0816 2–8

Revision 0816 2–9

Footnote 2: Backbone FIDs can be administratively configured using the fcrconfigure

Virtual Fabrics is covered in a separate module in this class.

DPR = Destination Router Port

Notes continued on next page

The router port cost has the following considerations:

Footnote1: The Shortest IFL Selection feature is disabled by default.

Notes continued on next page

• 8-Gbps port blades (FC8-16, FC8-32, FC8-32E, FC8-48, FC8-48E,

Footnote 5: Use the fosconfig –-enable fcr to enable FC-FC routing.

Create an enforce LSAN tag: fcrlsan --add –enforce <tag>

Create a speed LSAN tag: fcrlsan --add –speed <tag>

Display the current enhancement/speed LSAN tags:

Delete an enhancement or speed LSAN tag:

Delete all enhancement or speed LSAN tags:

Revision 0816 3–1

Revision 0816 3–2

Revision 0816 3–3

Revision 0816 3–4

Revision 0816 3–5

BB_G620:admin> fddcfg --showall

Fabric Wide Consistency Policy:- ""

Revision 0816 3–6

Preparing Fabrics for Routing (cont.)

Revision 0816 3–7

Revision 0816 3–8

Revision 0816 3–9

The portcfgexport command is used to place an FC port into EX_Port mode

Verify Connectivity – Backbone (cont,)

Index Port Address Media Speed State Proto

Router2:admin> fcrrouterportcost 8 10000