BCNE Nutshell - Brocade Certified Network Engineer Exam Topics

74  Download (0)

Full text


BCNE 2012 in a

Nutshell Study Guide

for Exam 150-130


T: (408) 333-8000

European Headquarters - Geneva, Switzerland T: +41 22 799 56 40

Asia Pacific Headquarters - Singapore T: +65-6538-4700

© 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.


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

Joe Cannata

Certification Manager


Table of Contents

1 — Layer1 Hardware Concepts . . . 1

Physical Media . . . 1 Coaxial. . . 1 Twisted Pair . . . 1 Fiber Optic. . . 1 Form Factors . . . 2 POE/POE+. . . 3

Detection of PoE Power Requirements . . . 4

2 — Brocade Hardware Platforms . . . 5

Hardware Platforms . . . 5

ICX 6430 and 6450 Product Overview. . . 5

FastIron CX Series . . . 5

FastIron SX Series . . . 6

Brocade VDX 6730 Data Center Switches . . . 6

ServerIron ADX Series . . . 6

NetIron CER Series. . . 7

NetIron MLXe Series . . . 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 . . . 12

Bridge Protocol Data Units (BPDUs) . . . 13

Fast Port Span . . . 13

Root Guard . . . 15

BPDU Guard . . . 15

ACL Overview . . . 15

IGMP Snooping Overview. . . 15

802.1W Rapid Spanning Tree (RSTP) . . . 15

Device Discovery Protocols . . . 15

Virtual Local Area Network Implementations . . . 16

Private VLANs . . . 17

802.1Q Tagging . . . 18

802.1q-in-q tagging . . . 19

VLAN CPU Protection . . . 21

Virtual Interfaces . . . 21

Link Aggregation Implementations . . . 21


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). . . 29

Neighbor Adjacency . . . 30

Areas . . . 31

OSPFs Four Level Routing Hierarchy . . . 33

Loopback Interfaces . . . 33

Link State Advertisement . . . 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). . . 42

Administrative Distance . . . 43

Static IP route parameters. . . 43

Link State vs. Distance Vector (OSPF vs. RIP) . . . 44

IGMP Snooping . . . 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 . . . 50

QoS for Brocade Stackable Devices . . . 50

QoS Queueing Methods . . . 50

Qos-tos trust and qos-tos mark Commands . . . 51

Recognizing Inbound Packet Priorities and Mapping to Internal Priority . . . 51

QoS Options for IP ACLs . . . 52


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

Network Monitoring . . . 53

sFlow . . . 53

Port Mirroring and Monitoring. . . 53

Network Management . . . 54

SNMP Access . . . 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 . . . 59

Interface Configuration . . . 60

Recovering Disabled Ports. . . 60

IP Packet Parameters. . . 60

802.1x Debug Commands. . . 61

Protocol Ports . . . 61


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


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


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:




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


Single-mode Fiber (SMF)


1000 Mbps (LX) attenuation: 5 km


1000 Mbps (LHA) attenuation: 70 km


10 Gbps (LR) attenuation: 10 km


10 Gbps (ZR) attenuation: 70 km

Form 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

TABLE 1 Optics Comparison Chart

Transceiver Type Supported Speeds Cable Type Used Distance at Max Speed1

1. The distance shown in this chart represents the maximum distance, with high quality cabling, that is available at the maximum line speed of the transceiver. Distances can actually be increased beyond what is listed by reducing transmission speed. For a full list of supported distances, speeds, and cable types for any transceiver please visit our web site: products/all/transceivers/product-details/transceiver-modules/ 4 Gbps SWL SFP 4, 2, 1 Gbps OM1/OM2/OM3 380 m 4 Gbps LWL SFP Singe-mode 10 km 4 Gbps ELWL SFP 30 km 8 Gbps SWL SFP OM1/OM2/OM3 150 m 8 Gbps LWL SFP 8, 4, 2 Gbps Single-mode 10 km 8 Gbps ELWL SFP 25 km 10 Gbps SWL SFP+ OM1/OM2/OM3 300 m 10 Gbps LWL SFP+ 10 Gbps Single-mode 10 km 16 Gbps SWL SFP+ OM1/OM2/OM3 100 m 16 Gpbs LWL SFP+ 16 Gpbs Single-mode 10 km 4x16 Gbps SWL QSFP MPO 1x12 ribbon2

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


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:





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

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

Brocade(config)# interface ethernet 1/1

Brocade(config-if-e1000-1/1)# inline power power-limit 14000

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

Syntax: inline power power-limit <power level>

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

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

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

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



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 LLDP-enabled devices in the same 802 LAN segments.

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

Maximum PD wattage (W) Class 0, 3: 12.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


Type1: 1-event classification

Type2: 2-event classification and LLDP

TABLE 2 IEEE 802.23a PoE and 802.23at PoE+


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 fixed-port solution

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

Provides non-stop availability with:


Hitless stacking failover


Hot insertion/removal of stacked units


Internal redundant hot-swappable power supplies and fans

TABLE 3 FCX Series: Data Center vs. Campus Offerings

Data Center Feature Campus

No PoE Yes (PoE models)

No Stacking ports Yes

4 10 GbE ports 2

SFP+ 10 GbE type XFP

Optional GbE combo ports built-in Front-to-back (reversible) Airflow Side-to-back


