Beruflich Dokumente
Kultur Dokumente
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
b currently
be tl available.
il bl C Contact
t taB Brocade
d sales
l office
ffi for
f information
i f ti on feature
f t and
d product
d t availability.
il bilit
Export of technical data contained in this document may require an export license from the United
States government.
Objective: The BCNE Nutshell guide is designed to help you prepare for the BCNE Certification, exam number
150-120.
Audience: The BCNE Nutshell self-study guide is intended for those who have successfully completed the
ETH 101 and 103 courses, and who wish to undertake self-study or review activities before taking the actual
BCNE exam. The BCNE guide is not intended as a substitute for classroom training or hands-on time with
Brocade products.
How to make the most of the BCNE guide: The BCNE guide summarizes the key topics on the BCNE exam for
you in an easy to use format. It is organized closely around the exam objectives. We suggest this guide be
used in conjunction with our free online knowledge assessment test - CNE 101-WBT BCNE Knowledge
Assessment. To benefit from the BCNE guide, we strongly recommend you have successfully completed the
ETH 101 and 103 courses.
We hope you find this useful in your journey towards BCNE Certification, and we welcome your feedback by
sending an email to jcannata@brocade.com.
Table of Contents
1 - Layer 1/Hardware Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Physical Media Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
SFP Transceivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Media Access Control (MAC) Address Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Terminology - Layer 1 Key Cabling Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Terminology - Layer 1 Media Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Implementing POE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
POE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Cabling Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Implementing Hardware Platforms and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
File management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Digital Optical Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 - Layer 2 Switching and Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
PVST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
The Root Bridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
BPDUs (Bridge Protocol Data Units) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Fast Port Span. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Topology Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Layer 2 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Clearing MAC Address Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
UDLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Switch Frame Forwarding Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VLAN Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
802.1q Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Configurin Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Link Aggregation Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Trunking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
LACP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 - General Layer 2/Layer 3 Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
General Routing and Switching Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Ethernet Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Spanning Tree Protocol (STP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Traffic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Defining a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
VRRP-E (Virtual Router Redundancy Protocol - Enhanced) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 - Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
General Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Classless Inter-Domain Routing (CIDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Variable Length Subnet Masks (VLSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Routed Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Designated Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
LSA Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
BGP (Border Gateway Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
What is BGP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Injecting Routes into BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
BGP Connectivity Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Multicast Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
PIM Sparse Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Mapping IP Multicast to a MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
List of Tables
Default Routing Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
List of Figures
MAC Address Inside an Ethernet Frame .................................................................................................................................................................................. 7
Per VLAN Spanning Tree......................................................................................................................................................................................................... 10
Switch Frame Forwarding Methods ....................................................................................................................................................................................... 14
VLAN Tagging........................................................................................................................................................................................................................... 15
802.1q Tagging (Packet Format) ........................................................................................................................................................................................... 16
Dynamic Trunks ...................................................................................................................................................................................................................... 18
Ethernet Frame Format .......................................................................................................................................................................................................... 19
Default Routes ........................................................................................................................................................................................................................ 20
Subnetting ............................................................................................................................................................................................................................... 23
IP Multicast Mapping .............................................................................................................................................................................................................. 29
802.11b Spectrum ................................................................................................................................................................................................................. 33
Sample NDA ............................................................................................................................................................................................................................ 42
Sample Question..................................................................................................................................................................................................................... 43
Example Exam Score Sheet ................................................................................................................................................................................................... 44
SFP Transceivers
The small form-factor pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunica-
tion and data communications applications. It interfaces a network device motherboard (for a switch, router,
media converter or similar device) to a fiber optic or copper networking cable. It is a popular industry format.
SFP transceivers are designed to support SONET, Gigabit Ethernet, Fibre Channel, and other communications
standards. The standard is covering SFP+ supporting data rates up to 10 Gbit/sec (to also include for 8 Gbit/
sec Fibre Channel, and 10 GbE). The SFP+ has a smaller form factor than a regular SFP. 1000 Mbit TX SFPs
could be used on “non-combo” ports if copper is required.
Implementing POE
POE Overview
Power over Ethernet (POE) devices, are compliant with the IEEE 802.3af standards for delivering in-line power
over existing network cabling infrastructure, enabling multicast-enabled full streaming audio and video appli-
cations for converged services, such as, Voice over IP (VoIP), WLAN access points, IP surveillance cameras,
and other IP technology devices. POE technology eliminates the need for an electrical outlet and dedicated
UPS near IP powered devices. With power sourcing devices, power is consolidated and centralized in the wir-
ing closets, improving the reliability and resiliency of the network. Because POE can provide power over Ether-
net cable, power is continuous, even in the event of a power failure. An error message will be displayed if the
device attached does not support POE.
Cabling Requirements
The 802.3af standard currently supports POE on 10/100/1000 Mbps Ethernet ports operating over standard
Category 5 unshielded twisted pair (UTP) cable or better. If your network uses cabling categories less than 5,
you cannot implement POE without first upgrading your cables to CAT 5 UTP or better.
File Management
The secondary partition of the flash card may be used as the storage space for upgrade code.
Layer 2 Protocols
PVST
In environments with multiple VLANs, the Per VLAN Spanning Tree Protocol may be used. Brocade Layer 2 and
Layer 3 Switches support standard STP as described in the IEEE 802.1D specification. PVST is enabled within
each VLAN as it is enabled on an L2 switch. The enhanced PVST+ support in release 07.6.01 allows a Brocade
device to interoperate with PVST spanning trees and the IEEE 802.1Q spanning tree at the same time. IEEE
802.1Q and PVST regions cannot interoperate directly but can interoperate indirectly through PVST+ regions.
• Each VLAN has its own Spanning Tree instance
• Each VLAN has its own Root Bridge
• Ports blocked by one STP instance can be used by another STP instance
FastIron II
VLAN 2 VLAN 33
1 Link 2 3 Link 4 5 L in k 6 7 L in k 8 Co n s o l e
1 2 3 4 5 6 7 8 9 10 1131 11
24 15 16 17 18 19 20 21 22 23 24
1 2 3 4 5 6 7 8 9 10 1131 11
24 15 16 17 18 19 20 21 22 23 24
1 2 3 4 5 6 7 8 9 10 1131 11
24 15 16 17 18 19 20 21 22 23 24
Switch 1
Switch 2
FastIron II
1 2 3 4 5 6 7 8 Co n s o l e
L in k Link L in k L in k
1 2 3 4 5 6 7 8 9 10 1131 12
14 15 16 17 18 19 20 21 22 23 24
1 2 3 4 5 6 7 8 9 10 1131 12
14 15 16 17 18 19 20 21 22 23 24
1 2 3 4 5 6 7 8 9 10 1131 12
14 15 16 17 18 19 20 21 22 23 24
VLAN 2 VLAN 33
ple switches share a connection that is not a root port, one of them will become the designated port, the other
will block.
Topology Groups
A topology group is a named set of VLANs that share a Layer 2 topology. Topology groups simplify configura-
tion and enhance scalability of Layer 2 protocols by allowing you to run a single instance of a Layer 2 protocol
on multiple VLANs. You can use topology groups with the following Layer 2 protocols:
• STP
• MRP
• VSRP
• 802.1w
MRP is the Metro Ring Protocol. If a break in the ring occurs, MRP heals the ring by changing states of some of
the ring interfaces.
• Blocking interface – The Blocking interface on the Master node has a dead timer. If the dead time expires
before the interface receives one of its ring’s RHPs, the interface changes state to Preforwarding. Once the
secondary interface changes state to Preforwarding:
- If the interface receives an RHP, the interface changes back to the Blocking state and resets the
dead timer.
- If the interface does not receive an RHP for its ring before the Preforwarding time expires, the inter-
face changes to the Forwarding state
• Forwarding interfaces – Each member interface remains in the Forwarding state
• If the link between shared interfaces breaks, the secondary interface on the master node changes to a
preforwarding state
• You can display the following MRP information:
- Topology group configuration information
- Ring configuration information and statistic
Layer 2 Functionality
Running the clear mac-address command without any parameters will remove all MAC address entries.
UDLD
UniDirectional Link Detection is a Layer 2 protocol to monitor the physical condition of any cables and detect
any unidirectional links as a result of a cable failure. If it is enabled on a switch or a router, the packets are
generated and processed by the device’s CPU. An interface could be disabled by UDLD.
Store-and-forward switching means that the switch copies each complete frame into the switch memory
buffers and computes a cyclic redundancy check (CRC) for errors. CRC is an error-checking method that uses
a mathematical formula, based on the number of bits (1s) in the frame, to determine whether the received
frame is corrupted. If a CRC error is found, the frame is discarded. If the frame is error free, the switch
forwards the frame out the appropriate interface port.
Cut-through switching means that the switch copies into its memory only the destination MAC address, which
is located in the first 6 bytes of the frame following the preamble. The switch looks up the destination MAC
address in its forwarding table, determines the outgoing interface port, and forwards the frame on to its
destination through the designated switch port. This method will not detect runt frames.
Another alternative is Fragment-free switching, which works like cut-through switching with the exception that
a switch in fragment-free mode stores the first 64 bytes of the frame before forwarding. This can be viewed as
a hybrid/compromise between store-and-forward switching and cut-through switching. The reason fragment-
free switching stores only the first 64 bytes of the frame is that most network errors and collisions occur
within the first 64 bytes of a frame.
VLAN Implementations
VLANs
Virtual Local Area Network
• A logical subgroup within a local area network that is created via software rather than manually moving
cables in the wiring closet
• Combines user stations and network devices into a single unit regardless of the physical LAN segment they
are attached to and allows traffic to flow more efficiently within populations of mutual interest
• Creates a broadcast domain
• Done through software configuration
• Implemented in port switching, hubs and LAN switches
• By default, all Brocade switch ports are members of VLAN 1
• VLANs reduce the time it takes to implement moves, adds and changes
• Layer 3 VLANs require that all members are in the same port-based VLAN
802.1Q Tagging
When you create a VLAN on a switch, you need to determine which of its ports participate in that VLAN. The
two types of membership are:
• Tagged - the switch adds an extra 4 bytes to the Ethernet frame called the 802.1Q header
- Allows multiple port based VLANs to span switches over a single physical link
• Untagged - the switch keeps track of this port as a member of the VLAN
The tag contains the TPI, which identifies the frame as a tagged. The value of the TPI is 8100, and also con-
tains the VLAN ID of the VLAN from which the packet is sent. The VLAN ID is determined by the VLAN on which
the packet is being forwarded. There are also 3 bits reserved for the priority (802.1p), and the field type is
8100.
CLI Command sequence to configure VLAN (14 in this example) and assign an IP address to a VE for VLAN 14:
NetIron(config)# vlan 14
NetIron(config-vlan-14)# untag ethernet 1/1 to 1/12
NetIron(config-vlan-14)# router-interface ve 1
NetIron(config-vlan-14)# exit
NetIron(config)# interface ve1
NetIron(config-vif-1)# ip address 192.123.22.1 255.255.255.0
By default, a private VLAN does not forward broadcast or unknown-unicast packets from outside sources into
the private VLAN. If needed, you can override this behavior for broadcast packets, unknown-unicast packets,
or both. You can configure a combination of the following types of private VLANs:
• Primary – The primary private VLAN ports are “promiscuous”. They can communicate with all the isolated
private VLAN ports and community private VLAN ports in the isolated and community VLANs that are
mapped to the promiscuous port.
• Isolated – Broadcasts and unknown unicasts received on isolated ports are sent only to the primary port.
They are not flooded to other ports in the isolated VLAN
• Community – Broadcasts and unknown unicasts received on community ports are sent to the primary port
and also are flooded to the other ports in the community VLAN
Each private VLAN must have a primary VLAN. The primary VLAN is the interface between the secured ports
and the rest of the network. The private VLAN can have any combination of community and isolated VLANs.
• You cannot configure isolated, community, or primary VLANs on 802.1Q tagged ports
• Normally, in any port-based VLAN, the device floods unknown unicast, unregistered multicast, and
broadcast packets in hardware, although selective packets, such as IGMP, may be sent to only to the CPU
for analysis, based on the IGMP snooping configuration.
• When Protocol or Subnet VLANs are enabled, or if Private VLAN mappings are enabled, the device will flood
unknown unicast, unregistered multicast, and broadcast packets in software
• You can configure private VLANs and dual-mode VLAN ports on the same device
- Dual-mode VLAN ports cannot be members of Private VLANs
Trunking
A trunk is a group of physical ports that act as one logical port. (trunking = link aggregation). In addition to
enabling load sharing of traffic, trunk groups provide redundant, alternate paths for traffic if any of the seg-
ments fail.
• Benefits of Trunking:
- Load-sharing
- Redundancy
• Two types of Trunking:
- Static Trunking:
o Manually configured aggregate links containing multiple ports
- Dynamic Trunking: (802.3ad Link Aggregation)
o Dynamically created and managed trunk groups using Link Aggregation Control Protocol
(LACP)
• Trunking can be established between Brocade Layer 2/3 switches, or between a switch and a server
LACP
Brocade software supports the IEEE 802.3ad standard for link aggregation. This standard describes the Link
Aggregation Control Protocol (LACP), a mechanism for allowing ports on both sides of a redundant link to form
a trunk link (aggregate link), without the need for manual configuration of the ports into trunk groups. When
you enable link aggregation on a group of Brocade ports, the Brocade ports can negotiate with the ports at
the remote ends of the links to establish trunk groups. To display link aggregation information, including the
key for all ports on which link aggregation is enabled, enter the following command at any level of the CLI:
FastIron#show link-aggregation
Operational ports are denoted with Ope
• If one network segment in the Spanning Tree Protocol becomes unreachable, or if a port cost changes, the
spanning-tree algorithm reconfigures the spanning-tree topology and re-establishes the link by activating
the standby path
Traffic Types
Unicast traffic describes point to point communication where there is just one sender, and one receiver. Uni-
cast transmission, in which a packet is sent from a single source to a specified destination, is still the predom-
inant form of transmission on LANs and within the Internet. IP networks support the Unicast transfer mode,
and most users are familiar with the standard Unicast applications (e.g. HTTP, SMTP, FTP and Telnet) which
employ the TCP transport protocol.
Multicast traffic describes communication which occurs between a sender and a grouping of recipients. Multi-
casting is the networking technique of delivering the same packet simultaneously to a group of clients. One
example of an application which may use multicast is a video server sending out networked TV channels.
Broadcast traffic describes communication where a piece of information is sent from one point to all other
points. In this case there is one sender and many receivers. An example of this is the ARP which uses a broad-
cast to send an address resolution query to all devices on a LAN segment in order to resolve an IP address to
a physical MAC address. A host will drop the ARP if it is not the target of the request. ARPs are used to resolve
unknown destination MAC addresses.
The command ip route 0.0.0.0 0.0.0.0 209.157.1.1 is a default route or “route of last resort”
because it is last place in the order of execution of the route table.
ip route 0.0.0.0 0.0.0.0 209.157.1.1 can appear in a route table because it is:
4 - Routing Concepts
RIP
• There are two basic steps to enabling IP RIP routing:
1. Enable RIP globally
2. Assign IP address/mask to each routed interface.
• RIP is enabled on a per interface basis. This way RIP updates are not flooded out of every port.
• RIPv2 supports MD5
During the early adoption phase of CIDR a real concern existed about the imminent depletion of Class B
networks. (Class C networks were not favored by companies due to its inherent host address constraints).
CIDR was seen as an interim solution until the adoption of IPv6 and its much larger address space. For
example, if an network administrator has a need for 300 IP addresses he/she would typically either need a
small portion of a class B network (and thereby waste much of that address space) or 2 Class C networks
(remember 254 hosts are possible in a standard Class C network). There is no middle ground with the
structured classful address scheme. CIDR provides a mechanism for aggregating multiple smaller networks
into a single larger network as in combining 2 Class C networks to provide 512 host addresses.
CIDR provides the mechanism to combine multiple networks into groups or blocks, which the router, in turn,
treats as one big network (route summarization or route aggregation). For instance instead of having to store
10 Class C network addresses (any multiple number of smaller classful networks) the router can store a single
CIDR-based network address.
CIDR implementations do not try to solve this problem. The eventual adoption of IPv6 is the answer to a much
larger addressing space. VLSM is used to set the boundary between host ID and network.
Subnetting
To begin we will use a fairly easy subnetting example for a traditional class C network – 192.168.1.100 -
255.255.255.192
• The chart below shows the decimal and binary values
Figure 9: Subnetting
• How many subnet bits are there?
- 2 (most significant) bits from the 4th octet (27 or 128 + 26 or 64 = 192)
• How many Host ID bits are left?
- 6 bits
• To determine the # of possible (sub) networks take the # of subnet bits to the power of 2
- In this case 22 = 4 possible (sub) networks
- Remember there is only 1 possible network with the default subnet mask of 255.255.255.0
• To determine the # of possible host addresses per subnetwork take the # of Host ID bits to the power of 2
and then subtract 2 for the network and broadcast addresses for the subnetwork
- In this 26 - 2 = 64. 64 - 2 = 62 possible host addresses per subnetwork
- It is important to note when subnetting each subnetwork created has an identical number of host
ID space created. In this example we can use up to 4 subnetworks and each subnetwork has a
possible of 62 unique host addresses that can be deployed.
Administrative Distance
Each route in a routing table has a metric called an administrative distance in the range of 0-255. Lower met-
rics mean better values or routes to be chosen. The lowest value administrative distance is the one that will
be stored in the routing table.
Routed Protocols
A list of some routed protocols:
• IPX
• IP
- SMTP
- SNMP
- Telnet
OSPF
Areas
Routers in OSPF are split into different groups called areas. The purpose is to reduce traffic and CPU load. The
area that is the most restrictive will use the least resources (CPU and memory). Areas may be organized in any
way that makes the most sense for a particular network. Areas get assigned numbers on the range of 1-
4,294,967,295. Enabling OSPF logging is good for troubleshooting.
Area Types:
• Area 0 - Backbone
- A required area to which all other areas must connect
• Ordinary or standard area (Normal or transit area)
- All routers in a OSPF area have the same topological database, but their routing tables will be
based on the router’s position in the area and will thus be unique to the router
• Stub area
- An area that does not accept external routes but will accept routes from within the same autono-
mous system
• Not So Stubby Area (NSSA)
- A stub area does not accept external summary routes from the backbone, but can advertise exter-
nal summary routes into the backbone
• Totally stubby area
- IThis area won’t accept routes from any other area. The ABR advertises 0.0.0.0/0 instead.
An OSPF AS can be divided into multiple Areas. The propagation of Types 1 and 2 Link State advertisements is
limited to the bounds of an area. The propagation of Types 1 and 2 Link State advertisements is limited to the
bounds of an area. An OSPF router can be a member of multiple areas. These routers are known as Area
Border Routers (ABRs). Each ABR maintains a separate topological database for each area the router is in.
Each topological database contains all of the LSAs within a given area. The routers within the same area have
identical topological databases. The ABR is responsible for forwarding routing information or changes
between its border areas. An Autonomous System Boundary Router (ASBR) is a router that is running multiple
protocols and serves as a gateway to routers outside an AS. The ASBR is able to import and translate different
protocols routes into OSPF through a process known as redistribution.
If there are two routing paths to choose from, paths that are internal to an OSPF routing domain are preferred
over external routes. External routes can be imported into the OSPF domain at two separate levels, one that
has Type 1 Metrics and the other Type 2 Metrics.
The use of Type 1 metrics assumes that in the path from the OSPF router to the destination, the internal OSPF
AS component (path to the ASBR advertising the AS-external-LSA) and external component are of the same
importance.
In Type 2 metrics, it is assumed that only the external component is more significant than the internal
component. The aggregate cost to these external destinations does not change when viewed from different
routers, since the internal costs are not important. But the cost of Intra-area and Inter-area destinations does
change depending on which router the cost is observed.
The aggregate cost to these external destinations does not change when viewed from different routers, since
the internal costs are not important. But the cost of Intra-area and Inter-area destinations does change
depending on which router the cost is observed.
Designated Routers
In order to minimize the amount of information exchange on a particular segment, OSPF elects one router to
be a designated router and one router to be a backup designated router on each multi access segment. The
idea behind this is that routers have a central point of contact for information exchange. Instead of each
router exchanging updates with every other router on the segment, every router will exchange the information
with the DR and BDR. The DR and BDR will relay the information to everybody else. The adjacency building
process takes effect after multiple stages have been fulfilled. Routers that become adjacent will have the
exact link state database.
Designated Router (DR) Election is done by selecting the neighboring router with the highest priority. The
router with the next largest priority is elected as the Backup DR (BDR). If the DR goes off line, the BDR auto-
matically becomes the DR. The router with the next highest priority becomes the new BDR. If two neighbors
share the same priority, the router with the highest router ID is designated as the DR.
1. The Router ID can be manually configured using the global command ip router-id x.x.x.x
2. If the Router ID is not manually configured, the IP address configured on the lowest numbered loopback
interface will be used as the Router ID
3. If there is no loopback interface, then the router ID is the lowest numbered IP address configured on the
device
When only one router on the network claims the DR role despite neighboring routers with higher priorities or
router IDs; this router remains the DR. This is also true for BDRs.
The DR and BDR election process is performed when one of the following events occurs:
1. An interface is in a waiting state and the wait time expires
2. An interface is in a waiting state and a hello packet is received that addresses the BDR
3. A change in the neighbor state occurs, such as, a neighbor state transitions from 2 or higher,
communication to a neighbor is lost, or a neighbor declares itself to be the DR or BDR for the first time
LSA Types
Link State Advertisements (LSAs) communicate the router's local routing topology to all other local routers in
the same OSPF area.
What is BGP?
• BGP is an inter-Autonomous System (AS) routing protocol between exactly two routers
• Defined in RFC 1771; performs loop-free inter-AS routing
• Once a TCP handshake is completed, BGP places a router in an established state
• BGP is a Path Vector Protocol to learn shortest route (path) to a network in another AS
• BGP rides on top of TCP - port 179
Multicast Routing
To enhance overall network performance, Brocade Layer 3 Switches use the RP to forward only the first
packet from a group source to the group’s receivers. After the first packet, the Layer 3 Switch calculates the
shortest path between the receiver and source (the Shortest Path Tree, or SPT) and uses the SPT for
subsequent packets from the source to the receiver. The Layer 3 Switch calculates a separate SPT for each
source-receiver pair.
By default, when a multicast packet is received on a PIM-capable router interface in a multi-path topology, the
interface checks its IP routing table to determine the shortest path back to the source. If the alternate paths
have the same cost, the first entry in the IP routing table is picked as the path back to the source. When
choosing the RPF, the router first checks the Multicast Routing Table. If the table is not available, it chooses
an RPF from the IP Routing Table.
ACL Overview
Brocade’s FastIron devices support rule-based ACLs (sometimes called hardware-based ACLs), where the
decisions to permit or deny packets are processed in hardware and all permitted packets are switched or
routed in hardware. In addition, Brocade’s FastIron devices support inbound ACLs only; outbound ACLs are
not supported. Rule-based ACLs program the ACL entries you assign to an interface into Content Addressable
Memory (CAM) space allocated for the ports. The ACLs are programmed into hardware at startup (or as new
ACLs are entered and bound to ports). Devices that use rule-based ACLs program the ACLs into the CAM
entries and use these entries to permit or deny packets in the hardware, without sending the packets to the
CPU for processing. Rule-based ACLs are supported on the following interface types:
• Gigabit Ethernet ports
• 10-Gigabit Ethernet ports
• Trunk groups
• Virtual routing interfaces
802.1p
• The 802.1p priority is also called the Class of Service (CoS), and uses a 3-bit field
• There is support for up to 8 priority levels (0-7) with 7 being the highest
• It is not preserved end-to-end
• Trust levels can be one of the following:
- Static MAC address
- Ingress port default priority
- ACL keyword
Marking
Marking is the process of changing the packet’s QoS information (the 802.1p and DSCP information in a
packet) for the next hop. For example, for traffic coming from a device that does not support DiffServ, you can
change the packet’s IP Precedence value into a DSCP value before forwarding the packet.
You can mark a packet’s Layer 2 CoS value, its Layer 3 DSCP value, or both values. The Layer 2 CoS or DSCP
value the device marks in the packet is the same value that results from mapping the packet’s QoS value into
a Layer 2 CoS or DSCP value.
Marking is optional and is disabled by default. Marking is performed using ACLs. When marking is not used,
the device still performs the mappings listed in “Classification” for scheduling the packet, but leaves the
packet’s QoS values unchanged when the device forwards the packet.
7 - Wireless Concepts
Wireless Protocols
802.11b Channels
802.11 divides each of its bands into channels, similar to how the radio and TV broadcast bands are allo-
cated, but with greater channel width and overlap. There are only 3 non-overlapping channels available in the
802.11b standard.These are Channels 1,6, and 11. For WiFi access points that are located near each other it
is recommended that they each use one of the above non-overlapping channels to minimize the effects of
interference. The following graphic is used with permission from the Creative Commons website:
ESSIDs
An extended service set ID (ESSID) identifies a WLAN with which clients can establish a connection. The Bro-
cade IronPoint Mobility Series provides multiple configuration options for managing the traffic, security, and
service requirements that are needed by the enterprise. You can configure:
• a VLAN that supports multiple access points per ESSID
• multiple ESSIDs per physical access point
• a VLAN for each ESSID to separate network traffic and can also specify that a VLAN be shared between
multiple ESSIDs
• an ESSID that supports just one person
• an ESSID for Remote AP, such as in a branch office, and that AP can also support ESSIDs for local traffic
Typically, a wireless LAN supports one beacon on a single BSSID, which can advertise the primary ESSID.
Clients can request to associate to that BSSID by requesting one of the ESSIDs. The Brocade IronPoint
Mobility Series allows you to customize a beacon per ESSID to support different access point settings, such as
base or supported transmit rates, different BSSIDs, different beacon intervals, and different DTIM periods.
This beacon customization allows service customization for each ESSID, as well as more flexibility in
supporting different clients and services.
802.11i
Brocade IronPoint Mobility Series supports both WPA2 and WPA protocols that have been presented by the Wi-
Fi Alliance as interim security standards that improve upon the known vulnerabilities of WEP until the release
of the 802.11i standard.
In WPA2, the WPA Message Integrity Code (MIC) algorithm is replaced by a message authentication code,
CCMP, that is considered fully secure and the RC4 cipher is replaced by the Advanced Encryption Standard
(AES), as described in CCMP-AES.
WPA includes the encryption protocol TKIP (see TKIP) and leverages existing 802.1X authentication, including
the dynamic key management facility.
If 802.1X authentication is not available (in a SOHO, for example), WPA2-Personal or WPA-Personal can be
implemented as alternatives and provide for manual key distribution between APs and clients.
802.1X Authentication
For enterprise wireless security to scale to hundreds or thousands of users, an authentication framework that
supports centralized user authentication must be used in addition to the encryption type specified by 802.11,
WEP, or by using WPA/WPA2 , which incorporates TKIP/CCMP-AES and 802.1X authentication.
The use of IEEE 802.1X offers an effective framework for authenticating and controlling user traffic to a pro-
tected network, as well as dynamically varying encryption keys if WPA/WPA2 is configured. 802.1X ties a pro-
tocol called EAP (Extensible Authentication Protocol) to both the wired and wireless LAN media and supports
multiple authentication methods, such as token cards, Kerberos, one-time passwords, certificates, and public
key authentication.
Extensible Authentication Protocol (EAP) is used to pass the authentication information between the
supplicant (the wireless station) and the authentication server (RADIUS, MS IAS, or other). The actual
authentication is defined and handled by the EAP type. The access point (and the controller in the
configuration) acts as the authenticator. The authenticator is a client of the RADIUS server that allows the
supplicant and the authentication server to communicate. The EAP type you choose, and whether you choose
to implement authentication in your organization, depends on the level of security you require.
• EAP-TLS
• EAP-PEAP
• EAP-TTLS
• Cisco LEAP
Network Monitoring
By default, access is allowed for all the methods listed above on all ports. Once you configure security for a
given access method based on VLAN ID, access to the device using that method is restricted to only the ports
within the specified VLAN.
Syslog Messages
A Brocade device’s software can write syslog messages to provide information at the following severity levels:
• Emergencies
• Alerts
• Critical
• Errors
• Warnings
• Notifications
• Informational
• Debugging
The device writes the messages to a local buffer. The buffer can hold up to 1000 entries. You also can specify
the IP address or host name of up to six Syslog servers. When you specify a Syslog server, the Brocade device
writes the messages both to the system log and to the Syslog server.
Using a Syslog server ensures that the messages remain available even after a system reload. The Brocade
device’s local Syslog buffer is cleared during a system reload or reboot, but the Syslog messages sent to the
Syslog server remain on the server.
By default, to view Syslog messages generated by a Brocade device, you need to display the Syslog buffer or
the log on a Syslog server used by the Brocade device. You can enable real-time display of Syslog messages
on the management console. When you enable this feature, the software displays a Syslog message on the
management console when the message is generated. However, to enable display of real-time Syslog mes-
sages in Telnet or SSH sessions, you also must enable display within the individual sessions.
To enable real-time display of Syslog messages, enter the following command at the global CONFIG level of
the CLI: FastIron(config)#logging console
The sampling rate is a fraction in the form 1/N, meaning that, on average, one out of every N packets will be
sampled. The sflow sample command at the global level or port level specifies N, the denominator of the
fraction. Thus a higher number for the denominator means a lower sampling rate since fewer packets are
sampled. Likewise, a lower number for the denominator means a higher sampling rate because more packets
are sampled. For example, if you change the denominator from 512 to 128, the sampling rate increases
because four times as many packets will be sampled. Brocade recommends that you do not change the
denominator to a value lower than the default. Sampling requires CPU resources. Using a low denominator for
the sampling rate can cause high CPU utilization.
Network Management
Console Port
The first step in configuring your Brocade device is to connect a console cable (typically shipped with your
device) to the serial port. You can then use the CLI (command line interface) to assign an IP address. After you
assign an address, you can access the system through Telnet, the Web management interface, or Iron View. In
order to attach a management station using the serial port, connect a PC or terminal to the serial port using a
straight through cable. You will need a serial interface on your computer or a DB9-to-USB converter to be able
to access the switch. The serial port has a male DB-9 connector. You will need a straight-through (female-to-
female) cable. You need to run a terminal emulation program such as Hyperterm or Procomm plus on the PC.
The session parameters should be set to Baud: 9600, Data Bits: 8, Parity: none, Stop Bits: 1 and Flow control:
none. For a modem connection, you must use a cross-over cable (typically a DB-9F-to-DB25F cable).
SNMP
SNMP is a set of protocols for managing complex networks. SNMP sends messages, called protocol data units
(PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves
in Management Information Bases (MIBs) and return this data to the SNMP requesters. SNMP management
access may be controlled, or restricted, by using a VLAN or ACLs.
Applying Security
SNMP and Web Management use community strings for authentication. In addition, you can restrict all access
methods to the same IP address using a single command. Some examples:
• FastIron(config)#telnet-client 209.157.22.39 to restrict Telnet
• FastIron(config)#ip ssh client 209.157.22.39 to restrict SSH
• FastIron(config)#web-client 209.157.22.39 to restrict Web Management
• FastIron(config)#snmp-client 209.157.22.39 to restrict SNMP
• FastIron(config)#all-client 209.157.22.39 to restrict all
To restrict access using ACLs the command is basically the same for all, except for the modifier before the
access group. An example for Telnet:
To allow Telnet access to the device, you must first issue the telnet server command. If you wish to allow
SSHv2 access, additionally, you must generate a Crypto Key. That is done with the crypto key generate
command. In addition, you must use AAA authentication to create a password to allow SSHv2 access.
You can tell which level of the command hierarchy that you are currently at by looking at the system prompt.
• User = >
• Privileged = #
• CONFIG = (config)#
Securing CLI
There are 5 ways to secure access to the Privileged EXEC and CONFIG levels of CLI:
• Establish a password for Telnet access to the CLI
• Establish passwords for management privilege levels
• Set up local user accounts
• Configure TACACS/TACACS+ security
• Configure RADIUS security
Maintenance Procedures
File Management
The flash memory is divided into two different storage areas. This allows you to have two different software
image versions stored in the flash memory. Secondary Flash is storage space for Upgrade Code:
• Put new code in the secondary flash
• Schedule a reload to boot on secondary flash during low traffic periods. Unsuccessful reloads will cause
the system to revert back to primary flash.
• When confidence is established in upgrade code, execute a copy flash flash primary to overwrite
old software image with upgrade image in primary flash
• This command will copy the system image in the primary flash to the TFTP server:
- FastIron# copy flash tftp 192.22.33.44 vm1r07501.bin primary
- Any failure might indicate the presence of something in the secondary flash
9 - Troubleshooting
Collisions
An increasing collision rate (number of packets output divided by the number of collisions) does not indicate a
problem: it is merely an indication of a higher offered load to the network. An example of this could be
because another station was added to the network. Excessive collisions indicate a problem. Common causes
are devices connected as full-duplex on a shared Ethernet, broken NICs, or simply too many stations on the
shared medium. The excessive collisions can be resolved by hardcoding speed and duplex.
Gathering Data
As previously mentioned, the show tech command is extremely useful in gather data for an escalated sup-
port call. The more information you can provide up front, the more likely a faster resolution is possible.
Blocking Ports
• Alternate port - a port that is not a root port, and can not be a designated port, because it is receiving a
superior BPDU from another switch
• Backup port - a port that is not a root port, and can not be a designated port, because it is receiving a
superior BPDU from its own switch
• Disabled port - a port not controlled by RSTP either because it is down, administratively down, or
administratively removed from RSTP
Different route sources are shown above, both static and dynamically learned. If a route to a destination
network is expected and is not shown, the router has not learned the route.
Once you agree to the Non-Disclosure terms, the timed exam will begin. This is a sample of how the questions
will look. In this example, you see a multiple-choice question.
This is a sample of the score sheet you will see at the end of the exam. You also see the breakdown of how
many questions there are in each section of the exam. A hard copy of this will be printed at the testing center.
It is vital that you obtain and save this hard copy as proof and validation.