BCNE Nutshell - Brocade Certified Network Engineer Exam Topics

BCNE 2012 in a Nutshell Study Guide for Exam 150-130
Brocade University Revision 0912
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, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, MLX, SAN Health, VCS, and VDX are registered trademarks, and AnyIO, Brocade One, CloudPlex, Effortless Networking, ICX, NET Health, OpenScript, and The Effortless Network are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be trademarks of 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 0912
Brocade Certified Network Engineer 2012 in a Nutshell First Edition
Introduction to BCNE 2012 in a Nutshell First Edition
Objective: The BCNE 2012 Nutshell guide is designed to help you prepare for the BCNE 2012 Certification, exam number 150-130. Audience: The BCNE 2012 Nutshell self-study guide is intended for those who have successfully completed the CNE 200 Brocade Certified Network Engineer Training course, and who wish to undertake self-study or review activities before taking the actual BCNE 2012 exam. The BCNE 2012 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 2012 guide: The BCNE 2012 guide summarizes the key topics on the BCNE 2012 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. To benefit from the BCNE 2012 guide, we strongly recommend you have successfully completed the CNE 200 Brocade Certified Network Engineer Training course. We hope you find this useful in your journey towards BCNE 2012 Certification, and we welcome your feedback by sending an email to jcannata@brocade.com.
Joe Cannata Certification Manager
2012 Brocade Communications
ii
Brocade Certified Network Engineer in a Nutshell Second Edition
Table of Contents
1 Layer1 Hardware Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Physical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Coaxial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Twisted Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fiber Optic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Form Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2
POE/POE+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Detection of PoE Power Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Brocade Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ICX 6430 and 6450 Product Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FastIron CX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FastIron SX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Brocade VDX 6730 Data Center Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ServerIron ADX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetIron CER Series. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NetIron MLXe Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 6 6 6 7 7
Hardware Platform Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Brocade IronStack features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Brocade IronStack topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
MCT Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Multi-Chassis Trunking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Layer 2 Switching and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Enabling or Disabling Layer 2 Switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bridge Protocol Data Units (BPDUs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fast Port Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Root Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BPDU Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IGMP Snooping Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1W Rapid Spanning Tree (RSTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Device Discovery Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1Q Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1q-in-q tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VLAN CPU Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13 13 15 15 15 15 15 15 17 18 19 21 21
Virtual Local Area Network Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Link Aggregation Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

LAG Formation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
iii
4 General Layer 2 and Layer 3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 End-to-End Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Private Networks (RFC 1918) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Designated Router (DR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neighbor Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OSPFs Four Level Routing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loopback Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link State Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 30 31 33 33 33
Mapping of IPv4 Multicast Group Addresses to Ethernet MAC Addresses . . . . . . . . . . . . . . . . . . . . . 34 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IPv6 Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Virtual Router Redundancy Protocol - Enhanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
General Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Defining a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Classless Inter-Domain Routing (CIDR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static IP route parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link State vs. Distance Vector (OSPF vs. RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42 43 43 44 44
Supported Layer 3 multicast routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6 Access Control List (ACL) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

ACL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Default ACL Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Standard Named ACL syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Policy-Based Routing (PBR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Configuring a PBR policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7 Quality of Service (QoS) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

QoS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QoS for Brocade Stackable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QoS Queueing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qos-tos trust and qos-tos mark Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recognizing Inbound Packet Priorities and Mapping to Internal Priority . . . . . . . . . . . . . . . . . . . . . . . QoS Options for IP ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1p Priority Override. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 50 50 51 51 52 52
iv
8 Network Security, Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Mirroring and Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNMP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 53 54 54
SNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Applying Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Setting the SSH port number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
TACACS+ versus TACACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Maintenance Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Loading and Saving Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
File Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Password Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Contacting Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
supportsave Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Determining STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

STP Port States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Viewing Optical Monitoring Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovering Disabled Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Packet Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1x Debug Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59 60 60 60 61 61
Taking the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
vi
List of Figures
SFP Side View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 MCT Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Root Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Fast Port Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Types of VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 VLAN Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 802.1Q Tagging (Packet Format) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 SAV Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 802.1 Q-in-Q Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 End-to-End Flow Example 1 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 End-to-End Flow Example 2 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 End-to-End Flow Example 3 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 End-to-End Flow Example 4 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 OSPF DR Election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 OSPF AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 VRRP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Multiple VRRP-E Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Supernetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Standard ACL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Policy-based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
vii
viii
List of Tables
Optics Comparison Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 IEEE 802.23a PoE and 802.23at PoE+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 FCX Series: Data Center vs. Campus Offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 RFC 1918 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Classful versus Classless Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Default Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Support SNMP Access Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 802.1x Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
ix
1 Layer1 Hardware Concepts

Upon completing this section you should be able to identify physical media and describe how to implement POE/POE+.
Physical Media
Physical media are the physical devices that transmit raw bits across a network. They include, but are not limited to the following:
Cabling Transceivers
Coaxial
The coaxial cable has one thin strand of copper in the middle of it, surrounded by quite a bit of insulation. This is surrounded by an additional meshwork of copper, which is, in turn, surrounded by more insulation. This cable is designed to carry an electrical signal.
Twisted Pair
The most common medium is called twisted pair. This comes in many varieties. On the high level, there's Unshielded Twisted Pair (UTP) and Shielded Twisted Pair (STP). STP is expensive, and the shielding can make it difficult to bend or shape. On the other hand, the additional shielding does a better job of preventing outside interference. UTP is the most common. STP and UTP come in different grades called categories. Some of the most common categories include category 3, category 5, category 5e, and category 6. These are most commonly abbreviated to CAT3, CAT5, CAT5e, and CAT6. CAT5 uses thicker cables inside than CAT3. It also has more twists per meter. Likewise with CAT5e and CAT6, the higher the number, the thicker the copper cables and the more twists per meter. Also, the higher the category, the greater the performance. CAT3 is only rated for 10 Mbps Ethernet, while CAT5e and CAT6 are required for Gigabit.
Fiber Optic
If you need lengths of cables much longer than 100 meters or your facility has a lot of EMI, use fiber. The major advantages with fiber are its attenuation limit (up to 70 km) and, because it uses light rather than electricity, it is invulnerable to EMI. It can achieve much greater speeds than its copper counterparts. The current maximum is 40 Gbps, but this is only limited by technology. The cables are made by combining fiber optic strands and insulating them. A laser light generates the signal. The more powerful the laser, the longer the attenuation limit. There are two varieties you need to be familiar with:
Multimode Fiber (MMF) - 1000 Mbps (SX) attenuation: 550 meters - 10 Gbps (SR) attenuation: 300 meters
Single-mode Fiber (SMF) - 1000 Mbps (LX) attenuation: 5 km - 1000 Mbps (LHA) attenuation: 70 km - 10 Gbps (LR) attenuation: 10 km - 10 Gbps (ZR) attenuation: 70 km
TABLE 1
Optics Comparison Chart

Supported Speeds Cable Type Used OM1/OM2/OM3 4, 2, 1 Gbps Singe-mode OM1/OM2/OM3 8, 4, 2 Gbps Single-mode OM1/OM2/OM3 10 Gbps Single-mode OM1/OM2/OM3 16 Gpbs Single-mode MPO 1x12 ribbon2 Distance at Max Speed1 380 m 10 km 30 km 150 m 10 km 25 km 300 m 10 km 100 m 10 km 50 km
Transceiver Type 4 Gbps SWL SFP 4 Gbps LWL SFP 4 Gbps ELWL SFP 8 Gbps SWL SFP 8 Gbps LWL SFP 8 Gbps ELWL SFP 10 Gbps SWL SFP+ 10 Gbps LWL SFP+ 16 Gbps SWL SFP+ 16 Gpbs LWL SFP+ 4x16 Gbps SWL QSFP
1. The distance shown in this chart represents the maximum distance, with high quality cabling, that is available at the maximum line speed of the transceiver. Distances can actually be increased beyond what is listed by reducing transmission speed. For a full list of supported distances, speeds, and cable types for any transceiver please visit our web site: http://www.brocade.com/ products/all/transceivers/product-details/transceiver-modules/features.page. 2. The 4x16 Gbps QSFP is currently only used on the DCX8510-4 and DCX 8510-8 Backbone switches for ICL links between chassis. These switches will be covered in greater detail in the next module.
Form Factors
The Small Form-factor Pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communication 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 (GbE), Fibre Channel (FC), and other communications standards. The standard covers SFP+ supporting data rates up to 10 Gbps (includes 8 Gbps Fibre Channel and 10 GbE). The SFP+ has a smaller form factor than a regular SFP. If copper is required 1000 Mbit TX SFPs could be used on non-combo ports.
Figure 1: SFP Side View
The XFP is a 10 GbE small form factor pluggable transceiver for use with optical fiber. XFPs are protocol independent and used in Ethernet devices. The following form factors are supported by Brocade switches and routers:
SFP SFP+ XFP
POE/POE+
When PoE is enabled on a port to which a power consuming device or PD is attached, by default, a Brocade PoE device will supply 15.4 watts of power at the RJ-45 jack, minus any power loss through the cables. A PoE+ device will supply either 15.4 or 30 watts of power (depending on the type of PD connected to the port), minus any power loss through the cables. For example, a PoE port with a default maximum power level of 15.4 watts will receive a maximum of 12.95 watts of power after 2.45 watts of power loss through the cable. To configure the maximum power level for a power consuming device, enter commands such as the following: Brocade#configure terminal Brocade(config)# interface ethernet 1/1 Brocade(config-if-e1000-1/1)# inline power power-limit 14000 These commands enable in-line power on interface ethernet 1 in slot 1 and set the PoE power level to 14,000 milliwatts (14 watts). Syntax: inline power power-limit <power level> The <power level> variable is the maximum power level in number of milliwatts. The following values are supported:
PoE: Enter a value from 1000 through 15,400. The default is 15,400. PoE+: Enter a value from 1000 through 30,000. The default is 30,000.
Table2 provides a side-by-side comparison of PoE nad PoE+.
TABLE 2
Feature
Cable requirement PSE current (A) PSE voltage (Vdc) PD current (A) PD voltage (Vdc)
IEEE 802.23a PoE and 802.23at PoE+

802.23af PoE
CAT3 or CAT5 0.35 44-57 0.35 37-57
802.23at PoE+
Type1: CAT3 Type2: CAT5/5e Type1: 0.35 Type2: 0.60 Type1: 44-57 Type2: 50-57 Type1: 0.35 Type2: 0.60 Type1: 37-57 Type2: 47-57
TABLE 2
Feature
IEEE 802.23a PoE and 802.23at PoE+

802.23af PoE
Class 0, 3: 12.95 Class 1: 3.84 Class 2: 6.49 Class 4: unused Optional 1-Event classification
802.23at PoE+
Type1, Class 0, 3: 12.95 Type1, Class 1: 3.84 Type1, Class 2: 6.49 Type2, Class 4: 25.5 Required Type1: 1-event classification Type2: 2-event classification and LLDP
Maximum PD wattage (W)
PD Classification Requirement
Note
The 802.3at 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 lower than 5, you cannot implement PoE+ without first upgrading your cables to CAT 5 UTP or better.
Detection of PoE Power Requirements

There are two ways for the powered devices to dynamically request the PoE power from the PSEproprietary protocols such as the Cisco Discovery Protocol (CDP) used by Cisco IP phones or the standard-based Link Layer Discovery Protocol (LLDP) used by variety of IP phones and access points. Brocade switches support both methods but recommend the latter because it does not limit organizations to a single class of powered devices and because LLDP provides a lot of additional features. Some powered devices such as Cisco IP phones use CDP to advertise their power requirements to PSEs such as Brocades PoE switches. Brocade PoE switches support such powered devices and can detect and process power requirements for these devices automatically. The Brocade FastIron PoE switches support IEEE 802.1AB LLDP and ANSI TIA 1057 LLDP-MED standards, enabling organizations to build open-convergence, advanced, multi-vendor networks that enable a variety of PDs to be plugged with Brocade switches. LLDP is a Layer 2 network discovery protocol described in the IEEE 802.1AB standard. This protocol enables a device to advertise its capabilities to and to discover other LLDPenabled devices in the same 802 LAN segments. LLDP Media Endpoint Devices (LLDP-MED) is the Layer 2 network discovery protocol extension to LLDP described in the ANSI/TIA-1057 standard. This protocol enables a PoE switch to configure and manage connected powered devices that need to send media streams across the network (for example, IP phones and security cameras). LLDP enables network discovery between network connectivity devices (such as switches), whereas LLDP-MED enables network discovery at the edge of the network, between network connectivity devices and media endpoint devices (such as IP phones).
2 Brocade Hardware Platforms

When you have completed this section you should be able to identify Brocade hardware platforms and describe how to implement the platforms and associated features.
Hardware Platforms
ICX 6430 and 6450 Product Overview
Offers enterprise-class stackable switching at an
entry-level price
Buy what you need now and easily scale as demand grows and new technologies emerge
Delivers feature/price value for applications

including:
Unified Communications (UC) and mobility, with 10 Gigabit Ethernet (GbE) and PoE/PoE+
Provides availability for low-cost switching: - Redundant uplink/stacking ports, hitless stacking failover, and configurable power redundancy
FastIron CX Series
Delivers enterprise-class Layer 2/3 switching in a compact,
stackable form factor
Combines chassis-like capabilities with an economical fixedport solution
Includes IPv4 and IPv6 Layer 3 capabilities as a standard feature on all models Provides non-stop availability with: - Hitless stacking failover - Hot insertion/removal of stacked units - Internal redundant hot-swappable power supplies and fans
TABLE 3
FCX Series: Data Center vs. Campus Offerings

Feature
PoE Stacking ports 10 GbE ports 10 GbE type GbE combo ports Airflow
Data Center
No No 4 SFP+ Optional Front-to-back (reversible)
Campus
Yes (PoE models) Yes 2 XFP built-in Side-to-back
FastIron SX Series
Price/performance value for campus aggregation and core switching Provides a scalable, secure, low-latency, and fault-tolerant infrastructure
for 1 GbE and 10 GbE enterprise deployments
High-performance architecture with: - Up to 128 x 10 GbE and 384 x 1 GbE ports Supports IPv4/IPv6- capable Layer 2/3 switching and routing Highly available design with: - Multi-Chassis Trunking (MCT) - Redundant management modules (with hitless failover) - Switch fabrics - Stateful OSPF redundancy; graceful BGP and OSFP restarts; and hitless In-Service Software Upgrades
(ISSU)
Brocade VDX 6730 Data Center Switches

32- and 76-port models with Ports on Demand
(PoD)
Non-blocking, cut-through architecture, wirespeed
600 ns port-to-port latency; 1.8 s across port

groups
Ethernet storage connectivity for FCoE, iSCSI, and

NAS storage
Multihop FCoE and iSCSI Data Center Bridging (DCB) support 10 Gbps and 1 Gbps supported on every LAN port; 2,4, and 8 Gbps on FC ports Direct-attached copper SFP and SFP optical connectivity options Reversible front-to-back airflow
ServerIron ADX Series

Enables high-speed application delivery by leveraging a purpose-built
architecture designed with high core density and embedded application accelerators
Maximizes investment protection with on-demand capacity for fixed

platforms and fully interchangeable modules for chassis platforms
Accelerates service creation and application deployment via the open

and flexible Brocade OpenScript engine
Simplifies management of highly virtualized and cloud-optimized environments through Brocade

Application Resource Broker and extensible SOAP/XML APIs
Eases the transition to IPv6 with full performance and feature parity between IPv6 and IPv4 as well as
scalable, standards-based translation technology
6
NetIron CER Series

Compact 1U IP/MPLS router purpose-built for high-performance
Ethernet edge routing applications
Scalable routing and MPLS for advanced business and residential

triple-play services
Scalable compact edge router designed to support a full Internet

routing table
Powered by the field-proven Brocade Multi-Service IronWare OS that

also runs on Brocade MLXe Series routers
Complete suite of IPv4/IPv6 unicast and multicast routing with fast convergence times Advanced QoS features to enforce strict SLAs at the edge of the network
NetIron MLXe Series

Scalable multiservice IP/MPLS Carrier Ethernet routers in 4-, 8-, 16-,
and 32-slot options
Fully distributed, non-blocking architecture with up to 15.36 Tbps

fabric capacity
Wire-speed ports in a single router: 1536 x 1 GbE or 256 x 10 GbE or 32 x 100 GbE Wire-speed IPv4, IPv6, and MPLS forwarding performance with 1
million IPv4 routes in hardware
High-availability design with: - Redundant management modules, switch fabrics; hitless

failover; hitless software upgrades; and non-stop routing
Hardware Platform Features

Brocade IronStack features
A stack is a group of devices that are connected so that they operate as a single chassis. IronStack features include the following:
Management by a single IP address Support for up to eight units per stack. ICX 6430 supports only up to four units in the stack Flexible stacking ports Linear and ring stack topology support Secure-setup utility to make stack setup easy and secure Active Controller, Standby Controller, and member units in a stack Active Controller management of entire stack Active Controller download of software images to all stack units Standby Controller for stack redundancy
Active Controller maintenance of information database for all stack units Packet switching in hardware between ports on stack units All protocols operate on an IronStack in the same way as on a chassis system
Brocade IronStack topologies

Brocade IronStack technology supports linear and ring stack topologies. Although Brocade stackable units may be connected in a simple linear topology, Brocade recommends a ring topology because it offers the best redundancy and the most resilient operation.
MCT Terminology
Figure 2MCT Components
MCT peer switches: A pair of switches connected as peers through the ICL. The LAG interface is spread
across two MCT peer switches and it acts as the single logical endpoint to the MCT client.
MCT client: The MCT client is the device that connects with MCT peer switches through an IEEE 802.3ad
link. It can be a switch or an endpoint server host in the single-level MCT topology or another pair of MCT switches in a multi-tier MCT topology.
MCT Inter-Chassis Link (ICL): A single-port or multi-port GbE or 10 GbE interface between the two MCT
peer switches. This link is typically a standard IEEE 802.3ad Link Aggregation interface. ICL ports should not be untagged members of any VLAN. The ICL is a tagged Layer 2 link, which carries packets for multiple VLANs. MCT VLANs are the VLANs on which MCT clients are operating. On the Brocade NetIron XMR or Brocade MLX series, non-MCT VLANs can co-exist with MCT VLANs on the ICL. However, on the Brocade NetIron CES and Brocade NetIron CER, only MCT VLANs are carried over ICL.
MCT Cluster Communication Protocol (CCP): A Brocade proprietary protocol that provides reliable, point-topoint transport to synchronize information between peers. CCP comprises two main components: CCP peer management and CCP client management. CCP peer management deals with establishing, and maintaining TCP transport session between peers, while CCP client management provides event-based, reliable packet transport to CCP peers.
MCT Cluster Client Edge Port (CCEP): A physical port on one of the MCT peer switches that is a member of
the LAG interface to the MCT client. To have a running MCT instance, at least one Link Aggregation Interface is needed with a member port on each peer switch.
MCT Cluster Edge Port (CEP): A port on MCT peer switches that is neither a Cluster Client Edge Port nor an
ICL port.
MCT VLANs: VLANs on which MCT clients are operating. These VLANs are explicitly configured in the MCT
configuration by the user. NOTE: For MCT VLANs, MAC learning is disabled on ICL ports, while MAC learning is enabled on ICL port for non-MCT VLANs.
MCT Session VLANs: The VLAN used by the cluster for control operations. CCP protocol runs over this
VLAN. The interface can be a single link or LAG port. If it is LAG port, it should be the primary port of the LAG. Note: MCT session VLAN's subnet will not be distributed in routing protocols using redistribute commands
RBridge ID: RBridge ID is a value assigned to MCT nodes and clients to uniquely identify them, and helps
in associating Source MAC with a MCT node.
MDUP: MAC Database Update Protocol CL: Cluster Local MACs CCL: Cluster Client Local MACs CR: Cluster Remote MACs CCR: Cluster Client Remote MACs CCRR: Cluster Client RBridge Reachability MDB: Mac Data Base. The MDB can have multiple MAC entries for the same address FDB: Forwarding MAC Database. The FDM will have the best MAC only installed
Multi-Chassis Trunking
The following FastIron features are not supported with MCT:
LACP on ICL MSTP, VSRP, RIP, OSPF, IS-IS, and BGP IPv6, VRRP-E (IPv6), and VRRPv3 GRE on the ICL VE interfaces DAI on the CCEPs Host security features (port MAC security, multi-port authentication, 802.1X, DAI, DHCP snooping) on CCEPs Multi-port ARP on ICL or CCEPs Web authentication on MCT VLANs
10
3 Layer 2 Switching and Protocols

When you have completed reviewing this section be sure you can do the following:
Describe Layer 2 protocols Identify Layer 2 functionality Identify different VLAN implementations Describe the different link aggregation (LAG) implementations
Enabling or Disabling Layer 2 Switching

By default, Brocade devices supports routing over Layer 2 switching. You can enable Layer 2 switching globally or on individual port using the no route-only command. The no route-only and route-only commands prompts you to change the route-only behavior. You must enter y if you want to proceed or n if you do not. The prompt is displayed as shown in the following examples of the no route-only and route-only commands. To enable Layer 2 switching globally, enter the following. Brocade(config)# no route-only This will change the route-only behavior at the global level. Are you sure? (enter y or n): y Global route-only committed.
To enable Layer 2 switching only on a specific interface, go to the Interface configuration level for that interface, and
add the no route-only command. The following command shows how to enable Layer 2 switching on port 3/2. Brocade(config)# interface ethernet 3/2 Brocade(config-if-e10000-3/2)# no route-only To globally disable Layer 2 switching on a Brocade device and return to the default (route-only) condition, enter commands such as the following: Brocade(config)# route-only This will change the route-only behavior at the global level. Are you sure? (enter y or n): y Global no route-only committed.
Layer 2 Protocols
A protocol is a set of rules that governs the communications between computers on a network These rules include guidelines that regulate the following characteristics of a network:
Access method Allowed physical topologies Transport medium Speed of data transfer
11
Spanning Tree Protocol

The Spanning Tree Protocol (STP) eliminates Layer 2 loops in networks, by selectively blocking some ports and allowing other ports to forward traffic, based on global (bridge) and local (port) parameters you can configure. STP related features, such as RSTP and PVST, extend the operation of standard STP, enabling you to fine-tune standard STP and avoid some of its limitations. You can enable or disable STP on a global basis (for the entire device), a port-based VLAN basis (for the individual Layer 2 broadcast domain), or an individual port basis. Brocade Layer 2 Switches and Layer 3 Switches support standard STP as described in the IEEE 802.1D specification. STP is enabled by default on Layer 2 Switches but disabled by default on Layer 3 Switches.
The Root Bridge

When STP begins, a selection process is made to determine which redundant paths to keep forwarding user traffic and which ones to shut down. BPDUs are sent. Root bridge is used as a reference point by all other switches in the network for eliminating loops, and determining when an alternate path is required due to a topology change. It has (numerically) the lowest bridge ID (BID). By default, each bridge has a configurable priority number, called the bridge priority, and a unique MAC address. The BID is a combination of the bridge priority and the MAC address. The lowest numerical BID has the highest priority for root bridge selection. All other switches in the network calculate path cost to the root bridge to determine which ports will be used, and which will be blocked to eliminate loops. The switch with the lowest Bridge ID (BID) becomes the root bridge. All Brocade switches have the default bridge priority 32768. If that is the case, the lowest MAC address is used. In Figure3, Switch#1 is the Root Bridge because its Bridge Priority is the lowest; if all three switches have the same Bridge Priority, then Switch#3 will be the Root Bridge because its MAC address is the lowest. After the election, each switch determines the shortest path to the root bridge. The switch port with the best path to the root bridge is the Root Port (RP). The path cost is based on the bandwidth. The higher the bandwidth, the lower the cost. When multiple switches share a connection that is not a root port, one of them becomes the Designated Port (DP), the other ports are blocked.
Bridge ID = Bridge Priority + MAC address
12
The switch with the lowest BID wins and becomes the Root Bridge. If Bridge Priorities are the same, the switch with the lowest MAC address wins and becomes the Root Bridge.
Root Bridge (Priority:0) Switch#1
00:0E:80:0A:F0:06
DP
DP
RP Switch#3
00:0E:80:01:90:06
RP DP Switch#2
00:0E:80:01:F0:06
(Priority:200)
Figure 3: Root Bridge
(Priority:100)
Bridge Protocol Data Units (BPDUs)

BPDUs are data messages that are exchanged across switches within a LAN and VLAN to form and maintain a Spanning Tree Protocol topology (Spanning Tree is on by default on switches, but off by default on routers). The BPDU data messages are exchanged across bridges to detect loops in a network topology. The loops are then removed by blocking selected bridge ports and placing redundant switch ports in a backup or blocked state. BPDUs contain information about switches, ports, addresses, priorities, and costs. The following are BPDU types:
Configuration BPDU
Generated only by the root bridge and sent to non-root bridges, it provides a method of providing election information across the L2 domains and controlls reconvergence after a link has been broken.
Topology Change Notification (TCN) BPDU

Topology Change Notification BPDU (TCN BPDU): TCNs are generated by non-root bridges and sent towards the root bridge. Their purpose is to indicate that one of their data forwarding ports has been broken and a new forwarding path needs to be provided.
Fast Port Span

When STP is running on a device, message forwarding is delayed during the spanning tree recalculation period following a topology change. The STP forward delay parameter specifies the period of time a bridge waits before forwarding data packets. The forward delay controls the listening and learning periods of STP reconvergence. You can configure the forward delay to a value from 430 seconds. The default is 15 seconds. Therefore, using the standard forward delay, convergence requires at least 30 seconds (15 seconds for listening and an additional 15 seconds for learning) when the default value is used.
13
The Fast Port Span feature allows certain ports to enter the forwarding state in four seconds. It allows faster convergence on ports that are attached to end stations and do not cause Layer 2 forwarding loops. Because the end stations cannot cause forwarding loops, they can safely go through the STP state changes (blocking to listening to learning to forwarding) more quickly than is allowed by the standard STP convergence time. The purpose of Fast Port and Fast Uplink are to remedy the latency of 802.1d failover at critical network locations. The 802.1d timers could be changed to cut down the 30 second convergence, however, this could lead to network instability.
Figure 4: Fast Port Span
Fast Port Span performs the convergence on these ports in four seconds (two seconds for listening and two seconds for learning). In addition, Fast Port Span enhances overall network performance in the following ways:
Reduces the number of STP topology change notifications on the network Eliminates unnecessary MAC cache aging that can be caused by topology change notifications When STP sends a topology change notification, devices that receive the notification use the value of the
STP forward delay to quickly age out their MAC caches
If a port matches any of the following criteria, it port is ineligible for Fast Port Span and uses normal STP
instead:
The port is 802.1Q tagged (refer to 802.1Q Tagging on page18) The port is a member of a trunk group The port has learned more than one active MAC address An STP configuration BPDU has been received on the port, thus indicating the presence of another bridge on the port
14
Root Guard
The standard STP (802.1D), RSTP (802.1W) or 802.1S does not provide any way for a network administrator to securely enforce the topology of a switched layer 2 network. The forwarding topology of a switched network is calculated based on the root bridge position, along with other parameters. This means any switch can be the root bridge in a network as long as it has the lowest bridge ID. The administrator cannot enforce the position of the root bridge. A better forwarding topology comes with the requirement to place the root bridge at a specific predetermined location. Root Guard can be used to predetermine a root bridge location and prevent rogue or unwanted switches from becoming the root bridge.
BPDU Guard
In an STP environment, switches, end stations, and other Layer 2 devices use Bridge Protocol Data Units (BPDUs) to exchange information that STP will use to determine the best path for data flow. The BPDU guard, an enhancement to STP, removes a node that reflects BPDUs back in the network. It enforces the STP domain borders and keeps the active topology predictable by not allowing any network devices behind a BPDU guard-enabled port to participate in STP.
ACL Overview
Brocade 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. All denied packets are also dropped in hardware. In addition, FastIron FWS devices support inbound ACLs only. Outbound ACLs are not supported on those devices. FSX, FCX, and ICX devices support both inbound and outbound ACLs.
IGMP Snooping Overview

When a device processes a multicast packet, by default, it broadcasts the packets to all ports except the incoming port of a VLAN. Packets are flooded by hardware without going to the CPU. This behavior causes some clients to receive unwanted traffic. IGMP snooping provides multicast containment by forwarding traffic to only the ports that have IGMP receivers for a specific multicast group (destination address). A device maintains the IGMP group membership information by processing the IGMP reports and leave messages, so traffic can be forwarded to ports receiving IGMP reports.
802.1W Rapid Spanning Tree (RSTP)

The 802.1W feature provides rapid traffic reconvergence for point-to-point links within a few milliseconds (0 500 milliseconds), following the failure of a bridge or bridge port. This reconvergence occurs more rapidly than the reconvergence provided by the 802.1D Spanning Tree Protocol (STP)) or by RSTP Draft 3.
Device Discovery Protocols

Link Layer Discovery Protocol (LLDP) is a layer 2 network discovery protocol supported only on Ethernet interfaces. It allows a station to advertise its capabilities to and learn the capabilities of other stations in the Ethernet LAN. Examples include:
System name
15
System description System capabilities Management address

The information distributed by LLDP is stored by the receiving device in a standard Management Information Base (MIB). The information can be viewed by a Network Management System or from the CLI. The Foundry Discovery Protocol (FDP) enables Brocade devices to advertise themselves to other Brocade devices on the network. When you enable FDP on a Brocade device, the device periodically advertises information including the following:
Hostname (device ID) Product platform and capability Software version VLAN and Layer 3 protocol address information for the port sending the update (IP, IPX, and AppleTalk Layer 3 information is supported)
Virtual Local Area Network Implementations

A Virtual LAN (VLAN) is a logical subgroup within a local area network (LAN) that is created through software rather than manually moving cables in the wiring closet. It 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. VLANs have the following characteristics:
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.
16
There are three types of VLANs:
Port-based
A group of ports which constitutes a Layer 2 broadcast domain. This allows you to divide your user traffic into logical network segments.
MAC-base
The MAC-based VLAN feature controls network access, by authenticating a host source MAC address, and mapping the incoming packet source MAC to a VLAN
Protocol-based
A subset of ports within a Layer 2 port-based VLAN organized according to the Layer 3 protocol type.
L3 protocolbased VLAN for IPX L2 portbased VLAN 20 L3 protocolbased VLAN for IPv6
L3 protocolbased VLAN for IPv4
Figure 5: Types of VLANs
Private VLANs
Platform support:
FastIron X Series devices running software release 02.4.00 and later FGS and FLS devices running software release FGS-STK and FLS-STK devices running software release 05.0.00 and later FWS devices running software release 04.3.00 and later
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: Broadcast and unknown unicast traffic received on isolated ports are sent only to the primary
port. They are not flooded to other ports in the isolated VLAN
17
Community: Broadcast and unknown unicast traffic received on community ports are sent to the primary
port and also are flooded to the other ports in the community VLAN
Private VLAN Port-Based VLAN Forwarding among Private VLAN ports
Figure 6 Private 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, or private VLAN mappings are enabled, the device floods unknown
unicast, unregistered multicast, and broadcast packets in software
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
802.1Q tagging is an IEEE standard that allows a networking device to add information to a Layer 2 frame in order to identify its VLAN membership. A port can belong to only one port-based VLAN, unless 802.1Q tagging is applied to the port.
Note
VLAN Without 802.1Q tagging is where the Ports require dedicated uplinks for each VLAN between switches. There is no question where broadcast traffic went from port-to-port. 802.1Q tagging allows the port to add a four-byte field, which contains the VLAN ID, to each frame sent on the port. Port-based VLANs can also be configured to span multiple devices by tagging the ports within the VLAN. The tag enables each device that receives the frame to determine to which VLAN the frame belongs. 802.1Q tagging applies only to Layer 2 VLANs.
18
Figure 7: VLAN Tagging
The tag contains the TPID, which identifies the frame as a tagged. The value of the TPID is 8100, and also contains 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.
Figure 8: 802.1Q Tagging (Packet Format)
802.1q-in-q tagging
802.1Q-in-Q tagging enables you to configure 802.1Q tag types on a group of ports, such as LAG
19
ports, thereby enabling the creation of two identical 802.1Q tags (802.1Q-in-Q tagging) on a single device. This feature improves Super Aggregated VLANs (SAV) interoperability between Brocade devices and other vendor devices that support the 802.1Q tag types, but are not very flexible with the tag types they accept.
Figure 9 SAV Configuration Example
As shown in Figure9, the ports to customer interfaces are untagged, whereas the uplink ports to the provider cloud are tagged, because multiple client VLANs share the uplink to the provider cloud. In this example, the Brocade device treats the customers private VLAN ID and 8100 tag type as normal payload, and adds the 9100 tag type to the packet when the packet is sent to the uplink and forwarded along the provider cloud. As long as the switches in the providers network support the 9100 tag type, the data gets switched along the network. However, devices that do not support the 9100 tag type may not properly handle the packets.
Figure 10 802.1 Q-in-Q Configuration Example
In Figure10, the untagged ports (to customer interfaces) accept frames that have any 802.1Q tag other than the configured tag-type 9100. These packets are considered untagged on this incoming port and are retagged when they are sent out of the uplink towards the provider. The 802.1Q tag-type on the uplink port is 8100, so the Brocade device will switch the frames to the uplink device with an additional 8100 tag, thereby supporting devices that only support this method of VLAN tagging.
20
VLAN CPU Protection

VLAN CPU protection is recommended for the VLANs which are intended for pure Layer 2 usage. This feature protects the CPU from the flooding of unknown-unicast, multicast, or broadcast L2 packets on that VLAN. When using routing protocols, such as OSPF, on a specific VLAN you need to disable VLAN CPU protection for it to work. This feature is intended for Layer 2 applications and not for Layer 3 routing applications.
Virtual Interfaces
The Brocade device sends Layer 3 traffic at Layer 2 within a protocol-based VLAN. However, Layer 3 traffic from one protocol-based VLAN to another must be routed. If you want the device to be able to send Layer 3 traffic from one protocol-based VLAN to another on the same device, you must configure a virtual routing interface on each protocol-based VLAN, then configure routing parameters on the virtual routing interfaces. A virtual routing interface is a logical routing interface that the Brocade device uses to route Layer 3 protocol traffic between protocol-based VLANs. It is a logical port on which you can configure Layer 3 routing parameters. A virtual interface can have multiple IP addresses. For example, to enable a Brocade device to route IP traffic from one IP protocol VLAN to another, you must configure a virtual routing interface on each IP protocol VLAN, then configure the appropriate IP routing parameters on each of the virtual routing interfaces. Hosts in a VLAN can use the IP address of the virtual interface as their default gateway.
Link Aggregation Implementations

Trunking is another term for Link Aggregation. Link Aggregation allows an administrator to combine multiple Ethernet links into a larger logical trunk known as a Link Aggregation Group (LAG). The switch treats the trunk as a single logical link. The physical links must all be the same speed and duplex setting and must connect to the same adjacent switch including stackable switches1. LAG requirements may vary for different platforms, such as the number of links in the LAG, specific port boundaries2. Always check what is supported at both ends The rules for LAGs are heavily dependent on the hardware type and code version in use. All interface parameters in a LAG must match, including:
Port tag type (tagged/untagged) Configured port speed3 and duplex QoS priority
1. Link Aggregation Groups are also referred to as: Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Port Trunking, Link Bundling, EtherChannel, Multi-Link Trunking (MLT), DMLT, SMLT, DSMLT, R-SMLT, NIC bonding, Network Fault Tolerance (NFT), and Fast EtherChannel. 2. Multi-Chassis Trunking is a technology that allows multiple switches to appear as a single logical switch connecting to another switch using a standard LAG. Since the technology is an enhancement to the standard LAG protocol, a single MCT-unaware server or switch using a standard LAG trunk can connect to two MCT-aware switches--and the traffic is dynamically load balanced. For more information on this topic, please refer to the FastIron Configuration Guide for the particular platform. 3. Each port in the LAG operates at the speed of the slowest link. For example, if one LAG is created with 2 ports and one is running at 10 Gbps and the other is running at 1 Gbps; each link operates at 1 Gbps. This behavior occurs if the ports are configured to auto and negotiate to different speeds.
21
Brocade switches support the use of static and dynamic LAGs on the same device4, but can use only one type of LAG for any given port.
Figure 11: Link Aggregation
In addition to traffic load sharing, trunk groups provide redundant, alternate paths for traffic if any of the segments fail.
Benefits of trunking: - Load-sharing - Redundancy

There are two types of trunking:
Static trunking - Manually configured aggregate links containing multiple ports Dynamic Trunking: (802.3ad Link Aggregation) - 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.
LAG Formation Rules

The LAG formation rules are mentioned below:
You cannot configure a port concurrently as a member of a static, dynamic, or keep-alive LAG. Any number or combination of ports between 1 and 32 within the same chassis can be used to configure
a LAG. The maximum number of LAG ports is checked when adding ports to a LAG.
All ports configured in a LAG must be of equal bandwidth. For example all 10 Gbps ports. All ports configured in a LAG must be configured with the same port attributes. LAG formation rules are checked when a static or dynamic LAG is deployed. A LAG must have its primary port selected before it can be deployed.
4. Multiple LAGs can be created on a switch with some of them being static LAGs and some of them being dynamic LAGs. A single port can only be part of one LAG type. 22
All ports configured in a LAG must be configured in the same VLAN. All ports must have the same PBR configuration before deployment. During deployment, the configuration
on the primary port is replicated to all ports. On undeployment, each port inherits the same PBR configuration.
All static LAG ports must have the same LACP BPDU forwarding configuration. VLAN and inner-VLAN translation
Configuring Keys for Ports with Link Aggregation Enabled

Syntax: [no] link-aggregate configure [system-priority <num>] | [port-priority <num>] | [key <num>]
The system-priority <num> parameter specifies the Brocade device link aggregation priority. A higher value indicates a lower priority. You can specify a priority from 0 through 65535. The default is 1. The port-priority <num> parameter specifies an individual port priority within the port group. A higher value indicates a lower priority. You can specify a priority from 0 through 65535. The default is 1. The key <num> parameter identifies the group of ports that are eligible to be aggregated into a trunk group. The software automatically assigns a key to each group of ports. The software assigns the keys in ascending numerical order, beginning with 0. You can change a port group key to a value from 10000 through 65535.
Configuring Load Sharing Type

Individual LAGs can be configured to perform load sharing over the ports in the LAG using either a hash based or per packet method, as shown in the following.
Command and Output of show lag

Brocade(config)# show lag Total number of LAGs: 1 Total number of deployed LAGs: 1 Total number of s created:1 (127 available) LACP System Priority / ID: 1 / 0000.0001.c000 LACP Long timeout: 90, default: 90 LACP Short timeout: 3, default: 3 === LAG "lag1" ID 124 (static Deployed) === LAG Configuration: Ports: ethe 1/2 to 1/3 Port Count: 2 Primary Port: 1/3 Type: hash-based Deployment: ID 124, Active Primary 1/2 Port Link L2 State Dupl Speed Tag Priori MAC Name 1/2 Up Forward Full 10G 124 No level0 0000.0001.c002 1/3 Up Forward Full 10G 124 No level0 0000.0001.c002
23
4 General Layer 2 and Layer 3 Concepts

When you have completed reviewing this section be sure you can describe general routing and switching concepts.
Address Resolution Protocol

Address Resolution Protocol (ARP) is used to associate a Layer 3 (Network layer) address, such as an IP address, with a Layer 2 (Data Link layer) address (MAC address). ARP is used to resolve MAC addresses for hosts on the local subnet; for remote destinations, the source host sends out ARP requests asking for the MAC address of the default gateway. If a node matches the requested IP, it sends back its MAC address. Other nodes discard the ARP request.
Figure 12: ARP
If an address you want to communicate with is not in the ARP table then the Network Layer sends an ARP broadcast. The ARP broadcast is addressed to the broadcast address of the network. When the Data Link Layer receives the ARP broadcast packet, it uses the workstation MAC address as the source address, but it uses a broadcast MAC address as the destination. The broadcast MAC address sets all 48 of the bits in the address to 1. In hexadecimal, it looks like this: FF:FF:FF:FF:FF:FF.
End-to-End Packet Flow

The following example details how a packet is routed from Host A to Host B on another subnet or network address. 1. If the destination hosts network number was the same as the source hosts, then the destination host would be considered local and on the same subnet. This is determined by taking Host A taking its own IP address and subnet mask and determining its own network address and then doing the same operation with the destination IP and sourcess subnet mask and comparing the results. If they are the same
24
then the destination Host B would be considered local; Otherwise the packets will be forwarded to the default gateway in order to be sent to a remote host. In this example the destination Host Bs Network ID of 192.168.3.0 is different from the source Host As Network ID of 192.168.1.0 and therefore the packets will need to be routed to the destination Host B. 2. The source Host A must check its own Local Route Table for its default gateway (this is the general behavior unless a special route has been defined). The default gateway IP is the IP of the routing interface for that subnet. In this example it is 192.168.1.1 which is the IP of Router 1 Interface E1. Since this is an Ethernet LAN, Host A will need to encapsulate the frame in order to sent it out to the routing interface of E1 and to do so it needs to know the MAC address of the routing interface. If it is not in its local cache an ARP broadcast will need to be initiated in order to send the encapsulated frames to the routing interface (E1 on Router1).
Figure 13: End-to-End Flow Example 1 of 4
3. In Figure14, the default gateways MAC address is not in Host As cache. Host A initiates a local ARP broadcast request attempting to resolve the IP address to a physical MAC address. 4. Router 1 responds with a unicast ARP response to Host A with its MAC address of 22. 5. Host A creates/encapsulates an Ethernet frame with its own MAC 11 as the source and a destination MAC address of 22. Notice the destination IP still remains 192.168.3.20 and the frame can be sent on the wire.
25
6. Once Interface E1 on R1 receives the Ethernet frame it looks at the destination MAC address of the frame to check it if matches his own in order to determine if he is the recipient of the frame. In this case R1 interface E1 is the default gateway of Host A and therefore the intended recipient. R1 checks the frames Type field and notices 0x800 which indicates that there is an IP packet in the data portion of the Ethernet frame. R1 then proceeds to decapsulate the Ethernet frame in order to analyze the destination IP of the packet. 7. The Router must then consult its routing table to determine what to do with the packet. In general terms it looks to identify network routes in its table which would include the destination IP address as a host address on that network. Note: If there are several viable routes to the destination network it will chose the route with the longest subnet mask match. How routing tables become populated and an in depth look of how they are evaluated are beyond the scope of this example and class. After viewing R1s routing table it finds that the network address of 192.168.3.0 is the destination network where these packets need to be routed. It also notices the next hop IP of 192.168.2.2 which represents the next stop for the packets on its way to the 192.168.3.0 network and this can be reached through local interface E2. 8. In order for R1 to do the frame encapsulation process it needs to know the MAC address of the 192.168.2.2 interface. So it must check its local ARP cache and again if the MAC address is not found, it must send an ARP broadcast to request the MAC address. In this case it will be already present. Therefore the frame encapsulation process can continue. Notice that the source and destination IP addresses stay the same but the source MAC becomes 33 and the destination MAC becomes 44. Also note that it also will decrement the Time to Live field of the packet (in the IP header) by 1. Now the packet is sent on the wire.
26
9. Once Interface E1 on R2 receives the Ethernet frame, it looks at the destination MAC address of the frame to check it if matches his own in order to determine if he is the recipient of the frame. In this case R2 interface E1 is the next hop IP of R1 and therefore the intended recipient. R2 checks the frames Type field and notices 0x800 which indicates that there is an IP packet in the data portion of the Ethernet Frame. R2 then proceeds to decapsulate the Ethernet frame in order to analyze the destination IP of the packet. 10. R2 must then consult its routing table to determine what to do with the packet. After consulting its routing table it finds that the Network Address of 192.168.3.0 is the destination network where these packets need to be forwarded and this is a directly connected route in its table through interface E2. 11. In order for R2 to do the frame encapsulation process it needs to know the MAC address of the final destination host B with the IP 192.168.3.20. So it must check its local ARP cache and again if the MAC address is not found it must be a ARP broadcast to resolve the IP Address to a matching physical MAC address. In this case it will be already present and therefore the frame encapsulation process can continue. Notice that the source MAC is 55 and the destination MAC becomes 66. Now the frame(s) are sent on the wire. 12. Once Host B receives the frame, it recognizes its own MAC address. It then decapsulates the frame and notices that itself is the intended host with an IP of 192.168.3.20.
27
Figure 16: End-to-End Flow Example 4 of 4 Note
Throughout the packet flow the source and destination IP addresses stay the same, but the source and destination MAC changes. Also, the Time to Live field of the packet (in the IP header) is decremented by 1.
Private Networks (RFC 1918)

The Internet Engineering Task Force (IETF) publishes a set of standards called Request for Comments (RFC). These detail all kinds of different standards for the Internet. Among them is RFC 1918: Address Allocation for Private Internets. This addresses (no pun intended) the problem by allowing private networks to be created. You can still use TCP/IP, but you don't have to worry about registering addresses with an Internet registry. RFC 1918 specifies a network range in each of the three addressable classes (A, B, and C).
TABLE 4
Class
A B C
RFC 1918
Address
10.0.0.0/8 172.16.0.0/12 192.168.0./16
Range
10.0.0.0 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255
28
Open Shortest Path First

Open Shortest Path First (OSPF) is a link state routing Interior Gateway Protocol (IGP) for medium to large networks. Its cost metric is based on aggregated link cost. OSPF supports Classless Inter-Domain Routing (CIDR) and Variable Length Subnet Masks (VLSM). It is hierarchy-based using OSPF areas. Its network topology is built using Link State Advertisements (LSAs) received from other routers. OSPF has the following characteristics:
Decreases routing overhead Speeds up convergence Confines network instability to a single area of the network Communicates between routers using multicast advertisements Has no periodic updates
Designated Router (DR)

OSPF has a Designated Router which receives all the updates on a given segment. The Backup Designated Router is the second-in-command. This router receives the updates, too, but does not send them back out. When a router needs to update other routers, it sends the update to the Designated Router and the Backup Designated Router. The Designated Router sends the update to all of the other routers on its segment. When the Designated Router becomes unavailable, the Backup Designated Router instantly becomes the Designated Router, and an election is held to see who becomes the next Backup Designated Router. This way, each router need not be aware of all of the OSPF routers involved. It needs only to communicate its updates (and receive updates) from a single source. This minimizes traffic, and allows the OSPF design to expand nicely, as needed.
Figure 17: OSPF DR Election
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 offline, the BDR automatically 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.
29
1. The Router ID can be manually configured using the global ip router-id x.x.x.x command. 2. If the Router ID is not manually configured, the IP address configured on the lowest numbered loopback interface is 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
Neighbor Adjacency
OSPF defines a neighbor as a router that has an interface with an IP address in the same broadcast domain. The following parameters must match to become neighbors:
Subnet mask Hello/Dead intervals Area-ID Authentication password Stub area flag
Neighbor States
The neighbors on a given router will go through six states on their way to fully becoming synchronized with its routing table. The first three states are referred to as the neighboring process. These are the states neighbors go through in order to establish themselves as neighbors.
Down: The router has not sent a Hello packet, nor has it received one Init: A Hello packet has been sent to a neighbor, but no Hello packet has been received from that neighbor 2 Way: The router has sent a Hello packet to a neighbor, and has received a Hello packet back; the reply
will contain your router's Router ID inside; now, your router knows that the neighbor knows your router as well The next three states are referred to as the adjacency process. To establish adjacency means that your OSPF database is synchronized with your neighbor (there's currently no further information to share).
Ex-Start: This is short for Exchange Start; this is where the DR/BDR election takes place; routers are
sending Hello packets to determine who will become the DR and BDR
Exchange: Now the neighbors are finally talking; in this state, your router is sharing everything it knows,
and the neighbor router is sharing everything it knows
Full: We're adjacent! The neighbors have no more information to share; they've shared it all
30
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 uses the least resources (CPU and memory). Areas may be organized in any way that makes the most sense for a particular network. Areas are assigned numbers on the range of 1 through 4,294,967,295. Enabling OSPF logging is good for troubleshooting.
New York
San Jose
Los Angeles
Figure 18: OSPF Areas
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 are based on
the routers position in the area and are unique to the router
Stub area - An area that does not accept external routes but accepts routes from within the same autonomous
system
Not So Stubby Area (NSSA) - A stub area does not accept external summary routes from the backbone, but can advertise external
summary routes into the backbone
Totally stubby area - This area wont accept routes from any other area. The Area Border Router (ABR) advertises 0.0.0.0/0
instead
31
OSPF Autonomous System (AS) is the entire OSPF routing domain. 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. 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.
Figure 19: OSPF AS
OSPF Virtual Links

OSPF virtual links allow administrators to work around the requirement that all other areas must connect directly to the backbone. If the new area cannot connect directly to the backbone area, two ABRs are set up to bridge the gap and recreate the connectivity. The configuration commands pass area information between ABRs in the intermediary area. From the viewpoint of OSPF, each ABR has a direct connection to three areas (Area 0, the outlying area, and the area traversed). This scenario may emerge in a variety of cases:
Merge or failure isolates an area from Area 0 The area is critical to the company, and an extra link has been configured for redundancy
Requirement to create a virtual link:
Both routers must share a common area

32
The transit area cannot be a stub area One of the ABRs must be connected to Area 0
Virtual links are meant to be a temporary solution to connectivity problems and are not recommended as a design strategy
OSPFs Four Level Routing Hierarchy

Level 1 - Intra-area routing Level 2 - Inter-area routing Level 3 - External Type 1 Metrics Level 4 - External Type 2 Metrics
If there are two routing paths to choose from then 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.
Loopback Interfaces
You should configure a loopback interface on the router that is participating in OSPF. The loopback address does not belong to a particular interface. If you have a router participating in OSPF with several physical links, the router will have to be identified by the IP address of one of those links (the Router ID). This means that If that link goes down the router would have to start the neighboring process all over again using a new Router ID. If you use a loopback address, the Router ID does not change. Also, it is not contingent on whether one of the physical interfaces is up or down. The loopback is the IP address of the device, not an individual interface. Common practice would be to choose a unique /30 network (some even use a /32 network), assign an IP address to a loopback interface, and assign that interface to be a member of a particular area.
Link State Advertisement

Link State Advertisement (LSA) is an OSPF data packet that communicates the router's local routing topology to all other local routers in the same OSPF area. OSPF Link State process: 1. Link State Advertisements exchanged between routers 2. Topology Database is built 3. Router runs Shortest Path First (SPF) algorithm to calculate the best path 4. SPF tree is generated
33
5. Best routes are selected from SPF tree, and entered into the routing table, based on cost to individual networks LSA Types (by type code)
Type 1: Router LSA - generated by each router for each area to which it belongs. Type 2: Network LSA - generated by DRs describing the set of routers attached to a particular network. Type 3: Network Summary LSA - generated by ABRs describing inter-area routes. Type 4: ASBR Summary LSA - generated by ABRs advertising the IP address of the ASBR. Type 5: External LSA - generated by the ASBR describing networks external to the Autonomous System (AS). converts Type 7 LSAs into type 5 before flooding them into the backbone area (area 0).
Type 7: NSSA External LSA - generated by ASBR and only flooded within the Not-So-Stubby area. The ABR
By default, the device sends summary LSAs (LSA type 3) into stub areas. You can further reduce the number of link state advertisements (LSA) sent into a stub area by configuring the device to stop sending summary LSAs (type 3 LSAs) into the area. You can disable the summary LSAs when you are configuring the stub area or later after you have configured the area. To disable summary LSAs for a stub area, enter commands such as the following. Brocade(config-ospf-router)# area 40 stub 99 no-summary
Mapping of IPv4 Multicast Group Addresses to Ethernet MAC Addresses

The IANA owns a block of Ethernet MAC addresses for Multicast usage that are in the range 0100.5e00.0000 through 0100.5e7F.FFFF. For a given IPv4 Multicast group, there is a simple way of obtaining the appropriate Ethernet Destination MAC address that must be used in Layer 2 encapsulation. This is defined in RFC 1112, as follows: An IP host group address is mapped to an Ethernet multicast address by placing the low-order 23-bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Because there are 28 significant bits in an IP host group address, more than one host group address may map to the same Ethernet multicast address.
34
IPv6 Address Types

As with IPv4 addresses, you can assign multiple IPv6 addresses to a switch interface. Table 5 presents the three major types of IPv6 addresses that you can assign to a switch interface.
TABLE 5
Address Type
Unicast
IPv6 Address Types

Description
An address for a single interface. A packet sent to a unicast address is delivered to the interface identified by the address.
Address Structure
Depends on the type of the unicast address:

Multicast An address for a set of interfaces belonging to different nodes. Sending a packet to a multicast address results in the delivery of the packet to all interfaces in the set. An address for a set of interfaces belonging to different nodes. Sending a packet to an anycast address results in the delivery of the packet to the closest interface identified by the address.
Aggregatable global addressAn address equivalent to a global or public IPv4 address. The address structure is as follows: a fixed prefix of 2000::/3 (001), a 45-bit global routing prefix, a 16-bit subnet ID, and a 64-bit interface ID. Site-local addressAn address used within a site or intranet. (This address is similar to a private IPv4 address.) A site consists of multiple network links. The address structure is as follows: a fixed prefix of FEC0::/10 (1111 1110 11), a 16-bit subnet ID, and a 64-bit interface ID. Link-local addressAn address used between directly connected nodes on a single network link. The address structure is as follows: a fixed prefix of FE80::/10 (1111 1110 10) and a 64-bit interface ID. IPv4-compatible addressAn address used in IPv6 transition mechanisms that tunnel IPv6 packets dynamically over IPv4 infrastructures. The address embeds an IPv4 address in the low-order 32 bits and the high-order 96 bits are zeros. The address structure is as follows: 0:0:0:0:0:0:A.B.C.D. Loopback addressAn address (0:0:0:0:0:0:0:1 or ::1) that a switch can use to send an IPv6 packet to itself. You cannot assign a loopback address to a physical interface. Unspecified addressAn address (0:0:0:0:0:0:0:0 or ::) that a node can use until you configure an IPv6 address for it.
A multicast address has a fixed prefix of FF00::/8 (1111 1111). The next 4 bits define the address as a permanent or temporary address. The next 4 bits define the scope of the address (node, link, site, organization, global). An anycast address looks similar to a unicast address, because it is allocated from the unicast address space. If you assign a unicast address to multiple interfaces, it is an anycast address. An interface assigned an anycast address must be configured to recognize the address as an anycast address. An anycast address can be assigned to a switch only. An anycast address must not be used as the source address of an IPv6 packet.
Anycast
IPv6 Address Representation

IPv6 addresses are presented in a very unique way and very different than its predecessor, IPv4. Considering the overall length of the address it was imperative to find ways to express the address in a more concise manner whenever possible. When expressing IPv6 addresses verbally, it is proper to call out each colon (:). For example, the address 2001::49:17 would be read as:
Two thousand and one, colon, colon, forty-nine, colon, seventeen

Two options are defined to shorten IPv6 address expressions
35
1. Leading zeros in each 16-bit field are optional Standard Expression 2001:0000:130F:0000:0000:00C0:876A: 12EB Shortened Expression 2001:0:130F:0:0:00C0:876A:12EB
2. The double colon ( :: ) represent two or more consecutive fields of zeros
The double colon may be used only once in an address Double Colon Use 2001:0:130F::C0:876A:12EB 2001::1 ::1 :: 2001::130F::C0:876A:2EB
Shortened Expression 2001:0:130F:0:0:C0:876A:12EB 2001:0:0:0:0:0:0:1 0:0:0:0:0:0:0:1 0:0:0:0:0:0:0:0 2001:0:130F:0:0:C0:876A:12EB
Example of Incorrect Use

Note
For a default route, enter 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx (use ::/0 for the <mask-bits> if you specify the address in CIDR format).
Virtual Router Redundancy Protocol - Enhanced

Virtual Router Redundancy Protocol - Enhanced (VRRP-E) is Brocades enhanced version of VRRP that overcomes limitations in the standard protocol. All routers are backups for a given Virtual Router ID (VRID). The router with the highest priority (a configurable value) becomes master. VRRP-E uses UDP to send Hello messages in IP multicast messages. To prevent an immediate transition from backup to re-instated master, enable the slow start timer. VRRP-E requires only that the VRID be in the same subnet as an interface configured on the VRIDs interface. Multiple VRIDs can exist on a single interface. VRRP-E supports the use of more than one track port.
36
The Virtual IP (VIP) is a unique IP address on the same subnet as the VRRP-E routers. There is no concept of an owner IP address, as a real interface IP is not used. The elected master hosts the VIP address and answers ICMP requests. VRRP-E uses UDP (port 8888) to send multicast hello messages to 224.0.0.2, the multicast address. The VIP address can be reached by the use of ping. All switches participating in VRRP-E with the same VRID group must have the same Virtual IP address.
Figure 20 VRRP-E
The following command sequence sets up and activates VRRP-E. It follows the configuration rules which state the following:
The router interfaces in a VRID must be in the same IP subnet The Hello/Dead intervals must be set to the same values on all the VRRP-E enabled devices The Virtual IP (VIP) address must be configured the same on routers belonging to the same VRRP-E
backup group Router_A(config)# router VRRPExtended Router_A(config)# interface e1 Router_A(config-if-1)# ip address 192.53.5.2 Router_A(config-if-1)# ip VRRPExtended vrid 1 Router_A(config-if-1-vrid-1)# backup priority 110 track-priority 20 Router_A(config-if-1-vrid-1)# ip-address 192.53.5.1 <-- Virtual IP Router_A(config-if-1-vrid-1)# track-port e15 e16 Router_A(config-if-1-vrid-1)# activate Router_B(config)# router VRRPExtended Router_B(config)# interface e1 Router_B(config-if-1)# ip address 192.53.5.3 Router_B(config-if-1)# ip VRRPExtended vrid 1 Router_B(config-if-1-vrid-1)# backup priority 80 Router_B(config-if-1-vrid-1)# ip-address 192.53.5.1 Router_B(config-if-1-vrid-1)# activate
<-- Virtual IP
37
Figure 21: Multiple VRRP-E Groups
In Figure21, Router A and Router B use VRRP-E to load share as well as provide redundancy to the hosts. The load sharing is accomplished by creating two VRRP-E groups. Each group has its own virtual IP address. Half of the clients point to virtual IP address of VRID 1 as their default gateway and the other half point to virtual IP address of VRID 2 as their default gateway. This enables some of the outbound Internet traffic to go through Router A and the rest to go through Router B. VRRP-E reduces the priority of a VRRP-E interface by the amount of a tracked interface's priority if the tracked interface's link goes down. For example, if the VRRP-E interface's priority is 200 and a tracked interface with track priority 20 goes down, the software changes the VRRP-E interface's priority to 180. If another tracked interface goes down, the software reduces the VRIDs priority again, by the amount of the tracked interface's track priority.
38
Router A is the master for VRID 1 (backup priority = 110) and Router B is the backup for VRID 1 (backup priority = 100). RouterA and RouterB both track the uplinks to the Internet. If an uplink failure occurs on Router A, its backup priority is decremented by 20 (track priority = 20), so that all traffic destined to the Internet is sent through Router B instead. Similarly, RouterB is the master for VRID 2 (backup priority = 110) and RouterA is the backup for VRID 2 (backup priority = 100). Router A and Router B are both tracking the uplinks to the Internet. If an uplink failure occurs on RouterB, its backup priority is decremented by 20 (track priority = 20), so that all traffic destined to the internet is sent through RouterA instead.
39
5 Routing Concepts
When you have completed reviewing this section be sure you can do the following:
Describe general routing concepts Describe how to implement the OSPF protocol Describe multicast routing
General Routing Concepts

Routing is needed when data needs to reach a remote network that is not directly connected to the local router.
Routing Tables
A router uses its routing table to determine the next hop for the packet's destination and forwards the packet appropriately5. The next router repeats this process using its own routing table until the packet reaches its destination. At each stage, the IP address in the packet header is used to determine the next hop. If either a destination network or a default route are not in the routing table, the packet is dropped.
Defining a Default Route

A default route is a routing table entry used to route packets when an explicit route to a destination network is not in the routing table. It is the network route used by a router when no other known route exists for a given IP packet's destination address. It is last in the order of execution of the routing table. Brocade supports two types of default routes:
Explicit default route - IPv4 default route 0.0.0.0 0.0.0.0 or 0.0.0.0/0 - Can be a static route or learned dynamically by a routing protocol like OSPF. OSPF uses a command
called default-information originate to send the default route to other OSPF routers
5. When an IP packet is to be forwarded, a router uses its routing table to determine the next hop for the packet's destination (based on the destination IP address in the IP packet header), and forwards the packet appropriately. The next router then repeats this process using its own routing table, and so on until the packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to determine the next hop; no additional protocol headers are required. 40
Candidate default route - A Candidate default network is used when a default route is not statically configured or propagated by
a routing protocol
The default route has precedence over the default network
Figure 22: Default Routes
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. The ip route 0.0.0.0 0.0.0.0 209.157.1.1 can appear in a route table because it is:
Manually configured on the router Can be sent to other routers by a routing protocol like OSPF The command ip default-network 209.157.1.0 is a default network route and is there in case
a default route is not present because it has neither been manually configured nor passed by routing protocol like OSPF
41
Static Routes
A static route is a route manually created by a network administrator to instruct a router how to reach a particular remote network. A local next hop IP address or a local outgoing interface number can be used in the static route configuration. Each router in the path needs a next hop route.
Figure 23Static Routes
Router_A(config)# Router_B(config)# Router_B(config)# Router_C(config)#
ip ip ip ip
route route route route
172.16.1.0/24 10.1.2.1 172.16.1.0/24 10.1.1.1 192.168.1.0/24 10.1.2.2 192.168.1.0/24 10.1.1.2
Classless Inter-Domain Routing (CIDR)

Classless Inter-Domain Routing (CIDR) is used to aggregate multiple classful network addresses into a single routable address called supernetting. CIDR was created to help resolve the following problems:
Because of the Internet evolution there was a real concern that in the IPv4 address space, especially
Class B addresses would be exhausted
Running out of capacity in the global routing tables Eventual exhaustion of the entire 32-bit IP address space
The motivation behind CIDR implementations was allocating IP address space more efficiently. CIDR is used instead of handing out full classful addresses (A or B) to organizations that were not fully utilizing the entire address space. The convention states that you can represent the number of network bits in a subnet mask, by adding a number after a forward slash (/) character. For example, 10.0.0.0, in classful networking, has a subnet mask of 255.0.0.0 (Class A). This means that the network portion has eight bits. Using CIDR, we would represent this same network like this: 10.0.0.0/8. Notice that I used the network address (10.0.0.0), followed it by a forward slash (/), and then followed that by the number of network bits in the subnet mask (8, in this example).
TABLE 6
Classful versus Classless Networks From 1.0.0.0 128.0.0.0 192.0.0.0 1.0.0.0. To 127.255.255.255 191.255.255.255 223.255.255.255 223.255.255.255 Mask or Prefix 255.0.0.0 255.255.0.0 255.255.255.0 /1-32 (Address bits 1-32)
Type Class A Class B Class C CIDR
42
CIDR provides the mechanism to combine multiple networks into groups or blocks, which the router treats as one big network (route summarization or route aggregation). For example, instead of having to store 10 Class C network addresses (any multiple number of smaller classful networks) the router can store a single CIDRbased network address. CIDR is still bound by the base network address space. That is, a traditional Class C network address can use all 24 network mask bits for supernetting (as long as the bits are contiguous) but a Class A address can only use the first 8 bits of the prefix for supernetting. If more than the first 8 bits are used this would be subnetting, rather than supernetting. To supernet: 1. Use the lowest network address for the supernet address 2. Find the lowest order matching bit between the addresses
The lowest order matching bit will be the last bit in the supernet prefix
Figure 24 Supernetting
Administrative Distance
Each route in a routing table has a metric called an administrative distance in the range of 0-255. Lower metrics mean better values or routes are chosen. The lowest value administrative distance is the one that is stored in the routing table.
TABLE 7
Protocol Directly connected Static External BGP (eBGP) OSPF RIP Internal BGP (iBGP)
Default Administrative Distances

Cost 0 1 20 110 120 200
Static IP route parameters

When you configure a static IP route, you must specify the following parameters:
The IP address and network mask for the route destination network.
43
The route path, which can be one of the following: - The IP address of a next-hop gateway - An Ethernet port - A virtual interface (a routing interface used by VLANs for routing Layer 3 protocol traffic among one
another)
A null interface. The Layer 3 Switch drops traffic forwarded to the null interface.
Link State vs. Distance Vector (OSPF vs. RIP)

Metric: OSPF is a link state protocol. This means that each router participating in the protocol is
responsible for reporting the state of each of its links. OSPF uses a link's cost to make its routing decisions. The cost is determined by dividing the speed of the link (in Mbps) into 100, by default (this method can be customized; more on this later). Just as in consumer pricing, the lower the cost, the more desirable the route. Distance vector, as you may recall from Chapter 9, means that the protocol bases its routing decisions on distance. If you have two or more routes to the same destination, you choose the one with the shortest distance. RIP is the most common example of this type of protocol. For its distance, it uses hop count, or the number of routers a packet must traverse to get to its destination.
Route Advertisements: RIP advertises its entire routing table: OSPF sends only updates. Route Advertisement Recipients: RIP broadcasts its entire routing table to any address within its
configured broadcast domains. It doesn't matter if you're a router or a workstation. You will receive a copy of the router's routing table. In OSPF, it sends updates multicast. A multicast packet is a packet that originates from a single host, but is delivered to multiple destinations.
It might help to think of broadcast versus multicast in the same way you understand an Ethernet hub
versus a switch. An IP broadcast, in some ways, is like a hub. With a hub, if a frame comes in one port, it gets duplicated and sent out every other port. There's no intelligence to it. It just gets duplicated. An IP multicast is more like a switch with VLANs configured. An incoming frame will be duplicated, but only sent out the port of the frame's destination, or, if that is unknown, the ports that are participating in the VLAN. In this case, OSPF sends its updates to all OSPF routers. Two special multicast addresses to remember are:
224.0.0.2 - all routers 224.0.0.5 - all OSPF routers
Updates: RIP broadcasts its entire routing table every 30 seconds. OSPF sends updates only when
changes occur.
Authentication: MD5 hash authentication is available in RIP, but only in version 2. OSPF also provides
MD5 hash authentication.
Variable Length Subnet Masks (VLSM): RIP version 2 supports this. OSPF supports it, too.
IGMP Snooping
The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships. PIM snooping must be used only in topologies where multiple PIM sparse routers connect through a device. PIM snooping does not work on a PIM dense mode router which does not send join messages, and traffic to PIM dense ports is stopped. A PIM snooping-enabled device displays a warning if it receives PIM dense join or prune messages.
44
IGMP protocols provide a method for clients and a device to exchange messages, and let the device build a database indicating which port wants what traffic. The protocols do not specify forwarding methods. They require IGMP snooping or multicast protocols such as PIM or DVMRP to handle packet forwarding. PIM or DVMRP can route multicast packets within and outside a VLAN, while IGMP snooping can switch packets only within a VLAN.
Supported Layer 3 multicast routing protocols

Brocade Layer 3 switches support the multicast routing protocol DVMRP and PIM along with the Internet Group Membership Protocol (IGMP). PIM and DVMRP are broadcast and pruning multicast protocol that deliver IP multicast datagrams. The protocol employs reverse path lookup check and pruning to allow source-specific multicast delivery trees to reach all group members. DVMRP and PIM build a different multicast tree for each source and destination host groups.
Note
DVMRP and PIM can concurrently operate on different ports of a Brocade Layer 3 switch.
45
6 Access Control List (ACL) Concepts

After reviewing this section you should be able to describe Access Control List (ACL) concepts.
ACL Overview
Brocades 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, Brocades 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
ACLs filter traffic by permitting or denying incoming frames from passing through interfaces that have the ACL applied to them. Each ACL is a collection of permit and deny statements (rules) that apply to frames. A switch compares the fields in the frame against any ACLs applied to the interface to verify that the frame has the required permissions to be received or forwarded. The switch sequentially compares the frame against each rule in the ACL and either forwards or drops it. The order of the rules in an ACL is critical because the first rule that matches the traffic stops further processing of the frame.
Default ACL Action

The default action when no ACLs are configured on a device is to permit all traffic. However, once you configure an ACL and apply it to a port, the default action for that port is to deny all traffic that is not explicitly permitted on the port:
If you want to tightly control access, configure ACLs consisting of permit entries for the access you want to
permit. The ACLs implicitly deny all other access.
If you want to secure access in environments with many users, you might want to configure ACLs that
consist of explicit deny entries, then add an entry to permit all access to the end of each ACL. The software permits packets that are not denied by the deny entries.
Note
The ACL takes effect immediately after being applied to an interface.
Access Control Lists

ACLs filter traffic by permitting or denying incoming frames from passing through interfaces that have the ACL applied to them. Each ACL is a collection of permit and deny statements (rules) that apply to frames. The switch sequentially compares the frame against each rule in the ACL and either forwards or drops it. A switch also compares the fields in the frame against any ACLs applied to the interface to verify that the frame has the
46
required permissions to be received or forwarded. The order of the rules in an ACL is critical because the first rule that matches the traffic stops further processing of the frame. Since ACLs are executed sequentially, from top to bottom, place the deny statements before the permit statements. There is an implicit deny statement at the end of each ACL. All traffic not specifically permitted is automatically denied.There are two types of ACLs:
Standard (ACL 1-99) - Permits or Denies packets based on source IP address - Configured with the access-list command Extended (ACL 100-199) - Permits or denies packets based on source and destination IP addresses, TCP/UDP ports, or protocol
number or name
Configured with the access-list command The following are editing options for extended ACLs:
Insert a new ACL entry within an existing ACL Delete an entry from an ACL Replace an existing ACL entry Add, insert, replace, or delete a remark per ACL entry
If you can, try to apply ACLs Inbound rather than Outbound. Inbound ACL behavior states that the first instance of a TCP or UDP packet is handled by the ASIC and not the CPU. Enabling access list logging impacts the CPU. Example Standard ACL
Figure 25: Standard ACL Example
Router_A(config)# ip dns server-address 209.157.22.30 Router_A(config)# access-list 1 deny host 209.157.22.26 log Router_A(config)# access-list 1 deny host 209.157.29.12 log Router_A(config)# access-list 1 deny host IPHost1 log Router_A(config)# access-list 1 permit any Router_A(config)# interface ethernet 1/1 Router_A(config-if-1/1)# ip access-group 1 in Example Explanation Q: Why do the 2nd, 3rd, and 4th access list 1 lines have no subnet mask?
47
A: With the host argument, there is an implicit /32 bit mask.
The host argument is used in the syntax as a substitute for the subnet mask. DNS server configuration allows a host name to be specified and it is looked up on the servers listed in the command, you can list up to four servers. The DNS servers are searched in the order listed in the configuration. Syslog entries: The first time an ACL entry permits or denies a packet, the software immediately generates a Syslog entry and SNMP trap. The software also starts a five-minute timer. The timer keeps track of all packets explicitly denied by the ACL entries. After five minutes, the software generates a single Syslog entry for each ACL entry that has denied a packet. The message indicates the number of packets denied by the ACL entry during the previous five minutes.
Standard Named ACL syntax

Syntax: [no] ip access-list standard <ACL-name> | <ACL-num> Syntax: deny | permit <source-ip> | <hostname> <wildcard> [log] or Syntax: deny | permit <source-ip>/<mask-bits> | <hostname> [log] Syntax: deny | permit host <source-ip> | <hostname> [log] Syntax: deny | permit any [log] Syntax: [no] ip access-group <ACL-name> in | out The <ACL-name> parameter is the access list name. You can specify a string of up to 256 alphanumeric characters. You can use blanks in the ACL name if you enclose the name in quotation marks (for example, ACL for Net1). The <ACL-num> parameter allows you to specify an ACL number if you prefer. If you specify a number, you can specify from 1 99 for standard ACLs. The deny | permit parameter indicates whether packets that match a policy in the access list are denied (dropped) or permitted (forwarded). The <source-ip> parameter specifies the source IP address. Alternatively, you can specify the host name. The <wildcard> parameter specifies the mask value to compare against the host address specified by the <source-ip> parameter. The host <source-ip> | <hostname> parameter lets you specify a host IP address or name. When you use this parameter, you do not need to specify the mask. A mask of all zeros (0.0.0.0) is implied. The any parameter configures the policy to match on all host addresses. The log argument configures the device to generate Syslog entries and SNMP traps for inbound packets that are denied by the access policy.
Policy-Based Routing (PBR)

Policy-Based Routing (PBR) allows you to use ACLs and route maps to selectively modify and route IP packets in hardware. The ACLs classify the traffic. Route maps that match on the ACLs set routing attributes for the traffic.
48
A PBR policy specifies the next hop for traffic that matches the policy. Using standard ACLs with PBR, you can route IP packets based on their source IP address. With extended ACLs, you can route IP packets based on all of the clauses in the extended ACL.
ISP_WAN
V L VE1 A N
192.168.2.1
R
VE3: 192.168.2.4/24
Customer B AS 110
209.157.23.X
192.168.2.2
AS 200
192.168.2.3
Customer C AS 120
209.157.24.X
Customer D AS 130
209.157.25.X
Figure 26: Policy-based Routing
Configuring a PBR policy

To configure PBR, you define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device programs the ACLs into the packet processor on the interfaces and routes traffic that matches the ACLs according to the instructions in the route maps. PBR policy configuration overview:
Configure ACLs that contain the source IP addresses for the IP traffic you want to route using PBR. Configure a route map that matches on the ACLs and sets the route information. Apply the route map to an interface.
49
7 Quality of Service (QoS) Concepts

After reviewing this section you should be able to describe Quality of Service (QoS) concepts and their use in different situations.
QoS Overview
Quality of Service (QoS) features are used to prioritize the use of bandwidth in a switch. When QoS features are enabled, traffic is classified as it arrives at the switch, and processed through on the basis of configured priorities. Traffic can be dropped, prioritized for guaranteed delivery, or subject to limited delivery options as configured by a number of different mechanisms. Classification is the process of selecting packets on which to perform QoS, reading the QoS information, and assigning a priority to the packets. The classification process assigns a priority to packets as they enter the switch. These priorities can be determined on the basis of information contained within the packet or assigned to the packet as it arrives at the switch. Once a packet or traffic flow is classified, it is mapped to a forwarding priority queue. Packets on Brocade devices are classified in up to eight traffic classes with values from 0 to 7. Packets with higher priority classifications are given a precedence for forwarding.
QoS for Brocade Stackable Devices

Brocade FastIron units in an IronStack support QoS. Units in a stack communicate the stack topology information and other proprietary control information through the stacking links. In addition to control information, the stacking links also carry user network data packets. In an IronStack topology, the priority of stacking-specific control packets is elevated above that of data path packets, preventing loss of control packets, and timed retries that affect performance. This prioritization also prevents stack topology changes that may occur if enough stack topology information packets are lost. IronStack technology reserves one QoS profile to provide a higher priority for stack topology and control traffic.
QoS Queueing Methods

Weighted Round Robin (WRR) WRR ensures that all queues are serviced during each cycle. A weighted
fair queuing algorithm is used to rotate service among the eight queues on FESX, FSX, FWSX, FGS, FLS, FWS, and FGS-STK and FLS-STK devices. The rotation is based on the weights you assign to each queue. This method rotates service among the queues, forwarding a specific number of packets in one queue before moving on to the next one. WRR is the default queuing method and uses a default set of queue weights.
Strict Priority (SP) SP ensures service for high priority traffic. The software assigns the maximum
weights to each queue which causes the queuing mechanism to serve as many packets in one queue as possible before moving to a lower queue. This method biases the queuing mechanism to favor the higher queues over the lower queues.
Hybrid WRR and SP Starting with software release 02.2.00, an additional configurable queueing
mechanism combines both the strict priority and weighted round robin mechanisms. The combined method enables the Brocade device to give strict priority to delay-sensitive traffic such as VoIP traffic, and weighted round robin priority over other traffic types.
50
Qos-tos trust and qos-tos mark Commands

The qos-tos trust and qos-tos mark commands are retained in 03.8.00 and later versions of the Multi-Service IronWare software as described in the following:
The primary use of these commands is for packet remarking (without changing the internal priority of the
packet if desired). Qos-tos trust indicates the priority to be trusted on the Ingress interface (cos, dscp or ip-prec). Qos-tos mark indicates which priority is to be marked on the Egress interface (cos or dscp).
Qos-tos trust and qos-tos mark commands are both applied at the Ingress interface (physical or
virtual).
Recognizing Inbound Packet Priorities and Mapping to Internal Priority

The processes performed in the first block of Figure 49 can be described in two stages.
Stage 1
Collect priority and drop precedence information from various portions of the packet header
If a packets EtherType matches 8100 or the ports EtherType, derive a priority value and drop precedence by decoding the PCP value. If the qos use-dei command is configured, the bit between the VLAN ID and PCP in the VLAN tag will be interpreted as a drop precedence and priority value. For MPLS packets, derive a priority value and drop precedence by decoding the EXP bits. For IPv4 or v6 packets, derive a priority value and drop precedence by decoding the DSCP bits. The derived values for PCP, EXP and DSCP are mapped to either a default map or a configured Ingress Decode Policy Map. To assist the device in the decoding process described in stage 1 decode-map tables are defined.
Stage 2
Determine if a priority value should be forced or merged
If a packet EtherType matches 8100 or the ports EtherType, derive a priority value and drop precedence by decoding the PCP value. If the qos pcp force command is configured on the port, the priority and drop precedence values are set to the value read from the PCP bits. If the qos exp force command is configured on the port, the priority and drop precedence values are set to the value read from the MPLS EXP bits. If the qos dscp force command is configured on the port, the priority and drop precedence values are set to the value read from the DSCP bits. If none of the qos force commands are configured, the priority and drop precedence values are set for IPv4 or v6 packets and MPLS packets as described in the following:
For IPv4 or v6 Packets: Priority and drop precedence values obtained as a merge of the decoded
PCP and decoded DSCP values.
For MPLS Packets: Priority and drop precedence values obtained as a merge of the decoded PCP
and decoded EXP values.
51
QoS Options for IP ACLs

Quality of Service (QoS) options enable you to perform QoS for packets that match the ACLs. Using an ACL to perform QoS is an alternative to directly setting the internal forwarding priority based on incoming port, VLAN membership, and so on. The following QoS ACL options are supported:
dscp-cos-mapping This option is similar to the dscp-matching command (described below). This option
maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 63 DSCP values, and distributes them among eight traffic classes (internal priorities) and eight 802.1p priorities. By default, the Brocade device does the 802.1p to CoS mapping. If you want to change the priority mapping to DSCP to CoS mapping, you must enter the following ACL statement. permit ip any any dscp-cos-mapping
dscp-marking Marks the DSCP value in the outgoing packet with the value you specify. internal-priority-marking and 802.1p-priority-marking Supported with the DSCP marking option, these
commands assign traffic that matches the ACL to a hardware forwarding queue (internal-priority-marking), and re-mark the packets that match the ACL with the 802.1p priority (802.1p-priority-marking).
dscp-matching Matches on the packet DSCP value. This option does not change the packet forwarding
priority through the device or mark the packet.
802.1p-priority-matching Inspects the 802.1p bit in the ACL that can be used with adaptive rate limiting
802.1p Priority Override

You can configure a port to ignore the 802.1p priority for traffic classification for an incoming packet. When this feature is enabled, packets will be classified as follows:
If the packet matches an ACL that defines the priority, then ACL priority will be used. If the packet source or destination MAC address matches a configured static MAC address with priority,
then static MAC priority will be used.
If the ingress port has a configured priority, then port priority will be used. If the other situations do not apply, the configured or default port priority (0) will be used. 802.1p priority override is supported on physical ports and trunk ports. When applied to the primary port
of a trunk group, the configuration applies to all members of the trunk group.
This feature is not supported together with trust dscp.

Note that the original 802.1p priority in the packet will be retained. This feature does not re-mark the 802.1p value.
52
8 Network Security, Management and Monitoring

After reviewing this section you should be able to do the following:
Describe the tools used to monitor a network Describe the tools used to manage a network Demonstrate how to apply security on switches and routers Describe maintenance procedures for switches and routers
Network Monitoring
sFlow
sFlow is a standards-based protocol that allows network traffic to be sampled at a user-defined rate for the purpose of monitoring traffic flow patterns and identifying packet transfer rates on user-specified interfaces. When sFlow is enabled on a Layer 2 or Layer 3 switch, the system performs the following sFlow-related tasks:
Samples traffic flows by copying packet header information Identifies ingress and egress interfaces for the sampled flows Combines sFlow samples into UDP packets and forwards them to the sFlow collectors for analysis (uses
default UDP port 6343)
Forwards byte and packet count data, or counter samples, to sFlow collectors
Port Mirroring and Monitoring

Port mirroring is a method of monitoring network traffic that forwards a copy of each incoming or outgoing packet from one port on a network switch to another port where the packet can be analyzed. Port mirroring may be used as a diagnostic tool or debugging feature, especially for preventing attacks. Port mirroring can be managed locally or remotely. Configure port mirroring by determining which port from which to copy all packets and assign a mirror port where the copies of the packets are sent. A packet received on, or issued from, the first port is forwarded to the second port. Attach a protocol analyzer on the mirror port to monitor each segment separately. The analyzer captures and evaluates the data without affecting the client on the original port. In the following command sequence example, incoming and outgoing traffic on port e1/2/11 is copied to the mirror port, e 1/2/4, and then monitors are enabled. FastIron(config)#mirror-port ethernet 1/2/4 FastIron(config)#interface ethernet 1/2/11 FastIron(config-if-e1000-11)#monitor ethernet 1/2/4 both The mirror port may be a port on the same switch with an attached RMON probe, a port on a different switch in the same hub, or the switch processor. To configure port monitoring, first specify the mirror port, then enable monitoring on the monitored port.
The mirror port is the port to which the monitored traffic is copied. Attach your protocol analyzer to the
mirror port.
The monitored port is the port whose traffic you want to monitor
53
Network Management
SNMP Access
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. Table8 lists individual Brocade switches and the SNMP access methods they support. These features are supported in the Layer 2, base Layer 3, edge Layer 3, and full Layer 3 software images, except where explicitly noted.
TABLE 8
Support SNMP Access Features FESX FSX 800 FSX 1600 Yes Yes Yes Yes Yes Yes Yes FWS FCX ICX 6610 ICX 6430 ICX 6450 Yes Yes Yes Yes Yes Yes Yes
Feature
SNMP v1, v2, v3 Community strings User-based security model for SNMP v3 SNMP v3 traps Defining the UDP port for SNMP v3 traps SNMP v3 over IPv6 AES encryption for SNMP v3
Yes Yes Yes Yes Yes Yes Yes
Setting the SNMP Trap Holddown Time

When a Brocade device starts up, the software waits for Layer 2 convergence (STP) and Layer 3 convergence (OSPF) before beginning to send SNMP traps to external SNMP servers. Until convergence occurs, the device might not be able to reach the servers, in which case the messages are lost. By default, a Brocade device uses a one-minute holddown time to wait for the convergence to occur before starting to send SNMP traps. After the holddown time expires, the device sends the traps, including traps such as cold start or warm start that occur before the holddown time expires. You can change the holddown time to a value from one second to ten minutes. To change the holddown time for SNMP traps, enter a command such as the following at the global CONFIG level of the CLI. Brocade(config)# snmp-server enable traps holddown-time 30 The command in this example changes the holddown time for SNMP traps to 30 seconds. The device waits 30 seconds to allow convergence in STP and OSPF before sending traps to the SNMP trap receiver. Syntax: [no] snmp-server enable traps holddown-time <secs> The <secs> parameter specifies the number of seconds and can be from 1 600 (ten minutes). The default is 60 seconds.
54
SNTP
Brocade devices can be configured as a Simple Network Time Protocol (SNTP) client. You can configure the Brocade device to consult up to three SNTP servers for the current system time and date. The first server configured will be used unless it becomes unreachable, in which case the Brocade device will attempt to synchronize with the other SNTP servers (if any) in the order in which they were configured. You can configure Brocade devices to function as an SNTP server to its downstream clients. When using the device as an SNTP server, you can also set it to use its own internal clock as the reference source if an upstream server becomes unavailable.
Applying Security
Setting the SSH port number
By default, SSH traffic occurs on TCP port 22. You can change this port number. For example, the following command changes the SSH port number to 2200. Brocade(config)#ip ssh port 2200 Note that if you change the default SSH port number, you must configure SSH clients to connect to the new port. Also, you should be careful not to assign SSH to a port that is used by another service. If you change the SSH port number, Brocade recommends that you change it to a port number greater than 1024. Syntax: ip ssh port <number>
802.1X
Brocade devices support the IEEE 802.1X standard for authenticating devices attached to LAN ports. Using 802.1X port security, you can configure a Brocade device to grant access to a port based on information supplied by a client to an authentication server. When a user logs on to a network that uses 802.1X port security, the Brocade device grants (or denies) access to network services after the user is authenticated through an authentication server. The user-based authentication in 802.1X port security provides an alternative to granting network access based on a user's IP address, MAC address, or sub network. While the client awaits authentication, only the following traffic types are allowed on the client port:
EAPOL Extensible Authentication Protocol On the LAN FDP Brocade Discovery Protocol STP Assumes secure connection
802.1x allows MAC-based authentication. The following are device roles in an 802.1X configuration:
Supplicant (network device) Authenticator (Brocade switch) Authentication Server
55
TACACS+ versus TACACS

TACACS is a simple UDP-based access control protocol originally developed by BBN for MILNET. TACACS+ is an enhancement to TACACS and uses TCP to ensure reliable delivery. TACACS+ is an enhancement to the TACACS security protocol. TACACS+ improves on TACACS by separating the functions of authentication, authorization, and accounting (AAA) and by encrypting all traffic between the Brocade device and the TACACS+ server. TACACS+ allows for arbitrary length and content authentication exchanges, which allow any authentication mechanism to be utilized with the Brocade device. TACACS+ is extensible to provide for site customization and future development features. The protocol allows the Brocade device to request very precise access control and allows the TACACS+ server to respond to each component of that request.
Note
TACACS+ provides for authentication, authorization, and accounting, but an implementation or configuration is not required to employ all three. To create an authentication method list that specifies TACACS/TACACS+ as the primary authentication method for securing Telnet/SSH access to the CLI. Brocade(config)#enable telnet authentication Brocade(config)#aaa authentication login default tacacs local The commands above cause TACACS/TACACS+ to be the primary authentication method for securing Telnet/ SSH access to the CLI. If TACACS/TACACS+ authentication fails due to an error with the server, authentication is performed using local user accounts instead.
Maintenance Procedures Loading and Saving Configuration Files

For easy configuration management, all Brocade devices support both the download and upload of configuration files between the devices and a TFTP server on the network. You can upload either the startup configuration file or the running configuration file to the TFTP server for backup and use in booting the system:
Startup configuration file This file contains the configuration information that is currently saved in flash.
To display this file, enter the show configuration command at any CLI prompt.
Running configuration file This file contains the configuration active in the system RAM but not yet
saved to flash. These changes could represent a short-term requirement or general configuration change. To display this file, enter the show running-config or write terminal command at any CLI prompt. Each device can have one startup configuration file and one running configuration file. The startup configuration file is shared by both flash modules. The running configuration file resides in DRAM.
Note
Brocade devices also support Secure Copy (SCP) for securely transferring files between a Brocade device and SCP-enabled remote hosts.
56
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, use the copy flash flash primary command to
overwrite the old software image with the upgrade image in primary flash
The following command copies the system image in the primary flash to the TFTP server: - FastIron# copy flash tftp 192.22.33.44 vm1r07501.bin primary - A failure may indicate the presence of something in the secondary flash
Note
Always use the write memory command to save configuration changes.
Password Recovery
Recovering from a lost password requires direct access to the serial port and a system reset. This procedure can only be accomplished from the console port. To recover from a lost password: 1. Start a CLI session over the serial interface to the device and reboot it SW-Switch# reload Are you sure? (enter 'y' or 'n'): y Halt and reboot 2. At the initial boot prompt at system startup, enter b to enter the boot monitor mode. 3. Enter no password at the prompt BOOT MONITOR> no password OK! Skip password check when the system is up. This command will bypass the system password check, and cannot be abbreviated (this will not erase any existing passwords) 4. Enter boot system flash [primary | secondary] at the prompt BOOT MONITOR> boot system flash primary BOOT INFO: load from primary copy <Truncated Output> 5. Once the console prompt reappears, assign a new password. 6. Issue the write memory command to save the new password.
57
9 Troubleshooting
After reviewing this section you should be able to do the following:
Demonstrate knowledge of troubleshooting tools and techniques Demonstrate ability to analyze troubleshooting output
Contacting Support
When contacting support there are several pieces of information about your data center that would expedite your case:
Collect a supportsave Collect a show tech-support Have the most recent topology diagram available Have the most recent changes to your environment
supportsave Command
The supportsave is an important utility for collecting logs from the driver, internal libraries, and firmware. The collected logs are shared with the technical support personnel for investigating issues seen on the device. Note
The supportsave utility is supported only on the Brocade ICX 6430 and 6450 devices.
TFTP is used to capture supportsave data. It is disabled by default, if FIPS is enabled. Enable TFTP manually for uploading supportsave data. It is a prerequisite to have the TFTP server with a write permission and the server must be accessible from the device.
Determining STP Port States

The show interface brief command is a good tool to use to determine the state of the port: Brocade(config-if-e10000-cx4-1/2/1)# show interface br 1/1/4 Up Forward Full 1G None No 1 0 001b.f288.0003 1/2/1 Up Forward Full 16G None No 1 0 001b.f288.0019 1/3/1 Up Forward Full 10G None No N/A 0 001b.f288.001b 3/3/1 Up Forward Full 10G None No N/A 0 0024.3814.9df3 mgmt1 Up None Full 1G None No 1 0 001b.f288.0018
58
STP Port States

In the Spanning Tree algorithm, a port transitions through the states listed in to determine if it either forwards or blocks data traffic.
TABLE 9
State Listening
STP Port States

Description Blocks traffic, listens for BPDUs, and builds the STP tree topology to ensure there are no loops in the network. Creation of the STP topology, within a particular VLAN, involves election of the root bridge and a designated bridge for each LAN segment inside of the VLAN. When the forwarding timer expires, if the port is classified as either a Root Port (RP), or a Designated Port (DP) it moves to the Learning state. If the port has no designation then it moves to the Blocking state. In the Learning state, RPs and DPs continue to block data traffic as the switches learn MAC addresses and build their MAC tables. The second expiration of the forwarding timer moves RPs and DPs to the Forwarding state to start forwarding traffic. Data traffic is blocked for a non-designated port, but BPDUs are allowed to circulate.
Learning Forwarding Blocking
You can change the bridge priority, port priority, and path cost so that a predetermined outcome occurs in the election process (Learning state).
Port initialization Non Designated Ports: Port is Blocked MAC table remains empty Port Role is established as: Root Port Designated Port Non-Designated (15 sec) Root and Designated Ports: Port receives data traffic Populates its MAC table (15 sec) Root and Designated Ports: Send and Receive data traffic
Figure 27: STP Port States
Blocking state
Listening state
Learning state
Forwarding state
Viewing Optical Monitoring Information

You can view temperature and power information for qualified XFPs, SFPs, and SFP+ installed in a FastIron device. Use the show optic <port-number> command to view information about an XFP, SFP, or SFP+ installed in a particular port. The following shows example output.
59
Brocade# show optic 13 Port Temperature Tx Power Rx Power Tx Bias Current +----+-----------+----------+------------+-------------------+ 13 33.2968 C -005.4075 dBm -007.4328 dBm 6.306 mA Normal Normal Normal Normal Optical monitoring feature will not work in the following scenarios:
The port is DOWN. The port is configured as a stacking port. The the optic module does not support optical monitoring. For ICX 6430 devices only: - If an SFP+ optic is inserted in an SFP only port, the optic will not initialize. - If an SFP optic is inserted in an SFP+ only port, the optic will not initialize. - If an optic is inserted into a device that supports both SFP and SFP+ optics, use the speed-duplex
command to set the port speed correctly.
Interface Configuration
Each 10/100/1000 port is designed to auto-sense and auto-negotiate the speed and mode of the connected device. If the attached device does not support this operation, the port speed may be set to operate at either 10, 100, or 1000 Mbps. The default value is for the ports to auto-sense speed and duplex. Settings should be the same at both ends. If a port is not working or cannot connect to another switch or server, verify that the settings are correct, the port is not administratively disabled, and the cable between the source and destination is not damaged.
Recovering Disabled Ports

Once a loop is detected on a port, it is placed in Err-Disable state. The port will remain disabled until one of the following occurs:
You manually disable and enable the port at the Interface Level of the CLI. You enter the command clear loop-detection. This command clears loop detection statistics and enables
all Err-Disabled ports.
The device automatically re-enables the port.
IP Packet Parameters
You can configure the following packet parameters on Layer 3 Switches. These parameters control how the Layer 3 Switch sends IP packets to other devices on an Ethernet network. The Layer 3 Switch always places IP packets into Ethernet packets to forward them on an Ethernet port.
Encapsulation type The format for the Layer 2 packets within which the Layer 3 Switch sends IP packets.
60
Maximum Transmission Unit (MTU) The maximum length of IP packet that a Layer 2 packet can contain.
If MTU size is not the same between switches you may see a high packet loss. IP packets that are longer than the MTU are fragmented and sent in multiple Layer 2 packets. You can change the MTU globally or an individual ports:
Global MTU The default MTU value depends on the encapsulation type on a port and is 1500 bytes for Ethernet II encapsulation and 1492 bytes for SNAP encapsulation. Port MTU A port default MTU depends on the encapsulation type enabled on the port.
802.1x Debug Commands

The following commands displays information about 802.1x authentication events, activities, and settings.
TABLE 10
Debug Type debug dot1x events
802.1x Debug Commands

Syntax [no] debug dot1x events Brocade# debug dot1x events dot1x: Events debugging is on Description This command displays the authentications failed or succeeded and the application of VLANs or ACLs requested by the Remote Authentication Dial In User Service (RADIUS) server. This command works globally across all the ports.
debug dot1x filter
[no] debug dot1x filter Brocade# debug dot1x filter dot1x: Filter debugging is on
This command enables the 802.1x filter debugging.
debug dot1x misc
[no] debug dot1x misc Brocade# debug dot1x misc dot1x: Misc debugging is on
This command enables the 802.1x miscellaneous debugging.
debug dot1x packets
[no] debug dot1x packets Brocade# debug dot1x packets dot1x: Packets debugging is on
This command displays information about 802.1x packets. This command displays information about 802.1x timers.
debug dot1x timers
[no] debug dot1x timers Brocade# debug dot1x timers dot1x: Timers debugging is on
Protocol Ports
It is common practice for network security administrators to shut down unused ports. Before calling support about an unavailable application or service, verify the port that the application or service uses (both sending and receiving) is available for that traffic.
61
Taking the Test

After the Introduction Screen, once you click on Next, you will see the following non-disclosure agreement:
IMPORTANT: PLEASE READ THE FOLLOWING BROCADE NON-DISCLOSURE CONFIDENTIALITY AGREEMENT CAREFULLY BEFORE TAKING THIS EXAM.
The following Non-Disclosure Confidentiality Agreement (the Agreement) sets forth the terms and conditions of your use of the exam materials as defined below. The Disclosure to you of this Exam and any questions, answers, worksheets, computations, drawings, diagrams, or any communications, including verbal communication by any party, regarding or related to the Exam and such Exam Materials and any derivatives thereof is subject to the Terms and Conditions of this Agreement. You understand, acknowledge and agree:
That the questions and answers of the Exam are the exclusive and confidential property of Brocade
and are protected by Brocade intellectual property rights;
That you may not disclose the Exam questions or answers or discuss any of the content of the Exam
Materials with any person, without prior approval from Brocade;
Not to copy or attempt to make copies (written, photocopied, or otherwise) of any Exam Material,
including, without limitation, any Exam questions or answers;
Not to sell, license, distribute, or give away the Exam Materials, questions, or answers; You have not purchased, solicited or used unauthorized (non-Brocade sanctioned) Exam Materials,
questions, or answers in preparation for this exam;
That your obligations under this Agreement shall continue in effect after the Exam and, if applicable,
after termination of your credential, regardless of the reason or reasons for terminations, and whether such termination is voluntary or involuntary. Brocade reserves the right to take all appropriate actions to remedy or prevent disclosure or misuse, including, without limitation, obtaining an immediate injunction. Brocade reserves the right to validate all results and take any appropriate actions as needed. Brocade also reserves the right to use any technologies and methods for verifying the identity of candidates. Such technology may include, without limitation, personally identifiable information, challenge questions, identification numbers, photographic information, and other measures to protect against fraud and abuse. Neither this Agreement nor any right granted hereunder shall be assignable or otherwise transferable by you. By clicking on the "A" button (YES, I AGREE), you are consenting to be bound by the terms and conditions of this agreement and state that you have read this agreement carefully and you understand and accept the obligations which it imposes without reservation. You further state that no promises or representations have been made to induce agreement and that you accept this agreement voluntarily and freely. A. B. YES, I AGREE NO, I DO NOT AGREE
62

BCNE Nutshell - Brocade Certified Network Engineer Exam Topics

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BCNE Nutshell - Brocade Certified Network Engineer Exam Topics

Transféré par

Droits d'auteur :

Formats disponibles

BCNE 2012 in a Nutshell Study Guide for Exam 150-130

Brocade University Revision 0912

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Introduction to BCNE 2012 in a Nutshell First Edition

Joe Cannata Certification Manager

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

2012 Brocade Communications

Brocade Certified Network Engineer in a Nutshell Second Edition

2 Brocade Hardware Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Hardware Platform Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Layer 2 Switching and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Virtual Local Area Network Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Link Aggregation Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2011 Brocade Communications

Brocade Certified Network Engineer in a Nutshell Second Edition

4 General Layer 2 and Layer 3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Virtual Router Redundancy Protocol - Enhanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Supported Layer 3 multicast routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 Access Control List (ACL) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Policy-Based Routing (PBR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Quality of Service (QoS) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2011 Brocade Communications

Brocade Certified Network Engineer in a Nutshell Second Edition

8 Network Security, Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Determining STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Taking the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2011 Brocade Communications

Brocade Certified Network Engineer in a Nutshell Second Edition

2011 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

1 Layer1 Hardware Concepts

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Optics Comparison Chart

Figure 1: SFP Side View

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

SFP SFP+ XFP

IEEE 802.23a PoE and 802.23at PoE+

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

IEEE 802.23a PoE and 802.23at PoE+

Maximum PD wattage (W)

Detection of PoE Power Requirements

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

2 Brocade Hardware Platforms

Delivers feature/price value for applications

Combines chassis-like capabilities with an economical fixedport solution

FCX Series: Data Center vs. Campus Offerings

2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Brocade VDX 6730 Data Center Switches

Non-blocking, cut-through architecture, wirespeed