Académique Documents
Professionnel Documents
Culture Documents
Corporate Headquarters - San Jose, CA USA T: (408) 333-8000 info@brocade.com European Headquarters - Geneva, Switzerland T: +41 22 799 56 40 emea-info@brocade.com Asia Pacific Headquarters - Singapore T: +65-6538-4700 apac-info@brocade.com
2012 Brocade Communications Systems, Inc. All Rights Reserved. Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, MLX, SAN Health, VCS, and VDX are registered trademarks, and AnyIO, Brocade One, CloudPlex, Effortless Networking, ICX, NET Health, OpenScript, and The Effortless Network are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be trademarks of their respective owners. Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability.Export of technical data contained in this document may require an export license from the United States government. Revision 0912
Objective: The BCNE 2012 Nutshell guide is designed to help you prepare for the BCNE 2012 Certification, exam number 150-130. Audience: The BCNE 2012 Nutshell self-study guide is intended for those who have successfully completed the CNE 200 Brocade Certified Network Engineer Training course, and who wish to undertake self-study or review activities before taking the actual BCNE 2012 exam. The BCNE 2012 guide is not intended as a substitute for classroom training or hands-on time with Brocade products. How to make the most of the BCNE 2012 guide: The BCNE 2012 guide summarizes the key topics on the BCNE 2012 exam for you in an easy to use format. It is organized closely around the exam objectives. We suggest this guide be used in conjunction with our free online knowledge assessment test. To benefit from the BCNE 2012 guide, we strongly recommend you have successfully completed the CNE 200 Brocade Certified Network Engineer Training course. We hope you find this useful in your journey towards BCNE 2012 Certification, and we welcome your feedback by sending an email to jcannata@brocade.com.
ii
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
iii
Mapping of IPv4 Multicast Group Addresses to Ethernet MAC Addresses . . . . . . . . . . . . . . . . . . . . . 34 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IPv6 Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
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
iv
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
Viewing Optical Monitoring Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovering Disabled Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Packet Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1x Debug Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59 60 60 60 61 61
vi
List of Figures
SFP Side View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 MCT Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Root Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Fast Port Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Types of VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 VLAN Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 802.1Q Tagging (Packet Format) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 SAV Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 802.1 Q-in-Q Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 End-to-End Flow Example 1 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 End-to-End Flow Example 2 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 End-to-End Flow Example 3 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 End-to-End Flow Example 4 of 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 OSPF DR Election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 OSPF AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 VRRP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 Multiple VRRP-E Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Supernetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Standard ACL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Policy-based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
vii
viii
List of Tables
Optics Comparison Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 IEEE 802.23a PoE and 802.23at PoE+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 FCX Series: Data Center vs. Campus Offerings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 RFC 1918 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Classful versus Classless Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Default Administrative Distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Support SNMP Access Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 STP Port States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 802.1x Debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
ix
Physical Media
Physical media are the physical devices that transmit raw bits across a network. They include, but are not limited to the following:
Cabling Transceivers
Coaxial
The coaxial cable has one thin strand of copper in the middle of it, surrounded by quite a bit of insulation. This is surrounded by an additional meshwork of copper, which is, in turn, surrounded by more insulation. This cable is designed to carry an electrical signal.
Twisted Pair
The most common medium is called twisted pair. This comes in many varieties. On the high level, there's Unshielded Twisted Pair (UTP) and Shielded Twisted Pair (STP). STP is expensive, and the shielding can make it difficult to bend or shape. On the other hand, the additional shielding does a better job of preventing outside interference. UTP is the most common. STP and UTP come in different grades called categories. Some of the most common categories include category 3, category 5, category 5e, and category 6. These are most commonly abbreviated to CAT3, CAT5, CAT5e, and CAT6. CAT5 uses thicker cables inside than CAT3. It also has more twists per meter. Likewise with CAT5e and CAT6, the higher the number, the thicker the copper cables and the more twists per meter. Also, the higher the category, the greater the performance. CAT3 is only rated for 10 Mbps Ethernet, while CAT5e and CAT6 are required for Gigabit.
Fiber Optic
If you need lengths of cables much longer than 100 meters or your facility has a lot of EMI, use fiber. The major advantages with fiber are its attenuation limit (up to 70 km) and, because it uses light rather than electricity, it is invulnerable to EMI. It can achieve much greater speeds than its copper counterparts. The current maximum is 40 Gbps, but this is only limited by technology. The cables are made by combining fiber optic strands and insulating them. A laser light generates the signal. The more powerful the laser, the longer the attenuation limit. There are two varieties you need to be familiar with:
Multimode Fiber (MMF) - 1000 Mbps (SX) attenuation: 550 meters - 10 Gbps (SR) attenuation: 300 meters
Single-mode Fiber (SMF) - 1000 Mbps (LX) attenuation: 5 km - 1000 Mbps (LHA) attenuation: 70 km - 10 Gbps (LR) attenuation: 10 km - 10 Gbps (ZR) attenuation: 70 km
TABLE 1
Transceiver Type 4 Gbps SWL SFP 4 Gbps LWL SFP 4 Gbps ELWL SFP 8 Gbps SWL SFP 8 Gbps LWL SFP 8 Gbps ELWL SFP 10 Gbps SWL SFP+ 10 Gbps LWL SFP+ 16 Gbps SWL SFP+ 16 Gpbs LWL SFP+ 4x16 Gbps SWL QSFP
1. The distance shown in this chart represents the maximum distance, with high quality cabling, that is available at the maximum line speed of the transceiver. Distances can actually be increased beyond what is listed by reducing transmission speed. For a full list of supported distances, speeds, and cable types for any transceiver please visit our web site: http://www.brocade.com/ products/all/transceivers/product-details/transceiver-modules/features.page. 2. The 4x16 Gbps QSFP is currently only used on the DCX8510-4 and DCX 8510-8 Backbone switches for ICL links between chassis. These switches will be covered in greater detail in the next module.
Form Factors
The Small Form-factor Pluggable (SFP) is a compact, hot-pluggable transceiver used for both telecommunication and data communication applications. It interfaces a network device motherboard (for a switch, router, media converter, or similar device) to a fiber optic or copper networking cable. It is a popular industry format. SFP transceivers are designed to support SONET, Gigabit Ethernet (GbE), Fibre Channel (FC), and other communications standards. The standard covers SFP+ supporting data rates up to 10 Gbps (includes 8 Gbps Fibre Channel and 10 GbE). The SFP+ has a smaller form factor than a regular SFP. If copper is required 1000 Mbit TX SFPs could be used on non-combo ports.
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:
POE/POE+
When PoE is enabled on a port to which a power consuming device or PD is attached, by default, a Brocade PoE device will supply 15.4 watts of power at the RJ-45 jack, minus any power loss through the cables. A PoE+ device will supply either 15.4 or 30 watts of power (depending on the type of PD connected to the port), minus any power loss through the cables. For example, a PoE port with a default maximum power level of 15.4 watts will receive a maximum of 12.95 watts of power after 2.45 watts of power loss through the cable. To configure the maximum power level for a power consuming device, enter commands such as the following: Brocade#configure terminal Brocade(config)# interface ethernet 1/1 Brocade(config-if-e1000-1/1)# inline power power-limit 14000 These commands enable in-line power on interface ethernet 1 in slot 1 and set the PoE power level to 14,000 milliwatts (14 watts). Syntax: inline power power-limit <power level> The <power level> variable is the maximum power level in number of milliwatts. The following values are supported:
PoE: Enter a value from 1000 through 15,400. The default is 15,400. PoE+: Enter a value from 1000 through 30,000. The default is 30,000.
Table2 provides a side-by-side comparison of PoE nad PoE+.
TABLE 2
Feature
Cable requirement PSE current (A) PSE voltage (Vdc) PD current (A) PD voltage (Vdc)
802.23at PoE+
Type1: CAT3 Type2: CAT5/5e Type1: 0.35 Type2: 0.60 Type1: 44-57 Type2: 50-57 Type1: 0.35 Type2: 0.60 Type1: 37-57 Type2: 47-57
TABLE 2
Feature
802.23at PoE+
Type1, Class 0, 3: 12.95 Type1, Class 1: 3.84 Type1, Class 2: 6.49 Type2, Class 4: 25.5 Required Type1: 1-event classification Type2: 2-event classification and LLDP
PD Classification Requirement
Note
The 802.3at standard currently supports POE+ on 10/100/1000 Mbps Ethernet ports operating over standard Category 5 Unshielded Twisted Pair (UTP) cable or better. If your network uses cabling categories lower than 5, you cannot implement PoE+ without first upgrading your cables to CAT 5 UTP or better.
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
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
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
Data Center
No No 4 SFP+ Optional Front-to-back (reversible)
Campus
Yes (PoE models) Yes 2 XFP built-in Side-to-back
FastIron SX Series
Price/performance value for campus aggregation and core switching Provides a scalable, secure, low-latency, and fault-tolerant infrastructure
for 1 GbE and 10 GbE enterprise deployments
High-performance architecture with: - Up to 128 x 10 GbE and 384 x 1 GbE ports Supports IPv4/IPv6- capable Layer 2/3 switching and routing Highly available design with: - Multi-Chassis Trunking (MCT) - Redundant management modules (with hitless failover) - Switch fabrics - Stateful OSPF redundancy; graceful BGP and OSFP restarts; and hitless In-Service Software Upgrades
(ISSU)
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
Eases the transition to IPv6 with full performance and feature parity between IPv6 and IPv4 as well as
scalable, standards-based translation technology
6
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
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
Management by a single IP address Support for up to eight units per stack. ICX 6430 supports only up to four units in the stack Flexible stacking ports Linear and ring stack topology support Secure-setup utility to make stack setup easy and secure Active Controller, Standby Controller, and member units in a stack Active Controller management of entire stack Active Controller download of software images to all stack units Standby Controller for stack redundancy
Active Controller maintenance of information database for all stack units Packet switching in hardware between ports on stack units All protocols operate on an IronStack in the same way as on a chassis system
MCT Terminology
MCT peer switches: A pair of switches connected as peers through the ICL. The LAG interface is spread
across two MCT peer switches and it acts as the single logical endpoint to the MCT client.
MCT client: The MCT client is the device that connects with MCT peer switches through an IEEE 802.3ad
link. It can be a switch or an endpoint server host in the single-level MCT topology or another pair of MCT switches in a multi-tier MCT topology.
MCT Inter-Chassis Link (ICL): A single-port or multi-port GbE or 10 GbE interface between the two MCT
peer switches. This link is typically a standard IEEE 802.3ad Link Aggregation interface. ICL ports should not be untagged members of any VLAN. The ICL is a tagged Layer 2 link, which carries packets for multiple VLANs. MCT VLANs are the VLANs on which MCT clients are operating. On the Brocade NetIron XMR or Brocade MLX series, non-MCT VLANs can co-exist with MCT VLANs on the ICL. However, on the Brocade NetIron CES and Brocade NetIron CER, only MCT VLANs are carried over ICL.
MCT Cluster Communication Protocol (CCP): A Brocade proprietary protocol that provides reliable, point-topoint transport to synchronize information between peers. CCP comprises two main components: CCP peer management and CCP client management. CCP peer management deals with establishing, and maintaining TCP transport session between peers, while CCP client management provides event-based, reliable packet transport to CCP peers.
MCT Cluster Client Edge Port (CCEP): A physical port on one of the MCT peer switches that is a member of
the LAG interface to the MCT client. To have a running MCT instance, at least one Link Aggregation Interface is needed with a member port on each peer switch.
MCT Cluster Edge Port (CEP): A port on MCT peer switches that is neither a Cluster Client Edge Port nor an
ICL port.
MCT VLANs: VLANs on which MCT clients are operating. These VLANs are explicitly configured in the MCT
configuration by the user. NOTE: For MCT VLANs, MAC learning is disabled on ICL ports, while MAC learning is enabled on ICL port for non-MCT VLANs.
MCT Session VLANs: The VLAN used by the cluster for control operations. CCP protocol runs over this
VLAN. The interface can be a single link or LAG port. If it is LAG port, it should be the primary port of the LAG. Note: MCT session VLAN's subnet will not be distributed in routing protocols using redistribute commands
RBridge ID: RBridge ID is a value assigned to MCT nodes and clients to uniquely identify them, and helps
in associating Source MAC with a MCT node.
MDUP: MAC Database Update Protocol CL: Cluster Local MACs CCL: Cluster Client Local MACs CR: Cluster Remote MACs CCR: Cluster Client Remote MACs CCRR: Cluster Client RBridge Reachability MDB: Mac Data Base. The MDB can have multiple MAC entries for the same address FDB: Forwarding MAC Database. The FDM will have the best MAC only installed
Multi-Chassis Trunking
The following FastIron features are not supported with MCT:
LACP on ICL MSTP, VSRP, RIP, OSPF, IS-IS, and BGP IPv6, VRRP-E (IPv6), and VRRPv3 GRE on the ICL VE interfaces DAI on the CCEPs Host security features (port MAC security, multi-port authentication, 802.1X, DAI, DHCP snooping) on CCEPs Multi-port ARP on ICL or CCEPs Web authentication on MCT VLANs
10
Describe Layer 2 protocols Identify Layer 2 functionality Identify different VLAN implementations Describe the different link aggregation (LAG) implementations
add the no route-only command. The following command shows how to enable Layer 2 switching on port 3/2. Brocade(config)# interface ethernet 3/2 Brocade(config-if-e10000-3/2)# no route-only To globally disable Layer 2 switching on a Brocade device and return to the default (route-only) condition, enter commands such as the following: Brocade(config)# route-only This will change the route-only behavior at the global level. Are you sure? (enter y or n): y Global no route-only committed.
Layer 2 Protocols
A protocol is a set of rules that governs the communications between computers on a network These rules include guidelines that regulate the following characteristics of a network:
Access method Allowed physical topologies Transport medium Speed of data transfer
11
12
The switch with the lowest BID wins and becomes the Root Bridge. If Bridge Priorities are the same, the switch with the lowest MAC address wins and becomes the Root Bridge.
Root Bridge (Priority:0) Switch#1
00:0E:80:0A:F0:06
DP
DP
RP Switch#3
00:0E:80:01:90:06
RP DP Switch#2
00:0E:80:01:F0:06
(Priority:200)
Figure 3: Root Bridge
(Priority:100)
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.
13
The Fast Port Span feature allows certain ports to enter the forwarding state in four seconds. It allows faster convergence on ports that are attached to end stations and do not cause Layer 2 forwarding loops. Because the end stations cannot cause forwarding loops, they can safely go through the STP state changes (blocking to listening to learning to forwarding) more quickly than is allowed by the standard STP convergence time. The purpose of Fast Port and Fast Uplink are to remedy the latency of 802.1d failover at critical network locations. The 802.1d timers could be changed to cut down the 30 second convergence, however, this could lead to network instability.
Fast Port Span performs the convergence on these ports in four seconds (two seconds for listening and two seconds for learning). In addition, Fast Port Span enhances overall network performance in the following ways:
Reduces the number of STP topology change notifications on the network Eliminates unnecessary MAC cache aging that can be caused by topology change notifications When STP sends a topology change notification, devices that receive the notification use the value of the
STP forward delay to quickly age out their MAC caches
If a port matches any of the following criteria, it port is ineligible for Fast Port Span and uses normal STP
instead:
The port is 802.1Q tagged (refer to 802.1Q Tagging on page18) The port is a member of a trunk group The port has learned more than one active MAC address An STP configuration BPDU has been received on the port, thus indicating the presence of another bridge on the port
14
Root Guard
The standard STP (802.1D), RSTP (802.1W) or 802.1S does not provide any way for a network administrator to securely enforce the topology of a switched layer 2 network. The forwarding topology of a switched network is calculated based on the root bridge position, along with other parameters. This means any switch can be the root bridge in a network as long as it has the lowest bridge ID. The administrator cannot enforce the position of the root bridge. A better forwarding topology comes with the requirement to place the root bridge at a specific predetermined location. Root Guard can be used to predetermine a root bridge location and prevent rogue or unwanted switches from becoming the root bridge.
BPDU Guard
In an STP environment, switches, end stations, and other Layer 2 devices use Bridge Protocol Data Units (BPDUs) to exchange information that STP will use to determine the best path for data flow. The BPDU guard, an enhancement to STP, removes a node that reflects BPDUs back in the network. It enforces the STP domain borders and keeps the active topology predictable by not allowing any network devices behind a BPDU guard-enabled port to participate in STP.
ACL Overview
Brocade devices support rule-based ACLs (sometimes called hardware-based ACLs), where the decisions to permit or deny packets are processed in hardware and all permitted packets are switched or routed in hardware. All denied packets are also dropped in hardware. In addition, FastIron FWS devices support inbound ACLs only. Outbound ACLs are not supported on those devices. FSX, FCX, and ICX devices support both inbound and outbound ACLs.
System name
2012 Brocade Communications
15
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)
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
Port-based
A group of ports which constitutes a Layer 2 broadcast domain. This allows you to divide your user traffic into logical network segments.
MAC-base
The MAC-based VLAN feature controls network access, by authenticating a host source MAC address, and mapping the incoming packet source MAC to a VLAN
Protocol-based
A subset of ports within a Layer 2 port-based VLAN organized according to the Layer 3 protocol type.
L3 protocolbased VLAN for IPX L2 portbased VLAN 20 L3 protocolbased VLAN for IPv6
Private VLANs
Platform support:
FastIron X Series devices running software release 02.4.00 and later FGS and FLS devices running software release FGS-STK and FLS-STK devices running software release 05.0.00 and later FWS devices running software release 04.3.00 and later
By default, a private VLAN does not forward broadcast or unknown-unicast packets from outside sources into the private VLAN. If needed, you can override this behavior for broadcast packets, unknown-unicast packets, or both. You can configure a combination of the following types of private VLANs:
Primary: The primary private VLAN ports are promiscuous. They can communicate with all the isolated
private VLAN ports and community private VLAN ports in the isolated and community VLANs that are mapped to the promiscuous port.
Isolated: Broadcast and unknown unicast traffic received on isolated ports are sent only to the primary
port. They are not flooded to other ports in the isolated VLAN
17
Community: Broadcast and unknown unicast traffic received on community ports are sent to the primary
port and also are flooded to the other ports in the community VLAN
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
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.
802.1q-in-q tagging
802.1Q-in-Q tagging enables you to configure 802.1Q tag types on a group of ports, such as LAG
19
ports, thereby enabling the creation of two identical 802.1Q tags (802.1Q-in-Q tagging) on a single device. This feature improves Super Aggregated VLANs (SAV) interoperability between Brocade devices and other vendor devices that support the 802.1Q tag types, but are not very flexible with the tag types they accept.
As shown in Figure9, the ports to customer interfaces are untagged, whereas the uplink ports to the provider cloud are tagged, because multiple client VLANs share the uplink to the provider cloud. In this example, the Brocade device treats the customers private VLAN ID and 8100 tag type as normal payload, and adds the 9100 tag type to the packet when the packet is sent to the uplink and forwarded along the provider cloud. As long as the switches in the providers network support the 9100 tag type, the data gets switched along the network. However, devices that do not support the 9100 tag type may not properly handle the packets.
In Figure10, the untagged ports (to customer interfaces) accept frames that have any 802.1Q tag other than the configured tag-type 9100. These packets are considered untagged on this incoming port and are retagged when they are sent out of the uplink towards the provider. The 802.1Q tag-type on the uplink port is 8100, so the Brocade device will switch the frames to the uplink device with an additional 8100 tag, thereby supporting devices that only support this method of VLAN tagging.
20
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.
Port tag type (tagged/untagged) Configured port speed3 and duplex QoS priority
1. Link Aggregation Groups are also referred to as: Ethernet trunk, NIC Teaming, Port Channel, Port Teaming, Port Trunking, Link Bundling, EtherChannel, Multi-Link Trunking (MLT), DMLT, SMLT, DSMLT, R-SMLT, NIC bonding, Network Fault Tolerance (NFT), and Fast EtherChannel. 2. Multi-Chassis Trunking is a technology that allows multiple switches to appear as a single logical switch connecting to another switch using a standard LAG. Since the technology is an enhancement to the standard LAG protocol, a single MCT-unaware server or switch using a standard LAG trunk can connect to two MCT-aware switches--and the traffic is dynamically load balanced. For more information on this topic, please refer to the FastIron Configuration Guide for the particular platform. 3. Each port in the LAG operates at the speed of the slowest link. For example, if one LAG is created with 2 ports and one is running at 10 Gbps and the other is running at 1 Gbps; each link operates at 1 Gbps. This behavior occurs if the ports are configured to auto and negotiate to different speeds.
21
Brocade switches support the use of static and dynamic LAGs on the same device4, but can use only one type of LAG for any given port.
In addition to traffic load sharing, trunk groups provide redundant, alternate paths for traffic if any of the segments fail.
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.
You cannot configure a port concurrently as a member of a static, dynamic, or keep-alive LAG. Any number or combination of ports between 1 and 32 within the same chassis can be used to configure
a LAG. The maximum number of LAG ports is checked when adding ports to a LAG.
All ports configured in a LAG must be of equal bandwidth. For example all 10 Gbps ports. All ports configured in a LAG must be configured with the same port attributes. LAG formation rules are checked when a static or dynamic LAG is deployed. A LAG must have its primary port selected before it can be deployed.
4. Multiple LAGs can be created on a switch with some of them being static LAGs and some of them being dynamic LAGs. A single port can only be part of one LAG type. 22
All ports configured in a LAG must be configured in the same VLAN. All ports must have the same PBR configuration before deployment. During deployment, the configuration
on the primary port is replicated to all ports. On undeployment, each port inherits the same PBR configuration.
All static LAG ports must have the same LACP BPDU forwarding configuration. VLAN and inner-VLAN translation
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.
23
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.
24
then the destination Host B would be considered local; Otherwise the packets will be forwarded to the default gateway in order to be sent to a remote host. In this example the destination Host Bs Network ID of 192.168.3.0 is different from the source Host As Network ID of 192.168.1.0 and therefore the packets will need to be routed to the destination Host B. 2. The source Host A must check its own Local Route Table for its default gateway (this is the general behavior unless a special route has been defined). The default gateway IP is the IP of the routing interface for that subnet. In this example it is 192.168.1.1 which is the IP of Router 1 Interface E1. Since this is an Ethernet LAN, Host A will need to encapsulate the frame in order to sent it out to the routing interface of E1 and to do so it needs to know the MAC address of the routing interface. If it is not in its local cache an ARP broadcast will need to be initiated in order to send the encapsulated frames to the routing interface (E1 on Router1).
3. In Figure14, the default gateways MAC address is not in Host As cache. Host A initiates a local ARP broadcast request attempting to resolve the IP address to a physical MAC address. 4. Router 1 responds with a unicast ARP response to Host A with its MAC address of 22. 5. Host A creates/encapsulates an Ethernet frame with its own MAC 11 as the source and a destination MAC address of 22. Notice the destination IP still remains 192.168.3.20 and the frame can be sent on the wire.
25
6. Once Interface E1 on R1 receives the Ethernet frame it looks at the destination MAC address of the frame to check it if matches his own in order to determine if he is the recipient of the frame. In this case R1 interface E1 is the default gateway of Host A and therefore the intended recipient. R1 checks the frames Type field and notices 0x800 which indicates that there is an IP packet in the data portion of the Ethernet frame. R1 then proceeds to decapsulate the Ethernet frame in order to analyze the destination IP of the packet. 7. The Router must then consult its routing table to determine what to do with the packet. In general terms it looks to identify network routes in its table which would include the destination IP address as a host address on that network. Note: If there are several viable routes to the destination network it will chose the route with the longest subnet mask match. How routing tables become populated and an in depth look of how they are evaluated are beyond the scope of this example and class. After viewing R1s routing table it finds that the network address of 192.168.3.0 is the destination network where these packets need to be routed. It also notices the next hop IP of 192.168.2.2 which represents the next stop for the packets on its way to the 192.168.3.0 network and this can be reached through local interface E2. 8. In order for R1 to do the frame encapsulation process it needs to know the MAC address of the 192.168.2.2 interface. So it must check its local ARP cache and again if the MAC address is not found, it must send an ARP broadcast to request the MAC address. In this case it will be already present. Therefore the frame encapsulation process can continue. Notice that the source and destination IP addresses stay the same but the source MAC becomes 33 and the destination MAC becomes 44. Also note that it also will decrement the Time to Live field of the packet (in the IP header) by 1. Now the packet is sent on the wire.
26
9. Once Interface E1 on R2 receives the Ethernet frame, it looks at the destination MAC address of the frame to check it if matches his own in order to determine if he is the recipient of the frame. In this case R2 interface E1 is the next hop IP of R1 and therefore the intended recipient. R2 checks the frames Type field and notices 0x800 which indicates that there is an IP packet in the data portion of the Ethernet Frame. R2 then proceeds to decapsulate the Ethernet frame in order to analyze the destination IP of the packet. 10. R2 must then consult its routing table to determine what to do with the packet. After consulting its routing table it finds that the Network Address of 192.168.3.0 is the destination network where these packets need to be forwarded and this is a directly connected route in its table through interface E2. 11. In order for R2 to do the frame encapsulation process it needs to know the MAC address of the final destination host B with the IP 192.168.3.20. So it must check its local ARP cache and again if the MAC address is not found it must be a ARP broadcast to resolve the IP Address to a matching physical MAC address. In this case it will be already present and therefore the frame encapsulation process can continue. Notice that the source MAC is 55 and the destination MAC becomes 66. Now the frame(s) are sent on the wire. 12. Once Host B receives the frame, it recognizes its own MAC address. It then decapsulates the frame and notices that itself is the intended host with an IP of 192.168.3.20.
27
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.
RFC 1918
Address
10.0.0.0/8 172.16.0.0/12 192.168.0./16
Range
10.0.0.0 10.255.255.255 172.16.0.0 172.31.255.255 192.168.0.0 192.168.255.255
28
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) election is done by selecting the neighboring router with the highest priority. The router with the next largest priority is elected as the Backup DR (BDR). If the DR goes offline, the BDR automatically becomes the DR. The router with the next highest priority becomes the new BDR. If two neighbors share the same priority, the router with the highest router ID is designated as the DR.
29
1. The Router ID can be manually configured using the global ip router-id x.x.x.x command. 2. If the Router ID is not manually configured, the IP address configured on the lowest numbered loopback interface is used as the Router ID 3. If there is no loopback interface, then the router ID is the lowest numbered IP address configured on the device When only one router on the network claims the DR role despite neighboring routers with higher priorities or router IDs; this router remains the DR. This is also true for BDRs. The DR and BDR election process is performed when one of the following events occurs: 1. An interface is in a waiting state and the wait time expires 2. An interface is in a waiting state and a hello packet is received that addresses the BDR 3. A change in the neighbor state occurs, such as, a neighbor state transitions from 2 or higher, communication to a neighbor is lost, or a neighbor declares itself to be the DR or BDR for the first time
Neighbor Adjacency
OSPF defines a neighbor as a router that has an interface with an IP address in the same broadcast domain. The following parameters must match to become neighbors:
Subnet mask Hello/Dead intervals Area-ID Authentication password Stub area flag
Neighbor States
The neighbors on a given router will go through six states on their way to fully becoming synchronized with its routing table. The first three states are referred to as the neighboring process. These are the states neighbors go through in order to establish themselves as neighbors.
Down: The router has not sent a Hello packet, nor has it received one Init: A Hello packet has been sent to a neighbor, but no Hello packet has been received from that neighbor 2 Way: The router has sent a Hello packet to a neighbor, and has received a Hello packet back; the reply
will contain your router's Router ID inside; now, your router knows that the neighbor knows your router as well The next three states are referred to as the adjacency process. To establish adjacency means that your OSPF database is synchronized with your neighbor (there's currently no further information to share).
Ex-Start: This is short for Exchange Start; this is where the DR/BDR election takes place; routers are
sending Hello packets to determine who will become the DR and BDR
Exchange: Now the neighbors are finally talking; in this state, your router is sharing everything it knows,
and the neighbor router is sharing everything it knows
Full: We're adjacent! The neighbors have no more information to share; they've shared it all
30
Areas
Routers in OSPF are split into different groups called areas. The purpose is to reduce traffic and CPU load. The area that is the most restrictive uses the least resources (CPU and memory). Areas may be organized in any way that makes the most sense for a particular network. Areas are assigned numbers on the range of 1 through 4,294,967,295. Enabling OSPF logging is good for troubleshooting.
New York
San Jose
Los Angeles
Figure 18: OSPF Areas
Area Types:
Area 0 - Backbone - A required area to which all other areas must connect Ordinary or standard area (Normal or transit area) - All routers in a OSPF area have the same topological database, but their routing tables are based on
the routers position in the area and are unique to the router
Stub area - An area that does not accept external routes but accepts routes from within the same autonomous
system
Not So Stubby Area (NSSA) - A stub area does not accept external summary routes from the backbone, but can advertise external
summary routes into the backbone
Totally stubby area - This area wont accept routes from any other area. The Area Border Router (ABR) advertises 0.0.0.0/0
instead
31
OSPF Autonomous System (AS) is the entire OSPF routing domain. An OSPF AS can be divided into multiple areas. The propagation of Types 1 and 2 Link State Advertisements is limited to the bounds of an area. An OSPF router can be a member of multiple areas. These routers are known as Area Border Routers (ABRs). Each ABR maintains a separate topological database for each area the router is in. Each topological database contains all of the LSAs within a given area. The routers within the same area have identical topological databases. The ABR is responsible for forwarding routing information or changes between its border areas. An Autonomous System Boundary Router (ASBR) is a router that is running multiple protocols and serves as a gateway to routers outside an AS. The ASBR is able to import and translate different protocols routes into OSPF through a process known as redistribution.
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:
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
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.
33
5. Best routes are selected from SPF tree, and entered into the routing table, based on cost to individual networks LSA Types (by type code)
Type 1: Router LSA - generated by each router for each area to which it belongs. Type 2: Network LSA - generated by DRs describing the set of routers attached to a particular network. Type 3: Network Summary LSA - generated by ABRs describing inter-area routes. Type 4: ASBR Summary LSA - generated by ABRs advertising the IP address of the ASBR. Type 5: External LSA - generated by the ASBR describing networks external to the Autonomous System (AS). converts Type 7 LSAs into type 5 before flooding them into the backbone area (area 0).
Type 7: NSSA External LSA - generated by ASBR and only flooded within the Not-So-Stubby area. The ABR
By default, the device sends summary LSAs (LSA type 3) into stub areas. You can further reduce the number of link state advertisements (LSA) sent into a stub area by configuring the device to stop sending summary LSAs (type 3 LSAs) into the area. You can disable the summary LSAs when you are configuring the stub area or later after you have configured the area. To disable summary LSAs for a stub area, enter commands such as the following. Brocade(config-ospf-router)# area 40 stub 99 no-summary
34
Address Structure
Depends on the type of the unicast address:
Multicast An address for a set of interfaces belonging to different nodes. Sending a packet to a multicast address results in the delivery of the packet to all interfaces in the set. An address for a set of interfaces belonging to different nodes. Sending a packet to an anycast address results in the delivery of the packet to the closest interface identified by the address.
Aggregatable global addressAn address equivalent to a global or public IPv4 address. The address structure is as follows: a fixed prefix of 2000::/3 (001), a 45-bit global routing prefix, a 16-bit subnet ID, and a 64-bit interface ID. Site-local addressAn address used within a site or intranet. (This address is similar to a private IPv4 address.) A site consists of multiple network links. The address structure is as follows: a fixed prefix of FEC0::/10 (1111 1110 11), a 16-bit subnet ID, and a 64-bit interface ID. Link-local addressAn address used between directly connected nodes on a single network link. The address structure is as follows: a fixed prefix of FE80::/10 (1111 1110 10) and a 64-bit interface ID. IPv4-compatible addressAn address used in IPv6 transition mechanisms that tunnel IPv6 packets dynamically over IPv4 infrastructures. The address embeds an IPv4 address in the low-order 32 bits and the high-order 96 bits are zeros. The address structure is as follows: 0:0:0:0:0:0:A.B.C.D. Loopback addressAn address (0:0:0:0:0:0:0:1 or ::1) that a switch can use to send an IPv6 packet to itself. You cannot assign a loopback address to a physical interface. Unspecified addressAn address (0:0:0:0:0:0:0:0 or ::) that a node can use until you configure an IPv6 address for it.
A multicast address has a fixed prefix of FF00::/8 (1111 1111). The next 4 bits define the address as a permanent or temporary address. The next 4 bits define the scope of the address (node, link, site, organization, global). An anycast address looks similar to a unicast address, because it is allocated from the unicast address space. If you assign a unicast address to multiple interfaces, it is an anycast address. An interface assigned an anycast address must be configured to recognize the address as an anycast address. An anycast address can be assigned to a switch only. An anycast address must not be used as the source address of an IPv6 packet.
Anycast
35
1. Leading zeros in each 16-bit field are optional Standard Expression 2001:0000:130F:0000:0000:00C0:876A: 12EB Shortened Expression 2001:0:130F:0:0:00C0:876A:12EB
The double colon may be used only once in an address Double Colon Use 2001:0:130F::C0:876A:12EB 2001::1 ::1 :: 2001::130F::C0:876A:2EB
For a default route, enter 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx (use ::/0 for the <mask-bits> if you specify the address in CIDR format).
36
The Virtual IP (VIP) is a unique IP address on the same subnet as the VRRP-E routers. There is no concept of an owner IP address, as a real interface IP is not used. The elected master hosts the VIP address and answers ICMP requests. VRRP-E uses UDP (port 8888) to send multicast hello messages to 224.0.0.2, the multicast address. The VIP address can be reached by the use of ping. All switches participating in VRRP-E with the same VRID group must have the same Virtual IP address.
Figure 20 VRRP-E
The following command sequence sets up and activates VRRP-E. It follows the configuration rules which state the following:
The router interfaces in a VRID must be in the same IP subnet The Hello/Dead intervals must be set to the same values on all the VRRP-E enabled devices The Virtual IP (VIP) address must be configured the same on routers belonging to the same VRRP-E
backup group Router_A(config)# router VRRPExtended Router_A(config)# interface e1 Router_A(config-if-1)# ip address 192.53.5.2 Router_A(config-if-1)# ip VRRPExtended vrid 1 Router_A(config-if-1-vrid-1)# backup priority 110 track-priority 20 Router_A(config-if-1-vrid-1)# ip-address 192.53.5.1 <-- Virtual IP Router_A(config-if-1-vrid-1)# track-port e15 e16 Router_A(config-if-1-vrid-1)# activate Router_B(config)# router VRRPExtended Router_B(config)# interface e1 Router_B(config-if-1)# ip address 192.53.5.3 Router_B(config-if-1)# ip VRRPExtended vrid 1 Router_B(config-if-1-vrid-1)# backup priority 80 Router_B(config-if-1-vrid-1)# ip-address 192.53.5.1 Router_B(config-if-1-vrid-1)# activate
<-- Virtual IP
37
In Figure21, Router A and Router B use VRRP-E to load share as well as provide redundancy to the hosts. The load sharing is accomplished by creating two VRRP-E groups. Each group has its own virtual IP address. Half of the clients point to virtual IP address of VRID 1 as their default gateway and the other half point to virtual IP address of VRID 2 as their default gateway. This enables some of the outbound Internet traffic to go through Router A and the rest to go through Router B. VRRP-E reduces the priority of a VRRP-E interface by the amount of a tracked interface's priority if the tracked interface's link goes down. For example, if the VRRP-E interface's priority is 200 and a tracked interface with track priority 20 goes down, the software changes the VRRP-E interface's priority to 180. If another tracked interface goes down, the software reduces the VRIDs priority again, by the amount of the tracked interface's track priority.
38
Router A is the master for VRID 1 (backup priority = 110) and Router B is the backup for VRID 1 (backup priority = 100). RouterA and RouterB both track the uplinks to the Internet. If an uplink failure occurs on Router A, its backup priority is decremented by 20 (track priority = 20), so that all traffic destined to the Internet is sent through Router B instead. Similarly, RouterB is the master for VRID 2 (backup priority = 110) and RouterA is the backup for VRID 2 (backup priority = 100). Router A and Router B are both tracking the uplinks to the Internet. If an uplink failure occurs on RouterB, its backup priority is decremented by 20 (track priority = 20), so that all traffic destined to the internet is sent through RouterA instead.
39
5 Routing Concepts
When you have completed reviewing this section be sure you can do the following:
Describe general routing concepts Describe how to implement the OSPF protocol Describe multicast routing
Routing Tables
A router uses its routing table to determine the next hop for the packet's destination and forwards the packet appropriately5. The next router repeats this process using its own routing table until the packet reaches its destination. At each stage, the IP address in the packet header is used to determine the next hop. If either a destination network or a default route are not in the routing table, the packet is dropped.
Explicit default route - IPv4 default route 0.0.0.0 0.0.0.0 or 0.0.0.0/0 - Can be a static route or learned dynamically by a routing protocol like OSPF. OSPF uses a command
called default-information originate to send the default route to other OSPF routers
5. When an IP packet is to be forwarded, a router uses its routing table to determine the next hop for the packet's destination (based on the destination IP address in the IP packet header), and forwards the packet appropriately. The next router then repeats this process using its own routing table, and so on until the packet reaches its destination. At each stage, the IP address in the packet header is sufficient information to determine the next hop; no additional protocol headers are required. 40
Candidate default route - A Candidate default network is used when a default route is not statically configured or propagated by
a routing protocol
The command ip route 0.0.0.0 0.0.0.0 209.157.1.1 is a default route or route of last resort because it is last place in the order of execution of the route table. The ip route 0.0.0.0 0.0.0.0 209.157.1.1 can appear in a route table because it is:
Manually configured on the router Can be sent to other routers by a routing protocol like OSPF The command ip default-network 209.157.1.0 is a default network route and is there in case
a default route is not present because it has neither been manually configured nor passed by routing protocol like OSPF
41
Static Routes
A static route is a route manually created by a network administrator to instruct a router how to reach a particular remote network. A local next hop IP address or a local outgoing interface number can be used in the static route configuration. Each router in the path needs a next hop route.
ip ip ip ip
Because of the Internet evolution there was a real concern that in the IPv4 address space, especially
Class B addresses would be exhausted
Running out of capacity in the global routing tables Eventual exhaustion of the entire 32-bit IP address space
The motivation behind CIDR implementations was allocating IP address space more efficiently. CIDR is used instead of handing out full classful addresses (A or B) to organizations that were not fully utilizing the entire address space. The convention states that you can represent the number of network bits in a subnet mask, by adding a number after a forward slash (/) character. For example, 10.0.0.0, in classful networking, has a subnet mask of 255.0.0.0 (Class A). This means that the network portion has eight bits. Using CIDR, we would represent this same network like this: 10.0.0.0/8. Notice that I used the network address (10.0.0.0), followed it by a forward slash (/), and then followed that by the number of network bits in the subnet mask (8, in this example).
TABLE 6
Classful versus Classless Networks From 1.0.0.0 128.0.0.0 192.0.0.0 1.0.0.0. To 127.255.255.255 191.255.255.255 223.255.255.255 223.255.255.255 Mask or Prefix 255.0.0.0 255.255.0.0 255.255.255.0 /1-32 (Address bits 1-32)
42
CIDR provides the mechanism to combine multiple networks into groups or blocks, which the router treats as one big network (route summarization or route aggregation). For example, instead of having to store 10 Class C network addresses (any multiple number of smaller classful networks) the router can store a single CIDRbased network address. CIDR is still bound by the base network address space. That is, a traditional Class C network address can use all 24 network mask bits for supernetting (as long as the bits are contiguous) but a Class A address can only use the first 8 bits of the prefix for supernetting. If more than the first 8 bits are used this would be subnetting, rather than supernetting. To supernet: 1. Use the lowest network address for the supernet address 2. Find the lowest order matching bit between the addresses
The lowest order matching bit will be the last bit in the supernet prefix
Figure 24 Supernetting
Administrative Distance
Each route in a routing table has a metric called an administrative distance in the range of 0-255. Lower metrics mean better values or routes are chosen. The lowest value administrative distance is the one that is stored in the routing table.
TABLE 7
Protocol Directly connected Static External BGP (eBGP) OSPF RIP Internal BGP (iBGP)
The IP address and network mask for the route destination network.
43
The route path, which can be one of the following: - The IP address of a next-hop gateway - An Ethernet port - A virtual interface (a routing interface used by VLANs for routing Layer 3 protocol traffic among one
another)
A null interface. The Layer 3 Switch drops traffic forwarded to the null interface.
Route Advertisements: RIP advertises its entire routing table: OSPF sends only updates. Route Advertisement Recipients: RIP broadcasts its entire routing table to any address within its
configured broadcast domains. It doesn't matter if you're a router or a workstation. You will receive a copy of the router's routing table. In OSPF, it sends updates multicast. A multicast packet is a packet that originates from a single host, but is delivered to multiple destinations.
It might help to think of broadcast versus multicast in the same way you understand an Ethernet hub
versus a switch. An IP broadcast, in some ways, is like a hub. With a hub, if a frame comes in one port, it gets duplicated and sent out every other port. There's no intelligence to it. It just gets duplicated. An IP multicast is more like a switch with VLANs configured. An incoming frame will be duplicated, but only sent out the port of the frame's destination, or, if that is unknown, the ports that are participating in the VLAN. In this case, OSPF sends its updates to all OSPF routers. Two special multicast addresses to remember are:
Updates: RIP broadcasts its entire routing table every 30 seconds. OSPF sends updates only when
changes occur.
Authentication: MD5 hash authentication is available in RIP, but only in version 2. OSPF also provides
MD5 hash authentication.
Variable Length Subnet Masks (VLSM): RIP version 2 supports this. OSPF supports it, too.
IGMP Snooping
The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships. PIM snooping must be used only in topologies where multiple PIM sparse routers connect through a device. PIM snooping does not work on a PIM dense mode router which does not send join messages, and traffic to PIM dense ports is stopped. A PIM snooping-enabled device displays a warning if it receives PIM dense join or prune messages.
44
IGMP protocols provide a method for clients and a device to exchange messages, and let the device build a database indicating which port wants what traffic. The protocols do not specify forwarding methods. They require IGMP snooping or multicast protocols such as PIM or DVMRP to handle packet forwarding. PIM or DVMRP can route multicast packets within and outside a VLAN, while IGMP snooping can switch packets only within a VLAN.
DVMRP and PIM can concurrently operate on different ports of a Brocade Layer 3 switch.
45
ACL Overview
Brocades FastIron devices support rule-based ACLs (sometimes called hardware-based ACLs), where the decisions to permit or deny packets are processed in hardware and all permitted packets are switched or routed in hardware. In addition, Brocades FastIron devices support inbound ACLs only; outbound ACLs are not supported. Rule-based ACLs program the ACL entries you assign to an interface into Content Addressable Memory (CAM) space allocated for the ports. The ACLs are programmed into hardware at startup (or as new ACLs are entered and bound to ports). Devices that use rule-based ACLs program the ACLs into the CAM entries and use these entries to permit or deny packets in the hardware, without sending the packets to the CPU for processing. Rule-based ACLs are supported on the following interface types:
Gigabit Ethernet ports 10 Gigabit Ethernet ports Trunk groups Virtual routing interfaces
ACLs filter traffic by permitting or denying incoming frames from passing through interfaces that have the ACL applied to them. Each ACL is a collection of permit and deny statements (rules) that apply to frames. A switch compares the fields in the frame against any ACLs applied to the interface to verify that the frame has the required permissions to be received or forwarded. The switch sequentially compares the frame against each rule in the ACL and either forwards or drops it. The order of the rules in an ACL is critical because the first rule that matches the traffic stops further processing of the frame.
If you want to tightly control access, configure ACLs consisting of permit entries for the access you want to
permit. The ACLs implicitly deny all other access.
If you want to secure access in environments with many users, you might want to configure ACLs that
consist of explicit deny entries, then add an entry to permit all access to the end of each ACL. The software permits packets that are not denied by the deny entries.
Note
required permissions to be received or forwarded. The order of the rules in an ACL is critical because the first rule that matches the traffic stops further processing of the frame. Since ACLs are executed sequentially, from top to bottom, place the deny statements before the permit statements. There is an implicit deny statement at the end of each ACL. All traffic not specifically permitted is automatically denied.There are two types of ACLs:
Standard (ACL 1-99) - Permits or Denies packets based on source IP address - Configured with the access-list command Extended (ACL 100-199) - Permits or denies packets based on source and destination IP addresses, TCP/UDP ports, or protocol
number or name
Configured with the access-list command The following are editing options for extended ACLs:
Insert a new ACL entry within an existing ACL Delete an entry from an ACL Replace an existing ACL entry Add, insert, replace, or delete a remark per ACL entry
If you can, try to apply ACLs Inbound rather than Outbound. Inbound ACL behavior states that the first instance of a TCP or UDP packet is handled by the ASIC and not the CPU. Enabling access list logging impacts the CPU. Example Standard ACL
Router_A(config)# ip dns server-address 209.157.22.30 Router_A(config)# access-list 1 deny host 209.157.22.26 log Router_A(config)# access-list 1 deny host 209.157.29.12 log Router_A(config)# access-list 1 deny host IPHost1 log Router_A(config)# access-list 1 permit any Router_A(config)# interface ethernet 1/1 Router_A(config-if-1/1)# ip access-group 1 in Example Explanation Q: Why do the 2nd, 3rd, and 4th access list 1 lines have no subnet mask?
47
The host argument is used in the syntax as a substitute for the subnet mask. DNS server configuration allows a host name to be specified and it is looked up on the servers listed in the command, you can list up to four servers. The DNS servers are searched in the order listed in the configuration. Syslog entries: The first time an ACL entry permits or denies a packet, the software immediately generates a Syslog entry and SNMP trap. The software also starts a five-minute timer. The timer keeps track of all packets explicitly denied by the ACL entries. After five minutes, the software generates a single Syslog entry for each ACL entry that has denied a packet. The message indicates the number of packets denied by the ACL entry during the previous five minutes.
48
A PBR policy specifies the next hop for traffic that matches the policy. Using standard ACLs with PBR, you can route IP packets based on their source IP address. With extended ACLs, you can route IP packets based on all of the clauses in the extended ACL.
ISP_WAN
V L VE1 A N
192.168.2.1
R
VE3: 192.168.2.4/24
Customer B AS 110
209.157.23.X
192.168.2.2
AS 200
192.168.2.3
Customer C AS 120
209.157.24.X
Customer D AS 130
209.157.25.X
Configure ACLs that contain the source IP addresses for the IP traffic you want to route using PBR. Configure a route map that matches on the ACLs and sets the route information. Apply the route map to an interface.
49
QoS Overview
Quality of Service (QoS) features are used to prioritize the use of bandwidth in a switch. When QoS features are enabled, traffic is classified as it arrives at the switch, and processed through on the basis of configured priorities. Traffic can be dropped, prioritized for guaranteed delivery, or subject to limited delivery options as configured by a number of different mechanisms. Classification is the process of selecting packets on which to perform QoS, reading the QoS information, and assigning a priority to the packets. The classification process assigns a priority to packets as they enter the switch. These priorities can be determined on the basis of information contained within the packet or assigned to the packet as it arrives at the switch. Once a packet or traffic flow is classified, it is mapped to a forwarding priority queue. Packets on Brocade devices are classified in up to eight traffic classes with values from 0 to 7. Packets with higher priority classifications are given a precedence for forwarding.
Strict Priority (SP) SP ensures service for high priority traffic. The software assigns the maximum
weights to each queue which causes the queuing mechanism to serve as many packets in one queue as possible before moving to a lower queue. This method biases the queuing mechanism to favor the higher queues over the lower queues.
Hybrid WRR and SP Starting with software release 02.2.00, an additional configurable queueing
mechanism combines both the strict priority and weighted round robin mechanisms. The combined method enables the Brocade device to give strict priority to delay-sensitive traffic such as VoIP traffic, and weighted round robin priority over other traffic types.
50
The primary use of these commands is for packet remarking (without changing the internal priority of the
packet if desired). Qos-tos trust indicates the priority to be trusted on the Ingress interface (cos, dscp or ip-prec). Qos-tos mark indicates which priority is to be marked on the Egress interface (cos or dscp).
Qos-tos trust and qos-tos mark commands are both applied at the Ingress interface (physical or
virtual).
Stage 1
Collect priority and drop precedence information from various portions of the packet header
If a packets EtherType matches 8100 or the ports EtherType, derive a priority value and drop precedence by decoding the PCP value. If the qos use-dei command is configured, the bit between the VLAN ID and PCP in the VLAN tag will be interpreted as a drop precedence and priority value. For MPLS packets, derive a priority value and drop precedence by decoding the EXP bits. For IPv4 or v6 packets, derive a priority value and drop precedence by decoding the DSCP bits. The derived values for PCP, EXP and DSCP are mapped to either a default map or a configured Ingress Decode Policy Map. To assist the device in the decoding process described in stage 1 decode-map tables are defined.
Stage 2
Determine if a priority value should be forced or merged
If a packet EtherType matches 8100 or the ports EtherType, derive a priority value and drop precedence by decoding the PCP value. If the qos pcp force command is configured on the port, the priority and drop precedence values are set to the value read from the PCP bits. If the qos exp force command is configured on the port, the priority and drop precedence values are set to the value read from the MPLS EXP bits. If the qos dscp force command is configured on the port, the priority and drop precedence values are set to the value read from the DSCP bits. If none of the qos force commands are configured, the priority and drop precedence values are set for IPv4 or v6 packets and MPLS packets as described in the following:
For IPv4 or v6 Packets: Priority and drop precedence values obtained as a merge of the decoded
PCP and decoded DSCP values.
For MPLS Packets: Priority and drop precedence values obtained as a merge of the decoded PCP
and decoded EXP values.
51
dscp-cos-mapping This option is similar to the dscp-matching command (described below). This option
maps the DSCP value in incoming packets to a hardware table that provides mapping of each of the 0 63 DSCP values, and distributes them among eight traffic classes (internal priorities) and eight 802.1p priorities. By default, the Brocade device does the 802.1p to CoS mapping. If you want to change the priority mapping to DSCP to CoS mapping, you must enter the following ACL statement. permit ip any any dscp-cos-mapping
dscp-marking Marks the DSCP value in the outgoing packet with the value you specify. internal-priority-marking and 802.1p-priority-marking Supported with the DSCP marking option, these
commands assign traffic that matches the ACL to a hardware forwarding queue (internal-priority-marking), and re-mark the packets that match the ACL with the 802.1p priority (802.1p-priority-marking).
dscp-matching Matches on the packet DSCP value. This option does not change the packet forwarding
priority through the device or mark the packet.
802.1p-priority-matching Inspects the 802.1p bit in the ACL that can be used with adaptive rate limiting
If the packet matches an ACL that defines the priority, then ACL priority will be used. If the packet source or destination MAC address matches a configured static MAC address with priority,
then static MAC priority will be used.
If the ingress port has a configured priority, then port priority will be used. If the other situations do not apply, the configured or default port priority (0) will be used. 802.1p priority override is supported on physical ports and trunk ports. When applied to the primary port
of a trunk group, the configuration applies to all members of the trunk group.
52
Describe the tools used to monitor a network Describe the tools used to manage a network Demonstrate how to apply security on switches and routers Describe maintenance procedures for switches and routers
Network Monitoring
sFlow
sFlow is a standards-based protocol that allows network traffic to be sampled at a user-defined rate for the purpose of monitoring traffic flow patterns and identifying packet transfer rates on user-specified interfaces. When sFlow is enabled on a Layer 2 or Layer 3 switch, the system performs the following sFlow-related tasks:
Samples traffic flows by copying packet header information Identifies ingress and egress interfaces for the sampled flows Combines sFlow samples into UDP packets and forwards them to the sFlow collectors for analysis (uses
default UDP port 6343)
Forwards byte and packet count data, or counter samples, to sFlow collectors
The mirror port is the port to which the monitored traffic is copied. Attach your protocol analyzer to the
mirror port.
The monitored port is the port whose traffic you want to monitor
53
Network Management
SNMP Access
SNMP is a set of protocols for managing complex networks. SNMP sends messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves in Management Information Bases (MIBs) and return this data to the SNMP requesters. Table8 lists individual Brocade switches and the SNMP access methods they support. These features are supported in the Layer 2, base Layer 3, edge Layer 3, and full Layer 3 software images, except where explicitly noted.
TABLE 8
Support SNMP Access Features FESX FSX 800 FSX 1600 Yes Yes Yes Yes Yes Yes Yes FWS FCX ICX 6610 ICX 6430 ICX 6450 Yes Yes Yes Yes Yes Yes Yes
Feature
SNMP v1, v2, v3 Community strings User-based security model for SNMP v3 SNMP v3 traps Defining the UDP port for SNMP v3 traps SNMP v3 over IPv6 AES encryption for SNMP v3
54
SNTP
Brocade devices can be configured as a Simple Network Time Protocol (SNTP) client. You can configure the Brocade device to consult up to three SNTP servers for the current system time and date. The first server configured will be used unless it becomes unreachable, in which case the Brocade device will attempt to synchronize with the other SNTP servers (if any) in the order in which they were configured. You can configure Brocade devices to function as an SNTP server to its downstream clients. When using the device as an SNTP server, you can also set it to use its own internal clock as the reference source if an upstream server becomes unavailable.
Applying Security
Setting the SSH port number
By default, SSH traffic occurs on TCP port 22. You can change this port number. For example, the following command changes the SSH port number to 2200. Brocade(config)#ip ssh port 2200 Note that if you change the default SSH port number, you must configure SSH clients to connect to the new port. Also, you should be careful not to assign SSH to a port that is used by another service. If you change the SSH port number, Brocade recommends that you change it to a port number greater than 1024. Syntax: ip ssh port <number>
802.1X
Brocade devices support the IEEE 802.1X standard for authenticating devices attached to LAN ports. Using 802.1X port security, you can configure a Brocade device to grant access to a port based on information supplied by a client to an authentication server. When a user logs on to a network that uses 802.1X port security, the Brocade device grants (or denies) access to network services after the user is authenticated through an authentication server. The user-based authentication in 802.1X port security provides an alternative to granting network access based on a user's IP address, MAC address, or sub network. While the client awaits authentication, only the following traffic types are allowed on the client port:
EAPOL Extensible Authentication Protocol On the LAN FDP Brocade Discovery Protocol STP Assumes secure connection
802.1x allows MAC-based authentication. The following are device roles in an 802.1X configuration:
55
TACACS+ provides for authentication, authorization, and accounting, but an implementation or configuration is not required to employ all three. To create an authentication method list that specifies TACACS/TACACS+ as the primary authentication method for securing Telnet/SSH access to the CLI. Brocade(config)#enable telnet authentication Brocade(config)#aaa authentication login default tacacs local The commands above cause TACACS/TACACS+ to be the primary authentication method for securing Telnet/ SSH access to the CLI. If TACACS/TACACS+ authentication fails due to an error with the server, authentication is performed using local user accounts instead.
Startup configuration file This file contains the configuration information that is currently saved in flash.
To display this file, enter the show configuration command at any CLI prompt.
Running configuration file This file contains the configuration active in the system RAM but not yet
saved to flash. These changes could represent a short-term requirement or general configuration change. To display this file, enter the show running-config or write terminal command at any CLI prompt. Each device can have one startup configuration file and one running configuration file. The startup configuration file is shared by both flash modules. The running configuration file resides in DRAM.
Note
Brocade devices also support Secure Copy (SCP) for securely transferring files between a Brocade device and SCP-enabled remote hosts.
56
File Management
The flash memory is divided into two different storage areas. This allows you to have two different software image versions stored in the flash memory. Secondary flash is storage space for upgrade code:
Put new code in the secondary flash Schedule a reload to boot on secondary flash during low traffic periods. Unsuccessful reloads will cause
the system to revert back to primary flash.
When confidence is established in upgrade code, use the copy flash flash primary command to
overwrite the old software image with the upgrade image in primary flash
The following command copies the system image in the primary flash to the TFTP server: - FastIron# copy flash tftp 192.22.33.44 vm1r07501.bin primary - A failure may indicate the presence of something in the secondary flash
Note
Password Recovery
Recovering from a lost password requires direct access to the serial port and a system reset. This procedure can only be accomplished from the console port. To recover from a lost password: 1. Start a CLI session over the serial interface to the device and reboot it SW-Switch# reload Are you sure? (enter 'y' or 'n'): y Halt and reboot 2. At the initial boot prompt at system startup, enter b to enter the boot monitor mode. 3. Enter no password at the prompt BOOT MONITOR> no password OK! Skip password check when the system is up. This command will bypass the system password check, and cannot be abbreviated (this will not erase any existing passwords) 4. Enter boot system flash [primary | secondary] at the prompt BOOT MONITOR> boot system flash primary BOOT INFO: load from primary copy <Truncated Output> 5. Once the console prompt reappears, assign a new password. 6. Issue the write memory command to save the new password.
57
9 Troubleshooting
After reviewing this section you should be able to do the following:
Demonstrate knowledge of troubleshooting tools and techniques Demonstrate ability to analyze troubleshooting output
Contacting Support
When contacting support there are several pieces of information about your data center that would expedite your case:
Collect a supportsave Collect a show tech-support Have the most recent topology diagram available Have the most recent changes to your environment
supportsave Command
The supportsave is an important utility for collecting logs from the driver, internal libraries, and firmware. The collected logs are shared with the technical support personnel for investigating issues seen on the device. Note
The supportsave utility is supported only on the Brocade ICX 6430 and 6450 devices.
TFTP is used to capture supportsave data. It is disabled by default, if FIPS is enabled. Enable TFTP manually for uploading supportsave data. It is a prerequisite to have the TFTP server with a write permission and the server must be accessible from the device.
58
You can change the bridge priority, port priority, and path cost so that a predetermined outcome occurs in the election process (Learning state).
Port initialization Non Designated Ports: Port is Blocked MAC table remains empty Port Role is established as: Root Port Designated Port Non-Designated (15 sec) Root and Designated Ports: Port receives data traffic Populates its MAC table (15 sec) Root and Designated Ports: Send and Receive data traffic
Figure 27: STP Port States
Blocking state
Listening state
Learning state
Forwarding state
59
Brocade# show optic 13 Port Temperature Tx Power Rx Power Tx Bias Current +----+-----------+----------+------------+-------------------+ 13 33.2968 C -005.4075 dBm -007.4328 dBm 6.306 mA Normal Normal Normal Normal Optical monitoring feature will not work in the following scenarios:
The port is DOWN. The port is configured as a stacking port. The the optic module does not support optical monitoring. For ICX 6430 devices only: - If an SFP+ optic is inserted in an SFP only port, the optic will not initialize. - If an SFP optic is inserted in an SFP+ only port, the optic will not initialize. - If an optic is inserted into a device that supports both SFP and SFP+ optics, use the speed-duplex
command to set the port speed correctly.
Interface Configuration
Each 10/100/1000 port is designed to auto-sense and auto-negotiate the speed and mode of the connected device. If the attached device does not support this operation, the port speed may be set to operate at either 10, 100, or 1000 Mbps. The default value is for the ports to auto-sense speed and duplex. Settings should be the same at both ends. If a port is not working or cannot connect to another switch or server, verify that the settings are correct, the port is not administratively disabled, and the cable between the source and destination is not damaged.
You manually disable and enable the port at the Interface Level of the CLI. You enter the command clear loop-detection. This command clears loop detection statistics and enables
all Err-Disabled ports.
IP Packet Parameters
You can configure the following packet parameters on Layer 3 Switches. These parameters control how the Layer 3 Switch sends IP packets to other devices on an Ethernet network. The Layer 3 Switch always places IP packets into Ethernet packets to forward them on an Ethernet port.
Encapsulation type The format for the Layer 2 packets within which the Layer 3 Switch sends IP packets.
60
Maximum Transmission Unit (MTU) The maximum length of IP packet that a Layer 2 packet can contain.
If MTU size is not the same between switches you may see a high packet loss. IP packets that are longer than the MTU are fragmented and sent in multiple Layer 2 packets. You can change the MTU globally or an individual ports:
Global MTU The default MTU value depends on the encapsulation type on a port and is 1500 bytes for Ethernet II encapsulation and 1492 bytes for SNAP encapsulation. Port MTU A port default MTU depends on the encapsulation type enabled on the port.
[no] debug dot1x filter Brocade# debug dot1x filter dot1x: Filter debugging is on
[no] debug dot1x misc Brocade# debug dot1x misc dot1x: Misc debugging is on
[no] debug dot1x packets Brocade# debug dot1x packets dot1x: Packets debugging is on
This command displays information about 802.1x packets. This command displays information about 802.1x timers.
[no] debug dot1x timers Brocade# debug dot1x timers dot1x: Timers debugging is on
Protocol Ports
It is common practice for network security administrators to shut down unused ports. Before calling support about an unavailable application or service, verify the port that the application or service uses (both sending and receiving) is available for that traffic.
61
IMPORTANT: PLEASE READ THE FOLLOWING BROCADE NON-DISCLOSURE CONFIDENTIALITY AGREEMENT CAREFULLY BEFORE TAKING THIS EXAM.
The following Non-Disclosure Confidentiality Agreement (the Agreement) sets forth the terms and conditions of your use of the exam materials as defined below. The Disclosure to you of this Exam and any questions, answers, worksheets, computations, drawings, diagrams, or any communications, including verbal communication by any party, regarding or related to the Exam and such Exam Materials and any derivatives thereof is subject to the Terms and Conditions of this Agreement. You understand, acknowledge and agree:
That the questions and answers of the Exam are the exclusive and confidential property of Brocade
and are protected by Brocade intellectual property rights;
That you may not disclose the Exam questions or answers or discuss any of the content of the Exam
Materials with any person, without prior approval from Brocade;
Not to copy or attempt to make copies (written, photocopied, or otherwise) of any Exam Material,
including, without limitation, any Exam questions or answers;
Not to sell, license, distribute, or give away the Exam Materials, questions, or answers; You have not purchased, solicited or used unauthorized (non-Brocade sanctioned) Exam Materials,
questions, or answers in preparation for this exam;
That your obligations under this Agreement shall continue in effect after the Exam and, if applicable,
after termination of your credential, regardless of the reason or reasons for terminations, and whether such termination is voluntary or involuntary. Brocade reserves the right to take all appropriate actions to remedy or prevent disclosure or misuse, including, without limitation, obtaining an immediate injunction. Brocade reserves the right to validate all results and take any appropriate actions as needed. Brocade also reserves the right to use any technologies and methods for verifying the identity of candidates. Such technology may include, without limitation, personally identifiable information, challenge questions, identification numbers, photographic information, and other measures to protect against fraud and abuse. Neither this Agreement nor any right granted hereunder shall be assignable or otherwise transferable by you. By clicking on the "A" button (YES, I AGREE), you are consenting to be bound by the terms and conditions of this agreement and state that you have read this agreement carefully and you understand and accept the obligations which it imposes without reservation. You further state that no promises or representations have been made to induce agreement and that you accept this agreement voluntarily and freely. A. B. YES, I AGREE NO, I DO NOT AGREE
62