BCFP CFP300 StudentGuide

CFP 300
BROCADE
CERTIFIED FABRIC
PROFESSIONAL
16 Gbps TRAINING
(Student Guide)
Brocade University
Revision <#> Revision 0312
Brocade Certified Fabric Professional 16 Gbps Training
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
© 2012 Brocade Communications Systems, Inc. All Rights Reserved.
Brocade, the Brocade B-weave logo, Fabric OS, File Lifecycle Manager, MyView, Secure Fabric
OS, SilkWorm, and StorageX are registered trademarks and the Brocade B-wing symbol and
Tapestry are trademarks of Brocade Communications Systems, Inc., in the United States and/or
in other countries. FICON is a registered trademark of IBM Corporation in the U.S. and other
countries. All other brands, products, or service names are or may be trademarks or service
marks of, and are used to identify, products or services of their respective owners.
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: 0312
CFP 300 Course Introduction
Revision 0312 1–1

Revision 0312 1–2

CFP300 web-based training does not have to be completed before the instructor-led
training.
Revision 0312 1–3

Revision 0312 1–4

Revision 0312 1–5

This course also includes web-based training components.
Revision 0312 1–6

The materials are available only online and will not be taught by your instructor.
The scope of this course does not cover the FCoE related products. For information
regarding the FCoE family of products, refer to the Brocade FCoE 101 Introduction to
Fibre Channel over Ethernet (FCoE) course.
Revision 0312 1–7

Revision 0312 1–8

Learn more about the program at our website:

http://www.brocade.com/education/certification-accreditation
Revision 0312 1–9

Revision 0312 1 – 10
Registering for a certification exam:

• Visit http://www.pearsonvue.com/brocade
• Call 866-361-5817 toll-free in North America
• Visit http://www.pearsonvue.com for other contact numbers worldwide (some
locations may not have toll-free numbers)
Registering for an accreditation exam:
• https://www.webassessor.com/wa.do?page=publicHome&branding=BROCADE
Footnote 1: Brocade University releases nutshell guides for each certification exam. The
guides are named after the exam, i.e. BCFP in a Nutshell, and are available from the
Brocade University certification page: http://www.brocade.com/education/certification-
accreditation.
<Course Number> Course Introduction
Facebook — Brocade Certified

http://www.facebook.com/pages/Brocade-Certified/161604617227755
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 <mmyy> 1 – 13
For a list of Brocade University courses please see our website:

http://www.brocade.com/education/product-training/index.page.
Footnote 1: Use CTRL+6 as a shortcut to create PDF notes.
CFP 300 FC-FC Routing Theory
Revision 0312 2-1

Revision 0312 2-2

Revision 0312 2-3

FC-FC routing was introduced in Fabric OS v5.1 on the Brocade 7500 and Brocade FR4-
18i blade. 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 0312 2-4

For the latest list of Brocade tested and approved platforms, firmware revisions, and
scalability guidelines visit www.brocade.com.
These requirements reflect testing performed by Brocade, and may be different from
those specified by your Brocade switch provider. As always, your switch provider sets the
guidelines and definitions that you should follow.
Revision 0312 2-5

Footnote1: Interopmode is no longer supported on E_Ports beginning with Fabric OS

v7.0, but is allowed on EX_Ports.
Revision 0312 2-6

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.
Footnote 2: In an FC-FC routed environment, EX_Ports can be set to specific

interoperability modes. Each edge fabric maintains its own interoperability
configurations. For example, an FC Router can connect an interoperability EX_Port to an
M-EOS fabric, and it will not have any impact on the backbone fabric nor the other edge
fabrics.
Revision 0312 2-7

Revision 0312 2-8

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.
Revision 0312 2-9

Revision 0312 2 - 10
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: The FC router backbone fabric and Virtual Fabric base switch share the
same FID. 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 while a VF enabled edge fabric would have the FID
configured locally within the edge fabric.
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 and the switch must be
disabled using the switchdisable command.
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.
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 1-Open 2-McDATA Fabric, 3-McDATA
Fabric Legacy]
[-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.
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 M-EOS. 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_B51: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.
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.
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.
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.
Footnote 1: Training course CFA200: Brocade Certified Fabric Administrator (BCFA) 16

Gbps Training has additional information on ASICs and hardware platforms. You can
access this information through the Brocade University learning management system
(my.brocade.com).
Footnote 2: If the license is removed while EX_Ports are online, EX_Ports continue to
function until the next fabric rebuild, switch disable, or port offline event.
router:admin> licenseshow
Integrated Routing license
AXQYN3mMKa3DXBAmJRWfFPTaHRNtRZPFB7ZAR:
<truncated output>
Footnote 3: Not supported on:
• DCX ICL ports
• FC10-6 10 Gbps blade
• 8 Gbps blades in the Brocade 48000
• Brocade 300
• All 4 Gbps switches and blades except the Brocade 7500 and FR4-18i
• All embedded switches both 4 and 8 Gbps
Footnote 4: FC8 are 8 Gbps port blades, FX8 is the distance extension blade and FS8 is
the encryption blade. FC routing over FCIP ports, VEX_Ports , is supported on the FX8-24
blade and Brocade 7800 switch.
Footnote 5: Check corresponding Release Notes for latest information.

Footnote 6: 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.
FR4-18i: When an FR4-18i or FX8-24 blade is inserted, all of its Fibre Channel ports are
persistently disabled by default.
If FR4-18i EX_Port is online, Condor2 EX_Ports cannot be configured and enabled. The
reverse is also true, where FR4-18i EX_Ports cannot be configured and enabled if online
Condor2 EX_Port are enabled on the DCX/DCX-4S chassis.
If EX_Ports are present on the FR4-18i blade, upgrade to Fabric OS v7.0.0 is prevented.
EX_Ports are not supported on the FR4-18i blade in Fabric OS v7.0.0. VEX_Ports
continue to be supported on this blade, however.
Footnote 1: TopTalkers in F_Port mode is supported with IR.

Footnote 2: Previous versions of Fabric OS do not support IR and TopTalkers running
concurrently.
Fabric OS v7.0.0 Scalability

Refer to the scalability guide for additional details and latest supportability.
FC-FC Routing Scalability (MetaSAN)
Max # edge fabrics per metaSAN 48

Max # FCR switches per metaSAN 241
Max # LSAN device per metaSAN 10,000
Max # LSAN zones per metaSAN 5,0002
Footnote 1: All BB FCRs with Fabric OS v6.0.0 and above.

Footnote 2: This is the maximum configured setting. The default limit is 3,000. Change
the configured limit using the fcrlsancount command.
FC-FC Routing Scalability (Backbone)
Max # L2 switches per backbone fabric 12

Max # FCR’s per backbone fabric 12
Max # total domains per backbone fabric1 60
Max # WWNs per backbone fabric 1024
Footnote 1: This number of domains includes the switch domain IDs, Front Domain(fd)
IDs, and Translate Domain(xd) IDs.
FC-FC Routing Scalability (Edge)

Max # switches per edge fabric (FOS) 26
Max # switches per edge fabric (M-EOS fabric)1 2 24
Max # Front Domains per edge fabric 10
Max # Total Domains per edge fabric (FOS)3 85
Max # Total Domains per edge fabric (M-EOS)3 31
Max # WWNs per edge fabric (FOS) 1500
Max # local and remote WWNs per fabric 1500
Max # imported devices per fabric 1000
Max # devices per LSAN zone 64
Footnote 1: M-EOS fabrics must be running M-EOS 9.6.2 firmware or later.

Footnote 2: Mi10k must be running M-EOSn 9.9.5 or greater when in edge fabric
connected to Brocade 7800 FCR Backbone.
Footnote 3: This number of domains includes the switch domain IDs, Front Domain(fd)
IDs and Translate Domain(xd) IDs.
Footnote 1: Lowest backend port number becomes new master port, not the lowest
front end switch port number (normal user port). The backend port number is used by
the ASIC for the associated front end switch port number and are different (may be
higher or lower).
The topology in this slide illustrates that FCR2 has two DRPs (EX_2 and EX_3) to route
the frames from Fabric 1 to Fabric 2. Prior to Fabric OS v6.2, FCR2 would use both DRP1
(EX_2) and DRP2 (EX_3) across FCIP link to route the frames to Fabric 2. In Fabric OS
v6.2 and later, FCR2 uses DRP1 (EX_2) only, as that DRP is the only local DRP.
R11-ST10-B51:admin> fcrfabricshow
FC Router WWN: 10:00:00:05:1e:9a:71:af, Dom ID: 98,
Info: 10.255.240.76, "R11-ST10-B51"
EX_Port FID Neighbor Switch Info (enet IP, WWN, name)
------------------------------------------------------------------------
3 10 10.255.240.75 10:00:00:05:1e:0b:ba:7e "R11-ST10-B30“
With LSAN zone binding, FC Router 1 will processe 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 which specifies pairs of FC routers in
the backbone fabric that can access each other, and an LSAN fabric matrix which 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 setup 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 5 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 setup 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 Enforce tag is defined on the router only Enforce tagged LSAN zones and
Speed tagged LSAN zones are imported by the router. If 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.
CFP 300 FC-FC Routing Admin
Revision 0312 3-1

Revision 0312 3-2

Revision 0312 3-3

Revision 0312 3-4

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

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

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

Local Switch Configuration for all Databases:-
DATABASE - Accept/Reject
---------------------------------
SCC - accept
• Tolerant policies display: "SCC; DCC―
DCC - accept
• Strict policies display: "SCC:S;
PWD - accept DCC:S―
FCS - accept • A strict SCC and a tolerant DCC policy
AUTH - accept output displays: "SCC:S; DCC"
IPFILTER - accept
Fabric Wide Consistency Policy:- ""
Revision 0312 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 0312 3-7

Footnote 1: 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, as indicated in the command output.
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 0312 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 0312 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, 1: M-Series Open
Fabric 1.0 mode (and Brocade Interop mode), 2: M-Series McDATA Fabric mode used
when the neighboring M-Series switch is running OS version such as 6.0.2 or later, 3:
M-Series Fabric Legacy mode, for the legacy M-Series ED5000 platform)
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
Current Domain ID: 120 pool of WWNs by the FC
WWN: 50:00:51:e7:e2:62:ee:0a router to 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) or active
Zone Set (M-EOS).
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).
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.
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.
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 5100 (switchType: 66.1).
• 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_B30" 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_B51:admin> switchshow
switchName: BB_B51
switchType: 66.1
switchState: Online
switchMode: Native
switchRole: Principal
switchDomain: 98
switchId: fffc62
switchWwn: 10:00:00:05:1e:7e:26:2e
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 -- N8 No_Module FC
1 1 620100 id N4 Online FC Loopback->Port 1
2 2 620200 id N4 Online FC Loopback->Port 2
3 3 620300 id N8 Online FC EX-Port 10:00:00:05:1e:0b:96:8f
"Edge_B30" (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:00:05:1e:7e:26:2e
• Domain ID = 98
• IP address = 10.255.240.33
• Switch name = BB_B51
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_B30
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 AL_PA 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 AL_PA 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.
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
Note: The switch must be disabled to change the backbone fabric ID, valid range for
backbone fabric IDs is 1-128.
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
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
• M-Series Open Fabric 1.0 mode (and Brocade Interop mode)
• M-Series McDATA Fabric mode used when the neighboring M-Series switch is
running OS version such as 6.0.2 or later
• M-Series Fabric Legacy mode, for the legacy M-Series ED5000 platform)
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.
Specify the FC parameters:

8. Specify FC parameters using the Speed, Ingress Rate Limit, and Long Distance
Mode 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 be displayed
13.To enable the EX_Port select it from the list and click 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
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
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

7. 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
8. 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.
9. 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
10.Change the Zoning Scope to one of the routed fabrics.

11.Refresh the Zone DB.
12.Accept the message that the Network Advisor DB will be overwritten with the one
currently active in the fabric.
13.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 domains 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
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_B51: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_B51: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 6206e4 Imported
100 10:00:00:05:1e:57:7c:79 01f001 10 030100 Imported
Total devices displayed: 2
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>
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-AL_PA 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 supportsave command output includes information from the following FC

routing-related CLI commands: fcrproxydevshow, fcrphydevshow,
portcfgexport, fcrxlateconfig, fcrrouteshow, lsanzoneshow, and
fcrfabricshow.
BB_B51:admin> switchdisable
BB_B51:admin> fcrlsan --add –enforce local
Lsan Tag set successfully.
BB_B51:admin> fcrlsan --add -enforce BRCD
BB_B51:admin> fcrlsan --add -enforce remote
BB_B51:admin> fcrlsan --remove -enforce BRCD
BB_B51:admin> fcrlsan --show -enforce
Total lsan Tags : 2
enf : local
enf : remote
BB_B51:admin> fcrlsan --add -speed super
BB_B51:admin> fcrlsan --show -speed
speed : super
CFP 300 Fibre Channel over IP Theory
Revision 0312 4-1

Revision 0312 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 0312 4-3

Footnote 1: Distances that utilize native FC 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 0312 4-4

Revision 0312 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 storage area networks over IP-based
networks
• Distance Extension over IP LAN/WAN/MAN
Revision 0312 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).
Revision 0312 4-7

Revision 0312 4-8

Revision 0312 4-9

Retired Products:
7500 switch
7500E switch
FR4-18i blade (DCX, DCX-4S and 48000 director chassis)
Footnote 1: An Upgrade License is required to enable all 16 FC ports and 6 GbE ports.
Footnote 2: Two GbE ports can be configured for copper (via built-in RJ45) or optical (via
SFP module) cable connectivity. The other four GbE ports offer optical SFP module only.
SFP ports will also accept 1 Gbps copper SFPs, Avago part number ABCU-5700RZ-BR1.
Footnote 3: Link speeds of 1 Gbps require a 4 Gbps Brocade-branded SFP.
Footnote 4: The Inband Management feature allows a customer to define one or more IP
addresses on the nonmanagement GE ports and will provide a management path from
the WAN network to the switch CP. Customers can then use the IP addresses to access
SNMP events, telnet, etc.
Footnote 1: The top two GbE ports (GE0 and GE1) are configured for copper using built-
in RJ45. In standard configuration, users have the option of using either the top two GbE
ports, which are configured for copper SFPs, or the bottom two, left-most, GbE ports
(GE0 and GE1) which are configured for optical SFPs. The remaining four GbE ports can
use either optical or copper via SFP module up to 1 Gbps. It is possible to configure GE0
as copper and GE1 as optical and vice versa.
Fabric OS identifies power supplies left to right as Power Supply #1 and Power Supply
#2. The Brocade 7800 requires a minimum of one power supply (connected and
powered on) for switch operation.
Fabric OS identifies the fan assemblies left to right as Fan #1 and Fan #2.
Weight: 9.3 kg (20.6 lb)1
Dimensions:
Width: 42.87 cm (16.88 in)
Height: 4.30 cm (1.70 in) or 1U
Depth: 61.0 cm (24.02 in)
Power Consumption: 84 Watts nominal, 91 Watts maximum
Both weight and power consumption numbers assume Brocade 7800 with two power
supply/fan FRUs and zero SFPs installed.
The base unit has 2 GbE ports available for use. They can be the two copper ports, or
the two fiber ports. The default is copper. The upgrade license is named the 7800
Upgrade license.
Footnote 1: The FICON Acceleration features are controlled by the FICON Acceleration
slot-based license. The FICON Teradata Emulation is only supported between FICON
Channels and FICON Teradata controllers. If a customer has an ESCON Teradata
controller, they should upgrade the controller to have FICON interfaces.
There are several new capabilities added for FICON acceleration in FOS v7.0. They are:
• Support for Optica’s Prizm connected 3480, 3490 and 3590 ESCON Tape control
units
• Support for Optica’s Prizm and ESBT connected 3480 Bus and Tag Tape control
units
• New FICON Acceleration Feature or Teradata controllers
• New FICON Acceleration Feature for various Printers
Please refer to the Release Notes for the most up-to-date information.
Enabling either of the 2 x10 GbE ports requires a 10GbE FCIP license, which is a slot-
based license.
Footnote 1: The supported operational modes are:
• 10 x 1 GbE port
• 10 x 1 GbE ports and 1 x 10 GbE port
• 2 x 10 GbE ports
Footnote 2: Check release notes for FOS version support. Only two blades are supported
in a chassis with FOS v6.3.X.
Each Cavium processor has 4G of DDR memory.
Footnote 1: Typically, port groups for Condor2 ASICs are 8-port trunk groups. There are
40 ports on a Condor2 ASIC. As seen in the notes section of the previous slide, there is
a 5-port trunk to each of the four Blaster FPGAs. By definition, a trunk must be created
from the same octet. This means that each octet from a Blaster trunk octet has 3 ports
remaining in the octet. Thus, Brocade engineers used the available ports to create 2
other 2-port trunks to use some of the remaining ports.
Weight: 3.2 kg (7.0 lb)1
Dimensions:
Width: 3.60 cm (1.41 in)
Height: 42.06 cm (16.56 in)
Depth: 29.89 cm (11.77 in)
Power Consumption: 235 Watts nominal
Approximate weight with zero SFPs installed. The minimum power consumption of the
Brocade FX8-24 Extension Blade is 235 watts with 0 optical SFPs installed running at 8
Gbps.
Footnote 2: VEX_Ports on the FX8-24 are supported on FOS v6.4 and later.
Footnote 1: Requires the 10Gbps license.
Footnote 1: This license enables the two 10GbE ports on the FX8-24 or the 10G FC
capability on FC16-xx blade ports. On the Brocade 6510, this license enables 10G FC
ports. This license is available on the DCX/DCX-4S/DCX8510-8/DCX8510-4 on an
individual slot basis.
• FX8-24: With this license assigned to a slot with an FX8-24 blade, two additional
operating modes (in addition to 10 1GbE ports mode) can be selected;10 1GbE
ports and 1 10GbE port, or 2 10GbE ports
• FC16-xx: Enables 10G FC capability on an FC16-xx blade in a slot that has this
license
• Brocade 6510: Enables 10G FC capability on the switch
Footnote 2: The FICON Acceleration features are controlled by the FICON Acceleration
slot-based license. The FICON Teradata Emulation is only supported between FICON
Channels and FICON Teradata controllers. If a customer has an ESCON Teradata
controller, they should upgrade the controller to have FICON interfaces.
There are several new capabilities added for FICON acceleration in FOS v7.0. They are:
• Support for Optica’s Prizm connected 3480, 3490 and 3590 ESCON Tape control
units
• Support for Optica’s Prizm and ESBT connected 3480 Bus and Tag Tape control
units
• New FICON Acceleration Feature or Teradata controllers
• New FICON Acceleration Feature for various Printers
Footnote 1:
FCIP Tunnels:
• B7800 - up to 8 VE_Ports
• FX8-24 - up to 20 VE_Ports
FCIP Trunking:
• B7800 - up to 4 circuits per trunk
• FX8-24 - up to 4 circuits per trunk for 1 GbE; up to 10 circuits per trunk for 10
GbE
Footnote 2: 10GbE FCIP, Advanced Extension and FICON Accelerator licenses for
FX8-24 supported in DCX and DCX-4S are slot based licenses
Footnote 3: Not supported in pre Fabric OS v6.3.0 release.
Footnote 1: IPSec will not be supported with IPv6 implementations.
Certified (Support is through the SFP vendor)

1/2/4 Gbps ELWL - 50km
1/2/4 Gbps ELWL - 100km
1/2/4 Gbps CWDM - 1470nm - 80km
1/2/4 Gbps CWDM - 1490nm - 80km
1/2/4 Gbps CWDM - 1510nm - 80km
1/2/4 Gbps CWDM - 1530nm - 80km
1/2/4 Gbps CWDM - 1550nm - 80km
1/2/4 Gbps CWDM - 1570nm - 80km
1/2/4 Gbps CWDM - 1590nm - 80km
1/2/4 Gbps CWDM - 1610nm - 80km
1/2/4 Gbps DWDM 80km (25 wavelengths from 1530nm-1560nm)
2/4/8 Gbps CWDM 40km(8 wavelengths from 1290nm-1430nm)
For the most up-to-date support, refer to the following site:

http://www.brocade.com/products-solutions/products/tranceivers/index.page
Footnote 1: FC flow control mechanisms include R_RDYs and ACKs. FC communications

also utilize long distance modes, BB credits, and VC channels.
Footnote 1: As of Fabric OS v6.4.0, VEX_Ports are supported on the FX8-24.
Footnote 1: There are 8 VE_Ports for 6 physical ge ports on the 7800 16/6. An FX8-24
blade can support 20 VE_Ports, and therefore 20 FCIP tunnels. Each FCIP tunnel is
associated with a specific VE_Port. On FX8-24 blades, and on the 7800 switch, VE_Ports
do not have to be associated with a particular GbE port.
VE_Ports 12 through 21 may use GbE ports ge0 through ge9, or they may use XGE port
1. VE_Ports 22 through 31 can only be used by XGE port 0. The total bandwidth cannot
exceed 20 Gbps.
VE ports and GbE ports are no longer 1:1 associated as they were on the 7500 and
FR4-18i.
VE and GbE ports can have a 1:1 association, but they are not limited by the design.
Footnote 1: Configuring a tunnel with more than one circuit requires an Advanced
Extension license. Without a license present, a second circuit will not be allowed to be
configured. The administrator will receive a message stating as such.
3 Modes of operation for the Ethernet ports on FX8-24:

