BCNE Nutshell

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

Brocade University

Revision 0912

Corporate Headquarters - San Jose, CA USAT: (408) [email protected]

European Headquarters - Geneva, SwitzerlandT: +41 22 799 56 [email protected]

Asia Pacific Headquarters - SingaporeT: [email protected]

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

Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, MLX, SAN Health, VCS, and VDX are registered trademarks, and AnyIO, Brocade One, CloudPlex, Effortless Networking, ICX, NET Health, OpenScript, and The Effortless Network are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be trademarks of their respective owners.

Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability.Export of technical data contained in this document may require an export license from the United States government.

Revision 0912

©2012 Brocade Communications i

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Objective: The BCNE 2012 Nutshell guide is designed to help you prepare for the BCNE 2012 Certification, exam number 150-130.

Audience: The BCNE 2012 Nutshell self-study guide is intended for those who have successfully completed the CNE 200 Brocade Certified Network Engineer Training course, and who wish to undertake self-study or review activities before taking the actual BCNE 2012 exam. The BCNE 2012 guide is not intended as a substitute for classroom training or hands-on time with Brocade products.

How to make the most of the BCNE 2012 guide: The BCNE 2012 guide summarizes the key topics on the BCNE 2012 exam for you in an easy to use format. It is organized closely around the exam objectives. We suggest this guide be used in conjunction with our free online knowledge assessment test. To benefit from the BCNE 2012 guide, we strongly recommend you have successfully completed the CNE 200 Brocade Certified Network Engineer Training course.

We hope you find this useful in your journey towards BCNE 2012 Certification, and we welcome your feedback by sending an email to [email protected].

Joe Cannata

Certification Manager

Introduction to BCNE 2012 in a Nutshell First Edition


ii ©2012 Brocade Communications

©2011 Brocade Communications iii

Brocade Certified Network Engineer in a Nutshell Second Edition

Table of Contents

1 — Layer1 Hardware Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Physical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Coaxial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Twisted Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Fiber Optic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Form Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

POE/POE+. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Detection of PoE Power Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

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

Hardware Platform Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Brocade IronStack features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Brocade IronStack topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

