BCNE Nutshell - Brocade Certified Network Engineer Exam Topics

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

Brocade University Revision 0912

Corporate Headquarters - San Jose, CA USA T: (408) 333-8000 [email protected] European Headquarters - Geneva, Switzerland T: +41 22 799 56 40 [email protected] Asia Pacific Headquarters - Singapore T: +65-6538-4700 [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

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Introduction to BCNE 2012 in a Nutshell First Edition

Objective: The BCNE 2012 Nutshell guide is designed to help you prepare for the BCNE 2012 Certification, exam number 150-130. Audience: The BCNE 2012 Nutshell self-study guide is intended for those who have successfully completed the CNE 200 Brocade Certified Network Engineer Training course, and who wish to undertake self-study or review activities before taking the actual BCNE 2012 exam. The BCNE 2012 guide is not intended as a substitute for classroom training or hands-on time with Brocade products. How to make the most of the BCNE 2012 guide: The BCNE 2012 guide summarizes the key topics on the BCNE 2012 exam for you in an easy to use format. It is organized closely around the exam objectives. We suggest this guide be used in conjunction with our free online knowledge assessment test. To benefit from the BCNE 2012 guide, we strongly recommend you have successfully completed the CNE 200 Brocade Certified Network Engineer Training course. We hope you find this useful in your journey towards BCNE 2012 Certification, and we welcome your feedback by sending an email to [email protected].

Joe Cannata Certification Manager

©2012 Brocade Communications

i

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

ii

©2012 Brocade Communications

Brocade Certified Network Engineer in a Nutshell Second Edition

Table of Contents 1 — Layer1 Hardware Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Physical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Coaxial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Twisted Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fiber Optic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Form Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 2

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

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

5 5 6 6 6 7 7

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

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

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

12 13 13 15 15 15 15 15 15

Virtual Local Area Network Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1Q Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1q-in-q tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VLAN CPU Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 18 19 21 21

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

©2011 Brocade Communications

iii

Brocade Certified Network Engineer in a Nutshell Second Edition

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

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

29 30 31 33 33 33

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

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

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

Classless Inter-Domain Routing (CIDR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static IP route parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link State vs. Distance Vector (OSPF vs. RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42 43 43 44 44

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

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

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

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

iv

©2011 Brocade Communications

50 50 50 51 51 52 52

Brocade Certified Network Engineer in a Nutshell Second Edition

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

53 53 54 54

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

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

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

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

Viewing Optical Monitoring Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovering Disabled Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Packet Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1x Debug Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 60 60 60 61 61

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

©2011 Brocade Communications

v

Brocade Certified Network Engineer in a Nutshell Second Edition

vi

©2011 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

©2012 Brocade Communications

vii

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

viii

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

©2012 Brocade Communications

ix

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

x

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

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

• Cabling • Transceivers

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

Twisted Pair The most common medium is called twisted pair. This comes in many varieties. On the high level, there's Unshielded Twisted Pair (UTP) and Shielded Twisted Pair (STP). STP is expensive, and the shielding can make it difficult to bend or shape. On the other hand, the additional shielding does a better job of preventing outside interference. UTP is the most common. STP and UTP come in different grades called categories. Some of the most common categories include category 3, category 5, category 5e, and category 6. These are most commonly abbreviated to CAT3, CAT5, CAT5e, and CAT6. CAT5 uses thicker cables inside than CAT3. It also has more twists per meter. Likewise with CAT5e and CAT6, the higher the number, the thicker the copper cables and the more twists per meter. Also, the higher the category, the greater the performance. CAT3 is only rated for 10 Mbps Ethernet, while CAT5e and CAT6 are required for Gigabit.

Fiber Optic If you need lengths of cables much longer than 100 meters or your facility has a lot of EMI, use fiber. The major advantages with fiber are its attenuation limit (up to 70 km) and, because it uses light rather than electricity, it is invulnerable to EMI. It can achieve much greater speeds than its copper counterparts. The current maximum is 40 Gbps, but this is only limited by technology. The cables are made by combining fiber optic strands and insulating them. A laser light generates the signal. The more powerful the laser, the longer the attenuation limit. There are two varieties you need to be familiar with:

• Multimode Fiber (MMF) - 1000 Mbps (SX) attenuation: 550 meters - 10 Gbps (SR) attenuation: 300 meters

©2012 Brocade Communications

1

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

• Single-mode Fiber (SMF) - 1000 Mbps (LX) attenuation: 5 km - 1000 Mbps (LHA) attenuation: 70 km - 10 Gbps (LR) attenuation: 10 km - 10 Gbps (ZR) attenuation: 70 km TABLE 1

Optics Comparison Chart

Transceiver Type

Supported Speeds

4 Gbps SWL SFP 4 Gbps LWL SFP

4, 2, 1 Gbps

4 Gbps ELWL SFP 8 Gbps SWL SFP 8 Gbps LWL SFP

8, 4, 2 Gbps

10 Gbps SWL SFP+ 10 Gbps

16 Gbps SWL SFP+ 16 Gpbs LWL SFP+ 4x16 Gbps SWL QSFP

Distance at Max Speed1

OM1/OM2/OM3

380 m

Singe-mode OM1/OM2/OM3

8 Gbps ELWL SFP

10 Gbps LWL SFP+

Cable Type Used

16 Gpbs

Single-mode

10 km 30 km 150 m 10 km 25 km

OM1/OM2/OM3

300 m

Single-mode

10 km

OM1/OM2/OM3

100 m

Single-mode

10 km

MPO 1x12 ribbon2

50 km

1. The distance shown in this chart represents the maximum distance, with high quality cabling, that is available at the maximum line speed of the transceiver. Distances can actually be increased beyond what is listed by reducing transmission speed. For a full list of supported distances, speeds, and cable types for any transceiver please visit our web site: http://www.brocade.com/ products/all/transceivers/product-details/transceiver-modules/features.page. 2. The 4x16 Gbps QSFP is currently only used on the DCX8510-4 and DCX 8510-8 Backbone switches for ICL links between chassis. These switches will be covered in greater detail in the next module.

Form Factors The Small Form-factor Pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communication applications. It interfaces a network device motherboard (for a switch, router, media converter, or similar device) to a fiber optic or copper networking cable. It is a popular industry format. SFP transceivers are designed to support SONET, Gigabit Ethernet (GbE), Fibre Channel (FC), and other communications standards. The standard covers SFP+ supporting data rates up to 10 Gbps (includes 8 Gbps Fibre Channel and 10 GbE). The SFP+ has a smaller form factor than a regular SFP. If copper is required 1000 Mbit TX SFPs could be used on non-combo ports.

Figure 1: SFP Side View

2

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

The XFP is a 10 GbE small form factor pluggable transceiver for use with optical fiber. XFPs are protocol independent and used in Ethernet devices. The following form factors are supported by Brocade switches and routers:

• SFP • SFP+ • XFP

POE/POE+ When PoE is enabled on a port to which a power consuming device or PD is attached, by default, a Brocade PoE device will supply 15.4 watts of power at the RJ-45 jack, minus any power loss through the cables. A PoE+ device will supply either 15.4 or 30 watts of power (depending on the type of PD connected to the port), minus any power loss through the cables. For example, a PoE port with a default maximum power level of 15.4 watts will receive a maximum of 12.95 watts of power after 2.45 watts of power loss through the cable. To configure the maximum power level for a power consuming device, enter commands such as the following: Brocade#configure terminal Brocade(config)# interface ethernet 1/1 Brocade(config-if-e1000-1/1)# inline power power-limit 14000 These commands enable in-line power on interface ethernet 1 in slot 1 and set the PoE power level to 14,000 milliwatts (14 watts). Syntax: inline power power-limit The 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: CAT3 Type2: CAT5/5e

PSE current (A)

0.35

Type1: 0.35 Type2: 0.60

PSE voltage (Vdc)

44-57

Type1: 44-57 Type2: 50-57

PD current (A)

0.35

Type1: 0.35 Type2: 0.60

PD voltage (Vdc)

37-57

Type1: 37-57 Type2: 47-57

©2012 Brocade Communications

3

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

TABLE 2

IEEE 802.23a PoE and 802.23at PoE+

Feature

802.23af PoE

802.23at PoE+

Maximum PD wattage (W)

Class 0, 3: 12.95 Class 1: 3.84 Class 2: 6.49 Class 4: unused

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

PD Classification Requirement

Optional 1-Event classification

Required Type1: 1-event classification Type2: 2-event classification and LLDP

Note

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

Detection of PoE Power Requirements There are two ways for the powered devices to dynamically request the PoE power from the 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 LLDPenabled devices in the same 802 LAN segments. LLDP Media Endpoint Devices (LLDP-MED) is the Layer 2 network discovery protocol extension to LLDP described in the ANSI/TIA-1057 standard. This protocol enables a PoE switch to configure and manage connected powered devices that need to send media streams across the network (for example, IP phones and security cameras). LLDP enables network discovery between network connectivity devices (such as switches), whereas LLDP-MED enables network discovery at the edge of the network, between network connectivity devices and media endpoint devices (such as IP phones).

4

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Hardware Platforms ICX 6430 and 6450 Product Overview • Offers enterprise-class stackable switching at an entry-level price

-

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

• Delivers feature/price value for applications including:

-

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

• Provides availability for low-cost switching: - Redundant uplink/stacking ports, hitless stacking failover, and configurable power redundancy

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

-

Combines chassis-like capabilities with an economical fixedport solution

• Includes IPv4 and IPv6 Layer 3 capabilities as a standard feature on all models • Provides non-stop availability with: - Hitless stacking failover - Hot insertion/removal of stacked units - Internal redundant hot-swappable power supplies and fans FCX Series: Data Center vs. Campus Offerings

TABLE 3

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

©2012 Brocade Communications

5

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

FastIron SX Series • Price/performance value for campus aggregation and core switching • Provides a scalable, secure, low-latency, and fault-tolerant infrastructure for 1 GbE and 10 GbE enterprise deployments

• High-performance architecture with: - Up to 128 x 10 GbE and 384 x 1 GbE ports • Supports IPv4/IPv6- capable Layer 2/3 switching and routing • Highly available design with: - Multi-Chassis Trunking (MCT) - Redundant management modules (with hitless failover) - Switch fabrics - Stateful OSPF redundancy; graceful BGP and OSFP restarts; and hitless In-Service Software Upgrades (ISSU)

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

• Non-blocking, cut-through architecture, wirespeed

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

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

• • • • •

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

ServerIron ADX Series • Enables high-speed application delivery by leveraging a purpose-built architecture designed with high core density and embedded application accelerators

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

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

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

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

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

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

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

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

• Complete suite of IPv4/IPv6 unicast and multicast routing with fast convergence times • Advanced QoS features to enforce strict SLAs at the edge of the network

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

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

• Wire-speed ports in a single router: • 1536 x 1 GbE or 256 x 10 GbE or 32 x 100 GbE • Wire-speed IPv4, IPv6, and MPLS forwarding performance with 1 million IPv4 routes in hardware

• High-availability design with: - Redundant management modules, switch fabrics; hitless failover; hitless software upgrades; and non-stop routing

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

• • • • • • • • •

Management by a single IP address Support for up to eight units per stack. ICX 6430 supports only up to four units in the stack Flexible stacking ports Linear and ring stack topology support Secure-setup utility to make stack setup easy and secure Active Controller, Standby Controller, and member units in a stack Active Controller management of entire stack Active Controller download of software images to all stack units Standby Controller for stack redundancy

©2012 Brocade Communications

7

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

• Active Controller maintenance of information database for all stack units • Packet switching in hardware between ports on stack units • All protocols operate on an IronStack in the same way as on a chassis system

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

MCT Terminology

Figure 2MCT Components

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

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

8

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

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

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

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

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

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

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

• • • • • • • •

MDUP: MAC Database Update Protocol CL: Cluster Local MACs CCL: Cluster Client Local MACs CR: Cluster Remote MACs CCR: Cluster Client Remote MACs CCRR: Cluster Client RBridge Reachability MDB: Mac Data Base. The MDB can have multiple MAC entries for the same address FDB: Forwarding MAC Database. The FDM will have the best MAC only installed

©2012 Brocade Communications

9

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

• • • • • • • •

10

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

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

• • • •

Describe Layer 2 protocols Identify Layer 2 functionality Identify different VLAN implementations Describe the different link aggregation (LAG) implementations

Enabling or Disabling Layer 2 Switching By default, Brocade devices supports routing over Layer 2 switching. You can enable Layer 2 switching globally or on individual port using the no route-only command. The no route-only and route-only commands prompts you to change the route-only behavior. You must enter y if you want to proceed or n if you do not. The prompt is displayed as shown in the following examples of the no route-only and route-only commands. To enable Layer 2 switching globally, enter the following. Brocade(config)# no route-only This will change the route-only behavior at the global level. Are you sure? (enter ‘y’ or ‘n’): y Global ‘route-only’ committed. To enable Layer 2 switching only on a specific interface, go to the Interface configuration level for that interface, and

add the no route-only command. The following command shows how to enable Layer 2 switching on port 3/2. Brocade(config)# interface ethernet 3/2 Brocade(config-if-e10000-3/2)# no route-only To globally disable Layer 2 switching on a Brocade device and return to the default (route-only) condition, enter commands such as the following: Brocade(config)# route-only This will change the route-only behavior at the global level. Are you sure? (enter ‘y’ or ‘n’): y Global ‘no route-only committed.

Layer 2 Protocols A protocol is a set of rules that governs the communications between computers on a network These rules include guidelines that regulate the following characteristics of a network:

• • • •

Access method Allowed physical topologies Transport medium Speed of data transfer

©2012 Brocade Communications

11

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

The Root Bridge When STP begins, a selection process is made to determine which redundant paths to keep forwarding user traffic and which ones to shut down. BPDUs are sent. Root bridge is used as a reference point by all other switches in the network for eliminating loops, and determining when an alternate path is required due to a topology change. It has (numerically) the lowest bridge ID (BID). By default, each bridge has a configurable priority number, called the bridge priority, and a unique MAC address. The BID is a combination of the bridge priority and the MAC address. The lowest numerical BID has the highest priority for root bridge selection. All other switches in the network calculate path cost to the root bridge to determine which ports will be used, and which will be blocked to eliminate loops. The switch with the lowest Bridge ID (BID) becomes the root bridge. All Brocade switches have the default bridge priority 32768. If that is the case, the lowest MAC address is used. In 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

12

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

The switch with the lowest BID wins and becomes the Root Bridge. If Bridge Priorities are the same, the switch with the lowest MAC address wins and becomes the Root Bridge. Root Bridge (Priority:0) Switch#1 00:0E:80:0A:F0:06

DP

DP

RP

RP Switch#3

DP

Switch#2 00:0E:80:01:F0:06

00:0E:80:01:90:06

(Priority:100)

(Priority:200) 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 Span When STP is running on a device, message forwarding is delayed during the spanning tree recalculation period following a topology change. The STP forward delay parameter specifies the period of time a bridge waits before forwarding data packets. The forward delay controls the listening and learning periods of STP reconvergence. You can configure the forward delay to a value from 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.

©2012 Brocade Communications

13

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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:

-

14

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

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

BPDU Guard In an STP environment, switches, end stations, and other Layer 2 devices use Bridge Protocol Data Units (BPDUs) to exchange information that STP will use to determine the best path for data flow. The BPDU guard, an enhancement to STP, removes a node that reflects BPDUs back in the network. It enforces the STP domain borders and keeps the active topology predictable by not allowing any network devices behind a BPDU guard-enabled port to participate in STP.

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

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

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

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

• System name ©2012 Brocade Communications

15

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

• System description • System capabilities • Management address The information distributed by LLDP is stored by the receiving device in a standard Management Information Base (MIB). The information can be viewed by a Network Management System or from the CLI. The Foundry Discovery Protocol (FDP) enables Brocade devices to advertise themselves to other Brocade devices on the network. When you enable FDP on a Brocade device, the device periodically advertises information including the following:

• • • •

Hostname (device ID) Product platform and capability Software version VLAN and Layer 3 protocol address information for the port sending the update (IP, IPX, and AppleTalk Layer 3 information is supported)

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

• Creates a broadcast domain • Done through software configuration • Implemented in port switching, hubs and LAN switches By default, all Brocade switch ports are members of VLAN 1. VLANs reduce the time it takes to implement moves, adds and changes. Layer 3 VLANs require that all members are in the same port-based VLAN.

16

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

There are three types of VLANs:

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

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

• Protocol-based A subset of ports within a Layer 2 port-based VLAN organized according to the Layer 3 protocol type. L3 protocolbased VLAN for IPX

L3 protocolbased VLAN for IPv6

L2 portbased VLAN 20

L3 protocolbased VLAN for IPv4

Figure 5: Types of VLANs

Private VLANs Platform support:

• • • •

FastIron X Series devices running software release 02.4.00 and later FGS and FLS devices running software release FGS-STK and FLS-STK devices running software release 05.0.00 and later FWS devices running software release 04.3.00 and later

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

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

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

©2012 Brocade Communications

17

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Private VLAN Port-Based VLAN Forwarding among Private VLAN ports

Figure 6 Private VLAN

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

• You cannot configure isolated, community, or primary VLANs on 802.1Q tagged ports • Normally, in any port-based VLAN, the device floods unknown unicast, unregistered multicast, and broadcast packets in hardware, although selective packets, such as IGMP, may be sent to only to the CPU for analysis, based on the IGMP snooping configuration.

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

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

• Tagged the switch adds an extra 4 bytes to the Ethernet frame called the 802.1Q header - Allows multiple port based VLANs to span switches over a single physical link • Untagged the switch keeps track of this port as a member of the VLAN 802.1Q tagging is an IEEE standard that allows a networking device to add information to a Layer 2 frame in order to identify its VLAN membership. A port can belong to only one port-based VLAN, unless 802.1Q tagging is applied to the port. Note

VLAN Without 802.1Q tagging is where the Ports require dedicated uplinks for each VLAN between switches. There is no question where broadcast traffic went from port-to-port. 802.1Q tagging allows the port to add a four-byte field, which contains the VLAN ID, to each frame sent on the port. Port-based VLANs can also be configured to span multiple devices by tagging the ports within the VLAN. The tag enables each device that receives the frame to determine to which VLAN the frame belongs. 802.1Q tagging applies only to Layer 2 VLANs.

18

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Figure 7: VLAN Tagging

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

Figure 8: 802.1Q Tagging (Packet Format)

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

©2012 Brocade Communications

19

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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 retagged when they are sent out of the uplink towards the provider. The 802.1Q tag-type on the uplink port is 8100, so the Brocade device will switch the frames to the uplink device with an additional 8100 tag, thereby supporting devices that only support this method of VLAN tagging.

20

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Virtual Interfaces The Brocade device sends Layer 3 traffic at Layer 2 within a protocol-based VLAN. However, Layer 3 traffic from one protocol-based VLAN to another must be routed. If you want the device to be able to send Layer 3 traffic from one protocol-based VLAN to another on the same device, you must configure a virtual routing interface on each protocol-based VLAN, then configure routing parameters on the virtual routing interfaces. A virtual routing interface is a logical routing interface that the Brocade device uses to route Layer 3 protocol traffic between protocol-based VLANs. It is a logical port on which you can configure Layer 3 routing parameters. A virtual interface can have multiple IP addresses. For example, to enable a Brocade device to route IP traffic from one IP protocol VLAN to another, you must configure a virtual routing interface on each IP protocol VLAN, then configure the appropriate IP routing parameters on each of the virtual routing interfaces. Hosts in a VLAN can use the IP address of the virtual interface as their default gateway.

Link Aggregation Implementations Trunking is another term for Link Aggregation. Link Aggregation allows an administrator to combine multiple Ethernet links into a larger logical trunk known as a Link Aggregation Group (LAG). The switch treats the trunk as a single logical link. The physical links must all be the same speed and duplex setting and must connect to the same adjacent switch including stackable switches1. LAG requirements may vary for different platforms, such as the number of links in the LAG, specific port boundaries2. Always check what is supported at both ends The rules for LAGs are heavily dependent on the hardware type and code version in use. All interface parameters in a LAG must match, including:

• Port tag type (tagged/untagged) • Configured port speed3 and duplex • QoS priority

1. Link Aggregation Groups are also referred to as: Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Port Trunking, Link Bundling, EtherChannel, Multi-Link Trunking (MLT), DMLT, SMLT, DSMLT, R-SMLT, NIC bonding, Network Fault Tolerance (NFT), and Fast EtherChannel. 2. Multi-Chassis Trunking is a technology that allows multiple switches to appear as a single logical switch connecting to another switch using a standard LAG. Since the technology is an enhancement to the standard LAG protocol, a single MCT-unaware server or switch using a standard LAG trunk can connect to two MCT-aware switches--and the traffic is dynamically load balanced. For more information on this topic, please refer to the FastIron Configuration Guide for the particular platform. 3. Each port in the LAG operates at the speed of the slowest link. For example, if one LAG is created with 2 ports and one is running at 10 Gbps and the other is running at 1 Gbps; each link operates at 1 Gbps. This behavior occurs if the ports are configured to auto and negotiate to different speeds.

©2012 Brocade Communications

21

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Figure 11: Link Aggregation

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

• Benefits of trunking: - Load-sharing - Redundancy There are two types of trunking:

• Static trunking - Manually configured aggregate links containing multiple ports • Dynamic Trunking: (802.3ad Link Aggregation) - Dynamically created and managed trunk groups using Link Aggregation Control Protocol (LACP) Trunking can be established between Brocade Layer 2/3 switches, or between a switch and a server.

LAG Formation Rules The LAG formation rules are mentioned below:

• You cannot configure a port concurrently as a member of a static, dynamic, or keep-alive LAG. • Any number or combination of ports between 1 and 32 within the same chassis can be used to configure a LAG. The maximum number of LAG ports is checked when adding ports to a LAG.

• • • •

All ports configured in a LAG must be of equal bandwidth. For example all 10 Gbps ports. All ports configured in a LAG must be configured with the same port attributes. LAG formation rules are checked when a static or dynamic LAG is deployed. A LAG must have its primary port selected before it can be deployed.

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

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

• All static LAG ports must have the same LACP BPDU forwarding configuration. • VLAN and inner-VLAN translation

Configuring Keys for Ports with Link Aggregation Enabled Syntax: [no] link-aggregate configure [system-priority ] | [port-priority ] | [key ]

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

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

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

©2012 Brocade Communications

23

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Address Resolution Protocol Address Resolution Protocol (ARP) is used to associate a Layer 3 (Network layer) address, such as an IP address, with a Layer 2 (Data Link layer) address (MAC address). ARP is used to resolve MAC addresses for hosts on the local subnet; for remote destinations, the source host sends out ARP requests asking for the MAC address of the default gateway. If a node matches the requested IP, it sends back its MAC address. Other nodes discard the ARP request.

Figure 12: ARP

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

End-to-End Packet Flow The following example details how a packet is routed from Host A to Host B on another subnet or network address. 1. If the destination 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

24

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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.

©2012 Brocade Communications

25

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Figure 14: End-to-End Flow Example 2 of 4

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.

26

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Figure 15: End-to-End Flow Example 3 of 4

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.

©2012 Brocade Communications

27

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

Figure 16: End-to-End Flow Example 4 of 4 Note

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

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

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

28

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

• • • • •

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

Designated Router (DR) OSPF has a Designated Router which receives all the updates on a given segment. The Backup Designated Router is the second-in-command. This router receives the updates, too, but does not send them back out. When a router needs to update other routers, it sends the update to the Designated Router and the Backup Designated Router. The Designated Router sends the update to all of the other routers on its segment. When the Designated Router becomes unavailable, the Backup Designated Router instantly becomes the Designated Router, and an election is held to see who becomes the next Backup Designated Router. This way, each router need not be aware of all of the OSPF routers involved. It needs only to communicate its updates (and receive updates) from a single source. This minimizes traffic, and allows the OSPF design to expand nicely, as needed.

Figure 17: OSPF DR Election

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

©2012 Brocade Communications

29

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

1. The Router ID can be manually configured using the global ip router-id x.x.x.x command. 2. If the Router ID is not manually configured, the IP address configured on the lowest numbered loopback interface is used as the Router ID 3. If there is no loopback interface, then the router ID is the lowest numbered IP address configured on the device When only one router on the network claims the DR role despite neighboring routers with higher priorities or router IDs; this router remains the DR. This is also true for BDRs. The DR and BDR election process is performed when one of the following events occurs: 1. An interface is in a waiting state and the wait time expires 2. An interface is in a waiting state and a hello packet is received that addresses the BDR 3. A change in the neighbor state occurs, such as, a neighbor state transitions from 2 or higher, communication to a neighbor is lost, or a neighbor declares itself to be the DR or BDR for the first time

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

• • • • •

Subnet mask Hello/Dead intervals Area-ID Authentication password Stub area flag

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

• Down: The router has not sent a Hello packet, nor has it received one • Init: A Hello packet has been sent to a neighbor, but no Hello packet has been received from that neighbor • 2 Way: The router has sent a Hello packet to a neighbor, and has received a Hello packet back; the reply will contain your router's Router ID inside; now, your router knows that the neighbor knows your router as well The next three states are referred to as the adjacency process. To establish adjacency means that your OSPF database is synchronized with your neighbor (there's currently no further information to share).

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

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

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

30

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

New York

San Jose

Los Angeles Figure 18: OSPF Areas

Area Types:

• Area 0 - Backbone - A required area to which all other areas must connect • Ordinary or standard area (Normal or transit area) - All routers in a OSPF area have the same topological database, but their routing tables are based on the 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

©2012 Brocade Communications

31

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

OSPF Autonomous System (AS) is the entire OSPF routing domain. An OSPF AS can be divided into multiple areas. The propagation of Types 1 and 2 Link State Advertisements is limited to the bounds of an area. An OSPF router can be a member of multiple areas. These routers are known as Area Border Routers (ABRs). Each ABR maintains a separate topological database for each area the router is in. Each topological database contains all of the LSAs within a given area. The routers within the same area have identical topological databases. The ABR is responsible for forwarding routing information or changes between its border areas. An Autonomous System Boundary Router (ASBR) is a router that is running multiple protocols and serves as a gateway to routers outside an AS. The ASBR is able to import and translate different protocols routes into OSPF through a process known as redistribution.

Figure 19: OSPF AS

OSPF Virtual Links OSPF virtual links allow administrators to work around the requirement that all other areas must connect directly to the backbone. If the new area cannot connect directly to the backbone area, two ABRs are set up to “bridge” the gap and recreate the connectivity. The configuration commands pass area information between ABRs in the intermediary area. From the viewpoint of OSPF, each ABR has a direct connection to three areas (Area 0, the outlying area, and the area traversed). This scenario may emerge in a variety of cases:

• Merge or failure isolates an area from Area 0 • The area is critical to the company, and an extra link has been configured for redundancy Requirement to create a virtual link:

• Both routers must share a common area 32

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

OSPFs Four Level Routing Hierarchy • • • •

Level 1 - Intra-area routing Level 2 - Inter-area routing Level 3 - External Type 1 Metrics Level 4 - External Type 2 Metrics

If there are two routing paths to choose from then paths that are internal to an OSPF routing domain are preferred over external routes. External routes can be imported into the OSPF domain at two separate levels, one that has Type 1 Metrics and the other Type 2 Metrics. The use of Type 1 metrics assumes that in the path from the OSPF router to the destination, the internal OSPF AS component (path to the ASBR advertising the AS-external-LSA) and external component are of the same importance. In Type 2 metrics, it is assumed that only the external component is more significant than the internal component. The aggregate cost to these external destinations does not change when viewed from different routers, since the internal costs are not important. But the cost of Intra-area and Inter-area destinations does change depending on which router the cost is observed.

Loopback Interfaces You should configure a loopback interface on the router that is participating in OSPF. The loopback address does not belong to a particular interface. If you have a router participating in OSPF with several physical links, the router will have to be identified by the IP address of one of those links (the Router ID). This means that If that link goes down the router would have to start the neighboring process all over again using a new Router ID. If you use a loopback address, the Router ID does not change. Also, it is not contingent on whether one of the physical interfaces is up or down. The loopback is the IP address of the device, not an individual interface. Common practice would be to choose a unique /30 network (some even use a /32 network), assign an IP address to a loopback interface, and assign that interface to be a member of a particular area.

Link State Advertisement Link State Advertisement (LSA) is an OSPF data packet that communicates the router's local routing topology to all other local routers in the same OSPF area. OSPF Link State process: 1. Link State Advertisements exchanged between routers 2. Topology Database is built 3. Router runs Shortest Path First (SPF) algorithm to calculate the best path 4. SPF tree is generated

©2012 Brocade Communications

33

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

34

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

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.

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

• Two thousand and one, colon, colon, forty-nine, colon, seventeen Two options are defined to shorten IPv6 address expressions

©2012 Brocade Communications

35

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Shortened Expression

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

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

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

-

The double colon may be used only once in an address

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 of Incorrect Use Note

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

Virtual Router Redundancy Protocol - Enhanced Virtual 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.

36

©2012 Brocade Communications

Brocade Certified Network Engineer 2012 in a Nutshell First Edition

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

Figure 20 VRRP-E

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

• The router interfaces in a VRID must be in the same IP subnet • The Hello/Dead intervals must be set to the same values on all the VRRP-E enabled devices • The Virtual IP (VIP) address must be configured the same on routers belonging to the same VRRP-E backup group Router_A(config)# router VRRPExtended Router_A(config)# interface e1 Router_A(config-if-1)# ip address 192.53.5.2 Router_A(config-if-1)# ip VRRPExtended vrid 1 Router_A(config-if-1-vrid-1)# backup priority 110 track-priority 20 Router_A(config-if-1-vrid-1)# ip-address 192.53.5.1