1G Only Mode: 10 x 1 Gbps ports are available for use (GE0 through GE9)
10G Only: 2 x 10 Gbps ports are available for use (XGE0 and XGE1)1
Dual Mode: 10 x 1 Gbps ports and 1 x 10 Gbps port available for use (GE0 through
GE9, XGE0)
In almost every case, while the mathematical limits may allow for higher circuit counts,
there is a limit based on the number of available 1GE/10GE ports and the limits of how
many circuits can exist on those ports regardless of tunnel ownership. For example with
a single GE port, you can have 1 tunnel with 4 circuits, or 4 tunnels with 1 circuit each.
That is the limit though. That particular GE port cannot have any more circuits. So in
almost every case, the total circuit count limit is calculated based on the available GE
ports and the GE port circuit limit, not the number of tunnels or the number of circuits
per tunnel. Here are the specific cases.
B7800 4/2 - In this mode you can have at most 2 tunnels, and up to 6 circuits per
tunnel. However there is a limit to only 4 circuits per GE port, and since we can only use
2 GE ports, we are limited to a total of 8 circuits. This could be in a configuration where
one tunnel has 6 circuits (4 on one GE, and 2 on the other), and then the other tunnel
can only have 2 circuits on the second GE port. The typical case would be more similar
to how Ben listed it though where you would have 2 tunnels with 4 circuits each. So the
main limit here is the number of circuits per GE port (regardless of which tunnel they
belong to).
B7800 16/6 - In this mode all GE ports are available. There are a total of 8 tunnels
available, and again each tunnel can have upto 6 circuits. However again we have a
limit of 4 circuits per GE port (regardless of tunnel ownership), and a total of 6 GE
ports. So our limit is again enforced by the number of GE ports giving us a total value
of 24 available circuits split up however you want amongst the available tunnels.
FX8-24 1G - In this mode, we only have the first 10 Tunnels available, and each of
those tunnels can have up to 10 circuits. However we are again limited to only 4
circuits per 1GE port, and a total of 10 x 1G ports gives us a total of 40 circuits in the
system. This can be split up to 4 tunnels with 10 circuits each, or 10 tunnels with 4
circuits each, or anything between. The limit is enforced the same though, so the
limit is still 40.
FX8-24 Dual Mode - In this mode the first 10 tunnels (VE12-VE21) are available the
same as in the FX8-24 1G Mode case, so there is a total of 40 circuits available
there. Then for the second 10 tunnels (VE22-VE31), we only have a single 10G port
available, and so there is a limit to 10 circuits total on that 10G port. So this can be
either in a 10 tunnels with 1 circuit each, or 1 tunnel with 10 circuits, or something
in between again. But the limit is still 10 circuits total on that 10G port. This gives
this configuration a maximum limit of 50 circuit for the entire blade.
FX8-24 10G w/o crossport - In this mode, we have two 10G ports available and the
limit is 10 circuits total on those 10G ports split up however you want on the
available tunnels. This gives a total of 20 circuits total on the system split up
amongst the tunnels.
FX8-24 10G w/ crossport - In v7.0 crossport was introduces which allowed VE12-21
to make use of XGE0 in a crossport configuration, and VE22-31 to make use of XGE1
in a crossport configuration. Using the correct bandwidth restrictions and metric
values for failover, it is then possible to create a total of 40 possible circuits across
all tunnels. There are some complex bandwidth restrictions when using the
crossport configurations, but that is another topic entirely. If needed I can delve into
that further, but as for actual circuit number limits this isn’t needed.
Footnote 1: 10 Gbps rate is limited to the 10 GbE ports using Multi-Gigabit Circuits.
Example tunnel/circuit creation:

A tunnel using VE_Port 16 is created with an initial circuit 0 with a maximum rate of
1Gbps, metric of 0.
• IPPM_LINK_UP.bandwidth = 1Gbps
Circuit 1 is added to Tunnel 16 with a max rate of 500Mbs, metric 0.
• TUNNEL_UPDATE.bandwidth = 1.5 Gbps
Circuit 2 is added to Tunnel 16 with a max rate of 1Gps, 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 16 with a max rate of 1Gps, metric 1.
• Since this is a higher metric, it is considered a standby and no TUNNEL_UPDATE is
generated.
Example circuit failures/recovery (after initial creation state)

Circuit 1 fails.
• Since this was a low metric circuit (active) we will try to re-establish, no
TUNNEL_UPDATE is sent to CP (and no updated will be sent once it re-
establishes).
Circuit 0 fails, 1 is still failed.
• Since this is the last of the low metric circuits, the tunnel will failover to the next
lowest circuits, which are circuits 2 and 3. Since the combined bandwidth of
circuits 2 and 3 is different than circuits 0 and 1, a TUNNEL_UPDATE.bandwidth =
2.0 Gbps is generated to the CP.
Circuit 0 and 1 come back on line.
• Since these are again the low metric circuits, we will resume traffic on these
circuits and 2 and 3 become the hot standbys. Since the bandwidth has changed
again, a TUNNEL_UPDATE.bandwidth = 1.5 Gbps is generated to the CP. Note
that the bandwidth was reduced.
Example circuit deletions (after initial creation state);

Circuit 1 is deleted.
• Since this was a low metric circuit, all traffic will be directed to circuit 0. Again,
the bandwidth has changed so the tunnel will generate a
TUNNEL_UPDATE.bandwidth = 1.0 Gbps to the CP.
Deleting circuits 2 or 3 at this point would have no affect since they are standby and
the bandwidth is not included in the calculations.
Example circuit metric changes (after initial creation state);
Circuit 1’s metric is changed to 1.

• Since this was a low metric circuit, all traffic will be directed to circuit 0. The
bandwidth has changed, so the tunnel will generate a
TUNNEL_UPDATE.bandwidth = 1.0 Gbps to the CP. This would basically have the
same affect on bandwidth as if deleting the circuit instead.
Circuit 3’s is changed to metric 0 (circuit 1 still has a metric of 1)
• Since this was a high metric circuit changed to a low. The bandwidth has
changed, so FTNL will generate a TUNNEL_UPDATE.bandwidth 2.0 Gbps to the CP
(circuit 0 and circuit 3 are now “active”, circuits 1 and 2 are now in “standby”
mode).
Footnote 1: Prior maximum was 4.
Footnote 1: 10 tunnels for all 1 GbE ports and 10 tunnels per 10 GbE port
Footnote 2: 10 tunnels per 10 GbE port
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.
Time out values:

• Default FICON is 1 sec
• Default FC is 4 sec
• Depending on the solution being extended, the time out values may need to be
changed from default.
Footnote 1: 3 Modes of operation for the Ethernet ports on FX8-24:

• 1G Only Mode: 10 x 1 Gbps ports are available for use (GE0 through GE9)
• 10G Only: 2 x 10 Gbps ports are available for use (XGE0 and XGE1)
• Dual Mode: 10 x 1 Gbps ports and 1 x 10 Gbps port available for use (GE0 through
GE9, XGE0)
Each circuit will be configured with a metric of 0 (active) or 1 (standby)

The metric will be used by the tunnel to determine which circuits will be used as active
circuits
Metric 0 circuits have the lowest metric and will be designated as active circuits and will
be used for all data transfers
Metric 1 circuits are classified as standby circuits. It is in standby mode in the event that
all metric 0 circuits fail
In active/active, best practice is to use Adaptive Rate Limiting to allow optimal
bandwidth usage.
Footnote 1: On FX8-24 running pre-FOS v7.0, to create a tunnel in an LS, both the VE-
port and the corresponding GE-port needs to be in the same LS. Starting with FOS v7.0,
this limitation is removed, that is, VE ports in different Logical Switches (LS) will be able
to share a GE-port/xGE-port which is present in the Default- Switch(DS). The GE-
port/xGE-ports in other logical switches or the Base Switch cannot be shared.
Additionally, creating tunnels using a mix of dedicated (within the same Logical switch)
and shared (in the default switch) GE/xGE ports is not supported. VE-ports created out
of shared GE/xGE ports will come up as regular VE ISLs in their respective logical
switches. All of the ARL committed-rate restrictions and bandwidth sharing of the GE
and xGE ports remain the same even when the GE and xGE ports are shared across the
LS.
To learn more about Brocade Virtual Fabrics, please refer to the Brocade AFS141 web-
based training course
Footnote 2: 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. This feature is
supported only on FX8-24 blades in both 1G and 10G modes.
Footnote 1: Software compression was available on the Brocade 7800 with FOS v6.3.0.
Software compression for the FX8-24 was introduced in Fabric OS v.6.4.0.
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.
Software compression is supported for:

Brocade 7800 - Fabric OS v6.3.0 and later
FX8-24 – Fabric OS v6.4.0 and later
-c | --compression compression_level
Configures compression on the specified FCIP tunnel. By default,
compression is disabled (0). Specify one of the following values:
0 Compression disabled
1 Standard compression
2 Moderate compression
3 Aggressive compression
4 Auto compression. Automatically adjusts compression level based on the
maximum configured tunnel bandwidth. The To enable this feature you must
upgrade both ends of the tunnel to Fabric OS v7.0.0. Based on total effective
tunnel bandwidth, the compression level will be adjusted as follows:
Aggressive Bandwidth less than 512 Mbps
Moderate Bandwidth more than 512 Mbps and less than 2 Gbps.
Standard Bandwidth more than 2Gbps.
Option 1 (Standard mode) is for maximizing the overall per box/blade throughput.
Traffic is compressed by hardware only. Provides roughly 2:1
Option 2 (Moderate mode) supports 8 Gbps of FC traffic (HW +SW). This mode also
uses both hardware and software compression. If the rate is exceeded, frames will by-
pass software compression but will still be compressed by hardware. The 8 Gbps limit
is on a per FCIP complex basis (7800 has 1 FCIP complex and FX8-24 has 2 FCIP
complexes). Provides roughly 2.5:1
Option 3 (Aggressive mode) is for maximizing the compression ratio (software only). If
FC throughput runs over 2.5 Gbps, frames will begin by-passing compression. The 2.5
Gbps limit is on a per FCIP complex basis (7800 has 1 FCIP complex and FX8-24 has 2
FCIP complexes). Provides roughly 4:1
Option 4 (Auto Mode) On FX8-24 and 7800, a new compression mode viz. “auto-mode”
will be supported starting with FOS v7.0. This feature will adjust the compression mode
(1, 2 or 3) based on the maximum configured tunnel bandwidth. In the auto mode,
best compression mode is selected based on the configured maximum bandwidth of
the tunnel and advanced compression bandwidth usage in the system. Total supported
bandwidth by the advanced compression is a shared resource that will be shared by all
tunnels that are configured in the auto mode or otherwise configured with advanced
compression. If a tunnel is configured with minimum and maximum bandwidth values,
the Auto mode selects the actual compression mode based on the maximum
configured bandwidth. The following table illustrates how the compression level will
change based on bandwidth usage when the tunnels are configured in AUTO mode.
Symmetric compression mode should be configured on both end points of a tunnel,
that is, “auto-mode” should be the same on either end-of the tunnel. Otherwise, the
tunnel will not come-up. Auto mode feature is new in FOS v7.0. Therefore both ends of
the FCIP tunnel need to be upgraded to FOS v7.0 before enabling the feature.
Footnote 1: 10GbE ARL

The 10GbE ARL feature allows the users to configure minimum and maximum rates for
each circuit of a tunnel that is using xge0 or xge1 on an FX8-24 blade.
The 10GbE ARL feature provides the following capabilities:
• Support for ARL on tunnels over the 10GbE ports.
• Maximum guaranteed rate of 10Gbit/s combined for all tunnels over a single 10GbE
port.
• Maximum rate (max rate) of 10Gbit/s for any single circuit.
The 10GbE ARL feature has the following dependencies and assumptions:
• Symmetric bandwidths on each end of a configured circuit.
• No more than a factor of 5 between the minimum and maximum rates.
Backward Compatibility
This feature is backwards compatible with 1GE ports on either 7800 or FX8-24. For
10GbE port to 10GbE
port connections, ARL is supported only if both ends are running FOS v7.0.
Please refer to Fabric OS FCIP Administrator’s Guide for restrictions that are applicable
from previous releases.
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.
ARL - Optimization After a Path Failure
With 1 interface online, When a 2nd interface is enabled the network

all available bandwidth is experiences a congestion event and the first interface
About 20
consumed up to the drops its rate down to the minimum configured rate.
seconds to
maximum rate From here it will seek the ceiling again
find ceiling
100%
80% Tunnel 1
60%
Tunnel 2
40%
20% Max Commit
0%
Min Commit
This interface steps up to

The 2nd interface fully utilize the available
starts by claiming its Blips are TCP WAN BW. It stops seeking a
minimum configured testing the ceiling ceiling at the maximum
rate configured rate
Offline equipment/link results in

available BW
Original Virtual Channel Model
VC # Assigned to
0 Class F
1 Class 2 Ack/Link Control
2 Data
Data
All
3
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. 6 frames of High priority traffic then,
3. 3 frames of Medium priority traffic then,
4. 1 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 FOS
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.
Command syntax: portcfg mgmtif [<slot>/]<gePort> [create|delete]

<ipAddress> <netmask> [<mtu>]
Example:
7800 SW1
portcfg mgmtif ge0 create 192.168.3.10 255.255.255.0
7800 SW2
Management Station can now Telnet to 192.168.3.10 and 192.168.3.20.
Example:
7800 SW1
1. Configure the inband management interfaces.
2. Configure the inband management route for the management station.
portcfg mgmtroute ge0 create 192.168.3.0 255.255.255.0 192.168.1.250
7800 SW2
1. Configure the inband management interfaces.
2. Configure the inband management route for the management station.
portcfg mgmtroute ge0 create 192.168.3.0 255.255.255.0 192.168.2.250
Management Station
1. Add route entries to access the 7800 external inband management interfaces.
route add 192.168.1.0 netmask 255.255.255.0 gw 192.168.3.250
route add 192.168.2.0 netmask 255.255.255.0 gw 192.168.3.250
Management Station can now Telnet to 192.168.110 and 192.168.2.20.
The management station is on the management network, but does not has a way to
connect to the remote 7800. Beginning with FOS v7.0.0, the administrator can configure
IP forwarding over inband management to allow communication to the remote switch
through the WAN connection. This is done by enabling IP forwarding to allow IP packets
arriving at the CP interface to be forwarded through the inband management interface
to the remote side. To prevent network routing and actual bridging of the LAN side of the
network to the WAN side of the network, ipfilter forwarding rules will default to deny
any forwarding traffic. To allow forwarding, new ipfilter rules must be added that
specify specific sources, destinations and protocols. This will prevent any unintended
network traffic from being forwarded from the LAN side to the WAN side of the network.
Footnote 1: Command syntax:

portcfg mgmtif [<slot>/]<gePort> [create|delete] <ipAddress>
<netmask> [<mtu>]
portcfg mgmtroute [<slot>/]<gePort> [create|delete]
<destination> <netmask> <gateway>
portcfg mgmtif [<slot>/]<gePort> [enable|disable]
Switch:FID128:admin> ipfilter ?
Usage:
ipfilter --addrule <policyname> -rule <rule_number> [-sip <source_IP>] -dp
<dest_port> -proto <protocol> -act <permit | deny> [-type <INPUT | FWD>] [-dip
<destination_IP>] : add a rule to an IP filter policy
Sub-options: -sip, -type, and -dip are optional

For FWD type, -sip alone is optional
For INPUT type, -type and -dip are alone optional
--create <policyname> -type <ipv4 | ipv6>: create an IP filter policy
--clone <policyname> -from <src_policyname>: create an IP filter policy as a
copy of an existing policy
--show [policyname]: display one or all IP filter policy
--save [policyname]: save one or all IP filter policy
--activate <policyname>: activate an IP filter policy
--delete <policyname>: delete an IP filter policy
--delrule <policyname> -rule <rule_number>: delete a rule from an IP
filter policy
--transabort: aborts an open IP filter transaction
--clrcounters: clears the IP filter counters
--showcounters: shows the IP filter counters
--help: display the IP filter synopsis

portcfg mgmtif [<slot>/]<gePort> [create|delete] <ipAddress>
<netmask> [<mtu>]
portcfg mgmtroute [<slot>/]<gePort> [create|delete]
<destination> <netmask> <gateway>
portcfg mgmtif [<slot>/]<gePort> [enable|disable]
Command syntax:
ipfilter --addrule inband_ipv4 -rule <rule_number> -dp
<dest_port> -proto <protocol> -act <permit|deny> -type FWD
-dip <destination_IP>
ipfilter --addrule inband_ipv4 -rule

<rule_number> -dp <dest_port> -proto
<protocol> -act <permit|deny> -type FWD
-dip <destination_IP>
Ports ge4 and ge9 are available to be used, but are not in the example above.
10GigE lossless failover requires configured crossport interfaces to provide lossless

failover between FCIP circuits on two different 10 GbE ports for an FCIP tunnel.
Virtual Fabric support allows Ge port sharing across Logical Switches; VE_Ports can be
configured in any logical switch, and VE_Ports can be used as XISL.
FC frames are compressed before sending to the processor to encapsulate.
FCIP QoS, which is a licensed Fabric OS feature (Adaptive Networking), allows you to
categorize the traffic flow between a given host and target as having a high or low
priority.
Revision 0312 4 - 100

• 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.
Revision 0312 4 - 101

CFP 300 FCIP Administration
Revision 0312 5-1

Recall that a VE_Port to VE_Port configuration merges both ends of the connections,
whereas a VEX_Port to VE_Port configuration isolates both ends of the connection.
Revision 0312 5-2

We will go through the steps to create a VE_Port-to-VE_Port tunnel and then go through
them again and add steps to create a VEX_Port-to-VE_Port tunnel. We will focus on the
different aspects of the configuration each time.
Revision 0312 5-3

Remember, an FCIP tunnel requires two endpoints.

Footnote 1: As of Fabric OS v6.3.0, the only supported value for the MTU is 1500.
Revision 0312 5-4

The default media type is copper. The copper ports are RJ45 ports. The optical ports are
SFP ports.
Revision 0312 5-5

Footnote 1: Requires the 10GbE FCIP license.
Revision 0312 5-6

1G, 10G and Dual Mode switchshow outputs.
Valid VE_Ports
Valid ge Ports
Revision 0312 5-7

Use licenseadd to install a license on a switch.

The licenseslotcfg --remove command is used when needing to reallocate a
license to a different slot.
10 GbE license: Enables the two 10 GbE ports and optional 10 GbE port configurations
Advanced Extension license: Enables FCIP Trunking and Adaptive Rate Limiting
Revision 0312 5-8

Revision 0312 5-9

Footnote 1: While disabling the port is supported, it is recommended that the port be
persistently disabled during the tunnel configuration.
Create an IP interface on the tunnel

Each IP interface requires:
• A static IP address
• MTU size specification
• TCP port (3225) – Note: this port is automatically assigned (not configurable)
IP Subnet Rules Prior to Fabric OS v7.0

• Each circuit that is included in a tunnel must use a different subnet for each GbE
interface it spans
– There cannot be multiple IP addresses on the same subnet spread across
multiple GE ports
• An GbE port can host multiple circuits that participate in multiple tunnels. These
circuits do not need to be in the same subnet, but can be
• Circuits that make up a tunnel on a 10 GbE interface can reside in the same
subnet
• Fabric OS v7.0.0 removes all subnet requirements
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.
Footnote 1: The IP interface must be configured before adding a destination route on an

interface. A maximum of 32 routes can be added on one GbE port. Route additions do
not require tearing down tunnels. The IP address and gateway parameters use Unicast
IPv4 addresses in dotted decimal format (1.0.0.1 through 223.255.255.254); netmask
uses contiguous bitmask in IPv4 dotted decimal format. The associated metric (weight)
value range is 0 through 255.
The specified IP address needs to be an actual IP address at the other end of the link,
not a subnet address.
When creating multiple routes:
• Specify a metric of 0 to use a preferred gateway
• Specify a higher metric value to configure alternate, secondary gateways
• The higher the metric, the less preferred the route
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.
• ipaddr: The IP address of the route.
• netmask: The IP netmask.
• gateway_router: The IP address of the gateway router.
• metric: The gateway metric; if not specified the default metric of 0 is used.
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.
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, ge0 on 7800).
• -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 4.
• -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
7800, to the new IP interface on the Brocade DCX-4S. The command output shows that the
ping messages are received and returned by the Brocade DCX-4S, verifying IP connectivity
between the IP interfaces.
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 compression_level Configures compression on the
specified FCIP tunnel. By default, compression is disabled (0). Specify one of the
following values:
• 0 Compression disabled
• 1 Standard compression
• 2 Moderate compression (Brocade 7800 only)
• 3 Aggressive (Brocade 7800 only)
-T |--tperf 0|1 Enables (1) or disables (0) TPerf test mode.
-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.
If upgrading an FR4-18i to Fabric OS v7.0.0 or later, FastWrite is NOT supported. Refer