MCT Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Multi-Chassis Trunking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 — Layer 2 Switching and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Enabling or Disabling Layer 2 Switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Layer 2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Bridge Protocol Data Units (BPDUs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Fast Port Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Root Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15BPDU Guard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15ACL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15IGMP Snooping Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15802.1W Rapid Spanning Tree (RSTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Device Discovery Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Virtual Local Area Network Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17802.1Q Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18802.1q-in-q tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19VLAN CPU Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Link Aggregation Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21LAG Formation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

iv ©2011 Brocade Communications


4 — General Layer 2 and Layer 3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24End-to-End Packet Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Private Networks (RFC 1918) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Designated Router (DR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Neighbor Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31OSPFs Four Level Routing Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Loopback Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Link State Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Mapping of IPv4 Multicast Group Addresses to Ethernet MAC Addresses . . . . . . . . . . . . . . . . . . . . . 34IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35IPv6 Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

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

5 — Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40General Routing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Defining a Default Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Classless Inter-Domain Routing (CIDR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Static IP route parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Link State vs. Distance Vector (OSPF vs. RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Supported Layer 3 multicast routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 — Access Control List (ACL) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46ACL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Default ACL Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Standard Named ACL syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Policy-Based Routing (PBR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Configuring a PBR policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 — Quality of Service (QoS) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50QoS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50QoS for Brocade Stackable Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50QoS Queueing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Qos-tos trust and qos-tos mark Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Recognizing Inbound Packet Priorities and Mapping to Internal Priority . . . . . . . . . . . . . . . . . . . . . . . 51QoS Options for IP ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52802.1p Priority Override. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

©2011 Brocade Communications v


8 — Network Security, Management and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Network Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53sFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Port Mirroring and Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54SNMP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

SNTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Applying Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Setting the SSH port number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

TACACS+ versus TACACS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Maintenance Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Loading and Saving Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56File Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Password Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9 — Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Contacting Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58supportsave Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

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

Viewing Optical Monitoring Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Recovering Disabled Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60IP Packet Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60802.1x Debug Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Protocol Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

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

vi ©2011 Brocade Communications


©2012 Brocade Communications vii


List of Figures

SFP Side View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2MCT Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Root Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Fast Port Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14Types of VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18VLAN Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19802.1Q Tagging (Packet Format) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19SAV Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20802.1 Q-in-Q Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24End-to-End Flow Example 1 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25End-to-End Flow Example 2 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26End-to-End Flow Example 3 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27End-to-End Flow Example 4 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28OSPF DR Election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31OSPF AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32VRRP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Multiple VRRP-E Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Supernetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Standard ACL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Policy-based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59


viii ©2012 Brocade Communications

©2012 Brocade Communications ix


List of Tables

Optics Comparison Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2IEEE 802.23a PoE and 802.23at PoE+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3FCX Series: Data Center vs. Campus Offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5RFC 1918 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Classful versus Classless Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Default Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Support SNMP Access Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59802.1x Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61


x ©2012 Brocade Communications

©2012 Brocade Communications 1


1 — Layer1 Hardware ConceptsUpon completing this section you should be able to identify physical media and describe how to implement POE/POE+.

Physical MediaPhysical media are the physical devices that transmit raw bits across a network. They include, but are not limited to the following:

• Cabling

• Transceivers

CoaxialThe coaxial cable has one thin strand of copper in the middle of it, surrounded by quite a bit of insulation. This is surrounded by an additional meshwork of copper, which is, in turn, surrounded by more insulation. This cable is designed to carry an electrical signal.

Twisted PairThe most common medium is called twisted pair. This comes in many varieties. On the high level, there's Unshielded Twisted Pair (UTP) and Shielded Twisted Pair (STP). STP is expensive, and the shielding can make it difficult to bend or shape. On the other hand, the additional shielding does a better job of preventing outside interference. UTP is the most common.

STP and UTP come in different grades called categories. Some of the most common categories include category 3, category 5, category 5e, and category 6. These are most commonly abbreviated to CAT3, CAT5, CAT5e, and CAT6. CAT5 uses thicker cables inside than CAT3. It also has more twists per meter. Likewise with CAT5e and CAT6, the higher the number, the thicker the copper cables and the more twists per meter. Also, the higher the category, the greater the performance. CAT3 is only rated for 10 Mbps Ethernet, while CAT5e and CAT6 are required for Gigabit.

Fiber OpticIf you need lengths of cables much longer than 100 meters or your facility has a lot of EMI, use fiber. The major advantages with fiber are its attenuation limit (up to 70 km) and, because it uses light rather than electricity, it is invulnerable to EMI. It can achieve much greater speeds than its copper counterparts. The current maximum is 40 Gbps, but this is only limited by technology.

The cables are made by combining fiber optic strands and insulating them. A laser light generates the signal. The more powerful the laser, the longer the attenuation limit. There are two varieties you need to be familiar with:

• Multimode Fiber (MMF)

- 1000 Mbps (SX) attenuation: 550 meters

- 10 Gbps (SR) attenuation: 300 meters


2 ©2012 Brocade Communications

• Single-mode Fiber (SMF)

- 1000 Mbps (LX) attenuation: 5 km

- 1000 Mbps (LHA) attenuation: 70 km

- 10 Gbps (LR) attenuation: 10 km

- 10 Gbps (ZR) attenuation: 70 km

Form FactorsThe Small Form-factor Pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communication applications. It interfaces a network device motherboard (for a switch, router, media converter, or similar device) to a fiber optic or copper networking cable. It is a popular industry format. SFP transceivers are designed to support SONET, Gigabit Ethernet (GbE), Fibre Channel (FC), and other communications standards.

The standard covers SFP+ supporting data rates up to 10 Gbps (includes 8 Gbps Fibre Channel and 10 GbE). The SFP+ has a smaller form factor than a regular SFP. If copper is required 1000 Mbit TX SFPs could be used on non-combo ports.

Figure 1: SFP Side View

TABLE 1 Optics Comparison Chart

Transceiver Type Supported Speeds Cable Type Used Distance at Max Speed1

1. The distance shown in this chart represents the maximum distance, with high quality cabling, that is available at the maximum line speed of the transceiver. Distances can actually be increased beyond what is listed by reducing transmission speed. For a full list of supported distances, speeds, and cable types for any transceiver please visit our web site: http://www.brocade.com/products/all/transceivers/product-details/transceiver-modules/features.page.

4 Gbps SWL SFP

4, 2, 1 Gbps

OM1/OM2/OM3 380 m

4 Gbps LWL SFPSinge-mode

10 km

4 Gbps ELWL SFP 30 km

8 Gbps SWL SFP OM1/OM2/OM3 150 km

8 Gbps LWL SFP 8, 4, 2 GbpsSingle-mode

10 km

8 Gbps ELWL SFP 25 km

10 Gbps SWL SFP+ OM1/OM2/OM3 300 km

10 Gbps LWL SFP+ 10 Gbps Single-mode 10 km

16 Gbps SWL SFP+ OM1/OM2/OM3 100 km

16 Gpbs LWL SFP+ 16 Gpbs Single-mode 10 km

4x16 Gbps SWL QSFP MPO 1x12 ribbon2

2. The 4x16 Gbps QSFP is currently only used on the DCX8510-4 and DCX 8510-8 Backbone switches for ICL links between chas-sis. These switches will be covered in greater detail in the next module.

50 km



The XFP is a 10 GbE small form factor pluggable transceiver for use with optical fiber. XFPs are protocol independent and used in Ethernet devices.

The following form factors are supported by Brocade switches and routers:

• SFP

• SFP+

• XFP

POE/POE+When PoE is enabled on a port to which a power consuming device or PD is attached, by default, a Brocade PoE device will supply 15.4 watts of power at the RJ-45 jack, minus any power loss through the cables. A PoE+ device will supply either 15.4 or 30 watts of power (depending on the type of PD connected to the port), minus any power loss through the cables. For example, a PoE port with a default maximum power level of 15.4 watts will receive a maximum of 12.95 watts of power after 2.45 watts of power loss through the cable.

To configure the maximum power level for a power consuming device, enter commands such as the following:

Brocade#configure terminalBrocade(config)# interface ethernet 1/1Brocade(config-if-e1000-1/1)# inline power power-limit 14000

These commands enable in-line power on interface ethernet 1 in slot 1 and set the PoE power level to 14,000 milliwatts (14 watts).

Syntax: inline power power-limit <power level>

The <power level> variable is the maximum power level in number of milliwatts. The following values are supported:

• PoE: Enter a value from 1000 through 15,400. The default is 15,400.

• PoE+: Enter a value from 1000 through 30,000. The default is 30,000.

Table 2 provides a side-by-side comparison of PoE nad PoE+.

TABLE 2 IEEE 802.23a PoE and 802.23at PoE+

Feature 802.23af PoE 802.23at PoE+

Cable requirement CAT3 or CAT5 Type1: CAT3Type2: CAT5/5e

PSE current (A) 0.35 Type1: 0.35Type2: 0.60

PSE voltage (Vdc) 44-57 Type1: 44-57Type2: 50-57

PD current (A) 0.35 Type1: 0.35Type2: 0.60

PD voltage (Vdc) 37-57 Type1: 37-57Type2: 47-57



Note

The 802.3at standard currently supports POE+ on 10/100/1000 Mbps Ethernet ports operating over standard Category 5 Unshielded Twisted Pair (UTP) cable or better. If your network uses cabling categories lower than 5, you cannot implement PoE+ without first upgrading your cables to CAT 5 UTP or better.

Detection of PoE Power RequirementsThere are two ways for the powered devices to dynamically request the PoE power from the PSE—proprietary protocols such as the Cisco Discovery Protocol (CDP) used by Cisco IP phones or the standard-based Link Layer Discovery Protocol (LLDP) used by variety of IP phones and access points. Brocade switches support both methods but recommend the latter because it does not limit organizations to a single class of powered devices and because LLDP provides a lot of additional features. Some powered devices such as Cisco IP phones use CDP to advertise their power requirements to PSEs such as Brocade’s PoE switches. Brocade PoE switches support such powered devices and can detect and process power requirements for these devices automatically.

The Brocade FastIron PoE switches support IEEE 802.1AB LLDP and ANSI TIA 1057 LLDP-MED standards, enabling organizations to build open-convergence, advanced, multi-vendor networks that enable a variety of PDs to be plugged with Brocade switches. LLDP is a Layer 2 network discovery protocol described in the IEEE 802.1AB standard. This protocol enables a device to advertise its capabilities to and to discover other LLDP-enabled devices in the same 802 LAN segments.

LLDP Media Endpoint Devices (LLDP-MED) is the Layer 2 network discovery protocol extension to LLDP described in the ANSI/TIA-1057 standard. This protocol enables a PoE switch to configure and manage connected powered devices that need to send media streams across the network (for example, IP phones and security cameras). LLDP enables network discovery between network connectivity devices (such as switches), whereas LLDP-MED enables network discovery at the edge of the network, between network connectivity devices and media endpoint devices (such as IP phones).

Maximum PD wattage (W) Class 0, 3: 12.95Class 1: 3.84Class 2: 6.49Class 4: unused

Type1, Class 0, 3: 12.95Type1, Class 1: 3.84Type1, Class 2: 6.49Type2, Class 4: 25.5

PD Classification Requirement Optional 1-Event classification

RequiredType1: 1-event classificationType2: 2-event classification and LLDP

TABLE 2 IEEE 802.23a PoE and 802.23at PoE+

Feature 802.23af PoE 802.23at PoE+



2 — Brocade Hardware PlatformsWhen you have completed this section you should be able to identify Brocade hardware platforms and describe how to implement the platforms and associated features.

Hardware Platforms

ICX 6430 and 6450 Product Overview• Offers enterprise-class stackable switching at an

entry-level price

- Buy what you need now and easily scale as demand grows and new technologies emerge

• Delivers feature/price value for applications including:

- Unified Communications (UC) and mobility, with 10 Gigabit Ethernet (GbE) and PoE/PoE+

• Provides availability for low-cost switching:

- Redundant uplink/stacking ports, hitless stacking failover, and configurable power redundancy

FastIron CX Series• Delivers enterprise-class Layer 2/3 switching in a compact,

stackable form factor

- Combines chassis-like capabilities with an economical fixed-port solution

• Includes IPv4 and IPv6 Layer 3 capabilities as a standard feature on all models

• Provides non-stop availability with:

- Hitless stacking failover

- Hot insertion/removal of stacked units

- Internal redundant hot-swappable power supplies and fans

TABLE 3 FCX Series: Data Center vs. Campus Offerings

Data Center Feature Campus

No PoE Yes (PoE models)

No Stacking ports Yes

4 10 GbE ports 2

SFP+ 10 GbE type XFP

Optional GbE combo ports built-in

Front-to-back (reversible) Airflow Side-to-back



FastIron SX Series• Price/performance value for campus aggregation and core switching

• Provides a scalable, secure, low-latency, and fault-tolerant infrastructure for 1 GbE and 10 GbE enterprise deployments

• High-performance architecture with:

- Up to 128 x 10 GbE and 384 x 1 GbE ports

• Supports IPv4/IPv6- capable Layer 2/3 switching and routing

• Highly available design with:

- Multi-Chassis Trunking (MCT)

- Redundant management modules (with hitless failover)

- Switch fabrics

- Stateful OSPF redundancy; graceful BGP and OSFP restarts; and hitless In-Service Software Upgrades (ISSU)

Brocade VDX 6730 Data Center Switches• 32- and 76-port models with Ports on Demand

(PoD)

• Non-blocking, cut-through architecture, wire-speed

• 600 ns port-to-port latency; 1.8 μs across port groups

• Ethernet storage connectivity for FCoE, iSCSI, and NAS storage

• Multihop FCoE and iSCSI Data Center Bridging (DCB) support

• 10 Gbps and 1 Gbps supported on every LAN port;

• 2,4, and 8 Gbps on FC ports

• Direct-attached copper SFP and SFP optical connectivity options

• Reversible front-to-back airflow

ServerIron ADX Series• Enables high-speed application delivery by leveraging a purpose-built

architecture designed with high core density and embedded application accelerators

• Maximizes investment protection with on-demand capacity for fixed platforms and fully interchangeable modules for chassis platforms

• Accelerates service creation and application deployment via the open and flexible Brocade OpenScript engine

• Simplifies management of highly virtualized and cloud-optimized environments through Brocade Application Resource Broker and extensible SOAP/XML APIs

• Eases the transition to IPv6 with full performance and feature parity between IPv6 and IPv4 as well as scalable, standards-based translation technology



NetIron CER Series• Compact 1U IP/MPLS router purpose-built for high-performance

Ethernet edge routing applications

• Scalable routing and MPLS for advanced business and residential triple-play services

• Scalable compact edge router designed to support a full Internet routing table

• Powered by the field-proven Brocade Multi-Service IronWare OS that also runs on Brocade MLXe Series routers

• Complete suite of IPv4/IPv6 unicast and multicast routing with fast convergence times

• Advanced QoS features to enforce strict SLAs at the edge of the network

NetIron MLXe Series• Scalable multiservice IP/MPLS Carrier Ethernet routers in 4-, 8-, 16-,

and 32-slot options

• Fully distributed, non-blocking architecture with up to 15.36 Tbps fabric capacity

• Wire-speed ports in a single router:

• 1536 x 1 GbE or 256 x 10 GbE or 32 x 100 GbE

• Wire-speed IPv4, IPv6, and MPLS forwarding performance with 1 million IPv4 routes in hardware

• High-availability design with:

- Redundant management modules, switch fabrics; hitless failover; hitless software upgrades; and non-stop routing

Hardware Platform Features

Brocade IronStack featuresA stack is a group of devices that are connected so that they operate as a single chassis. IronStack features include the following:

• Management by a single IP address

• Support for up to eight units per stack. ICX 6430 supports only up to four units in the stack

• Flexible stacking ports

• Linear and ring stack topology support

• Secure-setup utility to make stack setup easy and secure

• Active Controller, Standby Controller, and member units in a stack

• Active Controller management of entire stack

• Active Controller download of software images to all stack units

• Standby Controller for stack redundancy



• Active Controller maintenance of information database for all stack units

• Packet switching in hardware between ports on stack units

• All protocols operate on an IronStack in the same way as on a chassis system

Brocade IronStack topologiesBrocade IronStack technology supports linear and ring stack topologies. Although Brocade stackable units may be connected in a simple linear topology, Brocade recommends a ring topology because it offers the best redundancy and the most resilient operation.

MCT Terminology

Figure 2MCT Components

• MCT peer switches: A pair of switches connected as peers through the ICL. The LAG interface is spread across two MCT peer switches and it acts as the single logical endpoint to the MCT client.

• MCT client: The MCT client is the device that connects with MCT peer switches through an IEEE 802.3ad link. It can be a switch or an endpoint server host in the single-level MCT topology or another pair of MCT switches in a multi-tier MCT topology.



• MCT Inter-Chassis Link (ICL): A single-port or multi-port GbE or 10 GbE interface between the two MCT peer switches. This link is typically a standard IEEE 802.3ad Link Aggregation interface. ICL ports should not be untagged members of any VLAN. The ICL is a tagged Layer 2 link, which carries packets for multiple VLANs. MCT VLANs are the VLANs on which MCT clients are operating. On the Brocade NetIron XMR or Brocade MLX series, non-MCT VLANs can co-exist with MCT VLANs on the ICL. However, on the Brocade NetIron CES and Brocade NetIron CER, only MCT VLANs are carried over ICL.

• MCT Cluster Communication Protocol (CCP): A Brocade proprietary protocol that provides reliable, point-to-point transport to synchronize information between peers. CCP comprises two main components: CCP peer management and CCP client management. CCP peer management deals with establishing, and maintaining TCP transport session between peers, while CCP client management provides event-based, reliable packet transport to CCP peers.

• MCT Cluster Client Edge Port (CCEP): A physical port on one of the MCT peer switches that is a member of the LAG interface to the MCT client. To have a running MCT instance, at least one Link Aggregation Interface is needed with a member port on each peer switch.

• MCT Cluster Edge Port (CEP): A port on MCT peer switches that is neither a Cluster Client Edge Port nor an ICL port.

• MCT VLANs: VLANs on which MCT clients are operating. These VLANs are explicitly configured in the MCT configuration by the user. NOTE: For MCT VLANs, MAC learning is disabled on ICL ports, while MAC learning is enabled on ICL port for non-MCT VLANs.

• MCT Session VLANs: The VLAN used by the cluster for control operations. CCP protocol runs over this VLAN. The interface can be a single link or LAG port. If it is LAG port, it should be the primary port of the LAG. Note: MCT session VLAN's subnet will not be distributed in routing protocols using redistribute commands

• RBridge ID: RBridge ID is a value assigned to MCT nodes and clients to uniquely identify them, and helps in associating Source MAC with a MCT node.

• MDUP: MAC Database Update Protocol

• CL: Cluster Local MACs

• CCL: Cluster Client Local MACs

• CR: Cluster Remote MACs

• CCR: Cluster Client Remote MACs

• CCRR: Cluster Client RBridge Reachability

• MDB: Mac Data Base. The MDB can have multiple MAC entries for the same address

• FDB: Forwarding MAC Database. The FDM will have the best MAC only installed



Multi-Chassis TrunkingThe following FastIron features are not supported with MCT:

• LACP on ICL

• MSTP, VSRP, RIP, OSPF, IS-IS, and BGP

• IPv6, VRRP-E (IPv6), and VRRPv3

• GRE on the ICL VE interfaces

• DAI on the CCEPs

• Host security features (port MAC security, multi-port authentication, 802.1X, DAI, DHCP snooping) on CCEPs

• Multi-port ARP on ICL or CCEPs

• Web authentication on MCT VLANs



3 — Layer 2 Switching and ProtocolsWhen you have completed reviewing this section be sure you can do the following:

• Describe Layer 2 protocols

• Identify Layer 2 functionality

• Identify different VLAN implementations

• Describe the different link aggregation (LAG) implementations

Enabling or Disabling Layer 2 SwitchingBy default, Brocade devices supports routing over Layer 2 switching. You can enable Layer 2 switching globally or on individual port using the no route-only command.

The no route-only and route-only commands prompts you to change the route-only behavior. You must enter y if you want to proceed or n if you do not. The prompt is displayed as shown in the following examples of the no route-only and route-only commands.

To enable Layer 2 switching globally, enter the following.

Brocade(config)# no route-onlyThis will change the route-only behavior at the global level.Are you sure? (enter ‘y’ or ‘n’): yGlobal ‘route-only’ committed.

To enable Layer 2 switching only on a specific interface, go to the Interface configuration level for that interface, and add the no route-only command. The following command shows how to enable Layer 2 switching on port 3/2.

Brocade(config)# interface ethernet 3/2Brocade(config-if-e10000-3/2)# no route-only

To globally disable Layer 2 switching on a Brocade device and return to the default (route-only) condition, enter commands such as the following:

Brocade(config)# route-onlyThis will change the route-only behavior at the global level.Are you sure? (enter ‘y’ or ‘n’): yGlobal ‘no route-only committed.

Layer 2 ProtocolsA protocol is a set of rules that governs the communications between computers on a network

These rules include guidelines that regulate the following characteristics of a network:

• Access method

• Allowed physical topologies

• Transport medium

• Speed of data transfer



Spanning Tree ProtocolThe Spanning Tree Protocol (STP) eliminates Layer 2 loops in networks, by selectively blocking some ports and allowing other ports to forward traffic, based on global (bridge) and local (port) parameters you can configure.

STP related features, such as RSTP and PVST, extend the operation of standard STP, enabling you to fine-tune standard STP and avoid some of its limitations.

You can enable or disable STP on a global basis (for the entire device), a port-based VLAN basis (for the individual Layer 2 broadcast domain), or an individual port basis.

Brocade Layer 2 Switches and Layer 3 Switches support standard STP as described in the IEEE 802.1D specification. STP is enabled by default on Layer 2 Switches but disabled by default on Layer 3 Switches.

The Root BridgeWhen STP begins, a selection process is made to determine which redundant paths to keep forwarding user traffic and which ones to shut down. BPDUs are sent. Root bridge is used as a reference point by all other switches in the network for eliminating loops, and determining when an alternate path is required due to a topology change. It has (numerically) the lowest bridge ID (BID). By default, each bridge has a configurable priority number, called the bridge priority, and a unique MAC address. The BID is a combination of the bridge priority and the MAC address. The lowest numerical BID has the highest priority for root bridge selection. All other switches in the network calculate path cost to the root bridge to determine which ports will be used, and which will be blocked to eliminate loops.

The switch with the lowest Bridge ID (BID) becomes the root bridge. All Brocade switches have the default bridge priority 32768. If that is the case, the lowest MAC address is used. In Figure 3, Switch#1 is the Root Bridge because its Bridge Priority is the lowest; if all three switches have the same Bridge Priority, then Switch#3 will be the Root Bridge because its MAC address is the lowest.

After the election, each switch determines the shortest path to the root bridge. The switch port with the best path to the root bridge is the Root Port (RP). The path cost is based on the bandwidth. The higher the bandwidth, the lower the cost. When multiple switches share a connection that is not a root port, one of them becomes the Designated Port (DP), the other ports are blocked.

• Bridge ID = Bridge Priority + MAC address



The switch with the lowest BID wins and becomes the Root Bridge. If Bridge Priorities are the same, the switch with the lowest MAC address wins and becomes the Root Bridge.

Figure 3: Root Bridge

Bridge Protocol Data Units (BPDUs)BPDUs are data messages that are exchanged across switches within a LAN and VLAN to form and maintain a Spanning Tree Protocol topology (Spanning Tree is on by default on switches, but off by default on routers). The BPDU data messages are exchanged across bridges to detect loops in a network topology. The loops are then removed by blocking selected bridge ports and placing redundant switch ports in a backup or blocked state. BPDUs contain information about switches, ports, addresses, priorities, and costs.

The following are BPDU types:

• Configuration BPDU

Generated only by the root bridge and sent to non-root bridges, it provides a method of providing election information across the L2 domains and controlls reconvergence after a link has been broken.

• Topology Change Notification (TCN) BPDU

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

Fast Port SpanWhen 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 4–30 seconds. The default is 15 seconds. Therefore, using the standard forward delay, convergence requires at least 30 seconds (15 seconds for listening and an additional 15 seconds for learning) when the default value is used.

Switch#300:0E:80:01:90:06

Switch#1

(Priority:100)(Priority:200)

DP DP

DP

RP RP

Root Bridge(Priority:0)

Switch#2

00:0E:80:0A:F0:06

00:0E:80:01:F0:06



The Fast Port Span feature allows certain ports to enter the forwarding state in four seconds. It allows faster convergence on ports that are attached to end stations and do not cause Layer 2 forwarding loops. Because the end stations cannot cause forwarding loops, they can safely go through the STP state changes (blocking to listening to learning to forwarding) more quickly than is allowed by the standard STP convergence time. The purpose of Fast Port and Fast Uplink are to remedy the latency of 802.1d failover at critical network locations. The 802.1d timers could be changed to cut down the 30 second convergence, however, this could lead to network instability.

Figure 4: Fast Port Span

Fast Port Span performs the convergence on these ports in four seconds (two seconds for listening and two seconds for learning). In addition, Fast Port Span enhances overall network performance in the following ways:

• Reduces the number of STP topology change notifications on the network

• Eliminates unnecessary MAC cache aging that can be caused by topology change notifications

• When STP sends a topology change notification, devices that receive the notification use the value of the STP forward delay to quickly age out their MAC caches

• If a port matches any of the following criteria, it port is ineligible for Fast Port Span and uses normal STP instead:

- The port is 802.1Q tagged (refer to “802.1Q Tagging” on page 18)

- 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



Root GuardThe standard STP (802.1D), RSTP (802.1W) or 802.1S does not provide any way for a network administrator to securely enforce the topology of a switched layer 2 network. The forwarding topology of a switched network is calculated based on the root bridge position, along with other parameters. This means any switch can be the root bridge in a network as long as it has the lowest bridge ID. The administrator cannot enforce the position of the root bridge. A better forwarding topology comes with the requirement to place the root bridge at a specific predetermined location. Root Guard can be used to predetermine a root bridge location and prevent rogue or unwanted switches from becoming the root bridge.

BPDU GuardIn an STP environment, switches, end stations, and other Layer 2 devices use Bridge Protocol Data Units (BPDUs) to exchange information that STP will use to determine the best path for data flow.

The BPDU guard, an enhancement to STP, removes a node that reflects BPDUs back in the network. It enforces the STP domain borders and keeps the active topology predictable by not allowing any network devices behind a BPDU guard-enabled port to participate in STP.

ACL OverviewBrocade devices support rule-based ACLs (sometimes called hardware-based ACLs), where the decisions to permit or deny packets are processed in hardware and all permitted packets are switched or routed in hardware. All denied packets are also dropped in hardware. In addition, FastIron FWS devices support inbound ACLs only. Outbound ACLs are not supported on those devices. FSX, FCX, and ICX devices support both inbound and outbound ACLs.

IGMP Snooping OverviewWhen a device processes a multicast packet, by default, it broadcasts the packets to all ports except the incoming port of a VLAN. Packets are flooded by hardware without going to the CPU. This behavior causes some clients to receive unwanted traffic.

IGMP snooping provides multicast containment by forwarding traffic to only the ports that have IGMP receivers for a specific multicast group (destination address). A device maintains the IGMP group membership information by processing the IGMP reports and leave messages, so traffic can be forwarded to ports receiving IGMP reports.

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

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

• System name



• System description

• System capabilities

• Management address

The information distributed by LLDP is stored by the receiving device in a standard Management Information Base (MIB). The information can be viewed by a Network Management System or from the CLI.

The Foundry Discovery Protocol (FDP) enables Brocade devices to advertise themselves to other Brocade devices on the network. When you enable FDP on a Brocade device, the device periodically advertises information including the following:

• Hostname (device ID)

• Product platform and capability

• Software version

• VLAN and Layer 3 protocol address information for the port sending the update (IP, IPX, and AppleTalk Layer 3 information is supported)

Virtual Local Area Network Implementations A Virtual LAN (VLAN) is a logical subgroup within a local area network (LAN) that is created through software rather than manually moving cables in the wiring closet. It combines user stations and network devices into a single unit regardless of the physical LAN segment they are attached to and allows traffic to flow more efficiently within populations of mutual interest. VLANs have the following characteristics:

• Creates a broadcast domain

• Done through software configuration

• Implemented in port switching, hubs and LAN switches

By default, all Brocade switch ports are members of VLAN 1. VLANs reduce the time it takes to implement moves, adds and changes. Layer 3 VLANs require that all members are in the same port-based VLAN.



There are three types of VLANs:

• Port-based

A group of ports which constitutes a Layer 2 broadcast domain. This allows you to divide your user traffic into logical network segments.

• MAC-base

The MAC-based VLAN feature controls network access, by authenticating a host source MAC address, and mapping the incoming packet source MAC to a VLAN

• Protocol-based

A subset of ports within a Layer 2 port-based VLAN organized according to the Layer 3 protocol type.

Figure 5: Types of VLANs

Private VLANsPlatform support:

• FastIron X Series devices running software release 02.4.00 and later

• FGS and FLS devices running software release

• FGS-STK and FLS-STK devices running software release 05.0.00 and later

• FWS devices running software release 04.3.00 and later

By default, a private VLAN does not forward broadcast or unknown-unicast packets from outside sources into the private VLAN. If needed, you can override this behavior for broadcast packets, unknown-unicast packets, or both. You can configure a combination of the following types of private VLANs:

• Primary: The primary private VLAN ports are “promiscuous”. They can communicate with all the isolated private VLAN ports and community private VLAN ports in the isolated and community VLANs that are mapped to the promiscuous port.

• Isolated: Broadcast and unknown unicast traffic received on isolated ports are sent only to the primary port. They are not flooded to other ports in the isolated VLAN

L2 port-based VLAN 20

L3 protocol-based VLAN for IPv4

L3 protocol-based VLAN for IPv6

L3 protocol-based VLAN for IPX



• Community: Broadcast and unknown unicast traffic received on community ports are sent to the primary port and also are flooded to the other ports in the community VLAN

Figure 6 Private VLAN

Each private VLAN must have a primary VLAN. The primary VLAN is the interface between the secured ports and the rest of the network. The private VLAN can have any combination of community and isolated VLANs.

• You cannot configure isolated, community, or primary VLANs on 802.1Q tagged ports

• Normally, in any port-based VLAN, the device floods unknown unicast, unregistered multicast, and broadcast packets in hardware, although selective packets, such as IGMP, may be sent to only to the CPU for analysis, based on the IGMP snooping configuration.

• When protocol or subnet VLANs, or private VLAN mappings are enabled, the device floods unknown unicast, unregistered multicast, and broadcast packets in software

802.1Q TaggingWhen you create a VLAN on a switch, you need to determine which of its ports participate in that VLAN. The two types of membership are:

• Tagged the switch adds an extra 4 bytes to the Ethernet frame called the 802.1Q header

- Allows multiple port based VLANs to span switches over a single physical link

• Untagged the switch keeps track of this port as a member of the VLAN

802.1Q tagging is an IEEE standard that allows a networking device to add information to a Layer 2 frame in order to identify its VLAN membership. A port can belong to only one port-based VLAN, unless 802.1Q tagging is applied to the port.

Note

VLAN Without 802.1Q tagging is where the Ports require dedicated uplinks for each VLAN between switches. There is no question where broadcast traffic went from port-to-port.

802.1Q tagging allows the port to add a four-byte field, which contains the VLAN ID, to each frame sent on the port. Port-based VLANs can also be configured to span multiple devices by tagging the ports within the VLAN. The tag enables each device that receives the frame to determine to which VLAN the frame belongs. 802.1Q tagging applies only to Layer 2 VLANs.

Private VLANPort-Based VLAN

Forwarding among Private VLAN ports



Figure 7: VLAN Tagging

The tag contains the TPID, which identifies the frame as a tagged. The value of the TPID is 8100, and also contains the VLAN ID of the VLAN from which the packet is sent. The VLAN ID is determined by the VLAN on which the packet is being forwarded. There are also 3 bits reserved for the priority (802.1p), and the field type is 8100.

Figure 8: 802.1Q Tagging (Packet Format)

802.1q-in-q tagging802.1Q-in-Q tagging enables you to configure 802.1Q tag types on a group of ports, such as LAG



ports, thereby enabling the creation of two identical 802.1Q tags (802.1Q-in-Q tagging) on a single device. This feature improves Super Aggregated VLANs (SAV) interoperability between Brocade devices and other vendor devices that support the 802.1Q tag types, but are not very flexible with the tag types they accept.

Figure 9 SAV Configuration Example

As shown in Figure 9, the ports to customer interfaces are untagged, whereas the uplink ports to the provider cloud are tagged, because multiple client VLANs share the uplink to the provider cloud. In this example, the Brocade device treats the customer’s private VLAN ID and 8100 tag type as normal payload, and adds the 9100 tag type to the packet when the packet is sent to the uplink and forwarded along the provider cloud.

As long as the switches in the provider’s network support the 9100 tag type, the data gets switched along the network. However, devices that do not support the 9100 tag type may not properly handle the packets.

Figure 10 802.1 Q-in-Q Configuration Example

In Figure 10, the untagged ports (to customer interfaces) accept frames that have any 802.1Q tag other than the configured tag-type 9100. These packets are considered untagged on this incoming port and are re-tagged when they are sent out of the uplink towards the provider. The 802.1Q tag-type on the uplink port is 8100, so the Brocade device will switch the frames to the uplink device with an additional 8100 tag, thereby supporting devices that only support this method of VLAN tagging.



VLAN CPU ProtectionVLAN CPU protection is recommended for the VLANs which are intended for pure Layer 2 usage. This feature protects the CPU from the flooding of unknown-unicast, multicast, or broadcast L2 packets on that VLAN. When using routing protocols, such as OSPF, on a specific VLAN you need to disable VLAN CPU protection for it to work. This feature is intended for Layer 2 applications and not for Layer 3 routing applications.

Virtual InterfacesThe Brocade device sends Layer 3 traffic at Layer 2 within a protocol-based VLAN. However, Layer 3 traffic from one protocol-based VLAN to another must be routed. If you want the device to be able to send Layer 3 traffic from one protocol-based VLAN to another on the same device, you must configure a virtual routing interface on each protocol-based VLAN, then configure routing parameters on the virtual routing interfaces.

A virtual routing interface is a logical routing interface that the Brocade device uses to route Layer 3 protocol traffic between protocol-based VLANs. It is a logical port on which you can configure Layer 3 routing parameters. A virtual interface can have multiple IP addresses.

For example, to enable a Brocade device to route IP traffic from one IP protocol VLAN to another, you must configure a virtual routing interface on each IP protocol VLAN, then configure the appropriate IP routing parameters on each of the virtual routing interfaces. Hosts in a VLAN can use the IP address of the virtual interface as their default gateway.

Link Aggregation ImplementationsTrunking is another term for Link Aggregation. Link Aggregation allows an administrator to combine multiple Ethernet links into a larger logical trunk known as a Link Aggregation Group (LAG). The switch treats the trunk as a single logical link. The physical links must all be the same speed and duplex setting and must connect to the same adjacent switch including stackable switches1.

LAG requirements may vary for different platforms, such as the number of links in the LAG, specific port boundaries2. Always check what is supported at both ends

The rules for LAGs are heavily dependent on the hardware type and code version in use. All interface parameters in a LAG must match, including:

• Port tag type (tagged/untagged)

• Configured port speed3 and duplex

• QoS priority

1. Link Aggregation Groups are also referred to as: Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Port Trunking, Link Bundling, EtherChannel, Multi-Link Trunking (MLT), DMLT, SMLT, DSMLT, R-SMLT, NIC bonding, Network Fault Tolerance (NFT), and Fast EtherChannel.

2. Multi-Chassis Trunking is a technology that allows multiple switches to appear as a single logical switch connecting to another switch using a standard LAG. Since the technology is an enhancement to the standard LAG protocol, a single MCT-unaware server or switch using a standard LAG trunk can connect to two MCT-aware switches--and the traffic is dynamically load balanced. For more information on this topic, please refer to the FastIron Configuration Guide for the particular platform.

3. Each port in the LAG operates at the speed of the slowest link. For example, if one LAG is created with 2 ports and one is running at 10 Gbps and the other is running at 1 Gbps; each link operates at 1 Gbps. This behavior occurs if the ports are configured to auto and negotiate to different speeds.



Brocade switches support the use of static and dynamic LAGs on the same device4, but can use only one type of LAG for any given port.

Figure 11: Link Aggregation

In addition to traffic load sharing, trunk groups provide redundant, alternate paths for traffic if any of the segments fail.

• Benefits of trunking:

- Load-sharing

- Redundancy

There are two types of trunking:

• Static trunking

- Manually configured aggregate links containing multiple ports

• Dynamic Trunking: (802.3ad Link Aggregation)

- Dynamically created and managed trunk groups using Link Aggregation Control Protocol (LACP)

Trunking can be established between Brocade Layer 2/3 switches, or between a switch and a server.

LAG Formation RulesThe LAG formation rules are mentioned below:

• You cannot configure a port concurrently as a member of a static, dynamic, or keep-alive LAG.

• Any number or combination of ports between 1 and 32 within the same chassis can be used to configure a LAG. The maximum number of LAG ports is checked when adding ports to a LAG.

• All ports configured in a LAG must be of equal bandwidth. For example all 10 Gbps ports.

• All ports configured in a LAG must be configured with the same port attributes.

• LAG formation rules are checked when a static or dynamic LAG is deployed.

• A LAG must have its primary port selected before it can be deployed.

4. Multiple LAGs can be created on a switch with some of them being static LAGs and some of them being dynamic LAGs. A single port can only be part of one LAG type.



• All ports configured in a LAG must be configured in the same VLAN.

• All ports must have the same PBR configuration before deployment. During deployment, the configuration on the primary port is replicated to all ports. On undeployment, each port inherits the same PBR configuration.

• All static LAG ports must have the same LACP BPDU forwarding configuration.

• VLAN and inner-VLAN translation

Configuring Keys for Ports with Link Aggregation EnabledSyntax: [no] link-aggregate configure [system-priority <num>] | [port-priority <num>] | [key <num>]

The system-priority <num> parameter specifies the Brocade device link aggregation priority. A higher value indicates a lower priority. You can specify a priority from 0 through 65535. The default is 1.

The port-priority <num> parameter specifies an individual port priority within the port group. A higher value indicates a lower priority. You can specify a priority from 0 through 65535. The default is 1.

The key <num> parameter identifies the group of ports that are eligible to be aggregated into a trunk group. The software automatically assigns a key to each group of ports. The software assigns the keys in ascending numerical order, beginning with 0. You can change a port group key to a value from 10000 through 65535.

Configuring Load Sharing TypeIndividual LAGs can be configured to perform load sharing over the ports in the LAG using either a hash based or per packet method, as shown in the following.

Command and Output of show lagBrocade(config)# show lagTotal number of LAGs: 1Total number of deployed LAGs: 1Total number of s created:1 (127 available)LACP System Priority / ID: 1 / 0000.0001.c000LACP Long timeout: 90, default: 90LACP Short timeout: 3, default: 3=== LAG "lag1" ID 124 (static Deployed) ===LAG Configuration: Ports: ethe 1/2 to 1/3 Port Count: 2 Primary Port: 1/3 Type: hash-basedDeployment: ID 124, Active Primary 1/2Port Link L2 State Dupl Speed Tag Priori MAC Name1/2 Up Forward Full 10G 124 No level0 0000.0001.c0021/3 Up Forward Full 10G 124 No level0 0000.0001.c002



4 — General Layer 2 and Layer 3 ConceptsWhen you have completed reviewing this section be sure you can describe general routing and switching concepts.

Address Resolution ProtocolAddress Resolution Protocol (ARP) is used to associate a Layer 3 (Network layer) address, such as an IP address, with a Layer 2 (Data Link layer) address (MAC address).

ARP is used to resolve MAC addresses for hosts on the local subnet; for remote destinations, the source host sends out ARP requests asking for the MAC address of the default gateway. If a node matches the requested IP, it sends back its MAC address. Other nodes discard the ARP request.

Figure 12: ARP

If an address you want to communicate with is not in the ARP table then the Network Layer sends an ARP broadcast. The ARP broadcast is addressed to the broadcast address of the network. When the Data Link Layer receives the ARP broadcast packet, it uses the workstation MAC address as the source address, but it uses a broadcast MAC address as the destination. The broadcast MAC address sets all 48 of the bits in the address to “1.” In hexadecimal, it looks like this: FF:FF:FF:FF:FF:FF.

End-to-End Packet FlowThe following example details how a packet is routed from Host A to Host B on another subnet or network address.

1. If the destination host’s network number was the same as the source host’s, then the destination host would be considered local and on the same subnet. This is determined by taking Host A taking its own IP address and subnet mask and determining its own network address and then doing the same operation with the destination IP and sources’s subnet mask and comparing the results. If they are the same



then the destination Host B would be considered local; Otherwise the packets will be forwarded to the default gateway in order to be sent to a remote host. In this example the destination Host B’s Network ID of 192.168.3.0 is different from the source Host A’s Network ID of 192.168.1.0 and therefore the packets will need to be routed to the destination Host B.

2. The source Host A must check its own Local Route Table for its default gateway (this is the general behavior unless a special route has been defined). The default gateway IP is the IP of the routing interface for that subnet. In this example it is 192.168.1.1 which is the IP of Router 1 Interface E1. Since this is an Ethernet LAN, Host A will need to encapsulate the frame in order to sent it out to the routing interface of E1 and to do so it needs to know the MAC address of the routing interface. If it is not in its local cache an ARP broadcast will need to be initiated in order to send the encapsulated frames to the routing interface (E1 on Router1).

Figure 13: End-to-End Flow Example 1 of 4

3. In Figure 14, the default gateway’s MAC address is not in Host A’s cache. Host A initiates a local ARP broadcast request attempting to resolve the IP address to a physical MAC address.

4. Router 1 responds with a unicast ARP response to Host A with its MAC address of 22.

5. Host A creates/encapsulates an Ethernet frame with its own MAC 11 as the source and a destination MAC address of 22. Notice the destination IP still remains 192.168.3.20 and the frame can be sent on the wire.




6. Once Interface E1 on R1 receives the Ethernet frame it looks at the destination MAC address of the frame to check it if matches his own in order to determine if he is the recipient of the frame. In this case R1 interface E1 is the default gateway of Host A and therefore the intended recipient. R1 checks the frame’s Type field and notices 0x800 which indicates that there is an IP packet in the data portion of the Ethernet frame. R1 then proceeds to decapsulate the Ethernet frame in order to analyze the destination IP of the packet.

7. The Router must then consult its routing table to determine what to do with the packet. In general terms it looks to identify network routes in its table which would include the destination IP address as a host address on that network. Note: If there are several viable routes to the destination network it will chose the route with the longest “subnet mask” match. How routing tables become populated and an in depth look of how they are evaluated are beyond the scope of this example and class. After viewing R1’s routing table it finds that the network address of 192.168.3.0 is the destination network where these packets need to be routed. It also notices the next hop IP of 192.168.2.2 which represents the next stop for the packets on its way to the 192.168.3.0 network and this can be reached through local interface E2.

8. In order for R1 to do the frame encapsulation process it needs to know the MAC address of the 192.168.2.2 interface. So it must check its local ARP cache and again if the MAC address is not found, it must send an ARP broadcast to request the MAC address. In this case it will be already present. Therefore the frame encapsulation process can continue. Notice that the source and destination IP addresses stay the same but the source MAC becomes 33 and the destination MAC becomes 44. Also note that it also will decrement the Time to Live field of the packet (in the IP header) by 1. Now the packet is sent on the wire.




9. Once Interface E1 on R2 receives the Ethernet frame, it looks at the destination MAC address of the frame to check it if matches his own in order to determine if he is the recipient of the frame. In this case R2 interface E1 is the next hop IP of R1 and therefore the intended recipient. R2 checks the frame’s Type field and notices 0x800 which indicates that there is an IP packet in the data portion of the Ethernet Frame. R2 then proceeds to decapsulate the Ethernet frame in order to analyze the destination IP of the packet.

10. R2 must then consult its routing table to determine what to do with the packet. After consulting its routing table it finds that the Network Address of 192.168.3.0 is the destination network where these packets need to be forwarded and this is a directly connected route in its table through interface E2.

11. In order for R2 to do the frame encapsulation process it needs to know the MAC address of the final destination host B with the IP 192.168.3.20. So it must check its local ARP cache and again if the MAC address is not found it must be a ARP broadcast to resolve the IP Address to a matching physical MAC address. In this case it will be already present and therefore the frame encapsulation process can continue. Notice that the source MAC is 55 and the destination MAC becomes 66. Now the frame(s) are sent on the wire.

12. Once Host B receives the frame, it recognizes its own MAC address. It then decapsulates the frame and notices that itself is the intended host with an IP of 192.168.3.20.




Note

Throughout the packet flow the source and destination IP addresses stay the same, but the source and destination MAC changes. Also, the Time to Live field of the packet (in the IP header) is decre-mented by 1.

Private Networks (RFC 1918)The Internet Engineering Task Force (IETF) publishes a set of standards called Request for Comments (RFC). These detail all kinds of different standards for the Internet. Among them is RFC 1918: Address Allocation for Private Internets. This addresses (no pun intended) the problem by allowing private networks to be created. You can still use TCP/IP, but you don't have to worry about registering addresses with an Internet registry. RFC 1918 specifies a network range in each of the three addressable classes (A, B, and C).

TABLE 4 RFC 1918

Class Address Range

A 10.0.0.0/8 10.0.0.0 — 10.255.255.255

B 172.16.0.0/12 172.16.0.0 — 172.31.255.255

C 192.168.0./16 192.168.0.0 — 192.168.255.255



Open Shortest Path FirstOpen Shortest Path First (OSPF) is a link state routing Interior Gateway Protocol (IGP) for medium to large networks. Its cost metric is based on aggregated link cost. OSPF supports Classless Inter-Domain Routing (CIDR) and Variable Length Subnet Masks (VLSM). It is hierarchy-based using OSPF areas. Its network topology is built using Link State Advertisements (LSAs) received from other routers. OSPF has the following characteristics:

• Decreases routing overhead• Speeds up convergence• Confines network instability to a single area of the network• Communicates between routers using multicast advertisements• Has no periodic updates

Designated Router (DR)OSPF has a Designated Router which receives all the updates on a given segment. The Backup Designated Router is the second-in-command. This router receives the updates, too, but does not send them back out. When a router needs to update other routers, it sends the update to the Designated Router and the Backup Designated Router. The Designated Router sends the update to all of the other routers on its segment.

When the Designated Router becomes unavailable, the Backup Designated Router instantly becomes the Designated Router, and an election is held to see who becomes the next Backup Designated Router.

This way, each router need not be aware of all of the OSPF routers involved. It needs only to communicate its updates (and receive updates) from a single source. This minimizes traffic, and allows the OSPF design to expand nicely, as needed.

Figure 17: OSPF DR Election

Designated Router (DR) election is done by selecting the neighboring router with the highest priority. The router with the next largest priority is elected as the Backup DR (BDR). If the DR goes offline, the BDR automatically becomes the DR. The router with the next highest priority becomes the new BDR. If two neighbors share the same priority, the router with the highest router ID is designated as the DR.



1. The Router ID can be manually configured using the global ip router-id x.x.x.x command.

2. If the Router ID is not manually configured, the IP address configured on the lowest numbered loopback interface is used as the Router ID

3. If there is no loopback interface, then the router ID is the lowest numbered IP address configured on the device

When only one router on the network claims the DR role despite neighboring routers with higher priorities or router IDs; this router remains the DR. This is also true for BDRs.

The DR and BDR election process is performed when one of the following events occurs:

1. An interface is in a waiting state and the wait time expires

2. An interface is in a waiting state and a hello packet is received that addresses the BDR

3. A change in the neighbor state occurs, such as, a neighbor state transitions from 2 or higher, communication to a neighbor is lost, or a neighbor declares itself to be the DR or BDR for the first time

Neighbor AdjacencyOSPF defines a neighbor as a router that has an interface with an IP address in the same broadcast domain. The following parameters must match to become neighbors:

• Subnet mask

• Hello/Dead intervals

• Area-ID

• Authentication password

• Stub area flag

Neighbor StatesThe neighbors on a given router will go through six states on their way to fully becoming synchronized with its routing table. The first three states are referred to as the neighboring process. These are the states neighbors go through in order to establish themselves as neighbors.

• Down: The router has not sent a Hello packet, nor has it received one

• Init: A Hello packet has been sent to a neighbor, but no Hello packet has been received from that neighbor

• 2 Way: The router has sent a Hello packet to a neighbor, and has received a Hello packet back; the reply will contain your router's Router ID inside; now, your router knows that the neighbor knows your router as well

The next three states are referred to as the adjacency process. To establish adjacency means that your OSPF database is synchronized with your neighbor (there's currently no further information to share).

• Ex-Start: This is short for “Exchange Start”; this is where the DR/BDR election takes place; routers are sending Hello packets to determine who will become the DR and BDR

• Exchange: Now the neighbors are finally talking; in this state, your router is sharing everything it knows, and the neighbor router is sharing everything it knows

• Full: We're adjacent! The neighbors have no more information to share; they've shared it all



AreasRouters in OSPF are split into different groups called areas. The purpose is to reduce traffic and CPU load. The area that is the most restrictive uses the least resources (CPU and memory). Areas may be organized in any way that makes the most sense for a particular network. Areas are assigned numbers on the range of 1 through 4,294,967,295. Enabling OSPF logging is good for troubleshooting.

Figure 18: OSPF Areas

Area Types:

• Area 0 - Backbone

- A required area to which all other areas must connect

• Ordinary or standard area (Normal or transit area)

- All routers in a OSPF area have the same topological database, but their routing tables are based on the router’s position in the area and are unique to the router

• Stub area

- An area that does not accept external routes but accepts routes from within the same autonomous system

• Not So Stubby Area (NSSA)

- A stub area does not accept external summary routes from the backbone, but can advertise external summary routes into the backbone

• Totally stubby area

- This area won’t accept routes from any other area. The Area Border Router (ABR) advertises 0.0.0.0/0 instead

San Jose

Los Angeles

New York



OSPF Autonomous System (AS) is the entire OSPF routing domain. An OSPF AS can be divided into multiple areas. The propagation of Types 1 and 2 Link State Advertisements is limited to the bounds of an area.

An OSPF router can be a member of multiple areas. These routers are known as Area Border Routers (ABRs). Each ABR maintains a separate topological database for each area the router is in. Each topological database contains all of the LSAs within a given area. The routers within the same area have identical topological databases. The ABR is responsible for forwarding routing information or changes between its border areas.

An Autonomous System Boundary Router (ASBR) is a router that is running multiple protocols and serves as a gateway to routers outside an AS. The ASBR is able to import and translate different protocols routes into OSPF through a process known as redistribution.

Figure 19: OSPF AS

OSPF Virtual LinksOSPF virtual links allow administrators to work around the requirement that all other areas must connect directly to the backbone. If the new area cannot connect directly to the backbone area, two ABRs are set up to “bridge” the gap and recreate the connectivity.

The configuration commands pass area information between ABRs in the intermediary area. From the viewpoint of OSPF, each ABR has a direct connection to three areas (Area 0, the outlying area, and the area traversed).

This scenario may emerge in a variety of cases:

• Merge or failure isolates an area from Area 0

• The area is critical to the company, and an extra link has been configured for redundancy

Requirement to create a virtual link:

• Both routers must share a common area



• The transit area cannot be a stub area

• One of the ABRs must be connected to Area 0

Virtual links are meant to be a temporary solution to connectivity problems and are not recommended as a design strategy

OSPFs Four Level Routing Hierarchy• Level 1 - Intra-area routing

• Level 2 - Inter-area routing

• Level 3 - External Type 1 Metrics

• Level 4 - External Type 2 Metrics

If there are two routing paths to choose from then paths that are internal to an OSPF routing domain are preferred over external routes. External routes can be imported into the OSPF domain at two separate levels, one that has Type 1 Metrics and the other Type 2 Metrics.

The use of Type 1 metrics assumes that in the path from the OSPF router to the destination, the internal OSPF AS component (path to the ASBR advertising the AS-external-LSA) and external component are of the same importance.

In Type 2 metrics, it is assumed that only the external component is more significant than the internal component. The aggregate cost to these external destinations does not change when viewed from different routers, since the internal costs are not important. But the cost of Intra-area and Inter-area destinations does change depending on which router the cost is observed.

Loopback InterfacesYou should configure a loopback interface on the router that is participating in OSPF. The loopback address does not belong to a particular interface. If you have a router participating in OSPF with several physical links, the router will have to be identified by the IP address of one of those links (the Router ID). This means that If that link goes down the router would have to start the neighboring process all over again using a new Router ID.

If you use a loopback address, the Router ID does not change. Also, it is not contingent on whether one of the physical interfaces is up or down. The loopback is the IP address of the device, not an individual interface.

Common practice would be to choose a unique /30 network (some even use a /32 network), assign an IP address to a loopback interface, and assign that interface to be a member of a particular area.

Link State AdvertisementLink State Advertisement (LSA) is an OSPF data packet that communicates the router's local routing topology to all other local routers in the same OSPF area.

OSPF Link State process:

1. Link State Advertisements exchanged between routers

2. Topology Database is built

3. Router runs Shortest Path First (SPF) algorithm to calculate the best path

4. SPF tree is generated



5. Best routes are selected from SPF tree, and entered into the routing table, based on cost to individual networks

LSA Types (by type code)

• Type 1: Router LSA - generated by each router for each area to which it belongs.

• Type 2: Network LSA - generated by DRs describing the set of routers attached to a particular network.

• Type 3: Network Summary LSA - generated by ABRs describing inter-area routes.

• Type 4: ASBR Summary LSA - generated by ABRs advertising the IP address of the ASBR.

• Type 5: External LSA - generated by the ASBR describing networks external to the Autonomous System (AS).

• Type 7: NSSA External LSA - generated by ASBR and only flooded within the Not-So-Stubby area. The ABR converts Type 7 LSAs into type 5 before flooding them into the backbone area (area 0).

By default, the device sends summary LSAs (LSA type 3) into stub areas. You can further reduce the number of link state advertisements (LSA) sent into a stub area by configuring the device to stop sending summary LSAs (type 3 LSAs) into the area. You can disable the summary LSAs when you are configuring the stub area or later after you have configured the area. To disable summary LSAs for a stub area, enter commands such as the following.

Brocade(config-ospf-router)# area 40 stub 99 no-summary

Mapping of IPv4 Multicast Group Addresses to Ethernet MAC AddressesThe IANA owns a block of Ethernet MAC addresses for Multicast usage that are in the range 0100.5e00.0000 through 0100.5e7F.FFFF. For a given IPv4 Multicast group, there is a simple way of obtaining the appropriate Ethernet Destination MAC address that must be used in Layer 2 encapsulation. This is defined in RFC 1112, as follows:

An IP host group address is mapped to an Ethernet multicast address by placing the low-order 23-bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Because there are 28 significant bits in an IP host group address, more than one host group address may map to the same Ethernet multicast address.



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

IPv6 Address RepresentationIPv6 addresses are presented in a very unique way and very different than its predecessor, IPv4. Considering the overall length of the address it was imperative to find ways to express the address in a more concise manner whenever possible.

When expressing IPv6 addresses verbally, it is proper to call out each colon (:). For example, the address 2001::49:17 would be read as:

• Two thousand and one, colon, colon, forty-nine, colon, seventeen

Two options are defined to shorten IPv6 address expressions

TABLE 5 IPv6 Address Types

Address Type Description Address Structure

Unicast An address for a single interface. A packet sent to a unicast address is delivered to the interface identified by the address.

Depends on the type of the unicast address:• Aggregatable global address—An address equivalent to a

global or public IPv4 address. The address structure is as follows: a fixed prefix of 2000::/3 (001), a 45-bit global routing prefix, a 16-bit subnet ID, and a 64-bit interface ID.

• Site-local address—An address used within a site or intranet. (This address is similar to a private IPv4 address.) A site consists of multiple network links. The address structure is as follows: a fixed prefix of FEC0::/10 (1111 1110 11), a 16-bit subnet ID, and a 64-bit interface ID.

• Link-local address—An address used between directly connected nodes on a single network link. The address structure is as follows: a fixed prefix of FE80::/10 (1111 1110 10) and a 64-bit interface ID.

• IPv4-compatible address—An address used in IPv6 transition mechanisms that tunnel IPv6 packets dynamically over IPv4 infrastructures. The address embeds an IPv4 address in the low-order 32 bits and the high-order 96 bits are zeros. The address structure is as follows: 0:0:0:0:0:0:A.B.C.D.

• Loopback address—An address (0:0:0:0:0:0:0:1 or ::1) that a switch can use to send an IPv6 packet to itself. You cannot assign a loopback address to a physical interface.

• Unspecified address—An address (0:0:0:0:0:0:0:0 or ::) that a node can use until you configure an IPv6 address for it.

Multicast An address for a set of interfaces belonging to different nodes. Sending a packet to a multicast address results in the delivery of the packet to all interfaces in the set.

A multicast address has a fixed prefix of FF00::/8 (1111 1111). The next 4 bits define the address as a permanent or temporary address. The next 4 bits define the scope of the address (node, link, site, organization, global).

Anycast An address for a set of interfaces belonging to different nodes. Sending a packet to an anycast address results in the delivery of the packet to the closest interface identified by the address.

An anycast address looks similar to a unicast address, because it is allocated from the unicast address space. If you assign a unicast address to multiple interfaces, it is an anycast address. An interface assigned an anycast address must be configured to recognize the address as an anycast address.An anycast address can be assigned to a switch only. An anycast address must not be used as the source address of an IPv6 packet.



1. Leading zeros in each 16-bit field are optional

2. The double colon ( :: ) represent two or more consecutive fields of zeros

- The double colon may be used only once in an address

Note

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

Virtual Router Redundancy Protocol - EnhancedVirtual Router Redundancy Protocol - Enhanced (VRRP-E) is Brocade’s enhanced version of VRRP that overcomes limitations in the standard protocol. All routers are backups for a given Virtual Router ID (VRID). The router with the highest priority (a configurable value) becomes master. VRRP-E uses UDP to send Hello messages in IP multicast messages. To prevent an immediate transition from backup to re-instated master, enable the slow start timer.

VRRP-E requires only that the VRID be in the same subnet as an interface configured on the VRIDs interface. Multiple VRIDs can exist on a single interface.

VRRP-E supports the use of more than one track port.

Standard Expression Shortened Expression

2001:0000:130F:0000:0000:00C0:876A:12EB

2001:0:130F:0:0:00C0:876A:12EB

Shortened Expression Double Colon Use

2001:0:130F:0:0:C0:876A:12EB 2001:0:130F::C0:876A:12EB

2001:0:0:0:0:0:0:1 2001::1

0:0:0:0:0:0:0:1 ::1

0:0:0:0:0:0:0:0 ::

2001:0:130F:0:0:C0:876A:12EB 2001::130F::C0:876A:2EB

Example ofIncorrect Use



The Virtual IP (VIP) is a unique IP address on the same subnet as the VRRP-E routers. There is no concept of an owner IP address, as a real interface IP is not used. The elected master hosts the VIP address and answers ICMP requests. VRRP-E uses UDP (port 8888) to send multicast hello messages to 224.0.0.2, the multicast address. The VIP address can be reached by the use of ping. All switches participating in VRRP-E with the same VRID group must have the same Virtual IP address.

Figure 20 VRRP-E

The following command sequence sets up and activates VRRP-E. It follows the configuration rules which state the following:

• The router interfaces in a VRID must be in the same IP subnet

• The Hello/Dead intervals must be set to the same values on all the VRRP-E enabled devices

• The Virtual IP (VIP) address must be configured the same on routers belonging to the same VRRP-E backup group

Router_A(config)# router VRRPExtendedRouter_A(config)# interface e1Router_A(config-if-1)# ip address 192.53.5.2 Router_A(config-if-1)# ip VRRPExtended vrid 1Router_A(config-if-1-vrid-1)# backup priority 110 track-priority 20Router_A(config-if-1-vrid-1)# ip-address 192.53.5.1 <-- Virtual IPRouter_A(config-if-1-vrid-1)# track-port e15 e16Router_A(config-if-1-vrid-1)# activate

Router_B(config)# router VRRPExtendedRouter_B(config)# interface e1Router_B(config-if-1)# ip address 192.53.5.3 Router_B(config-if-1)# ip VRRPExtended vrid 1Router_B(config-if-1-vrid-1)# backup priority 80Router_B(config-if-1-vrid-1)# ip-address 192.53.5.1 <-- Virtual IPRouter_B(config-if-1-vrid-1)# activate



Figure 21: Multiple VRRP-E Groups

In Figure 21, Router A and Router B use VRRP-E to load share as well as provide redundancy to the hosts. The load sharing is accomplished by creating two VRRP-E groups. Each group has its own virtual IP address. Half of the clients point to virtual IP address of VRID 1 as their default gateway and the other half point to virtual IP address of VRID 2 as their default gateway. This enables some of the outbound Internet traffic to go through Router A and the rest to go through Router B.

VRRP-E reduces the priority of a VRRP-E interface by the amount of a tracked interface's priority if the tracked interface's link goes down. For example, if the VRRP-E interface's priority is 200 and a tracked interface with track priority 20 goes down, the software changes the VRRP-E interface's priority to 180. If another tracked interface goes down, the software reduces the VRIDs priority again, by the amount of the tracked interface's track priority.



Router A is the master for VRID 1 (backup priority = 110) and Router B is the backup for VRID 1 (backup priority = 100). RouterA and RouterB both track the uplinks to the Internet. If an uplink failure occurs on Router A, its backup priority is decremented by 20 (track priority = 20), so that all traffic destined to the Internet is sent through Router B instead.

Similarly, RouterB is the master for VRID 2 (backup priority = 110) and RouterA is the backup for VRID 2 (backup priority = 100). Router A and Router B are both tracking the uplinks to the Internet. If an uplink failure occurs on RouterB, its backup priority is decremented by 20 (track priority = 20), so that all traffic destined to the internet is sent through RouterA instead.



5 — Routing ConceptsWhen you have completed reviewing this section be sure you can do the following:

• Describe general routing concepts

• Describe how to implement the OSPF protocol

• Describe multicast routing

General Routing ConceptsRouting is needed when data needs to reach a remote network that is not directly connected to the local router.

Routing TablesA router uses its routing table to determine the next hop for the packet's destination and forwards the packet appropriately5. The next router repeats this process using its own routing table until the packet reaches its destination. At each stage, the IP address in the packet header is used to determine the next hop. If either a destination network or a default route are not in the routing table, the packet is dropped.

Defining a Default RouteA default route is a routing table entry used to route packets when an explicit route to a destination network is not in the routing table. It is the network route used by a router when no other known route exists for a given IP packet's destination address. It is last in the order of execution of the routing table.

Brocade supports two types of default routes:

• Explicit default route

- IPv4 default route 0.0.0.0 0.0.0.0 or 0.0.0.0/0

- Can be a static route or learned dynamically by a routing protocol like OSPF. OSPF uses a command called default-information originate to send the default route to other OSPF routers

5. When an IP packet is to be forwarded, a router uses its routing table to determine the next hop for the packet's destination (based on the destination IP address in the IP packet header), and forwards the packet appropriately. The next router then repeats this process using its own routing table, and so on until the packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to determine the next hop; no additional protocol headers are required.



• Candidate default route

- A Candidate default network is used when a default route is not statically configured or propagated by a routing protocol

- The default route has precedence over the default network

Figure 22: Default Routes

The command ip route 0.0.0.0 0.0.0.0 209.157.1.1 is a default route or “route of last resort” because it is last place in the order of execution of the route table.

The ip route 0.0.0.0 0.0.0.0 209.157.1.1 can appear in a route table because it is:

• Manually configured on the router

• Can be sent to other routers by a routing protocol like OSPF

• The command ip default-network 209.157.1.0 is a default network route and is there in case a default route is not present because it has neither been manually configured nor passed by routing protocol like OSPF



Static RoutesA static route is a route manually created by a network administrator to instruct a router how to reach a particular remote network. A local next hop IP address or a local outgoing interface number can be used in the static route configuration. Each router in the path needs a next hop route.

Figure 23Static Routes

Router_A(config)# ip route 172.16.1.0/24 10.1.2.1Router_B(config)# ip route 172.16.1.0/24 10.1.1.1Router_B(config)# ip route 192.168.1.0/24 10.1.2.2Router_C(config)# ip route 192.168.1.0/24 10.1.1.2

Classless Inter-Domain Routing (CIDR)Classless Inter-Domain Routing (CIDR) is used to aggregate multiple classful network addresses into a single routable address called supernetting. CIDR was created to help resolve the following problems:

• Because of the Internet evolution there was a real concern that in the IPv4 address space, especially Class B addresses would be exhausted

• Running out of capacity in the global routing tables

• Eventual exhaustion of the entire 32-bit IP address space

The motivation behind CIDR implementations was allocating IP address space more efficiently. CIDR is used instead of handing out full classful addresses (A or B) to organizations that were not fully utilizing the entire address space.

The convention states that you can represent the number of network bits in a subnet mask, by adding a number after a forward slash (“/”) character. For example, 10.0.0.0, in classful networking, has a subnet mask of 255.0.0.0 (Class A). This means that the network portion has eight bits. Using CIDR, we would represent this same network like this: 10.0.0.0/8. Notice that I used the network address (10.0.0.0), followed it by a forward slash (/), and then followed that by the number of network bits in the subnet mask (8, in this example).

TABLE 6 Classful versus Classless Networks

Type From To Mask or Prefix

Class A 1.0.0.0 127.255.255.255 255.0.0.0

Class B 128.0.0.0 191.255.255.255 255.255.0.0

Class C 192.0.0.0 223.255.255.255 255.255.255.0

CIDR 1.0.0.0. 223.255.255.255 /1-32 (Address bits 1-32)



CIDR provides the mechanism to combine multiple networks into groups or blocks, which the router treats as one big network (route summarization or route aggregation). For example, instead of having to store 10 Class C network addresses (any multiple number of smaller classful networks) the router can store a single CIDR-based network address.

CIDR is still bound by the base network address space. That is, a traditional Class C network address can use all 24 network mask bits for supernetting (as long as the bits are contiguous) but a Class A address can only use the first 8 bits of the prefix for supernetting. If more than the first 8 bits are used this would be subnetting, rather than supernetting.

To supernet:

1. Use the lowest network address for the supernet address

2. Find the lowest order matching bit between the addresses

- The lowest order matching bit will be the last bit in the supernet prefix

Figure 24 Supernetting

Administrative DistanceEach route in a routing table has a metric called an administrative distance in the range of 0-255. Lower metrics mean better values or routes are chosen. The lowest value administrative distance is the one that is stored in the routing table.

Static IP route parametersWhen you configure a static IP route, you must specify the following parameters:

• The IP address and network mask for the route destination network.

TABLE 7 Default Administrative Distances

Protocol Cost

Directly connected 0

Static 1

External BGP (eBGP) 20

OSPF 110

RIP 120

Internal BGP (iBGP) 200



• The route path, which can be one of the following:

- The IP address of a next-hop gateway

- An Ethernet port

- A virtual interface (a routing interface used by VLANs for routing Layer 3 protocol traffic among one another)

- A null interface. The Layer 3 Switch drops traffic forwarded to the null interface.

Link State vs. Distance Vector (OSPF vs. RIP)• Metric: OSPF is a link state protocol. This means that each router participating in the protocol is

responsible for reporting the state of each of its links. OSPF uses a link's cost to make its routing decisions. The cost is determined by dividing the speed of the link (in Mbps) into 100, by default (this method can be customized; more on this later). Just as in consumer pricing, the lower the cost, the more desirable the route. Distance vector, as you may recall from Chapter 9, means that the protocol bases its routing decisions on distance. If you have two or more routes to the same destination, you choose the one with the shortest distance. RIP is the most common example of this type of protocol. For its distance, it uses hop count, or the number of routers a packet must traverse to get to its destination.

• Route Advertisements: RIP advertises its entire routing table: OSPF sends only updates.

• Route Advertisement Recipients: RIP broadcasts its entire routing table to any address within its configured broadcast domains. It doesn't matter if you're a router or a workstation. You will receive a copy of the router's routing table. In OSPF, it sends updates multicast. A multicast packet is a packet that originates from a single host, but is delivered to multiple destinations.

• It might help to think of broadcast versus multicast in the same way you understand an Ethernet hub versus a switch. An IP broadcast, in some ways, is like a hub. With a hub, if a frame comes in one port, it gets duplicated and sent out every other port. There's no intelligence to it. It just gets duplicated. An IP multicast is more like a switch with VLANs configured. An incoming frame will be duplicated, but only sent out the port of the frame's destination, or, if that is unknown, the ports that are participating in the VLAN. In this case, OSPF sends its updates to all OSPF routers. Two special multicast addresses to remember are:

- 224.0.0.2 - all routers

- 224.0.0.5 - all OSPF routers

• Updates: RIP broadcasts its entire routing table every 30 seconds. OSPF sends updates only when changes occur.

• Authentication: MD5 hash authentication is available in RIP, but only in version 2. OSPF also provides MD5 hash authentication.

• Variable Length Subnet Masks (VLSM): RIP version 2 supports this. OSPF supports it, too.

IGMP SnoopingThe Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships.

PIM snooping must be used only in topologies where multiple PIM sparse routers connect through a device. PIM snooping does not work on a PIM dense mode router which does not send join messages, and traffic to PIM dense ports is stopped. A PIM snooping-enabled device displays a warning if it receives PIM dense join or prune messages.



IGMP protocols provide a method for clients and a device to exchange messages, and let the device build a database indicating which port wants what traffic. The protocols do not specify forwarding methods. They require IGMP snooping or multicast protocols such as PIM or DVMRP to handle packet forwarding. PIM or DVMRP can route multicast packets within and outside a VLAN, while IGMP snooping can switch packets only within a VLAN.

Supported Layer 3 multicast routing protocolsBrocade Layer 3 switches support the multicast routing protocol DVMRP and PIM along with the Internet Group Membership Protocol (IGMP).

PIM and DVMRP are broadcast and pruning multicast protocol that deliver IP multicast datagrams. The protocol employs reverse path lookup check and pruning to allow source-specific multicast delivery trees to reach all group members. DVMRP and PIM build a different multicast tree for each source and destination host groups.

Note

DVMRP and PIM can concurrently operate on different ports of a Brocade Layer 3 switch.



6 — Access Control List (ACL) ConceptsAfter reviewing this section you should be able to describe Access Control List (ACL) concepts.

ACL OverviewBrocade’s FastIron devices support rule-based ACLs (sometimes called hardware-based ACLs), where the decisions to permit or deny packets are processed in hardware and all permitted packets are switched or routed in hardware. In addition, Brocade’s FastIron devices support inbound ACLs only; outbound ACLs are not supported. Rule-based ACLs program the ACL entries you assign to an interface into Content Addressable Memory (CAM) space allocated for the ports. The ACLs are programmed into hardware at startup (or as new ACLs are entered and bound to ports). Devices that use rule-based ACLs program the ACLs into the CAM entries and use these entries to permit or deny packets in the hardware, without sending the packets to the CPU for processing. Rule-based ACLs are supported on the following interface types:

• Gigabit Ethernet ports

• 10 Gigabit Ethernet ports

• Trunk groups

• Virtual routing interfaces

ACLs filter traffic by permitting or denying incoming frames from passing through interfaces that have the ACL applied to them. Each ACL is a collection of permit and deny statements (rules) that apply to frames. A switch compares the fields in the frame against any ACLs applied to the interface to verify that the frame has the required permissions to be received or forwarded. The switch sequentially compares the frame against each rule in the ACL and either forwards or drops it. The order of the rules in an ACL is critical because the first rule that matches the traffic stops further processing of the frame.

Default ACL ActionThe default action when no ACLs are configured on a device is to permit all traffic. However, once you configure an ACL and apply it to a port, the default action for that port is to deny all traffic that is not explicitly permitted on the port:

• If you want to tightly control access, configure ACLs consisting of permit entries for the access you want to permit. The ACLs implicitly deny all other access.

• If you want to secure access in environments with many users, you might want to configure ACLs that consist of explicit deny entries, then add an entry to permit all access to the end of each ACL. The software permits packets that are not denied by the deny entries.

Note

The ACL takes effect immediately after being applied to an interface.

Access Control ListsACLs filter traffic by permitting or denying incoming frames from passing through interfaces that have the ACL applied to them. Each ACL is a collection of permit and deny statements (rules) that apply to frames. The switch sequentially compares the frame against each rule in the ACL and either forwards or drops it. A switch also compares the fields in the frame against any ACLs applied to the interface to verify that the frame has the



required permissions to be received or forwarded. The order of the rules in an ACL is critical because the first rule that matches the traffic stops further processing of the frame. Since ACLs are executed sequentially, from top to bottom, place the deny statements before the permit statements. There is an implicit deny statement at the end of each ACL. All traffic not specifically permitted is automatically denied.There are two types of ACLs:

• Standard (ACL 1-99)

- Permits or Denies packets based on source IP address

- Configured with the access-list command

• Extended (ACL 100-199)

- Permits or denies packets based on source and destination IP addresses, TCP/UDP ports, or protocol number or name

- Configured with the access-list command

- The following are editing options for extended ACLs:

• Insert a new ACL entry within an existing ACL

• Delete an entry from an ACL

• Replace an existing ACL entry

• Add, insert, replace, or delete a remark per ACL entry

If you can, try to apply ACLs “Inbound” rather than “Outbound”. Inbound ACL behavior states that the first instance of a TCP or UDP packet is handled by the ASIC and not the CPU. Enabling access list logging impacts the CPU.

Example Standard ACL

Figure 25: Standard ACL Example

Router_A(config)# ip dns server-address 209.157.22.30Router_A(config)# access-list 1 deny host 209.157.22.26 logRouter_A(config)# access-list 1 deny host 209.157.29.12 logRouter_A(config)# access-list 1 deny host IPHost1 logRouter_A(config)# access-list 1 permit anyRouter_A(config)# interface ethernet 1/1Router_A(config-if-1/1)# ip access-group 1 in

Example Explanation

Q: Why do the 2nd, 3rd, and 4th access list 1 lines have no subnet mask?



A: With the host argument, there is an implicit /32 bit mask.

- The host argument is used in the syntax as a substitute for the subnet mask.

- DNS server configuration allows a host name to be specified and it is looked up on the servers listed in the command, you can list up to four servers. The DNS servers are searched in the order listed in the configuration.

- Syslog entries: The first time an ACL entry permits or denies a packet, the software immediately generates a Syslog entry and SNMP trap. The software also starts a five-minute timer. The timer keeps track of all packets explicitly denied by the ACL entries. After five minutes, the software generates a single Syslog entry for each ACL entry that has denied a packet. The message indicates the number of packets denied by the ACL entry during the previous five minutes.

Standard Named ACL syntaxSyntax: [no] ip access-list standard <ACL-name> | <ACL-num>

Syntax: deny | permit <source-ip> | <hostname> <wildcard> [log]

or

Syntax: deny | permit <source-ip>/<mask-bits> | <hostname> [log]

Syntax: deny | permit host <source-ip> | <hostname> [log]

Syntax: deny | permit any [log]

Syntax: [no] ip access-group <ACL-name> in | out

The <ACL-name> parameter is the access list name. You can specify a string of up to 256 alphanumeric characters. You can use blanks in the ACL name if you enclose the name in quotation marks (for example, “ACL for Net1”).

The <ACL-num> parameter allows you to specify an ACL number if you prefer. If you specify a number, you can specify from 1 – 99 for standard ACLs.

The deny | permit parameter indicates whether packets that match a policy in the access list are denied (dropped) or permitted (forwarded).

The <source-ip> parameter specifies the source IP address. Alternatively, you can specify the host name.

The <wildcard> parameter specifies the mask value to compare against the host address specified by the <source-ip> parameter.

The host <source-ip> | <hostname> parameter lets you specify a host IP address or name. When you use this parameter, you do not need to specify the mask. A mask of all zeros (0.0.0.0) is implied.

The any parameter configures the policy to match on all host addresses.

The log argument configures the device to generate Syslog entries and SNMP traps for inbound packets that are denied by the access policy.

Policy-Based Routing (PBR)Policy-Based Routing (PBR) allows you to use ACLs and route maps to selectively modify and route IP packets in hardware. The ACLs classify the traffic. Route maps that match on the ACLs set routing attributes for the traffic.



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.

Figure 26: Policy-based Routing

Configuring a PBR policyTo configure PBR, you define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device programs the ACLs into the packet processor on the interfaces and routes traffic that matches the ACLs according to the instructions in the route maps.

PBR policy configuration overview:

• Configure ACLs that contain the source IP addresses for the IP traffic you want to route using PBR.

• Configure a route map that matches on the ACLs and sets the route information.

• Apply the route map to an interface.

Customer BAS 110

209.157.23.X

Customer CAS 120

209.157.24.X

Customer DAS 130

209.157.25.X

192.168.2.1

192.168.2.2

192.168.2.3

ISP_WAN

VLAN

RVE1

AS 200

VE3: 192.168.2.4/24



7 — Quality of Service (QoS) ConceptsAfter reviewing this section you should be able to describe Quality of Service (QoS) concepts and their use in different situations.

QoS OverviewQuality of Service (QoS) features are used to prioritize the use of bandwidth in a switch. When QoS features are enabled, traffic is classified as it arrives at the switch, and processed through on the basis of configured priorities. Traffic can be dropped, prioritized for guaranteed delivery, or subject to limited delivery options as configured by a number of different mechanisms.

Classification is the process of selecting packets on which to perform QoS, reading the QoS information, and assigning a priority to the packets. The classification process assigns a priority to packets as they enter the switch. These priorities can be determined on the basis of information contained within the packet or assigned to the packet as it arrives at the switch. Once a packet or traffic flow is classified, it is mapped to a forwarding priority queue.

Packets on Brocade devices are classified in up to eight traffic classes with values from 0 to 7. Packets with higher priority classifications are given a precedence for forwarding.

QoS for Brocade Stackable DevicesBrocade FastIron units in an IronStack support QoS. Units in a stack communicate the stack topology information and other proprietary control information through the stacking links.

In addition to control information, the stacking links also carry user network data packets. In an IronStack topology, the priority of stacking-specific control packets is elevated above that of data path packets, preventing loss of control packets, and timed retries that affect performance. This prioritization also prevents stack topology changes that may occur if enough stack topology information packets are lost.

IronStack technology reserves one QoS profile to provide a higher priority for stack topology and control traffic.

QoS Queueing Methods• Weighted Round Robin (WRR) – WRR ensures that all queues are serviced during each cycle. A weighted

fair queuing algorithm is used to rotate service among the eight queues on FESX, FSX, FWSX, FGS, FLS, FWS, and FGS-STK and FLS-STK devices. The rotation is based on the weights you assign to each queue. This method rotates service among the queues, forwarding a specific number of packets in one queue before moving on to the next one. WRR is the default queuing method and uses a default set of queue weights.

• Strict Priority (SP) – SP ensures service for high priority traffic. The software assigns the maximum weights to each queue which causes the queuing mechanism to serve as many packets in one queue as possible before moving to a lower queue. This method biases the queuing mechanism to favor the higher queues over the lower queues.

• Hybrid WRR and SP – Starting with software release 02.2.00, an additional configurable queueing mechanism combines both the strict priority and weighted round robin mechanisms. The combined method enables the Brocade device to give strict priority to delay-sensitive traffic such as VoIP traffic, and weighted round robin priority over other traffic types.



Qos-tos trust and qos-tos mark CommandsThe qos-tos trust and qos-tos mark commands are retained in 03.8.00 and later versions of the Multi-Service IronWare software as described in the following:

• The primary use of these commands is for packet remarking (without changing the internal priority of the packet if desired).

Qos-tos trust indicates the priority to be trusted on the Ingress interface (cos, dscp or ip-prec).

Qos-tos mark indicates which priority is to be marked on the Egress interface (cos or dscp).

• Qos-tos trust and qos-tos mark commands are both applied at the Ingress interface (physical or virtual).

Recognizing Inbound Packet Priorities and Mapping to Internal PriorityThe processes performed in the first block of Figure 49 can be described in two stages.

• Stage 1

Collect priority and drop precedence information from various portions of the packet header

- If a packet’s EtherType matches 8100 or the port’s EtherType, derive a priority value and drop precedence by decoding the PCP value.

- If the qos use-dei command is configured, the bit between the VLAN ID and PCP in the VLAN tag will be interpreted as a drop precedence and priority value.

- For MPLS packets, derive a priority value and drop precedence by decoding the EXP bits.

- For IPv4 or v6 packets, derive a priority value and drop precedence by decoding the DSCP bits.

- The derived values for PCP, EXP and DSCP are mapped to either a default map or a configured Ingress Decode Policy Map.

- To assist the device in the decoding process described in “stage 1” decode-map tables are defined.

• Stage 2

Determine if a priority value should be forced or merged

- If a packet EtherType matches 8100 or the port’s EtherType, derive a priority value and drop precedence by decoding the PCP value.

- If the qos pcp force command is configured on the port, the priority and drop precedence values are set to the value read from the PCP bits.

- If the qos exp force command is configured on the port, the priority and drop precedence values are set to the value read from the MPLS EXP bits.

- If the qos dscp force command is configured on the port, the priority and drop precedence values are set to the value read from the DSCP bits.

- If none of the qos force commands are configured, the priority and drop precedence values are set for IPv4 or v6 packets and MPLS packets as described in the following:

• For IPv4 or v6 Packets: Priority and drop precedence values obtained as a merge of the decoded PCP and decoded DSCP values.

• For MPLS Packets: Priority and drop precedence values obtained as a merge of the decoded PCP and decoded EXP values.



QoS Options for IP ACLsQuality of Service (QoS) options enable you to perform QoS for packets that match the ACLs. Using an ACL to perform QoS is an alternative to directly setting the internal forwarding priority based on incoming port, VLAN membership, and so on.

The following QoS ACL options are supported:

• dscp-cos-mapping – This option is similar to the dscp-matching command (described below). This option maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 – 63 DSCP values, and distributes them among eight traffic classes (internal priorities) and eight 802.1p priorities.

By default, the Brocade device does the 802.1p to CoS mapping. If you want to change the priority mapping to DSCP to CoS mapping, you must enter the following ACL statement.

permit ip any any dscp-cos-mapping

• dscp-marking – Marks the DSCP value in the outgoing packet with the value you specify.

• internal-priority-marking and 802.1p-priority-marking – Supported with the DSCP marking option, these commands assign traffic that matches the ACL to a hardware forwarding queue (internal-priority-marking), and re-mark the packets that match the ACL with the 802.1p priority (802.1p-priority-marking).

• dscp-matching – Matches on the packet DSCP value. This option does not change the packet forwarding priority through the device or mark the packet.

• 802.1p-priority-matching – Inspects the 802.1p bit in the ACL that can be used with adaptive rate limiting

802.1p Priority OverrideYou can configure a port to ignore the 802.1p priority for traffic classification for an incoming packet. When this feature is enabled, packets will be classified as follows:

• If the packet matches an ACL that defines the priority, then ACL priority will be used.

• If the packet source or destination MAC address matches a configured static MAC address with priority, then static MAC priority will be used.

• If the ingress port has a configured priority, then port priority will be used.

• If the other situations do not apply, the configured or default port priority (0) will be used.

• 802.1p priority override is supported on physical ports and trunk ports. When applied to the primary port of a trunk group, the configuration applies to all members of the trunk group.

• This feature is not supported together with trust dscp.

Note that the original 802.1p priority in the packet will be retained. This feature does not re-mark the 802.1p value.



8 — Network Security, Management and MonitoringAfter reviewing this section you should be able to do the following:

• Describe the tools used to monitor a network

• Describe the tools used to manage a network

• Demonstrate how to apply security on switches and routers

• Describe maintenance procedures for switches and routers

Network Monitoring

sFlowsFlow is a standards-based protocol that allows network traffic to be sampled at a user-defined rate for the purpose of monitoring traffic flow patterns and identifying packet transfer rates on user-specified interfaces.

When sFlow is enabled on a Layer 2 or Layer 3 switch, the system performs the following sFlow-related tasks:

• Samples traffic flows by copying packet header information

• Identifies ingress and egress interfaces for the sampled flows

• Combines sFlow samples into UDP packets and forwards them to the sFlow collectors for analysis (uses default UDP port 6343)

• Forwards byte and packet count data, or counter samples, to sFlow collectors

Port Mirroring and MonitoringPort mirroring is a method of monitoring network traffic that forwards a copy of each incoming or outgoing packet from one port on a network switch to another port where the packet can be analyzed. Port mirroring may be used as a diagnostic tool or debugging feature, especially for preventing attacks. Port mirroring can be managed locally or remotely.

Configure port mirroring by determining which port from which to copy all packets and assign a mirror port where the copies of the packets are sent. A packet received on, or issued from, the first port is forwarded to the second port. Attach a protocol analyzer on the mirror port to monitor each segment separately. The analyzer captures and evaluates the data without affecting the client on the original port.

In the following command sequence example, incoming and outgoing traffic on port e1/2/11 is copied to the mirror port, e 1/2/4, and then monitors are enabled.

FastIron(config)#mirror-port ethernet 1/2/4FastIron(config)#interface ethernet 1/2/11FastIron(config-if-e1000-11)#monitor ethernet 1/2/4 both

The mirror port may be a port on the same switch with an attached RMON probe, a port on a different switch in the same hub, or the switch processor. To configure port monitoring, first specify the mirror port, then enable monitoring on the monitored port.

• The mirror port is the port to which the monitored traffic is copied. Attach your protocol analyzer to the mirror port.

• The monitored port is the port whose traffic you want to monitor



Network Management

SNMP AccessSNMP 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.

Table 8 lists individual Brocade switches and the SNMP access methods they support. These features are supported in the Layer 2, base Layer 3, edge Layer 3, and full Layer 3 software images, except where explicitly noted.

Setting the SNMP Trap Holddown TimeWhen a Brocade device starts up, the software waits for Layer 2 convergence (STP) and Layer 3 convergence (OSPF) before beginning to send SNMP traps to external SNMP servers. Until convergence occurs, the device might not be able to reach the servers, in which case the messages are lost.

By default, a Brocade device uses a one-minute holddown time to wait for the convergence to occur before starting to send SNMP traps. After the holddown time expires, the device sends the traps, including traps such as “cold start” or “warm start” that occur before the holddown time expires.

You can change the holddown time to a value from one second to ten minutes. To change the holddown time for SNMP traps, enter a command such as the following at the global CONFIG level of the CLI.

Brocade(config)# snmp-server enable traps holddown-time 30

The command in this example changes the holddown time for SNMP traps to 30 seconds. The device waits 30 seconds to allow convergence in STP and OSPF before sending traps to the SNMP trap receiver.

Syntax: [no] snmp-server enable traps holddown-time <secs>

The <secs> parameter specifies the number of seconds and can be from 1 – 600 (ten minutes). The default is 60 seconds.

TABLE 8 Support SNMP Access Features

Feature FESXFSX 800FSX 1600

FWS FCX ICX 6610 ICX 6430ICX 6450

SNMP v1, v2, v3 Yes Yes Yes Yes Yes

Community strings Yes Yes Yes Yes Yes

User-based security model for SNMP v3 Yes Yes Yes Yes Yes

SNMP v3 traps Yes Yes Yes Yes Yes

Defining the UDP port for SNMP v3 traps Yes Yes Yes Yes Yes

SNMP v3 over IPv6 Yes Yes Yes Yes Yes

AES encryption for SNMP v3 Yes Yes Yes Yes Yes



SNTPBrocade devices can be configured as a Simple Network Time Protocol (SNTP) client. You can configure the Brocade device to consult up to three SNTP servers for the current system time and date. The first server configured will be used unless it becomes unreachable, in which case the Brocade device will attempt to synchronize with the other SNTP servers (if any) in the order in which they were configured.

You can configure Brocade devices to function as an SNTP server to its downstream clients. When using the device as an SNTP server, you can also set it to use its own internal clock as the reference source if an upstream server becomes unavailable.

Applying Security

Setting the SSH port numberBy default, SSH traffic occurs on TCP port 22. You can change this port number. For example, the following command changes the SSH port number to 2200.

Brocade(config)#ip ssh port 2200

Note that if you change the default SSH port number, you must configure SSH clients to connect to the new port. Also, you should be careful not to assign SSH to a port that is used by another service. If you change the SSH port number, Brocade recommends that you change it to a port number greater than 1024.

Syntax: ip ssh port <number>

802.1XBrocade devices support the IEEE 802.1X standard for authenticating devices attached to LAN ports. Using 802.1X port security, you can configure a Brocade device to grant access to a port based on information supplied by a client to an authentication server.

When a user logs on to a network that uses 802.1X port security, the Brocade device grants (or denies) access to network services after the user is authenticated through an authentication server. The user-based authentication in 802.1X port security provides an alternative to granting network access based on a user's IP address, MAC address, or sub network.

While the client awaits authentication, only the following traffic types are allowed on the client port:

• EAPOL – Extensible Authentication Protocol On the LAN

• FDP – Brocade Discovery Protocol

• STP –Assumes secure connection

802.1x allows MAC-based authentication.

The following are device roles in an 802.1X configuration:

• Supplicant (network device)

• Authenticator (Brocade switch)

• Authentication Server



TACACS+ versus TACACSTACACS is a simple UDP-based access control protocol originally developed by BBN for MILNET. TACACS+ is an enhancement to TACACS and uses TCP to ensure reliable delivery.

TACACS+ is an enhancement to the TACACS security protocol. TACACS+ improves on TACACS by separating the functions of authentication, authorization, and accounting (AAA) and by encrypting all traffic between the Brocade device and the TACACS+ server. TACACS+ allows for arbitrary length and content authentication exchanges, which allow any authentication mechanism to be utilized with the Brocade device. TACACS+ is extensible to provide for site customization and future development features. The protocol allows the Brocade device to request very precise access control and allows the TACACS+ server to respond to each component of that request.

Note

TACACS+ provides for authentication, authorization, and accounting, but an implementation or con-figuration is not required to employ all three.

To create an authentication method list that specifies TACACS/TACACS+ as the primary authentication method for securing Telnet/SSH access to the CLI.

Brocade(config)#enable telnet authenticationBrocade(config)#aaa authentication login default tacacs local

The commands above cause TACACS/TACACS+ to be the primary authentication method for securing Telnet/SSH access to the CLI. If TACACS/TACACS+ authentication fails due to an error with the server, authentication is performed using local user accounts instead.

Maintenance Procedures

Loading and Saving Configuration FilesFor easy configuration management, all Brocade devices support both the download and upload of configuration files between the devices and a TFTP server on the network. You can upload either the startup configuration file or the running configuration file to the TFTP server for backup and use in booting the system:

• Startup configuration file – This file contains the configuration information that is currently saved in flash. To display this file, enter the show configuration command at any CLI prompt.

• Running configuration file – This file contains the configuration active in the system RAM but not yet saved to flash. These changes could represent a short-term requirement or general configuration change. To display this file, enter the show running-config or write terminal command at any CLI prompt.

Each device can have one startup configuration file and one running configuration file. The startup configuration file is shared by both flash modules. The running configuration file resides in DRAM.

Note

Brocade devices also support Secure Copy (SCP) for securely transferring files between a Brocade device and SCP-enabled remote hosts.



File ManagementThe flash memory is divided into two different storage areas. This allows you to have two different software image versions stored in the flash memory. Secondary flash is storage space for upgrade code:

• Put new code in the secondary flash

• Schedule a reload to boot on secondary flash during low traffic periods. Unsuccessful reloads will cause the system to revert back to primary flash.

• When confidence is established in upgrade code, use the copy flash flash primary command to overwrite the old software image with the upgrade image in primary flash

• The following command copies the system image in the primary flash to the TFTP server:

- FastIron# copy flash tftp 192.22.33.44 vm1r07501.bin primary

- A failure may indicate the presence of something in the secondary flash

Note

Always use the write memory command to save configuration changes.

Password RecoveryRecovering from a lost password requires direct access to the serial port and a system reset. This procedure can only be accomplished from the console port.

To recover from a lost password:

1. Start a CLI session over the serial interface to the device and reboot it

SW-Switch# reloadAre you sure? (enter 'y' or 'n'): yHalt and reboot

2. At the initial boot prompt at system startup, enter b to enter the boot monitor mode.

3. Enter no password at the prompt

BOOT MONITOR> no passwordOK! Skip password check when the system is up.

This command will bypass the system password check, and cannot be abbreviated (this will not erase any existing passwords)

4. Enter boot system flash [primary | secondary] at the prompt

BOOT MONITOR> boot system flash primaryBOOT INFO: load from primary copy<Truncated Output>

5. Once the console prompt reappears, assign a new password.

6. Issue the write memory command to save the new password.



9 — TroubleshootingAfter reviewing this section you should be able to do the following:

• Demonstrate knowledge of troubleshooting tools and techniques

• Demonstrate ability to analyze troubleshooting output

Contacting SupportWhen contacting support there are several pieces of information about your data center that would expedite your case:

• Collect a supportsave

• Collect a show tech-support

• Have the most recent topology diagram available

• Have the most recent changes to your environment

supportsave CommandThe supportsave is an important utility for collecting logs from the driver, internal libraries, and firmware. The collected logs are shared with the technical support personnel for investigating issues seen on the device.

Note

The supportsave utility is supported only on the Brocade ICX 6430 and 6450 devices.

TFTP is used to capture supportsave data. It is disabled by default, if FIPS is enabled. Enable TFTP manually for uploading supportsave data. It is a prerequisite to have the TFTP server with a write permission and the server must be accessible from the device.

Determining STP Port StatesThe show interface brief command is a good tool to use to determine the state of the port:

Brocade(config-if-e10000-cx4-1/2/1)# show interface br1/1/4 Up Forward Full 1G None No 1 0 001b.f288.00031/2/1 Up Forward Full 16G None No 1 0 001b.f288.00191/3/1 Up Forward Full 10G None No N/A 0 001b.f288.001b3/3/1 Up Forward Full 10G None No N/A 0 0024.3814.9df3mgmt1 Up None Full 1G None No 1 0 001b.f288.0018



STP Port StatesIn the Spanning Tree algorithm, a port transitions through the states listed in to determine if it either forwards or blocks data traffic.

You can change the bridge priority, port priority, and path cost so that a predetermined outcome occurs in the election process (Learning state).

Figure 27: STP Port States

Viewing Optical Monitoring InformationYou can view temperature and power information for qualified XFPs, SFPs, and SFP+ installed in a FastIron device.

Use the show optic <port-number> command to view information about an XFP, SFP, or SFP+ installed in a particular port. The following shows example output.

TABLE 9 STP Port States

State Description

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 (RP), or a Designated Port (DP) it moves to the Learning state. If the port has no designation then it moves to the Blocking state.

Learning In the Learning state, RPs and DPs continue to block data traffic as the switches learn MAC addresses and build their MAC tables.

Forwarding The second expiration of the forwarding timer moves RPs and DPs to the Forwarding state to start forwarding traffic.

Blocking Data traffic is blocked for a non-designated port, but BPDUs are allowed to circulate.

Listening state

Blocking state

Learning state

Forwarding state

Port initialization

Port Role is established as: Root PortDesignated PortNon-Designated (15 sec)

Root and Designated Ports:Port receives data traffic Populates its MAC table (15 sec)

Non Designated Ports: Port is BlockedMAC table remains empty

Root and Designated Ports:Send and Receive data traffic



Brocade# show optic 13Port Temperature Tx Power Rx Power Tx Bias Current+----+-----------+----------+------------+-------------------+13 33.2968 C -005.4075 dBm -007.4328 dBm 6.306 mA Normal Normal Normal Normal

Optical monitoring feature will not work in the following scenarios:

• The port is DOWN.

• The port is configured as a stacking port.

• The the optic module does not support optical monitoring.

• For ICX 6430 devices only:

- If an SFP+ optic is inserted in an SFP only port, the optic will not initialize.

- If an SFP optic is inserted in an SFP+ only port, the optic will not initialize.

- If an optic is inserted into a device that supports both SFP and SFP+ optics, use the speed-duplex command to set the port speed correctly.

Interface ConfigurationEach 10/100/1000 port is designed to auto-sense and auto-negotiate the speed and mode of the connected device. If the attached device does not support this operation, the port speed may be set to operate at either 10, 100, or 1000 Mbps. The default value is for the ports to auto-sense speed and duplex. Settings should be the same at both ends.

If a port is not working or cannot connect to another switch or server, verify that the settings are correct, the port is not administratively disabled, and the cable between the source and destination is not damaged.

Recovering Disabled PortsOnce a loop is detected on a port, it is placed in Err-Disable state. The port will remain disabled until one of the following occurs:

• You manually disable and enable the port at the Interface Level of the CLI.

• You enter the command clear loop-detection. This command clears loop detection statistics and enables all Err-Disabled ports.

• The device automatically re-enables the port.

IP Packet ParametersYou can configure the following packet parameters on Layer 3 Switches. These parameters control how the Layer 3 Switch sends IP packets to other devices on an Ethernet network. The Layer 3 Switch always places IP packets into Ethernet packets to forward them on an Ethernet port.

• Encapsulation type – The format for the Layer 2 packets within which the Layer 3 Switch sends IP packets.



• Maximum Transmission Unit (MTU) – The maximum length of IP packet that a Layer 2 packet can contain. If MTU size is not the same between switches you may see a high packet loss. IP packets that are longer than the MTU are fragmented and sent in multiple Layer 2 packets. You can change the MTU globally or an individual ports:

- Global MTU – The default MTU value depends on the encapsulation type on a port and is 1500 bytes for Ethernet II encapsulation and 1492 bytes for SNAP encapsulation.

- Port MTU – A port default MTU depends on the encapsulation type enabled on the port.

802.1x Debug CommandsThe following commands displays information about 802.1x authentication events, activities, and settings.

Protocol PortsIt is common practice for network security administrators to shut down unused ports. Before calling support about an unavailable application or service, verify the port that the application or service uses (both sending and receiving) is available for that traffic.

TABLE 10 802.1x Debug Commands

Debug Type Syntax Description

debug dot1x events [no] debug dot1x events

Brocade# debug dot1x eventsdot1x: Events debugging is on

This command displays the authentications failed or succeeded and the application of VLANs or ACLs requested by the Remote Authentication Dial In User Service (RADIUS) server. This command works globally across all the ports.

debug dot1x filter [no] debug dot1x filter

Brocade# debug dot1x filterdot1x: Filter debugging is on

This command enables the 802.1x filter debugging.

debug dot1x misc [no] debug dot1x misc

Brocade# debug dot1x miscdot1x: Misc debugging is on

This command enables the 802.1x miscellaneous debugging.

debug dot1x packets [no] debug dot1x packets

Brocade# debug dot1x packetsdot1x: Packets debugging is on

This command displays information about 802.1x packets.

debug dot1x timers [no] debug dot1x timers

Brocade# debug dot1x timersdot1x: Timers debugging is on

This command displays information about 802.1x timers.



Taking the TestAfter the Introduction Screen, once you click on Next, you will see the following non-disclosure agreement:

IMPORTANT: PLEASE READ THE FOLLOWING BROCADE NON-DISCLOSURE CONFIDENTIALITY AGREEMENT CAREFULLY BEFORE TAKING THIS EXAM.

The following Non-Disclosure Confidentiality Agreement (the “Agreement”) sets forth the terms and conditions of your use of the exam materials as defined below.

The Disclosure to you of this Exam and any questions, answers, worksheets, computations, drawings, diagrams, or any communications, including verbal communication by any party, regarding or related to the Exam and such Exam Materials and any derivatives thereof is subject to the Terms and Conditions of this Agreement.

You understand, acknowledge and agree:

• That the questions and answers of the Exam are the exclusive and confidential property of Brocade and are protected by Brocade intellectual property rights;

• That you may not disclose the Exam questions or answers or discuss any of the content of the Exam Materials with any person, without prior approval from Brocade;

• Not to copy or attempt to make copies (written, photocopied, or otherwise) of any Exam Material, including, without limitation, any Exam questions or answers;

• Not to sell, license, distribute, or give away the Exam Materials, questions, or answers;

• You have not purchased, solicited or used unauthorized (non-Brocade sanctioned) Exam Materials, questions, or answers in preparation for this exam;

• That your obligations under this Agreement shall continue in effect after the Exam and, if applicable, after termination of your credential, regardless of the reason or reasons for terminations, and whether such termination is voluntary or involuntary.

Brocade reserves the right to take all appropriate actions to remedy or prevent disclosure or misuse, including, without limitation, obtaining an immediate injunction. Brocade reserves the right to validate all results and take any appropriate actions as needed. Brocade also reserves the right to use any technologies and methods for verifying the identity of candidates. Such technology may include, without limitation, personally identifiable information, challenge questions, identification numbers, photographic information, and other measures to protect against fraud and abuse.

Neither this Agreement nor any right granted hereunder shall be assignable or otherwise transferable by you.

By clicking on the "A" button (“YES, I AGREE”), you are consenting to be bound by the terms and conditions of this agreement and state that you have read this agreement carefully and you understand and accept the obligations which it imposes without reservation. You further state that no promises or representations have been made to induce agreement and that you accept this agreement voluntarily and freely.

A. YES, I AGREE

B. NO, I DO NOT AGREE

Documents

BCNE Nutshell