FastIron SX Series

Price/performance value for campus aggregation and core switching

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

High-performance architecture with:


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

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

Highly available design with:


Multi-Chassis Trunking (MCT)


Redundant management modules (with hitless failover)


Switch fabrics


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

Brocade VDX 6730 Data Center Switches

32- and 76-port models with Ports on Demand (PoD)

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

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

Ethernet storage connectivity for FCoE, iSCSI, and NAS storage

Multihop FCoE and iSCSI Data Center Bridging (DCB) support

10 Gbps and 1 Gbps supported on every LAN port;

2,4, and 8 Gbps on FC ports

Direct-attached copper SFP and SFP optical connectivity options

Reversible front-to-back airflow

ServerIron ADX Series

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

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

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

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

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


NetIron CER Series

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

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

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

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

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

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

NetIron MLXe Series

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

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

Wire-speed ports in a single router:

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

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

High-availability design with:


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

Hardware Platform Features

Brocade IronStack 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


Active Controller maintenance of information database for all stack units

Packet switching in hardware between ports on stack units

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

Brocade IronStack topologies

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

MCT Terminology

Figure 2MCT Components

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

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


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

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

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

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

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

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

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

MDUP: MAC Database Update Protocol

CL: Cluster Local MACs

CCL: Cluster Client Local MACs

CR: Cluster Remote MACs

CCR: Cluster Client Remote MACs

CCRR: Cluster Client RBridge Reachability

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


Multi-Chassis Trunking

The following FastIron features are not supported with MCT:



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


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


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.


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

Figure 3: Root Bridge

Bridge Protocol Data Units (BPDUs)

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

The following are BPDU types:

Configuration BPDU

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

Topology Change Notification (TCN) BPDU

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

Fast Port 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.

Switch#3 00:0E:80:01:90:06 Switch#1 (Priority:100) (Priority:200) DP DP DP RP RP Root Bridge (Priority:0) Switch#2 00:0E:80:0A:F0:06 00:0E:80:01:F0:06


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

Figure 4: Fast Port Span

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

Reduces the number of STP topology change notifications on the network

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

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

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


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


The port is a member of a trunk group


The port has learned more than one active MAC address


An STP configuration BPDU has been received on the port, thus indicating the presence of another bridge on the port


Root 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 description

System capabilities

Management address

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

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

Hostname (device ID)

Product platform and capability

Software version

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

Virtual Local Area Network Implementations

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

Creates a broadcast domain

Done through software configuration

Implemented in port switching, hubs and LAN switches

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


There are three types of VLANs:


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


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


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

Figure 5: Types of VLANs

Private 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

L2 port-based VLAN 20

L3 protocol-based VLAN for IPv4

L3 protocol-based VLAN for IPv6

L3 protocol-based VLAN for IPX


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

Figure 6 Private VLAN

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

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

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

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

802.1Q 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.


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

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

Private VLAN Port-Based VLAN Forwarding among Private VLAN ports


Figure 7: VLAN Tagging

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

Figure 8: 802.1Q Tagging (Packet Format)

802.1q-in-q tagging


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

Figure 9 SAV Configuration Example

As shown in Figure 9, the ports to customer interfaces are untagged, whereas the uplink ports to the provider cloud are tagged, because multiple client VLANs share the uplink to the provider cloud. In this example, the Brocade device treats the customer’s private VLAN ID and 8100 tag type as normal payload, and adds the 9100 tag type to the packet when the packet is sent to the uplink and forwarded along the provider cloud. As long as the switches in the provider’s network support the 9100 tag type, the data gets switched along the network. However, devices that do not support the 9100 tag type may not properly handle the packets.

Figure 10 802.1 Q-in-Q Configuration Example

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


VLAN CPU 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


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:





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.


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


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

VLAN and inner-VLAN translation

Configuring Keys for Ports with Link Aggregation Enabled

Syntax: [no] link-aggregate configure [system-priority <num>] | [port-priority <num>] | [key <num>]

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

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

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

Configuring Load Sharing Type

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

Command and Output of show lag

Brocade(config)# show lag

Total number of LAGs: 1

Total number of deployed LAGs: 1

Total number of s created:1 (127 available)

LACP System Priority / ID: 1 / 0000.0001.c000 LACP Long timeout: 90, default: 90 LACP Short timeout: 3, default: 3 === LAG "lag1" ID 124 (static Deployed) === LAG Configuration:

Ports: ethe 1/2 to 1/3 Port Count: 2

Primary Port: 1/3 Type: hash-based

Deployment: ID 124, Active Primary 1/2

Port Link L2 State Dupl Speed Tag Priori MAC Name

1/2 Up Forward Full 10G 124 No level0 0000.0001.c002 1/3 Up Forward Full 10G 124 No level0 0000.0001.c002


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


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 is different from the source Host A’s Network ID of 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 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 and the frame can be sent on the wire.


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 is the destination network where these packets need to be routed. It also notices the next hop IP of which represents the next stop for the packets on its way to the 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 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.


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 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 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


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 decre-mented by 1.

Private Networks (RFC 1918)

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

TABLE 4 RFC 1918

Class Address Range

A — B — C 192.168.0./16 —


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.


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


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



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.

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 instead

San Jose

Los Angeles


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:




Related subjects :