to release notes for additional information.
Optionally, a value can 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. The valid range is 10 Mbps - 1000000
Kbps. Both sides of the tunnel must have matching configurations.
To modify the minimum committed traffic rate on the FCIP circuit 0 in Kbps:
-b | --min-comm-rate minimum
To modify the maximum committed traffic rate on the FCIP circuit 0 in Kbps:
-B | --max-comm-rate maximum
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
ConnCnt = Connection count. Increments the times the circuit has been initialized.
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).
DCX: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 16 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.
DCX:admin> topologyshow
2 domain(s) in the fabric; Local Domain ID: 1
Domain: 3
Metric: 1800
Name: R1-ST01-B7800
Path Count: 1
Hops: 1
Out Port: 8/12
In Ports: 1/0
Total Bandwidth: 0.256 Gbps (adjusted)
Bandwidth Demand: 390 %
Flags: D
R1-ST01-DCX-4S:FID128: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 “DCX"
3: fffc03 10:00:00:05:1e:55:a1:80 10.255.248.19 0.0.0.0 ”B7800"
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.
A crossport is defined as the non-local XGE port to a VE port group. So for VE ports 12-
21, xge1 is the local XGE port and xge0 is the crossport. For VE ports 22-31, xge0 is the
local XGE port and xge1 is the crossport.
Footnote 1: Entering the same value in both fields is effectively setting a committed rate
without using Adaptive Rate Limiting (ARL).
This is a temporary test.

1. Select the Verify IP Connectivity button.
2. DCFM will configure the IP interface of both devices, execute a ping test and then
remove the IP configuration from both devices.
3. The results of the test are displayed.
The new tunnel is now created and active with status on each VE_Port being ‘Up’.
portcmd --tperf - Determines the path characteristics to a remote host or tunnel

destination. The --tperf option requires two separate FCIP end devices to function. One
device plays the role of a data sink and the other device plays the role of the data
source. Tperf also requires that you define a tunnel as a tperf tunnel.
-sink | -source Designates the switch to function either as a data sink or a data
source. This operand is required. When -sink is specified, tperf begins to respond to
traffic sent by the switch acting as the data source. The process continues to run until it
is either terminated by user intervention (Ctrl +C) or, if a duration is specified with the -t
option, until the process completes the set time frame.
The following optional arguments are ignored on the data sink, because it services all
requests from the data source: --high, --medium, --low, -
unidirectional, -random, -pattern, and -size.
The following arguments are optional:

-high: Generates high priority traffic.
-medium: Generates medium priority traffic.
-low : Generates low priority traffic. If no traffic priority is specified, high, medium,
and low priority traffic is generated.
-time duration: Specifies the duration of the TPerf traffic flow in seconds. If a
duration is not specified, the process continues to run until it is terminated with Ctrl +
C.
-unidirectional: Generates traffic in one direction only. The default is round-trip.
-loop: Re-issues a send request as fast as possible after completion of the previous
send request.
-random: Specifies a random protocol data unit (PDU) size between 1 and the size of
the send request. Refer to -size below.
-crc: Specifies cyclic redundancy check (CRC) to be performed on the payload.
-pattern pattern: Specifies the test data pattern for the payload as one of the
following values:
• 0: No pattern is specified. TPerf applies whatever is already set or in memory.
This is the default value.
• 1: All zeros
• 2: All ones
• 3: Incrementing byte
• 4: Random
• 5: Jitter
-size pdu_size: Specifies the PDU size to use (not including headers). The valid range
is between 1k and 16k. The default is equivalent to the maximum segment size
(MSS). This is the maximum size if the -random option is specified.
-interval interval: Specifies the interval at which the statistics display is refreshed, in
seconds. The default is 30 seconds.
When -source is specified, Tperf generates traffic until it is interrupted by user

intervention (Ctrl + C) or, if a duration is specified with the -T option, until the process
completes the set time frame. The Tperf module on the remote host will immediately
begin generating traffic; it is therefore imperative that the data sink has been started on
the opposing switch before the data source is started on the local switch.
Tperf generates statistics every 30 seconds by default unless you specify a different
value for -interval. The output displays the following information:
• Tunnel ID: Numeric identifier for the tperf tunnel.
• Traffic Priority: High, Medium, or Low.
• bytes tx: Number of bytes transmitted.
• bytes rx: Number of bytes received.
• PDUs tx: Number of protocol data units transmitted.
• PDUs rx: Number of protocol data units received.
• bad CRC headers rx: Number of bad CRC headers received.
• bad CRC payloads rx: Number of bad CRC payloads received.
• out of seq PDUs rx: Number of out-of-sequence PDUs received.
• flow control count: Flow control count.
• last rtt: Last Round trip in milliseconds (RT traffic only).
7800:admin> portcmd --tperf 16 -source -high -low random

TPerf has been configured successfully for 16
TPerf is generating traffic on 16 priority: high
TPerf is generating traffic on 16 priority: low
**********************************************************************
Tunnel ID: 16
High Priority Medium Priority Low Priority
bytes tx 263860632 0 104565600
bytes rx 1037640 0 410000
PDUs tx 25991 0 10300
PDUs rx 25941 0 10250
bad CRC headers rx 0 0 0
bad CRC payloads rx 0 0 0
out of seq PDUs rx 0 0 0
flow control count 0 0 0
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 521914320 0 207760680
bytes rx 2054400 0 816600
PDUs tx 51410 0 20465
PDUs rx 51360 0 20415
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 779957856 0 310976064
bytes rx 3071120 0 1223280
PDUs tx 76828 0 30632
PDUs rx 76778 0 30582
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 1038072456 0 414150840
bytes rx 4088120 0 1629800
PDUs tx 102253 0 40795
PDUs rx 102203 0 40745
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 1296115992 0 517345920
bytes rx 5104840 0 2036400
PDUs tx 127671 0 50960
PDUs rx 127621 0 50910
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 1554169680 0 620541000
bytes rx 6121600 0 2443000
PDUs tx 153090 0 61125
PDUs rx 153040 0 61075
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 1812182760 0 723725928
bytes rx 7138200 0 2849560
PDUs tx 178505 0 71289
PDUs rx 178455 0 71239
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 2070216144 0 826921008
bytes rx 8154880 0 3256160
PDUs tx 203922 0 81454
PDUs rx 203872 0 81404
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 2328269832 0 930095784
bytes rx 9171640 0 3662680
PDUs tx 229341 0 91617
PDUs rx 229291 0 91567
last rtt 58 0 146
**********************************************************************
**********************************************************************
Tunnel ID: 16
bytes tx 2586313368 0 1033290864
bytes rx 10188360 0 4069280
PDUs tx 254759 0 101782
PDUs rx 254709 0 101732
last rtt 58 0 146
**********************************************************************
Footnote 1: If the Brocade FX8-24 or a Brocade 7800 is disabled, a configupload would

still succeed in pushing the FCIP configuration to the config file.
Use the following commands to delete the tunnel created between the Brocade 7800
port 17 Brocade DCX-4S 10/17:
From Brocade 7800: portcfgdefault ge0; portcfgdefault 17
From Brocade DCX-4S: portcfgdefault 10/ge0
Slot 10 port 17 acts as a Virtual E_Port, it does not have and VEX_Port parameters to
delete.
Because ge0 was defaulted, the FCIP parameters associated with the connection
between the Brocade 7800 port 16 and Brocade DCX-4S 10/16 created earlier would
also be deleted. If the portcfgdefault command were invoked on the Brocade
7800 port 16 the VEX_Port parameters would also be deleted.
Footnote 1: A reboot of the CPs or chassis accomplishes the same function.
CFP 300 Adaptive Networking: Fabric Profiling
Revision 0312 6-1

Revision 0312 6-2

Revision 0312 6-3

Revision 0312 6-4

Data collected through Advanced Performance Monitoring is deleted when the switch is
rebooted.
Using the Brocade Network Advisor Enterprise Edition, you can store performance data
persistently.
Advanced Performance Monitoring provides the following monitors:
1) End-to-End monitors (EE monitors) measure the traffic between a host/target pair.
2) Frame monitors measure the traffic transmitted through a port with specific values
in the first 64 bytes of the frame.
3) Top Talker monitors measure the flows that are major consumers of bandwidth on a
switch or port.
Revision 0312 6-5

Restrictions for installing monitors

Advanced Performance Monitoring is not supported on VE_Ports and EX_Ports. If you
issue commands for any Advanced Performance Monitors on VE_Ports or EX_Ports you
will receive error messages.
For the Brocade 8000, performance monitoring is supported only on the FC ports and
not on the CEE ports.
All monitor types are allowed only on physical ports.
Top Talker and EE monitors on E_Ports should be installed only in the ingress direction.
Access Gateway considerations for Advanced Performance Monitoring

EE monitors and frame monitors are supported on switches in Access Gateway mode.
Top Talker monitors are not supported on these switches.
EE monitors must be installed on F_Ports. Frame monitors can be installed on F_Ports
or N_Ports.
See the Access Gateway Administrator’s Guide for additional information.
Revision 0312 6-6

In the example above, the busiest SID/DID pairs are shown. Advanced Performance
Monitor can measure performance quantitatively, but cannot determine the “busiest”
SID/DID pairs. Knowing the busiest devices can be a key factor in optimizing the
performance of a SAN design. Use Top Talker to identify the device pairs which put the
most demand on the capacity.
How do Top Talker monitors differ from EE monitors?

EE monitors provide counter statistics for traffic flowing between a given SID-DID pair.
Top Talker monitors identify all possible SID-DID flow combinations that are possible on
a given port and provides a sorted output of the top talking flows. Also, if the number of
flows exceeds the hardware resources, existing EE monitors fail to get real time data for
all of them; however, Top Talker monitors can monitor all flows for a given E_Port or
F_Port.
Revision 0312 6-7

Note: A flow is a stream of data traffic between a source and a destination.
The Top Talker monitor is based on SID-DID and not WWNs. Once Top Talker is
configured on a switch or port, it remains installed across power cycles.
Revision 0312 6-8

Revision 0312 6-9

The Top Talker feature is based on the Advanced Performance Monitor (APM) feature.
The Top Talker feature determines the largest users of F_Port bandwidth by monitoring
all flows (SID-DID pairs) through one or more switch F_Ports on any switch in the fabric.
This feature is not supported on Access Gateways.
Top Talker Monitors discards bandwidth information collected during the initial
stabilization. Initial stabilization is the time taken by a flow to reach the maximum
bandwidth. This time varies depending on the number of flows in the fabric and other
factors. The incubation period can be up to 14 seconds in the enterprise-class
platforms, and up to 82 seconds in the fixed-port switches.
A fabric mode Top Talker monitor and an EE monitor cannot be configured on the same
fabric. You must delete the EE monitor before you configure the fabric mode Top Talker.
Top Talkers supports two modes, port mode and fabric mode:
Port mode Top Talker
A Top Talker monitor can be installed on a port to measure the traffic originating from
the port and flowing to different destinations. You can configure Top Talker monitors on
F_Ports and, depending on the switch model, on E_Ports. The following platforms
support Top Talker monitors on E_Ports:
- Brocade 6510
-Brocade DCX 8510 family
Port mode Top Talker can be installed in either ingress or egress direction but not both.
Depending on the direction you measure traffic TO different destinations or FROM
different sources.
Fabric mode Top Talker
In fabric mode, Top Talker monitors are installed on all E_Ports in the fabric and
measure the data rate of all the possible flows in the fabric (ingress E_Port traffic only).
In fabric mode, Top Talker monitors can determine the top n bandwidth users on a given
switch.
You can install Top Talker monitors either in port mode or fabric mode, but not both.
Footnote 1: The Adaptive Networking licensed feature introduces QoS and Ingress Rate
Limiting functions.
Notes:
Administrators can use the Top Talker data to do the following:
• Re-route the traffic through different ports that are less busy, so as not to overload a
given port.
• Report the top-talking flows on a port if the total traffic on the port exceeds the
acceptable bandwidth consumption.
You can identify the initiator that consumes most bandwidth on a given storage port and
can balance the load to a different storage port.
There are a number of ways to balance bandwidth utilization, including: ISL trunking,
adding more ISLs, configuring a TI zone.
Initial stabilization is the time taken by a flow to reach the maximum bandwidth. This
time varies depending on the number of flows in the fabric and other factors. The
incubation period can be up to 14 seconds in the enterprise-class platforms, and up to
82 seconds in the fixed-port switches.
Because Top Talker identifies all possible flows on a given switch port or switch, Top
Talker may exceed the ASIC hardware resources (up to 2048 flows per Condor2; up to
256 flows per Condor). If there are more flows than the HW resources can support, the
Top Talker algorithm samples traffic (by looking at a new set of 256/2048 flows every
second) and extrapolates the measurement (estimating the actual performance from
the sampled data).
Interaction with other Fabric OS features:
• Administrative Domains: Top Talker monitors are placed in AD255
• FCIP and FC Routing: Not supported on VE_Ports, EX_Ports, or VEX_Ports
• Virtual Fabrics: All logical switches in the same chassis can use either fabric
mode Top Talker monitors or port mode Top Talker and end-to-end monitors.
You cannot use fabric mode Top Talker monitors and end-to-end monitors
together on the same logical switch.
Footnote 1: FC-FC routing and Top Talkers Fabric Mode cannot co-exist on the same
switch in pre-FOS v7.0.
Virtual Fabric considerations: All logical switches in the same chassis can use either
fabric mode Top Talker monitors or port mode Top Talker and EE monitors. You cannot
use fabric mode Top Talker monitors and EE monitors together on the same logical
switch.
Admin Domain considerations: Top Talker monitors are always installed in AD255.
NPIV considerations: Top Talker takes NPIV devices into consideration when calculating
the top talking flows.
Top Talker monitors are not supported on the embedded platforms: Brocade 5410,
5424, 5450, 5460, 5470, and 5480.
Footnote 1: FC-FC routing and Top Talkers Fabric Mode cannot coexist on the same
switch unless it is a 16G product with FOS v7.0. Enabling one while the other is already
enabled will be prevented.
Note the following restrictions:

• An E_Port-attached switch must be connected and merged with the backbone FC
router before you can enable Top Talker on the FC router.
• Fabric mode Top Talker does not support requests for domains (either front port
domain or xlate domain).
• Fabric mode Top Talker monitors do not monitor flows over EX_Ports.
For example, if a host is connected directly to an FC router and the target is on the edge
switch no flows are monitored because none of the flows traverse an E_Port on the FCR.
However, the flows across the E_Port on the FC router are monitored.
The perfttmon –-add ingress command adds a F_Port Top Talker monitor for
traffic entering a switch F_Port (receive, or Rx). The command has one argument:
the [slot]/port identifier for the port.
The perfttmon –-add egress command adds a F_Port Top Talker monitor for
traffic exiting a switch F_Port (transmit, or Tx). The command has one argument:
the [slot]/port identifier for the port.
The perfttmon –-delete command deletes an existing F_Port Top Talker
monitor from a port. The command has one argument: the [slot]/port identifier for
the port.
Footnote 1: The number of flows displayed is dependent on the hardware platform; 32

