BCNE Nutshell

BCNE in a Nutshell Study Guide for Exam 150-120
Exam Preparation Materials
Revision September 2009
Corporate Headquarters - San Jose, CA USA T: (408) 333-8000 info@brocade com 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 apac-info@brocade.com
2009 Brocade Communications Systems, Inc. All Rights Reserved. Brocade, the Brocade B-weave logo, Fabric OS, File Lifecycle Manager, MyView, Secure Fabric OS, SilkWorm, and StorageX are registered trademarks and the Brocade B-wing symbol and Tapestry are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. FICON is a registered trademark of IBM Corporation in the U.S. and other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners. Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not b currently be tl available. il bl C Contact t taB Brocade d sales l office ffi for f information i f ti on feature f t and d product d t availability. il bilit Export of technical data contained in this document may require an export license from the United States government. Revision: September, 2009
BCNE in a Nutshell First Edition
Objective: The BCNE Nutshell guide is designed to help you prepare for the BCNE Certification, exam number 150-120. Audience: The BCNE Nutshell self-study guide is intended for those who have successfully completed the ETH 101 and 103 courses, and who wish to undertake self-study or review activities before taking the actual BCNE exam. The BCNE guide is not intended as a substitute for classroom training or hands-on time with Brocade products. How to make the most of the BCNE guide: The BCNE guide summarizes the key topics on the BCNE exam for you in an easy to use format. It is organized closely around the exam objectives. We suggest this guide be used in conjunction with our free online knowledge assessment test - CNE 101-WBT BCNE Knowledge Assessment. To benefit from the BCNE guide, we strongly recommend you have successfully completed the ETH 101 and 103 courses. We hope you find this useful in your journey towards BCNE Certification, and we welcome your feedback by sending an email to jcannata@brocade.com.
Helen Lautenschlager Director of Education Solutions
Joe Cannata Certification Manager
2009 Brocade Communications
Table of Contents
1 - Layer 1/Hardware Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Physical Media Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 SFP Transceivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Media Access Control (MAC) Address Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Terminology - Layer 1 Key Cabling Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Terminology - Layer 1 Media Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Implementing POE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 POE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Cabling Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Implementing Hardware Platforms and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 File management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Digital Optical Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 - Layer 2 Switching and Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 PVST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 The Root Bridge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 BPDUs (Bridge Protocol Data Units) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Fast Port Span. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Topology Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Layer 2 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Clearing MAC Address Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 UDLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Switch Frame Forwarding Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 VLAN Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 802.1q Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Configurin Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Link Aggregation Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Trunking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 LACP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3 - General Layer 2/Layer 3 Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 General Routing and Switching Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Ethernet Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Spanning Tree Protocol (STP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Traffic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Defining a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 VRRP-E (Virtual Router Redundancy Protocol - Enhanced) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4 - Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 General Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Classless Inter-Domain Routing (CIDR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Variable Length Subnet Masks (VLSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Routed Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Designated Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 LSA Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 BGP (Border Gateway Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 What is BGP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Injecting Routes into BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 BGP Connectivity Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Multicast Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 PIM Sparse Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Mapping IP Multicast to a MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
BCFD in a Nutshell 8 Gbit/sec Edition
5 - Access Control List (ACL) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACL Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy-Based Routing (PBR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . QoS Options for ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACL-Based Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - Quality of Service (QoS) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qos Queueing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Marking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - Wireless Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.11b Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ESSIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1X Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - Network Security, Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restricting Remote Access to the Device to Specific VLAN IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syslog Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . sFlow Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Port Mirroring and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Console Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restricting Remote Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Levels of CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Securing CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintenance Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Switch and Router show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . File Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tools and Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reasons for Ping Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reasons for OSPF Neighbor Establishment Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gathering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyzing Troubleshooting Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RSTP (802.1w) Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying the IP Route Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Taking the Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30 30 30 31 31 31 32 32 32 32 33 33 33 34 34 35 35 35 35 36 36 37 37 37 37 37 38 39 39 39 39 40 40 40 40 40 40 41 41 41 42
List of Tables
Default Routing Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
BCNE in a Nutshell FIrst Edition
List of Figures
MAC Address Inside an Ethernet Frame .................................................................................................................................................................................. 7 Per VLAN Spanning Tree......................................................................................................................................................................................................... 10 Switch Frame Forwarding Methods ....................................................................................................................................................................................... 14 VLAN Tagging........................................................................................................................................................................................................................... 15 802.1q Tagging (Packet Format) ........................................................................................................................................................................................... 16 Dynamic Trunks ...................................................................................................................................................................................................................... 18 Ethernet Frame Format .......................................................................................................................................................................................................... 19 Default Routes ........................................................................................................................................................................................................................ 20 Subnetting ............................................................................................................................................................................................................................... 23 IP Multicast Mapping .............................................................................................................................................................................................................. 29 802.11b Spectrum ................................................................................................................................................................................................................. 33 Sample NDA ............................................................................................................................................................................................................................ 42 Sample Question..................................................................................................................................................................................................................... 43 Example Exam Score Sheet ................................................................................................................................................................................................... 44
1 - Layer 1/Hardware Concepts

Physical Media Topics
SFP Transceivers The small form-factor pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communications applications. It interfaces a network device motherboard (for a switch, router, media converter or similar device) to a fiber optic or copper networking cable. It is a popular industry format. SFP transceivers are designed to support SONET, Gigabit Ethernet, Fibre Channel, and other communications standards. The standard is covering SFP+ supporting data rates up to 10 Gbit/sec (to also include for 8 Gbit/ sec Fibre Channel, and 10 GbE). The SFP+ has a smaller form factor than a regular SFP. 1000 Mbit TX SFPs could be used on non-combo ports if copper is required. Media Access Control (MAC) Address Format MAC Address is also known as: - Ethernet Address - Physical Address - Data Link Address - Hardware Address - IEEE Address A MAC address is not a logical address; it is a physical address burned into the Network Interface Controller (NIC) at the factory - The MAC address is used to uniquely identify each node on the Ethernet network
Figure 1: MAC Address Inside an Ethernet Frame
A MAC is comprised of 48 bits (6 hex pairs): xx:xx:xx:yy:yy:yy - The first 3 bytes (xx:xx:xx) represent the IEEE registered manufacturers Organizational Unique Identifier (OUI) - The last 3 bytes (yy:yy:yy) represent a unique ID (all NICs must be unique) MAC addresses can also be notated by three sets of four nibbles: - 1234.5678.9abc The Destination Address (DA) and Source Address (SA) fields in an ethernet frame each contain a MAC address
Terminology - Layer 1 Key Cabling Issues Noise is unwanted signals, or interference, from sources near network cabling, such as electrical motors, power lines and radar Attenuation is the amount of signal loss over a given distance Crosstalk a type of interference caused by signals traveling on nearby wire pairs infringing on another pairs signal Bend radius is the radius of the maximum arc into which you can loop a cable before you will cause transmission errors Latency The delay between the transmission of a signal and its receipt Jitter is a variation in packet transit delay caused by queuing, contention and serialization effects on the path through the network Terminology - Layer 1 Media Types Coaxial Cable - Thick - Thin Twisted Pair Cable - Shielded (STP) - Unshielded (UTP) o UTP is less expensive and less resistant to noise than STP Fiber Optic Cable - Multi-mode - Single mode
Implementing POE
POE Overview Power over Ethernet (POE) devices, are compliant with the IEEE 802.3af standards for delivering in-line power over existing network cabling infrastructure, enabling multicast-enabled full streaming audio and video applications for converged services, such as, Voice over IP (VoIP), WLAN access points, IP surveillance cameras, and other IP technology devices. POE technology eliminates the need for an electrical outlet and dedicated UPS near IP powered devices. With power sourcing devices, power is consolidated and centralized in the wiring closets, improving the reliability and resiliency of the network. Because POE can provide power over Ethernet cable, power is continuous, even in the event of a power failure. An error message will be displayed if the device attached does not support POE. Cabling Requirements The 802.3af standard currently supports POE on 10/100/1000 Mbps Ethernet ports operating over standard Category 5 unshielded twisted pair (UTP) cable or better. If your network uses cabling categories less than 5, you cannot implement POE without first upgrading your cables to CAT 5 UTP or better.
Implementing Hardware Platforms and Features

File Management The secondary partition of the flash card may be used as the storage space for upgrade code. Digital Optical Monitoring You can let a Brocade device monitor optical transceivers in the system, either globally or by specified ports. When this feature is enabled, the system will monitor the temperature and signal power levels for the optical transceivers in the specified ports. Console messages and syslog messages are sent when optical operating conditions fall below or rise above the XFP or SFP manufacturers recommended thresholds.
2 - Layer 2 Switching and Protocols

Layer 2 Protocols
PVST In environments with multiple VLANs, the Per VLAN Spanning Tree Protocol may be used. Brocade Layer 2 and Layer 3 Switches support standard STP as described in the IEEE 802.1D specification. PVST is enabled within each VLAN as it is enabled on an L2 switch. The enhanced PVST+ support in release 07.6.01 allows a Brocade device to interoperate with PVST spanning trees and the IEEE 802.1Q spanning tree at the same time. IEEE 802.1Q and PVST regions cannot interoperate directly but can interoperate indirectly through PVST+ regions. Each VLAN has its own Spanning Tree instance Each VLAN has its own Root Bridge Ports blocked by one STP instance can be used by another STP instance
VLAN 2
1 Link 2 3 Link Ac ti v ity Ac tiv i ty 1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7
L in k Ac ti v ity
VLAN 33
7 L in k 8 Co n s o l e Ac tiv i ty 1 1 24 15 16 17 18 1 9 20 21 22 23 2 4 1 1 24 15 16 17 18 1 9 20 21 22 23 2 4 1 1 24 15 16 17 18 1 9 20 21 22 23 2 4
FastIron II
1 0
1 13 1
1 0
1 13 1
1 0
1 13 1
Switch 1
Switch 2
1 1 1
FastIron II
1 L in k Ac ti v ity 2 3 Link Ac tiv i ty 4 5 L in k Ac tiv i ty 6 7 L in k Ac ti v ity 8 Co n s o l e
1 0
1 13 1
12 14
15
16
1 7
18
1 9
2 0
21
2 2
23
2 4
1 0
1 13 1
12 14
15
16
1 7
18
1 9
2 0
21
2 2
23
2 4
1 0
1 13 1
12 14
15
16
1 7
18
1 9
2 0
21
2 2
23
2 4
VLAN 2
Figure 2: Per VLAN Spanning Tree
VLAN 33
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. The root bridge is elected to make that determination. BPDUs are sent. The switch with the lowest Bridge ID becomes the root bridge. All Brocade switches have the default priority. If that is the case, then the lowest MAC address will be used. After the election, each switch determines the shortest path to the root bridge. The switch port involved in that path will be called the root port. When multi-
10
ple switches share a connection that is not a root port, one of them will become the designated port, the other will block. BPDUs (Bridge Protocol Data Units) BPDUs are data messages that are exchanged across switches within a LAN/VLAN to form and maintain a Spanning Tree Protocol topology BPDU 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, etc. BPDU Types: Configuration BPDU and Topology Change Notification (TCN) BPDU Spanning Tree is on by default on switches but off by default on routers BPDU exchange results in the following: - One switch is elected as the root switch - The shortest distance to the root switch is calculated by each switch - A designated switch is selected. This is the switch closest to the root switch through which user traffic/frames will be forwarded to the root - A root port for each switch is selected. This is the port providing the best path from the switch to the root switch - A designated port for each LAN segment is selected. This is the port providing the best path from the LAN segment to the root switch. - Ports included in the Spanning-Tree Protocol are selected - If all switches are enabled with default settings, the switch with the lowest MAC address in the network becomes the root switch. The network assuming that Switch 1 has the lowest MAC address and is therefore the root switch. Due to traffic patterns, number of forwarding ports, or line types, Switch 1 might not be the ideal root switch. By increasing the priority (lowering the numerical priority number) of the ideal switch so that it then becomes the root switch, you force a Spanning-Tree Protocol recalculation to form a new, stable topology. Configuration BPDU: Generated only by the Root Bridge and sent to non-root bridges, provides a method of providing election information across the L2 domain and controlling reconvergence after a link has been broken. 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.
11
STP Port States In the Spanning Tree Algorithm, a port transitions through the following states to determine if it will either Forward data traffic or Block data traffic: Listening - 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, or a Designated Port it will move to the learning state. If, on the other hand, the port has no designation then it moves to the Blocking State. Learning - In the learning state, Root Ports and Designated ports continue to block data traffic as the switches learn MAC addresses and build their MAC tables. Forwarding - The 2nd expiration of the forwarding timer moves Root Ports and Designated Ports to the forwarding state to start forwarding traffic. Blocking Data Traffic is blocked, for a Non-Designated Port, while BPDUs are allowed to circulate. You can change the Bridge Priority, Port Priority, and Path Cost so that a pre-determined outcome occurs in the election process (learning state). 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. Thus, 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. 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 thus do not present the potential to 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. Fast Port Span performs the convergence on these ports in four seconds (two seconds for listening and two seconds for learning). In addition, it enhances overall network performance in the following ways: Fast Port Span reduces the number of STP topology change notifications on the network Fast Port Span 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 these criteria, it port is ineligible for Fast Port Span and uses normal STP instead: - The port is 802.1Q tagged - 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
12
Topology Groups A topology group is a named set of VLANs that share a Layer 2 topology. Topology groups simplify configuration and enhance scalability of Layer 2 protocols by allowing you to run a single instance of a Layer 2 protocol on multiple VLANs. You can use topology groups with the following Layer 2 protocols: STP MRP VSRP 802.1w
MRP is the Metro Ring Protocol. If a break in the ring occurs, MRP heals the ring by changing states of some of the ring interfaces. Blocking interface The Blocking interface on the Master node has a dead timer. If the dead time expires before the interface receives one of its rings RHPs, the interface changes state to Preforwarding. Once the secondary interface changes state to Preforwarding: - If the interface receives an RHP, the interface changes back to the Blocking state and resets the dead timer. - If the interface does not receive an RHP for its ring before the Preforwarding time expires, the interface changes to the Forwarding state Forwarding interfaces Each member interface remains in the Forwarding state If the link between shared interfaces breaks, the secondary interface on the master node changes to a preforwarding state You can display the following MRP information: - Topology group configuration information - Ring configuration information and statistic
Layer 2 Functionality
Clearing MAC Address Entries You can remove learned MAC address entries from the MAC address table. The types of MAC addresses that can be removed are: All MAC address entries All MAC address entries for a specified Ethernet port All MAC address entries for a specified VLAN All specified MAC address entry in all VLANs
Running the clear mac-address command without any parameters will remove all MAC address entries.
13
UDLD UniDirectional Link Detection is a Layer 2 protocol to monitor the physical condition of any cables and detect any unidirectional links as a result of a cable failure. If it is enabled on a switch or a router, the packets are generated and processed by the devices CPU. An interface could be disabled by UDLD. Switch Frame Forwarding Methods Store-and-forward - The switch buffers and, typically, performs a checksum on each frame before forwarding it on Cut-through - The switch reads only up to the frame's hardware address before starting to forward it. There is no error checking with this method. Store-and-forward switching means that the switch copies each complete frame into the switch memory buffers and computes a cyclic redundancy check (CRC) for errors. CRC is an error-checking method that uses a mathematical formula, based on the number of bits (1s) in the frame, to determine whether the received frame is corrupted. If a CRC error is found, the frame is discarded. If the frame is error free, the switch forwards the frame out the appropriate interface port. Cut-through switching means that the switch copies into its memory only the destination MAC address, which is located in the first 6 bytes of the frame following the preamble. The switch looks up the destination MAC address in its forwarding table, determines the outgoing interface port, and forwards the frame on to its destination through the designated switch port. This method will not detect runt frames. Another alternative is Fragment-free switching, which works like cut-through switching with the exception that a switch in fragment-free mode stores the first 64 bytes of the frame before forwarding. This can be viewed as a hybrid/compromise between store-and-forward switching and cut-through switching. The reason fragmentfree switching stores only the first 64 bytes of the frame is that most network errors and collisions occur within the first 64 bytes of a frame.
Figure 3: Switch Frame Forwarding Methods
14
VLAN Implementations
VLANs Virtual Local Area Network A logical subgroup within a local area network that is created via software rather than manually moving cables in the wiring closet Combines user stations and network devices into a single unit regardless of the physical LAN segment they are attached to and allows traffic to flow more efficiently within populations of mutual interest Creates a broadcast domain Done through software configuration Implemented in port switching, hubs and LAN switches By default, all Brocade switch ports are members of VLAN 1 VLANs reduce the time it takes to implement moves, adds and changes Layer 3 VLANs require that all members are in the same port-based VLAN 802.1Q Tagging When you create a VLAN on a switch, you need to determine which of its ports participate in that VLAN. The two types of membership are: Tagged - the switch adds an extra 4 bytes to the Ethernet frame called the 802.1Q header - Allows multiple port based VLANs to span switches over a single physical link Untagged - the switch keeps track of this port as a member of the VLAN
Figure 4: VLAN Tagging
15
The tag contains the TPI, which identifies the frame as a tagged. The value of the TPI 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 5: 802.1Q Tagging (Packet Format)
CLI Command sequence to configure VLAN (14 in this example) and assign an IP address to a VE for VLAN 14: NetIron(config)# vlan 14 NetIron(config-vlan-14)# untag ethernet 1/1 to 1/12 NetIron(config-vlan-14)# router-interface ve 1 NetIron(config-vlan-14)# exit NetIron(config)# interface ve1 NetIron(config-vif-1)# ip address 192.123.22.1 255.255.255.0 Configuring 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
16
By default, a private VLAN does not forward broadcast or unknown-unicast packets from outside sources into the private VLAN. If needed, you can override this behavior for broadcast packets, unknown-unicast packets, or both. You can configure a combination of the following types of private VLANs: Primary The primary private VLAN ports are promiscuous. They can communicate with all the isolated private VLAN ports and community private VLAN ports in the isolated and community VLANs that are mapped to the promiscuous port. Isolated Broadcasts and unknown unicasts received on isolated ports are sent only to the primary port. They are not flooded to other ports in the isolated VLAN Community Broadcasts and unknown unicasts received on community ports are sent to the primary port and also are flooded to the other ports in the community VLAN Each private VLAN must have a primary VLAN. The primary VLAN is the interface between the secured ports and the rest of the network. The private VLAN can have any combination of community and isolated VLANs. You cannot configure isolated, community, or primary VLANs on 802.1Q tagged ports Normally, in any port-based VLAN, the device floods unknown unicast, unregistered multicast, and broadcast packets in hardware, although selective packets, such as IGMP, may be sent to only to the CPU for analysis, based on the IGMP snooping configuration. When Protocol or Subnet VLANs are enabled, or if Private VLAN mappings are enabled, the device will flood unknown unicast, unregistered multicast, and broadcast packets in software You can configure private VLANs and dual-mode VLAN ports on the same device - Dual-mode VLAN ports cannot be members of Private VLANs
Link Aggregation Implementations

Trunking A trunk is a group of physical ports that act as one logical port. (trunking = link aggregation). In addition to enabling load sharing of traffic, trunk groups provide redundant, alternate paths for traffic if any of the segments fail. Benefits of Trunking: - Load-sharing - Redundancy Two types of Trunking: - Static Trunking: o Manually configured aggregate links containing multiple ports - Dynamic Trunking: (802.3ad Link Aggregation) o Dynamically created and managed trunk groups using Link Aggregation Control Protocol (LACP) Trunking can be established between Brocade Layer 2/3 switches, or between a switch and a server
17
LACP Brocade software supports the IEEE 802.3ad standard for link aggregation. This standard describes the Link Aggregation Control Protocol (LACP), a mechanism for allowing ports on both sides of a redundant link to form a trunk link (aggregate link), without the need for manual configuration of the ports into trunk groups. When you enable link aggregation on a group of Brocade ports, the Brocade ports can negotiate with the ports at the remote ends of the links to establish trunk groups. To display link aggregation information, including the key for all ports on which link aggregation is enabled, enter the following command at any level of the CLI: FastIron#show link-aggregation Operational ports are denoted with Ope Configuring 802.3ad Dynamic Trunks
Figure 6: Dynamic Trunks
BigIron_A(config)# interface ethernet 1/1 BigIron_A(config-if-e1000-1/1)# link-aggregate active BigIron_A(config)# interface ethernet 1/2 BigIron_A(config-if-e1000-1/2)# link-aggregate active BigIron_B(config)# interface ethernet 1/1 to 1/2 BigIron_B(config-mif-1/1-1/2)# link-aggregate passive The active device sends/receives LACPDUs; the passive device only receives LACPDUs.
18
3 - General Layer 2/Layer 3 Concepts

General Routing and Switching Functionality
Ethernet Frame Format Ethernet uses a very simple and efficient frame format
Figure 7: Ethernet Frame Format
Spanning Tree Protocol (STP) Spanning Tree Protocol (STP) is a link management protocol that provides path redundancy while preventing undesirable loops in the Ethernet network In order for an Ethernet network to function properly, only one active path can exist between two nodes - Multiple active paths between nodes cause loops in the network - If a loop exists in the network topology, the potential exists for duplication of frame delivery - When loops occur, switches may see the same node appear on different ports on the switch The STP algorithm relies on the use of Bridge Protocol Data Units (BPDUs), which provide information to all switches about the distance in hops to each switch port from a root switch By default the switch with the lowest MAC address will become the root switch - There is a configurable parameter (Bridge Priority) that can be set on each switch to allow administrators to predetermine a specific root switch Using BPDU information, a switch can determine whether one of its ports provides an optimal path to the root switch - If it does not, that port is placed in the blocked state - If the path distance is optimal but is the same as another switches path, a simple method (atie breaker) allows one of the ports to be placed in blocked mode
19
If one network segment in the Spanning Tree Protocol becomes unreachable, or if a port cost changes, the spanning-tree algorithm reconfigures the spanning-tree topology and re-establishes the link by activating the standby path Traffic Types Unicast traffic describes point to point communication where there is just one sender, and one receiver. Unicast transmission, in which a packet is sent from a single source to a specified destination, is still the predominant form of transmission on LANs and within the Internet. IP networks support the Unicast transfer mode, and most users are familiar with the standard Unicast applications (e.g. HTTP, SMTP, FTP and Telnet) which employ the TCP transport protocol. Multicast traffic describes communication which occurs between a sender and a grouping of recipients. Multicasting is the networking technique of delivering the same packet simultaneously to a group of clients. One example of an application which may use multicast is a video server sending out networked TV channels. Broadcast traffic describes communication where a piece of information is sent from one point to all other points. In this case there is one sender and many receivers. An example of this is the ARP which uses a broadcast to send an address resolution query to all devices on a LAN segment in order to resolve an IP address to a physical MAC address. A host will drop the ARP if it is not the target of the request. ARPs are used to resolve unknown destination MAC addresses. Defining a Default Route
Figure 8: 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. ip route 0.0.0.0 0.0.0.0 209.157.1.1 can appear in a route table because it is:
20
Manually configured on the router Can be sent to other routesr by a routing protocol like OSPF - OSPF uses a command called default-information originate to send the default route to other OSPF routers 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 VRRP-E (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 VRID. The router with the highest priority becomes Master. VRRP-E uses UDP to send Hello messages in IP multicast messages VRRP-E requires only that the VRID be in the same subnet as an interface configured on the VRID's interface. Multiple VRIDs can exist on a single interface. VRRP-E supports the use of more than one track port 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 To prevent an immediate transition from backup to re-instated master, enable the slow start timer
21
4 - Routing Concepts
General Routing Concepts
RIP There are two basic steps to enabling IP RIP routing: 1. Enable RIP globally 2. Assign IP address/mask to each routed interface. RIP is enabled on a per interface basis. This way RIP updates are not flooded out of every port. RIPv2 supports MD5 Classless Inter-Domain Routing (CIDR) CIDR was created to help resolve some problems: - Because of the Internet evolution there was a real concern that 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 A real motivation behind CIDR implementations was allocating IP address space more efficiently instead of handing out full classful addresses (A or B) to organizations that were not being fully utilized During the early adoption phase of CIDR a real concern existed about the imminent depletion of Class B networks. (Class C networks were not favored by companies due to its inherent host address constraints). CIDR was seen as an interim solution until the adoption of IPv6 and its much larger address space. For example, if an network administrator has a need for 300 IP addresses he/she would typically either need a small portion of a class B network (and thereby waste much of that address space) or 2 Class C networks (remember 254 hosts are possible in a standard Class C network). There is no middle ground with the structured classful address scheme. CIDR provides a mechanism for aggregating multiple smaller networks into a single larger network as in combining 2 Class C networks to provide 512 host addresses. CIDR provides the mechanism to combine multiple networks into groups or blocks, which the router, in turn, treats as one big network (route summarization or route aggregation). For instance instead of having to store 10 Class C network addresses (any multiple number of smaller classful networks) the router can store a single CIDR-based network address. CIDR implementations do not try to solve this problem. The eventual adoption of IPv6 is the answer to a much larger addressing space. VLSM is used to set the boundary between host ID and network.
22
Variable Length Subnet Masks (VLSM) CIDR leverages Variable Length Subnet Masks (VLSM) and provides the ability allocate address space based on the organizational needs of a customer. VLSM is classically understood as subnetting a subnet It provides for partitioning a larger address block into smaller blocks or subnets using multiple variable length subnet masks. In the use case of larger ISPs they are then able to allocate variable length address space based on customers organizational need since they own the overall larger block and all routing traffic passes back through them to the Internet. VLSM allows for subnets to be defined with different subnetwork sizes as needed under a single Network ID, thereby minimizing, if not eliminating, wasted addresses. Subnetting To begin we will use a fairly easy subnetting example for a traditional class C network 192.168.1.100 255.255.255.192 The chart below shows the decimal and binary values
Figure 9: Subnetting
How many subnet bits are there? - 2 (most significant) bits from the 4th octet (27 or 128 + 26 or 64 = 192) How many Host ID bits are left? - 6 bits To determine the # of possible (sub) networks take the # of subnet bits to the power of 2 - In this case 22 = 4 possible (sub) networks - Remember there is only 1 possible network with the default subnet mask of 255.255.255.0 To determine the # of possible host addresses per subnetwork take the # of Host ID bits to the power of 2 and then subtract 2 for the network and broadcast addresses for the subnetwork - In this 26 - 2 = 64. 64 - 2 = 62 possible host addresses per subnetwork - It is important to note when subnetting each subnetwork created has an identical number of host ID space created. In this example we can use up to 4 subnetworks and each subnetwork has a possible of 62 unique host addresses that can be deployed.
23
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 to be chosen. The lowest value administrative distance is the one that will be stored in the routing table.
Route Type Directly connected Static External BGP (eBGP) OSPF RIP Internal BGP (eBGP) 0 1
Administrative Distance
20 110 120 200
Table 1: Default Routing Administrative Distances
Routed Protocols A list of some routed protocols: IPX IP - SMTP - SNMP - Telnet
24
OSPF
Areas Routers in OSPF are split into different groups called areas. The purpose is to reduce traffic and CPU load. The area that is the most restrictive will use the least resources (CPU and memory). Areas may be organized in any way that makes the most sense for a particular network. Areas get assigned numbers on the range of 14,294,967,295. Enabling OSPF logging is good for troubleshooting. Area Types: Area 0 - Backbone - A required area to which all other areas must connect Ordinary or standard area (Normal or transit area) - All routers in a OSPF area have the same topological database, but their routing tables will be based on the routers position in the area and will thus be unique to the router Stub area - An area that does not accept external routes but will accept routes from within the same 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 - IThis area wont accept routes from any other area. The ABR advertises 0.0.0.0/0 instead. An OSPF AS can be divided into multiple Areas. The propagation of Types 1 and 2 Link State advertisements is limited to the bounds of an area. The propagation of Types 1 and 2 Link State advertisements is limited to the bounds of an area. An OSPF router can be a member of multiple areas. These routers are known as Area Border Routers (ABRs). Each ABR maintains a separate topological database for each area the router is in. Each topological database contains all of the LSAs within a given area. The routers within the same area have identical topological databases. The ABR is responsible for forwarding routing information or changes between its border areas. An Autonomous System Boundary Router (ASBR) is a router that is running multiple protocols and serves as a gateway to routers outside an AS. The ASBR is able to import and translate different protocols routes into OSPF through a process known as redistribution. 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, 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.
25
The use of Type 1 metrics assumes that in the path from the OSPF router to the destination, the internal OSPF AS component (path to the ASBR advertising the AS-external-LSA) and external component are of the same importance. In Type 2 metrics, it is assumed that only the external component is more significant than the internal component. The aggregate cost to these external destinations does not change when viewed from different routers, since the internal costs are not important. But the cost of Intra-area and Inter-area destinations does change depending on which router the cost is observed. The aggregate cost to these external destinations does not change when viewed from different routers, since the internal costs are not important. But the cost of Intra-area and Inter-area destinations does change depending on which router the cost is observed. Designated Routers In order to minimize the amount of information exchange on a particular segment, OSPF elects one router to be a designated router and one router to be a backup designated router on each multi access segment. The idea behind this is that routers have a central point of contact for information exchange. Instead of each router exchanging updates with every other router on the segment, every router will exchange the information with the DR and BDR. The DR and BDR will relay the information to everybody else. The adjacency building process takes effect after multiple stages have been fulfilled. Routers that become adjacent will have the exact link state database. Designated Router (DR) Election is done by selecting the neighboring router with the highest priority. The router with the next largest priority is elected as the Backup DR (BDR). If the DR goes off line, the BDR 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.
1. 2.
3.
The Router ID can be manually configured using the global command ip router-id x.x.x.x If the Router ID is not manually configured, the IP address configured on the lowest numbered loopback interface will be used as the Router ID 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. 2. 3.
An interface is in a waiting state and the wait time expires An interface is in a waiting state and a hello packet is received that addresses the BDR A change in the neighbor state occurs, such as, a neighbor state transitions from 2 or higher, communication to a neighbor is lost, or a neighbor declares itself to be the DR or BDR for the first time
LSA Types Link State Advertisements (LSAs) communicate the router's local routing topology to all other local routers in the same OSPF area.
26
LSA Types (by type code) 1 - Router LSA 2 - Network LSA 3 - Network summary LSA 4 - ASBR Summary LSA 5 - AS External LSA 6 - Group Membership LSA 7 - NSSA External LSA 8 - External Attributes LSA 9 - Opaque LSA (link-local scope) 10 - Opaque LSA (area-local scope) 11 - Opaque LSA (AS scope)
BGP (Border Gateway Protocol)

What is BGP? BGP is an inter-Autonomous System (AS) routing protocol between exactly two routers Defined in RFC 1771; performs loop-free inter-AS routing Once a TCP handshake is completed, BGP places a router in an established state BGP is a Path Vector Protocol to learn shortest route (path) to a network in another AS BGP rides on top of TCP - port 179
Injecting Routes Into BGP The BGP route table is empty until routes are injected into it from the network command or with the BGP redistribution command. BGP Connectivity Maintenance Once a BGP connection is established using OPEN messages, BGP peers will initially use UPDATE messages to send each other a large amount of routing information. They will then settle into a routine, where the BGP session is maintained, but UPDATE messages are sent only when needed. Since these updates correspond to route changes, and route changes are normally infrequent, this means many seconds may elapse between receipt of consecutive UPDATE messages. While a BGP peer is waiting to hear the next UPDATE message, it remains on hold. To keep track of how long it has been on hold, each BGP device maintains a special hold timer. To ensure that the timer doesn't expire even when no UPDATEs need to be sent for a long while, each peer periodically sends a BGP KEEPALIVE message. The name says it all: the message just keeps the BGP connection alive. The rate at which KEEPALIVE messages is sent is implementation-dependent, but the standard recommends that they be sent with an interval of one-third the value of the hold timer. So if the hold timer has a value of three seconds, each peer sends a KEEPALIVE every second (unless it needs to send some other message type in that second). To prevent excess bandwidth use, KEEPALIVEs must be sent no more often than once per second, so that is the minimum interval even if the hold timer is shorter than three seconds.
27
Multicast Routing
PIM Sparse Mode Brocade devices support Protocol Independent Multicast (PIM) Sparse version 2. PIM Sparse provides multicasting that is especially suitable for widely distributed multicast environments. The Brocade implementation is based on RFC 2362. In a PIM Sparse network, a PIM Sparse router that is connected to a host that wants to receive information for a multicast group must explicitly send a join request on behalf of the receiver (host). Traffic is optimized for a wide distribution. PIM Sparse routers are organized into domains. A PIM Sparse domain is a contiguous set of routers that all implement PIM and are configured to operate within a common boundary. Switches that are configured with PIM Sparse interfaces also can be configured to fill one or more of the following roles: - PMBR A PIM switch that has some interfaces within the PIM domain and other interface outside the PIM domain. PMBRs connect the PIM domain to the Internet. - BSR The Bootstrap Router (BSR) distributes RP information to the other PIM Sparse switches within the domain. Each PIM Sparse domain has one active BSR. For redundancy, you can configure ports on multiple switches as candidate BSRs. The PIM Sparse protocol uses an election process to select one of the candidate BSRs as the BSR for the domain. The BSR with the highest BSR priority (a user-configurable parameter) is elected. If the priorities result in a tie, then the candidate BSR interface with the highest IP address is elected. - RP The RP is the meeting point for PIM Sparse sources and receivers. A PIM Sparse domain can have multiple RPs, but each PIM Sparse multicast group address can have only one active RP. PIM Sparse switches learn the addresses of RPs and the groups for which they are responsible from messages that the BSR sends to each of the PIM Sparse switches. To enhance overall network performance, Brocade Layer 3 Switches use the RP to forward only the first packet from a group source to the groups receivers. After the first packet, the Layer 3 Switch calculates the shortest path between the receiver and source (the Shortest Path Tree, or SPT) and uses the SPT for subsequent packets from the source to the receiver. The Layer 3 Switch calculates a separate SPT for each source-receiver pair. By default, when a multicast packet is received on a PIM-capable router interface in a multi-path topology, the interface checks its IP routing table to determine the shortest path back to the source. If the alternate paths have the same cost, the first entry in the IP routing table is picked as the path back to the source. When choosing the RPF, the router first checks the Multicast Routing Table. If the table is not available, it chooses an RPF from the IP Routing Table.
28
Mapping IP Multicast to a MAC Address To map an IP Multicast address to the corresponding Hardware/Ethernet multicast address, place the loworder 23 bits of the IP multicast address into the low-order 23 bits of the special Ethernet multicast address. 01-00-5e is reserved for multicast. If the IP address is 239.6.30.5 the corresponding MAC address would result in: 01-00-5e-06-1e-05.
Figure 10: IP Multicast Mapping
29
5 - 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
Access Control Lists Permit or deny access to network devices; forward or drop packets ACL Types: - Standard (ACL 1-99) o Permits or Denies packets based on source IP address o Configured with the access-list command - Extended (ACL 100-199) o Permits or Denies packets based on source and destination IP addresses, TCP/UDP ports, or protocol number/name o Configured with the access-list command ACL entries are applied to data packets in the order that they are listed. Therefore, you need to choose this entry order for a desired outcome. 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 ACLs are executed sequentially, from top to bottom Generally, 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 will be automatically denied. If you can, try to apply ACLs Inbound rather than Outbound - Inbound ACL behavior: First instance of a TCP or UDP packet is handled by the ASIC rather than the CPU Enabling access list logging will impact the CPU
30
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. 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. QoS Options for 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 063 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. - 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 packets DSCP value. This option does not change the packets forwarding priority through the device or mark the packet. ACL-Based Rate Limiting ACL-based rate limiting provides the facility to limit the rate for IP traffic that matches the permit conditions in extended IP ACLs. This feature is available in the Layer 2 and Layer 3 code.
31
6 - Quality of Service (QoS) Concepts

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, to cause 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 to other traffic types. 802.1p The 802.1p priority is also called the Class of Service (CoS), and uses a 3-bit field There is support for up to 8 priority levels (0-7) with 7 being the highest It is not preserved end-to-end Trust levels can be one of the following: - Static MAC address - Ingress port default priority - ACL keyword
Marking Marking is the process of changing the packets QoS information (the 802.1p and DSCP information in a packet) for the next hop. For example, for traffic coming from a device that does not support DiffServ, you can change the packets IP Precedence value into a DSCP value before forwarding the packet. You can mark a packets Layer 2 CoS value, its Layer 3 DSCP value, or both values. The Layer 2 CoS or DSCP value the device marks in the packet is the same value that results from mapping the packets QoS value into a Layer 2 CoS or DSCP value. Marking is optional and is disabled by default. Marking is performed using ACLs. When marking is not used, the device still performs the mappings listed in Classification for scheduling the packet, but leaves the packets QoS values unchanged when the device forwards the packet.
32
7 - Wireless Concepts
Wireless Protocols
802.11b Channels 802.11 divides each of its bands into channels, similar to how the radio and TV broadcast bands are allocated, but with greater channel width and overlap. There are only 3 non-overlapping channels available in the 802.11b standard.These are Channels 1,6, and 11. For WiFi access points that are located near each other it is recommended that they each use one of the above non-overlapping channels to minimize the effects of interference. The following graphic is used with permission from the Creative Commons website:
Figure 11: 802.11b Spectrum
ESSIDs An extended service set ID (ESSID) identifies a WLAN with which clients can establish a connection. The Brocade IronPoint Mobility Series provides multiple configuration options for managing the traffic, security, and service requirements that are needed by the enterprise. You can configure: a VLAN that supports multiple access points per ESSID multiple ESSIDs per physical access point a VLAN for each ESSID to separate network traffic and can also specify that a VLAN be shared between multiple ESSIDs an ESSID that supports just one person an ESSID for Remote AP, such as in a branch office, and that AP can also support ESSIDs for local traffic Typically, a wireless LAN supports one beacon on a single BSSID, which can advertise the primary ESSID. Clients can request to associate to that BSSID by requesting one of the ESSIDs. The Brocade IronPoint Mobility Series allows you to customize a beacon per ESSID to support different access point settings, such as base or supported transmit rates, different BSSIDs, different beacon intervals, and different DTIM periods. This beacon customization allows service customization for each ESSID, as well as more flexibility in supporting different clients and services.
33
802.11i Brocade IronPoint Mobility Series supports both WPA2 and WPA protocols that have been presented by the WiFi Alliance as interim security standards that improve upon the known vulnerabilities of WEP until the release of the 802.11i standard. In WPA2, the WPA Message Integrity Code (MIC) algorithm is replaced by a message authentication code, CCMP, that is considered fully secure and the RC4 cipher is replaced by the Advanced Encryption Standard (AES), as described in CCMP-AES. WPA includes the encryption protocol TKIP (see TKIP) and leverages existing 802.1X authentication, including the dynamic key management facility. If 802.1X authentication is not available (in a SOHO, for example), WPA2-Personal or WPA-Personal can be implemented as alternatives and provide for manual key distribution between APs and clients. 802.1X Authentication For enterprise wireless security to scale to hundreds or thousands of users, an authentication framework that supports centralized user authentication must be used in addition to the encryption type specified by 802.11, WEP, or by using WPA/WPA2 , which incorporates TKIP/CCMP-AES and 802.1X authentication. The use of IEEE 802.1X offers an effective framework for authenticating and controlling user traffic to a protected network, as well as dynamically varying encryption keys if WPA/WPA2 is configured. 802.1X ties a protocol called EAP (Extensible Authentication Protocol) to both the wired and wireless LAN media and supports multiple authentication methods, such as token cards, Kerberos, one-time passwords, certificates, and public key authentication. There are three basic pieces to 802.1X authentication:
1. 2. 3.
Supplicanta software client running on the wireless station Authenticatorthe access point and the controller Authentication Serveran authentication database, usually a RADIUS server such as Cisco ACS, Microsoft IAS or Funk (Juniper) Odyssey.
Extensible Authentication Protocol (EAP) is used to pass the authentication information between the supplicant (the wireless station) and the authentication server (RADIUS, MS IAS, or other). The actual authentication is defined and handled by the EAP type. The access point (and the controller in the configuration) acts as the authenticator. The authenticator is a client of the RADIUS server that allows the supplicant and the authentication server to communicate. The EAP type you choose, and whether you choose to implement authentication in your organization, depends on the level of security you require. EAP-TLS EAP-PEAP EAP-TTLS Cisco LEAP
34
8 - Network Security, Management and Monitoring

Network Monitoring
Restricting Remote Access to the Device to Specific VLAN IDs You can restrict management access to a Foundry device to ports within a specific port-based VLAN. VLANbased access control applies to the following access methods: Telnet access Web management access SNMP access TFTP access
By default, access is allowed for all the methods listed above on all ports. Once you configure security for a given access method based on VLAN ID, access to the device using that method is restricted to only the ports within the specified VLAN. Syslog Messages A Brocade devices software can write syslog messages to provide information at the following severity levels: Emergencies Alerts Critical Errors Warnings Notifications Informational Debugging
The device writes the messages to a local buffer. The buffer can hold up to 1000 entries. You also can specify the IP address or host name of up to six Syslog servers. When you specify a Syslog server, the Brocade device writes the messages both to the system log and to the Syslog server. Using a Syslog server ensures that the messages remain available even after a system reload. The Brocade devices local Syslog buffer is cleared during a system reload or reboot, but the Syslog messages sent to the Syslog server remain on the server. By default, to view Syslog messages generated by a Brocade device, you need to display the Syslog buffer or the log on a Syslog server used by the Brocade device. You can enable real-time display of Syslog messages on the management console. When you enable this feature, the software displays a Syslog message on the management console when the message is generated. However, to enable display of real-time Syslog messages in Telnet or SSH sessions, you also must enable display within the individual sessions.
35
To enable real-time display of Syslog messages, enter the following command at the global CONFIG level of the CLI: FastIron(config)#logging console sFlow Configuration Considerations FastIron devices support sFlow packet sampling of inbound traffic only. These devices do not sample outbound packets. However, FastIron devices support byte and packet count statistics for both traffic directions. sFlow is supported on all Ethernet ports (10/100, Gigabit, and 10 Gigabit) Enabling sFlow may cause a slight and noticeable increase of up to 20% in CPU utilization. In typical scenarios, this is normal behavior for sFlow, and it does not affect the functionality of other features on the switch. The sampling rate is the average ratio of the number of packets incoming on an sFlow enabled port, to the number of flow samples taken from those packets. sFlow sampling can affect performance in some configurations. Note that on the FastIron devices, the configured sampling rate and the actual rate are the same. The software does not adjust the configured sampling rate as on other Brocade devices. sFlow and multicast packets are forwarded by default on a Brocade switch The sampling rate is a fraction in the form 1/N, meaning that, on average, one out of every N packets will be sampled. The sflow sample command at the global level or port level specifies N, the denominator of the fraction. Thus a higher number for the denominator means a lower sampling rate since fewer packets are sampled. Likewise, a lower number for the denominator means a higher sampling rate because more packets are sampled. For example, if you change the denominator from 512 to 128, the sampling rate increases because four times as many packets will be sampled. Brocade recommends that you do not change the denominator to a value lower than the default. Sampling requires CPU resources. Using a low denominator for the sampling rate can cause high CPU utilization. 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 assigning a port from which to copy all packets, and a mirror port where the copies of the packets are sent (also known as the monitor port). A packet received on, or issued from, the first port is forwarded to the second port as well. 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. 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
36
Network Management
Console Port The first step in configuring your Brocade device is to connect a console cable (typically shipped with your device) to the serial port. You can then use the CLI (command line interface) to assign an IP address. After you assign an address, you can access the system through Telnet, the Web management interface, or Iron View. In order to attach a management station using the serial port, connect a PC or terminal to the serial port using a straight through cable. You will need a serial interface on your computer or a DB9-to-USB converter to be able to access the switch. The serial port has a male DB-9 connector. You will need a straight-through (female-tofemale) cable. You need to run a terminal emulation program such as Hyperterm or Procomm plus on the PC. The session parameters should be set to Baud: 9600, Data Bits: 8, Parity: none, Stop Bits: 1 and Flow control: none. For a modem connection, you must use a cross-over cable (typically a DB-9F-to-DB25F cable). SNMP SNMP is a set of protocols for managing complex networks. SNMP sends messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves in Management Information Bases (MIBs) and return this data to the SNMP requesters. SNMP management access may be controlled, or restricted, by using a VLAN or ACLs.
Applying Security
Restricting Remote Access By default, a Brocade device does not control remote management access based on the IP address of the managing device. You can restrict remote management access to a single IP address for the following access methods: Telnet access SSH access Web Management access SNMP access
SNMP and Web Management use community strings for authentication. In addition, you can restrict all access methods to the same IP address using a single command. Some examples: FastIron(config)#telnet-client 209.157.22.39 to restrict Telnet FastIron(config)#ip ssh client 209.157.22.39 to restrict SSH FastIron(config)#web-client 209.157.22.39 to restrict Web Management FastIron(config)#snmp-client 209.157.22.39 to restrict SNMP FastIron(config)#all-client 209.157.22.39 to restrict all
To restrict access using ACLs the command is basically the same for all, except for the modifier before the access group. An example for Telnet:
37
FastIron(config)#access-list 10 deny host 209.157.22.32 log FastIron(config)#access-list 10 deny 209.157.23.0 0.0.0.255 log FastIron(config)#access-list 10 deny 209.157.24.0 0.0.0.255 log FastIron(config)#access-list 10 deny 209.157.25.0/24 log FastIron(config)#access-list 10 permit any FastIron(config)#telnet access-group 10 FastIron(config)#write memory To allow Telnet access to the device, you must first issue the telnet server command. If you wish to allow SSHv2 access, additionally, you must generate a Crypto Key. That is done with the crypto key generate command. In addition, you must use AAA authentication to create a password to allow SSHv2 access. Levels of CLI Commands The commands in the CLI are organized into the following levels: User Lets you display information and perform basic tasks such as pings and traceroutes - View basic information - Verify connectivity (ping command) Privileged Lets you use the same commands as those at the User level plus configuration commands that do not require saving the changes to the system-config file - Enter through the enable command - Can be password protected - View detailed information (show commands) - Execute system-wide features CONFIG Lets you make configuration changes to the device. To save the changes across reboots, you need to save them to the system-config file. The CONFIG level contains sub-levels for individual ports, for VLANs, for routing protocols, and other configuration areas. - Enter through the configure terminal command - Make global or local system changes (VLANs) - Save changes with the write memory command You can tell which level of the command hierarchy that you are currently at by looking at the system prompt. User = > Privileged = # CONFIG = (config)#
38
Securing CLI There are 5 ways to secure access to the Privileged EXEC and CONFIG levels of CLI: Establish a password for Telnet access to the CLI Establish passwords for management privilege levels Set up local user accounts Configure TACACS/TACACS+ security Configure RADIUS security
Maintenance Procedures
Switch and Router show Commands show show show show show show show show show show show show version - software version, uptime and last reload interface brief - interface status stat - interface statistics ip - IP address and mask information span - spanning tree information mac-address - MAC forwarding table mac-address stat - # of MACs learned per port flash - flash memory images vlan - configured VLANs telnet - IP address(es) of active telnet session(s) trunk - configured and active trunk groups tech-support - details for assistance in troubleshooting when working with Support
File Management The flash memory is divided into two different storage areas. This allows you to have two different software image versions stored in the flash memory. Secondary Flash is storage space for Upgrade Code: Put new code in the secondary flash Schedule a reload to boot on secondary flash during low traffic periods. Unsuccessful reloads will cause the system to revert back to primary flash. When confidence is established in upgrade code, execute a copy flash flash primary to overwrite old software image with upgrade image in primary flash This command will copy the system image in the primary flash to the TFTP server: - FastIron# copy flash tftp 192.22.33.44 vm1r07501.bin primary - Any failure might indicate the presence of something in the secondary flash
39
9 - Troubleshooting
Tools and Techniques
Reasons For Ping Failures Pings could fail because a host is unreachable A route to the target is unavailable An ARP for the default gateway could not be resolved The default gateway does not exist
Reasons For OSPF Neighbor Establishment Failures Different areas Different dead-intervals Different authentication passwords Collisions An increasing collision rate (number of packets output divided by the number of collisions) does not indicate a problem: it is merely an indication of a higher offered load to the network. An example of this could be because another station was added to the network. Excessive collisions indicate a problem. Common causes are devices connected as full-duplex on a shared Ethernet, broken NICs, or simply too many stations on the shared medium. The excessive collisions can be resolved by hardcoding speed and duplex. Gathering Data As previously mentioned, the show tech command is extremely useful in gather data for an escalated support call. The more information you can provide up front, the more likely a faster resolution is possible.
40
Analyzing Troubleshooting Output

RSTP (802.1w) Port Descriptions Forwarding Ports Root port - port having the best path to the root switch Designated port - on a given link, it is the port having the superior BPDU Edge port - a special type of designated port. It is a port that has been identified via manual configuration as being at the edge of the network, and hence, comes up immediately as a designated port. Blocking Ports Alternate port - a port that is not a root port, and can not be a designated port, because it is receiving a superior BPDU from another switch Backup port - a port that is not a root port, and can not be a designated port, because it is receiving a superior BPDU from its own switch Disabled port - a port not controlled by RSTP either because it is down, administratively down, or administratively removed from RSTP Displaying the IP Route Table FastIron#show ip route Total number of IP routes: 514 Start index: 1 B:BGP D:Connected R:RIP S:Static O:OSPF *:Candidate default Destination 1.1.0.0 1.2.0.0 1.3.0.0 NetMask 255.255.0.0 255.255.0.0 255.255.0.0 Gateway Port Cost Type 2 2 2 R R R 99.1.1.2 1/1 99.1.1.2 1/1 99.1.1.2 1/1
If there is no destination or netmask displayed the route may have been learned.
41
Taking the Test

After the Introduction Screen, once you click on Next (N), you will see the Non-Disclosure agreement:
Figure 12: Sample NDA
42
Once you agree to the Non-Disclosure terms, the timed exam will begin. This is a sample of how the questions will look. In this example, you see a multiple-choice question.
Figure 13: Sample Question
43
This is a sample of the score sheet you will see at the end of the exam. You also see the breakdown of how many questions there are in each section of the exam. A hard copy of this will be printed at the testing center. It is vital that you obtain and save this hard copy as proof and validation.
Figure 14: Example Exam Score Report
44

BCNE Nutshell

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

Transféré par

Droits d'auteur :

Formats disponibles

BCNE in a Nutshell Study Guide for Exam 150-120

Exam Preparation Materials

Revision September 2009

BCNE in a Nutshell First Edition

BCNE in a Nutshell First Edition

Helen Lautenschlager Director of Education Solutions

Joe Cannata Certification Manager

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCFD in a Nutshell 8 Gbit/sec Edition

2008 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell FIrst Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

1 - Layer 1/Hardware Concepts

Figure 1: MAC Address Inside an Ethernet Frame

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

Implementing Hardware Platforms and Features

2009 Brocade Communications

BCNE in a Nutshell First Edition

2 - Layer 2 Switching and Protocols

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

Figure 3: Switch Frame Forwarding Methods

2009 Brocade Communications

BCNE in a Nutshell First Edition

Figure 4: VLAN Tagging

2009 Brocade Communications

BCNE in a Nutshell First Edition

Figure 5: 802.1Q Tagging (Packet Format)

2009 Brocade Communications

BCNE in a Nutshell First Edition

Link Aggregation Implementations

2009 Brocade Communications

BCNE in a Nutshell First Edition

Figure 6: Dynamic Trunks

2009 Brocade Communications

BCNE in a Nutshell First Edition

3 - General Layer 2/Layer 3 Concepts

Figure 7: Ethernet Frame Format

2009 Brocade Communications

BCNE in a Nutshell First Edition

Figure 8: Default Routes

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications

BCNE in a Nutshell First Edition

2009 Brocade Communications