flows for Brocade 300, 5100, 5300, and FC8-xx port blades; 16 flows for Brocade 4100,
4900, 5000, 7600, and FC4-xx port blades; 4 flows for Brocade 7500. The command
can display a maximum of 32 flows.
Notes:
The perfttmon –-show command displays the largest flows measured by the
F_Port Top Talker monitor on a port. The command has the following arguments:
• [slot]/port: The identifier for the port. A mandatory argument.
• [wwn|pid]: The format of the SID and DID identifiers – WWN (wwn) or PID (pid). The
default is WWN format; an optional argument.
• [# of TT flows]: The number of largest-bandwidth flows to be displayed. The default
is 8 flows; an optional argument.
In the example above, the 3 largest flows through port 1/12 are displayed in PID format.
If end-to-end monitors are present on the local switch, the command fails with the message: Cannot
install Fabric Mode Top Talker because EE monitor is already present
If end-to-end monitors are present on remote switches running Fabric OS 6.1.0 or later, the command
succeeds; however, on the remote switches, fabric mode fails and a raslog message is displayed on
those switches.
If end-to-end monitors are present on remote switches running Fabric OS 6.0.x, the command
succeeds.
R11-ST11-B30:admin> perfttmon --show dom 3 5

=======================================================
Src_WWN Dst_WWN MB/sec Potential E-Ports
=============================================================
22:00:00:04:cf:bd:89:5f 10:00:00:05:1e:57:7c:a4 51.850 16 9
22:00:00:04:cf:92:5c:a1 10:00:00:05:1e:57:7c:a4 44.867 16 9
switch:admin> perfmonitorshow --class EE 0

There are 4 end-to-end monitor(s) defined on port 0.
KEY SID DID OWNER_APP TX_COUNT RX_COUNT OWNER_IP_ADDR
--------------------------------------------------------------------------------------
0 0x000024 0x000016 WEB_TOOLS 0x0000000000000000 0x0000000000000000 10.106.7.179
1 0x000022 0x000033 WEB_TOOLS 0x0000000000000000 0x0000000000000000 10.106.7.179
2 0x000123 0x000789 WEB_TOOLS 0x0000000000000000 0x0000000000000000 10.106.7.179
3 0x001212 0x003434 WEB_TOOLS 0x0000000000000000 0x0000000000000000 10.106.7.179
switch:admin> perfdeleemonitor 0, 2
End-to-End monitor number 2 deleted
Footnote 1: Fabric mode is only monitoring E_Port traffic.

Footnote 2: Maximum number of flows displayed is dependent on the hardware
platform; 32 flows for Brocade 300, 5100, 5300, 6510, FC8-xx and FC16-xx port blades;
16 flows for Brocade 4100, 4900, 5000, 7600, and FC4-xx port blades; 4 flows for
Brocade 7500. The command can display a maximum of 32 flows.
If an EE monitor is installed on a trunk group and you disable the trunk, the EE monitor
will be installed only on the last master port of that trunk group, which might not be the
actual port on which the EE monitor was installed when the trunk was enabled.
For F_Port trunks, end-to-end masks are allowed only on the F_Port trunk master. Unlike
the monitors, if the master changes, the mask does not automatically move to the new
master port.
All platforms support 12 frame monitors for trunks, except for the Brocade 300, which
supports 8 frame monitors for trunks.
For the Brocade 8000, trunk monitoring is supported only on the FC ports and not on
the CEE ports.
Setup Top Talker with BNA

1. Select Monitor drop down menu
2. Select Performance
3. Choose Top Talkers
Setup Top Talker with BNA (cont.)

1. Select Top Talkers Mode drop down menu
2. Select F_Ports
Setup Top Talker with BNA

1. Select Top Talkers Mode drop down menu
2. Select Fabric
3. Choose a switch in the fabric(s) desired
The benefits of bottleneck detection are they allow you to:

• Prevent degradation of throughput in the fabric.
The bottleneck detection feature alerts you to the existence and locations of devices
that are causing latency. If you receive alerts for one or more F_Ports, use the CLI to
check whether these F_Ports have a history of bottlenecks.
• Reduce the time it takes to troubleshoot network problems.
If you notice one or more applications slowing down, you can determine whether any
latency devices are attached to the fabric and where. You can use the CLI to display
a history of bottleneck conditions on a port. If the CLI shows above-threshold
bottleneck severity, you can narrow the problem down to device latency rather than
problems in the fabric.
You configure bottleneck detection on a per-switch basis, with optional per-port

exclusions. Bottleneck detection is disabled by default. Best practice is to enable
bottleneck detection on all switches in the fabric, and leave it on to continuously gather
statistics.
High availability considerations for bottleneck detection
The bottleneck detection configuration is maintained across a failover or reboot;
however, bottleneck statistics collected are lost.
Upgrade and downgrade considerations for bottleneck detection
The bottleneck detection configuration is persistent across firmware upgrades and
downgrades. The sub-second latency criterion parameter settings are not preserved on
downgrade to firmware versions earlier than Fabric OS 7.0.0. If you downgrade and then
upgrade back to Fabric OS 7.0.0, the settings revert to their default values.
Trunking considerations for bottleneck detection
A trunk behaves like a single port. Both latency and congestion bottlenecks are reported
on the master port only, but apply to the entire trunk. For masterless trunking, if the
master port goes offline, the new master acquires all the configurations and bottleneck
history of the old master and continues with bottleneck detection on the trunk.
This is an example of a latency bottleneck.
Bottlenecks are also reported through RASlog alerts and SNMP traps. These two alerting
mechanisms are intertwined and cannot be independently turned on and off. You can
use the bottleneckmon command to specify alerting parameters for the following:
• Whether alerts are to be sent when a bottleneck condition is detected
• The size of the time window to look at when determining whether to alert
• How many affected seconds are needed to generate the alert.
• How long to stay quiet after an alert
Changing alerting parameters affects RASlog alerting as well as SNMP traps
For more information: Fabric OS Administrator’s Guide 53-1002148-01
Bottleneck detection is enabled on a per switch basis. It is recommended that you

enable bottleneck detection on every switch in the fabric. If you later add additional
switches, including logical switches, to the fabric be sure to enable bottleneck detection
on those switches as well. When you enable bottleneck detection on a switch, the
settings are applied to all eligible ports on that switch. If ineligible ports later become
eligible or, in the case of a logical switch, if ports are moved to the logical switch,
bottleneck detection is automatically applied to those ports.
You can use the bottleneckmon --show command to display a history of

bottleneck conditions, for up to three hours. This command has several display options:
• Display only latency bottlenecks, only congestion bottlenecks, or both combined.
• Display bottleneck statistics for a single port, bottleneck statistics for all ports on
the switch, or a list of ports affected by bottleneck conditions.
• Continuously update the displayed data with fresh data.
Example of displaying the bottleneck history in 5-second windows over a period of 30

seconds.
In this example, the definition of bottlenecked ports is any port that had a bottleneck
occur during any second in the corresponding interval.
switch:admin> bottleneckmon --show -interval 5 -span 30

===========================================================
Wed Jan 13 18:54:35 UTC 2010
===========================================================
List of bottlenecked ports in most recent interval:
23
===========================================================
Number of From To bottlenecked ports
===========================================================
Jan 13 18:54:05 Jan 13 18:54:10 1
Jan 13 18:54:10 Jan 13 18:54:15 2
Jan 13 18:54:15 Jan 13 18:54:20 1
Jan 13 18:54:20 Jan 13 18:54:25 1
Setting a threshold of 0.1 and a time window of 30 seconds specifies that an alert
should be sent when 10% of the one-second samples over any period of 30 seconds
were affected by bottleneck conditions. The -qtime option can be used to throttle alerts
by specifying the minimum number of seconds between consecutive alerts.
Syntax:
bottleneckmon --enable [-alert][-thresh threshold]
[-time window] [-qtime quiet_time]
[slot/]port_list [[slot/]port_list] ...
bottleneckmon --disable [slot/]port_list
[[slot/]port_list] ...
bottleneckmon --show [-interval interval_size]
[-span span_size] [slot/]port
bottleneckmon –status
bottleneckmon --help
Enter the bottleneckmon --status command to display the details of bottleneck detection
configuration for the switch, which includes the following:
• Whether the feature is enabled
• Switch-wide parameters
• Per-port overrides, if any
• Excluded ports
Example
switch:admin> bottleneckmon --status
Bottleneck detection - Enabled
==============================
Switch-wide sub-second latency bottleneck criterion:
====================================================
Time threshold - 0.800
Severity threshold - 50.000
Switch-wide alerting parameters:
============================
Alerts - Yes
Latency threshold for alert - 0.100
Congestion threshold for alert - 0.800
Averaging time for alert - 300 seconds
Quiet time for alert - 300 seconds
Per-port overrides for sub-second latency bottleneck criterion:
==========================================================
Slot Port TimeThresh SevThresh
=========================================
0 3 0.500 100.000
0 4 0.600 50.000
0 5 0.700 20.000
Per-port overrides for alert parameters:
========================================
Slot Port Alerts? LatencyThresh CongestionThresh Time (s) QTime (s)
==========================================================
0 1 Y 0.990 0.900 3000 600
0 2 Y 0.990 0.900 4000 600
0 3 Y 0.990 0.900 4000 600
Excluded ports:
===============
Slot Port
============
0 2
0 3
0 4
When you enable bottleneck detection, you can configure switch-wide alerting and sub-
second latency criterion parameters that apply to every port on the switch. After you
enable bottleneck detection, you can change the alerting parameters on the entire
switch or on individual ports. You can change the sub-second latency criterion
parameters on individual ports only. You can also
change the parameters on ports that have been excluded from bottleneck detection.
The alerting parameters indicate whether alerts are sent, and the threshold, time, and
quiet time options.
For a trunk, you can change the parameters only on the master port.
1. Connect to the switch and log in as admin.
2. Enter the bottleneckmon --config command to set the alerting and sub-
second latency criterion parameters.
Enter the bottleneckmon --configclear command to remove any port-specific
alerting and sub-second latency criterion parameters and revert to the switch-wide
parameters.
The following example changes alerting parameters for the entire logical switch.
switch:admin> bottleneckmon --config -alert -lthresh .97 -cthresh .8 –time 5000
switch:admin> bottleneckmon --status
Bottleneck detection - Enabled
==============================
Switch-wide sub-second latency bottleneck criterion:
====================================================
Time threshold - 0.800

Severity threshold - 0.100
Switch-wide alerting parameters:
================================
Alerts - Yes
Latency threshold for alert - 0.970
Congestion threshold for alert - 0.800
Averaging time for alert - 5000 seconds
Quiet time for alert - 300 seconds
Per-port overrides for alert parameters:
========================================
Port Alerts? LatencyThresh CongestionThresh Time(s) QTime(s)
================================================================
1 N -- -- -- --
2 Y 0.990 0.900 4000 600
3 Y 0.990 0.900 4000 600
Excluded ports:
===============
Port
====
2
3
4
You can use the bottleneckmon command to configure alert thresholds for
congestion and latency bottlenecks.
Advanced settings allow you to refine the criterion for defining latency bottleneck
conditions to allow for more (or less) sensitive monitoring at the sub-second level. For
example, you would use the advanced settings to change the default value of 98% for
loss of throughput. If a bottleneck is reported, you can investigate and optimize the
resource allocation for the fabric.
Using the zone setup and Top Talkers, you can also determine which flows are destined
to any affected F_Ports.
The device does not return buffer credits in time, the cause whether this is due to a
driver issue, a software bug in an array, faulty components or high load can not be
determined with bottleneck detection.
You have the option of receiving per-port alerts based on the latency and congestion
history of the port. Alerts are generated based on the number of affected seconds over
a specified period of time. If the number of affected seconds is higher than the
threshold, an alert is generated. This process is done independently for latency and
congestion.
The bottleneckmon alerting parameters determine whether an alert is generated.
The averaging interval is configured in seconds, the threshold is a percentage value
represented by a fraction between 0 and 1.
An affected second is any 1 second period where the port has zero buffer credits and a
frame waiting to transmit.
In the example the averaging interval is configured for 12 seconds, during this interval
there were four affected 1 second periods giving a metric of 33.33%.
If the threshold was configured to be .3333 or less then a RAS log message would be
generated.
Affected seconds for bottleneck detection notes:

Default values are:
Threshold (thresh) = (0.1)
Time Window (time) = (300)
Quiet time (qtime) = (300)
Parameters are in seconds
The -time parameter specifies the time window. For this example, -time = 12 seconds.
The -cthresh and -lthresh parameters specify the thresholds on number of affected
seconds that trigger alerts for congestion and latency bottlenecks, respectively. For
example, assume the default values for these parameters:
-cthresh = 0.8 (80%)

-lthresh = 0.1 (10%)
For this time window, 50% of the seconds (6 out of 12 seconds) are affected by
congestion. This is below the threshold of 80%, so an alert would not be generated for
a congestion bottleneck.
For the same time window, 25% of the seconds (3 out of 12 seconds) are affected by
latency. This exceeds the threshold of 10%, so an alert would be generated for a
latency bottleneck.
CFP 300 Adaptive Networking: Traffic Management
Revision 0312 7-1

Revision 0312 7-2

Revision 0312 7-3

Footnote 1: See Appendix for information on the rate limiting feature.

While a Fabric OS license does exist with the same name, the concept of Adaptive
Networking goes beyond the single license.
Adaptive Networking is a suite of tools and capabilities that enable you to ensure
optimized behavior in the SAN. Even under the worst congestion conditions, the
Adaptive Networking features can maximize the fabric behavior and provide necessary
bandwidth for high-priority, mission-critical applications and connections.
The Adaptive Networking framework includes the following features:
• Top Talkers
• Traffic Isolation Routing
• QoS Ingress Rate Limiting
• HBA QoS Target Rate Limiting
• QoS SID/DID Traffic Prioritization
• QoS HBA Traffic Prioritization
• Bottleneck detection
The Adaptive Networking license only activates these features:
• QoS Ingress Rate Limiting
• QoS SID/DID Traffic Prioritization
Revision 0312 7-4

Revision 0312 7-5

Revision 0312 7-6

By default, QoS is enabled on 8 Gbps ports, except for long-distance 8 Gbps ports. QoS
is disabled by default on all 4 Gbps ports and long-distance 8 Gbps ports.
Revision 0312 7-7

Footnote 1: VC bandwidth is assigned to priority types. When all priorities are being
used, High priority gets approximately 60% of total bandwidth, Medium priority gets
approximately 30%, and Low priority gets approximately 10%. If not all bandwidth is
utilized in a particular priority level, unused bandwidth can be used by other priorities.
QoS is not supported on mirror ports or 10 Gbps ISLs.
The QoS for ISLs is a per-port configurable attribute applicable to E-Ports in both Condor,
Condor2 and Condor 3-based switches running a minimum of Fabric OS v6.0. A QoS
enabled E-Port will form a QoS capable ISL with a neighboring switch only if the
connecting E-Port on the neighboring switch is also QoS capable, with QoS enabled.
Otherwise, the fabric module will negotiate down to non-QoS mode (medium priority, VCs
2 – 5 only). The side that negotiated to a lower flow control value will log the information
in the RASLOG.
Revision 0312 7-8

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.
VC # Assigned to
0 Class F
1 Reserved
2 Data
Data
All
3
Data
4 Data Traffic
5 Data
6 Class 3 Multicast
Revision 0312 7-9

The example above illustrates the breakdown of the 16 Gbps ISL into individual VCs and
their priority assignments. Condor 3, Condor2 and Goldeneye2 ASICs support this
model.
Footnote 1: These operations will only occur if there are enough frames in each queue
to process. Results may vary depending on the status of the fabric profile at that
moment, known as a time slice.
Contention vs Congestion
Contention is when multiple frames arrive at the link at

the same time
Congestion is when there is more traffic than the link is

capable of carrying
Footnote 1: These numbers are generic and assume full payload frame size with a
complete variety of queued traffic. If payloads are not full, then the percentages could
vary greatly. If there are not enough frames of a particular priority in the queue, the
frames that are present will be sent and the process will skip the remaining allotment
and move to the next priority, thus varying the percentage.
For example, if there are only 4 frames of high priority traffic, but VC0 has 4 frames and
medium and low priority queues each have 20 frames, then the proportion of high
priority bandwidth to the other traffic will be much less than 60% at approximately 33%
(4 high/(4 VC0+4 high+3 med+1 low))
The percentages will vary depending on the fabric profile at the moment of QoS
processing.
Footnote 1: Bandwidth that is actually observed in the fabric during contention for the
line is coincidental and not a set, nor directly configurable rate. The number of frames
and their payloads of the fabric profile determine the actual bandwidth. QoS does not
use any of these metrics to determine frame priority.
Prioritization can be managed to use a specific VC for a given zone.

When creating the zone using the QOSH or QOSL prefix add a flow ID value.
QOSHid_
QOSLid_
• id1 – is an optional flow identifier to designate a specific virtual channel
• If no id is supplied VCs are assigned using a round-robin method
• Refer to the next slide: 8 Gbps – 16 Virtual Channel Model Flow Ids for id to VC
pairings
Example:
QOSH2_zone1
• When QoS is enforced, traffic for this zone will use VC 11
Footnote 1: Requires Fabric OS v6.3.0 or later
If a QoS zone name prefix is specified in an LSAN zone (a zone beginning with prefix
"LSAN_"), the QoS tag is ignored. Only the first prefix in a zone name is recognized. For
example, a zone with the name "LSAN_QOSH_zone1" is recognized as an LSAN zone
and not a QoS zone.
VC # Assigned to Flow ID % Bandwidth

0 Class F
1 Reserved
2 Medium Priority QoS
~30%
6 Class 3 Multicast
8 Low Priority QoS 1
9 Low Priority QoS 2 ~10%1
10 High Priority QoS 1

~60%
15 Reserved
The high and low priority sections have flow ids for each VC that can be used during the
creation of the QoS zone to designate specific VCs for use. Medium VCs do not have a
flow id.
Firmware Upgrade/Downgrade with QoS
• If upgrading from Fabric OS v6.x, QoS is not disrupted.

• If upgrading from Fabric OS v5.x, QoS will not become effective until the E_Ports are
disabled/enabled following the firmware upgrade.
• If QoS enabled E_Ports are active when a firmware downgrade is activated, the
firmware downgrade will not be allowed until QoS is disabled.
After a firmware downgrade to a version of Fabric OS prior to v6.0, any existing QoS
configurations will no longer be effective.
• Any existing zoning configurations will be intact, but any existing QoS zones will be
treated as regular zones.
After a firmware downgrade, the zoning configuration would be intact, however, any
zones that had a QOSX_ in the name would now be treated as regular zones. Since
earlier versions of Fabric OS do not understand the concept of QoS zoning, these zones
would be treated as normal zones.
Footnote 1: By default, the value is AE, Auto Enable. ‗ON‘ or ‗OFF‘ appears if the feature
has been explicitly enabled or disabled.
QoS is enabled by default. QoS is a ―best effort‖ facility, meaning it will work if there are
enough buffers to support it. In the default setting, QoS will work if there are enough
buffers available to sustain the requested links. If there are not enough buffers to
sustain the requested links, Buffer Limited Mode will be enforced, until such time that
buffers are not available. When this happens, VCs will start to collapse within their
priorities to conserve buffers.
If the number of Buffer Usage is less than the number of Needed Buffers, the port is
operating in the buffer limited mode.
Footnote 1: Because non-QoS zones are treated as medium priority, when a QoS higher
priority overlaps the medium priority zone takes precedence. For example, if
QOSH_zone1 (H,T) overlaps with a regular zone at the H port, the traffic flow between H
and T is dropped to medium priority and the H port is marked as a session-based zoning
port.
If QoS is enabled, an additional 16 buffer credits are allocated per port for 8-Gbps ports
in LE mode. (QOS chapter in v7.0 admin guide)
QoS requires an additional 20 buffer credits per active port so maximum supported
distances may be lower. (extended distance chapter v7.0 admin guide)
Footnote 1: Redirection zones are used in Brocade Encryption solutions.
Firmware Upgrade/Downgrade with QoS
•If upgrading from Fabric OS v6.x, QoS is not disrupted.

•If upgrading from Fabric OS v5.x, QoS will not become effective until the E_Ports are
disabled/enabled following the firmware upgrade.
•If QoS enabled E_Ports are active when a firmware downgrade is activated, the
firmware downgrade will not be allowed until QoS is disabled.
After a firmware downgrade to a version of Fabric OS prior to v6.0, any existing QoS
configurations will no longer be effective.
•Any existing zoning configurations will be intact, but any existing QoS zones will be
treated as regular zones.
After a firmware downgrade, the zoning configuration would be intact, however, any
zones that had a QOSX_ in the name would now be treated as regular zones. Since
earlier versions of Fabric OS do not understand the concept of QoS zoning, these zones
would be treated as normal zones.
Command operands:
--enable Enables Quality of Service (QoS)
port_id Specifies the ID of the port on which QoS is enabled
--disable Disables Quality of Service (QoS)
port_id Specifies the ID of the port on which QoS is disabled
--query Queries the QoS details
port_id Specifies the ID of the port for which you want to display information.
--stats Displays the QoS statistics
port_id Specifies the ID of the port for which you want to display statistical
information.
--statsclr Clears the QoS statistics
port_id Specifies the ID of the port for which you want to clear statistical
information
This feature can aid in the control of frame flow through a fabric. Please see the Fabric
OS admin guide for a more detailed discussion of the Traffic Isolation feature.
Footnote 1: With Fabric OS v6.3.0, Traffic Isolation Routing is supported only on Brocade
200E, 300, 4100, 4900, 5000, 5100, 5300, 5410, 5424, 5450, 5480, 7500, 7500E,
7600 switches, the Brocade 48000 and Brocade DCX platforms, all configured in
Brocade Native Mode (interopmode 0).
Footnote 1: Routes are not being changed, but one or more are being dedicated for use
by a specific set of devices. The urouteshow command will show available TI-zoned
routes.
Prior to Fabric OS v6.0, traffic isolation in a SAN environment was somewhat difficult to
implement
The process involved setting up static routes through the SAN with the
urouteconfig command, or the linkcost command.
• These would modify the routing table, and had to be done on each switch in the
data path
• The linkcost command is unidirectional, and would involve settings for both
directions along the route
• If the need to isolate this traffic was temporary, the routing table would have to be
modified again when traffic isolation was no longer necessary – on each switch in
the data path
TI Zoning is a routing related feature, but, unlike using urouteconfig or linkcost,
TI Zoning is bidirectional.
Fabric Shortest Path First (FSPF) is the protocol by which routes are selected in a fabric.
Dynamic Path Selection (DPS) is also called Exchange-Based Routing.
The ISL in the TI zone depicted above will be exclusively reserved to TI zoned traffic as
long as there is another equivalent cost route available.
Possible uses for TI zones might be:

• Dedicate an ISL for high priority host to target traffic
• Force high volume, low priority traffic onto a given ISL to limit the effect of that
traffic on the overall fabric
• Whatever the reason, a TI zone can be created that contains the set of N_Ports
and E_Ports to be used for a specific traffic flow.
Footnote 1: Fabric OS v6.1 has the limitation of 255 TI zones. Fabric OS 6.0 has a limit
of 239 TI zones. A fabric merge resulting in more than the supported number of TI zones
will cause a merge failure, and segmentation.
TI zones cannot be used in heterogeneous fabrics (Fabric OS and M-EOS) if interopmode
3 is being used. However, regular zoning can be used, and can be activated from any M-
series switch in the fabric.
Footnote 1: If all ports in a trunk group are not included in a TI zone, the behavior of the
TI zone will be uncertain, as TI zones are enforced on the trunk master only. For
example, if 3 out of 4 ISLs in a trunk group are included in a TI zone, and the trunk
master is part of the TI zone, behavior is normal. However, if the trunk master fails, and
the new trunk master is the ISL which is not included in the TI zone, behavior will be
dependent on the failover setting. If failover is disabled, the TI zone, and thereby the
dedicated route between host and target, will be broken, and no data will flow. More
information on failover on the next few slides.
Footnote 1: Traffic Isolation is a ―best effort‖ facility that will work as long as it doesn‘t
violate the FSPF ―lowest cost route‖ rules. This means that traffic from one TI zone may
have to share an ISL with other TI zones and devices if no equal-cost routes are
available and failover is enabled.
If a TI zoned E_Port fails, traffic will failover to a non-TI zoned E_Port, if no other equal-
cost TI zoned E_Ports exist (this behavior is dependent on the ―failover‖ setting, which is
covered on another slide). Also, a non-TI zoned device will use a TI zoned E_Port if no
equal cost alternatives exist and failover is enabled.
If used within an AD, the E_Ports specified in a TI zone must be in that AD‘s device list
(enforced during zone creation/modification).
• Since TI zones must use D,I notation, the AD‘s device list must be declared using
D,I for ports that are to be used in such zones (enforced during zone
creation/modification).
• Care must be taken if using TI zones for shared ports (E_Port or N_Port) because
of the limitation that a given port can only appear in a single TI zone. Conflicting
members across ADs can be detected by use of zone --validate, and ―best
practices‖ would demand that such situations not be allowed to persist.
Footnote 2: Used primarily for FICON with Fabric OS v6.4 and later.
Footnote 3: If you only want one N_Port (on that switch) in the zone put the port on a
non-shared port (0-15).
Footnote 1: Failback is not a configurable feature.
Traffic Isolation is subject to the rules of FSPF.

Note: This diagram represents only half of a redundant fabric.
When a zone is marked as a ―Traffic Isolation‖ zone (TI zone) and failover is enabled, the
fabric will attempt to isolate all inter-switch traffic entering a switch from a member of
that zone to only those E_Ports that have been included in the zone. In other words, the
domain routes for any of the members (N_Port or E_Port) to the domains of other
N_Port members of the zone will be set to use an E_Port included in the zone, if it
exists. Such domain routes will be used only if they are on a ―lowest cost‖ path to the
target domain (i.e. the FSPF routing rules will continue to be obeyed). The fabric will also
attempt to exclude traffic from other TI zones from using E_Ports within a different
traffic isolation zone. This Traffic Isolation is a ―best effort‖ facility that will do its work
only as long as doing so does not violate the FSPF ―lowest cost route‖ rules. This means
that traffic from one Traffic Isolation zone may have to share E_Ports with other TI zones
and devices when no equal-cost routes can be found using a ―preferred‖ E_Port. And if a
―preferred‖ E_Port fails, traffic will failover to a ―non-preferred‖ E_Port, if no preferred
E_Ports offer a ―lowest routing cost‖ route to the target domain. Similarly, a non-TI
device‘s traffic will use an E_Port from a TI zone if no equal cost alternatives exist.
Whether failover is enabled or disabled can be determined at the time the TI zone is
created. The default is failover enabled.
Disabling failover is intended for use in simple linear fabric configurations.
Requirements and Compatibility
• TI zones are supported with Condor, Condor2, Condor3, GoldenEye, GoldenEye2-

based Brocade switches running Fabric OS v6.x or later
– This feature is supported in Brocade Native Mode (Interop Mode 0) and in
McDATA Fabric Mode (Interop Mode 2). It also is supported for EX_Ports,
VEX_Ports and VE_Ports.
• TI zones are not supported by versions of Fabric OS prior to v6.x
Note: While Host B and Target B can form a TI zone, Host A and Target A cannot,
because of the Fabric OS v5.3 switch in the data path. However, the presence of the TI
zone in the fabric above will not disrupt traffic flowing from Host A to Target A.
Requirements and Compatibility (cont.)

• TI zones cannot be created on switches running pre-v6.0 Fabric OS versions, and
must obey FSPF rules.
• In fabrics consisting of mixed Fabric OS versions, TI zones will not disrupt traffic in
switches running older versions, however, TI zones cannot be enforced on a pre-
Fabric OS v6.x switch.
In the example above, TI zones cannot be enforced in default configurations, because

Domain 2 is running a version of Fabric OS prior to v6.0, on which the TI Zoning feature
is not supported. Also, the TI zones would not be enforced using Domains 4 and 5, since
they are not lowest cost paths.
However, it could be possible to change the link costs to make the path through domain
4 and domain 5 the FSPF path of choice and thereby allowing a TI zone in that direction
to function.

FSPF routing rules and traffic isolation
All traffic must use the lowest cost path. FSPF routing rules take precedence over the
TI zones.
• Example 1:
– If the dedicated ISL is not the lowest cost path ISL, then the following rules
apply:
• If failover is enabled, the traffic path for the TI zone is broken, and TI zone
traffic uses the lowest cost path instead
• If failover is disabled, the TI zone traffic is blocked

Example 2:
• If the dedicated ISL is the only lowest cost path ISL, then the following rules apply:
– If failover is enabled, non-TI zone traffic as well as TI zone traffic uses the
dedicated ISL
– If failover is disabled, non-TI zone traffic is blocked because it cannot use the
dedicated ISL, which is the lowest cost path
TI Failover
If failover is disabled:
• Intended for use in simple linear fabric configurations
– Ficon is the driving force behind implementing TI zone; the Mainframe wants to
see all traffic from the source come from one and only one path, not from two
or more paths.
• Ensure that there are multiple paths between switches
• Ensure that there are non-dedicated paths through the fabric for all devices that
are not in a TI zone
For administrative reasons, it is recommended that TI zone definitions and regular
zone definitions match
It is recommended that the insistent Domain ID feature be enabled
• If a switch changes its active domain ID, the route is broken
Note the following configuration rules for TI zones:

• Traffic Isolation Routing is supported only on Brocade 200E, 300, 4100, 4900, 5000,
5100, 5300, 5410, 5424, 5450, 5480, 7500, 7500E, 7600 switches, the Brocade
48000 and Brocade DCX platforms, all configured in Brocade Native Mode
(interopmode 0).
• Ports in a TI zone must belong to switches that run Fabric OS v6.0.0 or later. For TI
over FCR zones, ports must belong to switches that run Fabric OS v6.1.0 or later.
• Traffic Isolation Routing has limited support for FICON FCIP in McDATA Fabric Mode
(interopmode 2), in the following configuration only:
− Brocade 7500 with E_Port connections to an M-switch and VE_Port connections to
another Brocade 7500.
− Devices attached to M-switch only.
Following is a sample configuration:
Devices — M-switch — Brocade 7500 — Brocade 7500 — M-switch — Devices
• Fabric OS 6.1.0 or later supports Traffic Isolation Routing in a mixed fabric (that is, a
fabric with Fabric OS and M-EOS switches) operating in interopmode 2. Traffic
Isolation Routing is not supported in fabrics configured in Open Fabric Mode
(interopmode 3).
• In interopmode 2, a zone member for a TI zone is limited to a port index of 255 or less.
• VE_Ports are supported in TI zones.
• Traffic Isolation Routing is not supported in fabrics with switches running firmware
versions earlier than Fabric OS v6.0.0. However, the existence of a TI zone in such a
fabric is backward-compatible and does not disrupt fabric operation in switches
running earlier firmware versions.
• TI over FCR is not backward compatible with Fabric OS v6.0.x or earlier. The -1 in the
domain,index entries causes issues to legacy switches in a zone merge. Firmware
downgrade is prevented if TI over FCR zones exist.
zone --operation [-t objtype] [-o optionlist] name -p

[portlist]
operation: create, add, remove, delete, activate, deactivate and show
-t objtype: ti (traffic isolation zone)
-o optionlist: a (activate), d (deactivate),n (no-failover), f (enable-failover)
-p portlist: ―port; …; port‖ (In Domain, Index notation)
You can also configure TI zones with Network Advisor.
Example 1 shows how to create a TI zone with default settings – failover enabled, and
activate the TI zone upon creation. In Example 2, the ―-o‖ argument is required because
the TI zone is being created with failover disabled, and not activating upon creation.
To verify that the TI zone has been enabled on the fabric, issue a cfgshow, or zone -
-show command on each switch in the data path, and verify the TI zone shows up in
the Defined Configuration.
Examples:
• Add port member as a portlist to an existing TI zone
zone -–add “yellowzone” –p “1,217; 5,11”
• Add option to disable/enable failover for a TI zone

zone -–add –o n “yellowzone” –p “1,217 ; 5,11”
zone -–add –o f “yellowzone” –p “1,217 ; 5,11”
• Remove portlist member from an existing TI zone

zone -–remove “yellowzone” –p “1,217 ; 5,11”
The zone --showtierrors command analyzes real and potential routing problems with the
activated TI zoning set and prints a report. This command must be executed in the local domain
and analyzes only that domain.
Error Types: Error and Warning:
Error type records indicate that a problem is present within the fabric given the current set of
online devices and activated TI zone configuration. In this case, if traffic between the involved
devices has already been started, frames are likely to be dropped within the fabric.
Warnings are not currently a problem given the current set of online devices and ports and
reachable domains. Traffic may not be getting dropped in the fabric at the moment. However,
given the activated TI zone configuration, parallel exclusive paths between a shared device and
a remote domain have been detected which might cause a issue for devices that join the fabric
later and attempt to start communicating.
Following is an example report that would be generated for the illegal configuration shown
below. The configuration is illegal because there are two paths to one device on the same
remote domain (refer to illustration in slide):
switch:admin> zone --showTIerrors
My Domain: 3
Error type: ERROR
Affected Remote Domain: 1
Affected Local Port: 8
Affected TI Zones: etiz1, etiz2
Affected Remote Ports: 1, 2, 3, 4
Footnote 1: Error: Operation is not allowed on TI zone.
To define TI Zones in Network Advisor using the Zoning tool

1. Select the Zone DB tab
2. Choose Domain;Port Index for the Type
3. Choose New TI Zone
To define TI Zones in Network Advisor using the Zoning tool (cont.)

4. Select the E_Ports and Devices
5. Add them to the TI Zone
6. Right-click to edit the failover and enable configuration
7. Activate the Zone Config
Footnote 1: Support for TI zones across FC-FC routing was not implemented until Fabric
OS v6.1.
Footnote 2: It is a best practice to have these align, however, it is not a requirement that
the LSAN and TI zones be exactly the same. At the least, the devices that are using the
TI paths must be in the LSANs for proper functionality.
Example for creating the TI zone in the edge fabric
E1switch:admin> zone --create -t ti TI_Zone1 -p “1,8; 1,1,

3,-1; 4,-1”
E1switch:admin> zone --show

Defined TI zone configuration:
TI Zone Name: TI_Zone1
Port List: 9,2; 9,3; 9,6; 1,-1; 4,-1
Configured Status: Activated / Failover-Enabled

Enabled Status: Deactivated
Footnote 1: Non-TI data traffic is not restricted from going through the TI path in the backbone
fabric.
Example configuration:
• Host PWWN - 10:00:00:00:00:08:00:00
• Target1 PWWN - 10:00:00:00:00:02:00:00
• Target2 PWWN - 10:00:00:00:00:03:00:00
BB_DCX_1:admin> zone --create -t ti TI_Zone1 -p "1,1; 1,4; 2,1;

2,7; 10:00:00:00:00:08:00:00; 10:00:00:00:00:02:00:00;
10:00:00:00:00:03:00:00“
BB_DCX_1:admin> zone --show

Defined TI zone configuration:
TI Zone Name: TI_Zone1
Port List: 1,1; 1,4; 2,1; 2,7; 10:00:00:00:00:08:00:00;
10:00:00:00:00:02:00:00; 10:00:00:00:00:03:00:00
<Output truncated>
Footnote 1: The Brocade 48000 with 8 Gbps blades will support Ingress Rate Limiting
on all installed 8 Gbps ports, but QoS is limited to pass-through support in the same way
all other 4 Gbps switches operate. In other words, all 4 Gbps and 8 Gbps FC ports
support QoS through the switch, but do not support QoS to/from devices attached to the
Brocade 48000.
Footnote 2: The portdisable/portenable commands are required after the

addition of the license for the features to be effective.
Footnote 3: This is accomplished by throttling back the flow of R_RDYs.
Footnote 4: Slow drain and congestion issues will be covered in more detail in the
bottleneck detection section of this module.
The settings for Ingress Rate Limiting are unidirectional. In the example above, traffic
returning from a target to a host would travel at full line speed, unless the ingress side
of the target‘s port is also throttled back. In which case, traffic would be rate limited in
both directions.
The switch ports in the example above are assumed to be capable of 8 Gbps.
Note: If Virtual Fabrics is enabled, the rate limit configuration on a port is on a per-
logical switch basis. That is, if a port is configured to have a certain rate limit value, and
the port is then moved to a different logical switch, it would have no rate limit applied to
it in the new logical switch. If that same port is moved back to the original logical switch,
it would have the original rate limit take effect again.
Footnote 1: Rate Limit is set in Mbits/sec. For example, to set a rate limit on slot 3, port
4 to 2 Gbps, the command syntax would be:
portcfgqos --setratelimit 3/4 2000
SetRateLimit allows the following rates in Mbits/sec:
• 200
• 400
• 600
• 800
• 1000
• 1500
• 2000
• 2500
• 3000
• 3500
• 4000
• 5000
• 6000
• 7000
• 8000
From Web Tools:

1. Select Port Admin
2. Select Edit Configuration with the desired port selected
3. Specify the Port Parameters then click next
4. Select the Ingress Rate Limit(Mb/s)
Running portcfgshow command without specifying a port will show ON for any ports
that have Rate Limiting enabled. The configured speed will not be displayed.
Command operands:
--enable Enables Quality of Service (QoS).
port_id Specifies the ID of the port on which QoS is enabled.
--disable Disables Quality of Service (QoS).
port_id Specifies the ID of the port on which QoS is disabled.
--query Queries the QoS details.
port_id Specifies the ID of the port for which you want to display information.
--stats Displays the QoS statistics.
port_id Specifies the ID of the port for which you want to display statistical
information.
--statsclr Clears the QoS statistics.
port_id Specifies the ID of the port for which you want to clear statistical
information.
Command operands:
--enable Enables target rate limiting, if currently disabled
port_id Specifies the ID of the port you want to enable
--disable Disables target rate limiting on the HBA, if currently enabled
port_id Specifies the ID of the port you want to disable
--query Queries the target rate limiting details
port_id Specifies the ID of the port for which you want to display
information.
--defspeed Sets the default target rate limiting speed. The default TRL
speed must be supported and less than the maximum speed
at which the card can operate
port_id Specifies the ID of the port on which you want to set the
speed
speed 1|2|4 Sets the default target rate limiting speed on the HBA. Options
are 1 Gbps, 2 Gbps, and 4 Gbps.
For all discovered remote ports, the HBA management tool and corresponding driver will
use RPSC to find their port speed capabilities and then use this information to throttle
the transmitted traffic rate to that remote port. This will provide protection only for FCP
write traffic.
At each port level, target rate limiting can be turned on/off. When on, there are 2
scenarios:
• Target supports RPSC (Report Port Speed Capabilities) ELS
• Target does not support RPSC ELS. In this case, the HBA management tool will
assume a default target speed of 1G. A hidden configuration parameter (not
exposed to user) to change this default speed setting will be available for
troubleshooting purposes.
QoS over FC routers is supported only if Virtual Fabrics is disabled in the backbone
fabric. QoS over FC routers cannot be enabled if Virtual Fabrics is also enabled in the
backbone fabric.
The port WWN of the host or target and the port WWN of the proxy device must be in
both an LSAN zone and a QoS zone.
QoS over FC routers is supported on both EX_Ports and VEX_Ports. QoS over FC routers
is not supported on the FR4-18i blade.
Zones for Edge Fabric 1:

LSAN_zone1: Host1, Target1, Target2
QOSH_zone1: Host1, Target1, Target2
Zones for Edge Fabric 2:

LSAN_zone2: Host1, Target1, Target2
QOSH_zone2: Host1, Target1, Target2
Virtual channels assigned to QoS priority
CS_CTL value Priority Number of VCs VCs assigned

1–8 High priority 4 -10, 11, 12, 13
9 – 16 Medium priority 4 - 2, 3, 4, 5
17 – 24 Low priority 2 - 8, 9
High availability considerations for CS_CTL-based frame prioritization

If the standby CP is running a Fabric OS version earlier than 6.3.0 and is synchronized
with the active CP, then you cannot enable CS_CTL-based frame prioritization on the
active CP. If the standby CP is not synchronized or if no standby CP exists, then enabling
CS_CTL-based frame prioritization succeeds.
CFP 300 Virtual Connectivity - NPIV and Access Gateway
Revision 0312 8-1

Revision 0312 8-2

Revision 0312 8-3

N_Port ID Virtualization (NPIV) allows a single FC port to appear as multiple, distinct

ports providing separate port identification and security zoning with the fabric for each
operating system image as if each one had its own physical port.
Revision 0312 8-4

Revision 0312 8-5

Footnote 1: NPIV devices connected to the same NPIV-enabled switch port must have its
own unique WWNs. The machine virtualizing software assigns the WWNs or in some
cases the WWNs can be managed by the drivers installed on the VM. Physical hosts
connected to a switch in Access Gateway mode will use its factory provided WWNs. The
NPIV port on the switch does not assign these WWNs.
Footnote 2: Fabric Assigned PWWN addresses can be configured prior to attaching the
devices.
Revision 0312 8-6

You can also use domain, port zoning for an NPIV port, but all the virtual PIDs
associated with the port are included in the zone. A port login (PLOGI) to a non-existent
virtual PID is not blocked by the switch; rather, it is delivered to the device attached to
the NPIV port. In cases where the device is not capable of handling such unexpected
PLOGIs, you should use WWN-based zoning.
Revision 0312 8-7

Footnote1: Refer to the current release notes for the supported limit on your specific
blade type.
Revision 0312 8-8

Revision 0312 8-9

Number of supported NPIV devices
Platform Virtual Fabric Logical Switch Type NPIV Support

Yes, 127 virtual
DCX Disabled N/A
device limit1
Yes, 63 virtual
DCX Enabled Default switch
device limit1
Yes, 255 virtual
DCX Enabled Logical switch
device limit2,3
DCX Enabled Base switch No
Yes, 255 virtual
DCX-4S Disabled N/A
device limit
Yes, 255 virtual
DCX-4S Enabled Default switch
device limit
Yes, 255 virtual
DCX-4S Enabled Logical switch
device limit
DCX-4S Enabled Base switch No
Footnote 1: Maximum limit support takes precedence if user-configured maximum limit

is greater. This applies to shared areas on the FC4-48, FC8-48, and FC8-64 port
blades.
Footnote 2: The first 112 physical NPIV-capable devices connected to a logical switch
using 10-bit addressing can log in 255 logical devices. The physical NPIV-capable
devices after 112, 113, and higher, are limited to 63 logical devices.
Footnote 3: Maximum limit of 63 for 10-bit areas connected to third-party (non-
Brocade) NPIV HBAs.
Footnote 1: NPIV capability is a switch blade or port attribute that is required for NPIV
functionality. Some blades within a switch, or some ports within a switch or blade, may
not have NPIV capability. NPIV functionality cannot be enabled on such ports and they
do not respond to NPIV requests.
NPIV functionality must be enabled on a port for it to respond to NPIV requests. NPIV is
enabled by default. It can be selectively disabled or re-enabled on specified switch ports
using this command.
To enable NPIV functionality on dual-CP systems, NPIV-enabled firmware must be
running on both the active and the standby CPs. This requirement does not apply to
single-CP systems.
Footnote 2: Check vendor specific release notes for NPIV supportability.

portcfgnpivport --enable [slot/]port
portcfgnpivport --disable [slot/]port
portcfgnpivport --setloginlimit [slot/]port login_limit
portcfgnpivport --help
portcfgnpivport [slot/]port mode
Enables or disables N_Port ID virtualization (NPIV)
functionality on a port and sets the per-port login limit.
Use the portloginshow command to display port login status received from devices
attached to the specified port.
For each login, this command displays the following fields:
Type - Type of login can display one of the following:
• fd - FDISC, Discover F_Port Service Parameters or Virtual N_Port login.
• fe - FLOGI, Fabric Login to Fabric F_Port.
• ff - PLOGI, Port Login to specific N_Ports or well-known addresses like Name
Server.
PID - The 24-bit Port ID of the attached device.
WorldWideName - The port's world wide name.
credit - The credit for this login as appropriate. This is BB (buffer-to-buffer) credit for
Flogs and EE (end-to-end) credit for PLOGIs.
df_sz - The default frame size for this login.
cos - Class of Services supported. This can be a combination of the following bits:
4 - Class 2 is supported.
8 - Class 3 is supported.
Further information about each login is displayed after these columns, including the Port
ID of the well-known address or N_Port that was the target of the PLOGI, if applicable.
Footnote1: For more information on your product type, refer to the Access Gateway
Administration Guide.
The Brocade Access Gateway is a Fabric OS feature that lets you configure your
enterprise fabric to handle additional N_Ports instead of domains.
Switches in AG mode are logically transparent to the host and the fabric. It increases the
number of hosts to have access to the fabric without increasing the number of switches
in the fabric. This simplifies configuration and management in a large fabric by reducing
the number of domain IDs and ports.
The Brocade Access Gateway allows multiple Host Bus Adapters (HBAs) to access the
fabric using fewer physical ports. Instead, certain Access Gateway ports are configured
as N_Ports, with the attached hosts mapped through the N_Ports through the N_Port ID
Virtualization (NPIV) protocol. The Brocade Access Gateway is a device management tool
and provides only a subset of Fabric OS commands. Therefore it does not consume
critical fabric elements (e.g. domain IDs) that could inhibit scalability.
Footnote 1: The VA-40FC is a compact form factor version of the 5100 which supports
high-density server racks and also provides reversible airflow options (either port-side or
power-side exhaust). The VA-40FC ships with AG mode enabled by default but AG mode
can be disabled and put back into Fabric mode
Footnote 2: Current embedded switches:
8 Gbps Switches
Dell M5424 24-port for Dell PowerEdge M1000e
Fujitsu 5450 26-port for PRIMERGY BX900
Hitachi 5460 26-port for BladeSymphony BS2000
HP 5480 24-port for BladeSystem c-Class
HP 5481 24-port HP Virtual Connect for Bladesystem c-Class
HP 5410 12-port for EVA 4400-S (storage switch)
IBM 5470 20-port for BladeCenter
4 Gbps Switches
Dell 4424 24-port for PowerEdge M1000e
Fujitsu 4016 16-port for PRIMERGY BX600
Hitachi 4016 16-port for B1000 and BladeSymphony BS320
HP 4024 24-port for BladeSystem c-class
HuaWei 4018 18-port Embedded Switch
IBM 4020 20-port for BladeCenter
NEC 4024 24-port for SigmaBlade
Footnote 1: These features are only disabled on the AG, but are still available in the rest
of the fabric.
Fabric OS components supported on Access Gateway
Feature Support
Access Control Yes (limited roles)1
Adaptive Networking Yes
Admin Domains No
Audit Yes
Beaconing Yes
Bottleneck Detection Yes
Config Download/Upload Yes
Diagnostic Port No
DHCP Yes
Encryption Configuration and No
Management
Environmental Monitor Yes
Error Event Management Yes
Extended Fabrics No
Fabric Device Management Interface Yes*
(FDMI)
Fabric Manager Yes**
Fabric Provisioning No
Fabric Services No
Yes, Please refer to the Fabric Watch
Administrator's Guide for applicable support
Fabric Watch details.
Fibre Channel Routing (FCR) services No
FICON (includes CUP) No
High Availability Yes
Hot Code Load Yes
Native Interoperability Mode NA
License Yes**
Lightweight Directory Access Protocol Yes
(LDAP)
Log Tracking Yes
Management Server NA
Manufacturing Diagnostics Yes
N_Port ID Virtualization (NPIV) Yes
Name Server NA
Network Time Protocol (NTP) No (no relevance from fabric perspective)2
Open E_Port NA
Performance Monitor Yes
Persistent ALPA Yes
Fabric OS components supported on Access Gateway (cont.)
Feature Support
Port Decommission No
Port Mirroring No
QuickLoop, QuickLoop Fabric Assist No
Remote Authentication Dial-In User Yes
Service (RADIUS)
Resource Monitor Yes
Security Yes (ADS/DCC Policy)
SNMP Yes
Speed Negotiation Yes
Syslog Daemon Yes
Trunking Yes**
User-Defined Roles Yes
ValueLineOptions (Static POD, DPOD) Yes
Virtual Fabrics No3
Web Tools Yes
Zoning NA
* Indicates the feature is transparent to AG

** indicates that the feature may not be available if the fabric is not a Fabric OS fabric
Footnote 1: When a switch is behaving as an AG, RBAC features in Fabric OS are
available, but there are some limitations.
Footnote 2: In embedded switches, time should be updated by the server management
utility.
Footnote 3: You cannot enable AG mode on a switch enabled for virtual fabrics or
enable virtual fabrics on an AG switch. You can connect ports on an AG switch to virtual
fabrics, however.
NPIV must be enabled on the switch that the Access Gateway is connected to.
The example above shows 8 hosts (Host_1 through Host_8) connected to a Brocade
300. It is configured as an Access Gateway with the default port map. The hosts are
mapped to the N_Ports as follows:
• F_Port 0 (Host_1) and F_Port 1 (Host_2) are mapped to N_Port 16
The FC addresses associated with the N_Ports and F_Ports (attached devices) are:
• The FC address for N_Port 16 = 030000. F_Port 0 (Host_1) logs in first and
receives the address 030001; F_Port 1 (Host_2) logs in second and receives the
address 030002.
address 030102.
address 040502.
address 040602.
Footnote 1: A Fabric Discovery (FDISC) is typically used when an initiator receives an

RSCN and wants to determine the current state of the target that caused the RSCN. If
the current login session to the target is valid, the initiator can continue operations with
affected target; otherwise, the initiator attempts to re-login. If login to the affected port
is not possible, the initiator can implicitly log out of the affected port, thereby freeing
resources. The FDISC process allows F_Ports to log in targets and establish sessions.
The following sequence describes how a failover event occurs:

1. An N_Port goes offline (ISL failure, attached switch port or switch goes offline).
2. All F_Ports mapped to that N_Port are disabled.
3. If the N_Port Failover policy is enabled, the disabled F_Ports are remapped to an
online N_Port. The F_Ports are evenly distributed among the remaining online
N_Ports.
4. The F_Port is re-enabled on the new N_Port.
5. The host establishes a new connection with the fabric.
Cold failover: After the switch comes online, the N_Port must successfully log in to the
attached fabric within 6 seconds, or the mapped F_Ports are remapped to the
remaining N_Ports. An unsuccessful login can occur because the N_Port is not
connected to the enterprise fabric, NPIV is not enabled on the fabric port to which a
N_Port is connected, or the Fabric Login request from N_Port is rejected by enterprise
fabric with a reason other than “LS_LOGICAL_BUSY”.
In the example above, port 0 on Switch_A goes offline (highlighted in red). This causes
N_Port 16 on the Access Gateway to go offline. The N_Port Failover policy now goes into
effect, causing F_Port 0 to be remapped to N_Port 18, and F_Port 1 to be remapped to
N_Port 20. After the devices attached to these F_Ports re-login to the fabric, the devices
obtain new FC addresses (Host_1 = 030103, Host_2 = 040503).
Footnote 1: The Access Gateway remaps only those F_Ports that were originally mapped
to the recovered N_Ports. F_Ports mapped to still-failed N_Ports remain remapped.
Footnote 2: For port mapping, the N_Port Failback policy must be enabled on an N_Port
for failback to occur. For device mapping, the N_Port Failback policy has no effect. If a
device is mapped to a port group, it will always failover to an online N_Port in the port
group (or secondary N_Port if configured) and will remain connected to this failover
N_Port when the original N_Port comes back online.
This example is used to demonstrate the commands used to put a Brocade 300 in
Access Gateway mode and show various command outputs. It is not intended to be a
“best practice” example.
The ag --modeenable command enables Access Gateway mode on the Brocade

300. The switch must be in a disabled state to run this command. If the platform does
not support the command, the command output is:
Access Gateway mode is not supported on this platform.
In the example above, the Brocade 300 uploads the switch configuration, disables the
switch, and then enables the Access Gateway mode.
The ag --modeshow command displays the Access Gateway mode on the Brocade
300. The command has no arguments.
The ag --mapshow command displays the mapping between the N_Ports and the
F_Ports. Each line displays the following information:
• N_Port - Port numbers of ports locked in N_Port mode.
• Configured F_Ports - List of F_Ports that are mapped to the corresponding N_Port.
• Current F_Ports - Shows the F_Ports that are currently connected to the fabric on
the corresponding N_Port. In the case of failover, the Current F_Ports and
Configured F_Ports differ.
• Failover and Failback - Indicates whether or not N_Port policy is enabled (1) or
disabled (0).
When the Access Gateway mode is enabled, all N_Ports belong to the default port group,
pg0.
The ag --show command displays detailed information about the N_Ports and
F_Ports, including the FC address of the devices. General information includes the
switch name, the switch WWN, the number of switch ports (24), the IP address, the
firmware revision, the number of N_Ports (4) and current F_Ports (4) and the policies
enabled (pg). Port Group 0 is the default port group.
Use the N_Port information to review:

• The N_Ports are ports 16, 17, 18, and 19.
• By reviewing the N_Port FC addresses (PortID), the domain ID of the Brocade
5100 is 1 (0x01), and the switch ports used on the Brocade 5100 are ports 0
(0x0100), 1 (0x0101), 2 (0x0102), and 3 (0x0103).
• All N_Ports have failover (FO) and failback (FB) enabled (1).
• The per-port N_Port WWN (PortWWN) is 20:PP:00:05:1e:04:25:45, where
PP is the Brocade 5100 port to which the N_Port is attached, and
00:05:1e:04:25:45 is the last 6 bytes of the Brocade 5100 switch WWN.
• The IP_Addr value is 10.255.244.91, indicating that all the N_Ports are
attached to the same Brocade 5100.
Use the F_Port information to cross-check the port map:
• F_Port port 1 (0x010001) mapped to N_Port port 16
The switchshow command adds the NPIV-generated FC address for the F_Ports and
N_Ports. Use these addresses to verify the port map:
• F_Port port 1 (0x010001) mapped to N_Port port 16 (0x310000)
• AoQ = Application oriented QoS. Indicates that the link is capable of QoS. It
should appear on F and N_Ports on switches that are connected to either Brocade
HBAs with an active SAO license or Access Gateways that have a Adaptive
Networking license.
The switchshow command on the Brocade 5100 shows:

• Ports 0, 1, 2 and 3 are connected to the Brocade 300 in Access Gateway mode.
• The number of NPIV public devices is the number of online hosts on the 300, plus
1 for the N_Port connecting the 300 to the 5100.
Footnote 1: Dynamic Mapping

To move a mapping from one N_Port to a different N_Port
ag –-mapdel N_Port F_Port
ag --mapadd N_Port F_Port
If a N_Port is currently mapped to another F_Port, this command removes it from the old
N_Port and add it to the new N_Port.
In the example above, the Access Gateway port map is displayed. The default port map
has been altered so that F_Ports 1 and 2 are now mapped to N_Port 19.
Prior to Fabric OS v7.0.0:

• Mapped F_Ports must be deleted before they can be added to another N_Port
• Delete F_Ports 1 and 2 from currently mapped N_Ports:
B300:admin> ag –-mapdel 16 “1;2”
F-Port to N-Port mapping has been updated successfully
• Add F_Ports 1 and 2 to N_Port 19:
B300:admin> ag –-mapadd 19 “1;2”1
F-Port to N-Port mapping has been updated successfully
• An unconfigured N_Port can set the F-to-N_Port mapping with the ag --mapset
command.
The ag --mapdel command deletes one or more F_Ports from a specific N_Port on
an Access Gateway. The command has two arguments:
• N_Port: The specific N_Port.
• F_Port_list: A semicolon-separated list of F_Ports whose mappings are being
removed from the N_Port. When specifying multiple F_Ports, use “” to surround the
semi-colon separated list; for a single F_Port, “” marks are not required. To identify
ports 2, 4, 5, and 6, specify an F_Port list of “2; 4-6”.
The ag --mapadd command adds one or more F_Ports to a specific N_Port on an
Access Gateway. The command arguments are the same as with ag --mapdel.
The ag --mapset command creates an N-to-F_Port mapping on an unconfigured
N_Port on an Access Gateway. The command arguments are the same as with ag --
mapdel and ag --mapadd.
Static mapping is not supported on the B8000 switch.
See the Access Gateway Administrator’s Guide Supporting Fabric OS v7.0.0 for more
information.
For all the commands above, the only argument is the N_Port on which failover or
failback is to be displayed, enabled, or disabled. For the show commands, omit the port
argument to display the settings for all N_Ports.
Footnote 1: The portcfgnport command is used to monitor and manage N_Ports on

an Access Gateway. The only configuration parameters for an Access Gateway N_Port
are port speed, persistent disable, and NPIV enable.
Footnote 1: Before configuring port 15 as an N_Port, it must be deleted from the existing
port map. Port 15 is currently mapped to N_Port 23.
The ag --modedisable command disables Access Gateway mode. The switch must
be in a disabled state to run this command. The command has no arguments.
The details for each policy will be presented later in this module.
Footnote 1: The Brocade documentation refers to the Auto Port Configuration policy as
„APC‟ even though the command output shows “auto”. Auto Port Configuration is
discussed in the appendix of this module.
A switch in Access Gateway mode supports three policies:

1. Port Grouping
2. Auto Port Configuration
3. Advanced Device Security
The policy must be enabled before it can be used. Port Grouping is enabled by default;
Auto Port Configuration and Advanced Device Security are disabled by default.
In the example above, the Access Gateway is attached to two fabrics. Ports 16 and 18
are attached to Fabric 1 and ports 20 and 22 are attached to Fabric 2. To ensure the
F_Ports mapped to ports 16 and 18 failover only within Fabric 1, ports 16 and 18 are
put into a Port Group (Group 1). Similarly, to ensure the F_Ports mapped to ports 20 and
22 failover only within Fabric 2, ports 20 and 22 are put into a separate Port Group
(Group 2).
In the example above, we see the result of N_Port failover with Port Groups:
• If port 16 fails, F_Ports 0 and 1 failover to Port 18 – the only remaining port in
Group 1. Without port groups, one of the hosts would have failed over to port 20 or
22, which is not attached to Fabric 1. After the failover, the PIDs of the attached
hosts are updated (Host_1 changes from 0x030001 to 0x040403; Host_2
changes from 0x030002 to 0x040404).
• If port 22 fails, F_Ports 12 and 13 failover to Port 20 – the only remaining port in
Group 2. Without port groups, one of the hosts would have failed over to port 16 or
18, which is not attached to Fabric 2. After the failover, the PIDs of the attached
hosts are updated (Host_7 changes from 0x030701 to 0x060203; Host_8
changes from 0x030702 to 0x060204).
The command output above displays the default Port Group (pg0) on a Brocade 300
with the default port map in place.
Any N_Ports not in a user-defined Port Group remain in the default Port Group (pg0).
Preferred N_Port provides an alternate N_Port for F_Ports to failover to. The F_Ports
must have a primary N_Port mapping before a preferred (secondary) N_Port can be
configured.
The ag --prefshow command displays the current Preferred N_Ports on the Access
Gateway. The command has no arguments.
There are currently no Preferred N_Ports – the default setting.
The ag --prefset command sets the Preferred N_Port for an F_Port.
Also known as N_Port Trunking
F_Port Trunking provides the same benefits that ISL Trunking does in the fabric. It
aggregates the bandwidth of each link within the trunk. Each link has an N_Port on one
side (the Access Gateway) and an F_Port on the other (Edge Switch in the fabric). In
addition, all N_Ports within a Trunk use the same 24-bit address.
Ports used for Trunking on the edge switch must be enabled using the portcfgtrunkport
command.
The ports in an F_Port Trunk use a shared port area. All associated N_Ports in the Trunk
share the same index.
Footnote 1: In command output, this is labeled “TI” for Trunk Area port index.
Use the porttrunkarea command to:

• Assign a static trunk area (TA) to a port or port trunk group
• Remove a TA from a port or group of ports in a trunk
• Display masterless F_Port Trunking information
Masterless F_Port Trunking interoperates between the Access Gateway (AG) and Condor-
based platforms. It is designed to (1) prevent reassignments of virtual addresses when
F_Ports come back online after going offline and (2) to increase N_Port bandwidth.
Assigning a static TA to a port or trunk group enables F_Port masterless trunking on that
port or trunk group. When a TA is assigned to a port or trunk group, the ports will
immediately acquire the TA as the area of their process IDs (PID). Likewise, when a TA is
removed from a port or trunk group, the ports will revert to the default area as their PID.
A non-bladed switch uses the area ID. A bladed switch uses the index number.
Footnote 1: Access Gateway cascading is not supported on the B6510.

Access Gateway Cascading provides more flexibility in configurations, more efficient use
of available ports, and additional cable and SFP consolidation.
Footnote 1: Several Edge AGs can connect into a single Core AG to support higher
consolidation ratios.
Only one firmware version upgrade is supported; upgrade from v6.4.x to v7.0.0 will work;
v6.0.x to v7.0.0 will not.
Check release notes for latest upgrade paths.
switch:admin> ag --show
Name : switch_ST1
NodeName : 10:00:00:05:1e:35:9b:e7
Number of Ports : 16
IP Address(es) : 10.115.74.53
Firmware Version : v6.0.0
N_Ports : 4
F_Ports : 10
Policies enabled : pg
Persistent ALPA : Disabled
Port Group information :
PG_ID PG_Members PG_Name PG mode
--------------------------------------------
0 1;3 pg0 -
2 0;2 SecondFabric -
--------------------------------------------
Fabric Information :
Attached Fabric Name N_Ports
---------------------------------------------
10:00:00:05:1e:34:01:d7 0;1;2;3
---------------------------------------------
N_Port information :
Port PortID Attached PWWN FO FB IP_Addr F_Ports
-----------------------------------------------------------
0 0x6d0a00 20:0a:00:05:1e:37:11:aa 1 0 10.32.74.109 4;5;6;
1 0x6d0b00 20:0b:00:05:1e:37:11:aa 0 1 10.32.74.109 7;8;9;
2 0x6d0c00 20:0c:00:05:1e:37:11:aa 1 0 10.32.74.109 10;11;
3 0x6d0d00 20:0d:00:05:1e:37:11:aa 0 1 10.32.74.109 12;13;
-----------------------------------------------------------
F_Port information :
Port PortID Attached PWWN N_Port Preferred N_Port Login
Exceeded?
------------------------------------------------------------
--------------
4 0x6d0a01 21:00:00:e0:8b:83:e3:cd 0 2 no
5 0x6d0a02 21:01:00:e0:8b:a3:e3:cd 0 2 no
6 0x6d0a03 21:00:00:e0:8b:83:3e:ce 0 2 no
7 0x6d0b01 21:01:00:e0:8b:a3:3e:ce 1 3 no
[Truncated Output]
The host does a login request to the AG, which forwards it on to the fabric. The fabric
responds with a PID, which the AG puts in its mapping table, persistently assigning the
PID to the PWWN for that host. The AG simultaneously sends the PID to the host.
If the host logs out, the PID is kept in the mapping table on the AG.
If the host logs back in using the same N_Port on the AG, the AG will search its mapping
table for the PWWN of the host. When it finds the PID associated with the PWWN, it will
request that PID from the fabric, which will respond with the requested PID.
Access Gateway uses a table to maintain a list of available and used ALPAs. When the
number of entries in this table is exhausted, the host receives an error message. You
can remove some of the entries to make space using the ag --deletepwwnfromdb
command.
switch:admin> ag --deletepwwnfromdb PWWN
The max number of entries in the table for each port is set
through the configure CLI command, as follows:
switch:admin> switchdisable
switch:admin> configure
Configure...
Fabric parameters (yes, y, no, n): [no]

F-Port login parameters (yes, y, no, n): [no] y
Maximum logins per switch: (1..25200) [3200]

Maximum logins per port: (1..255) [255]
Logins per second: (0..40) [0]

Login stage interval (milli-seconds): (0..10000) [0]
System services (yes, y, no, n): [no]

Portlog events enable (yes, y, no, n): [no]
ssl attributes (yes, y, no, n): [no]
rpcd attributes (yes, y, no, n): [no]
cfgload attributes (yes, y, no, n): [no]
webtools attributes (yes, y, no, n): [no]
system attributes (yes, y, no, n): [no]
mode - Specifies the manner in which the ALPA is obtained in the event that
the ALPA value is already taken by another host. Valid modes are:
-s Specifies a stringent ALPA request mode. In stringent mode, the login is rejected
if the ALPA is not available
-f Specifies a flexible ALPA request mode. In flexible mode, the host login is
accepted either with the requested ALPA value or with a different ALPA value if the
requested ALPA is not available
ag --printalpamap F_Port - Displays the database entry for the specified port.
An F_Port must be specified. The output displays the PWWN-to-host-ALPA mapping
ag --deletepwwnfromdb PWWN - Removes the specified port WWN entry from the
database after the host has logged out
ag--clearalpamap F_Port Clears the ALPA values for the specific F_Port. This
command removes the PWWN-to-ALPA-value mapping from the database
When Auto Port Configuration is enabled on an Access Gateway, the first major change
is that port roles are not pre-configured as F_Port or N_Port. Instead, Access Gateway
switch ports react as regular switch ports: based on the attached device or switch, the
port automatically configures as an F_Port or N_Port. Users can now attach devices or
switches to any port, without needing to know whether a port is locked as an N_Port or
not.
In the example above, hosts have been attached to an Access Gateway with Auto Port
Configuration enabled. The following ports are configured in different modes than the
default Port Map:
• Ports 7 and 8 are configured as N_Ports because they are attached to a switch. If
Automatic Configuration was disabled and the default Port Map was in effect,
these ports would be F_Ports.
• Ports 12 and 13 are configured as F_Ports because they are attached to hosts. If
Automatic Configuration was disabled and the default Port Map was in effect,
these ports would be N_Ports.
The second major change with Automatic Configuration is there is no pre-configured

Port Map. F_Ports are assigned to the available N_Ports on a round-robin basis, not
based on a user-defined Port Map.
In the example above, hosts have been automatically mapped to the N_Ports as follows:
• Ports 1 (0x090301), 4 (0x090302), and 12 (0x090303) are mapped to N_Port
7 (0x090300).
• Ports 2 (0x090201), 5 (0x090202), and 13 (0x090203) are mapped to N_Port
8 (0x090200).
The third major change with Automatic Configuration is that the Port Map is not fixed –
that is, an F_Port does not always have the same Primary N_Port. As hosts or switches
are attached to the Access Gateway, the Port Map is automatically readjusted to ensure
an even distribution of F_Ports across the N_Ports.
In the example above, a new switch port is attached to port 9, creating a new N_Port
(PID = 0x090400). As a result, the F_Ports are remapped across the three N_Ports. This
results in four of the six hosts (noted with a * symbol above) changing their PID:
• Host_3 has changed from 0x090302 to 0x090401.
The final major change with Automatic Configuration is that there is N_Port Failover, but
no N_Port Failback. When an N_Port fails, the F_Ports mapped to that N_Port are
automatically failed over, and the Port Map is automatically readjusted to ensure an
even distribution of F_Ports across the N_Ports. However, because F_Ports do not have
a Primary N_Port, there is nothing for a failed-over F_Port to fail back to. The absence of
a Primary N_Port also means that there are no Preferred N_Ports or Port Groups when
Automatic Configuration is enabled.
In the example above, a new switch port is attached to port 9, creating a new N_Port
(PID = 0x090400). As a result, the F_Ports are remapped across the three N_Ports. This
results in all of the six hosts (noted with a * symbol above) changing their PID:
The automatic Port Configuration (APC) policy provides the ability to automatically
discover port types (host vs. fabric) and dynamically update the routing maps when a
new connection is detected. This policy is intended for a fully hands-off operation of
Access Gateway. APC dynamically maps F_Ports across available N_Ports so they are
evenly distributed. For example, when a port on an AG is connected to a Fabric switch,
the AG configures the port as an N_Port. If a host is connected to a port on an AG, then
the AG determines that it is connected and configures the port as an F_Port and
automatically maps it to an existing N_Port with the least number of F_Ports mapped to
it.
When the APC policy is enabled, it applies to all ports on the switch. Enabling the APC
policy is disruptive and erases all existing F_Port-to-N_Port mappings. Therefore, before
enabling the APC
policy, you must disable the AG module. When you disable the APC policy, the N_Port
configuration and the F_Port-to-N_Port mapping revert back to the default factory
configurations for that platform.
See the following page for a description of the additions to the “ag” CLI command.
ag --pgcreate- pgid “N_Port1 [; N_Port2;...]” [-n pgname] [-

m “lb; mfnm”] - Creates a port group with the ID pgid and a specified list of
N_Ports to be included in the policy. The list must be enclosed in quotation marks.
Ports must be separated by semicolons. The Port Group ID must not exceed 64
characters. Optionally specify a name for the port group and a mode. Modes are
disabled by default.
ag --pgmapadd pgid "F_Port1[;F_Port2;...]“ - Maps the specified
F_Ports to the PG identified by the pgid. Upon execution, the system identifies the
least loaded N_Port in the port group and maps the F_Ports to that N_Port. The port
list must be enclosed in double quotation marks. Ports must be separated by
semicolons.
ag --pgmapdel pgid "F_Port1[;F_Port2;...]“ - Removes one or more
F_Ports that are part of the port group identified by the pgid from their mapping to a
corresponding N_Port. The port list must be enclosed in double quotation marks. Ports
must be separated by semicolons.
ag --pgsetmodes pgid "lb;mfnm“ - Sets the APC modes for the specified
port group. The mode list must be enclosed inn double quotation marks and the
modes must be separated by a semicolon. Alternately the modes may be set at the
time the port group is created, with the pgcreate command. The following modes are
supported:
lb - Specifies the load balancing mode for the specified port group. If load balancing
mode is enabled and an F_Port goes offline, logins in the port group are redistributed
among the remaining F_Ports. Similarly, if an N_Port comes online, port logins in the
PG are redistributed to maintain a balanced N_Port to F_Port ratio. This operation is
disruptive. Load balancing mode is by default enabled in the default port group 0. It
must be explicitly enabled on any other port group.
mfnm - Enables the managed fabric name monitoring mode (MFNM) in the specified
port group. This command changes the fabric name monitoring mode from “default” to
“managed”. In both default and managed mode, the system queries the fabric name
once every 120 seconds, and if it detects an inconsistency, for example, if the port
group is connected to multiple fabrics, it triggers a RASLOG message. The difference
between default and managed fabric name monitoring is that in managed mode,
failover is disabled for all ports in the port group if the system detects an inconsistency
in fabric names.
Revision 0312 8 - 100

See the following page for a description of the additions to the “ag” CLI command.
Footnote 1: The “fabric name“ of a fabric is the WWN of the principal switch of the
fabric. In AG mode, when you do an “ag --show”, the output will contain a section
that tells you which N-ports are connected to which fabric (according to fabric names).
Revision 0312 8 - 101

With APC Policy and introduction of Login Balancing in PG Policy, the F_Port to N_Port
mapping in an AG can change dynamically depending on addition/removal of ports.
Some admins might want to control this automatic rebalancing feature – which can be
achieved using the agautomapbalance CLI.
The --force option was introduced in order to allow admins to run nightly/weekly
scripts per say – in case the automatic rebalancing is turned off, and system is
unbalanced (e.g.: 10 F_Ports are mapped to 2 out of 5 N_Ports because 3 N_Ports
came online at a later time).
Revision 0312 8 - 102

Revision 0312 8 - 103

Revision 0312 8 - 104

CFP 300 Virtual Fabrics
Revision 0312 9-1

Revision 0312 9-2

Revision 0312 9-3

The unique advantages of Virtual Fabrics apply to a wide range of scenarios, such as:
• Consolidating from two multiple-switch fabrics to two SAN directors with Virtual
Fabrics for each business function.
• Providing storage resources for remote offices without duplicating physical
infrastructure or compromising local SAN security.
• Sharing an existing SAN fabric among multiple customers or business units.
• Dividing SAN administrative responsibilities among individual employees for
security reasons.
Revision 0312 9-4

Logical switches can be interconnected to form logical fabrics.
Each Logical Fibre Channel switch acts as an independent Fabric Element (logic switch)
in terms of protocol and management.
Revision 0312 9-5

Revision 0312 9-6

Footnote 1: Only one version of Fabric OS per chassis (physical

switch/director/backbone)
Each logical switch has its own independent address space. There could be multiple
domain IDs in the chassis. The exact same PID can exist in two different logical
switches/fabrics, in the same chassis. All fabric services are architected to manage
independent data sets for each logical switch/logical fabric.
Footnote2: Logical switches with zero ports assigned can be used as a pre-staging
phase for planning and administration.
Footnote 3: FL_Ports are not supported on 16 Gbps and later platforms. They are
supported on 8 Gbps platforms and earlier. 16 Gbps platforms and 8 Gbps FL_ports are
supported in Virtual Fabrics.
Revision 0312 9-7

Footnote 1: FL_Ports are not supported on 16 Gbps and later platforms. They are
supported on 8 Gbps platforms and earlier.
Footnote 2: No support for F_ or FL_Ports in the base logical switch.
Revision 0312 9-8

FC-SW-3 defines the Exchange Switch Support (ESS). ESS is used to exchange
information between switches in a fabric.
In the fabric below, starting from SW1, the middle switch would be the neighbor, and the
switch on the far right would be the remote switch.
SW1 Neighbor Remote
Although the concept is the same, this is not the same as a FC router FID. For example,
if a logical fabric has a FID = 20 and an EX_Port to the base fabric, the EX_Port cannot
have a FID = 20.
FID Check
• ESS (Exchange Switch Support) 1 exchanges VF-mode and FID information between
switches
• The fabric module checks for any FID conflicts
On detecting FID conflict
• Links to conflicting neighbor switch are disabled
• Links to conflicting remote switch are NOT disabled
• Every FID conflict is logged in the RASLOG as a WARNING
Revision 0312 9-9

You can connect a default switch to a logical switch and they will merge as one fabric as
long as the FIDs are the same and the DIDs are different.
Footnote 1: On chassis-based models, the default logical switch should be used as

storage for unused ports. This is not required, but considered a best practice. This is
also recommended on departmental switches. However, sharing of the default and
base switch gives flexibility due to limits on the number of logical switches that are
supported on departmental switches.
Maximum number of logical switches per chassis:

DCX, DCX-4S, and DCX 8510 Family = 8
5300 = 4
6510 = 4 (3 if logical switch is using FC-FC routing)
5100 & VA40FC = 3
To change the default switch fabric ID use the following command:

lscfg --change <FID> -newfid <NewFID>
Footnote 1: Attempting to upgrade from a version of Fabric OS prior to v7.0 that

supports different interopmodes will result in an error message. Interopmode must be
set to Brocade Native mode (disabled:0) before upgrading. To support interoperability
with M-EOS switches, FC-FC routing must be used.
Footnote 2: FICON support:

• Multiple logical switches supported (up to 2)
• Can utilize more than 256 ports in a single chassis
• Utilizes 48 port blades
• Not on base switch
Footnote 1: Base switch to base switch ISLs are called XISLs (extended inter switch link).
More details on this later in this presentation.
A Logical ISL (LISL) is established from FID 10 on SW1 to FID 10 on SW2 through the
XISL connections on the base switch. The same is true for FID 20. More information
about how this works later in this presentation.
Base Fabric
Implemented as an FC fabric of base switches, the base fabric can contain any Layer 2
switches. Security features can be enabled.
Footnote 1: These connections are physical and therefore require an external physical
connection between each FID (in this example FID 10 and 20) to the base switch. FC-FC
Routing from a base switch supports only edge-to-edge routing. Sharing devices from
the base switch backbone router to an edge fabric is not supported.
More information about how this works later in this presentation.
Note: Before creating EX_Ports between a logical switch and the base switch on FID 20,
all switches that belong to that fabric must have the XISL feature disabled. However,
another logical switch that is not using EX_Ports to the base can still use the XISL
feature on the base fabric.
Footnote 1: Non-VF capable switch or a VF capable switch with VF disabled is also know
as a switch in legacy mode.
DISL: Direct connection between two logical switches (other logical switches cannot use
this ISL).
XISL: Direct connection between two base switches.
LISL: Used for logically connecting two logical switches together through the base switch
XISL.
Footnote 1: The default switch can NOT be a base switch.
Blades (FA4-18, FS8-18 and FC10-6) blades must be in the default switch.
A best practice is to keep only unused ports in the default switch. Assign the ports to
other logical switches as needed.
Footnote 1: Maximum is 2 logical switches and one base switch with the EX_Port.
Even though there are LISLs between the switches using the XISLs, they have a higher
cost than the DISLs. In this example the LISL would be a failover path.
ISL Type Cost

DISL 500
LISL 510
For more information on Virtual Fabrics permission level requirements (chassis/logical

switch), and for commands, refer to the Brocade Command Reference Manual and the
Brocade Fabric OS Administration Guide for more information.
Usage: userconfig
Valid roles for LF and Chassis: admin | user | switchadmin |
zoneadmin | fabricadmin | basicswitchadmin | operator |
securityadmin (For more information on these roles refer to the Brocade Command
Reference Manual.)
--show [username | -a]: display current account information

--showlf <-l <LF_ID>> <-c>: display account names corresponds to lf
list
--add <username> -r <LF role> -l <LF_ID list> [-h <LF_ID>] [-c
<chassis role>] [-d <description>] [-x]: creates a new account
--delete <username>: delete an existing account
--change <username> [-l <LF_ID list> -r <LF role>] [-h <LF_ID>] [-c
<chassis role>] [ -d <description>] [ -e yes | no] [-x] [-u]:
modify existing account attributes
--addlf <username> [-h <LF_ID>] [-l <LF_ID list> -r <LF role)>] [-c
<chassis role>] adds lfs to a user's lf list
--deletelf <username> [-h <LF_ID>] [-l <LF_ID list>] [-c]: deletes
lfs from a user's lf list
--help: display the userconfig synopsis
If –c role is not specified, chassis is set to no access.
Once you click on the OK button above you will return to the switch admin window (see
slide on next page).
A base switch is like a backbone switch and a base fabric is like a backbone fabric.
Footnote 1: If a previously configured EX_Port is moved to a non-base switch, it will be

persistently disabled and the following message will be displayed: EX_Port in non base switch.
To clear the port of this configuration use command portcfgdefault. The
portcfgexport command cannot be used, as this command only works on the base
switch. See the example below:
switch_30:FID30:admin> switchshow
<truncated output>
Area Port Media Speed State Proto
=====================================
1 1 id N4 In_Sync Disabled (ExPort in non base
switch)
<truncated output>
switch_30:FID30:admin> portcfgexport 1 -a 2
Error: EX-Port related operations are allowed on base switch only,
not on any other logical switch.
switch_30:FID30:admin> portcfgdefault 1
Footnote 2: Refer to the Brocade Fabric OS Administrator’s Guide section entitled ―Backbone-to-
edge routing with Virtual Fabrics‖ for information on how to configure legacy FC routers (e.g.
Brocade 7500) for backbone-to-edge routing with Virtual Fabrics.
Footnote 1: Since the base switch does not support the connection of F_Ports, Host A was
connected to the FC router in legacy mode (No VF), which is supported. Because the base fabric
does not support backbone-to-edge routing, Host A cannot see Storage A . However, because
backbone-to-edge routing is supported in legacy mode, Host A can see Storage B.
Host B can see both Storage A and Storage B.
Footnote2: The FID on this IFL connection can not be any of the FIDs used by logical switches. If
so you will get the following:
errdump:
2008/11/15-22:17:47, [FCR-1066], 381, FID 128, ERROR, switch_128,
Fabric on port 8 has the same fabric ID as another fabric.
switchshow:
=====================================
8 8 id N4 In_Sync Disabled (Fabric ID conflict)
In the graphic, assuming all necessary zones and LSAN_ zones have been created and
are working properly, Host B can communicate with Storage A since they are connected
to the same logical switch.
Host B can communicate with Storage B, since the base switch, BS4, is performing the
FC-FC, edge-to-edge fabric routing through the EX_Port connected to the logical switch,
LS3, and the EX_Port connected into Edge Fabric FID 20.
Host A cannot communicate with Storage A since Host A is directly connected to the
backbone fabric and the base switch FC-FC router is the FC router that is connected to
the logical switch LS3. Backbone-to-edge sharing is not supported from a logical base
switch.
Host A can communicate with Storage B since Host A is directly connected to the FC
router in legacy mode within the backbone, and Storage B is connected to the Edge
Fabric FID 2 that physically connects to the FC router in legacy mode. Backbone-to-
edge sharing is supported from legacy mode FC routers.
With Virtual Fabrics use the lscfg command to configure the FID; the fcrconfigure
command is not allowed when Virtual Fabrics are enabled.
Configure...
Fabric parameters (yes, y, no, n): [no] y
WWN Based persistent PID (yes, y, no, n): [no]

Allow XISL Use (yes, y, no, n): [no]
Footnote 1: A Virtual Fabrics base switch that is participating in the backbone of a

MetaSAN, uses the same FID for Virtual Fabrics purposes as well as FC-FC routing
purposes.
The same restrictions that apply to E_Ports and EX_Ports also apply to VE_Ports
and VEX_Ports, respectively.
GE0 and GE1 in an FR4-18i do not need to reside in the same logical switch. This allows
for the partitioning of switches and normal creation of switch routes that could remove
the need to create TI Zones to control GE tunnel usage.
Footnote 1: Virtual Fabrics are not supported on the B7800.
Port sharing example:

•FID 1 and FID 2 are configured to share physical ports
ge0 - ge3
•A VE_Port (logical port) resides in each respective fabric/logical switch
Support VE/VEX for XISL on FX8-24

Allows multiple logical fabrics to share VE/VEX port in the base switch across wide area
network to simplify configuration.
Enables 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 FCIP links are expensive and the ability to share the tunnel link across
multiple fabrics can become a necessity.
The Base fabric will provide the physical connectivity across which logical connectivity
will be established.
This feature is supported only on FX8-24 blades in both 1G and 10G modes.
VE VE
Footnote 1: Fabric OS v6.2 supports Virtual Fabrics on: DCX, DCX-4S, B5300 and
B5100.
Footnote 2: Before logical fabrics can be disabled, all logical switches (except the
default switch) must be deleted.
To turn off this feature the command would be: fosconfig –-disable vf,
followed by a reboot of the switch, which happens automatically.
To verify that the Virtual Fabrics feature has been enabled:
R1-st02-B51:FID128:admin> fosconfig --show

FC Routing service: disabled
iSCSI service: Service not supported on this Platform
iSNS client service: Service not supported on this Platform
Virtual Fabric:enabled
lscfg command options:

lscfg [--create | --delete | --config | --show | --change | --help]
-------------------
lscfg --create FID [-base] [-force]
FID: Required. Fabric ID for this switch. Must be
unique.
-base: Optional. Make this switch the base switch.
Only a single switch may be the base
switch in a chassis.
-force: Optional. Foregoes all user prompts.
-------------------
lscfg --delete FID
FID: Required. Fabric ID for the switch to be deleted.
All ports must be removed from this switch
prior to issuing the command.
-------------------
lscfg --config FID [-port port | port range]
FID: Required. Fabric ID for the switch.
-port: Required. The port to be added to the
switch.
A range may be supplied (example:
-port 6-16).
-------------------
lscfg --show [-provision]
-------------------
lscfg --change FID [-newfid fid] [-base]
FID: Required. Fabric ID for the switch.
-newfid: Optional. The new fid for the switch.
-base: Optional. Makes this switch the base
switch.
lscfg --create FID [-base] [-force]

FID: Required. Fabric ID for this switch. Must
be unique.
-base: Optional. Make this switch the base
switch.
Only a single switch may be the
base switch in a chassis.
Command syntax:
configupload [-all] [-p ftp | -ftp] ["host","user","path","passwd”]
configupload [-all] [-p scp | -scp] ["host","user","path"]
configupload [-all] [-p sftp | -sftp] ["host","user","path"]
configupload [-all] [-force] [-local | USB |-U] ["file"]
configupload [-fid FID | -chassis | -all | -switch] [-p ftp | -
ftp]["host","user","path" [,"passwd"]]
configupload [-fid FID | -chassis | -all | -switch] [-p scp| -
scp]["host","user","path"]
configupload [-fid FID | -chassis | -all | -switch] [-p sftp | -
sftp]["host","user","path"]
configupload [-fid FID | -chassis | -all] | -switch] [-force] [-local |
USB | -U] ["file"]
configupload [-vf] [-p ftp | -ftp] ["host","user","path","passwd"]]
configupload [-vf] [-p scp | -scp] ["host","user","path"]
configupload [-vf] [-p sftp | -sftp] ["host","user","path"]
configupload [-vf] [-force] [-local | USB |-U] ["file"]
Example –vf configuration file:

# BROCADE
# VERSION 700
# PLATFORM 77
# SWITCHCONF
SYSTEM max
{
ATTRIBUTE MAJORVER_C:6
ATTRIBUTE MINORVER_C:4
ATTRIBUTE SYS_NAME:sw0
ATTRIBUTE VF:1
ATTRIBUTE BLADE_IDS1:00603363323263
ATTRIBUTE BLADE_IDS2:4a4d0000000000
ATTRIBUTE ETHSW_ENABLED:1
}
SWITCH fcsw-0
{
ATTRIBUTE FID:128 SWNAME:R1.ST02.DCX.851
USR:1800 GE:128 ICL:32 DS:1 TID:833892288 SWNAME2:0.4
LF:0
PIN 5
PORTMAP FC:[0-191,256-287,736-751,784-799]
PORTMAP GE:[0-255]
}
SWITCH fcsw-1
{
ATTRIBUTE USR:1800 GE:128 FID:10
SWNAME:switch_10 SWNAME2: LF:1
PIN 5
PORTMAP FC:[192-255]
}
LSs’ FIDs and assigned

ports
Footnote 1: The FID determines which fabric the switch is in.
After selecting to enable Virtual Fabrics the following pop-up message appears. Click
OK to proceed.
A default switch with FID 128 is created which contains all switch ports.
Select the Chassis (physical switch/director) you are going to be working with:
This is very important:

Whichever chassis is chosen
will be the only chassis
configuration changes will be
made to.
Select the Port Display Option:
New Logical Fabric Template:
1. Select the Chassis (physical switch or director)

2. Click New Fabric
New Fabric: Fabric tab

1. Enter the Logical Fabric ID.
2. Perform one of the following tasks based on if your switch is going to be a Base
switch:
a. Check Base Switch if the switch is going to be a Base Switch.
b. If the switch is not going to be a base switch:
• Select 256 Area Limit (Address Mode)
• Disable—select to disable this option.
• Zero Based Area Assignment—select to enable a 256 port number limit with
Zero Based Assignment for all logical switches in the selected logical fabric. If
ports with indexes greater than 256 are added to a logical switch in this mode,
this logical switch may not be compatible with domain-index zoning.
• Port Based Area Assignment—select to enable port number area assignment.
Ports with indexes greater than 256 can be added to a logical switch in this
mode.
• Select Base Fabric for Transport – if XISLs in the base switch are going to be
used for transport.
• Interoperability Mode: If Base Switch selected this is disabled (Brocade Native,
McDATA Native (IM-2) or McDATA Open (IM-3)).
Most of the time the other parameters should be left at the defaults: However, there
may be times when these settings should be changed. Following is more information
about these other settings:
• Enter a resource allocation timeout value in the R_A_TOV (default is 10000 seconds)
field. This is the amount of time given to devices to allocate the resources needed to
process received frames.
• Enter a error detect timeout value in the E_D_TOV (default is 2000 seconds) field.
This is the basic error timeout used for all Fibre Channel error detection.
• Enter a wide area network timeout value in the WAN_TOV (default is 0 milliseconds)
field. This is the maximum frame timeout value for a WAN.
• Enter a value in the Maximum Hops (default is 7) field. This is the number of hops a
frame can traverse to reach a destination port from any source port across a fabric.
• Enter the buffer-to-buffer credit in the BB Credit (default is 16) field. This represents
the number of buffers available to attached devices for frame receipt.
• Enter a value in the Data Field Size (default is 2112) field. This specifies the largest
possible value, in bytes, for the size of a type-1 (data) frame.
• Select the Sequence Level Switching check box to enable frames of the same
sequence from a particular source are transmitted together as a group. When this
check box is clear, frames are transmitted interleaved among multiple sequences.
• Select the Disable Device Probing check box to not show devices that do not register
themselves with the Name Server in the Name Server database. Set this mode only if
the switch's N_Port discovery process (PLOGI, PRLI, INQUIRY) causes some attached
device to fail.
• Select the Per-frame Routing Priority check box to enable the virtual channel ID to be
used in conjunction with a frame header to form the final virtual channel ID.
• Select the Suppress Class F Traffic check box to convert Class-F traffic to Class-2
traffic before being transmitted.
• Select the Long Distance Fabric check box to enable ISLs in a fabric can be up to 100
km long. The exact distance is determined by the per-port configuration on the
E_Ports of each ISL. Configure both E_Ports in an ISL to run the same long-distance
level; otherwise, the fabric segments.
• NOTE The Brocade Extended Fabrics license is required to set this mode.
New Logical Switch (default settings based on Fabric Template) There are some settings
that are now based on the configured template settings. In our example the fabric
template was for a base switch so the address mode (256 address mode) and
Interopmode mode options have been grayed out. This can be undone by unselecting
the Base Switch option.
It is possible when adding ports to a logical switch to select and move disparate ports
numbers in a single operation using Network Advisor.
Before Start is selected the Logical Switch Change and Configuration Status windows
looks as follows:
Sequence of steps to add ports to a logical switch: (this operation could be done before
the logical switch was formally created on the physical chassis or after)
1: Select the Chassis
2: Select the ports (unlike the CLI, ports can be picked out of sequence; example I could
pick 8-9 and 15-17 at the same time)
3: Select the Logical switch you want to add the ports to
4: Click the right arrow button to add the ports to the selected switch
Note: Notice the switch is listed as ―Undiscovered‖; this is true as the newly create
Logical switch has not been discovered by Network Advisor. More on this later.
Before Start is selected the Logical Switch Change and Configuration Status windows
looks as follows:
To rediscover the fabrics from the main menu select Discover > Setup
Select any fabrics and switches which have been changed and click Delete to remove
them from the discovered list.
Note: If the change was only moving ports from one logical switch to another, you do not
need to rediscover.
The newly created base logical switch is its own fabric at this point. The current view
shows a base logical switch a VF enabled chassis (default switch) and non VF capable
switch which is ISL’ed to the default switch.
CFP 300 Module Name
Revision 0312 64
Adding Virtual Fabric capable devices to the existing environment is non-disruptive. In

this use case, the Default switch is connected to switches in an existing fabric and all its
ports are part of the "grey" fabric on the right.
The Logical Switch capability is used to create a Base switch which will be used as the
Backbone Fabric with Integrated Routing. No other Logical Switches or Fabrics are
created.
Since FC-FC Routing services are enabled using the Base switch in the VF enabled DCX,
as bandwidth for routing is required, ports in the Default switch can be allocated to the
Base switch and configured for Integrated Routing providing dynamic scalability of
routing services.
For some environments where FOS fabric islands were used to provide fault and
management isolation, Virtual Fabrics can provide equivalent fault isolation while
simplifying the cable plant via ICL connections and improving utilization of ports as any
port can be dynamically allocated to a Logical Fabric when needed.
In this configuration, virtual server clusters are used for Tier-2 and Tier-3 applications
while single server per application is used for higher performance, Tier-1 applications.
Three Logical Switches are created on the DCX. Two are attached to Access Gateway
switches in Blade Server Chassis. Each Blade Server is assigned to an application tier.
Virtual server software is used to create server clusters and virtual machines to host the
applications in each tier.
Virtual Fabrics provides independent management, per-port fabric scalability and full
data path isolation by application.
In this configuration, each replication application uses a separate Logical Fabric

extended over the WAN cloud. The Logical Fabric spans two geographically separated
sites using FCIP and VE_Ports.
DCX-1 has a GE port on an FR4-18i assigned to LS-1 which is configured as a VE_Port.

All (8) tunnels in the VE_Port are part of the same Logical Fabric. The second GE port is
assigned to LS-2 configured as a VE_Port. Traffic within LS-3 has no VE_Port assigned
to it, and its traffic does not go over the WAN cloud
DCX-2 has an FR4-18i with (1) GE port assigned to LS-5 and another GE port assigned
to LS-6. The VE_Ports in each Logical Switch create a "tunneled" E_Port connection
between the Logical Switches with the same Fabric ID in each DCX. Again, LS-7 in DCX-
2 does not send any traffic over the WAN cloud since it does not have a VE port
assigned to it.
There are two configuration options possible when using Encryption with the Virtual
Fabrics feature.
Option 1: The FS8-16 encryption blade is used. Encryption ports (grey) must be in the
Default Switch.
Integrated Routing ports (EX_Ports) are created in the Base Switch and attached to
E_Ports in the General Logical Switches and the Default Switch.
All traffic requiring encryption is routed to the Encryption Services in the Default Switch.
Option 2: The Encryption switch is used.

ISL connections between the Encryption switch and the Standard Logical Switches carry
traffic to the Encryption Service.
When attaching an Access Gateway to a Logical Switch, the physical port and all NPIV
connections defined are in a single Logical Fabric.
Different Port Groups can be connected to separate Standard Logical Switches.
Fixed Addressing Mode

This is the default addressing mode used in all the non-VF platforms and the VF platforms
except the DCX platform. In this mode, each port has a fixed address assigned by the
system based on the port number and does not change unless the user chooses to swap
the address using portswap CLI.
In the non-VF mode, this addressing mode would support shared areas as in Fabric OS
v6.1. In order to support FICON in this mode, there should not be any shared area ports in
the chassis (i.e. 48 port blades). Thus all the restrictions applicable for shared area ports
continue to exist in this mode. Additionally ICL ports are not addressable or manageable by
FICON CUP and therefore will not be visible by the mainframe. However ICL’s can still carry
FICON traffic between connected chassis.
In the VF mode, the shared area ports would have the most significant 2nd bit of the ALPA
set to 1. Thus the number of NPIV devices supported on shared ports will be reduced to 64
from 128 in VF mode. Also in the VF capable platforms, the FC addresses are always
unique with a logical switch. Thus the same FC address can co-exist in two different logical
switches in the same chassis.
SW1:admin> switchshow
Index Slot Port Address Media Speed State Proto
===================================================
216 10 24 1fc9c0 id N4 Online E-Port ….
217 10 25 1fc980 id N4 Online E-Port ….
<truncated output>
sw2:FID10:admin> configure
Configure...
Domain: (1..239) [1] 11
Allow XISL Use (yes, y, no, n): [yes]
Enable a 256 Area Limit
(0 = No,
1 = Zero Based Area Assignment,
2 = Port Based Area Assignment): (0..2) [0] 1
Enable Area limit: The 256 area limit allows the partition to be configured for 8-bit addressing rather than
the default 10-bit addressing. Each port in this partition is given a unique area represented by the middle
8 bits of the PID. Valid values are:
0: No limit is imposed on the area. This is the default value. The partition is configured for 10-bit
addressing and supports up to 1800 ports.
1: The unique area assignments begin at zero regardless of where the port is physically located. This
allows FICON users to make use of high port count port blades with port indexes greater than 256.
However, this mode is not compatible with domain-index zoning.
2: The unique area assignments are based on the port index. This mode does not allow FICON users to
make use of ports with an index greater than 256 (high ports of a high port count blade), but this mode is
compatible with domain-index zoning. This parameter is configurable only if the switch is Virtual Fabrics-
aware and Virtual Fabrics is enabled on the switch.
When enabled, this feature supports Dynamic Area Mode in default partitions on the
Brocade DCX, DCX-4S, DCX 8510-8, and DCX 8510-4. Dynamic Area Mode is disabled
by default. When enabled, Dynamic Area Mode supports both static and dynamic area
assignment. Use the portAddress command to perform a static assignment of an area
to a given port. In Dynamic Area Mode, areas are dynamically assigned to the ports (up
to a 255 limit). Port area assignments are persistent; however, disabling Dynamic Area
Mode with configure resets the area assignments. This feature is configurable only on
the default switch. Enabling Dynamic Area Mode fails under one or more of the
following conditions:
•The number of ports in the default partition exceeds 255.
•An AP blade with FL ports is present in the chassis (Brocade Encryption blade, or FCoE
10-24.
sw2:FID10:admin> configure
Configure...
Domain: (1..239) [1] 11
Allow XISL Use (yes, y, no, n): [yes]
Enable a 256 Area Limit
(0 = No,
1 = Zero Based Area Assignment,
2 = Port Based Area Assignment): (0..2) [0] 2
Noticed the Shared area is gone.
10 bit Addressing Mode

This addressing mode was introduced in Fabric OS v6.2.0 and would be the default
mode for all the dynamically created logical switches in the DCX chassis. This mode
supports 10 bit area addressing model allowing us to support up to 1024 F-ports in a
logical switch. This is not a configurable mode. This is achieved by borrowing the most
significant 2 bits from the ALPA field of the FC address. While this scheme is flexible to
support a large number of F-ports, it also reduces the number of NPIV/loop devices
supported on a port to 64.
In order to overcome this issue, a flexible approach is used where a block of 10 bit
addresses are reserved for specifically assigning to NPIV/Loop ports. Under this
scheme, 4 contiguous 10 bit addresses are used for a single NPIV/Loop port so that it
can support 256 devices.
As per this scheme, the areas would be dynamically assigned depending on the port
type. And once an area is assigned to the port, the area remains persistent across
reboots and offline until the port type changes.
Also, since each port has a unique 10 bit area address, there is no need to have shared
area ports in a logical switch. Thus when a shared area port is moved to a logical switch
in the DCX chassis, they don’t have any of the shared area port restrictions [like support
of L-ports]
Note: areas 0x00 – 0x8F [144 in total] are reserved for 8-bit addresses and areas 0x90
– 0xFF [112 in total (with all combinations of 00, 01, 10, 11 in the borrowed 2 ALPA bits
= 448)] are used for 10-bit addresses supporting 448 F-Ports in DCX Chassis
portaddress - Assigns the low 16 bits of the Fibre Channel Port ID.
SYNOPSIS
portaddress --bind [slot_number/]port_number [16-bit_address]
[--auto]
portaddress --unbind [slot_number/]port_number
portaddress --show [[slot_number/]port_number]
portaddress --findPID 24-bit_Port_ID
portaddress –help
DESCRIPTION
Use this command to bind the 16-bit address to the lower two bytes of a port 24-bit Fibre
Channel address, or to unbind the currently bound address for the specified port. Changes
effected by this command are persistent across reboots and power cycles.
The port must be offline to bind an address and not currently bound to another address. If
the port is currently bound to another address, use this command with the –unbind option to
unbind the port.
This command returns an error if the chosen address is in use or is bound to another port. If
the address is currently assigned to another port, use this command with the --findPID option
to identify the port that is bound to that address, and then unbind the port.
The command provides a --show option that displays the currently bound address for a
specified port or for all ports. Alternately, you can use the --findPID option to display the port
currently bound to a specified port ID (PID).
OPERANDS
This command has the following operands:
--bind slot_number port_number 16_bit_address
Assigns the lower two bytes of the Fibre Channel address to the specified port.
slot_number: Specifies the slot number on bladed systems, followed by a slash (/).
port_number :Specifies the port number, relative to its slot on bladed systems.
16-bit_address: Specifies the 16-bit address to be bound to the FC address. Note that
only 10 bits of the area can be used for a unique route. Therefore, not all addresses in the 16-
bit range are available.
--auto
Enables auto-binding on the specified port. If the auto feature is enabled, the entire
area field of the PID is bound to a single port. With 10-bit routing, up to 4 ports can share the
same 8-bit area field of the PID. This address assignment mode dedicates all four unique
routes to a single port. By default, auto is off. This operand is optional; if unspecified, the
default is used.
--unbind
Removes both the address and any auto mode override configuration from the
specified port.
--show
Displays the currently bound address attributes for the specified port. This command
shows the lowest two bytes of the Fibre Channel address as well as the current setting for
auto mode. If a port is not specified, the display shows all ports on the current partition. A -1 is
displayed for ports that have not been assigned an area. Areas are dynamically assigned an
address as they are added to a partition.
--findPID 24-bit_Port_ID
Displays the port (slot and port offset) of the port that is currently assigned the
provided address. This command applies the 10-bit area mask to the provided PID and
returns the port that has been assigned the specified address. Therefore not all 24 bits are
required to match exactly.
24-bit_Port_ID: Specifies the 24-bit Fibre Channel port address. This operand is required
with the –findPID option. This command applies the 10-bit area mask to the provided PID
and returns the port that has been assigned the specified address. Therefore not all 24 bits
are required to match.
--help
Displays command usage.
Sw1:admin> portaddress –-show
Index Slot Port Area Mode

=============================== Notice 4 x 64
112 12 0 0xe3c0 10 bit
113 12 1 0xe380 10 bit address blocks
114 12 2 0xe340 10 bit 80 (80, 90, a0 and
115 12 3 0xe300 10 bit
116 12 4 0xe2c0 10 bit
b0) –> c0
117 12 5 0xe280 10 bit
118 12 6 0xe240 10 bit
119 12 7 0xe200 10 bit
120 12 8 0xe1c0 10 bit
121 12 9 0xe180 10 bit
122 12 10 0xe140 10 bit
<truncated output>
To display the port bound to a specified address.

Sw1:admin>portaddress --findPID 0x2400
Index Port Port ID

===================
36 36 0x 2400
Fixed address mode:

===================================================
112 12 0 017000 -- N8 No_Module Disabled
Zero Base address mode:

===================================================
Port base address mode:

===================================================
10bit base default mode:

===================================================
112 12 0 01e3c0 -- N8 No_Module Disabled
113 12 1 01e380 -- N8 No_Module Disabled
116 12 4 01e2c0 -- N8 No_Module Disabled
switch_128:FID128:admin> configurechassis
Configure...
cfgload attributes (yes, y, no, n): [no] y
Enforce secure config Upload/Download (yes, y, no, n): [no]

Enforce signature validation for firmware (yes, y, no, n): [no]
Add Suffix to the uploaded file name (yes, y, no, n): [no]
Custom attributes (yes, y, no, n): [no] y
Config Index (0 to ignore): (0..1000) [0]
system attributes (yes, y, no, n): [no] y
system.blade.bladeFaultOnHwErrMsk: (0x0..0xffff) [0x0]

system.cpuLoad: (10..121) [121]
system.i2cTurboCnfg: (0..2) [1]
Note: system.blade.bladeFaultOnHwErrMsk
If this field is set to a value other than 0, any nonfatal HW ASIC data parity error causes
the problem blade to be powered off.
To see chassis configuration only: configshow --chassis (must have chassis

permissions)
Footnote 1: The setcontext command could be used to get from one logical
switch to another, and then run the configshow command on each logical switch
(one at a time). However, it could also see any switches the user does not have
access to.
Configuration file information: When uploading a Fabric OS v6.1 configuration file into a
Fabric OS v6.2 switch, most of the information will be applied to the default switch or
the chassis level configuration. Some items, such as switchname, will not be restored.
Footnote 1: Since ports can be moved out of the default switch, only configurations
related to default switch ports apply.
Footnote 2: This is really important when a physical switch is replaced. If the

configuration file and the physical switch do not match (logical switches and FIDs), the
user would have to either:
A. Edit the configuration file (which can be difficult) or, B. Configure the physical switch
to match the configuration file.
Footnote 3: For example: Let’s assume a physical switch has three logical switches. The
second one needs a change that requires it switch to be offline, the download would
work on the first logical switch, fail on the second logical switch, and would not attempt
the third logical switch.
If a configupload -all command is run, all logical switches and chassis

information is returned. The file can then be edited, and only the information for a single
logical switch can be downloaded, if necessary.
Note: If ports have been moved from one logical switch to another, and then a
configdownload command is run, the ports will NOT be moved back. However,
port configuration information (such as speed) will be updated. In other words port
configuration information is saved in the configupload file but port to logical switch
mappings are not.
The bladebeacon command has been removed from Fabric OS, since ports can be in
multiple logical switches.
Use the chassisbeacon command to enable or disable beaconing on a chassis.

Chassis beaconing can be used to locate a failing port. When beaconing mode is
turned on, the port LEDs flash green at various rates across the chassis. The
beaconing continues until you turn it off. Beaconing mode takes over the port LEDs.
The normal flashing LED pattern associated with an active, faulty, or disabled port is
suppressed, and only the beaconing pattern is shown. Other commands are still
executable and functional. However, if diagnostic frame-based tests, such as
portloopbacktest, are executed, the diagnostic LED pattern is interleaved with
the beaconing pattern.
The firmwaredownload command syntax, and command-line options remain

unchanged.
Virtual Fabrics capable switches that ship with Fabric OS v6.2.0 or later will have the
Virtual Fabrics feature enabled by default.
Footnote 1: Start with the Standby CP.
Revision 0312 9 - 100

Revision 0312 9 - 101

Revision 0312 9 - 102

Footnote 1: Requires Fabric OS v6.2 or later
Footnote 2: The FID determines which fabric the switch is in.
Revision 0312 9 - 103

Footnote 1: It is required to have a B series switch as the seed switch for Network
Advisor
In this example the VF feature is also enabled on a DCX. This was done to show
certain outputs but would not be required for this example.
Listed below are the steps required for the example:

• Enable VF
• Create a base switch
• Create a logic switch (to be used by the Fabric OS fabric; the default switch will be
used for the M-EOS fabric)
• Set the fabric parameters
• Set the default switch to Interopmode 2
• Set the address modes
• Move ports from the default switch the base and logical switches
Revision 0312 9 - 104

This example will create a base switch (FID = 30) on the DCX (ports 10/24 and 10/25)
and the B5100 (ports 8 and 9).
On the B5100 ports 0,1 and 4 will be left in the default fabric (which will be used for the
M-EOS fabric). Also, any unused ports will be left in the default fabric.
The remaining ports( 2-7 and 10-23) will be put into LS FID=10 (Fabric OS fabric). Two of
these ports (16 and 17) will be DISL connections to the B48000 director.
Revision 0312 9 - 105

Revision 0312 9 - 106

Revision 0312 9 - 107

Revision 0312 9 - 108

Logical switches can be created / deleted without affecting other logical switches.
FID 10 will be used for the Fabric OS fabric

FID 30 is the base fabric
FID 128 (default) will be used for the M-EOS fabric
Revision 0312 9 - 109

The default switch was created when Virtual Fabrics were enabled. At this point all ports
are assigned to the default switch.
FID 10 will be used for the Fabric OS fabric

FID 30 is the base fabric
FID 128 (default) will be used for the M-EOS fabric
Revision 0312 9 - 110

Base switch:
Putting ports 8 and 9 into the base switch (FID = 30); these will be XISL connections
between the B5100 and the DCX.
Default switch: (M-EOS)

Ports 0,1 are DISL connects to the M-EOS fabric.
Attached to port 4 is a storage device that the customer wants hosts attached to the M-
EOS fabric to have access to.
Ports 24-39 are not used (requires a POD licenses to enable), these unused ports will be
left in the default switch.
The default switch will also be used as the ―seed switch‖ to discover and manage the M-
EOS fabric using Network Advisor.
Logical switch FID 10: (Fabric OS)

The remaining ports 2-3, 5-7 and 10-23 will be put into the LS FID=10 (Fabric OS fabric).
Two of these ports (16 and 17) will be DISL connections to the B48000 director.
Revision 0312 9 - 111

Note: Another way this could have been done was just change the default switch FID to
10 and all the ports, including the unused ICL ports, would have been in the same VF as
the Logical switch created on the B5100. The command to do this would be:
sw0:FID128:admin> lscfg --change 128 -newfid 10

Changing of a switch fid requires that the switch be
disabled.
Would you like to continue [y/n]?: y
Disabling switch...
All active login sessions for FID 128 have been terminated.
Checking and logging message: fid = 128.
Please enable your switch.
sw0:FID128:admin> setcontext 10
sw0:FID10:admin>
Now the default switch with all the ports in it has the same FID as the Fabric OS
logical switch in the B5100
Revision 0312 9 - 112

128 Default switch used for the M-EOS Fabric

10 Logic switch used for the Fabric OS Fabric
30 Base Switch used for XISL connections between the B5100 and the DCX. Can also be
used at a later date for EX_Ports to share devices between the Fabric OS and M-EOS
Fabrics (A customer requirement).
Running this same command on the DCX shows the two ports on the base switch.
Notice that ports 10/24 and 10/25 are in the Base switch (FID=20) all other ports on
slots 3 and 10 are in the in the Logical Switch (FID = 10) and all unused ports (ICL ) port
were left in the Default Switch (FID = 128)
Revision 0312 9 - 113

Revision 0312 9 - 114

On the default switch: Set the domain ID, turn off ―Allow XISL‖ (this must be done before the
interopmode can be set.
Once the switch is enabled run a switchshow command.
sw0:FID128:admin> switchshow
switchName: sw0
switchType: 66.1
switchState: Online
switchMode: McDATA Fabric
switchRole: Subordinate
switchDomain: 128 Notice the only ports
switchId: fffc80 shown in the
switchWwn: 10:00:00:05:1e:0c:97:47
switchshow output are
zoning: ON (cfg2)
switchBeacon: OFF the port assigned to this
FC Router: OFF switch
Allow XISL Use: OFF
Fabric ID: 128

=====================================
0 0 id N4 Online E-Port 10:00:08:00:88:e3:24:dd "r6-ST04-B44-
1"
1 1 id N4 Online E-Port 10:00:08:00:88:e3:24:dd "r6-ST04-B44-
1" (upstream)
4 4 id N4 Online L-Port 5 public
24 24 -- N8 No_Module (No POD License) Disabled
<truncated output>
Revision 0312 9 - 115

Revision 0312 9 - 116

The full sequences of steps are as follows:

setcontext 10 (Log into logical switch 10)
switchdisable (Disable switch to configure it)
configure (Set domain ID, address mode etc…..)
Switchenable (Enable switch to bring ports online)
Revision 0312 9 - 117

Revision 0312 9 - 118

Revision 0312 9 - 119

Revision 0312 9 - 120

The two logical switches (FID 10) in the B5100 and the DCX are connected through the
XISL connections in the base fabric.
Revision 0312 9 - 121

CFP 300 Module Name
Revision 0312 122

BCFP CFP300 StudentGuide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BCFP CFP300 StudentGuide

Uploaded by

Copyright:

Available Formats

CFP 300

Corporate Headquarters - San Jose, CA USA

European Headquarters - Geneva, Switzerland

Asia Pacific Headquarters - Singapore

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

Revision 0312 1–1

Revision 0312 1–2

Revision 0312 1–3

Revision 0312 1–4

Revision 0312 1–5

This course also includes web-based training components.

Revision 0312 1–6

Revision 0312 1–7

Revision 0312 1–8

Learn more about the program at our website:

Revision 0312 1–9

Registering for a certification exam:

Facebook — Brocade Certified

For a list of Brocade University courses please see our website:

Footnote 1: Use CTRL+6 as a shortcut to create PDF notes.

Revision 0312 2-1

Revision 0312 2-2

Revision 0312 2-3

Footnote 1: Includes implementing and configuring the underlying physical connectivity

Revision 0312 2-4

Revision 0312 2-5

Footnote1: Interopmode is no longer supported on E_Ports beginning with Fabric OS

Revision 0312 2-6

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

Footnote 2: In an FC-FC routed environment, EX_Ports can be set to specific

Revision 0312 2-7

Revision 0312 2-8

Revision 0312 2-9

From the point of view of a switch in an edge fabric an EX_Port is virtually

Footnote 1: Training course CFA200: Brocade Certified Fabric Administrator (BCFA) 16

Footnote 5: Check corresponding Release Notes for latest information.

Footnote 1: TopTalkers in F_Port mode is supported with IR.

Fabric OS v7.0.0 Scalability

FC-FC Routing Scalability (MetaSAN)

Max # edge fabrics per metaSAN 48

Footnote 1: All BB FCRs with Fabric OS v6.0.0 and above.

FC-FC Routing Scalability (Backbone)

Max # L2 switches per backbone fabric 12

FC-FC Routing Scalability (Edge)

Footnote 1: M-EOS fabrics must be running M-EOS 9.6.2 firmware or later.

FC Router WWN: 10:00:00:05:1e:9a:71:af, Dom ID: 98,

Info: 10.255.240.76, "R11-ST10-B51"

EX_Port FID Neighbor Switch Info (enet IP, WWN, name)

3 10 10.255.240.75 10:00:00:05:1e:0b:ba:7e "R11-ST10-B30“

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 0312 3-1

Revision 0312 3-2

Revision 0312 3-3

Revision 0312 3-4

BB_B51:admin> fddcfg --showall

Fabric Wide Consistency Policy:- ""

Revision 0312 3-5

BB_B51:admin> fddcfg --showall

Fabric Wide Consistency Policy:- ""