CCIE _R&S_ NOTE FROM EXPERIENCE BY ROBERT WEBBERT

CCIE Notes From

Experience

Study Notes Learned from Practice Labs, Home Routers and Real Life

by Robert Webber CCIE 6922

© Copyright 2009, Robert Webber

RobWebber's CCIE Notes from Experience Version 8.0

Table of Contents - Notes From Experience

Introduction ........................................................................................................ 8Foreword............................................................................................................. 93560 ................................................................................................................... 10 Time Savers ................................................................................................... 10 Creating VLANs .............................................................................................. 11 Access Ports................................................................................................... 12 Trunk Ports ..................................................................................................... 13 Restricting VLANs on Trunk Ports .................................................................. 14 Routing with the 3560 ..................................................................................... 14 DHCP ............................................................................................................. 16 Etherchannels................................................................................................. 18 Fallback Bridging ............................................................................................ 18 SPAN and RSPAN.......................................................................................... 20 Spanning Tree ................................................................................................ 23 VTP................................................................................................................. 27 3560 Connection Types.................................................................................. 28 Example of Using the 3560............................................................................. 28

BGP ................................................................................................................... 32 Peers .............................................................................................................. 32 Advertising to Peers........................................................................................ 32 iBGP Full Mesh............................................................................................... 35 Filtering........................................................................................................... 35 Communities................................................................................................... 36 Synchronization .............................................................................................. 37 Aggregate Address ......................................................................................... 38 Attributes ........................................................................................................ 38 BGP Official Path Selection Process .............................................................. 40 BGP Unofficial Path Selection Process .......................................................... 41

Bridging (Routers) ........................................................................................... 42 Spanning Tree ................................................................................................ 42 Frame Relay ................................................................................................... 42

Control Plane Policing ..................................................................................... 43Debug................................................................................................................ 44Distance ............................................................................................................ 45Distribute Lists................................................................................................. 47 Distribute List In .............................................................................................. 47 Distribute List Out ........................................................................................... 49EIGRP ................................................................................................................ 50 EIGRP Metric.................................................................................................. 50 EIGRP Summarization.................................................................................... 50 EIGRP Default Route...................................................................................... 51 EIGRP Network Commands ........................................................................... 51 EIGRP Stub Routing....................................................................................... 52Firewalls............................................................................................................ 53 IOS Firewall (CBAC)....................................................................................... 53

© Copyright 2009, RobWebber 2


Zone-Based Firewall....................................................................................... 54Frame Relay...................................................................................................... 56 Interfaces and Sub-Interfaces......................................................................... 56 PVC Status ..................................................................................................... 56 Inverse Arp and Mapping................................................................................ 56 OSPF.............................................................................................................. 59

Gateway Load Balancing Protocol (GLBP).................................................... 60Home Lab.......................................................................................................... 62 Home Lab Considerations .............................................................................. 63 IOS For Your Home Lab ................................................................................. 63 Choosing a Terminal Emulator ....................................................................... 65 Accessing Your Lab From the Internet ........................................................... 65 Automatically Logging in to All Routers .......................................................... 66

IKE ..................................................................................................................... 68Intrusion Prevention System (IPS) - IOS ....................................................... 69IPSec ................................................................................................................. 69 Access lists ..................................................................................................... 70 IPSec through a Tunnel Interface ................................................................... 70 IPSec Example ............................................................................................... 71 Verifying IPSec Connectivity........................................................................... 73

IPv6.................................................................................................................... 77 Access Lists.................................................................................................... 77 Addressing...................................................................................................... 78 BGP ................................................................................................................ 80 EIGRP ............................................................................................................ 81 Filtering........................................................................................................... 82 IOS Firewall .................................................................................................... 83 OSPF.............................................................................................................. 83 RIP.................................................................................................................. 84 Redistribution.................................................................................................. 85 Tunneling........................................................................................................ 85

Lab Day!!........................................................................................................... 87 Getting Started Checklist ................................................................................ 87 Script for all routers......................................................................................... 88 Aliases ............................................................................................................ 88 Configuring the Routers.................................................................................. 89 Making Your Diagram ..................................................................................... 90 Keep a List...................................................................................................... 90

Loopback Interfaces ........................................................................................ 90MPLS ................................................................................................................. 91 MPLS Overview .............................................................................................. 91 Terminology.................................................................................................... 91 Configuring MPLS........................................................................................... 92 Configuring Multiprotocol BGP ....................................................................... 93 Configuring MPLS VPNs ................................................................................ 94

Multicast............................................................................................................ 96 IGMP/CGMP................................................................................................... 96 PIM ................................................................................................................. 97



Rendezvous Point (RP) .................................................................................. 97 DVMRP........................................................................................................... 98

NTP .................................................................................................................... 98 Overview......................................................................................................... 98 NTP Modes..................................................................................................... 99 Basic Commands............................................................................................ 99 Advanced Commands .................................................................................... 99

OSPF ............................................................................................................... 100 Network Types.............................................................................................. 101 Cost (Metrics) ............................................................................................... 102 External Routes ............................................................................................ 102 Router ID ...................................................................................................... 102 Distance........................................................................................................ 103 Summarization.............................................................................................. 103 Stub and NSSA Areas .................................................................................. 104 Virtual Links .................................................................................................. 104 Graceful Restart............................................................................................ 105

Prefix Lists...................................................................................................... 105Quality of Service........................................................................................... 107 Class of Service, IP Precedence and DiffServ Code Points ......................... 107 Classification and Marking............................................................................ 108 Congestion Management.............................................................................. 110 Policing and Shaping .................................................................................... 113 Configuring Policing...................................................................................... 113 Traffic Shaping ............................................................................................. 114 Configuring Traffic Shaping .......................................................................... 115 RSVP ............................................................................................................ 116 QoS Overview .............................................................................................. 117

Redistribution................................................................................................. 120 Metrics .......................................................................................................... 121 Route-Maps .................................................................................................. 122 OSPF............................................................................................................ 122 Summarization Notes ................................................................................... 122

RIP ................................................................................................................... 123 Sending and Receiving Updates .................................................................. 124

Route Maps..................................................................................................... 125 Tagging Routes ............................................................................................ 126

Router Services.............................................................................................. 127 FTP............................................................................................................... 127 NetFlow ........................................................................................................ 127 TFTP Server ................................................................................................. 128

Routing (General)........................................................................................... 128 Router "Network" Statements ....................................................................... 128 Passive Interface .......................................................................................... 128 Default Metrics.............................................................................................. 129

Split Horizon ................................................................................................... 129SSH.................................................................................................................. 130Tips & Tricks................................................................................................... 130



Practice Speed ............................................................................................. 131 IP Subnetting ................................................................................................ 132 Access Lists.................................................................................................. 133 Logging......................................................................................................... 133 Console and VTY Ports ................................................................................ 134 Terminal Editing............................................................................................ 134Troubleshooting............................................................................................. 134 Extended Pings from Another Interface ........................................................ 135 Extended Pings with High Repeat Count...................................................... 136 Extended Pings with Large Size Packets or Large Repeat Counts .............. 137 Debug ........................................................................................................... 138 Other Tools................................................................................................... 138Tunnels ........................................................................................................... 138WCCP .............................................................................................................. 139Appendix A: Tera Term Macro ...................................................................... 139

Study Sheet

CCIE Study Sheet - Foreword....................................................................... 1473560 ................................................................................................................. 147 Etherchannel ................................................................................................ 147 FallBack Bridging.......................................................................................... 148 Ports ............................................................................................................. 148 Spanning Tree .............................................................................................. 148 VTP............................................................................................................... 149

Access Lists ................................................................................................... 150 Standard Access Lists .................................................................................. 150 Extended Access Lists.................................................................................. 150 Named Access Lists ..................................................................................... 150 Reflexive Access Lists .................................................................................. 150

Aliases............................................................................................................. 150BGP ................................................................................................................. 150 Filtering with Route-Maps ............................................................................. 151 Filtering by AS_PATH................................................................................... 151 EBGP Peers between loopback addresses .................................................. 151 AS_PATH Prepending (Making the AS_PATH Longer)................................ 152 Route Map to Set Local Preference on Incoming Updates ........................... 152 Route Map to Set MED on outgoing updates ............................................... 153 Route Reflector Cluster ................................................................................ 153 Aggregate Address ....................................................................................... 153 Authentication - MD5 ................................................................................... 154

Bridging (Routers) ......................................................................................... 154 Global ........................................................................................................... 154 Interface........................................................................................................ 155

DHCP ............................................................................................................... 155EIGRP .............................................................................................................. 156 Authentication - MD5 ................................................................................... 156



Firewalls.......................................................................................................... 157 Context Based Access Control (CBAC)........................................................ 157 Zone Based Firewall ..................................................................................... 157 Reflexive Access Lists .................................................................................. 158 Lock and Key Access ................................................................................... 158Frame Relay.................................................................................................... 159 Frame Relay Switching................................................................................. 159 Frame Relay ................................................................................................. 159 Frame Relay Traffic Shaping ........................................................................ 160

HSRP ............................................................................................................... 160ISAKMP ........................................................................................................... 161IPSEC .............................................................................................................. 161IPv6.................................................................................................................. 162 Access-Lists & Filtering ................................................................................ 162 EIGRP .......................................................................................................... 163 OSPF............................................................................................................ 163 Tunneling...................................................................................................... 163

MPLS ............................................................................................................... 163Multicast.......................................................................................................... 165 IGMP ............................................................................................................ 165 CGMP........................................................................................................... 165 PIM - Dense Mode ....................................................................................... 165 PIM - Sparse Mode (Static Rendezvous Point)............................................ 165 PIM - Sparse-Dense Mode (Automatic Rendezvous Point) ......................... 165

Netflow ............................................................................................................ 166Network Address Translation (NAT)............................................................. 166 Outgoing - Source Addresses...................................................................... 166 Incoming - Source Addresses...................................................................... 167

NTP .................................................................................................................. 167 Clock and date commands ........................................................................... 168 Using one Device as an NTP Server ............................................................ 168 Restricting Access to an NTP Server............................................................ 168 Configuring NTP Authentication ................................................................... 168

OSPF ............................................................................................................... 168 Basic............................................................................................................. 168 Summarization.............................................................................................. 169 Authentication - Simple (Cleartext) .............................................................. 169 Authentication - MD5 ................................................................................... 169 Statically Defined Neighbors......................................................................... 169 Stub and NSSA Areas .................................................................................. 170 Virtual Link.................................................................................................... 170

Password Recovery ....................................................................................... 171 2500/4000..................................................................................................... 171 2600/3600/4500............................................................................................ 171

Queuing and TrafficShaping ........................................................................ 172 Priority Queuing ............................................................................................ 172 Custom Queuing........................................................................................... 172 Frame Relay ................................................................................................. 173



Redistribution................................................................................................. 173 Basic............................................................................................................. 173 Using Route-Maps to Control Redistribution................................................. 173 OSPF Example............................................................................................. 173 BGP Example ............................................................................................... 174

Regular Expressions ..................................................................................... 175RIP ................................................................................................................... 175Route Maps..................................................................................................... 175 Policy Route Maps........................................................................................ 176Terminal Server Configuration...................................................................... 176Trunking.......................................................................................................... 177 ISL: ............................................................................................................... 177 802.1Q:......................................................................................................... 177Tunnels ........................................................................................................... 177VRRP ............................................................................................................... 177

Table of Tables

Table 1: BGP Route Advertisement Rules ......................................................... 34Table 2: Frame Relay Interface Types and Issues............................................. 59Table 3: Sample Loopback Address Assignments ............................................. 90Table 4: OSPF Network Types......................................................................... 101Table 5: OSPF Stub and NSSA Area ............................................................... 104Table 6: IP Precedence Classes ...................................................................... 107Table 7: DSCP Classes.................................................................................... 108Table 8: IP Subnetting Summary ..................................................................... 132

Table of Figures

Figure 1: Switched Virtual Interfaces (SVI's) for the 3560 (Logical Routing) ...... 16Figure 2: Typical 3560 Connectivity (Physical)................................................... 29Figure 3: Typical 3560 Connectivity (Logical)..................................................... 30Figure 4: Bridging Over Frame Relay................................................................. 43Figure 5: Filtering RIP Routes ............................................................................ 48Figure 6: Home Lab with Internet Connectivity................................................... 66Figure 7: IPSec Using Multiple Tunnels ............................................................. 71Figure 8: OSPF Summarization with RIP Redistribution .................................. 123Figure 9: Using Route Tags ............................................................................. 126Figure 10: Using "Tools" To Help Troubleshooting .......................................... 135

These documents are registered with the U.S. Copyright office. It is illegal to sell, reproduce or distribute any portion of this document. I worked hard to create a study guide to help you achieve your CCIE. Please respect my work and obey the law!



Introduction

The first section of this guide, Notes From Experience, discusses issues, tricks and approaches to many networking problems. This section attempts to explain "how and why" to do certain things.

This guide does not attempt to explain the basics of BGP, OSPF, Frame Relay and other networking topics - there are many references for that. Instead this guide provides useful insights and explanations of the more subtle and complex aspects of networking.

The second section of this guide, Study Sheet, is a compilation of many condensed configurations, quick explanations and useful "show" and "debug" commands. This section is appropriate as a quick refresher on various configurations and a good review point as you make your final preparations for the exam.

Note: Included with some configs in the Study Sheet section are debug and show commands. Obviously these are not part of the configuration, but are included since I feel these are the most valuable debug and show commands related to the given technology.



Foreword As you prepare for the CCIE lab exam expose yourself to as many topics as you can - NTP, DHCP, Tunnels, NAT, etc. However do not do this at the sacrifice of knowing the "core" topics inside and out.

The "core" topics include the 3560, OSPF, BGP, redistribution, access lists, and Frame Relay. Know these so well you can configure them in your sleep (yes, you will find yourself dreaming about router configs)! Know what every command in the command reference does for these topics. You will not have time to look-up very much on these topics (there will be other topics during the exam which will require your time to look-up). These topics are particularly important since they are probably required in order for other aspects of the exam network to operate properly. You simply must know these extremely well!!

There is a second set of topics that is not quite as fundamental as those listed above, but still important and likely to appear on the exam. These include QoS, Security, EIGRP, RIP, route maps and Multicast. Get extremely familiar with these and practice them.

Once you have mastered these topics, then you can spend time on the less common topics. I recommend spending the final 2-4 weeks before your lab exam practicing on the "core" and the "second set" of topics (not the myriad of "other" topics)!

As I prepared for my exam, I first mastered the core topics. I spent the time necessary learning OSPF, BGP, Frame Relay, redistribution and access-lists extremely well. For me this required many months. Once I knew these inside and out, I tackled the "second set" of topics. I learned these thoroughly, though perhaps not quite as in-depth as the core topics. This required several months. I then pursued the "odd ball" topics. These are the little things that might end up being worth a few points on the exam. In most cases I didn't learn every command nor did I try every possible scenario in the lab. Instead I tried a few common scenarios for each topic and generally tried to become somewhat familiar with a lot of the commands. I went on the assumption that if I knew a fair amount about these topics, I could probably figure out the rest on the fly (and even if I couldn't, it should only cost me a few points).

About 4-6 weeks before my exam I made a conscious decision to abandon the oddball topics and re-focus on the core and second set of topics. I created a few lab scenarios of these topics and repeated them, actually timing myself to improve on speed - speed is important! This made sure that all the really important skills were fresh and it instilled confidence in me that I knew these topics very well and could implement them quickly. Two or three days before the exam I stopped all my lab



work, figuring if I hadn't learned a topic by then I wasn't about to do it at that point. Instead I tried to relax as much as possible and calmly reviewed these notes. That was my strategy. Hopefully yours will work well for you!

3560 The 3560 is a very flexible and powerful device within Cisco's product line. I recommend becoming very familiar with the topics you know will be required for the exam: creating VLANs, assigning ports to VLANs, Layer 2 and Layer 3 switching/routing, Trunking, etc. However I also recommend browsing through the full 3560 administrative guide to review all its features. You don't have to memorize the syntax of every command for every feature, but if you've read/skimmed the entire guide then when a requirement is presented on the exam, it will likely trigger a memory of something you've read.

For example, if the lab exam has a 1-point requirement on the 3560 for several ports to not receive unknown packets or multicast packets, you may not know the exact command immediately, but you may remember reading about Port Blocking in the Traffic Control section. At that point it probably won't take you that long to identify the exact command(s) and syntax required.

I view the basic functionality of the 3560 this way:

· Each port of the 3560 will either be a trunk port (ISL or 802.1Q) or a non-trunk port (access port)

· Access ports will be in one VLAN; trunk ports can carry many VLANs

· For each VLAN, the 3560 may participate in IP routing or it may not. If it does not, the VLAN will either be completely isolated or will require an external router to connect to other VLANs/subnets.

· There are two basic ways of routing for the 3560. These are discussed in the section "Routing with the 3560," below.

For the 3560 !" #$%&!'( is not enabled by default. I recommend enabling this!

Time Savers

You can use the interface range command to make identical configurations on several ports at once. This is a nice way to save a bit of time. For example, to configure ports FastEthernet 0/5 through 0/9 to be members of VLAN 11, use:

)*!&+,-+$'.!(/0!'&1#.2+1 #2'(1 324&5&,1#'1& 678 9 : )*!&+,-+$'.!(;!.;#2'(1/04*!&+,"$#& <$=1 2++144



)*!&+,-+$'.!(;!.;#2'(1/04*!&+,"$#& 2++144 >?2' @@

When you want to see a 3560 configuration specific to an interface or VLAN, you don't need to page through the entire config (time consuming for a 24-port or, especially 48-port 3560). Instead you can use keywords after the 4,$* #%''!'(;+$'.!(%#2&!$' command. This can save a lot of time, so you should practice it! Here are some examples of showing the configuration on physical interfaces (GigabitEthernet, FastEthernet) as well as logical interfaces (Vlan 158):

ABCD;D8E604,$ #%' !'& (!(2F!&5&,1#'1& 67@ G%!?=!'( +$'.!(%#2&!$'HHH I%##1'& +$'.!(%#2&!$' J @6D FK&14 L !'&1#.2+1 M!(2F!&5&,1#'1&67@ 4*!&+,"$#& 2++144 >?2' @8N 4*!&+,"$#& <$=1 2++144 '$ !" 2==#144 1'= ABCD;D8E604,$ #%' !'& >?2' @8O G%!?=!'( +$'.!(%#2&!$'HHH I%##1'& +$'.!(%#2&!$' J @8D FK&14 L !'&1#.2+1 P?2'@8O !" 2==#144 @6HN6H@8OHN8N N88HN88HN88H6 '$ !" #1=!#1+&4 4&2'=FK @ !" @6HN6H@8OHN86 4&2'=FK @ "#!$#!&K @@8 4&2'=FK @ "#11<"& 1'= ABCD;D8E604,$ #%' !'& .267QO G%!?=!'( +$'.!(%#2&!$'HHH I%##1'& +$'.!(%#2&!$' J @8D FK&14 L !'&1#.2+1 324&5&,1#'1&67QO 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& &#%'R 2??$*1= >?2' @QOT@8E;@8: 4*!&+,"$#& <$=1 &#%'R '$ !" 2==#144 1'=

Creating VLANs You can create VLANs one of two ways:

D8E6;@0 >?2' =2&2F241 D8E6;@->?2'/0>?2' @66 !""#$%&

or



D8E6;@0 +$'. & D8E6;@-+$'.!(/0 >?2' :: D8E6;@-+$'.!(;>?2'/0 !""#$%

Both ways accomplish the same task. I prefer the latter method, simply because I am used to entering "+$'.!( &" mode, but I'm not used to entering "vlan database" mode. Also, I will need to go into config t mode for other configuration steps. I won't use "vlan database" to configure any other attributes of the 3560.

If the exam does not specify the VLAN numbers I like to use the third octet of the IP address for the VLAN number. This provides unique VLAN numbers and since the VLAN numbers go to 1000 there is no problem covering all 256 possible numbers that can be used by the third octet. The biggest advantage of this is as soon as you see the VLAN number you will instantly know what subnet it is.

So if I'm creating a VLAN for the 144.32.87.0/24 subnet, I will use VLAN 87 for that subnet. Likewise, if I'm creating a VLAN for the 144.32.16.0/24 subnet, I will use VLAN 16 for that subnet. This way simply by looking at the VLAN number I know what IP subnet is associated with it (and vice versa - by looking at the IP address I know what VLAN it is).

Access Ports A key concept you will need to understand with the 3560 is access ports vs. trunk ports. Access ports are ports that only support one VLAN. The port gets assigned to a single VLAN and whatever device is connected on that port is in that VLAN, period.

So if port FastEthernet 0/19 gets configured as an access port and assigned to VLAN 4, whatever is plugged into FastEthernet 0/19 (a router, a PC, etc.) will be in VLAN 4.

The command to configure a port as an access port is 4*!&+,"$#& <$=1

2++144, however the default is 4*!&+,"$#& <$=1 =K'2<!+ =14!#2F?1. This means that the port will actively try to negotiate to create a trunk port. If the other end is willing to become a trunk, the port becomes a trunk. Only when the other end refuses to become a trunk (or does not answer the Dynamic Trunking Protocol, DTP) will the port become an access port. Yet even in this case the port will periodically send DTP packets to see if the other end is willing to become a trunk. My advice - as you will read so often in this guide - is to nail down the port exactly the way you want it. If you know you want an access port, use the 4*!&+,"$#& <$=1 2++144

command.

The command to assign an access port to a VLAN is (you will definitely need this command):



4*!&+,"$#& 2++144 >?2' $'"()*

Where number is the vlan number. So to assign Fast Ethernet 0/7 to VLAN 100 the commands would be:

)*!&+,-+$'.!(/0!'& .267U )*!&+,-+$'.!(;!./0 4*!&+,"$#& <$=1 2++144 )*!&+,-+$'.!(;!./0 4*!&+,"$#& 2++144 >?2' @66

Trunk Ports Trunk ports can transport (or carry) many VLANs over a single physical connection. The trunk ports need to be configured with an encapsulation type. This simply defines the protocol used to encapsulate, or "tag" packets sent over the trunk.When sending packets the devices at either end of the trunk add a small header with the VLAN number to identify the VLAN to which that packet belongs.When receiving packets, the device reads (and strips) the header and thus knows in what VLAN the packet belongs.

The 3560 supports both ISL and dot1q (802.1Q) trunk encapsulation types. Both work equally well; I personally prefer dot1q simply because it is an industry standard and thus it is my preferred choice in the "real" world. You need to set the trunk encapsulation type on a port before configuring it as a trunk. So to configure FastEthernet 0/3 as a trunk using 802.1Q:

)*!&+,-+$'.!(/0!'& .267D )*!&+,-+$'.!(;!./04*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S )*!&+,-+$'.!(;!./04*!&+,"$#& <$=1 &#%'R

You can configure a port to dynamically negotiate a trunk connection. For example, 4*!&+,"$#& <$=1 =K'2<!+ 2%&$ will create a trunk port if the device at the other end of the link wants to create a trunk (but will not initiate, or start, the negotiation of a trunk). Similarly, 4*!&+,"$#& <$=1

=K'2<!+ =14!#2F?1 will try to create a trunk with the device at the other end of the link, yet it will bring up a non-trunk connection if the device at the other end refuses to create a trunk.

As with other similar things in the CCIE lab, I recommend against using any type of auto-negotiation. I much prefer to 'hard' configure both ends of the link as a trunk (if that is allowed by the exam). That way you'll know for sure that you are not experiencing any type of negotiation problems. If the trunk link does not come up right away, you won't have any questions in your mind about whether there is a negotiation problem. Let's face it - on the exam if you know a particular link needs to be a trunk, you're probably better off having it not work at all than having it negotiate to be a non-trunk link. That way you can troubleshoot it right away (since it will be down)



and not have the link working, but only passing one VLAN (in a non-trunk mode).

Note that in order for two switches to create a trunk they must be in the same VTP domain (>&" =$<2!' %!"#+$,$#") command). If a trunk does not come up right away its not always obvious that this is the problem!

Restricting VLANs on Trunk Ports By default all VLANs on a given 3560 will be allowed on a trunk port. That is, if you have configured VLANs 2, 10, 11, 12, 40, 41 and 103 on a 3560, all of those VLANs will be allowed to pass along the trunk. The exam may require that you restrict what VLANs are allowed on the trunk. They may specify what VLANs are allowed, or they may state that you should only allow VLANs on the trunk that are required for the network to work.

Either way you will need the 4*!&+,"$#& &#%'R 2??$*1= >?2' command. So to allow VLANs 2, 10, 11, 12 and 103 on a given trunk port, use the following command. Note that you cannot use any spaces between the VLANs (or VLAN ranges) when you issue this command!

4*!&+,"$#& &#%'R 2??$*1= >?2' NT@6;@NT@6D

If at a later time you need to add VLAN 40, you can either list all the VLANs you would like allowed (probably a good idea so you know exactly what VLANs will be traversing the trunk) or use the 'add' command:

4*!&+,"$#& &#%'R 2??$*1= >?2' NT@6;@NTQ6T@6D

or

4*!&+,"$#& &#%'R 2??$*1= >?2' 2== Q6

Note that you cannot use the command:

4*!&+,"$#& &#%'R 2??$*1= >?2' Q6

to add VLAN 40 to the allowed list as instead this will only allow VLAN 40.

To remove VLAN 12 from a trunk (once you have already allowed it, or if the port is in the default mode, where all VLANs are allowed on the port):

4*!&+,"$#& &#%'R 2??$*1= >?2' #1<$>1 @N

Routingwith the 3560 The 3560 can route in one of two ways. I describe these two methods as "physical" routing vs. "logical" routing.

Physical routing applies an IP address to one physical port. This method has the restriction that only one 3560 port can be a member of that IP



subnet. Use the '$ 4*!&+,"$#& command to create a physically routed port:

!'&1#.2+1 324&5&,1#'1&67ND '$ 4*!&+,"$#& !" 2==#144 @88H@ONHDNH@8 N88HN88HN88H6

Each port that is configured for physical routing acts like a port on a traditional router - it gets assigned a unique IP subnet and it is the only port on the 3560 that is a member of that subnet. These ports do not get assigned to any VLAN since they are "standalone" router ports (based on '$ 4*!&+,"$#&). Cisco refers to these ports as "routed ports."

To change a port from a routed port back to the default (a port that can be assigned to a VLAN or configured as a trunk) use the commands:

!'&1#.2+1 324&5&,1#'1&67ND '$ !" 2==#144 4*!&+,"$#&

Note that 4*!&+,"$#& is the default configuration, thus when this is configured on a port it will not display in the configuration.

Logical routing places any number of ports into a VLAN (IP subnet), then creates a logical (virtual) routed interface for that entire VLAN. This method can be used regardless of the number of ports in the VLAN - you can have one port or dozens of ports in the VLAN. You can easily add ports to a subnet at any time. Another advantage of this type of routing is ports can easily be added or removed from the VLAN/subnet with the 4*!&+,"$#& <$=1 2++144 command:

!'&1#.2+1 324&5&,1#'1&67ND 4*!&+,"$#& 2++144 >?2' DN 4*!&+,"$#& <$=1 2++144 '$ !" 2==#144 L !'&1#.2+1 P?2'DN !" 2==#144 @88H@ONHDNH@E N88HN88HN88H6

Note that the VLAN assigned to the ports (>?2' DN) exactly matches the interface name (P?2'DN). This is what ties the router interface to the physical ports. Cisco refers to these as "Switched Virtual Interfaces (SVI's)." Don't let this fancy name intimidate you - it is simply a collection of ports in a Layer 2 VLAN, with a connection to the router portion of the 3560. Figure 1: Switched Virtual Interfaces (SVI's) for the 3560 (Logical Routing) shows a logical view of how the 3560 router function and the physical RJ-45 ports of the 3560 tie together using SVI's.



Internal Router Interface Fast Eth 0/8 Interface Fast Eth 0/1 switchport access vlan 8 switchport access vlan 3 Function in the 3560 Interface Fast Eth 0/17 Interface Fast Eth 0/2 switchport access vlan 8 switchport access vlan 3

Interface Fast Eth 0/10 Interface Vlan3 Interface Vlan8 Interface Fast Eth 0/20

ip address 147.142.8.1 switchport access vlan 8 switchport access vlan 3 ip address 147.142.3.1 Interface Fast Eth 0/21 switchport access vlan 8

VLAN 8 Logical "SVI" Interfaces subnet 147.142.8.0

Physical Interfaces

Figure 1: Switched Virtual Interfaces (SVI's) for the 3560 (Logical Routing)

Although both methods (physical routing and logical routing) work well, I prefer to use logical routing (SVI's) for all my routing, even if only a single port is in a VLAN (a case where physical routing would work). Here are my reasons for always using logical routing (even though in a few cases it may require an additional command or two): 1. Logical routing covers all situations - where there is one port in a

VLAN and where multiple ports are in a VLAN (IP subnet). Physical routing is limited to only one port in an IP subnet.

2. Logical routing allows additional ports to be added to a VLAN/subnet at a later time. In order to add ports to a subnet that is physically routed, you need to first convert it to logical routing - a bit of a hassle (especially under the pressure of the exam)!

3. Logical routing is very similar to the routing used by the 6500/MSFC platform. If you have any experience with these products you will find logical routing almost identical.

4. I can be completely consistent using logical routing - I can use it for routing on all my VLAN/subnets. If I use physical routing in some cases I'll almost surely also need logical routing in other cases. In that case I need to work with both types. I find it easier to simply deal with one type of routing!

5. All of my IP addressing configuration in the 3560 appears in one continuous section (the !'&1#.2+1 P?2'VV section).

As with so many things on the CCIE exam, you should select your preferred way, but know how to configure the solution both ways (especially since the exam may require you to do it the other way).

Lastly, don't forget to enable ip routing globally (!" #$%&!'()!!DHCP



The switch can act as a DHCP server (see the "DHCP" section of the Study Sheet) or a normal DHCP relay (!" ,1?"1#;2==#144 WHWHWHW). However the 3560 can also provide other DHCP functions.

DHCP Snooping is a security feature that prevents a certain type of "Man in the Middle" attack. In this scenario the attacker uses a device to impersonate a DHCP server in order to direct all traffic to a device the attacker controls. DHCP Snooping can also be used to prevent Denial of Service (DoS) attacks on a DHCP server by preventing the flooding of the server with bogus, unwanted requests.

DHCP Snooping can be enabled on most Catalyst switches. DHCP Snooping is disabled by default but can be enabled globally with the !" =,+" 4'$$"!'( command.

DHCP Snooping uses the notion of trusted and untrusted interfaces. DHCP Snooping only applies to untrusted interfaces. Each interface can be configured as a DHCP Snooping trusted or untrusted interface. Interfaces default to being untrusted but can be set to trusted using the !" =,+" 4'$$"!'( &#%4& interface command. To set an interface back to untrusted use the '$ !" =,+" 4'$$"!'( &#%4& command.

DHCP servers must be on interfaces that are configured as trusted - that is what allows them to freely send DHCP offers and acknowledgements. IP phone subnets can be configured as untrusted interfaces, allowing the switch to inspect the incoming DHCP requests for several security checks.

DHCP Snooping can be enabled on a VLAN with the !" =,+" 4'$$"!'(

>?2' -.#$,$'"()* command. This command only has effect if the !" =,+" 4'$$"!'( global command is enabled.

To help prevent DoS attacks you can apply rate limiting for DHCP packets on an interface. Use the !" =,+" 4'$$"!'( ?!<!& #2&1 *#/) interface command to limit DHCP packets. The actual number used for *#/) is the number of DHCP packets per second accepted on the interface. This command is normally only applied to untrusted interfaces, since presumably all DHCP packets on trusted interfaces are legitimate.

Optionally, the switch can provide additional security by maintaining DHCP Snooping binding tables. The binding table only applies to untrusted interfaces and contains individual bindings, which includes the MAC address, IP address, lease time, binding type, VLAN number, and interface information. The switch builds and updates this table dynamically by monitoring DHCP packets. The table can be displayed with the !"#$ %&$'!(&$ )""&%)*$+%)'%)*$command.



For further security IP Source Guard can be enabled. If DHCP Snooping has been enabled on an interface, the !" >1#!.K 4$%#+1 interface command can also be applied. This enables IP Source Guard, which restricts traffic on non-routed, layer 2 interfaces. DHCP Snooping watches for a DHCP address to be assigned to the interface. Once that occurs a port ACL is created, only allowing traffic to and from that IP address.

Etherchannels When creating Etherchannel connections in the 3560, you can create layer 2 or layer 3 Etherchannels. I recommend using layer 2 Etherchannels, simply because they are a bit simpler and because they are more similar to other Etherchannels you may have seen, such as with the 6500. Furthermore the difference is similar to the routing discussed in the previous section, Routing with the 3560. That is, Layer 2 Etherchannels get assigned to a VLAN (or configured as a trunk with several VLANs). Other ports can be added to any of the VLANs at any time, even if they will not be part of the Etherchannel.With Layer 2 Etherchannels you perform routing just as you would any Layer 2 VLAN (with the !'&1#.2+1 P?2'VV command). Layer 3 Etherchannels do not get assigned to a VLAN and only provide a point-to-point routed link, similar to the physical routing discussed earlier.

If I know I'm creating an Etherchannel (which you will), I set the Etherchannel mode to 'on' rather than 'auto' or 'desirable' with the +,2''1?;(#$%" O <$=1 $' command. Although desirable should work fine, I prefer "nailing" the Etherchannel on if I know I need it.

Make sure all the Etherchannel ports are configured the same - including VLAN(s), speed & duplex, trunking, Spanning Tree, etc.

I don't recommend spending a lot of time understanding the underlying Etherchannel protocols - either Port Aggregation Protocol (PAgP) or the Link Aggregation Control Protocol (LACP). They are interesting to read, but so is The Da Vinci Code yet it isn't going to help you on the exam very much. Rarely, if ever, have I had the need to configure or troubleshoot these protocols. I recommend spending a small amount of time reviewing their attributes that can be configured (just so you will have seen them), but spend the bulk of your Etherchannel time practicing Layer 2 (and Layer 3) Etherchannels.

Fallback Bridging Fallback bridging configures the switch to bridge (i.e., switch at layer 2) packets between different VLANs. This probably seems counter-intuitive - one of the reasons for creating VLANs is to create layer 2 boundaries. Fallback bridging is something you are very unlikely to ever use in "real" life - but of course this makes it perfect for the CCIE exam!



I think the idea behind fallback bridging was to allow the switch to create layer 2 VLANs for IP subnets (by far the most common protocol used in every network), but allow fallback bridging to bridge non-routable packets between several VLANs.

For example, let's assume you have a typical switch that may have four VLANs - each VLAN corresponding to an IP subnet. However let's also assume you have some legacy traffic in your network, such as DecNET or perhaps some proprietary protocol that is not routable. You can still maintain the four VLANs for the IP traffic, but create one, flat, bridged environment for all four VLANs for the non-routed traffic. Any routed port not assigned to a VLAN (i.e., )"$ #%,(!&"-,) can also be part of this bridging instance, called a bridge group.

You can have more than one bridge group on a switch - some VLANs could be in bridge group 1, while others were in bridge group 2. There is no connectivity between two different bridge groups on a switch.

A bridge group still allows each VLAN to run Spanning Tree (without allowing the BPDU's to get bridged together) and the bridge group runs its own instance of Spanning Tree, called the VLAN-bridge Spanning Tree. The VLAN-bridge Spanning Tree can run Spanning Tree with an external device - such as a router configured for bridging. You can configure the VLAN-bridge Spanning Tree with "typical" Spanning Tree commands:

F#!=(1 @ "#!$#!&K @EDOQ L 41&4 &,1 #$$& F#!=(1 "#!$#!&K L !'&1#.2+1 PCXY N F#!=(1;(#$%" @ "#!$#!&K EQ L 41&4 &,1 )H B#11 "$#& "#!$#!&K F#!=(1;(#$%" @ "2&,;+$4& 8 L 41&4 &,1 )H B#11 "2&, +$4& .$# &,1 !'&1#.2+1

To configure fallback bridging, create one or more bridge groups, then assign them to interfaces. This example creates two bridge groups and assigns several interfaces to each. There are no options when configuring the "protocol" on a bridge group:

F#!=(1 @ "#$&$+$? >?2';F#!=(1 F#!=(1 N "#$&$+$? >?2';F#!=(1 L !'&1#.2+1 PCXY @6 !" 2==#144 @6HOEH@H@ N88HN88HN88H6

F#!=(1;(#$%" @ L !'&1#.2+1 PCXY N6 !" 2==#144 @6HOEHNH@ N88HN88HN88H6

F#!=(1;(#$%" @ L !'&1#.2+1 324&5&,1#'1&67U '$ 4*!&+,"$#& !" 2==#144 @6HOEHDH@ N88HN88HN88H6

F#!=(1;(#$%" @



L !'&1#.2+1 PCXY @Q6 !" 2==#144 @6HOEHQH@ N88HN88HN88H6

F#!=(1;(#$%" N L !'&1#.2+1 PCXY @86 !" 2==#144 @6HOEH8H@ N88HN88HN88H6

F#!=(1;(#$%" N L !'&1#.2+1 324&5&,1#'1&67@O '$ 4*!&+,"$#& !" 2==#144 @6HOEHEH@ N88HN88HN88H6

F#!=(1;(#$%" N L

SPAN and RSPAN SPAN and RSPAN sessions are used to copy traffic from source ports or source VLANs to a port on the local switch (SPAN) or to a port on a remote switch via a special, dedicated VLAN (RSPAN). SPAN and RSPAN can copy just received traffic, transmitted traffic, or both (to/from the source ports or source VLANs) based on the keyword used when creating the session (#WT &W or F$&,). Existing SPAN and RSPAN sessions can be displayed with the 4,$* <$'!&$# command.

Normally SPAN and RSPAN don't copy Layer 2 control traffic (such as Spanning Tree BPDUs and CDP packets), though this can be overridden with the 1'+2"4%?2&!$' #1"?!+2&1 keyword. This can be useful if the lab requires all traffic to be copied. That keyword also maintains any ISL or 802.1Q trunk tagging the packets may have had at the point they were copied (without this keyword those headers are stripped before being sent out the SPAN/RSPAN ports).

SPAN is configured using two sets of commands - one specifies the source of the traffic, the other the destination ports. In this example traffic transmitted from a source port is used in session number 3:

<$'!&$# 4144!$' D 4$%#+1 !'&1#.2+1 32@767U &W <$'!&$# 4144!$' D =14&!'2&!$' !'&1#.2+1 32@767NQ

In this example traffic received on source VLANs are used in session number 1:

<$'!&$# 4144!$' @ 4$%#+1 >?2' O6 T :6 #W <$'!&$# 4144!$' @ =14&!'2&!$' !'&1#.2+1 32@767NQ

The source can be physical ports or VLANs - but the destination must always be a physical port.

To completely disable a session (such as session 2), use the '$ <$'!&$#

4144!$' N command.



If the monitoring device will be generating traffic (in addition to receiving it), the !'(#144 keyword is required. Ingress can be specified with the =$&@S >?2' -.#$,+% keyword, the !4? keyword or the %'&2((1= >?2'

-.#$,+% or just >?2' -.#$,+%) keyword to tell the switch how to handle the incoming traffic. Here traffic transmitted and received on port Fa0/0/1 is copied to port Fa0/1/12. Traffic received by the switch from port Fa0/1/12 is placed on VLAN 8 without any trunk encapsulation (untagged) in session number 4:

<$'!&$# 4144!$' Q 4$%#+1 .24&1&,1#'1&6767@ F$&, <$'!&$# 4144!$' Q =14&!'2&!$' !'&1#.2+1 .24&1&,1#'1&67@7@N !'(#144 %'&2((1= >?2' O

You can monitor all traffic on a trunk port by configuring that physical port as the source. To only monitor certain VLANs on that trunk, you can filter VLANs to prevent them from being monitored. The following example shows a trunk port carrying VLANs 80-89. The port is SPANned, but VLANs 81 and 85-88 are filtered. As such only VLANs 80,82-84 and 89 will be SPANned:

!'&1#.2+1 .267D 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R 4*!&+,"$#& &#%'R 2??$*1= >?2' O6;O: L <$'!&$# 4144!$' U 4$%#+1 .24&1&,1#'1&67D F$&, <$'!&$# 4144!$' U =14&!'2&!$' !'&1#.2+1 .24&1&,1#'1&67@: <$'!&$# 4144!$' U .!?&1# >?2' O@TO8 ; OO

RSPAN requires first configuring the RSPAN VLAN that will carry monitored traffic between switches. If VTP is configured for &#2'4"2#1'&

mode, this VLAN must be created on all switches that will participate in the RSPAN (even switches just passing the traffic through to other switches). If VTP is configured in +?!1'&741#>1# mode, the RSPAN VLAN can be configured on the server and it will be propagated to all client switches. The #1<$&1;4"2' VLAN command is required:

>?2' @66 #1<$&1;4"2'

RSPAN typically uses two sets of <$'!&$# commands - one set on the source switch and one set on the destination switch. At the source, the RSPAN source monitor command(s) are identical to the SPAN configuration. The destination command uses the #1<$&1 >?2' -.#$,+% keyword to direct traffic to the RSPAN VLAN: <$'!&$# 4144!$' N =14&!'2&!$' #1<$&1 >?2' @66



Similarly, at the destination the monitor source command references the remote vlan and the monitor destination command references the port to which the Sniffing device connects (similar to SPAN).

In this example switch A is monitoring port Fa0/1/24 (a member of VLAN 25). It copies the traffic onto RSPAN VLAN 101. It uses its port Fa0/1/1 to connect to switch B's port Fa0/1/1. Switch B is only passing through the RSPAN VLAN. It uses port Fa0/1/2 to connect to switch C's port Fa0/1/2. Switch C sends the traffic to a Sniffer connected to port Fa0/1/23. Note that while switch B requires the VLAN to be configured as a #1<$&1 >?2', it only passes through the VLAN on its trunk ports:

Switch A Switch B Switch C Fa0/1/2 Fa0/1/2

VLAN 25 Fa0/1/24 Trunk Fa0/1/23 VLANs 25, 101 VLANs 25, 101 Sniffer

Switch A

>&" <$=1 &#2'4"2#1'& >&" =$<2!' ++!1 L >?2' N8 '2<1 =2&2Z>?2' >?2' @6@ '2<1 >?2'Z.$#ZA)[XY #1<$&1;4"2' L !'&1#.2+1 324&5&,1#'1&@767@ 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R 4*!&+,"$#& &#%'R 2??$*1= >?2' N8T@6@ L !'&1#.2+1 324&5&,1#'1&@767NQ 4*!&+,"$#& 2++144 >?2' N8 4*!&+,"$#& <$=1 2++144 '$ !" 2==#144 L <$'!&$# 4144!$' E 4$%#+1 .24&1&,1#'1&@767NQ F$&, <$'!&$# 4144!$' E =14&!'2&!$' #1<$&1 >?2' @6@

Switch B

>&" <$=1 &#2'4"2#1'& >&" =$<2!' ++!1 L >?2' N8 '2<1 =2&2Z>?2' >?2' @6@ '2<1 >?2'Z.$#ZA)[XY #1<$&1;4"2' L !'&1#.2+1 324&5&,1#'1&@767@ 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R



4*!&+,"$#& &#%'R 2??$*1= >?2' N8T@6@ L !'&1#.2+1 324&5&,1#'1&@767N 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R 4*!&+,"$#& &#%'R 2??$*1= >?2' N8T@6@ L

$

Switch C

>&" <$=1 &#2'4"2#1'& >&" =$<2!' ++!1 L >?2' N8 '2<1 =2&2Z>?2' >?2' @6@ '2<1 >?2'Z.$#ZA)[XY #1<$&1;4"2' L !'&1#.2+1 324&5&,1#'1&@767N 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R 4*!&+,"$#& &#%'R 2??$*1= >?2' N8T@6@ L <$'!&$# 4144!$' E 4$%#+1 #1<$&1 >?2' @6@ <$'!&$# 4144!$' E =14&!'2&!$' !'&1#.2+1 32@767ND

Note that while Switch A and Switch C do not need to have the same session number (6, in this example) keeping them the same makes life simpler (if allowed by the lab). The configuration of Port Fa1/0/23 of Switch C (VLAN, etc.) is not particularly relevant, once it is used for a monitor destination.

Spanning Tree

Modes Spanning Tree on the 3560 is very similar to Spanning Tree used by bridges and switches for years, though Cisco has made some enhancements. The 3560 can use one of three different modes for Spanning Tree:

· PVST+ - Per-VLAN Spanning Tree (traditional 802.1d Spanning Tree running on each VLAN individually)

· Rapid PVST+ - Per-VLAN Spanning Tree with rapid convergence (IEEE 802.1w)

· MSTP - Multiple VLAN Spanning Tree (IEEE 802.1s)

PVST+ runs a separate instance of Spanning Tree for each VLAN. Each instance can be configured differently (root bridge, timers, etc.) - however if you are allowed I highly recommend configuring them identically!

Rapid PVST+ is extremely similar to PVST+, though the Spanning Tree network will converge more quickly, meaning ports will go through



listening and learning states to arrive at either forwarding or blocking much faster.

MSTP allows multiple VLANs to be mapped to the same Spanning Tree instance, reducing the number of Spanning Tree instances operating on the switch. In this mode many VLANs (possibly all of them) will really only be running one Spanning Tree.

PVST+ is the default Spanning Tree mode, though the mode can be set with the 4"2''!'(;&#11 <$=1 ">4& \ <4& \ #2"!=;">4& command.

Rapid PVST+ uses most of the same concepts as PVST+ (root bridge, path cost, ports go through blocking/listening/learning/forwarding states, etc.) Rapid PVST+ also introduces the concept of "Edge Ports," implemented with the 4"2''!'(;&#11 "$#&.24& interface command. These are ports that immediately transition into the forwarding state. As such only ports connecting to end-stations should be configured this way. Rapid PVST+ also uses the 4"2''!'(;&#11 ?!'R;&K"1 /01) interface command. Full duplex ports are assumed to be point-to-point connections; half- duplex ports are considered to use a shared connection. This can be overridden with the 4"2''!'(;&#11 ?!'R;&K"1$/01) interface command.

MSTP introduces the concept of regions. Regions are extremely simple - it is one or more switches that have the exact same MSTP configuration. All switches in the same region must be configured the same way:

4"2''!'(;&#11 <4& +$'.!(%#2&!$' !'4&2'+1 @ >?2' N;@6 '2<1 #1(!$'@ #1>!4!$' @

The region's name and revision can be set to anything (they simply must be set the same on each switch in the region). Again - I prefer to keep things simple!

Root Bridge My approach to Spanning Tree is to first identify the root bridge. In the real world this is the bridge closet to the core of my network. In the CCIE lab they may specify which device should be the root, or you may need to figure it out. One quality of the root is it will be the bridge where you want all ports forwarding, since the root bridge never blocks ports.

The root bridge in Spanning Tree is defined as the switch with the lowest bridge ID. The bridge ID is composed of the switch's priority (from the configuration) combined with the switch's MAC address. The MAC address acts as the tie-breaker in the event multiple switches have the same priority (something you want to avoid, both in the real world and in the lab!!!) A switch can be configured as the root with either the 4"2''!'(;



&#11 >?2' -.#$,+% #$$& "#!<2#K command or the 4"2''!'(;&#11 >?2'

-.#$,+% "#!$#!&K 1*+!*+/0 command.

The former command sets the priority of the switch for the specified VLAN to 24576 if that will cause the switch to become the root for that VLAN. If a switch on that VLAN has a priority lower than 24576, the command causes the switch to set its priority to 4096 lower than the lowest switch priority (thus causing it to become the root). The latter command sets the priority of the switch for the specified VLAN to between 0 and 61440 (in increments of 4096). If the switch has the lowest priority it will become the root bridge.

If allowed, I recommend setting the root bridge with the 4"2''!'(;&#11

>?2' -.#$,+% "#!$#!&K Q6:E command. That way you'll know that switch will be the root and you'll know its priority exactly. If they require you to configure the root without using a specific root priority, then you'll need the 4"2''!'(;&#11 >?2' -.#$,+% #$$& "#!<2#K command.

Path Costing Once I have selected my root bridge I cost paths appropriately to allow the bridges to forward and block on each link as I see fit. I usually do this by lowering the default cost on a link I want to be in forwarding mode. You could raise the cost of a link you want in blocking mode, though if you ever add a redundant link it will start with the default cost and compete with your forwarding link. If you lower the cost on your forwarding link, you can add additional links without worrying about setting path costs.

On each subnet a designated bridge is elected. This is the bridge that will have the forwarding path to the root. The bridge with the lowest path cost to the root will be the designated bridge (and thus will be forwarding). In the case where two or more bridges have the exact same path cost to the root, the bridge with the lowest priority becomes the designated bridge.

The path cost is calculated by adding the "outbound" path costs of all paths (links) to the root. That is, path costs are added as you are leaving each switch on the way to the root (the path cost as you enter a switch is irrelevant). On the 3560 the default path cost is dependent on the link speed:

· 1000 Mb/s: 4

· 100 Mb/s: 19

· 10 Mb/s: 100

So on a given switch to change a link that is in the blocking state to be forwarding, I recommend lowering the path cost on the blocked port (though in some cases you may need to increase the path cost on the forwarding link) using the 4"2''!'(;&#11 +$4& !2/ command. If a port is



a trunk and you only want to apply a path cost on a single VLAN, use the 4"2''!'(;&#11 >?2' -.#$,+%$(" ,$ !2/ command.

Port priority is almost never used ( &.))%)*/,-00$12.)$-.#$,+%$ &"-,/&-%"-%,3$1*+!*+/0). The only time this might be used is if two non-root bridges had redundant links between them. One of the four ports for those two links would have to block - port priority would allow you to control which one it was. If you don't set this on any of the four, the IOS will select one to block.

Features Port fast is used for ports that connect to end stations (or devices that do not run Spanning Tree) in order to place those ports into a forwarding state much faster than without the &.))%)*/,-00$&"-,4. ,

command.

BPDU Guard is a feature to protect ports configured for Port Fast. BPDU Guard is enabled with the global &.))%)*/,-00$&"-,4. ,$ +&'5*5.-'$'04.52,$command. It will then shut down any port configured for Port Fast on which a BPDU is received - since those ports should only be connected to end stations. You can also enable BPDU Guard on an individual port that is not configured for Port Fast with the &.))%)*/,-00$+&'5*5.-'$0).+20$interface command. On ports configured as trunks rather than shutting down the entire port you can just shut down the VLAN on which the unexpected BPDU was received with the 0--'% .+20$'0,0(,$(.5 0$+&'5*5.-'$ !5,'"#)$12.) global command.

BPDU Filtering is probably a better feature than BPDU Guard. It is similar - it is enabled globally with the &.))%)*/,-00$&"-,4. ,$ +&'54%2,0-$'04.52, global command and it applies to Port Fast ports. However it blocks the receiving and sending of BPDUs. Furthermore if it received a BPDU on a port that is configured for Port Fast and a BPDU is received on that interface, it loses its Port Fast status and starts acting like a normal Spanning Tree port (listening, learning, forwarding). You can also block the sending and receiving of BPDU on "normal" ports (non- Port Fast) with the &.))%)*/,-00$+&'54%2,0-$0).+20 interface command. This operates the exact same way as the global command - though just on the one port.

UplinkFast is designed to allow a switch to regain connectivity very quickly in the event of failure of a directly connected link.With the &.))%)*/,-00$ 5&2%)64. , global command, if the switch loses link on its root port (the port on which it has connectivity back to the root - an uplink, usually) the new root port (the other "uplink" or other connection to the core that had been blocked) immediately goes into the forwarding state, bypassing the listening and learning states. Note that since it is made for access switches



(typically), this cannot be configured on a switch that has had its root priority configured (4"2''!'(;&#11 >?2' -.#$,+% "#!$#!&K 1*+!*+/0).

BackboneFast is similar to UplinkFast, except that it detects failures of links that are not directly connected. If a switch has the &.))%)*/,-00$ +.(6+")04. , global command and it detects a remote link failure - by receiving a BPDU from a switch that had an active path to the root that now indicates that path is gone, it actively starts looking for a new path to the root - without waiting the typical standard delay. Note that Cisco states you must enable BackboneFast on all switches in the network (so all switches agree on the faster timers), and that it only applies to PVST+ (you can configure it while in rapid PVST+ or MSTP, but it won't activate until the mode is changed to PVST+).

Root Guard is configured per interface (no global commands needed) with the &.))%)*/,-00$*5.-'$-"",$command.When configured the port will run Spanning Tree normally, but it will not learn about the root via that port. There can be "downstream" switches connected to that port (switches that use that port to access the root), but the switch on which it is configured will never use that port to access the root bridge.

Loop Guard prevents loops that could occur within Spanning Tree due to unidirectional links - when one switch thinks a link is up and the other thinks it is down. Loop Guard is enabled globally with the &.))%)*/ ,-00$2""&*5.-'$'04.52, global command. Loop Guard prevents root ports or alternate ports (ports that are used to get to the root bridge or blocked ports) from becoming a designated port (the port in a VLAN/subnet that other switches use to get to the root bridge.

Examples See the "Spanning Tree" section of the Study Sheet (on page 148) for examples of Spanning Tree configurations.

VTP The VLAN Trunking Protocol (VTP) is used to propagate VLAN information between 3560's. VTP automatically propagates this information from the VTP server to all VTP clients. VTP is not required - VLANs can be defined manually on each switch. In fact, this is my preference. If I need VLAN 5 on 3560-1 and on 3560-2 I would prefer to manually create it on each switch and assign the appropriate ports to it (in this case the switches would be configured to not participate in VTP with the >&" <$=1 &#2'4"2#1'& command).

However you may be asked to use VTP on the exam. In that case it is important to identify the switch that will be the VTP server. The exam may choose for you or you may be allowed to pick a switch. In that case the actual switch selected is not particularly important - just remember to



create and modify VLANs on that switch. It will propagate updates to all other VTP clients in the same VTP domain (so it is important to use the same >&" =$<2!' %!"#+$,$#") command on each switch). Although a VTP client switch will learn its VTP domain name via VTP advertisements received on a trunk link, I prefer to configure the VTP domain name on each switch. This eliminates any question or doubt about the VTP domain. Just make sure that the switches are configured with the identical VTP domain name, otherwise they will not exchange information.

As discussed earlier, remember that any switch configured for VTP transparent mode (>&" <$=1 &#2'4"2#1'&) will not send or receive VTP updates. All VLAN information needs to be configured manually on these switches.

VTP commands can be entered in global configuration mode (+$'.!( &) or VLAN mode (>?2' =2&2F241). Global configuration mode offers a few (rarely used) additional commands.

VTP can be protected with the >&" "244*$#= 1#223!*% command. Although this is not often used in real life, you may be required to use this on the exam.

3560 Connection Types Based on its functionality, there are several "ways" the 3560 can be used, especially on the CCIE exam. Listed below are four basic 'connection types' the 3560 can employ: 1. The 3560 can be used to create a Layer 2 VLAN made up of

access ports in which it does not participate in routing. This is the equivalent of the 3560 acting like a 'pure' Layer 2 switch.

2. The 3560 can be used to create Layer 2 VLANs made up of access ports and trunk ports, where the 3560 does not participate in routing. The trunk ports will connect to another device that also supports trunking. This allows an external router, such as a 3700, to connect to several VLANs via a single physical connection.

3. The 3560 can be used to route (i.e., a "Layer 3 VLAN") using access ports only. This is similar to connection type #1, but here the 3560 participates in and performs routing.

4. The 3560 can be used to route (i.e., a "Layer 3 VLAN") using access and trunk ports. This is similar to connection type #2, but here the 3560 participates in and performs routing.

Example of Using the 3560 Here is an example of using the 3560 for all four "connection types" (discussed in the previous section). I always make note of the physical connectivity (how devices are cabled together) vs. the logical connectivity (what devices are on what subnets). I have found that the more I have



worked with the 3560 the more comfortable I am with the connection types.

In the lab you may find it useful to draw both diagrams so you clearly understand both how the devices are cabled as well as what subnets they share. On the logical diagram you may also want to add the port and/or interface used by each device. I have omitted these simply because I didn't want to clutter this diagram.

Figure 2: Typical 3560 Connectivity (Physical) and Figure 3: Typical 3560 Connectivity (Logical) show how a 3560 can be connected to utilize all four "connection types":

· The 3560 provides a simple Layer 2 VLAN (VLAN 192) for r5 and r6 (connection type 1).

· The 3560 provides a Layer 2 VLAN (VLAN 64) for r4 and r14, though r4 connects with an access port and r14 connects via a trunk port (connection type 2).

· The 3560 provides a VLAN (VLAN 32) for r13 and r16 (itself) using access ports on which it also routes (connection type 3).

· Finally the 3560 provides a VLAN (VLAN 128) for r14 and r16 (itself) using a trunk port on which it also routes (connection type 4).

3560 Physical Diagram

r5 r6

VLAN 192 VLAN 192 155.182.192.0/24 3560 155.182.192.0/24

r13 FA 0/5 (r16) FA 0/6 r4

FA 0/23 FA 0/4

VLAN 32 155.182.32.0/24 trunk

FA 0/14 VLAN 64 155.182.64.0/24 VLAN 128

r14 155.182.128.0/24

Figure 2: Typical 3560 Connectivity (Physical)



3560 Logical Diagram

r6 r5

VLAN 192 connection

155.182.192.0/24 type 1

VLAN 32 connection 155.182.32.0/24 type 3 3560 (r16) r4

r13

connection type 4 VLAN 64

155.182.64.0/24 r14

connection type 2

Figure 3: Typical 3560 Connectivity (Logical)

You should be familiar with each of these types of connectivity. The configurations for each device are included below. Note how the VLAN number equals the third octet of the IP subnet and how the forth octet of the IP address is the same as the router number.

Here are the configurations from each device in the figures above:

,$4&'2<1 D8E6;#@E !'&1#.2+1 324&5&,1#'1&67Q 4*!&+,"$#& 2++144 >?2' EQ '$ !" 2==#144 L !'&1#.2+1 324&5&,1#'1&678 4*!&+,"$#& 2++144 >?2' @:N '$ !" 2==#144 L !'&1#.2+1 324&5&,1#'1&67E 4*!&+,"$#& 2++144 >?2' @:N '$ !" 2==#144 L !'&1#.2+1 324&5&,1#'1&67@Q 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R '$ !" 2==#144 L !'&1#.2+1 324&5&,1#'1&67ND



4*!&+,"$#& 2++144 >?2' DN 4*!&+,"$#& <$=1 2++144 '$ !" 2==#144 L !'&1#.2+1 P?2'DN !" 2==#144 @88H@ONHDNH@E N88HN88HN88H6 L !'&1#.2+1 P?2'@NO !" 2==#144 @88H@ONH@NOH@E N88HN88HN88H6 ,$4&'2<1 #8 !'&1#.2+1 5&,1#'1&6 !" 2==#144 @88H@ONH@:NH8 N88HN88HN88H6 ,$4&'2<1 #E !'&1#.2+1 5&,1#'1&6 !" 2==#144 @88H@ONH@:NHE N88HN88HN88H6 L !'&1#.2+1 )1#!2?6 !" 2==#144 @88H@ONH@E6HE N88HN88HN88H6 ,$4&'2<1 #Q !'&1#.2+1 5&,1#'1&6 !" 2==#144 @88H@ONHEQHQ N88HN88HN88H6 L !'&1#.2+1 )1#!2?6 !" 2==#144 @88H@ONH@E6HQ N88HN88HN88H6 ,$4&'2<1 #@D !'&1#.2+1 5&,1#'1&@76 !" 2==#144 @88H@ONHDNH@D N88HN88HN88H6 ,2?.;=%"?1W L !'&1#.2+1 )1#!2?@7@ !" 2==#144 @88H@ONH@EH@D N88HN88HN88H6 +?$+R#2&1 @666666 ,$4&'2<1 #@Q !'&1#.2+1 324&5&,1#'1&676 '$ !" 2==#144 L !'&1#.2+1 324&5&,1#'1&676HEQ 1'+2"4%?2&!$' =$&@] EQ !" 2==#144 @88H@ONHEQH@Q N88HN88HN88H6 L !'&1#.2+1 324&5&,1#'1&676H@NO 1'+2"4%?2&!$' =$&@] @NO !" 2==#144 @88H@ONH@NOH@Q N88HN88HN88H6 L !'&1#.2+1 )1#!2?@7@ !" 2==#144 @88H@ONH@EH@Q N88HN88HN88H6

The 3560 is a complex and powerful device. I highly recommend taking some time to read the configuration guide and command reference thoroughly. Make sure you have some hands-on experience!



BGP

Peers BGP uses two types of peers: internal BGP (iBGP) peers and external BGP (eBGP) peers. Internal peers are BGP peers that are in the same Autonomous System (AS). External BGP peers are peers that are in different Autonomous Systems.

By default eBGP peers must define each other as neighbors using the subnet that directly connects them. If either one or both do not use this "directly connected" address (if either one or both use their loopback addresses or if they are separated by a few hops) they must use the 1F(";

<%?&!,$" neighbor command.

By default iBGP peers can be up to 255 hops away without requiring the 1F(";<%?&!,$" command.

If BGP peers (eBGP or iBGP) peer between loopback addresses they will also need the %"=2&1;4$%#+1 neighbor command. This instructs the local router to update its BGP source IP address with the interface specified (such as loopback 0). Otherwise by default the router uses the IP address of the outgoing interface used to reach the BGP peer as its BGP source address. If you are peering between loopback addresses, this address will not match the IP address defined at the remote peer via the neighbor command. This mismatch will prevent the BGP peer relationship from forming.

Advertising to Peers If a router is originating a route with the '1&*$#R command, the exact network and mask specified must be in that router's routing table. This is worth noting - and it becomes especially important when attempting to advertise a summary. If the router has networks 172.16.16.0/24 through 172.16.19.0/24 in its routing table these can be advertised by one summary advertisement (172.16.16.0/22). However if you simply enter:

#$%&1# F(" E8666 '1&*$#R @UNH@EH@EH6 <24R N88HN88HN8NH6

The router will not advertise the summary nor any of the four class C subnets. This is because you have stated to only advertise the summary, yet the router does not have that exact network and mask in its routing table. This can be overcome with the aggregate-address command (see the Aggregate Address example on page 153) or with a static route to null0. For the latter technique, simply place a static route in the routing table to act as a placeholder so BGP will advertise a route. So you could enter:

!" #$%&1 @UNH@EH@EH6 N88HN88HN8NH6 '%??6



#$%&1# F(" E8666 '1&*$#R @UNH@EH@EH6 <24R N88HN88HN8NH6

In this case the router will advertise the summary 172.16.16.0/22 (since it is now in its routing table).When actual traffic reaches this router it will have a valid route pointing to null0, yet it will also have four more specific (in this case /24) routes in its routing table. More specific routes always take precedence over less specific routes, so the traffic will get routed correctly.

Make sure you check carefully if static routes to null0 are allowed in order to use this approach.



BGP peers do not always advertise BGP updates to each other. The table below summarizes how BGP advertises:

Table 1: BGP Route Advertisement Rules

Update Will I send an What the "next-hop" attributewill be set to received update to: from: An An YES The advertising router will set the next hop to external external the value it is using for the BGP session for the BGP BGP router to which it is making the advertisement. Peer Peer This is usually the IP address on the interface

connecting to the peer, but can be overridden with the %"=2&1;4$%#+1 command.

An An YES By default on advertisements to iBGP peers, external internal the advertising router maintains the next hop BGP BGP value that it received from the eBGP peer. Peer Peer Thus when the update reaches the iBGP peer,

the next hop will be an IP address that is not directly connected to it! **

An An YES The advertising router will set the next hop to internal external the value it is using for the BGP session for the BGP BGP router to which it is making the advertisement. Peer Peer This is usually the IP address on the interface

connecting to the peer, but can be overridden with the %"=2&1;4$%#+1 command.

An An NO* Normally iBGP peers do not advertise routes to internal internal iBGP peers, thus there is no next-hop attribute. BGP BGP This no-advertise behavior can be overridden Peer Peer using confederations or route-reflectors.

* - This is the reason iBGP networks require a "full mesh" of connectivity. If you receive an update from an internal peer, you will not forward that to another internal peer. Thus whenever a router within an AS advertises a route it must advertise it to all BGP routers within that AS (i.e., all iBGP routers). ** - This is why it is important that this iBGP peer have a route (usually via its IGP) to that next-hop subnet. If the iBGP peer does not have a route to the BGP next hop subnet, it will not insert the route into its routing table!!! (A common symptom of this is to see the route in the BGP table [show ip bgp] but not in the routing table). This behavior can be overridden with the '1W&;,$";41?. BGP neighbor command. This forces the advertising router to replace the next hop attribute with the value it is using for the BGP session for the router to which it is making the advertisement (the iBGP peer). Usually this is either its loopback address or a directly connected IP address. This address will be reachable from the iBGP peer - or the BGP session won't be "up" anyway!



iBGP Full Mesh As briefly discussed in the previous section, internal BGP (iBGP), that is, BGP within one Autonomous System, must have a logical "full mesh" of connectivity. In other words every iBGP router must have a logical connection (a peer relationship) with every other BGP router in that AS. This requirement exists because BGP does not inherently have good loop- detection capability (especially within an AS). A physical full mesh is not required, but even a logical full mesh can become unmanageable!

There are two alternate solutions to the iBGP full mesh requirement: route reflectors and confederations.

Routers that are configured in a route reflector are collectively known as a cluster.Within the cluster, each router is either a route reflector server or a route reflector client. Typically there are either one or two route reflector servers in a cluster. There can be many (dozens if not hundreds) of clients in a route reflector cluster. Route reflector clients require no configuration. In fact they do not even realize they are in a cluster. Route reflector servers require that each client be identified with the '1!(,F$# #$%&1;

#1.?1+&$#;+?!1'& command.When route reflector servers receive routing updates from clients they forward the update to all other clients as well as to any iBGP peers they have that are not participating in the cluster.When route reflector servers receive routing updates from iBGP peers that are not participating in the cluster they forward the update to all clients but not to other iBGP peers that are not participating in the cluster.

Deploying confederations breaks an Autonomous System up into smaller Autonomous Systems called confederations. Confederations act like a hybrid between EBGP and iBGP.When exchanging routing updates with other (real) Autonomous Systems, the confederations are completely hidden (like an iBGP). Yet when exchanging routing updates between confederations, then deploy EBGP rules. That is, there is not a full mesh requirement. In fact two confederations can have one connection between them, multiple connections between them, or even no connections between them.

Route reflectors are the easier solution to implement and offer few, if any, drawbacks from the confederation solution.

Filtering Although there are many ways to filter with BGP, I like using route-maps with prefix lists. Part of the reason is you need to master route-maps, so this is a skill you will need anyway. Furthermore both the route-map and prefix-list can use the same, meaningful name. See the CCIE Study Sheet "BGP - Filtering with Route Maps" for an example of this.

To filter BGP routes you can use:



" '1!(,F$# #$%&1;<2" command with only a <2&+, !" 2==#144

statement in the route-map " '1!(,F$# =!4&#!F%&1;?!4& (applies to the neighbor specified) " =!4&#!F%&1;?!4& (applies to the entire BGP process) " '1!(,F$# .!?&1#;?!4& with an !" 24;"2&, 2++144;?!4&

" '1!(,F$# "#1.!W;?!4&

The first two options apply the filter to a specific neighbor. The third option applies the filter to the entire BGP process (routes learned from any neighbor). Using just a =!4&;?!4& filters updates from the routing table but leaves them in the bgp table. The other two eliminate them from both.

The '1!(,F$# "#1.!W;?!4& command or the '1!(,F$# =!4&#!F%&1;?!4&

can be applied to a neighbor - but not both commands to the same neighbor. Given my preference for prefix lists, I prefer the '1!(,F$#

"#1.!W;?!4& command.

When filtering based on AS path, use the '1!(,F$# .!?&1#;?!4&

command. However note that using ̂ (to denote the beginning of an AS path) matches the beginning of the path as it is listed in the bgp table. For example, to match: Y1&*$#R Y1W& ^$" _1&#!+ C$+[#. `1!(,& [2&, a !DH6H6H6 @DUHD:HNDHO: @666 86 6 !"#$!#%

You could use the BGP show regular expression command: 4,$* !" F(" #1( bU6@ZO6Z

This will show you the BGP entries that match the particular regular expression you specify (in this case, beginning with 701, followed by 80).

The BGP regular expression command (above) states that the "beginning" of the AS path must be 701 (followed by 80). Even though the true "beginning" of the AS path is 80 (that is, the route was originated from AS 80, then went through 701). The same holds true when using $ to mark the end of an AS path.

Thus to construct an AS_PATH filter, you apply the same logic:

!" 24;"2&, 2++144;?!4& @ "1#<!& bU6@ZO6Z #$%&1# F(" E8@ND '1!(,F$# @DQH@EUH@H@6 .!?&1#;?!4& @ !'

Communities In order to send communities, you need to enter the '1!(,F$# @6H@DH@DH@

41'=;+$<<%'!&K command. This will send to that neighbor both: any communities that BGP routes already have (that were sent to you from



other peers and/or AS's) as well as any communities you set with a route- map. Communities are not sent by default - they need this command!!!

In order to tag routes with communities, you need:

'1!(,F$# @:NH@EOH@HN 41'=;+$<<%'!&K '1!(,F$# @:NH@EOH@HN #$%&1;<2" 41&+$<<%'!&K $%& #$%&1;<2" 41&+$<<%'!&K "1#<!& @6 <2&+, !" 2==#144 N 41& +$<<%'!&K '$;1W"$#& L #$%&1;<2" 41&+$<<%'!&K "1#<!& N6 L 2++144;?!4& N "1#<!& @:NH@EOHN8QH6

You need the second route-map statement to send "all other" routes without communities. Also, it is helpful to use the global command !" F(";

+$<<%'!&K '1*;.$#<2&. Otherwise your communities look really weird!

Synchronization Synchronization is a parameter that can be enabled or disabled in #$%&1# F(" configuration. Synchronization requires that a BGP route must also show up in an IGP (OSPF, EIGRP, etc.) before it will be installed in the routing table. This rule was established in case some routers within a network were not running BGP. If they were not running BGP and the routes were not in the IGP, those routers would not be able to correctly forward packets because they would be "missing" routes. You can 'officially' disable synchronization if either of the following are true: 1. All routers in the AS run BGP (thus there is no need to include them in the IGP)

2. The AS is not a transit AS, that is, it does not forward traffic between other Autonomous Systems (in this case it is presumed non-BGP routers will know how to correctly forward traffic since it is destined for within their Autonomous System).

My rule of thumb is to turn it off whenever possible!With it on, all iBGP learned routes must also show up in some IGP (OSPF, etc.) Even static routes are not enough! This can be very frustrating since it is not always obvious why the routes appear in the BGP table but do not appear in the routing table. A closer examination of a BGP route shows:

As you can see, the route 10.20.255.236/32 appears in the BGP table but not in the routing table:

ABCD3INN;@8E04,$ !" F(" Y1&*$#R Y1W& ^$" _1&#!+ C$+[#. `1!(,& [2&, a !@6HN6HN88HNDE7DN @6HN6HN86HNDE 6 @66 6 ! ABCD3INN;@8E04,$ !" #$%&1 F("



ABCD3INN;@8E0

A closer examination of the BGP entry shows that the route is not synchronized (a case where synchronization is still enabled on the router):

ABCD3INN;@8E04,$ !" F(" @6HN6HN88HNDE GM[ #$%&!'( &2F?1 1'&#K .$# @6HN6HN88HNDE7DNT >1#4!$' D [2&,4J -@ 2>2!?2F?1T '$ F14& "2&,/ Y$& 2=>1#&!41= &$ 2'K "11# C$+2? @6HN6HN86HNDE -<1&#!+ N/ .#$< @6HN6HN86HNDE -@6HN6HN86HNDE/ c#!(!' dM[T <1&#!+ 6T ?$+2?"#1. @66T >2?!=T !'&1#'2?T &'(# )*&+,-'&%./0 ABCD3INN;@8E0

Use the '$ 4K'+,#$'!e2&!$' command under the router BGP config to disable synchronization.

Aggregate Address This is a useful command for summarizing an address block. Use the keyword 4%<<2#K;$'?K to suppress more specific routes. If this keyword is not included, the aggregate address you specify will be advertised, but the more specific routes will be as well. However to advertise a summary (an aggregate) at least one more specific route must be in the router's BGP table (via a network command, redistribution, etc.)

Attributes It is extremely important to understand each BGP attribute - especially the more important ones (local pref, AS_PATH, MEDs, communities). I won't identify all the BGP attributes, but I will discuss the more common ones. I recommend further reading and a lot of hands-on practice, but here is an overview: AS_PATH - possibly the most important BGP attribute. It is a "running tally" of all the Autonomous Systems through which the advertisement has passed. This is important since (realistically) only local preference is higher in the order of route selection. This is by far the most common attribute used to determine routing on the Internet. Often routing is controlled by prepending an ASN (making the AS_PATH longer by including your own ASN several times). Local Preference - this is effectively first on the BGP route selection algorithm. It is set within an AS, it is passed to all routers in the AS yet it does not leave the AS. It controls how that AS routes traffic outbound to other AS's. Since it is shared among all routers in an AS, all routers should agree on the local preference for each route. The higher local preference is preferred. A router can set the local preference on all routes (F(" =1.2%?& ?$+2?;"#1.1#1'+1) or on specific routes (41& ?$+2?; "#1.1#1'+1 via a route-map). For example, assume AS 10 has two ISP connections, ISP 1 and ISP 2. Without setting Local Preference, AS 10 will route traffic to whichever ISP



offers a shorter AS path for each route. But suppose AS 10 wants to route traffic via ISP 2 (if ISP 1 is a measured service, for example). AS 10 can set Local Preference higher on routes learned via ISP 2. This will cause routing via ISP 2 (unless a failure occurs, upon which ISP 1 will be used). See the CCIE Study Sheet on page 152 for an example config on setting local preference. Origin - Origin is an attribute that denotes how the route was first placed into BGP (or its "origin"). It is included in routing advertisements as they pass from one AS to another. It is surprisingly high on the route selection algorithm, though it is rarely used in route selection. This is because it is extremely rare to have two possible choices (paths) for a route where the origins are different. Since the two possible routes invariably started from the same AS, they almost always have the same origin. Origin of "i" means it was placed into BGP via a network statement, "?"means via redistribution and "e" means via EGP (rare). It can be set via BGP configuration, though this is not common. MEDs - the Multi-Exit Discriminator attribute is targeted for the scenario where two AS's have multiple connections between them. In this case most other attributes will be identical - local pref, AS_PATH, origin, etc. MEDs allow as AS to influence how the other AS routes traffic to it.We say "influence" since the other AS can still set the local preference if it desires, and since local preference is higher than MEDs on the route selection algorithm, MEDs will be ignored. The lower MED (like an IGP metric) is preferred. It is sent from one AS to another AS, but the receiving AS does not send it to any other AS's. So if AS 1 and AS 2 have two connections between them (connection x and connection y), AS 1 could set the MED on each so that the MED is lower on connection x. Assuming AS 2 does not set weight or Local Preference, traffic routed from AS 2 to AS 1 will get sent over connection x.Why would this be advantageous? Perhaps AS 1 wants traffic delivered over connection x because it is closer to the core of their network, or it connects into a more robust portion of their network. Weight - weight is the first attribute on the route selection algorithm, but I have never seen it used. Not on a practice lab, in real life - never. It is a "Cisco proprietary" attribute and is local to the router only (not passed with a routing advertisement at all). It can be set with the '1!(,F$# *1!(,& or the 41& *1!(,& commands&from what I'm told. Community - This attribute is sent with each routing advertisement from AS to AS. It is set with the 41& +$<<%'!&K route-map command. It is basically a way of identifying, or tagging certain routes. There are well known communities (such as no-export which means do not advertise this route to any other AS's and no-advertise which means do not advertise this route to any peer (internal or external)). There are also user-defined communities. These are common within an AS to denote or identify certain features. They also can be used between AS's, though this requires the coordination of the two AS's. Their most common use is to identify a route



so that some action - not advertising, setting local preference, blocking completely, etc. - can be taken at some point later.

BGP Official Path Selection Process BGP has a somewhat complicated route selection algorithm (when presented with the same route from more than one peer). From the CCO, here is the "official" process. See the following section for my unofficial process. My unofficial process streamlines the "official" process into the most common scenarios.

1. If the next hop is inaccessible, do not consider it.

This is why it is important to have an IGP route to the next hop.

2. If the path is internal, synchronization is enabled, and the route is not in the IGP, do not consider the route. 3. Prefer the path with the largest weight (weight is a Cisco proprietary

parameter). 4. If the routes have the same weight, prefer the route with the largest local

preference. 5. If the routes have the same local preference, prefer the route that was

originated by the local router.

For example, a route might be originated by the local router using the network bgp command, or through redistribution from an IGP.

6. If the local preference is the same, or if no route was originated by the local router, prefer the route with the shortest autonomous system path.

7. If the autonomous system path length is the same, prefer the route with the lowest origin code (IGP < EGP < INCOMPLETE).

8. If the origin codes are the same, prefer the route with the lowestMulti Exit Discriminator (MED) metric attribute.

This comparison is only done if the neighboring autonomous system is the same for all routes considered, unless bgp always-compare-med is enabled.

Note The most recent IETF decision regarding BGP MED assigns a value of infinity to the missing MED, making the route lacking the MED variable the least preferred. The default behavior of BGP routers running Cisco IOS software is to treat routes without the MED attribute as having a MED of 0, making the route lacking the MED variable the most preferred. To configure the router to conform to the IETF standard, use the bgp bestpath missing-as-worst command.

9. Prefer the external (EBGP) path over the internal (IBGP) path.



All confederation paths are considered internal paths.

10. Prefer the route that can be reached through the closest IGP neighbor (the lowest IGP metric).

This means the router will prefer the shortest internal path within the autonomous system to reach the destination (the shortest path to the BGP next-hop).

11. If the following conditions are all true, insert the route for this path into the IP routing table:

$ Both the best route and this route are external. $ Both the best route and this route are from the same neighboring

autonomous system. $ maximum-paths is enabled.

Note EBGP load sharing can occur at this point, which means that multiple paths can be installed in the forwarding table.

12. If multipath is not enabled, prefer the route with the lowest IP address value for the BGP router ID.

The router ID is usually the highest IP address on the router or the loopback (virtual) address, but might be implementation-specific.

BGP Unofficial Path Selection Process This is derived from the "Official" Path Selection Process, but I have removed scenarios that almost never exist.

1. If the next hop is inaccessible, do not consider it.

This is why it is important to have an IGP route to the next hop address.

2. If the path is internal, synchronization is enabled, and the route is not in the IGP, do not consider the route. (So turn off synchronization!)

3. If the routes have the same weight, prefer the route with the largest local preference.

4. If the local preference is the same prefer the route with the shortest autonomous system path. 5. If the origin codes are the same, prefer the route with the lowest Multi

Exit Discriminator (MED) metric attribute. 6. Prefer the external (EBGP) path over the internal (IBGP) path. 7. Prefer the route that can be reached through the closest IGP neighbor (the lowest IGPmetric).



This means the router will prefer the shortest internal path within the autonomous system to reach the destination (the shortest path to the BGP next-hop).

8. If multipath is not enabled, prefer the route with the lowest IP address value for the BGP router ID.

The router ID is usually the highest IP address on the router or the loopback (virtual) address, but might be implementation-specific.

Bridging (Routers) You will surely encounter Spanning Tree on the switches (and may or may not need to configure it), but don't forget that the routers also can run bridging and Spanning Tree. Although its not common for routers to run bridging, let's say the lab requires that devices on both Fa0/0/0 and Fa0/0/1 of a router share the same subnet. In that case you'd need to enable bridging (and not enable IP routing) on both of those ports on the router, using the +-%'*0/*-"5&$7 interface command.

If you need to enable bridging on a router don't forget that it will run (and interact!) with Spanning Tree with the switches - helping select the root bridge, etc.

Spanning Tree The root bridge is determined by the lowest bridge priority - set on a router by the global F#!=(1 @ "#!$#!&K Q6:E command, where 1 is the number of the bridge-group and 4096 is the configured root priority for that router. The router certainly doesn't have to be the root bridge - one of the switches can be the root.

The path cost is set using the +-%'*0/*-"5&$7$&.,!/(" ,$788 interface command, where 1 is the number of the bridge-group and 100 is the configured cost.

Frame Relay Use caution when bridging via physical Frame Relay interfaces on routers. A physical Frame Relay interface will not forward packets out the same interface upon which they were received, even if the packet is intended for a different DLCI.

For bridging over Frame Relay, there are no special requirements if all interfaces are point-to-point. However for Frame Relay physical interfaces (no subinterfaces) or multipoint interfaces, you need one .#2<1;#1?2K <2"

F#!=(1 %. + F#$2=+24& command for each DLCI that's part of a physical or multipoint interface. However, note that for physical and multipoint interfaces, the router will not forward packets out the same physical or



multipoint interface that bridge packets were received on (regardless of all else, including Spanning Tree)!

In the diagram shown in Figure 4: Bridging Over Frame Relay router1 is not a good choice for the root of the Spanning Tree since if router1 is the root then both Frame Relay DLCIs on its Frame Relay interface will be forwarding bridging packets (because interfaces on the root bridge are never blocking). Yet router1 will not forward packets from router2 to router3 because it is the same physical interface.

A better solution would be to make router3 the root bridge. In this case the Frame Relay connection between router1 and router2 would be blocking - and thus router1 would not be required to forward packets to and from its Frame Relay interface, serial 0. Router3 could forward packets on both serial interfaces since they are separate physical interfaces.

Spanning Tree root bridge

Cannot be router3 Spanning Tree root bridge

S1 router1

Point to Point Frame Serial Connection S0 Relay

S1

router2 S0

Blocked by Spanning Tree

Figure 4: Bridging Over Frame Relay

Control Plane Policing Control Plane Policing (CPP) is nothing more than limiting packets that are destined for the router or switch (as opposed to the packets simply flowing through the router or switch). CPP can help protect the router or switch against DoS and other attacks. CPP can be implemented for Distributed Control Plane Services, but since the equipment in the lab doesn't support



that implementation you should only have to worry about regular CPP (also known as "Aggregate Control Plane Services").

CPP simply implements an existing service policy on packets destined to or coming from the router. So to implement CPP just use:

+$'&#$?;"?2'1 41#>!+1;"$?!+K !'"%& 1!.+ 0,$#")

The policy can be applied in either direction, input (packets addressed to the router) or output (packets sourced from the router). In reality it would be unlikely you'd want to throttle packets coming from the router, but the lab could demand either direction.

The service policy is like any other - with classes and class maps. So if you need to implement CPP in the lab they will likely specify how/what to limit. For example, the lab may require you to not limit SNMP traffic from a particular station (network management, for example) of 192.168.10.10. Telnet from that station should not be limited, nor should it be limited from the 192.168.80.0 subnet (the I.T. Department). All other SNMP and Telnet traffic should be limited to 72 Kb/s each:

!" 2++144;?!4& 1W&1'=1= 4'<" =1'K %=" ,$4& @:NH@EOH@6H@6 2'K 1S 4'<" "1#<!& %=" 2'K 2'K 1S 4'<" L !" 2++144;?!4& 1W&1'=1= &1?'1& =1'K &+" ,$4& @:NH@EOH@6H@6 2'K 1S &1?'1& =1'K &+" @:NH@EOHO6H6 N88HN88HN88H6 2'K 1S &1?'1& "1#<!& &+" 2'K 2'K 1S &1?'1& L +?244;<2" 4'<" <2&+, 2++144;(#$%" '2<1 4'<" +?244;<2" &1?'1& <2&+, 2++144;(#$%" '2<1 &1?'1& L "$?!+K;<2" I[[;!' +?244 4'<" "$?!+1 UN666 +$'.$#< &#2'4<!& 1W+11= =#$" +?244 &1?'1& "$?!+1 UN666 +$'.$#< &#2'4<!& 1W+11= =#$" L +$'&#$?;"?2'1 41#>!+1;"$?!+K !'"%& I[[;!'

show policy-map control-plane [all]

Debug If you need to use =1F%( !" "2+R1& f=1&2!?g f# )22,.+2/g, remember that in some cases (depending on router and IOS version) only packets that are processed switched will get debugged. To disable fast switching (and force process switching) use '$ !" #$%&1;+2+,1 on each interface



(especially the incoming interface for the packets in question). In a lab environment, configuring '$ !" #$%&1;+2+,1 has few negative affects. In a production environment, it will slow throughput since the CPU must process every packet. An example of using an access list to debug traffic between two hosts is shown below. This is helpful if there is a lot of other "stuff" going on that is causing the debug messages to clog up the screen:

#$%&1#D-+$'.!(/0 2++144;?!4& @68 "1#<!& !" ,$4& @UNHD@HNHN ,$4& @UNHD@HN6@H@ #$%&1#D0 =1F%( !" "2+R1& =1&2!? @68

During configuration ctrl-r will refresh the current line if a console or debug message is displayed (for example, if you are in the middle of a long configuration command and a debug message gets displayed, ctrl-r will refresh the line and redisplay the command you are working on).

Here is a sample output of =1F%( !" "2+R1& =1&2!?H I have made every other packet bold to make it easier to read:

1121"2132#452#)6" 178"7171#9:/-%;<"=>#06" 178"71!"7"#9:/-%;<!=># ?6" 178"7@7">#</&#@@>#A'-B;-0# 1121"2132#####CD5#)-+6E8@F">#0)(618>#)/G6831@!"!E1F>#;+H6!>#B%&6@"1$# :IJ# NNJN@JN8J d[J 4h@UNHD@HN6@H@ -)1#!2?6/T =h@UNHD@HNHN -)1#!2?@/T (h@UNHD@HNHNT ?1' QQT .$#*2#= NNJN@JN8J BI[ 4#+hNDT =4&hEDQ:@T 41ShDED6EQQOET 2+RhD8NQ6@6ED6T *!'hQ@NO XIi )jY

1121"21$2#452#)6" 178"7@7"#9:/-%;<!=>#0611@7!7!7"!>#</&#E!>#-+K0#1># L-'('6$$# NNJN@JNOJ d[J 4h@UNHD@HQHD -?$+2?/T =hNNQH6H6H@6 -)1#!2?6/T ?1' E6T 41'=!'( F#$2=7<%?&!+24&T "#$&$hOO

1121"21$2#452#)6" 178"7171#9:/-%;<"=>#06" 178"7178>#</&#@!>#-+K0#!# 1121"21$2#####CD5#)-+6" F>#0)(6""!!1>#)/G61!!@@$ 1F >#;+H6""8$@881$3># B%&6"3!3F#MDN#

From the above output several things can be learned. The first two packets are telnet packets (BI[ =4& 2'= 4#+hND) between 172.31.2.2 and 172.31.201.1. Note that this is the start of a connection (the )jY and XIi

)jY). The "g=" indicates the gateway (next hop address) the router will use to forward the packet.

The next two packets are EIGRP packets (protocol 88) from 172.31.4.1 and 172.31.4.3 to 224.0.0.10 (the EIGRP multicast address). The first packet is a received packet (#+>= N) while the second one is a transmitted packet (41'=!'( F#$2=7<%?&!+24&).

On the last packet you can see the source port (BI[ 4#+h) is TCP 179 - this is BGP. This is a BGP session between 172.31.2.2 and 172.31.2.3.

Distance



Distance is the parameter that Cisco uses to determine what routing source to use for a given network when there is more than one choice. For example, suppose a router learns about 192.168.1.0/24 from RIP and EIGRP.Which one should it use? The answer is the routing source (routing protocol) with the lower distance.

Note that distance is only a factor when identical routes are learned by different means. For example, if 137.17.58.0/24 is learned via OSPF and 137.17.58.0/23 is learned via BGP, both will get placed into the routing table because they are different routes (because of their different subnet masks).

Note that distance takes precedence over any type of routing metric. For example, a router can learn about a RIP route with a metric of 1. It can learn about the same route via EIGRP with a metric of 2,297,856. Yet the router will prefer the EIGRP route (even though it has a much, much higher metric) since the distance of EIGRP is lower than that of RIP.

Distances can be altered, usually with a =!4&2'+1 command within the given routing protocol. Distances can also be set when creating a static route. This is handy when you would prefer to learn about a route via a protocol, but want the static route there in case the protocol-learned route goes away.

The following commands set the administrative distance for EIGRP internal and external routes to 130 and 140, respectively:

#$%&1# 1!(#" @ =!4&2'+1 1!(#" @D6 @Q6

You can also set the distance on routes learned from a specific neighbor. This can be handy if you want to prefer EIGRP routes from a given neighbor. To set the distance of routes learned from neighbor 172.31.3.4 to 80, use:

#$%&1# 1!(#" @ =!4&2'+1 O6 @UNHD@HDHQ

Here are what Cisco uses for distances by default:

· Directly connected 0

· Static route 1

· EIGRP Summary 5

· BGP (eBGP) 20

· EIGRP 90

· IGRP 100

· OSPF 110

· ISIS 115

· RIP 120



· EIGRP External 170

· Internal BGP 200

Distance is contained within each router. That is, routers do not share or advertise distance in any way. For simplicity, each router should be configured with the same distance commands (whenever possible). However in the CCIE lab you may be required to configure distance differently on each router.Whatever the case, distance commands only affect the router to which they are being applied (distance is not passed in routing updates, etc.)

Distribute Lists

* Try adding the word log at the end of an access-list statement to log what is happening with the access list (for example, what packets are being denied). For example, the configuration:

#$%&1# #!" '1&*$#R @UNHD@H6H6 =!4&#!F%&1;?!4& @ !' L 2++144;?!4& @ =1'K @UNHD@H:UH6 6H6H6HN88 ?$( 2++144;?!4& @ "1#<!& 2'K

Produces a message on the console:

8=N6,J k)5I;E;d[XII5))CcM)J ?!4& @ =1'!1= @UNHD@H:UH6 @ "2+R1&

When a RIP update is received for the 172.31.97.0 network (which is denied by the access-list).

Distribute List In Distribute lists "in" block routes from the routing table, but not the OSPF (or other) database. This will block the routes from appearing in that router. However it will not prevent these routes from being passed to other routers via the exchange of the OSPF Link State Database. Thus these "filtered" routes may appear in other routers running OSPF.

Often you may be required to enable a routing protocol on an interface, though you may not want to actually send and receive routes on that interface. For example, refer to Figure 5: Filtering RIP Routes.



Unwanted RIP advertisements

172.16.8.1/24 E0

172.16.1.1/24 172.16.1.2/24

S0 S0

R1 R2 172.16.12.1/24

RIP advertisements

Figure 5: Filtering RIP Routes

Let's assume RIP is required between R1 and R2 (on the 172.16.1.0/24 network). Your RIP config would look something like this:

#$%&1# #!" '1&*$#R @UNH@EH6H6

RIP is enabled on classful networks only (that is, networks with their "natural" class A, class B or class C mask). So if you enter the command '1&*$#R @UNH@EH@H6 under the RIP process, the router will automatically (and sometimes surprisingly!) change it to simply '1&*$#R @UNH@EH6H6. This is because 172.16.1.0 is a subnet, yet 172.16.0.0 is the actual network. This behavior was also true of EIGRP, though with version 12.0(4)T and 12.1 (and later) the subnet mask attribute was introduced, allowing you to enable EIGRP on specific subnets, not just the entire network.

Thus enabling RIP for the S0 interface will also enable RIP on the E0 and E1 interfaces as well. Let's also assume that you don't want to send or receive any routes on the E0 interface. The "244!>1;!'&1#.2+1 56

command will prevent you from sending routing updates on that interface, but you will still receive them. An easy way to block receiving all routes on this interface is to use a distribute list:

#$%&1# #!" '1&*$#R @UNH@EH6H6 "244!>1;!'&1#.2+1 16 =!4&#!F%&1;?!4& @ !' 16 L 2++144;?!4& @ =1'K 2'K

This is completely effective for blocking all incoming updates on the E0 interface. Another problem can occur from this scenario. Since RIP has been enabled on E0, by default that network will be advertised in RIP updates. In a scenario where this may not be desired, see the next section.



Distribute List Out In the network in Figure 5: Filtering RIP Routes, RIP is automatically enabled on S0, E0 and E1 by the '1&*$#R @UNH@EH6H6 command. Let's assume there is a requirement that the only subnet in the 172.16.0.0/16 range that R2 should learn about via RIP is the 172.16.12.0/24 subnet. Distribute List out commands can control this. You can configure your access-list to:

· Block the 172.16.8.0/24 route (and send all others) or

· Permit the 172.16.12.0/24 route (and deny all others by default). The two scenarios are:

#$%&1# #!" '1&*$#R @UNH@EH6H6 =!4&#!F%&1;?!4& N $%& )6

With either this access-list: 2++144;?!4& N =1'K @UNH@EHOH6 2++144;?!4& N "1#<!& 2'K

Or this access-list: 2++144;?!4& N "1#<!& @UNH@EH@NH6

! Note

My general philosophy with filtering (in the CCIE lab) is to only allow those routes you want send. So in the above example I would select the second access-list option. The reason for my choice is this method tends to "block more stuff" than the former option, which blocks one or two specific routes and allows all others. In the lab if a particular route does not appear in a given router, its reasonably easy to trace back through the network and find out where it is blocked - such as by a =!4&#!F%&1;?!4& $%&.

However consider the case where you configure the network using the former option (where you block 172.16.8.0/24 and allow all others). Perhaps several hours later you may choose (or be required) to add a loopback address of 172.16.100.1/24 to R1. Unless you remember to go back and block that network using access-list 2, it will propagate through your network - yet this will break the aforementioned requirement that the only subnet in the 172.16.0.0/16 range that R2 should learn about via RIP is the 172.16.12.0/24 subnet. However you may not even be aware that you've broken this requirement! If you select the second access-list option mentioned, 172.16.100.0/24 will be blocked automatically.

Distribute lists "out" are typically much more effective from blocking a route from a large portion of the network. However with OSPF =!4&#!F%&1;?!4& $%& only works on External Type 1 or 2 routes - not with internal OSPF routes.



Distribution lists may not take effect immediately. You may have to bounce the interface or do a +?12# !" #$%&1 a to activate them.

The =!4&#!F%&1;?!4& .+2/4 $%& 1*! )22 is very tricky. For example:

N86@F-+$'.!(/0 #$%&1# $4". @6D N86@F-+$'.!(;#$%&1#/0=!4&#!F%&1;?!4& @E $%& 1!(#" @

It would appear that this would regulate what ospf sends out to eigrp 1. But instead it controls what OSPF receives in from EIGRP 1 (or, more aptly, what EIGRP sends out to OSPF).

EIGRP By default EIGRP will summarize routes on a classful boundary in a manner similar to RIP. I tend to dislike this behavior and disable this feature with the '$ 2%&$;4%<<2#K. Note that this command only affects how you advertise routes to other routers (i.e., whether or not you summarize on classful boundaries). It does not affect routes that you learn from other routers - you accept them just as they are (either classful summaries or not - depending on whether that router has auto-summary enabled or disabled). Given the choice I configure '$ 2%&$;4%<<2#K on all my EIGRP routers.

For NBMA topologies (Non-broadcast Multi-access, such as Frame Relay, etc.) EIGRP can have split-horizon disabled for spoke-spoke reachability. For IP, use the '$ !" 4"?!&;,$#!e$' 1!(#" @ interface command.

EIGRP Metric When setting the EIGRP metric (via the <1&#!+ keyword during redistribution or via the =1.2%?&;<1&#!+ command) or when examining these metrics in the routing table, there are five attributes that get set (for redistributed routes) or calculated (for regular EIGRP routes):

=1.2%?&;<1&#!+ F2'=*!=&, =1?2K #1?!2F!?!&K ?$2=!'( _Bl

By default reliability does not affect the metric (though this can be changed). The bandwidth is the smallest bandwidth of all links used to reach the destination network. The delay is an accumulation of the delay of all links to reach the destination network. Loading is a rough estimate of the utilization of a given link.

When I needed to set the EIGRP metric I would typically use =1.2%?&; <1&#!+ @666 @6 N88 86 @866. I would use this regardless of the actual speed, loading, etc. of the link. This approximately corresponds to 1 Mb/s of bandwidth, 100 microsecond delay, 100% reliable, 25% loaded with a 1500 byte MTU (packet size).

EIGRP Summarization



EIGRP has the ability to summarize IP routes. Unlike many routing protocols, which perform summarization in the routing process configuration, EIGRP performs summarization at the interface level. The !" 4%<<2#K;2==#144 1!(#" @ @6HN6H6H6 N88HN88H6H6 command can be applied to an interface, such as s0/0.When that configuration is applied, all EIGRP routes that are within the 10.20.0.0/16 range will be summarized to one EIGRP advertisement (10.20.0.0 255.255.0.0) for advertisements out the s0 interface. All other interfaces will not be affected by this summarization (and will advertise EIGRP routes normally).

You will see an EIGRP route to Null0 in the routing table. For the above example, you will see the following (where m indicates EIGRP):

#@04,$ !" #$%&1 1!(#" @6H6H6H67O !4 >2#!2F?K 4%F'1&&1=T D 4%F'1&4T D <24R4 m @6HN6H6H67@E !4 2 4%<<2#KT 66J66J6NT Y%??6 #@0

You can use the !" 4%<<2#K;2==#144 1!(#" @ 6H6H6H6 6H6H6H6

command to summarize and advertise a default route out an interface to other EIGRP neighbors. Since all other EIGRP routes will fall within that range, only the default route will be advertised out that interface. Be careful about using this command if default routes are prohibited in the exam!

You can also use a distance keyword on the !" 4%<<2#K;2==#144

command. By default it uses a distance of 5, which is very preferred. Let's say you want to advertise the 172.19.0.0/16 network out Serial 1/0, but you are also learning that route via EIGRP on interface Eth 0/0. If you use the !" 4%<<2#K;2==#144 1!(#" @ @UNH@:H6H6 N88HN88H6H6 command on interface S1/0, the route to Null0 (with a distance of 5) will be preferred over the same route learned via EIGRP on Eth 0/0 (with a distance of 90). In that case use the command with a distance greater than 90, such as .

!'&1#.2+1 )1#!2? @76 !" 4%<<2#K;2==#144 1!(#" @ @UNH@:H6H6 N88HN88H6H6 @86 L

EIGRP Default Route EIGRP cannot "generate" a default route (as OSPF can, for example, with the =1.2%?&;!'.$#<2&!$' $#!(!'2&1 command). EIGRP can accept and propagate the default route (if it is redistributed from another protocol, etc.) - it just can't generate one when no default route exists.

EIGRP Network Commands Much like RIP, EIGRP will change networks entered into the EIGRP process with the '1&*$#R command unless the subnet mask is included. So the command:



ABCD3INN;@8E-+$'.!(/0#$%&1# 1!(#" @ ABCD3INN;@8E-+$'.!(;#$%&1#/0'1&*$#R @UNH@UH@H6

Becomes: #$%&1# 1!(#" @ '1&*$#R @UNH@UH6H6

However the command:

ABCD3INN;@8E-+$'.!(/0#$%&1# 1!(#" @ ABCD3INN;@8E-+$'.!(;#$%&1#/0'1&*$#R @UNH@OH@H6 6H6H6HN88

Becomes:

#$%&1# 1!(#" @ '1&*$#R @UNH@OH@H6 6H6H6HN88

The difference is significant, as the first command will run EIGRP on all 172.17.0.0 interfaces. The latter command will only run EIGRP on the 172.18.1.0 interface. Needless to say I prefer explicitly indicating the exact interfaces on which EIGRP should run by using the subnet mask. Note that it is a "reverse mask" (which I've never understood why Cisco uses!) like OSPF.

EIGRP Stub Routing EIGRP has the ability to utilize stub routing, much like OSPF. Stub routing provides several benefits:

· It reduces the routing table in the "remote" (stub) router

· It prevents using a dual-homed remote router as a transit network in the event of a link failure between core routers (useful since remotes usually use lower speed links)

· Prevents flapping in the case of a route disappearing, but a remote thinking it is still reachable and advertising it as available

· Reduces filter lists on the "central site" and/or remote routers to filter unwanted networks

The 1!(#" 4&%F router command configures a remote router as a stub. This has several keywords:

1. #1+1!>1;$'?K will prevent the stub router from advertising any routes (so the hub router would need statics or the equivalent). If this keyword is used, none of the other keywords can be used.

2. ?12R;<2" specifies a route map that allows certain EIGRP routes to be advertised (leaked) to the hub

3. +$''1+&1= automatically advertises routes that are connected to the stub router. Network statements for those subnets are still required.



4. 4&2&!+ allows the stub router's static routes to be advertised to the hub. Useful if the stub router has statics to other subnets (which is unlikely in the lab!!)

5. 4%<<2#K will advertise EIGRP summary routes configured with the 4%<<2#K 2==#144 command (or with an automatic summary if the default, 2%&$;4%<<2#K is enabled) - though I usually configure '$ 2%&$;4%<<2#K

6. #1=!4&#!F%&1= advertises to the hub any routes that are redistributed into EIGRP on the stub router

FirewallsIOS Firewall (CBAC)

The "Classic" IOS firewall is also known as Context Based Access Control (CBAC).

The !" !'4"1+& '2<1 commands instruct the router to inspect those protocols on the interface specified. The return traffic for those sessions is automatically permitted (even though it will arrive on a different interface and even though that interface likely already has an ACL applied to it that would otherwise block the return traffic - such as ACL 100 on s0/0, below). All traffic specified by the !" !'4"1+& commands will be controlled by CBAC. Any traffic not specified by those commands will be treated by the remainder of the router config - which is why ACL 100 (below) is required to block all other traffic. ACL 100 needs to be an extended access list for CBAC to operate properly. ACL 100 should "block" the CBAC return traffic (i.e., with the =1'K 2'K 2'K at the end) since CBAC will automatically allow the return traffic.

!" !'4"1+& '2<1 <K.!#1*2?? .&" !" !'4"1+& '2<1 <K.!#1*2?? &+" L !'&1#.2+1 5&,1#'1& 676 -!'4!=1 !'&1#.2+1/ !" !'4"1+& <K.!#1*2?? !' L !'&1#.2+1 41#!2? 676 -$%&4!=1 !'&1#.2+1/ !" 2++144;(#$%" @66 !' L 2++144;?!4& @66 =1'K !" 2'K 2'K

CBAC will only inspect packets that pass both the inbound ACL on the input interface (if any) as well as the outbound ACL on the output interface (if any). That is, the traffic can't be blocked at either the in or out interface - if they are CBAC will ignore the packets.

Beyond just TCP and UDP, CBAC can inspect certain protocols (as they typically create more complex sessions and its important the firewall understand them), such as FTP, SMTP, TFTP, H.323, SQL Net, etc.



You'll notice the example (above) traffic is inspected inbound on the "internal" interface. In some cases you may have several internal interfaces (Fa0/0, Fa0/1, Fa1/0) and one "external" interface (serial 2/0). In this case traffic leaving serial 2/0 is inspected, with the return traffic allowed into the same interface. Here ACL 150 always allows traffic into a web server on Fa0/1 (10.20.30.250), but all other TCP traffic is only allowed in if the session was started on an internal interface (and used serial 2/0 as the external interface). Traffic running between the Ethernet interfaces is not inspected or restricted. All non-TCP traffic is denied into serial 2/0. A record (audit trail) of all network access will be sent to whatever server is configured with the ?$((!'( 2)*-)* command.

!" !'4"1+& '2<1 .!#1*2??;@ &+" !" !'4"1+& 2%=!&;&#2!? L !'&1#.2+1 324&5&,1#'1& 676 -!'4!=1 !'&1#.2+1/ !" 2==#144 @6HE6HE6H@ N88HN88HN88H6 L !'&1#.2+1 324&5&,1#'1& 67@ -!'4!=1 !'&1#.2+1/ !" 2==#144 @6HN6HD6H@ N88HN88HN88H6 L !'&1#.2+1 324&5&,1#'1& @76 -!'4!=1 !'&1#.2+1/ !" 2==#144 @6HU6HU6H@ N88HN88HN88H6 L !'&1#.2+1 41#!2? N76 -$%&4!=1 !'&1#.2+1/ !" !'4"1+& .!#1*2??;@ $%& !" 2++144;(#$%" @86 !' L 2++144;?!4& @86 "1#<!& &+" 2'K ,$4& @6HN6HD6HN86 1S *1F 2++144;?!4& @86 =1'K !" 2'K 2'K

CBAC does not inspect any ICMP traffic, so if this traffic should be allowed it must specifically be listed as permitted in the ACL on the external interface.

CBAC has many global timers and thresholds (tcp synwait, tcp finwait, tcp idel-time, udp idle-time, etc., etc.) These all have default values, however you should familiarize yourself with them in the event the lab requires you to change the defaults.

Zone-Based Firewall The Cisco Zone-Based Firewall (ZFW) is similar to the "Classic" Firewall (CBAC), but with significant improvements. Traffic can flow freely among interfaces in the same zone, but traffic between zones is automatically denied unless explicitly permitted by the policy - an ACL to deny traffic is not required (as with CBAC). Zones are created first with the e$'1 41+%#!&K 5!$),$#") command, then applied to interfaces using the e$'1; <1<F1# 41+%#!&K 5!$)6$#") interface command. Policies are created with a format similar to class-maps. Interfaces not configured with any zones are treated like "normal" routing ports and are not subject to the ZFW.



The +?244;<2" &K"1 !'4"1+& f<2&+,;2'K \ <2&+,;2??g .#22,"#1,$#")

command creates a class-map and enters class-map configuration mode. Each class-map must use either the <2&+,;2'K or <2&+,;2?? keyword. Class-maps can <2&+, on access-groups, protocols or other class-maps. If applications are specified in match criteria (such as protocols FTP, SIP, Skinny (SCCP), H.323, TFTP, etc.) they need to be listed above a generic <2&+, "#$&$+$? &+" or <2&+, "#$&$+$? %=" statement, since they are more specific.

Once class-maps identify certain types of traffic, policy-maps determine whether the firewall will inspect the traffic, pass the traffic or drop the traffic. Inspect will maintain session information and allow return traffic. Pass will simply pass the traffic identified by the class-map, but will not inspect the traffic. Drop is the default, but may be required for specific traffic (such as if a policy-map is to drop telnet traffic, but inspect all other TCP traffic, for example). The "$?!+K;<2" &K"1 !'4"1+& 1!.+ 0,"#1,$#")

command creates the policy and enters policy-configuration mode. Classes (previously configured with the +?244;<2" &K"1 !'4"1+& .#22,

"#1,$#") command) can then be configured for the inspect, pass or drop action.

Parameter-maps are optional and used by ZFW to set thresholds for timers, TCP and UDP settings and application specific settings (HTTP objects, POP3 and Instant Messaging settings). The "2#2<1&1#;<2" &K"1

!'4"1+& 1#*#")/)*,"#1,$#") command creates a parameter map and enters parameter-map configuration mode. Parametermaps can be applied to particular classes within a policy-map by adding it after the !'4"1+& command:

"2#2<1&1#;<2" &K"1 !'4"1+& <K;"2#2<1&1#;<2" -"2#2<1&1#;<2" +$'.!(%#2&!$' ,1#1/ L "$?!+K;<2" &K"1 !'4"1+& <K;1W2<"?1;"$?!+K +?244 &K"1 !'4"1+& d'&1#'1&;&#2..!+ !'4"1+& <K;"2#2<1&1#;<2"

Finally, the policy map is activated by the e$'1;"2!# 41+%#!&K 5!$),1#+*, $#") 4$%#+1 2!'* ),5!$),$#")&=14&!'2&!$' %)2/+$#/+!$,5!$),$#")

command and enters zone-pair configuration mode, where the 41#>!+1;

"$?!+K &K"1 !'4"1+& 1!.+ 0,"#1,$#") command applies the policy-map between the source and destination zones. For the e$'1;"2!#;'2<1, I recommend using the source zone followed by a hyphen, followed by the destination zone. So you would have a command such as e$'1;"2!#

41+%#!&K $%&4!=1;!'4!=1 4$%#+1 $%&4!=1&=14&!'2&!$' !'4!=1H The keyword 41?. can be substituted for either the source or destination zone for traffic to or from the router. See page 157 for an example of zone based firewall configuration.



Frame Relay Frame Relay traffic shaping always requires a .#2<1;#1?2K !'&1#.2+1;

=?+! command since this is where you configure the traffic shaping commands.

In Frame Relay you may want to place a map statement for your own (local) IP address so that you can ping it (or ask the proctor if this is necessary).

Interfaces and Sub-Interfaces Frame Relay PVCs can connect to a router's physical interface, a point-to- point subinterface or a multipoint subinterface. Each has its own issues and problems as discussed in Table 2: Frame Relay Interface Types and Issues, below.

By default all DLCI's that are announced to a router are placed in that router's physical interface. DLCI's can be assigned to an interface via the .#2<1;#1?2K !'&1#.2+1;=?+! command (preferred) or by applying a .#2<1;#1?2K <2" statement to a subinterface that references that DLCI. Due to their nature point-to-point subinterfaces can only receive one DLCI. Multipoint subinterfaces (and physical interfaces) can receive many DLCIs.

Point-to-point subinterfaces are by far the simplest. Each one is a unique IP subnet. They appear to the router as a direct link (like a physical point- to-point link, a T1 running PPP or HDLC, for example) so there are few issues with reachability, mapping, inverse arp, split horizon, etc. Because they are so easy to deal with don't expect to see a lot of these on the lab exam!

It is possible to mix interfaces on a router (have a router connecting to a Frame Relay cloud where the router uses a combination of physical, multipoint and point-to-point subinterfaces. Although this is unusual you should practice this at least a few times!

PVC Status If you see a PVC with the status of "deleted," it probably means you typed in a .#2<1;#1?2K !'&1#.2+1;=?+! @66 command, but the frame switch is not announcing (and doesn't know about) that DLCI - check DLCI.

If you see a PVC with the status of "inactive," it probably means the local router's connection to the frame switch is fine, but there is a problem with the 'far' end of the PVC. Check the router that is supposed to terminate the PVC.

Inverse Arp and Mapping



Frame Relay needs a way to connect, or map, a Layer 3 address (IP address) with a particular Frame Relay DLCI. That is, when a router attempts to forward packets to an IP address it needs to know out which virtual circuit - specified by a Frame Relay DLCI - the packet should be forwarded.

In some cases (such as where two routers are connected by a single virtual circuit, i.e., a single DLCI) the routers can use inverse-arp to determine the Layer 3 (IP) address at the opposite end of the virtual circuit. However in other cases, such as two "spoke" Frame Relay sites connected by one "hub" Frame Relay site, the two spokes can not use inverse-arp to learn each other's Layer 3 addresses. This is because inverse-arp packets are never forwarded (in this example, they are not forwarded by the "hub" router).

In these cases it is common to manually map (define) each Layer 3 address the router may need to reach to a specific DLCI (virtual circuit). Note that this applies only to physical and multipoint Frame Relay interfaces. Using point-to-point sub-interfaces is an easy way to avoid doing this because a point-to-point interface can only support a single DLCI (so there is no confusion about "which" DLCI to use to reach a remote host), but when does the CCIE exam ever take the easy way?

Also, if you perform mapping on a router, it is best to create a map for every other router in the Frame cloud, including the hub router. Even if connectivity exists between that router and the hub router, if you are mapping other remote routers make a habit of mapping the hub router as well. In some versions of IOS inverse-arp is disabled once a Frame Relay (manual) mapping occurs, however the problem this poses is often not apparent until the router is rebooted (which clears the mappings dynamically learned using inverse-arp).

The way this can occur is as follows: suppose router A is a "spoke" router connecting to router B. Router C is also a spoke router that connects to router B. Router A uses inverse-arp to map router B's IP address to a particular DLCI. However router A can not inverse-arp for router C's IP address as discussed. A map statement is placed in router A for router C. Everything works great since router A has the two mappings it needs: a dynamically learned one for router B (via inverse-arp) and a manually defined one (via a map statement) for router C.

However with some versions of code the map statement disables inverse- arp. Thus once the router is rebooted is loses its dynamically learned mapping for router B. Since the map statement has disabled inverse-arp, connectivity to router B is lost. Thus, to be safe if you are performing map statements add one for each router in the Frame cloud.



Table 2: Frame Relay Interface Types and Issues shows the various combination of Frame Relay interface types that can exist at the "hub" router and at the "spoke" routers. Each combination has potential problems and issues, as are outlined in the table.



Table 2: Frame Relay Interface Types and Issues

Central Site Frame Relay Remote Site Frame Relay router router Interface Issues Interface Issues No May need to disable IP split No subinterfaces Need a frame-relay map statement subinterfaces horizon. for all neighbors. Need ip ospf

priority 0 on all remotes. Need to enable IP split horizon.

No OSPF network type mismatch Point-Point Need frame-relay interface-dlci subinterfaces - probably have to use ip ospf subinterfaces command. OSPF network type network point-to-multipoint to mismatch - probably have to use ip make it work. May need to ospf network point-to-multipoint to disable IP split horizon. make it work.

No Multipoint Need frame-relay interface-dlci subinterfaces Very unlikely configuration. subinterfaces command. Need either:

May need to disable IP split · On remotes: a frame-relay map horizon. statement for all neighbors

and ip ospf priority 0, or · ip ospf network point-to- multipoint everywhere.

Point-Point Need frame-relay interface-dlci No subinterfaces OSPF network type mismatch - set subinterfaces command. OSPF network type remotes to ip ospf network point-to- mismatch. point. Remotes will be on different

subnets. Need to enable IP split horizon.

Point-Point Need frame-relay interface-dlci Point-Point Need frame-relay interface-dlci subinterfaces command. subinterfaces command. Point-Point Need frame-relay interface-dlci Multipoint Need frame-relay interface-dlci subinterfaces command. OSPF network type subinterfaces command. OSPF network type

mismatch. mismatch - set remotes to ip ospf Very unlikely configuration. network point-to-point.

Multipoint Need frame-relay interface-dlci No subinterfaces Need a frame-relay map statement subinterfaces command. Need to disable IP for all neighbors. Need ip ospf split horizon. priority 0 on all remotes. On 11.3

and lower, need ip ospf network point-to-multipoint or statically defined OSPF neighbors. Need to enable IP split horizon.

Multipoint Need frame-relay interface-dlci Point-Point Need frame-relay interface-dlci subinterfaces command. OSPF network type subinterfaces command. OSPF network type mismatch - probably have to mismatch - probably have to use ip use ip ospf network point-to- ospf network point-to-multipoint to multipoint to make it work. make it work. Need to disable IP split horizon.

Multipoint Need frame-relay interface-dlci Multipoint Need frame-relay interface-dlci subinterfaces command. Need to disable IP subinterfaces command. Need either: split horizon. · On remotes: a frame-relay map

statement for all neighbors Very unlikely configuration. and ip ospf priority 0, or

· ip ospf network point-to- multipoint everywhere.

· When configuring your .#2<1;#1?2K <2" statements, don't forget the F#$2=+24& at the end! This allows broadcast and multicast packets to traverse the link (important).

OSPF



A Frame Relay interface (not a subinterface) defaults to OSPF network type of nonbroadcast (NBMA). If using this default non-broadcast network type, be sure to set !" $4". "#!$#!&K 6 on all remotes (because you want the hub router to be the designated router).

A Frame Relay point-to-point subinterface defaults to OSPF network type of point_to_point.

A Frame Relay multipoint subinterface defaults to OSPF network type of nonbroadcast (NBMA).

If you use point-to-point subinterfaces at one end of a PVC and no subinterfaces at the end, you must account for the type mismatch. For example, use !" $4". '1&*$#R "$!'&;&$;"$!'& at the end not using subinterfaces. If you use a combination of physical and multipoint subinterfaces, use !" $4". '1&*$#R "$!'&;&$;<%?&!"$!'&H

Gateway Load Balancing Protocol (GLBP) GLBP provides default gateway redundancy for hosts and end-stations, much like HSRP and VRRP. However GLBP provides the benefit of having more than one router be actively forwarding packets (acting as the default gateway) without the need for multiple HSRP or VRRP groups - which also requires different hosts be configured with different default gateway IP addresses. More than one GLBP router can share the same default gateway IP address, yet all be forwarding packets.

Members of a GLBP group agree on a single active virtual gateway (AVG) with the (?F" "#!$#!&K command. Other routers become back-up AVG's, providing redundancy. The active AVG router assigns different virtual MAC addresses to each member of the GLBP group. It also answers ARP requests from hosts and end-stations. By responding to different ARP requests with different virtual MAC addresses, the active AVG can distribute the forwarding load among two or even many GLBP routers, also known as active virtual forwarders (AVFs). If an AVF fails, other members of the group take over, responding to its virtual MAC address as well as their own - so there is no significant downtime for the end-station.

As you can see, GLBP is a perfect choice if the lab requires a redundant default gateway solution with more than one router forwarding packets off the subnet (and it's the only solution if they restrict the number of virtual groups to one or only allow a single default gateway IP address)!

The AVG tracks which end-stations ARP for the default gateway, and which virtual MAC was assigned to them. These are help on the AVG (only) in a cache. By default the cache can hold 2000 entries per GLBP group. The (?F" +?!1'&;+2+,1 <2W!<%< command can raise (for more



than 2000 end-stations) or lower (to conserve memory) this default. The 4,$* (?F" =1&2!? command executed on the AVG will display this cache.

Not surprisingly, GLBP commands are quite similar to HSRP and VRRP commands. To enable GLBP on Fa0/0 using group 3 and 10.76.32.1 as the default gateway address and a priority of 105 (default is 100) with an authentication secret of "NEpatriots":

!'&1#.2+1 32676 !" 2==#144 @6HUEHDNHN N88HN88HN88H6 (?F" D !" @6HUEHDNH@ (?F" D "#!$#!&K @68 (?F" D "#11<"& (?F" D 2%&,1'&!+2&!$' &1W& Y5"2&#!$&4

GLBP has hello and hold timers just like HSRP and VRRP ((?F" 7*!'1

&!<1#4, with defaults of 3 and 10 seconds for hello and hold) to assure a GLBP router is still alive, but GLBP also introduces redirect timers ((?F"

7*!'1&&!<1#4 #1=!#1+&). This is the time during which the AVG will still answer ARP messages with a router's assigned virtual MAC address. This timer tends to be much larger (in hours), since the virtual MAC may still be handed out even if the assigned router has failed, because other group members will respond to it very quickly should the router fail.

Plain text authentication (shown above) is the simplest. As such I highly recommend using it if authentication is required but no other requirements are specified. The other authentication choices are MD5 with key strings or MD5 with key chains. All routers in a GLBP group must use the exact same form of authentication.

MD5 key strings are fairly simple - each router must use the same string, which is then encrypted using an MD5 hash. The (?F" 7*!'1,$'"()*&

2%&,1'&!+2&!$' <=8 R1K;4&#!'( f6 \ Ug 1#223!*%&command applies 1#223!*%&as the key, with 0 indicating the 1#223!*%&entered is not yet encrypted, and 7 indicating the 1#223!*%&is already encrypted. MD5 key chains are more complicated and require the definition of a key chain. Here a key chain with the name =$'%&4 and password (R1K;4&#!'() of cupcakes is applied to a router using GLBP group 8. The name links the key definition to the GLBP interface authentication: R1K +,2!' =$'%&4 R1K @ R1K;4&#!'( +%"+2R14 L !'&1#.2+1 324&5&,1#'1&676 !" 2==#144 @UNH@EH6H@ N88HN88HN88H6 (?F" O 2%&,1'&!+2&!$' <=8 R1K;+,2!' =$'%&4 (?F" O !" @UNH@EH6H8



Unlike HSRP and VRRP, GLBP has built-in load balancing (in fact, it is the appeal of GLBP). The (?F" 7*!'1&?$2=;F2?2'+!'( command has three possible arguments:

· host-dependent - a particular end-station (MAC address) is always assigned the same virtual default gateway. This is useful if the end- station needs the same MAC address tied to the default gateway IP address, for example.

· round-robin (default) - each GLBP router is handed out as the default gateway equally

· weighted - each virtual GLBP router can be weighted to accept more or fewer end-stations, specified with the (?F" 7*!'1& *1!(,&!'( command.

The (?F" 7*!'1 *1!(,&!'( 3)+78/ command specifies the weight of each GLBP member. The (?F" 7*!'1 *1!(,&!'( &#2+R !(9) /,$'"()*

command simply identifies that some object with the !(9) /,$'"()* number will be tracked, and optionally a decrement value for the weight can be added to this command (default is 10). The &#2+R !(9) /,$'"()*&

!'&1#.2+1 +$/)*:# ) global command is still required to identify the actual object (interface) to be tracked, which must include either ?!'1;"#$&$+$?

or !" #$%&!'(. The former simply looks at whether the specified interface is up or down, the latter goes further to see if the interface is up, has an IP address configured and has IP routing enabled. Optionally, the (?F" 7*!'1

*1!(,&!'( 3)+78/ command can have an upper and lower weight assigned. If tracking drops a router's weight below the ?$*1# weight value it will give up its role as a forwarder (and another router will take over). If the weight (reduced by tracking) rises back up above the %""1# weight value (even if it is not back up to its full weight - as may be possible if multiple interfaces are being tracked), it will resume its forwarding.

show glbp [interface-type interface-number] [group] [state] [brief] debug glbp errors debug glbp events debug glbp packets

Home Lab During your CCIE preparation you will need to decide whether to purchase a home lab. I highly recommend purchasing one. Unless you have access to a lab (at work, etc.) a home lab is invaluable. Not only can you work on it anytime it is convenient, you can also continue to build on configurations over several days (unlike labs where you rent rack time or equipment).

Now that used 2500's on eBay are under $200, a small home lab can be assembled at a reasonable price. At the very least I recommend purchasing some 2500's since they are extremely cheap and you can practice a fairly wide range of networking topics on these devices (OSPF,



BGP, EIGRP, access-lists, etc., etc.) Even if you are investing in a fairly complete lab, I still recommend getting a few 2500's.

A home lab is a significant investment, though when I sold my lab after one year I recovered all the money I had invested in it. Keep in mind that "older" technology will drop in price more quickly than newer technology.

Home Lab Considerations If you do decide to build a home lab, consider the following:

· Try to get at least 16 MB of RAM and at least 16 MB of flash on all routers (if not more). Memory and flash upgrades can easily be purchased on ebay, though you should plan on these costs when initially buying. Extra memory is useful for running compressed images (see "IOS For Your Home Lab" below).

· For most 12.1 and above images you will need at least 16 MB of flash. Although 16 MB of flash is less commonly found on 2500 series routers, you could buy a second 8 MB flash SIMM, insert it in the 2500 and have 16 MB of flash. Use the "2#&!&!$' .?24, @ @E

command to make the whole 16 MB usable for a single image (instead of two separate 8 MB partitions).

· The CCIE exam includes the 3560 layer 3 switch. These are typically expensive, though they will also probably retain their value for some time. If you can afford to purchase one it will be an advantage in your studies. If not, you should consider alternatives, such as renting rack time that includes the 3560.

· I used all 2500 routers, strictly for cost considerations. The 2500's allow you to practice most configurations and all of the "core" configurations. They do not allow you to practice some configurations (Ethernet trunking, etc.). For these technologies I rented rack time or used equipment at my local Cisco sales office.

· Make sure you purchase at least one "frame switch" router. This is a router with 4 or more serial lines that can act as a Frame Relay switch. You can use a 2520, 2521, 2522, 2523, an old AGS+, etc.

· Make sure you purchase a terminal server (2509, 2510, 2511, 2512, etc. are common). It is important that you become fluent accessing your routers via their console ports through the terminal server. If you are looking to save money you may be able to purchase a Token Ring terminal server, then connect it to the network via another router that has both Token Ring and either an Ethernet or a serial connection.

· Purchase your routers on eBay. You can find out about a seller (based on their rating) and there is an ample supply (which also usually dictates reasonable pricing).Watch a few auctions of routers you are interested in to determine the market value.

IOS For Your Home Lab If you have a home lab you'll need to select an IOS to use for each router.



For routers that have a limited flash, you can consider TFTP'ing the image from a TFTP server on boot-up. This allows you to run an image that is larger than the router's flash (because the TFTP'd image runs in memory). I recommend storing a smaller image in flash in case the TFTP fails. For example, I have a 1721 router in my home lab that has 96 MB of memory but only 16 MB of flash. My boot config is:

F$$&;4&2#&;<2#R1# F$$& 4K4&1< &.&" +@U66;2=>1'&1#"#!41R:;<eH@NQ;N8FHF!' @:NH@EOHN66HN F$$& 4K4&1< .?24, .?24,J+@U66;1'&F241R:;<eH@NQ;@8HB@@HF!' F$$&;1'=;<2#R1#

The router cleanly boots from my TFTP server (192.168.200.2) the Advanced Enterprise Services image of 12.4(25b), which is over 21 Mb.

Another alternative for limited flash is to used a compressed image. Cisco doesn't recommend this on production routers, though in a lab environment it works great. You do need a decent amount of memory (almost all my 2500's had 16 MB) but compressing an image let's you place a 10 or 11 MB image in an 8 MB flash. You can also compress a larger image so that it will fit into 16 MB of flash.

You can compress the image with any "standard" UNIX compress utility. The router will decompress the image on boot-up (it takes a few minutes longer to boot), then it runs the image from memory. Once the router is booted you can't tell that the image on flash was compressed.

For example, on some of my 2500 routers I only had 8 MB of flash. On these routers I ran c2500-jos56i-l.120-14.bin.Z. The "Z" at the end indicates it is compressed. Although this image is normally over 11 MB, compressed it was only 7.4 MB and fit easily into my 8 MB of flash. Although this is definitely an older image, it contains the Enterprise Plus with Firewall and IPSec software, so I could configure most of the features the 2500 supports. I was only missing a couple of the latest features and commands. I practiced those on some of my other routers.

Remember that if you are limited in flash you don't necessarily need every feature on every router. For example, you might want IPSec on certain routers, firewall features on other routers, etc.

If you decide to use 2500 routers in your lab (they are cheap!) I recommend c2500-is-l.122-15.T14.bin. This provides the "IP Plus" feature set on a very stable version of 12.2. The T14 'train' contains IPv6.

For a good, general image consider c2500-jos56i-l.121-26.bin for an image. The "jos56i" is the feature set. This represents Enterprise Plus



along with Firewall and IPSec software. Even though this is 12.1, this allowed me to configure IPSec, Firewall features and IP Plus features.

Choosing a Terminal Emulator My strategy for terminal emulators was to use my favorite one to prepare for my lab exam, then switch to Hyperterminal 2-3 weeks before the exam just to get used to the "look and feel" of Hyperterminal (which is the default emulator forWindows).

I selected Tera Term (also known as Tera Term Pro) for my terminal emulator of choice. I recommend Tera Term as it can make your life easier. The biggest advantage of Tera Term - other than good logging capability - for me was:

Tera Term uses a very simple macro language.With this you can very easily program Tera Term to execute commands on your routers. I have included two such useful Macros in Appendix A: Tera Term Macro.

For example:

I used a Tera Term macro to automatically prompt me for a filename. Once I entered it, Tera Term would go to each router and log its current config and IP routing table, then store all these configs and routing tables in a pre-determined directory using the filename I specified when it prompted me.

I found this extremely useful since it would very quickly "capture" the configs and IP routing tables (and any other info you desire - OSPF neighbors, IPSec associations, etc.) for a given scenario with virtually no effort. During my studying I was forever reviewing scenarios I had already staged in my lab. This made a very easy way to document all my work for later review.

This macro is included in "Appendix A: Tera Term Macro" for your reference. I have included my comments to attempt to explain what the macro is doing.

You could easily write a macro for other purposes, such as write-erasing your routers when changing from one lab scenario to another. Tera Term is freeware and can be found with a quick Google search.

Accessing Your Lab From the Internet When I was studying for the lab exam I created a network that allowed me to connect to all my routers from anywhere on the Internet. I found this to be handy since if I was at work (or anywhere with Internet connectivity) and had a few free minutes, such as during lunch, after work, etc., I could



quickly log on and begin studying. This could also allow you to share your equipment with a study partner.

I have a cable modem connection at home. I purchased a broadband router/firewall to both increase my network security and to allow several devices - such as my own laptop and my routers - to access the Internet simultaneously. I have been extremely pleased with my SMC Barricade. Here are a few broadband router/firewalls, all under $100:

Vendor Product SMC Barricade Linksys EtherFast Cable/DSL Firewall Router D-Link 4 Port Broadband Gateway Netgear Internet Gateway Router

Here is the configuration I used for my home lab:

Cable Modem,DSL router, Internet or other broadband

Internet access device

� accept DHCP address from Internet

192.168.123.254/24 � NAT telnet connections to 192.168.123.10

10 Mb/s Ethernet

192.168.123.10/24 2509, 2511 or similar terminal server router

async async

connection to connection to

the console the console

async connection to router1 router2 the console

router3

Figure 6: Home Lab with Internet Connectivity

Automatically Logging in to All Routers



I always felt that to have to create a connection to every router in my lab was a tedious chore I hoped to automate. As I discuss in other sections of this guide I used Tera Term as my terminal emulator. Using this program I created a macro (a script) to log into all my routers. Here are my router configs: Terminal Server router:

!'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @H@H@H@ N88HN88HN88HN88 !" ,$4& #$%&1#@ @H@H@H@ N66@ !" ,$4& #$%&1#N @H@H@H@ N66N !" ,$4& #$%&1#D @H@H@H@ N66D

In each router: ?!'1 +$' 6 "#!>!?1(1 ?1>1? @8 '$ ?$(!' ?!'1 >&K 6 Q "#!>!?1(1 ?1>1? @8 '$ ?$(!'

Once you are logged into your terminal server router (in enable mode), you simply invoke the script (via the Controlà Macro menu selection in Tera Term). Here is the script:

!"#$% &'&()*& & +#,-&./$% #/(.& +#,-0,&1(2& 34! &.1.& & +#,-0,&12*1567& 34! &.1.& +#,-&./$% #/).& +#,-0,&1(2& 34! &.1.& & !"#$"%&'(&)*+% ,-./%0&0% !"#%0123/!1'0% !"#$"%&4'% ,-./%0&0% & +#,-0,&12*1567& 34! &.1.& +#,-&.38#/#.& +#,-&1(2&

Simply save this as a text file, then select that file when you invoke the Tera Term script (Controlà Macro). You can use other names for your routers (such as r1, r2, etc.) Just simply change the config of the terminal



server router (such as !" ,$4& #@ @H@H@H@ N66@) and update the names in the script above.

You can repeat the portion of the script in bold for each of your routers (or other devices). The '+#,-0,&12*1567' sends the terminal server a Ctrl- Shift-6 X to escape back to the terminal server.

If you need to use telnet and enable passwords on your routers, simply replace the bold portion of the script with:

+#,-0,&12*1567& 34! &.1.& +#,-&./$% #/2.& +#,-0,&1(2& 34! &.94++3$/-:.& +#,-0,&.0%;<.& 34! &.=.& +#,-0,&.#,.& 34! &.94++3$/-:.& +#,-0,&.0%;<.& +#,-0,&1(2& +#,-0,&1(2& 34! &>1?&

Don't feel you need to use 'lucy' as your password. You can use the name of your own cat!

IKE IKE is the Internet Key Exchange standard and is usually performed using the ISAKMP protocol. IKE is often used with IPSec because it automates key management and controls the security associations that are formed, though IKE is not required for IPSec. IKE policies define five things:

· encryption algorithm (such as des) · hash algorithm (such as sha or md5) · authentication method (such as rsa-sig, rsa-encr or pre-share) · Diffe-Hellman group (such as group-1 (768-bit) or group-2 (1024 bit))

· security association lifetime (in seconds) All of these have defaults (and the defaults can be used) except authentication - that must be specified. Pre-share is by far the easiest authentication method - it simply requires one command defining the same text key at each peer. Thus this is my recommendation (assuming this is allowed on the exam). Rsa-sig authentication requires a certificate authority (and thus is very unlikely to be on the CCIE Lab). These parameters affect the data that flows between hosts during the IKE negotiation - not the actual data flows. Encryption and authentication of data flows are defined by the transform set in IPSec (step 3, below).



Intrusion Prevention System (IPS) - IOS Cisco's IOS IPS helps protect networks against threats and attacks. The IOS IPS monitors packets flowing through the router. As such, on the interfaces that will be configured for IPS you must decide if the IPS router will act as a normal router (routing packets) or if it will transparently bridge packets - both options are supported. If the bridging option is used in the lab, it will most likely bridge across 2 or more interfaces, then use a Layer 3 Bridged Virtual Interface (BVI) will be used to route the packets to and from all other (normally routed) interfaces.

The global command !" !"4 '2<1 +12,$#") enables the IPS and may apply an ACL using the keyword ?!4& # .. The !" !"4 +12,$#") n!' \

$%&o interface command determines which interfaces will participate in the IPS.

The signature definition file (SDF) defines all the attack signatures that the IPS will watch for and defend against. The !" !"4 4=. ?$+2&!$'

.?24,J@NO_GH4=. command tells the router where it can locate its SDF file. The lab will provide you with an SDF file, but it may need to be moved onto the router. In the above command it is pointing to the flash, though it can use any storage device as well as protocols such as FTP, HTTP, HTTPS, RTP, SCP, and TFTP.

To configure a router with the bridging option, use a configuration similar to the following:

!" !"4 '2<1 =1.1'=1#;!"4 F#!=(1 @ "#$&$+$? !111 L !'&1#.2+1 M!( 676 F#!=(1;(#$%" @ L !'&1#.2+1 32 N7676 F#!=(1;(#$%" @ L F#!=(1 !#F F#!=(1 @ #$%&1 !" L !'&1#.2+1 GPd@ !" 2==#144 @6HN6HD6HQ6 N88HN88HN88H6 !" !"4 =1.1'=1#;!"4 !'

IPSec To configure IPSec:

· Determine whether to use ISAKMP (recommended) or manual config for security associations

· Configure ISAKMP (recommended) or manual IPSec Then:



1. Define the ISAKMP policy (only if using ISAKMP) 2. Define the keys (pre-shared, RSA, etc. - pre-shared is recommended)

3. Define a transform set (security configuration) 4. Define an access list to determine what traffic will be sent via IPSec 5. Create crypto map entries 6. Apply the crypto map to an interface

The ISAKMP policy (encryption, authentication, length of association, etc.) applies to the exchange of keys - not to the actual data that gets passed between routers. This policy defines the security used by the routers to exchange keys.

The transform set defines the security (encryption, hash algorithm, etc.) used for the actual data that is passed between the routers. The transform set defines the security, then the crypto map defines the peer, the access list (which defines what traffic is sent into the IPSec tunnel) and the transform set that is used between the router and that peer. You can have more than one transform set. Different transform sets can be applied to different peers.

Finally the crypto map gets applied to the interface used to communicate between IPSec peers.

It appears IPSec likes to have the crypto map applied to the "outer most" interface. In the past I have applied the +#K"&$ <2" statement to the LAN (inside) interfaces and had no success. (I recommend applying the crypto maps to the outer-most interface even if the routers are IPSec peering between loopbacks).

Access lists For ipsec-manual mode (not using IKE/ISAKMP), only 1 access list entry is permitted; all others are ignored.

Always make access lists mirror images of each other at opposite ends!

Don't use the 2'K keyword in your access lists.

IPSec through a Tunnel Interface For running IPSec through a tunnel, first define the tunnel between the two physical interfaces on each router. Once the tunnel is working, define the IPSec peers between loopback interfaces. To do this you will need the +#K"&$ <2" <K<2" ?$+2?;2==#144 ?$$"F2+R 6 command (to set the peer's local IPSec peer address).



You will need some routing so that each router knows of the other's loopback address - static routing, a routing protocol through the tunnel, etc.

Enable the crypto map on both the physical interface and the tunnel interface.

IPSec Example For an example of implementing IPSec, consider the network in Figure 7: IPSec Using Multiple Tunnels. As you can see, r4 has two different IPSec associations: one with r1 and another with r2. For this example we will use IKE/ISAKMP for key management (my preferred solution).We will force traffic from the 10.0.0.0/8 network through the IPSec tunnels and we will ping between loopbacks.

loopback 150 All intefaces in OSPF loopback 150 r1 ip address 10.1.1.1/24 area 0 ip address 10.4.4.4/24

r4

Logical IPSec connection

192.168.123.51/24 eth 0 eth 0 172.26.77.4/24

192.168.123.0/24 172.26.77.0/24

eth 0 eth 0

r2 s 0 s 0

loopback 150 172.25.33.2 172.25.33.3 r3 ip address 10.2.2.2/24

Figure 7: IPSec Using Multiple Tunnels

We will use OSPF to route between the loopback interfaces and the physical interfaces - the serial and Ethernet interfaces. Even though the traffic on the 10.0.0.0 network is going through the IPSec tunnels, the router still requires a route (even a default) for those networks. The router routes the packet to the appropriate interface, then the crypto map takes over.

Following the "six step" procedure outlined above:

Step 1: ISAKMP On all routers:

+#K"&$ !42R<" "$?!+K @ 1'+#K"&!$' =14 ,24, 4,2 2%&,1'&!+2&!$' "#1;4,2#1 (#$%" @ ?!.1&!<1 UN66



Step 2: Pre-shared Keys On r1:

+#K"&$ !42R<" R1K ++!1 2==#144 @UNHNEHUUHQ

On r2: +#K"&$ !42R<" R1K ++!1 2==#144 @UNHNEHUUHQ

On r4: +#K"&$ !42R<" R1K ++!1 2==#144 @:NH@EOH@NDH8@ +#K"&$ !42R<" R1K ++!1 2==#144 @UNHN8HDDHN

Step 3: Transform Set We will use one transform set between r1-r4 and a different one between r2-r4.

On r1: +#K"&$ !"41+ &#2'4.$#<;41& #@;#Q41& 14";=14 14";4,2

On r2: +#K"&$ !"41+ &#2'4.$#<;41& #N;#Q41& 14";=14 2,;4,2;,<2+

On r4: +#K"&$ !"41+ &#2'4.$#<;41& #@;#Q41& 14";=14 14";4,2 +#K"&$ !"41+ &#2'4.$#<;41& #N;#Q41& 14";=14 2,;4,2;,<2+

Step 4: Access-List On r1:

2++144;?!4& @6Q "1#<!& !" @6H@H@H6 6H6H6HN88 @6HQHQH6 6H6H6HN88

On r2: 2++144;?!4& @6Q "1#<!& !" @6HNHNH6 6H6H6HN88 @6HQHQH6 6H6H6HN88

On r4: 2++144;?!4& @6@ "1#<!& !" @6HQHQH6 6H6H6HN88 @6H@H@H6 6H6H6HN88 2++144;?!4& @6N "1#<!& !" @6HQHQH6 6H6H6HN88 @6HNHNH6 6H6H6HN88

Step 5: Crypto Map Entries On r1:

+#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @6Q 41& "11# @UNHNEHUUHQ 41& &#2'4.$#<;41& #@;#Q41&

On r2: +#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @6Q 41& "11# @UNHNEHUUHQ 41& &#2'4.$#<;41& #N;#Q41&

On r4: +#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @6@ 41& "11# @:NH@EOH@NDH8@ 41& &#2'4.$#<;41& #@;#Q41& +#K"&$ <2" <K<2" N6 !"41+;!42R<" <2&+, 2==#144 @6N 41& "11# @UNHN8HDDHN 41& &#2'4.$#<;41& #N;#Q41&



Step 6: Apply the crypto map to an interface

On r1: !'&1#.2+1 5&,1#'1& 6 +#K"&$ <2" <K<2"

On r2: !'&1#.2+1 41#!2? 6 +#K"&$ <2" <K<2"

On r4: !'&1#.2+1 5&,1#'1& 6 +#K"&$ <2" <K<2"

Verifying IPSec Connectivity We can verify the IPSec connections in the previous example are up and working properly by using the 4,$* +#K"&$ !"41+ 42 command:

#@04,$ +#K"&$ !"41+ 42 !'&1#.2+1J 5&,1#'1&6 I#K"&$ <2" &2(J <K<2"T ?$+2? 2==#H @:NH@EOH@NDH86 ?$+2? !=1'& -2==#7<24R7"#$&7"$#&/J -@6H@H@H67N88HN88HN88H67676/ #1<$&1 !=1'& -2==#7<24R7"#$&7"$#&/J -@6HQHQH67N88HN88HN88H67676/ +%##1'&Z"11#J @UNHNEHUUHQ [5A_dBT .?2(4hn$#!(!'Z!4Z2+?To !"#$% &'()"%* +,- !"#$% &'(./"$* +,- !"#$% 012&%$ +, !"#$% 0&()"%* +3- !"#$% 0&(./"$* +3- !"#$% 4&.15/ +3 0"R&4 +$<"#1441=J 6T 0"R&4 =1+$<"#1441=J 6 0"R&4 '$& +$<"#1441=J 6T 0"R&4 +$<"#H .2!?1=J 6T 0"R&4 =1+$<"#144 .2!?1=J 6 041'= 1##$#4 OT 0#1+> 1##$#4 6 ?$+2? +#K"&$ 1'="&HJ @:NH@EOH@NDH86T #1<$&1 +#K"&$ 1'="&HJ @UNHNEHUUHQ "2&, <&% @866T <1=!2 <&% @866 +%##1'& $%&F$%'= 4"!J X3DNE6DO !'F$%'= 14" 424J 4"!J 6WEUO56OO:-@UDUDE@8Q8/ &#2'4.$#<J 14";=14 14";4,2;,<2+ T !' %41 41&&!'(4 hnB%''1?T o 4?$&J 6T +$'' !=J N666T .?$*Z!=J @T +#K"&$ <2"J <K<2" 42 &!<!'(J #1<2!'!'( R1K ?!.1&!<1 -R741+/J -QE6U::O7DDEQ/ dP 4!e1J O FK&14 #1"?2K =1&1+&!$' 4%""$#&J j !'F$%'= 2, 424J !'F$%'= "+" 424J $%&F$%'= 14" 424J 4"!J 6WX3DNE6DO-N:D:D@QNDN/



&#2'4.$#<J 14";=14 14";4,2;,<2+ T !' %41 41&&!'(4 hnB%''1?T o 4?$&J 6T +$'' !=J N66@T .?$*Z!=J NT +#K"&$ <2"J <K<2" 42 &!<!'(J #1<2!'!'( R1K ?!.1&!<1 -R741+/J -QE6U::O7DDEQ/ dP 4!e1J O FK&14 #1"?2K =1&1+&!$' 4%""$#&J j $%&F$%'= 2, 424J $%&F$%'= "+" 424J #@0

Notice above (in bold) the traffic that has been encapsulated (in IPSec), encrypted and had a digest applied.When we ping between loopbacks we have success - these packets are all going via the IPSec connections. To verify this you can do another 4,$* +#K"&$ !"41+ 42 after the 25 pings. You'll notice the traffic increases by the 25 packets:

#@0"!'( [#$&$+$? f!"gJ B2#(1& d[ 2==#144J +6787878 A1"12& +$%'& f8gJ N8 m2&2(#2< 4!e1 f@66gJ B!<1$%& !' 41+$'=4 fNgJ 5W&1'=1= +$<<2'=4 f'gJ K )$%#+1 2==#144 $# !'&1#.2+1J +67+7+7+ BK"1 $. 41#>!+1 f6gJ )1& m3 F!& !' d[ ,12=1#p f'$gJ P2?!=2&1 #1"?K =2&2p f'$gJ m2&2 "2&&1#' f6WXGImgJ C$$41T )&#!+&T A1+$#=T B!<14&2<"T P1#F$41f'$'1gJ )*11" #2'(1 $. 4!e14 f'gJ BK"1 14+2"1 41S%1'+1 &$ 2F$#&H )1'=!'( N8T @66;FK&1 dI_[ 5+,$4 &$ @6HQHQHQT &!<1$%& !4 N 41+$'=4J [2+R1& 41'& *!&, 2 4$%#+1 2==#144 $. @6H@H@H@ LLLLLLLLLLLLLLLLLLLLLLLLL )%++144 #2&1 !4 @66 "1#+1'& -N87N8/T #$%'=;&#!" <!'72>(7<2W h 8N78D7E6 <4 #@0 #@0 #@04,$ +#K"&$ !"41+ 42 !'&1#.2+1J 5&,1#'1&6 I#K"&$ <2" &2(J <K<2"T ?$+2? 2==#H @:NH@EOH@NDH86 ?$+2? !=1'& -2==#7<24R7"#$&7"$#&/J -@6H@H@H67N88HN88HN88H67676/ #1<$&1 !=1'& -2==#7<24R7"#$&7"$#&/J -@6HQHQH67N88HN88HN88H67676/ +%##1'&Z"11#J @UNHNEHUUHQ [5A_dBT .?2(4hn$#!(!'Z!4Z2+?To !"#$% &'()"%* 89- !"#$% &'(./"$* 89- !"#$% 012&%$ 89 !"#$% 0&()"%* 8+- !"#$% 0&(./"$* 8+- !"#$% 4&.15/ 8+



0"R&4 +$<"#1441=J 6T 0"R&4 =1+$<"#1441=J 6 0"R&4 '$& +$<"#1441=J 6T 0"R&4 +$<"#H .2!?1=J 6T 0"R&4 =1+$<"#144 .2!?1=J 6 041'= 1##$#4 OT 0#1+> 1##$#4 6 ?$+2? +#K"&$ 1'="&HJ @:NH@EOH@NDH86T #1<$&1 +#K"&$ 1'="&HJ @UNHNEHUUHQ "2&, <&% @866T <1=!2 <&% @866 +%##1'& $%&F$%'= 4"!J X3DNE6DO !'F$%'= 14" 424J 4"!J 6WEUO56OO:-@UDUDE@8Q8/ &#2'4.$#<J 14";=14 14";4,2;,<2+ T !' %41 41&&!'(4 hnB%''1?T o 4?$&J 6T +$'' !=J N666T .?$*Z!=J @T +#K"&$ <2"J <K<2" 42 &!<!'(J #1<2!'!'( R1K ?!.1&!<1 -R741+/J -QE6U::Q7@@68/ dP 4!e1J O FK&14 #1"?2K =1&1+&!$' 4%""$#&J j !'F$%'= 2, 424J !'F$%'= "+" 424J $%&F$%'= 14" 424J 4"!J 6WX3DNE6DO-N:D:D@QNDN/ &#2'4.$#<J 14";=14 14";4,2;,<2+ T !' %41 41&&!'(4 hnB%''1?T o 4?$&J 6T +$'' !=J N66@T .?$*Z!=J NT +#K"&$ <2"J <K<2" 42 &!<!'(J #1<2!'!'( R1K ?!.1&!<1 -R741+/J -QE6U::Q7@@68/ dP 4!e1J O FK&14 #1"?2K =1&1+&!$' 4%""$#&J j $%&F$%'= 2, 424J $%&F$%'= "+" 424J #@0

Performing a 4,$ +#K"&$ !42R<" 42 displays that the two routers have successfully made an ISAKMP connection:

#@04,$ +#K"&$ !42R<" 42 =4& 4#+ 4&2&1 +$'';!= 4?$& @UNHNEHUUHQ @:NH@EOH@NDH86 ]_ZdmC5 @ 6 #@0

The final router configs from the example in Figure 7: IPSec Using Multiple Tunnels: r1 +#K"&$ !42R<" "$?!+K @ 1'+#K"&!$' =14 ,24, 4,2 2%&,1'&!+2&!$' "#1;4,2#1 (#$%" @



?!.1&!<1 UN66 +#K"&$ !42R<" R1K ++!1 2==#144 @UNHNEHUUHQ +#K"&$ !"41+ &#2'4.$#<;41& #@;#Q41& 14";=14 14";4,2 +#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @6Q 41& "11# @UNHNEHUUHQ 41& &#2'4.$#<;41& #@;#Q41& !'&1#.2+1 ?$$"F2+R @86 !" 2==#144 @6H@H@H@ N88HN88HN88H6 !'&1#.2+1 5&,1#'1& 6 !" 2==#144 @:NH@EOH@NDH86 N88HN88HN88H6 +#K"&$ <2" <K<2" #$%&1# $4". @ '1&*$#R @:NH@EOH@NDH6 6H6H6HN88 2#12 6 '1&*$#R @6H@H@H6 6H6H6HN88 2#12 6 2++144;?!4& @6Q "1#<!& !" @6H@H@H6 6H6H6HN88 @6HQHQH6 6H6H6HN88

r2 +#K"&$ !42R<" "$?!+K @ 1'+#K"&!$' =14 ,24, 4,2 2%&,1'&!+2&!$' "#1;4,2#1 (#$%" @ ?!.1&!<1 UN66 +#K"&$ !42R<" R1K ++!1 2==#144 @UNHNEHUUHQ +#K"&$ !"41+ &#2'4.$#<;41& #N;#Q41& 14";=14 2,;4,2;,<2+ +#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @6Q 41& "11# @UNHNEHUUHQ 41& &#2'4.$#<;41& #N;#Q41& !'&1#.2+1 ?$$"F2+R @86 !" 2==#144 @6HNHNHN N88HN88HN88H6 !'&1#.2+1 5&,1#'1& 6 !" 2==#144 @:NH@EOH@NDH8N N88HN88HN88H6 !'&1#.2+1 41#!2? 6 !" 2==#144 @UNHN8HDDHN N88HN88HN88H6 +#K"&$ <2" <K<2" #$%&1# $4". @ '1&*$#R @:NH@EOH@NDH6 6H6H6HN88 2#12 6 '1&*$#R @UNHN8HDDH6 6H6H6HN88 2#12 6 '1&*$#R @6HNHNH6 6H6H6HN88 2#12 6 2++144;?!4& @6Q "1#<!& !" @6HNHNH6 6H6H6HN88 @6HQHQH6 6H6H6HN88

r4 +#K"&$ !42R<" "$?!+K @ 1'+#K"&!$' =14 ,24, 4,2 2%&,1'&!+2&!$' "#1;4,2#1 (#$%" @ ?!.1&!<1 UN66 +#K"&$ !42R<" R1K ++!1 2==#144 @:NH@EOH@NDH86 +#K"&$ !42R<" R1K ++!1 2==#144 @UNHN8HDDHN +#K"&$ !"41+ &#2'4.$#<;41& #@;#Q41& 14";=14 14";4,2 +#K"&$ !"41+ &#2'4.$#<;41& #N;#Q41& 14";=14 2,;4,2;,<2+ +#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @6@ 41& "11# @:NH@EOH@NDH86 41& &#2'4.$#<;41& #@;#Q41&



+#K"&$ <2" <K<2" N6 !"41+;!42R<" <2&+, 2==#144 @6N 41& "11# @UNHN8HDDHN 41& &#2'4.$#<;41& #N;#Q41& !'&1#.2+1 ?$$"F2+R @86 !" 2==#144 @6HQHQHQ N88HN88HN88H6 !'&1#.2+1 5&,1#'1& 6 !" 2==#144 @UNHNEHUUHQ N88HN88HN88H6 +#K"&$ <2" <K<2" #$%&1# $4". @ '1&*$#R @UNHNEHUUH6 6H6H6HN88 2#12 6 '1&*$#R @6HQHQH6 6H6H6HN88 2#12 6 2++144;?!4& @6@ "1#<!& !" @6HQHQH6 6H6H6HN88 @6H@H@H6 6H6H6HN88 2++144;?!4& @6N "1#<!& !" @6HQHQH6 6H6H6HN88 @6HNHNH6 6H6H6HN88

IPv6 With version 12.2 of IOS, Cisco has reasonably good support for IPv6. I used version 12.2(15)T14 on my 2500's with good success - it doesn't have every IPv6 feature, but it does include IPv6 RIP, OSPF, BGP, etc. IOS version 12.4T provides fairly extensive IPv6 functionality. IPv6 is likely to appear on the exam, so it is important you understand IPv6 and have practiced some configuration scenarios.

! Note: Unlike IPv4, IPv6 routing is not enabled globally by default. If you think this is strange, let's face it - how many people are really using it?!! To enable it globally, use the !">E %'!+24&;#$%&!'( global configuration command.

Access Lists Access lists are created with the !">E 2++144;?!4& ;<=6$#") command, where XICZ'2<1 can be any name you choose. IPv6 access lists are designated with a word, rather than a number. I prefer this anyway - with a word (or series of words separated by _ ) you can make a meaningful name for the list, rather than simply "access-list 100."

IPv6 access lists are formatted the same way IP extended access lists are formatted. That is, after the !">E 2++144;?!4& ;<=6$#") command there are an unlimited number of permit and deny statements that can specify protocol (TCP, UDP, etc.), source and destination IPv6 addresses and/or source and destination port numbers or port ranges. IPv6 ACL's contain an implied "deny any any" at the end, just like IPv4 ACL's. By default IPv6 ACL's allow Neighbor Discovery (the same way IPv4 ACL's by default allow ARP).

IPv6 access lists take sequence numbers. These are not required - if you simply type in permit and deny statements they will be entered in the order you type them. However if you need to place a new line in the middle of the list, sequence numbers are very handy. This is similar to the way route-maps work. If you need to do this the statements, by default, are



sequenced by 10's (10, 20, 30&) even though the sequence numbers will not be shown. Thus to place a new entry between the existing second and third entries (sequence entries 20 and 30), simply add a 41S%1'+1 N8

"1#<!& &+" 2'K 2'K command:

#D04,$ #%' q L !">E 2++144;?!4& F?$+RZ#@ "1#<!& %=" 2'K 1S #!" 2'K "1#<!& %=" 2'K 2'K 1S #!" =1'K !+<" ,$4& @6J@6J@6JJ@ ,$4& D66JD66JD66JJD ?$(;!'"%& "1#<!& %=" 2'K 2'K 1S 8N@ "1#<!& !">E ,$4& @6J@6J@6JJ@ 2'K L q #D0+$'. & #D-+$'.!(/0!">E 2++144;?!4& F?$+RZ#@ #D-+$'.!(;!">E;2+?/041S%1'+1 N8 "1#<!& &+" 2'K 2'K #D-+$'.!(;!">E;2+?/01'= #D04,$ #%' q L !">E 2++144;?!4& F?$+RZ#@ "1#<!& %=" 2'K 1S #!" 2'K "1#<!& %=" 2'K 2'K 1S #!" 41S%1'+1 N8 "1#<!& &+" 2'K 2'K 41S%1'+1 D6 =1'K !+<" ,$4& @6J@6J@6JJ@ ,$4& D66JD66JD66JJD ?$(;!'"%& "1#<!& %=" 2'K 2'K 1S 8N@ "1#<!& !">E ,$4& @6J@6J@6JJ@ 2'K L

ACL's have many uses, such as applying them to interfaces to filter traffic or to restrict access to vty ports:

!'&1#.2+1 3X67@ !">E &#2..!+;.!?&1# =1'K;,&&";2+? !' !">E &#2..!+;.!?&1# =1'K;4<&";2+? $%& L ?!'1 >&K 6 Q !">E 2++144;+?244 !&;=1"&;$'?K !'

IPv6 ACL's can also filter based on many IPv6 attributes, such as destination option type, DSCP, flow label, fragmented packets, mobility, etc.

Addressing As you may know IPv6 uses 128 bits of addressing rather than IPv4's 32 bits. So rather than the 4 octets of addressing you are used to, there are 16. On an editorial note I feel this is one of things that will slow its acceptance. Suppose your team is troubleshooting a problem. Today you might ask someone else on your network team "Hey, try pinging 172.16.1.5."With IPv6 you'll be asking, "Hey, try pinging 172.16.1.5.192.168.17.168.12.34.1.1.10.145.248.1!!" Now its not quite



that bad - there are some shortcuts that are useful - but without a doubt the addressing of IPv6 is much more cumbersome than IPv4.

In reality IPv6 addressing is not broken up into the 8-bit octets that we are used to. Instead of the sixteen 8-bit octets that would be required for 132 bits, IPv6 uses eight hex words that are 16 bits each. IPv6 addressing uses colons (:) instead of dots between these groups. So an actual IPv6 address would appear something like 10FE:29A4:333C:4194:DAC7:8A6B:100A:613F. Any "leading zeros" within a single hex block can be omitted, so 1076:0000:5234:0000:3CA1:0000:9812:101E can be represented as 1076:0:5234:0:3CA1:0:9812:101E. Another shortcut is a double colon (::) represents all zeros for any part of the address that are not otherwise called out. So rather than use an address of 172:16:0:0:0:0:0:1, you can simply use 172:16::1 (although remember - the 172, 16 and 1 are in hex!). Since only three hex words are listed and eight are required, in this case the :: represent five hex words of zeros. IPv6 addresses can be applied to all types of interfaces, just like ipv4 (Ethernet, serial, loopback, etc.)

Just as with IPv4 addressing, you need to tell the router the subnet mask so that it knows which part is the network/subnet portion and what part is the host portion. Again, where IPv6 uses such a large address space a shortcut is to simply list the number of network/subnet bits. So whereas today you might use a /24 or a /27, with IPv6 you might list /48, /56 or /64 as the number of subnet bits. Using a 64-bit subnet mask leaves the remaining 64 bits for host addressing. By default with IPv6 hosts use the last 64 bits of the 128-bit address as the host portion. Hosts typically use their MAC address as their host address (removing the need for ARP). Since Ethernet MAC addresses are only 48 bits long, stations add FFFE in the middle of their MAC address to complete the 64-bit host address. So a MAC address of 00E0.B05A.D998 becomes 00E0.B0FF.FE5A.D998.

IPv6 has the concept of link-local addresses. This is a process where IPv6 devices basically assign themselves their own address. This is helpful if a TV remote control and a TV are using IPv6 to communicate, for example. In this case DHCP may not be convenient and manually assigning the TV and remote an IPv6 address is definitely not helpful. (Most people can't set the clock on their VCR - imagine an average user trying to set an IPv6 address on their TV!!) Link local addresses use the prefix FE80, followed by the double colon (indicating the rest of the subnet portion is all zeros), followed by the 64-bit host address. So a router with a MAC address of 00E0.1E3E.3ACB will create a link-local address of FE80::00E0.1EFF.FE3E.3ACB. The FF.FE are used to extend the 48-bit MAC address to 64 bits. This will appear when you enter a "show ipv6 int brief," for example. Don't worry too much about these. The router will assign the addresses itself and they really aren't used much.



If you get to assign your own IPv6 addressing (likely), I would attempt to keep it as simple and familiar as possible. In my lab I used addresses like 192:168:10::1/64 and 300:300:300::1/48, etc. Even though in this case 192 is a 16-bit hex word (since only three hex letters are entered the router assumes a leading 0 (0192 or 0300)), it still is familiar. Obviously 300 could never be used in IPv4, but 300 is allowed because of the hex nature of IPv6 addressing. The address 300:300:300::3 might be a good loopback address to assign to r3, for example.

You can ping IPv6 addresses just like any other address:

#@0"!'( D66JD66JD66JJD BK"1 14+2"1 41S%1'+1 &$ 2F$#&H )1'=!'( 8T @66;FK&1 dI_[ 5+,$4 &$ D66JD66JD66JJDT &!<1$%& !4 N 41+$'=4J LLLLL )%++144 #2&1 !4 @66 "1#+1'& -878/T #$%'=;&#!" <!'72>(7<2W h @N7@N7@N <4 #@0

BGP For BGP, routers run a single autonomous system (such as #$%&1# F("

E8666), but can have IPv4 BGP neighbors and IPv6 neighbors.With IPv6 BGP, you start out as you would in IPv4 (define the autonomous system, no auto-summary, no synch, define any IPv4 neighbors and networks), but then use the 2==#144;.2<!?K !">E router bgp command to indicate to the router that it will be running IPv6 BGP. IPv6 neighbors and networks are defined in this portion of the configuration (a sub-portion of the BGP config).

Most of the same BGP commands will apply to IPv6. For example you can type "4,$ !" F(" '1!(,F$#4" and both IPv4 and IPv6 neighbors will be shown. However, you need to type "4,$* F(" !">E %'!+24&" or "4,$*

F(" 2??" to see all the IPv6 entries. This takes a bit of getting used to, and normally it is easy to figure out what command syntax is required. The best thing you can do is practice on your own routers and get used to the syntax.

A config from a router with one IPv4 and one IPv6 BGP neighbor:

#$%&1# F(" E866Q '$ 4K'+,#$'!e2&!$' F(" ?$(;'1!(,F$#;+,2'(14 '1!(,F$# @6J@6J@6JJ@ #1<$&1;24 E866@ '1!(,F$# @6H@6H@6H@ #1<$&1;24 E866@ '$ 2%&$;4%<<2#K L 2==#144;.2<!?K !">E '1!(,F$# @6J@6J@6JJ@ 2+&!>2&1 '1&*$#R @6J@6JQJJQ78E '1&*$#R @:NJ@EOJQJJQ7QO '1&*$#R Q66JQ66JQ66JJQ7@NO '$ 4K'+,#$'!e2&!$'



#1=!4&#!F%&1 #!" &14& <1&#!+ @ 1W!&;2==#144;.2<!?K L 2==#144;.2<!?K !">Q '$ '1!(,F$# @6J@6J@6JJ@ 2+&!>2&1 '1!(,F$# @6H@6H@6H@ 2+&!>2&1 '$ 2%&$;4%<<2#K '$ 4K'+,#$'!e2&!$' 1W!&;2==#144;.2<!?K L

A look at an IPv6 routing table displays: #@04,$ !">E #$%&1 d[>E A$%&!'( B2F?1 ; U 1'&#!14 I$=14J I ; I$''1+&1=T C ; C$+2?T ) ; )&2&!+T A ; Ad[T G ; GM[ d@ ; d)d) C@T dN ; d)d) CNT dX ; d)d) !'&1#2#12 B!<1#4J l"&!<175W"!#14 C @66J@66JJ@7@NO f676g >!2 JJT C$$"F2+RN66T 66J66J@U7'1>1# I @66J@66JJ7EQ f676g >!2 JJT C$$"F2+RN66T 66J66J@U7'1>1# C @:NJ@EOJJ@7@NO f676g >!2 JJT )1#!2?6T 66J68JDO7'1>1# I @:NJ@EOJJ7EQ f676g >!2 JJT )1#!2?6T 66J68JQ@7'1>1# A N66JN66JJ7EQ f@N67Ng >!2 35O6JJN56JG633J3588JG6D8T )1#!2?6T 66J6@JQO766J6NJDQ G D66JD66JJ78E fN67@g >!2 @:NJ@EOJ@NDJJ8NT 5&,1#'1&6T 66J66JNE7'1>1# C 35O6JJ7@6 f676g >!2 JJT Y%??6T 66J68JQ@7'1>1# C 3366JJ7O f676g >!2 JJT Y%??6T 66J68JQ@7'1>1# #@0

Here the 100:100::1/64 and 192:168::1/64 networks are configured locally on r1 on the loopback200 and serial0 interfaces, respectively. Network 200:200::/64 is learned via RIP from another router connected to the serial0 interface. Network 300:300::/56 is learned via BGP from an IPv6 BGP neighbor attached to Ethernet 0.

EIGRP EIGRPv6 supports IPv6. Although there is a global !">E #$%&1# 1!(#"

#2,$'"()*&command, there are no '1&*$#R commands. Instead EIGRP is enabled on each interface with the !">E 1!(#" #2,$'"()* interface command (similar approach to ipv6 OSPF). That command both enables EIGRP to search for neighbors on that interface and begins advertising that network (configured on the interface) via EIGRP.



Filtering EIGRP routes requires the =!4&#!F%&1;?!4& "#1.!W;?!4& router command - using a route-map to filter routes is not supported in EIGRP as it is with some IPv6 routing protocols.

EIGRP summary ranges can be configured on an interface - very similar to IPv4. Apply the !">E 4%<<2#K;2==#144 1!(#" @66 86@NJX66QJ@J@JJ7EQ

interface command to Fa0/0 to only advertise a summary for all routes falling within the range 86@NJX66QJ@J@JJ7EQ out interface Fa0/0 for EIGRP process 100.

By default an EIGRP router will advertise itself as the next hop address for all routes it is advertising. To override this - and keep the next hop address that was learned with the route - use the '$ !">E '1W&;,$";41?.

1!(#" #2,$'"()* interface command. Split Horizon is enabled by default - routes are not advertised out the same interface on which they were learned. To disable this (may be required on multipoint Frame-Relay or Tunnel interfaces, for example) use the '$ !">E 4"?!&;,$#!e$' 1!(#"

#2,$'"()* interface command. The hello/hold timers by default are 5/15 seconds on broadcast networks and 60/180 seconds on NBMA networks. Although it is somewhat unlikely you will need to change these, they can be modified with the !">E ,1??$;!'&1#>2? 1!(#" #2,$'"()*&2) !$%2 and !">E ,$?=;&!<1 1!(#" #2,$'"()*&2) !$%2 interface commands.

To make a router an EIGRP stub (similar to IPv4) use the 4&%F f#1+1!>1;

$'?K \ +$''1+&1= \ 4&2&!+ \ 4%<<2#K \ #1=!4&#!F%&1=g router command (see IPv4 Stub routing on page 52 for detailed explanation of keywords).

Filtering Access-lists and prefix-lists are included in IPv6, just as you would expect. The lists themselves are very similar to IPv4, with the obvious exception that you use IPv6 addresses.

One difference you will see is that access-lists get applied to interfaces (for packet filtering) with the &#2..!+;.!?&1# interface command, such as !">E &#2..!+;.!?&1# F?$+RZ#@ !'.

Prefix-lists and/or access-lists can still be applied to the OSPF and RIP routing processes with the =!4&#!F%&1;?!4& command in the d[>E #$%&1#

#!" &14& router configuration:

!">E #$%&1# #!" &14& =!4&#!F%&1;?!4& "#1.!W;?!4& G?$+RZAd[ !' )1#!2?6 L !">E "#1.!W;?!4& G?$+RZAd[ 41S 8 =1'K @UNJ@EJNJJN7@NO !">E "#1.!W;?!4& G?$+RZAd[ 41S @6 =1'K @6J@6J@6JJ7UN !">E "#1.!W;?!4& G?$+RZAd[ 41S @8 "1#<!& JJ76 ?1 @NO



Remember that in an IPv6 prefix-list the entry for "permit any any" is ""1#<!& JJ76 ?1 @NO" or ""1#<!& 6JJ676 ?1 @NO." Remember that if you apply a =!4&#!F%&1;?!4& to an existing IPv6 RIP process you will need to wait for the routes to time-out of the routing table (or perform a "+?12# !">E #$%&1 a" for impatient types, like myself!)

BGP filtering can be applied just as it is in IPv4 - distribute lists, neighbor route-maps, neighbor prefix-lists, etc. The !">E 2++144;+?244 #14&#!+&;

&1?'1& !' line command can be applied to vty, aux and con lines, just like with IPv4.

IOS Firewall Traffic filtering can be performed using IPv6 ACL's or with the IOS firewall. It is similar to the IPv4 IOS firewall, so you should become familiar with that first (page 53).

To implement IOS Firewall, an inspection name is configured. This configuration defines what traffic the IOS Firewall will inspect. That inspection name is then applied - either inbound or outbound - to an interface. Optionally an ACL can be applied to an interface to allow traffic that does not meet the inspection criteria. Return traffic to the interface that meets the inspection criteria (continuations of sessions that passed the inspection) are automatically allowed.

This example shows Fa0/0 as the inside interface and Fa0/1 as the outside. TCP Traffic is inspected leaving Fa0/1, and the return traffic is allowed back in. All ICMP traffic inbound on Fa0/1 is permitted by the ACL:

!">E !'4"1+& '2<1 !">EZ.!#1*2?? &+" L !'&1#.2+1 324&5&,1#'1&676 =14+#!"&!$' d'4!=1 !'&1#.2+1 !">E 2==#144 D6X6JGO66J6JIXJJ7EQ 1%!;EQ L !'&1#.2+1 324&5&,1#'1&67@ =14+#!"&!$' c%&4!=1 !'&1#.2+1 !">E 2==#144 D6X6JGO66J@JIGJJ7EQ 1%!;EQ !">E !'4"1+& !">EZ.!#1*2?? $%& !">E &#2..!+;.!?&1# X??$*ZdI_[ !' L !">E 2++144;?!4& X??$*ZdI_[ "1#<!& !+<" 2'K 2'K

OSPF You may hear OSPF for IPv6 referred to as "OSPFv3," since v1 and v2 were for IPv4 and in version 3 they included IPv6 support.

In IPv6 you identify each OSPF process with a process number like you do in IPv4. However the global command to configure the IPv6 OSPF process is !">E #$%&1# $4". @, unlike IP OSPF config (#$%&1# $4". @).



Rather than using '1&*$#R statements in the router ospf configuration, !">E $4". @ 2#12 6 commands are used under the interface configuration. This is similar to the difference between IP RIP and IPv6 RIP. In fact you are not required to configure IPv6 OSPF globally. Simply entering the !">E $4". @ 2#12 6 interface command will automatically enable the IPv6 OSPF process. You will need to enter the global IPv6 OSPF config mode to set other configuration parameters (distance, redistribution, etc. - many of the same global commands as OSPF with IPv4).

When running IPv6 over NBMA (Frame Relay) networks OSPF neighbors must be defined manually. Do this by using the !">E $4". '1!(,F$#

r2==#144s command, where <address> is the link-local address of the neighbor. Identify the link-local by performing a "4,$* !">E !'& F#!1." command on the neighbor. Once this is displayed I recommend copying & pasting the link local address into the opposite router's configuration.

!'&1#.2+1 41#!2? 676 !">E $4". @ 2#12 6 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K <2" !">E 35O6JJX6UGJUm33J3566J:G@8 @66 !">E $4". '1!(,F$# 35O6JJX6UGJUm33J3566J:G@8

IPv6 OSPF can generate a default route with the =1.2%?&;!'.$#<2&!$'

$#!(!'2&1 command in the !">E #$%&1# $4". @ router configuration mode. Use the 2?*2K4 keyword to generate the IPv6 default route regardless of whether that router actually has an IPv6 default route. The IPv6 default route will look like:

#N04,$ !">E #$%&1 d[>E A$%&!'( B2F?1 ; @U 1'&#!14 I$=14J I ; I$''1+&1=T C ; C$+2?T ) ; )&2&!+T A ; Ad[T G ; GM[ l ; [1#;%41# )&2&!+ #$%&1 d@ ; d)d) C@T dN ; d)d) CNT dX ; d)d) !'&1#2#12 c ; c)[3 !'&#2T cd ; c)[3 !'&1#T c5@ ; c)[3 1W& @T c5N ; c)[3 1W& N :;9 **<6 =++6<+>- $)2 + 41) ?;@6**9;6*A6??*?;BC*DEE@- F&.1)G6 #N0

RIP RIP for ipv6 is also known as RIPng (next generation). You use a word (or a number, optionally) to identify the IPv6 RIP process. This allows multiple IPv6 RIP processes to be running on a router, the same way you can have multiple OSPF or EIGRP processes with IPv4. Enable the IPv6 RIP process called "test" on each interface by using the !">E #!" &14& 1'2F?1

interface command. You do not use the '1&*$#R router command as you do with IPv4 RIP. IPv6 RIP is disabled by default, so you will need to specifically enable it wherever you need it.



In fact the only things you can actually configure in the router !">E #$%&1#

#!" &14& configuration are things that will look fairly familiar: distance, distribute lists, split horizon (yes, RIPng still uses split horizon!), timers, etc.

Configuring routing summaries with IPv6 RIP is similar to EIGRP. Rather than summarizing in the d[>E #$%&1# #!" &14& process, RIP summaries are defined on the interface with the !">E #!" &14& 4%<<2#K;2==#144

@:NJ@EOJJ7DN command (or whatever route you want to summarize). This route is then advertised out the interface to which this command is applied. Each interface upon which you'd like to advertise a summary will need this command, and different interfaces can advertise different summaries.

The interface level is where you can also configure the router to only advertise the default route or to originate the default route. Again, these commands will only apply to the interface on which they are applied. If you want to originate the default route on several interfaces the !">E #!" &14&

=1.2%?&;!'.$#<2&!$' $#!(!'2&1 command will be required on each one.

Redistribution IPv6 redistribution is very similar to routing redistribution in IPv4. One protocol can be redistributed into another (OSPF into BGP, RIP into OSPF, BGP into EIGRP, etc.) and one routing process can be redistributed into another (OSPF into OSPF, EIGRP into EIGRP, etc.) As with IPv4, this is done under the global routing configuration with the #1=!4&#!F%&1 command. IPv6 redistribution allows routing metrics to be set, route-maps to be applied and source protocol options (such as level-1 or level-2 for IS-IS, metric-type 1 or metric-type 2 for OSPF, etc.) to be set.

Tunneling The most common use of tunneling is to connect two separate IPv6 networks across an IPv4 backbone. The IPv6 packets get encapsulated at a router that supports both IPv4 and IPv6 and terminates one end of the tunnel. The packets can then be transported across any number of IPv4 hops, but eventually are de-encapsulated by a router at the other end of the tunnel. A routing protocol for IPv6 (RIP, OSPF, etc.) can be configured to run across the tunnel, so routers at either end will learn about routes in the other network. Use an IPv6 tunnel in the lab to connect two IPv6 routers that are separated by an IPv4 network (note you may not specifically told to configure a tunnel!)



Cisco supports several types of IPv6 tunnels. The tunneling type you choose will depend on the requirements you are given. Here is an overview of the tunneling types:

· Manual - the simplest type, and thus recommended if it meets all the requirements. The tunnel is a permanent, static tunnel defined by the tunnel source and destination IPv4 addresses. An IPv6 address is configured on the tunnel interface. It uses the command &%''1? <$=1 !">E!".

· Generic routing encapsulation (GRE) - the tunnel is a permanent, static tunnel defined by the tunnel source and destination IPv4 addresses. An IPv6 address is configured on the tunnel interface. A GRE tunnel can also carry CLNS traffic (which you almost surely will not see) and IS-IS traffic (which you could, but most likely won't see). It uses the command &%''1? <$=1 (#1 !">E.

· IPv4-compatible - the tunnel does not require a statically configured tunnel destination, since the destination is contained in the IPv6 address, which is 0:0:0:0:0:0:A.B.C.D or ::A.B.C.D, where "A.B.C.D" represents the embedded IPv4 address. It is unlikely you would use this type in the lab. It uses the command &%''1? <$=1 !">E!" 2%&$;&%''1?.

· 6to4 - these tunnels are not point-to-point, but rather point-to-multipoint. These also do not have a statically configured tunnel destination, but rather the destination is contained in the IPv6 address, in the format N66NJF$#=1#;#$%&1#;d[>Q;2==#144JJ7QO. Note that 2002 is 16 bits and the IPv4 address is 32 bits, for the 48 bits total. This leaves 16 bits for further network addressing, if desired. The advantage of this tunnel is the border router automatically tunnels each IPv6 packet to the correct destination address based on the IPv6 address. It uses the command &%''1? <$=1 !">E!" E&$Q.

· Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) - a similar point-to-multipoint tunnel as with 6to4, but the IPv6 address is composed of an 64-bit unicast IPv6 address, followed by the 32 bits "0000:5EFE," followed by the 32 bits of the destination IPv4 address. It uses the command &%''1? <$=1 !">E!"

!42&2".

Each tunnel -regardless of the type - is configured in a similar manner. The interface is defined with the !'&1#.2+1 &%''1? $'"()*&global command. I recommend using the same '%<F1# at both ends of the tunnel



- it may make it easier to remember which tunnel you are working on. The tunnel source is defined with the &%''1? 4$%#+1 interface command and the tunnel destination is either configured with the &%''1? =14&!'2&!$'

interface command or determined dynamically. The tunnel type is then configured with the &%''1? <$=1 interface command.

In this example router A and router B use a manual tunnel to connect their IPv6 networks. RIP (for IPv6) runs across the tunnel, advertising networks. This requires a fully functional IPv4 network:

Router A Configuration !'&1#.2+1 C$$"F2+R 6 !" 2==#144 @UNH@EHQ8H@ N88HN88HN88H6 L !'&1#.2+1 &%''1? 6 !">E 2==#144 @J@JNJ@JJN7@NE &%''1? 4$%#+1 C$$"F2+R 6 &%''1? =14&!'2&!$' @UNHN@H@:@H@ &%''1? <$=1 !">E!" !">E #!" ,$(*2#&4 1'2F?1

Router B Configuration !'&1#.2+1 C$$"F2+R 6 !" 2==#144 @UNHN@H@:@H@ N88HN88HN88H6 L !'&1#.2+1 &%''1? 6 !">E 2==#144 @J@JNJ@JJD7@NE &%''1? 4$%#+1 C$$"F2+R 6 &%''1? =14&!'2&!$' @UNH@EHQ8H@ &%''1? <$=1 !">E!" !">E #!" ,$(*2#&4 1'2F?1

Lab Day!! The information within this section is provided to help you prepare a strategy for the day you actually take your lab exam:

Getting Started Checklist It is easy to gather enough information about the lab to be able to prepare a "getting started" checklist. This is a list of the first steps to take on the morning of the lab. Here is my list, in order: 1. Read the lab exam completely. Read it quickly and efficiently - you

are not enjoying a John Grisham novel - but don't read it so quickly you are careless.Make a list of:

a. Hidden issues and pitfalls b. Your strong and weak areas

2. Use the terminal server to connect to every router and switch in your rack. If its not done for you, make r1 the first connection, r2 the second connection, etc. Make the switch(es) the last connections. That way you can type in a "3" at the terminal server and be connected to r3, etc.



3. In notepad enter all commands that will be entered into every router (see Script for all routers, below).

4. Configure the routers with the above commands as well as all "layer 2" commands you may need. Verify:

2H Verify all interfaces are up, up FH Verify all Frame Relay PVCs are CcIXC and XIBdP5

Script for all routers It is helpful to use a program like Notepad to record standard commands you want to place in every router. Then you can cut & paste them into the config. Here aremy commands:

2?!24 1W1+ ! 4,$* !" #$%&1 2?!24 1W1+ + 4,$* #%''!'(;+$'.!( 2?!24 1W1+ F 4,$* !" !'& F#!1. 2?!24 1W1+ $ 4,$* !" $4". 2?!24 1W1+ & +$'.!( &1#< '$ !" =$<2!';?$$R%" !" +?244?144 !" &+" 4K'*2!&;&!<1 8 ?!'1 +$'4$?1 6 ?$(( 4K' 1W!& ?!'1 >&K 6 Q ?$(( 4K' 1W!&

The "logg syn" (logging synchronous) is optional. It does a nice job of 'repainting' your screen (helpful if you are in the middle of a command when a debug message comes through), but it also delays debugs (such as until a ping ends) which can be annoying&try this in your lab to see if you like it. I didn't use it, preferring to use ctrl-r instead to refresh my screen.

The "ip tcp synwait-time 5" and "no ip domain-lookup" will both save you time. The former times-out a failed TCP connection (such as trying to telnet to another router) in 5 seconds, rather than the default of 30 (which feels more like 3 minutes). This is helpful if you telnet to another router but typed the IP address incorrectly, etc. This is one of my favorite IOS commands! Man, is it annoying waiting for the router to come back& The latter command prevents the router from trying to perform DNS lookups. This can occur when you mistype a command and the router attempts to perform a DNS look-up for it, such as when you type "enabv" instead of "enab" to get into enable mode. Possibly even more importantly this command prevents the router from performing reverse DNS lookups, such as during traceroutes. I highly recommend using both of these.

Aliases Aliases are simply shortcuts that you define for your own use. They basically allow you to create your own words for commonly used



commands. You define what the shortcut word (or letter) will be and what command it corresponds to. So the alias:

2?!24 1W1+ F4%<< 4,$* !" F(" 4%<<2#K

Creates a command called "bsumm" that is an exec level command that will actually send to the router "show ip bgp summary."

I used just a single letter for my aliases (shown in the previous section). Hey - I figured if they are meant to save me time, they might as well really save me time! Aliases like my 2?!24 1W1+ ! 4,$* !" #$%&1 are extremely handy because you can enter keywords after it. Thus if you enter "i bgp" the router gets "show ip route bgp" and displays all BGP-learned routes. If you enter "i 192.168.5.0" the router gets "show ip route 192.168.5.0" and it will show you how it will route to 192.168.5.0. You may want to enter more aliases like that. For example, you could configure:

2?!24 1W1+ $ 4,$* !" $4".

Thus when you enter: The router will display: o show ip ospf o int show ip ospf interfaces o nei show ip ospf neighbors etc. etc.

You may want to also create an alias for "show ip bgp" since this would be useful in the same way. You could use this to show "show ip bgp," "show ip bgp neighbors," "show ip bgp summary," etc.

Note: Each person takes a different approach to aliases. You should at least use some aliases - they will save you time. Some people configure many - 20 or more aliases. I prefer to just use these five or six because you know you will need these. I didn't want the burden of entering a ton of aliases into notepad on the day of the exam (not to mention remembering to use them all!)Whatever way you choose, always enter these in your practice routers so they become second nature to you!

Configuring the Routers There are two basic approaches to configuring the routers on lab day: 1. Configure Layer 2 (Frame Relay, etc.) first, then Layer 3 (IP), then

Routing (OSPF, BGP, etc.) This offers the advantage that it is very orderly, building the configs from the ground up. This is the approach I used when I took my lab.

2. Configure Layer 2, 3 and routing together. This has the advantage that it can be faster, since you configure everything on a given router before moving to the next router. The big disadvantage of this approach, in my opinion, is if there is a problem it is more



difficult to troubleshoot. If two routers are not forming an OSPF neighbor relationship: is OSPF misconfigured? Are the IP addresses misconfigured? Or has something at Layer 2 (such as a Frame Relay DLCI) been misconfigured?

You should practice with both methods and use the one you feel most comfortable with. In either case, don't start applying access lists and route maps until all Layer 2, Layer 3 and Routing are working correctly!

Making Your Diagram In your practice sessions you should develop a "standard" way of making a network diagram. Practice doing this until it becomes very comfortable to you. For example, I took the advice of another CCIE and made all my OSPF areas green circles. I made all my BGP Autonomous Systems blue squares. By doing this you will become very familiar at glancing at a diagram and understanding what is happening. Be careful not to go overboard. Trying to look at a diagram and understand 13 colors and 8 shapes can be more confusing than helpful! Use this same technique when you make your diagram on lab day. I just used normal black to document many of the "smaller" configs - NTP, Spanning Tree, etc.

Keep a List Consider keeping a list during the exam. It can be a list of "gotchas," a list of things you need to check, a list of items to configure before the exam ends - whatever is helpful to you.

Loopback Interfaces I like all my routers to have loopback addresses. These are useful for things such as:

· OSPF router IDs

· BGP peering

· Pinging to see if a router is reachable

I like to add loopback interfaces even if they are not required. Often I will assign loopback addresses from the upper end of whatever range of addresses I am using.

For example, if I am working on a practice lab that calls for using the 128.128.0.0 address space, I would assign my loopback addresses as shown in Table 3: Sample Loopback Address Assignments:

Table 3: Sample Loopback Address Assignments

Router Loopback Address r1 128.128.201.1/24 r2 128.128.202.1/24 r3 128.128.203.1/24 r4 128.128.204.1/24



r5 128.128.205.1/24 r6 128.128.206.1/24

As you can see, this creates a simple addressing plan where the last digit of the third octet matches the router number. Since the upper range of the 128.128.0.0 space is being used, it is also unlikely a higher addressed loopback will be required by the practice lab (and thus changing an OSPF router ID, for example).

MPLS If you are new to MPLS, my recommendation is to understand the basic concepts of MPLS, understand the basic components (P, PE and CE routers) and understand the basic configuration steps. Once this is complete, more detailed concepts and configurations (QoS, MPLS features, MPLS BGP attributes, etc.) can be mastered (as time allows).

The 3825 and 1841 both support MPLS.

MPLS Overview Multiprotocol Label Switching (MPLS) provides many benefits, but in a nutshell it allows service providers to provision many virtual, private networks (MPLS VPNs) for customers using the same shared infrastructure (routers, switches and links).

VPNs are "private" networks, dedicated to a particular customer, that run across a shared infrastructure (the PE and P routers are shared by many customers). Each customer network is logically separated from all others, providing privacy and security.

MPLS utilizes label switching in the core. Effectively packets are routed using labels that are attached to the packets at the edge, rather than by the destination IP address (traditional routing). Each label corresponds to a particular PE router destination. Since there are far fewer PE routers in a network than destination IP networks, it is simpler and faster to switch packets within a service provider network based on labels than it is based on destination IP addresses. In more advanced MPLS implementations, labels can be assigned to the combination of destination PE router and QoS assigned to the path.

MPLS VPNs provide "any to any" connectivity, meaning all sites in the VPN have direct, virtual connectivity to all other sites - there is no longer a concept of a "hub" or central site (typical with Frame Relay). Once a site is connected to the MPLS 'cloud' it has full connectivity to all other sites.

Terminology



Given that MPLS is newer and more complex than many technologies I will briefly review common terminology:

CE Router - Customer Equipment router, or the router that is physically on the customer site. This can be provided by the customer or the service provider. It most often runs BGP with the PE router, but can also use RIP or static routing.

PE Router - Provider Edge router, a router that connects to many CE routers (CE routers of more than one customer). It runs label switching, routing packets within the provider network using labels. For outgoing packets, it strips the labels before forwarding to the CE Router.

P Router - Provider "core" router. This type of router only connects to other P and PE routers (no CE routers). It forwards packets using label switching.

MPLS was formerly known as "Tag Switching." As such you may encounter both the older 'tag' commands (such as &2(;4*!&+,!'( !") as well as the newer commands (such as <"?4 !"). Since IOS 12.4T and newer versions standardized on the "mpls" versions of the commands, we will only use those in this guide, however depending on your exact IOS version you may enter commands in the newer format, but the router may store them in NVRAM in the older format for backward compatibility.

Configuring MPLS In order to configure MPLS, you must enable MPLS on the interfaces that will run MPLS (<"?4 !"). Note that MPLS requires cef, so be sure !" +1.

is configured (it is enabled by default - just make sure it did not get disabled).

In order for routers to share MPLS label information, they must run a distribution protocol - either the label distribution protocol (ldp) or the tag distribution protocol (tdp). Since ldp replaces tdp, our examples (and our recommendation) is to use ldp. MPLS label sharing is enabled on each interface with the <"?4 !" interface command. If all interfaces run ldp (recommended), you can use the global <"?4 ?2F1? "#$&$+$? ?="

command as opposed to using that command on each interface. A router that runs ldp is known as a Label Switch Router (LSR). If two routers running ldp (LSRs) share the same subnet they will automatically discover each other and start sharing label information. If they are more than one hop away and they need to share labels, LSRs must be manually configured with the <"?4 ?=" '1!(,F$# &2#(1&1= command. Labels are created using an LSR's MPLS router-id. I recommend setting this to the loopback address with the <"?4 ?=" #$%&1#;!= ?$$"F2+R6 .$#+1

command. Optionally you can have LSRs authenticate by using the <"?4



?=" '1!(,F$# >#. +%4&$<1#@ @6H@H@H@ "244*$#= 1#223!*% command (where 10.1.1.1 is the neighbor address).

<"?4 ?2F1? "#$&$+$? ?=" <"?4 ?=" #$%&1#;!= ?$$"F2+R6 .$#+1 L !'&1#.2+1 M!(2F!&5&,1#'1&676 <"?4 !" L !'&1#.2+1 M!(2F!&5&,1#'1&67@ <"?4 !" L

You can limit the networks for which label switching is used as well as limiting which neighbors receive advertisements. The <"?4 ?=" 2=>1#&!41;?2F1?4 .$# # .> &$ # .? command limits the networks advertised to access-list acl1 and the neighbors to which they are advertised to access-list acl2.

Configuring Multiprotocol BGP Multiprotocol BGP is simply a specialized config within BGP. As such, it starts with the normal BGP config - #$%&1# F(" #2$, defining neighbors, etc. However for each MPLS BGP neighbor, the '1!(,F$# +1,#%%*)22

2+&!>2&1 command is required - "normal" IPv4 neighbors are active by default, but all others (including MPLS VPN neighbors) must be manually activated.

PE routers must run BGP with the other PE routers (PE-to-CE connections can run BGP, but can also use other protocols). PE neighbors running Multiprotocol BGP are defined with the configuration:

#$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' '1!(,F$# @6H@H@H@ #1<$&1;24 E866@ L 2==#144;.2<!?K >"'>Q '1!(,F$# @6H@H@H@ 2+&!>2&1 '1!(,F$# @6H@H@H@ 41'=;+$<<%'!&K 1W&1'=1= 1W!&;2==#144;.2<!?K

The '1!(,F$# 41'=;+$<<%'!&K enables the sending of BGP communities (off by default) and is only required if communities are going to be used. Although in the above example the 10.1.1.1 IP address can be replaced with a peer-group command, unless you are extremely familiar with peer groups I recommend against this approach, as it may add confusion!

PE routers are almost always in the same BGP Autonomous System, thus will run iBGP. As such a full mesh configuration, confederation or BGP



route reflector will be required. Just a reminder that the internal routing protocol (OSPF, etc.) provides connectivity between iBGP members.

Configuring MPLS VPNs A VPN is associated with one virtual routing and forwarding instance (VRF). Although a VPN can be associated with more than one VRF, for simplicity (sanity?!!) we will only consider examples where each VPN corresponds to exactly one VRF. Each VRF has its own routing table, IP CEF table, set of physical interfaces and a set of rules and parameters that control the routing information that contributes to the VRF's routing table. Typically each customer has its own VRF.

Unless specifically configured to do so, VRF's do not share routing information, which is how customers remain isolated despite sharing the same core infrastructure.

When routes (IP prefixes) are learned from customer networks (via static, BGP, RIP, etc.), a route distinguisher (RD) is added to the IP prefix by the PE router. Each customer (that is, each VRF) has a unique RD, making the combination of RD and IP Prefix completely unique, even if many customers use the same network (such as 192.168.1.0/24, for example). The RD is manually configured on each node that services a customer. Each customer has their own unique RD, and that RD is configured on any router that supports that customer.

To configure MPLS VPNs, follow the following steps: 1. Configure MPLS in the core (P, PE routers) - discussed in a previous section (above).

2. Configure Multiprotocol BGP in the core (P, PE routers) - discussed in the previous section (above).

3. Configure VRFs and RDs on PE routers; assign PE interfaces to VRFs (below).

4. Configure routing protocols between the PE and CE routers (below).

A VRF is defined simply with the command !" >#. -*:,$#"). In the lab you will need to configure one of these for each "customer VPN." As with anything in the lab, try to keep the VRF name simple, yet meaningful (if possible).Within the VRF, configure a Route Distinguisher that uniquely identifies the VRF and gets attached to all the VRF's routes with the #=

*!'/),%+2/+$7'+28)* command. For simplicity, I recommend making the rd in the format ASN:Number, where ASN is the BGP ASN assigned to the MPLS PE routers and the Number is tied to the vrf-name. Unless complex importing and exporting of routes is required, use the #$%&1;&2#(1& F$&,

*!'/),/#*7)/, !""'$+/0 command to allow routes to be passed within a



VRF. Finally, enable a particular interface (facing the CE) to be a member of that customer's VRF. For example:

Customer 1 Customer 2 !" >#. +%4&$<1#@ !" >#. +%4&$<1#N #= E8666J@ #= E8666JN #$%&1;&2#(1& F$&, E8666J@ #$%&1;&2#(1& F$&, E8666JN L L !'&1#.2+1 M676 !'&1#.2+1 M67@ !" >#. .$#*2#=!'( +%4&$<1#@ !" >#. .$#*2#=!'( +%4&$<1#N

PE to CE connectivity is most commonly accomplished by BGP, RIP or static routes (not much chance of those on the lab exam!) though it can also use OSPF or EIGRP. BGP and RIP examples are shown below. OSPF and EIGRP configs are similar to RIP, so they will not be included here - but should be practiced in your home lab!

BGP between the PE and CE requires an 2==#144;.2<!?K !">Q

configuration. The PE requires the >#. -*:,$#") keyword, as it will have many VRFs defined. The CE - a member of only one VRF - will not need this. On the PE the CE neighbor is configured, as are any other configuration specific to that CE/customer. PE router config:

#$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' L 2==#144;.2<!?K !">Q %'!+24& >#. +%4&$<1#@ '1!(,F$# @6HN88HN88H@ #1<$&1;24 EQ::: '1!(,F$# @6HN88HN88H@ 2+&!>2&1 '$ 4K'+,#$'!e2&!$' '$ 2%&$;4%<<2#K 1W!&;2==#144;.2<!?K

The CE has a similar config. It must either define network statements or use the redistribution command to advertise its routes:

#$%&1# F(" EQ::: '$ 4K'+,#$'!e2&!$' L 2==#144;.2<!?K !">Q '1&*$#R @UNH@EH6H6 <24R N88HN88H6H6 '1!(,F$# @6HN88HN88HN #1<$&1;24 E866@ '1!(,F$# @6HN88HN88HN 2+&!>2&1 '$ 4K'+,#$'!e2&!$' '$ 2%&$;4%<<2#K 1W!&;2==#144;.2<!?K

When a PE and CE exchange routes using RIP, the PE has an 2==#144; .2<!?K !">Q configuration with its RIP config:

L #$%&1# #!"



L 2==#144;.2<!?K !">Q >#. +%4&$<1#@ >1#4!$' N '1&*$#R @UNH@OH6H6 1W!&;2==#144;.2<!?K

On the CE router RIP is configured normally. Occasionally you may also see OSPF configured between the PE and CE. In that case the PE OSPF config is very similar to the PE RIP config shown above.

Multicast If you need to configure IP multicast on the exam, it is most likely you will need to configure PIM. Cisco has limited support for DVMRP (mostly interoperability). Cisco does not support Multicast OSPF (MOSPF).

Multicast uses class D destination addresses (addresses in the range 224.0.0.0 to 239.255.255.255). The range 224.0.0.0 to 224.0.0.255 is used by routing protocols and other control and administration traffic.

You may want to disable fast switching for IP multicast using the '$ !"

<#$%&1;+2+,1 interface command. In a production environment fast switching is probably preferred, but disabling fast switching allows debug messages to be logged - very helpful in a lab environment.

IGMP/CGMP IGMP (Internet Group Management Protocol) is the standard multicast protocol that controls hosts joining multicast groups (and thus determines where a router needs to forward multicast traffic). Periodically (such as once per minute) the router sends our IGMP requests (queries) and any host participating in multicast sends back an IGMP report, indicating the multicast group or groups (i.e., the multicast IP addresses) on which it is listening.

Since this protocol is typically used between a router and end stations (PCs), it is unlikely you will actually see this protocol in operation, though you may be required to configure and tune it on the router.

Typically routers forward traffic to multicast groups, but are not members of the groups themselves. However it can be useful to have a router join a particular multicast group.When it is a member of a group, it will respond to pings destined to that group's multicast address. This is very helpful way to determine if multicast routing is working in your network. Use the !" !(<" t$!';(#$%" ND6H6H6H@ interface command to force a router to join the 230.0.0.1 multicast group.



CGMP is Cisco's proprietary IGMP. It only goes between the router and the switch, telling the switch on what ports it needs to forward multicast traffic.

PIM IP Multicast routing is not enabled by default. Enable it using the !"

<%?&!+24&;#$%&!'( command.

PIM (Protocol Independent Multicast) is one of the leading multicast standards and Cisco's preferredmulticast routing protocol. PIM can operate in sparse mode, dense mode or sparse-dense mode.

In dense mode, multicast routers assume all other multicast routers and users want multicast flows. Thus by default multicast traffic is forwarded on all multicast interfaces. If a multicast router has no clients for a flow, it can optionally send a Prune message back toward the source to stop that flow (such as with an IGMP Leave message). Dense mode is designed for environments where there are a lot of multicast clients (users), and thus forwarding multicast traffic throughout the network is expected.

In sparse mode, multicast routers assume all other multicast routers and users do not want multicast flows. A multicast router (based on the requests it receives from users) or amulticast user must specifically request a flow, such as with an IGMP Report message. Spare mode is typically used where either there are few multicast clients or where bandwidth is limited. In either of these cases sparse mode is efficient since it will only transmit multicast packets to subnets where active multicast clients exist.

In sparse mode or dense mode, an interface acts that way for all multicast groups. A sparse-dense mode interface can operate in both sparsemode and dense mode, depending on the multicast group. Thus in sparse-dense mode the interface can act like sparse mode for certain multicast groups and dense mode for other multicast groups. If you enable sparse mode or sparse-dense mode you must configure a rendezvous point (RP), as discussed in the next section.

Once IP multicast is enabled globally, it must be enabled on each interface on which multicast will operate. In each case the mode must be specified: dense mode, sparse mode, or sparse-dense mode. Cisco strongly recommends sparse-dense mode, allowing the routers to determine how to forward multicast traffic.

Rendezvous Point (RP) A rendezvous point (RP) is used to track multicast routers and multicast sources. A sparse mode multicast network requires a default RP (such as



a statically defined RP, using the !" "!< #";2==#144 command on each multicast router). A sparse-dense mode multicast network does not - it can use Auto-RP to elect its own RP. Thus for simplicity I recommend using sparse-dense mode (with Auto-RP) as opposed to using multicast in sparse mode if given the choice.

If an RP is required (such as with sparse-dense mode), I recommend using one router as the RP for the entire multicast environment. The auto- RP feature will automatically announce this to all multicast routers. Use the commands below to configure a router to be eligible to be an RP. Make sure the access list covers all the multicast groups used in the multicast network:

!" "!< 41'=;#";2''$%'+1 1&,1#'1&676 4+$"1 @E (#$%";?!4& @ !!"##$%&#'()(*"+,&'(-./010101(10-220-220-22((

Alternatively more than one RP can be configured for a network. Two or more RP's can be configured, each for separate multicast groups. For example, r2 could be the RP for all 232.0.0.0/8 multicast groups and r3 could be RP for all 233.0.0.0/8 groups. Another approach is to make two or more RP's eligible to be the RP for the same groups. This provides redundancy for the RP. In this case configure the routers with the same access list (as shown above). However one router needs to elect the RP - this router is called the mapping agent. It "maps" RP's to multicast groups. Pick a router to be the mapping agent and configure it with the command:

&*(*&,(#"34$+*$4&#!56"+7(#!5*"()/((

DVMRP DVMRP (Distance Vector Multicast Routing Protocol) is not fully supported by Cisco. However Cisco does support PIM to DVMRP conversion, allowing it to send to and receive packets from a DVMRP router.

From a lab standpoint, I would briefly review DVMRP multicast operation and commands, but I would not spend too much time on it as it is not Cisco's preferredmulticast protocol (PIM is). Thus, spend most of your IP multicast time learning PIM (and IGMP/CGMP).

NTP For NTP configuration examples, see the CCIE Study Sheet on page 167.

Overview NTP is the primary method to synchronize clocks (or the "time") between Cisco routers and switches. All NTP devices (routers, servers, clocks, etc.) maintain a stratum number. This number indicates how many hops away from the time source (usually an atomic clock, etc.) the device is. So a device directly connected to an atomic clock would be stratum 1. A router



that synchronizes to that device would be stratum 2. A switch that synchronizes to the router would be stratum 3, etc.

In the "real world" (although we know that has no relevance to the CCIE Lab!) typically 1 or 2 routers in a network will peer with (and obtain time from) 2 or 3 public NTP timeservers. NTP provides a mechanism for the router to select the "best" (most accurate) time of all NTP devices to which it connects. There are many of these servers freely available on the Internet. All routers, switches and other devices within that network then peer with (and obtain time from) those 1 or 2 routers. This allows for very accurate time within the network, yet it does not overburden public timeservers, nor does it incur the security risks of dozens of devices using NTP to peer with Internet-based servers.

In the CCIE lab it is unlikely such a timeserver will exist. (Although if one does exist the configuration becomes easier - it is the same as discussed here, though without the need to define a "master" server). Although NTP does have broadcast capability I don't recommend it. The broadcast method is less efficient and (more importantly) more difficult to troubleshoot than statically configuring NTP peers.

NTP Modes NTP between devices can operate in one of two modes:

· Client-Server mode

· Peer (Symmetric) mode

In client-server mode one router is clearly the timeserver and will distribute time to other routers (but not accept time from any routers). In peer mode two routers compare which has the more authoritative (lower stratum) clock; the routers use the more authoritative time of the two.

In the CCIE lab (unless directed otherwise), I recommend using the client- server mode. In this mode you can choose one router to be your time (NTP) server and all other devices can be time (NTP) clients.

Basic Commands To synchronize the clock of two routers, use one of the following commands: Client-server mode: '&" 41#>1# @6H@6H:QH@ (on the client router)

Peer mode: '&" "11# @6H@6H:QH@ (on both routers)

In client-server mode, the server router does not require configuration if its clock is synchronized. If it is not, it needs the '&" <24&1# command, as described below.

Advanced Commands



By default a router will only synchronize to another router if that router is synchronized itself. In the CCIE Lab you may be asked to have all routers synchronize their clocks to one router within your network. Use the '&" <24&1# command to instruct a router to act as an NTP server (and distribute time) despite the fact that it does not have a synchronized clock.

A common NTP configuration is using access-lists to restrict what routers will participate in NTP. You can use the '&" 2++144;(#$%" 41#>1 @

command on the NTP server to restrict the clients that are served. In this example only devices that pass access-list 1 will be allowed to use this device as an NTP server.

By default a router will use the IP address of the outgoing interface when sending NTP packets. Especially if access-groups are used to restrict NTP access, it may be useful to instruct the router to use a loopback address when sending NTP packets. For example, to configure the router to use the loopback 0 address for NTP packets, use the '&" 4$%#+1 ?$$"F2+R 6

command.

To further restrict access to an NTP server (and to increase NTP security), NTP authentication can be configured. Use '&" 2%&,1'&!+2&1 to enable authentication, then use '&" 2%&,1'&!+2&!$';R1K and '&" &#%4&1=;R1K to define the authentication keys used by ntp.

OSPF If you have a partial mesh Frame Relay network (a very common scenario) and you are forced to use the non-broadcast OSPF network type (as opposed to the more favorable point-to-multipoint type) you will likely have to manually configure neighbors. In this case you will probably only need to define these at the hub router. Use !" $4". "#!$#!&K 6 at the remotes since you don't want them becoming the designated router since they will not be able to directly share the OSPF database with all of the spoke routers - the hub router is best positioned for this.

You don't need '$ 2%&$;4%<<2#K. OSPF does not summarize by default - you must configure summarization manually (see Summarization, below).

Even if your router is using a loopback address as its OSPF router ID, loopback networks won't be part of the OSPF process by default - they need to be added with the '1&*$#R statement, like any other interface. Loopback networks get defined as host routes (/32 mask) regardless of the "real"mask. However if you want the "whole loopback subnet" to be visible to the rest of the network, consider:

· Placing the loopback in its own area and summarizing:



!'&1#.2+1 ?$$"F2+R6 !" 2==#144 @:NH@EOHN8DH@ N88HN88HN88H6 #$%&1# $4". @ '1&*$#R @:NH@EOHN8DH6 6H6H6HN88 2#12 Q 2#12 Q #2'(1 @:NH@EOHN8DH6 N88HN88HN88H6

· Or (much easier!) defining the ospf network type as point-to-point:

!'&1#.2+1 ?$$"F2+R6 !" 2==#144 @:NH@EOHN8DH@ N88HN88HN88H6 !" $4". '1&*$#R "$!'&;&$;"$!'&

Network Types OSPF uses four network types as shown in Table 4: OSPF Network Types:

Table 4: OSPF Network Types

Network Type Hello/Dead Timer Is DR/BDR Example (seconds) Used?

Broadcast 10/40 Yes Ethernet Point-to-Point 10/40 No T1 using HDLC

or PPP Non-Broadcast 30/120 Yes Frame Relay,

ATM Point-to- 30/120 No Hub & Spoke Multipoint Frame Relay

My rule of thumb is this: always get the routers to agree on the OSPF network type. If they don't agree you're asking for problems. If the routers don't agree you can manually set the Hello and Dead timers to match, but then one router is looking to elect a DR/BDR (designated router/back-up designated router) while the other is not.

Broadcast and Non-broadcast network types elect a DR and a BDR. The DR is the router with the highest priority (highest priority number). This can be set with the !" $4". "#!$#!&K command. A priority of 0 means the router cannot become the DR or BDR. Except when needed (as in the aforementioned Frame Relay case) I almost never set the OSPF priority. On a typical Ethernet subnet I usually don't care which router becomes the DR.

The OSPF network type point-to-multipoint was specifically designed for NBMA networks (Frame Relay, etc.) This network type makes an NBMA network appear as though it is a group of point-to-point networks. Thus a "hub" router with three spoke routers in a multipoint Frame Relay configuration will "appear" as a hub router with three point-to-point connections to the three routers from an OSPF point of view. As



discussed earlier, point-to-point circuitsmake connectivity easier in almost every way.

d[ $4". '1&*$#R "$!'&;&$;<%?&!"$!'& is my preferred way to run OSPF over Frame Relay.

Cost (Metrics) The OSPF cost, or metric, of a route is the sum of the costs of all outgoing interfaces to reach the destination. By default each OSPF interface cost is 100 Mb/s divided by the speed of the interface. Fast Ethernets use a cost of 1, 10 Mb/s Ethernets use a cost of 10, 1.544 Mb/s T1s use a cost of 64, etc. Note that the router does not detectWAN port speeds automatically. Thus the F2'=*!=&, command must be used to specify the bandwidth. If no bandwidth is specified on aWAN port, the router assumes T1 speed (1.544 Mb/s).

The cost can be changed on an interface via the !" $4". +$4& interface command. To change the cost on all interfaces (such as increasing all costs by a factor of 10), use the 2%&$;+$4& #1.1#1'+1;F2'=*!=&, @666

command (where 1000 is in Mb/s and is used in place of 100 Mb/s in the formula discussed above). This is helpful if you have Gigabit (or 10 Gig) interfaces since otherwise they receive the same cost as 100 Mb/s interfaces - 1. Although it is unlikely you'll need this in the lab, I have used this in real life several times.

External Routes OSPF uses two types of external routes: external type 1 and external type 2. Type 1 routes increase their metric by the OSPF metric of a link when they cross that link (as discussed in the previous section). That is, their OSPF metric increases as they propagate through a network. Type 2 routes remain with a fixed metric regardless of how far they propagate through a network.

Networks for which OSPF is configured become OSPF internal routes. All other OSPF routes are OSPF external routes. Usually external routes are the result of redistribution from another protocol. By default redistributed routes become external type 2 routes. This can be overridden with the <1&#!+;&K"1 @ keyword in the redistribute command. Either type (type 1 or type 2) can be given an initial metric with the <1&#!+ keyword in the redistribute command. For type 2 routes, this will be their metric throughout the network since type 2 routes do not change their metric. For type 1 routes this will be the "starting" metric that gets increased with every link.

Router ID



Each OSPF router uses a router ID to identify itself to other routers.When the OSPF process is started (with the #$%&1# $4". command) or when the router is booted it selects a router ID. The router uses the following criteria to select its router ID: 1. The router will select the highest IP address of all loopback interfaces.

2. If no loopback interfaces exist, the router selects the highest IP address of all interfaces.

As you can see, if there are no loopback interfaces the router selects the highest IP address of all interfaces as its router ID. Then if a loopback address is added later, then the router booted, the router will change its router ID to the (highest) loopback IP address.

Changing the router ID can "break" OSPF virtual links as they reference a router's router ID. To avoid this create all loopback interfaces before configuring OSPF. The OSPF router ID can also be set (with more recent versions of IOS) with the #$%&1#;!= router command, though this is not too common.

Distance Using the =!4&2'+1 $4". router command you can set distances for:

· intra-area routes (OSPF routes that are in that router's area)

· inter-area routes (OSPF routes that are from a different area)

· external OSPF routes

This can control what routes the router chooses to place in the routing table. I recommend leaving these at the default unless you are required to change them. If you are required to change them, I recommend setting them all the same (if possible).

Summarization When you use an 2#12 @ #2'(1 command it will summarize all OSPF internal routes, but none of the OSPF external (type 1 or 2) routes. This is usually done on the ABR for whatever area is being summarized.

When you use the 4%<<2#K;2==#144 @UNH@UH6H6 N88HN88H6H6 command, it does the opposite: it summarizes all OSPF external routes but none of the internal OSPF routes. It also only works on routers that are the ASBR for the external routes being summarized. Also, the summary advertisement seems to be an external type 2 route, with the metric being the lowest of the routes within that range.

However the OSPF 4%<<2#K;2==#144 command can also summarize external (type 1 or type 2) OSPF routes that are being redistributed into another protocol from OSPF. This can be very useful for protocols such as RIP, which are bound by FLSM (fixed length subnet masking). For



example, OSPF can use the 4%<<2#K;2==#144 command to summarize many /27 OSPF networks into a single /24 to advertise into the RIP domain which uses a /24 mask. This command is entered on the ASBR between the OSPF and the RIP domain.

Stub and NSSA Areas When configuring a stub or NSSA area, all routers in the area must agree on the stub or NSSA setting.

Table 5: OSPF Stub and NSSA Area

Area Type Gets External Gets Inter- Gets a default Can generate routes? Area Routes? route? Ext Routes?

area 1 stub no yes yes no area 1 stub no- no no yes no summary area 1 nssa no yes no yes area 1 nssa no- no no yes yes summary

Use a stub area (2#12 @ 4&%F) to block external (type 1 and type 2) routes from being sent to the stub area. Use a stub area with no summary (2#12 @ 4&%F '$;4%<<2#K) to block all OSPF routes except those from within that area (this commands blocks inter-area routes, external type-1 routes and external type-2 routes).

Use an NSSA area when you want to block external (type 1 or type 2) routes from being sent to the area (NSSA areas do not get OSPF external routes) but you want the area to be able to originate external routes, such as from redistribution. NSSA external routes can be summarized by the router that connects between the NSSA area and the backbone.

Virtual Links You do need to have every OSPF ABR (Area Border Router) connect to area 0, either directly or through a virtual link.When setting up virtual links, the area defined (in the 2#12 @ >!#&%2?;?!'R @8QH@EHDNH@

command) is the area through which the virtual link will traverse.When configuring the virtual link, you must use the router id of the router at the other end of the virtual link.

If area 0 is using authentication, you must add either the 2%&,1'&!+2&!$';

R1K or <1442(1;=!(14&;R1K to the 2#12 $ >!#&%2?;?!'R command. Additionally you must add 2#12 6 2%&,1'&!+2&!$' f<1442(1;=!(14&g to all routers in area 0 including the router at the "far" end of the virtual link (even though it doesn't really "touch" area 0 - it only connects via the virtual link).

For the following network:



A@ ;;; 2#12 6 ;;; AN ;;; 2#12 @ ;;; AD ;;; 2#12 N ;;; AQ ;;; 2#12 D

R3 needs a virtual link to R2 and R4 needs a virtual link to R3.

Graceful Restart OSPF Graceful Restart (also known as Non-Stop Forwarding, or NSF) is enabled by default on the 3560 and cannot be configured. If its OSPF neighbor is NSF aware, the 3560 will use NSF.

For routers NSF can be configured in two ways - Cisco NSF or IETF NSF:

#$%&1# $4". @ '4. +!4+$

Or:

#$%&1# $4". @ '4. !1&.

The '4. !1&. command has an optional keyword of f#14&2#&;!'&1#>2?

2) !$%2g that will specify the length of the graceful restart.

The 3560 uses the IETF version of NSF, so if you are given the choice (or if both routers and switches in your lab need to run NSF) use the '4. !1&.

command on your routers.

Prefix Lists The way prefix lists work are you can specify a network and mask or a network and a range of masks. Specifying a network and mask is fairly simple:

!" "#1.!W;?!4& <K?!4& 41S @6 "1#<!& @UNH@EHN8H67NQ

This will allow (match) the exact network 172.16.25.0/24 to pass the list. Prefix lists can also specify a range of networks (very useful) using the (1

and ?1 keywords. The keyword (1 matches a mask that is greater than or equal to the network specified. The keyword ?1 matches a mask smaller than or equal to the one specified.

So (1 NU ?1 D6 indicates masks greater than or equal to /27 and less than or equal to /30: /27, /28, /29 and /30 (255.255.255.224 through 255.255.255.252).

In this following example:



!" "#1.!W;?!4& <K?!4& 41S @6 "1#<!& @UNH@EH6H67@E (1 NQ ?1 NE

This will take the entire class B network 172.16.0.0 (172.16.0.0/16) and pass only subnets with a /24, /25 or /26 mask (ge 24 le 26). So the exact network 172.16.0.0/16 would actually fail the list because it does not have a mask of /24, /25 or /26.

By default if you only specify "ge" then any subnet with a mask greater than or equal to the ge value will pass. That is, ge all the way up to /32. For example:

!" "#1.!W;?!4& <K?!4& 41S @6 "1#<!& @6H@6H@6H67NQ (1 NO

This list specifies any subnet within the 10.10.10.0/24 range that has a mask of /28 or greater (255.255.255.240à 255.255.255.255). Again, the exact subnet 10.10.10.0/24 would fail because it does not have a mask of /28 or greater.

By default if you only specify "le" then any subnet with a mask less than or equal to the le value but greater than or equal to the mask specified will pass. That is, le all the way down to the mask listed. For example:

!" "#1.!W;?!4& <K?!4& 41S @6 "1#<!& @6HEQH6H67@E ?1 ND

This list specifies any subnet within the 10.64.0.0/16 range that has a mask between /16 and /23, inclusive (255.255.0.0à 255.255.254.0). In this case the exact subnet 10.64.0.0/16 would pass because it has a mask in the range /16à /23.

The prefix list command:

!" "#1.!W;?!4& 2??$*;!' 41S @6 "1#<!& @6H@6H@NOH67@: (1 ND ?1 NQ

would have the following effect:

· 10.10.128.0/23 would pass · 10.10.159.0/24 would pass · 10.10.140.0/23 would pass · 10.10.160.0/24 would fail (not in range of 10.10.128.0/19) · 10.10.148.0/22 would fail (not within ge 23 le 24) · 10.10.127.192/26 would fail (not within the range and not the correct mask)

The "permit any any" in a prefix list is:

!" "#1.!W;?!4& <K?!4& 41S N66 "1#<!& 6H6H6H676 ?1 DN



Prefix lists are my preferred way to filter routing updates. I feel they are extremely powerful. Once you become familiar with them they are easy to use.

Quality of Service

Class of Service, IP Precedence and DiffServ Code Points This section provides little information that you will configure during the exam, but it provides important background information for other QoS concepts.

The phrase "Class of Service" is used in many ways. One common use of the phrase is to describe a particular level of service, such as the classes of service defined by the IP Precedence bits (see below). Another use is to define a level of priority in a layer 2 header. The 802.1p standard dictates bits for use in defining Class of Service (CoS). The 802.1p and 802.1q standards are commonly used on layer 2 trunk links. 802.1p defines priority of packets using the CoS bits. 802.1q defines a tagging standard, allowing more than one VLAN (or subnet) to be carried separately across one physical link.When the CoS bits are set in an 802.1p header a layer 2-only device (such as a switch) can still apply priority to certain packets since they understand and adhere to the CoS value (whereas they likely do not always understand the layer 3 IP Precedence or DSCP field).

IPv4 contains an 8-bit Type of Service (ToS) field in its header. Three of these eight bits form the IP Precedence bits, providing six different classes of service (two levels are reserved), as shown in Table 6: IP Precedence Classes. Once these bits are set other devices throughout the network can assign a level of service (low latency, etc.) based on the three IP Precedence bits. For exampleWeighted Fair Queuing (WFQ) and Weighted Random Early Detection (WRED) can both use IP Precedence bits to determine how to treat packets.

Table 6: IP Precedence Classes

IP Precedence Bits Name of Service Class 0 (000) routine 1 (001) priority 2 (010) immediate 3 (011) flash 4 (100) flash-override 5 (101) critical 6 (110) internet control (reserved) 7 (111) network control (reserved)



The DiffServ Code Point (DSCP) uses (and replaces) the Type of Service (ToS) field in the IPv4 header. The eight bits of the IPv4 Type of Service field are:

· the three IP Precedence bits (discussed earlier in this section) · one bit for 'low delay' · one bit for 'high throughput' · one bit for 'high reliability.'

The last two bits of the ToS field are not used. DSCP uses these first six bits to define its levels of service, also known as forwarding classes.

Table 7: DSCP Classes

DSCP Value Forwarding Class Default Forwarding 000000 Assured Forwarding - Class 1 - 4 001010 through 100110 Expedited Forwarding 101110

IPv6 (for those of you who are really optimistic!) has a 'Traffic Class' field that is very similar to the IPv4 Type of Service field. This field also contains bits used to prioritize traffic. DSCP also replaces this field with its own information.

Classification and Marking Classification is identifying a packet based on some criteria and assigning it to a group that can be given a particular class of service. Classification uses a class-map and a match command to identify (match) traffic:

+?244;<2" 42<"?1 <2&+,;2'K <2&+, =4+" 1.

More than one match command can be included in a class-map. In that case the <2&+,;2'K or <2&+,;2?? keyword determines whether just one or all of the match statements must be true to qualify as a match. Classification can match on any of the following match commands:

<2&+, 2++144 (#$%" <2&+, !" #&" <2&+, "#$&$+$? +!&#!W

<2&+, 2'K <2&+, <"?4 <2&+, "#$&$+$?

<2&+, +?244;<2" 1W"1#!<1'&2? .24&&#2+R

<2&+, +$4 <2&+, <"?4 <2&+, "#$&$+$?

<2&+, =14&!'2&!$'; 1W"1#!<1'&2? &$"<$4& ('%&1??2 2==#144 <2+ <2&+, '$& <2&+, "#$&$+$? ,&&"

<2&+, =!4+2#=;+?244 <2&+, "2+R1& ?1'(&, <2&+, "#$&$+$? #&"

<2&+, =4+" -+?244;<2"/ <2&+, S$4;(#$%"

<2&+, .!1?= <2&+, "$#&;&K"1 <2&+, 4$%#+1;2==#144

<2&+, .#;=1 <2&+, "#1+1=1'+1 <2+

<2&+, .#;=?+! <2&+, "#$&$+$? <2&+, 4&2#&

<2&+, !'"%&;!'&1#.2+1 <2&+, "#$&$+$? -YGXA/ <2&+, &2( -+?244;<2"/



<2&+, >?2' -]$)/

Marking is changing or setting part of the packet, allowing it to be easily recognized throughout the network so that a class of service can be applied. Marking can be done by:

· Setting the IP Precedence, ToS or DSCP bits in the IP header

· Setting the Class of Service (CoS) bits in the layer 2 802.1p header

· Setting the Frame-Relay Discard Eligible (DE) bit

· Associating a local QoS group value with the packet

Setting the IP Precedence or DSCP bits is very effective since once these values are set, by default, layer 3 devices adhere to but do not alter them. These also determine howWeighted Random Early Detection (WRED) treats packets in a congestion situation.

Setting the CoS value is not as useful since it is not maintained from end- to-end throughout the network - it gets removed when the 802.1p header is stripped. However it is very useful for marking (and thus prioritizing) traffic on a trunk link, switch-to-switch link or router-to-switch link. DSCP values can also get mapped based on CoS values, making the marking more permanent.

Setting the DE bit is useful, though only applies to traffic being sent over a Frame-Relay network.

Setting a local QoS group is useful to classify packets within a router (not between routers). This classification can be made based on parameters such as IP prefix, autonomous system and BGP community values.

Marking is performed with a policy-map, using classes already defined (classification). Marking can be performed with set commands:

"$?!+K;<2" `2##!$#4 +?244 4<&";+?244 41& !" "#1+1=1'+1 8 +?244 "$";+?244 41& !" =4+" 1.

Or using a pre-defined mapping table, where one attribute (such as CoS) is directly mapped to another (such as DSCP):

"$?!+K;<2" <2";+$4;&$;"#1+1=1'+1 +?244 <K;+?244 41& +$4 "#1+1=1'+1 &2F?1 +$4;&$;"#1+1=1'+1;&2F?1 L &2F?1;<2" +$4;&$;"#1+1=1'+1;&2F?1 <2" .#$< 6 &$ D <2" .#$< @ &$ D



<2" .#$< N &$ 8 <2" .#$< D &$ 8 L 1&+H

The policy-map is then applied to an interface.

Congestion Management Congestion management techniques allow you to control congestion by determining the order in which packets are sent out an interface based on priorities assigned to each packet. Congestion management includes:

· Creating queues

· Using classification to assign packets to queues

· Scheduling packets in a queue for transmission

IOS provides four broad types of queuing (congestion management) techniques:

· First In, First Out (FIFO)

· Weighted Fair Queuing (WFQ) · Custom Queuing (CQ)

· Priority Queuing (PQ)

First In, First Out is by far the simplest queuing mechanism. Packets are sent out an interface in the order they are received. No preferential treatment is administered, no bandwidth is reserved. Although FIFO sounds almost overly simplistic, on higher speed interfaces (over T1/E1) it is the default. This is mostly because it is extremely easy for the router to process packets and the average wait or delay on these interfaces is usually very low.

Weighted Fair Queuing actually includes four different variations:

· Flow-BasedWeighted Fair Queuing (WFQ)

· Class-BasedWeighted Fair Queuing (CBWFQ)

· DistributedWeighted Fair Queuing (DWFQ)

· Distributed Class-BasedWeighted Fair Queuing (DCBWFQ)

The first two types are designed for the standard IOS routers. The distributed types are simply the same implementations as the non- distributed types, but designed for the Route Switch Processor (7000 series) or the Versatile Interface Processor (VIP) (7500 series). In this guide unless otherwise notedWFQ will denote bothWFQ and DWFQ. Similarly CBWFQ will be used to mean CBWFQ and DCBWFQ.

With WFQ the router identifies and sorts traffic into flows, or conversations. Each flow is assigned a weight, which effectively acts as that flow's priority. The weight can be set by:

· IP Precedence of the packet

· RSVP



· Traffic of the flow (lower traffic rates get higher weight) · Frame Relay BECN, FECN and DE

The router cycles through all flows, servicing them in proportion to their weight. The router automatically sorts traffic based on many attributes, such as source and destination network or MAC address, protocol, source and destination port and socket numbers of the session, Frame Relay data-link connection identifier (DLCI) value, and ToS value. IP Precedence is part of the ToS value, andWFQ will adhere to this setting. It will give higher weights to flows with higher IP Precedence values.

The router identifies traffic as either low-volume flows (usually interactive traffic) or high-volume flows (usually file transfers or database operations). WFQ gives preferential treatment to low-volume traffic since this is usually the traffic users are waiting for when using their applications.

WFQ will adapt to changing network conditions, since it is constantly evaluating and sorting flows.

CBWFQ is similar to WFQ, but instead of the router automatically identifying and sorting flows, the administrator can manually configure classes of traffic based on protocols, access control lists, and input interfaces. CBWFQ allows the administrator to customize each class, such as defining the guaranteed bandwidth or maximum packet limit.

Once a queue has reached its maximum packet limit, any additional packets for that queue will be dropped. The user can decide whether the default, tail drop, will be used (packets at the end (or tail) of the queue that won't fit in get dropped). The alternative to this is to useWeighted Random Early Detection (WRED) to drop excess packets.

To configure CBWFQ, first identify the traffic using a class-map. Then use a policy map to identify that class and add a F2'=*!=&, command to limit the bandwidth used by that traffic:

"$?!+K;<2" #1<$&1 +?244 $..!+1;&#2..!+ F2'=*!=&, 8@N -!' RF74 $# K$% +2' 4"1+!.K "1#+1'& F2'=*!=&,/

You can also customize the policy by limiting the size of the queue (S%1%1;

?!<!&) as well as other modification.With CBWFQ, you can define as many classes as you'd like, each with their own bandwidth configuration.

Low Latency Queuing (LLQ) is a part of CBWFQ - it introduces strict priority queuing (for traffic such as voice and video) within CBWFQ. Class- maps are still used to identify traffic and a policy-map is used with the class included. However rather than using the F2'=*!=&, command, one class can be configured with the "#!$#!&K command. This specifies the



class and the bandwidth that is strictly reserved for it - not weighted fair, as the other classes in the policy map will receive. You can either specify the bandwidth as Kb/s ("#!$#!&K UEO for 768 Kb/s) or as a percentage of the link ("#!$#!&K "1#+1'& N8 for 25%). Here the voice traffic is given a strict allocation of 256 Kb/s, whereas two other classes are assigned 512 Kb/s and 64 Kb/s - but bandwidth in those classes will employ CBWFQ:

"$?!+K;<2" ??S;1W2<"?1 +?244 >$!+1;1'2F?1= "#!$#!&K N8E +?244 R1K;2""?!+2&!$';&#2..!+ F2'=*!=&, 8@N +?244 ?$*;F*;2""?!+2&!$';&#2..!+ F2'=*!=&, EQ L

Custom Queuing provides up to 16 queues for traffic (if you are using anywhere near 16 queues your configuration is more complicated than it needs to be!) Each queue is serviced in a round-robin fashion, with the router moving from one queue to the next, to the next. The administrator specifies how many bytes are sent from each queue before the router should move onto the next queue. If any queue is empty, the router immediately moves onto the next queue. The router maintains one queue for system traffic (keepalives, etc.) that is emptied before any other queue.

With CQ you do not specify a percentage of bandwidth, you specify a byte count for each queue. However this can indirectly be a percentage of bandwidth. For example, suppose you define three queues. If you specify byte counts of 2000 bytes, 1000 bytes and 1000 bytes, the queue with 2000 bytes will get 50% of the bandwidth (2000 out of every 2000+1000+1000=4000 bytes) and the other queues will get 25% each. Setting the byte count too high can result in delays for the other queues. For example, setting a byte count to 7500 bytes could result in five 1500 byte packets being sent. This could require 94 mS per packet (on a 128 Kb/s link). This could result in that queue sending 5 packets at 94 mS each - almost half a second of time just to service that queue!

Priority Queuing uses just four queues - high, medium, normal and low. This is the priority order of the four queues. The highest queue with traffic to send is always serviced first. Thus if the high priority queue has enough traffic to fill a link, the other three queues will never send a packet! The administrator uses filters to place packets into one of the four queues. Packets that do not match any list are placed in the normal queue. Packets can be classified by the following criteria:

· Protocol or subprotocol type

· Incoming interface

· Packet size

· Fragments



· Access list

Packets are filtered and sorted by the router's processor. This causes a slight delay in the handling of each packet. On low speed interfaces this small delay is usually acceptable (especially compared to the benefit PQ provides). On higher speed interfaces this delay may be unacceptable.

Each queue does have a limit on the number of packets that can be in the queue. This is especially helpful for the lower queues, as packets may build up there, waiting for transmission. In the case of long delays in the lower queues, the application is probably resending the data anyway - so the router is better off dropping the packets.

Keepalives are always placed in the high priority queues. Other important system traffic (OSPF hellos, CDP, etc.) needs to be manually configured.

Custom Queuing and Priority Queuing are statically configured - they do not adapt to changing conditions the wayWFQ and CBWFQ do.

Policing and Shaping Policing and shaping are both traffic regulation techniques that typically evaluate traffic in the same way. Policing and shaping treat violations of traffic policy differently - policing tends to drop the packets, whereas shaping tends to delay the packets by holding them in a buffer before queuing them. This slows down the flow of traffic.

Policing benefits QoS by preventing certain sources or applications from taking too much bandwidth (or more bandwidth than was agreed upon). Shaping helps QoS by slowing traffic when an interface gets congested. Slowing traffic is often more efficient than dropping it. Dropped packets usually get retransmitted (adding to the interface congestion, though possibly at a slower rate). Delaying packets prevents the retransmission problem but also tends to slow down traffic, easing congestion.

Configuring Policing Policing is applied when a strict limit needs to be set on traffic (or on certain types of traffic) on a particular interface. Policing is configured by:

· Creating a traffic class to define the type of traffic to be policed (+?244;<2")

· Creating a traffic policy ("$?!+K;<2") to define the actions to be taken on the traffic ("$?!+1)

· Applying the policy to an interface (41#>!+1;"$?!+K)

+?244;<2" "$";1<2!? <2&+, 2++144;(#$%" @66 L "$?!+K;<2" ?!<!&;1<2!?



+?244 "$";1<2!? "$?!+1 @NO666 @E666 DN666 +$'.$#<;2+&!$' &#2'4<!& 1W+11=;

2+&!$' 41&;S$4;&#2'4<!& D >!$?2&1;2+&!$' =#$" L !'&1#.2+1 41#!2? 676 41#>!+1;"$?!+K !'"%& ?!<!&;1<2!? L 2++144;?!4& @66 "1#<!& &+" 2'K 2'K 1S "$"D

The class-map uses an access list to define the type of traffic to be policed (use <2&+, 2'K in the class-map or an !" 2'K 2'K in the access-list to police all traffic). The policy-map uses the traffic defined by the class-map and defines how the traffic will be treated (transmitted, dropped, change the QoS, precedence or DSCP value). The service-policy applies the policing policy to a given interface.

Traffic Shaping Traffic shaping allows you to control traffic going out an interface. This can be done to match the speed of a remote connection or remote portion of the network, to adhere to a policy or to restrict certain types of traffic. Traffic shaping can be more useful than policing, since it shapes traffic by delaying it, whereas policing drops excess traffic. Dropped traffic often is simply retransmitted, creating inefficiency.

There are four types of traffic shaping: 1. Generic Traffic Shaping (GTS) 2. Class-based Traffic Shaping 3. Distributed Traffic Shaping (DTS) 4. Frame Relay Traffic Shaping (FRTS)

DTS is similar to GTS but primarily targeted at distributed architectures - such as the VIP processors used on 7500 routers, etc. - thus you will not see any DTS.

All four methods use similar methods to determine whether a packet can be forwarded or whether it must be delayed. If a packet must be delayed GTS and Class-based Shaping use a weighted fair queue to delay the traffic. FRTS uses either a weighted queue, a custom queue or a priority queue to hold delayed traffic, depending on how it is configured.

GTS applies traffic shaping to an entire interface or to traffic based on access control lists (ACLs). Class-based shaping applies shaping to classes. Classes can be defined based on ACLs, input interfaces, protocols, etc. Shaping can be defined uniquely on each class.

FRTS can apply shaping to individual VC's (PVCs or SVCs) that are assigned to a subinterface. In this case if a subinterface does not have any shaping configured, it will inherit the shaping on the main interface (if



any is configured there). Any shaping configuration on the subinterface will override the shaping configured on the main interface.

GTS is applied to interfaces (or subinterfaces). FRTS can be applied on a per-DLCI basis. Class-based shaping is applied to a class (or, occasionally, on an interface).

A variable that you should be familiar with for traffic shaping is Bc. This is known as the "committed burst" (thus the Bc) of traffic a router can send. That is, this is the burst of traffic that a router transmits that the network (such as a Frame Relay network) is committed to accept and deliver. This is directly related to the Committed Information Rate (CIR) - the CIR is simply Bc divided by time. For example if the CIR is 128 Kb/s and the router's sampling period is 1 second then Bc = 128,000 bits.

Another variable used in traffic shaping is Be. This is the "excess burst" (thus the Be) that the router can send that the network will accept but is not committed to deliver. It will mark this traffic discard eligible (set the DE bit) and will give a best effort to deliver this traffic, but may drop this traffic upon congestion.

The total amount of traffic the router can transmit in any given sampling period is the committed burst plus the excess burst (Bc plus Be).

Configuring Traffic Shaping To configure Generic Traffic Shaping (GTS) on all traffic on an interface for 128 Kb/s (with a burst of 32 Kb/s): !'&1#.2+1 41#!2? 676 &#2..!+;4,2"1 #2&1 @NO666 DN666

To configure GTS on an interface to limit the traffic caused by POP3 email to 500 Kb/s (all other (non-POP3) traffic will not be restricted at all): !'&1#.2+1 41#!2? @76 &#2..!+;4,2"1 (#$%" @68 866666 L 2++144;?!4& @68 "1#<!& &+" 2'K 2'K 1S "$"D 2++144;?!4& @68 "1#<!& &+" 2'K 1S "$"D 2'K

To configure Class-based Traffic Shaping: +?244;<2" N8ER <2&+, 2'K L "$?!+K;<2" ,$%4&$' +?244 N8ER 4,2"1 2>1#2(1 N8E666 L !'&1#.2+1 41#!2? @ 41#>!+1;"$?!+K $%&"%& ,$%4&$'



To configure Frame Relay Traffic Shaping create a class with the <2"; +?244 command. Apply the <2";+?244 to an interface, subinterface or DLCI using the +?244 command (or the .#2<1;#1?2K +?244 command, depending on the config mode you are in).

For example, subinterfaces s1.2 and s1.3 do not have any shaping configured and inherit the main interface shaping (configured for a 384K PVC). S1.1 has shaping configured on the subinterface for a 512K PVC. S1.4 has individual shaping configured on the DLCI - for a 256K PVC:

!'&1#.2+1 )1#!2?@ 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K +?244 DOQiZPI4 .#2<1;#1?2K &#2..!+;4,2"!'( L !'&1#.2+1 )1#!2?@H@ "$!'&;&$;"$!'& .#2<1;#1?2K +?244 8@NiZPI4 .#2<1;#1?2K !'&1#.2+1;=?+! @6@ L !'&1#.2+1 )1#!2?@HN "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! @6N L !'&1#.2+1 )1#!2?@HD "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! @6D L !'&1#.2+1 )1#!2?@HQ "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! @6Q +?244 N8EiZPI4 L <2";+?244 .#2<1;#1?2K DOQiZPI4 .#2<1;#1?2K &#2..!+;#2&1 DOQ666 DOQ666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L <2";+?244 .#2<1;#1?2K 8@NiZPI4 .#2<1;#1?2K &#2..!+;#2&1 8@N666 8@N666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L <2";+?244 .#2<1;#1?2K N8EiZPI4 .#2<1;#1?2K &#2..!+;#2&1 N8E666 N8E666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L

The map-classes also let you configure many other characteristics, such as custom queuing, priority queuing, weighted fair queuing, committed and excess burst sizes, etc.

RSVP The Resource Reservation Protocol (RSVP) is an end-to-end signaling protocol. That is, (ideally) all elements in the network must support it. A host uses RSVP to reserve network bandwidth and other resources across all network devices to meet its QoS needs before any traffic is sent.



RSVP is enabled on an interface with the !" #4>" F2'=*!=&, @+$/)*:# ),

A(12B&@2+$7.),:.!3,A(12B command. Interface-kbps limits the amount of bandwidth that can be reserved with RSVP and single-flow-kbps limits the amount of bandwidth that can be reserved by a single reservation (flow).

QoS Overview Here is a good overview of the QoS tools offered by Cisco IOS. I've included a few other, less commonly used QoS techniques for reference:

FIFO: default, no config necessary

WFQ: !'&1#.2+1 41#!2? 6 .2!#;S%1%1

CBWFQ: +?244;<2" )2#24$&2;&#2..!+

<2&+, 2++144;(#$%" @6@ !

<2&+, !'"%&;!'&1#.2+1 41#!2? @ ! <2&+, "#$&$+$? !" L "$?!+K;<2" 42#24$&2 +?244 )2#24$&2;&#2..!+ F2'=*!=&, DOQ -!' RF74 $# K$% +2' 4"1+!.K "1#+1'& F2'=*!=&,/ S%1%1;?!<!& N6 #2'=$<;=1&1+& -!. %4!'( À5m #2&,1# &,2' &,1 =1.2%?&T &2!? =#$"/ L !'&1#.2+1 41#!2? Q7@ 41#>!+1;"$?!+K $%&"%& 42#24$&2

CQ: !'&1#.2+1 41#!2? @7@ +%4&$<;S%1%1;?!4& @ L S%1%1;?!4& @ "#$&$+$? !" @ &+" ND -BI[ "$#& ND &$ S%1%1 @/ S%1%1;?!4& @ "#$&$+$? !" N &+" O6 -BI[ "$#& O6 &$ S%1%1 N/ S%1%1;?!4& @ "#$&$+$? !" D ?!4& @66 -XIC @66 &$ S%1%1 D/ S%1%1;?!4& @ S%1%1 @ ?!<!& N6 -<2W N6 "2+R1&4 !' S%1%1 @/ S%1%1;?!4& @ S%1%1 N FK&1;+$%'& @666 -FK&1 +$%'& @666 !' S%1%1 N/

PQ: "#!$#!&K;?!4& N "#$&$+$? !" ,!(, ?!4& 8 or "#!$#!&K;?!4& N !'&1#.2+1 1&,1#'1& @76 ?$* or "#!$#!&K;?!4& N "#$&$+$? !" <1=!%< %=" @E@ L !'&1#.2+1 41#!2? @76 "#!$#!&K;(#$%" N L 2++144;?!4& 8 "1#<!& @:NH@EOH@H6 6H6H6HN88

LLQ:



+?244;<2" >$!+1;1'2F?1= <2&+, 2++144;(#$%" @86 L "$?!+K;<2" ",$1'!W +?244 >$!+1;1'2F?1= "#!$#!&K @NO L !'&1#.2+1 41#!2? @ 41#>!+1;"$?!+K $%&"%& ",$1'!W L 2++144;?!4& @86 "1#<!& %=" 2'K #2'(1 @EDOQ DNUEO 2'K 2++144;?!4& @86 "1#<!& %=" 2'K 2'K #2'(1 @EDOQ DNUEO

IP RTP Priority: !'&1#.2+1 41#!2? 67@ !" #&" "#!$#!&K 2/#*/+$7,1!*/,$'"()*&1!*/,$'"()*,*#$7)&(#$%3+%/8

CAR: !'&1#.2+1 41#!2? 67@ #2&1;?!<!& !'"%& @NO666 @6666 N6666 +$'.$#<;2+&!$' &#2'4<!&

1W+11=;2+&!$' =#$"

Classification and Marking: +?244;<2" &1?'1&;+?244 <2&+, 2++144;(#$%" '2<1 &1?'1& +?244;<2" *1F;+?244 <2&+, 2++144;(#$%" '2<1 *** L "$?!+K;<2" 42?1< +?244 &1?'1&;+?244 41& !" "#1+1=1'+1 8 +?244 *1F;+?244 41& !" =4+" 1. L !'&1#.2+1 41#!2? @7@ 41#>!+1;"$?!+K !'"%& 42?1< L !" 2++144;?!4& 1W&1'=1= &1?'1& "1#<!& &+" 2'K 2'K 1S &1?'1& !" 2++144;?!4& 1W&1'=1= *** "1#<!& &+" 2'K 2'K 1S *** L

Policing: +?244;<2" .&" <2&+, 2++144;(#$%" @6@ L "$?!+K;<2" ?!<!&;.&" +?244 .&"

"$?!+1 N8E666 DN666 DN666 +$'.$#<;2+&!$' &#2'4<!& 1W+11=;2+&!$' =#$" >!$?2&1;2+&!$' =#$"

L !'&1#.2+1 41#!2? 676 41#>!+1;"$?!+K !'"%& ?!<!&;.&" L



2++144;?!4& @6@ "1#<!& &+" 2'K 2'K 1S .&";=2&2

WRED: !'&1#.2+1 41#!2? 6 #2'=$<;=1&1+&

FRED: !'&1#.2+1 41#!2? @ #2'=$<;=1&1+& #2'=$<;=1&1+& .?$* #2'=$<;=1&1+& .?$* +$%'& @E #2'=$<;=1&1+& .?$* 2>1#2(1;=1"&,;.2+&$# O

Compressed IP RTP (CRTP): !'&1#.2+1 41#!2? 676 !" #&" ,12=1#;+$<"#144!$'

!'&1#.2+1 41#!2? 676 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K <2" !" @6H@6H6H@ @U F#$2=+24& #&" ,12=1#;+$<"#144!$'

Link Fragmentation and Interleaving (LFI) for Multilink PPP (MLP): !'&1#.2+1 >!#&%2?;&1<"?2&1 @ !" %''%<F1#1= ?$$"F2+R 6 """ <%?&!?!'R """ <%?&!?!'R !'&1#?12>1 """ <%?&!?!'R .#2(<1'&;=1?2K D6 L <%?&!?!'R >!#&%2?;&1<"?2&1 @

LFI for Frame Relay: !'&1#.2+1 )1#!2? D76 '$ !" 2==#144 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K &#2..!+;4,2"!'( L !'&1#.2+1 )1#!2? D76H@ "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! OD """ P!#&%2?;B1<"?2&1@ +?244 .#2<1;">+ L !'&1#.2+1 P!#&%2?;B1<"?2&1@ F2'=*!=&, @66 !" 2==#144 @6H@6H@6H8@ N88HN88HN88HN8N """ 2%&,1'&!+2&!$' +,2" """ +,2" ,$4&'2<1 #&#D """ <%?&!?!'R """ <%?&!?!'R .#2(<1'&;=1?2K N6 """ <%?&!?!'R !'&1#?12>1 L <2";+?244 .#2<1;#1?2K .#2<1;">+ .#2<1;#1?2K +!# :E666 .#2<1;#1?2K F+ @666 .#2<1;#1?2K F1 6 '$ .#2<1;#1?2K 2=2"&!>1;4,2"!'(



LFI using FRF.12: !'&1#.2+1 41#!2? @7@ .#2<1;#1?2K &#2..!+;4,2"!'( .#2<1;#1?2K !'&1#.2+1;=?+! @68 +?244 3A;.#2(<1'& L <2";+?244 .#2<1;#1?2K 3A;.#2(<1'& .#2<1;#1?2K +!# EQ666 .#2<1;#1?2K .#2(<1'& N8 .#2<1;#1?2K .2!#;S%1%1

Generic Traffic Shaping: !'&1#.2+1 41#!2? 676 &#2..!+;4,2"1 #2&1 @NO666 DN666

Frame Relay Traffic Shaping: !'&1#.2+1 )1#!2?@ 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K +?244 DOQiZPI4 .#2<1;#1?2K &#2..!+;4,2"!'( L !'&1#.2+1 )1#!2?@H@ "$!'&;&$;"$!'& .#2<1;#1?2K +?244 8@NiZPI4 .#2<1;#1?2K !'&1#.2+1;=?+! @6@ L !'&1#.2+1 )1#!2?@HN "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! @6N L !'&1#.2+1 )1#!2?@HD "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! @6D L !'&1#.2+1 )1#!2?@HQ "$!'&;&$;"$!'& .#2<1;#1?2K !'&1#.2+1;=?+! @6Q +?244 N8EiZPI4 L <2";+?244 .#2<1;#1?2K DOQiZPI4 .#2<1;#1?2K &#2..!+;#2&1 DOQ666 DOQ666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L <2";+?244 .#2<1;#1?2K 8@NiZPI4 .#2<1;#1?2K &#2..!+;#2&1 8@N666 8@N666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L <2";+?244 .#2<1;#1?2K N8EiZPI4 .#2<1;#1?2K &#2..!+;#2&1 N8E666 N8E666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L

Redistribution Redistribution is the act of taking routes from one routing process (OSPF, EIGRP, static routes, etc.) and placing them into another routing process. By default, Cisco routers do not share routing information between routing



processes. For example, you could have a single router running EIGRP on the 150.150.0.0 network and running RIP on the 160.160.0.0 network. By default routers on the 150.150.0.0 network would not be able to communicate with other routers on the 160.160.0.0 network. This is because the router running both protocols does not automatically share routing information between its routing processes - between EIGRP and RIP, in this case. (Users directly connected to that router would be able to communicate with each other because the router connected to both networks forwards packets between the 150.150.0.0 and 160.160.0.0 networks).

Given the choice, I would always prefer to specify networks as part of a routing process given the '1&*$#R command rather than using #1=!4&#!F%&1 +$''1+&1=. The '1&*$#R command allows more precise control over which networks are given to a routing process.

The '1&*$#R command makes a route internal to a routing process, whereas #1=!4&#!F%&1 makes a route external to a routing process (such as EIGRP or OSPF).

Metrics When redistributing from one protocol to another, it is recommended to specifically define the routing metric. This is because almost every routing protocol has a metric that is not compatible with any other protocol. You can do this in the redistribute command:

#$%&1# #!" #1=!4&#!F%&1 1!(#" @ <1&#!+ Q

Or this can be done with a default-metric command:

#$%&1# #!" #1=!4&#!F%&1 1!(#" @ =1.2%?&;<1&#!+ Q

When redistributing a protocol into EIGRP using the #1=!4&#!F%&1

command you need to explicitly configure the EIGRP metric (otherwise no routes get redistributed). You can do this by:

#$%&1# 1!(#" @ =1.2%?&;<1&#!+ @666 86 N88 @NO @8@Q

or

#$%&1# 1!(#" @ #1=!4&#!F%&1 F(" E8NNN <1&#!+ @666 86 N88 @NO @8@Q



Note: in EIGRP the metric values are (in order): BW (in Kbits/sec), delay, reliability, loading and MTU. You can select almost any allowed values for these - they don't necessarily need to reflect the actual network.

When redistributing into RIP, make very sure you add the <1&#!+ keyword, such as <1&#!+ D (or the =1.2%?&;<1&#!+ command). This is critical because RIP has such a low metric. Otherwise you may get the metric set to 16 (unreachable), depending on the metric of the routing protocol supplying the route.

Route-Maps I recommend getting in the habit of using route-maps when you redistribute routes. Route-maps can be used to set various route attributes, but the most common use I found was simply for filtering (controlling) what routes were actually redistributed. Often the CCIE Lab will specifically state what routes are to be redistributed (rather than simply all routes). A route-map can be used to meet this requirement. Even if the lab does not specifically require this, it is a good idea to use a route-map for filtering so that you know exactly what routes are being redistributed.

OSPF When redistributing a protocol into OSPF, I usually use the subnets keyword. This enables all routes to be redistributed into OSPF. If you omit this keyword routes will be summarized to their "natural" classful mask when they are redistributed into OSPF (which is probably not what you want).

By default, routes redistributed into OSPF become external type 2 routes. Often this is fine, however at times you may need to make them external type 1 routes (see OSPF - External Routes, earlier). This can be overridden with the <1&#!+;&K"1 @ keyword in the redistribute command.

When redistributing OSPF into BGP by default BGP will only accept OSPF internal (inter- and intra-area) routes - not external type 1 or type 2 routes by default. To change this, use the match keyword:

#$%&1# F(" E8666 #1=!4&#!F%&1 $4". @ <2&+, !'&1#'2? 1W&1#'2? @ 1W&1#'2? N

Summarization Notes When you redistribute, make sure that you don't "violate" a requirement of summarization that the lab may require. For example, you may be summarizing OSPF routes. You may also be required to run RIP on those interfaces and redistribute RIP into OSPF. If you don't use a route-map to control which routes get placed into OSPF, you'll see the OSPF summary and one external OSPF route for each of the RIP interfaces (from the redistribution) - and thus you won't really be summarizing correctly.



For example, examine the diagram in Figure 8: OSPF Summarization with RIP Redistribution:

router4

RIP

router1 router3

router2

172.16.10.0/24 172.16.254.0/24

172.16.8.0/24 OSPF Area 0

172.16.9.0/24

OSPF Area 1

Figure 8: OSPF Summarization with RIP Redistribution

You may be asked to summarize the following routes on router 1 into a single OSPF advertisement: 172.16.8.0/24 172.16.9.0/24

So you create an 2#12 @ #2'(1 @UNH@EHOH6 N88HN88HN8QH6 statement on router 1. However you also need to run RIP on the 172.16.0.0 network for connectivity to router4 (thus RIP gets run on all the above interfaces). Assume you have to redistribute RIP into OSPF.When you do that, if router3 happens to be also running RIP then both of the routes listed above go back into OSPF as external routes. Thus other OSPF routers will have the OSPF area summary, but also the specific routes as OSPF externals. To prevent this, filter (use a route-map) on the redistribution of RIP into OSPF to prevent the above three routes from being redistributed into OSPF.

RIP Cisco supports RIP version 1 and version 2. There are several differences, though the most important difference is V2 includes the subnet mask of each route within the advertisement. Thus V2 is capable



of handling variable length subnet masks. You should be familiar with and practice both as you may be required to use one or the other during the Lab exam.

You can set the version of RIP for the entire routing process (every interface):

#$%&1# #!" >1#4!$' N

However you may also override this behavior on an interface-by-interface basis using the commands:

!'&1#.2+1 5&,1#'1& 6 !" #!" #1+1!>1 >1#4!$' @ !" #!" 41'= >1#4!$' @

RIP version 1 is a "classless" protocol. This does not mean its lacks elegance and grace (though many would argue that as well!), it means it does not share subnet information in routing updates. That is, because no subnet mask is provided for each route announced with RIP version 1, the receiving router must make certain assumptions that are detailed in the following section.

Sending and Receiving Updates RIP version 1 follows a specific algorithm when both sending and receiving updates. Part of this is a logical way to "assume" subnet mask information, but it is also a way to minimize loops:

When sending an update the router determines (for each network or subnet being sent) whether the subnet defined on the interface sending the update is in the same major network (traditional class A, B or C network) as the advertisement about to be sent. If it is not, the advertisement is sent as the major (class A, B or C) network (not as a subnet). If the subnet defined on the interface sending the update is in the same major network, the router compares the subnet mask of the interface to that of the advertisement. If they are the same (i.e., both /24) the advertisement is sent. If they are different, the router drops the advertisement.

This is critical to understand when sending updates via RIPv1. For example consider a case where router 1 and router 2 are connected via a /24 subnet. Router 1 has four /26 subnets it needs to advertise to router 2. In this case if the subnet connecting the routers is in the same classful (major) network as the four /26 subnets, RIPv1 will not advertise the /26 subnets. Two ways to avoid this are to make the /24 connecting the routers a different major network than the /26's. That way router 1 will



summarize them to their natural (class)mask. Another way is to summarize the four /26's to the same mask as the link between the routers (/24). This could be done with a static route to null0 (though its unlikely you'll be allowed to do this on the exam).

When receiving updates the router makes the same comparison - whether the subnet defined on the interface receiving the updates is in the same major network (traditional class A, B or C network) as the advertisement that was received. If it is, the mask of the interface on which the update is received is applied to the advertisement. If it is not, the router examines its routing table. It determines whether it already knows about any other subnets of that major network. If it does not the "natural" class mask is applied and the update is accepted. If it does, the update is dropped.

This is why RIPv1 subnets must be contiguous. If router 1 and router 2 each have a /24 subnet of the 128.128.0.0 class B network, yet they are interconnected by a subnet not in the 128.128.0.0 range, each one will drop all the other router's updates about it's 128.128.x.0 subnets and routing will be incomplete.

Route Maps There are three primary uses for route-maps: 1. To control redistribution from one routing protocol to another 2. To use for policy routing 3. To control the way BGP updates are sent between BGP neighbors

My recommendation is to become extremely proficient with route maps. It is an incredibly powerful tool. The best way to become highly skilled with route maps is to practice using them many times.

You will typically need them during redistribution since you are usually limiting what routes get redistributed. However they can also perform a myriad of other functions: setting almost any BGP attribute, setting route tags, setting various routing parameters (metric, metric-type, etc.), filtering routes inbound or outbound from BGP neighbors, performing policy routing, etc. I typically use these for many of my filtering functions. Even though they may be an extra command out two (compared to a distribute- list) I was so comfortable using them it was easier to use route maps. Practice route maps!!

Remember, when working with route maps the behavior is as follows:

· For policy routing, if none of the route-map statements match then the packet gets routed normally

· For routing updates if none of the route-map statements match then the routing update gets dropped



Thus if you are using a route-map to modify some routing updates (set communities, set tags, etc.) in order to still propagate all other routing updates (if that is what you want to do), you need:

#$%&1;<2" <K<2" "1#<!& N66 -'$&,!'( ,1#1 9 &,!4 !4 ?1.& F?2'R &$ u<2&+, 1>1#K&,!'(v 2'= ?1& &,1 #14& $. &,1 #$%&!'( %"=2&14 "244 '$#<2??K/

Tagging Routes One of the things route maps can do is to tag routes. This is not something you will use often, but it can be a handy "tool" in your toolbox. Several protocols (RIP, OSPF) support tags. A tag is basically an arbitrary value that you can apply to certain routes. Each route maintains its tag from router to router. You may use this tag for things such as filtering or adjusting metrics.

R1 hostname R1

172.16.1.1/24 ip route 10.10.10.0 255.255.255.0 172.16.1.2 ip route 10.10.11.0 255.255.255.0 172.16.1.2

RIP 192.168.11.0

R2 EIGRP R3 192.168.200.0

Figure 9: Using Route Tags

For example, in Figure 9: Using Route Tags assume R1 is running RIP with R2. R1 runs RIP on its Ethernet interface and redistributes two static routes into RIP. R1 can set tags on the routes it redistributes into RIP:

#$%&1# #!" >1#4!$' N #1=!4&#!F%&1 4&2&!+ <1&#!+ Q #$%&1;<2" 4&2&!+Bc#!" '1&*$#R @:NH@EOH@@H6 '1&*$#R @UNH@EH6H6 '$ 2%&$;4%<<2#K L #$%&1;<2" 4&2&!+Bc#!" "1#<!& @6 <2&+, !" 2==#144 "#1.!W;?!4& 4&2&!+Bc#!" 41& &2( NNNN L !" "#1.!W;?!4& 4&2&!+Bc#!" 41S 8 "1#<!& @6H@6H@6H67NQ !" "#1.!W;?!4& 4&2&!+Bc#!" 41S @6 "1#<!& @6H@6H@@H67NQ

This is one way you can identify certain routes to other routers, such as R2. For example, R2 can be configured to only redistribute into EIGRP



RIP routes that have tags set to 2222 (i.e., static routes on R1 that have been redistributed, not the 172.16.1.0/24 "pure RIP" network): #$%&1# 1!(#" @ #1=!4&#!F%&1 #!" #$%&1;<2" #!"Bc1!(#" '1&*$#R @:NH@EOHN66H6 =1.2%?&;<1&#!+ @666 @6 N88 @66 @866 '$ 2%&$;4%<<2#K L #$%&1;<2" #!"Bc1!(#" "1#<!& @6 <2&+, &2( NNNN

Router Services This section descries some fairly simple router services that may appear on the lab. These are grouped together here since they are not complicated enough to require their own dedicated sections.

FTP A router can use FTP to copy a file to flash - though it cannot act as an FTP server. FTP is more reliable than TFTP and is a better method if traversing a somewhat unreliable or congested link. The username and password are required, setting the mode to passive and specifying the source interface are optional (but can be useful if the FTP server uses IP address restrictions. Once these commands are configured the +$"K .&"

.?24, command can be used.

!" .&" %41#'2<1 F2#2+R !" .&" "244*$#= $F2<2 !" .&" "244!>1 !" .&" 4$%#+1;!'&1#.2+1 ?$$"F2+R6

NetFlow Netflow captures source and destination IP address and port, Layer 3 protocol type (TCP, UDP, etc.), the ToS field and the input interface. Be aware that the exam may not ask you to configure Netflow on an interface, but may require that you capture some or all of these fields - which then requires Netflow.

Netflow is enabled on an interface with the !" .?$* !'(#144 (traffic entering) command or the !" .?$* 1(#144 (traffic leaving) command. Netflow requires cef. Cef is on by default (!" +1.), but just make sure this is enabled if Netflow is required. Netflow can be configured in version 1, 5 or 9. Version 1 is the default, but since (no surprise!) version 9 is the latest you may want to configure that with the !" .?$*;1W"$#& >1#4!$' :

command. In order to send NetFlow to a receiving host, use the !" .?$*;

1W"$#& =14&!'2&!$' @6H@H@H@ command. Although you will not need to configure such a host, it is possible they will have you send Netflow data to such a host.



There are several optional !" .?$*;+2+,1 and !" .?$*;1W"$#&

commands used to customize Netflow. These are optional.

TFTP Server A router can act as a TFTP server - this is quite helpful even in the real world! If you have several devices at a remote location that require an IOS upgrade you can transfer the code to a router at or near that location, then TFTP it from the router to each device. This often saves time. A router can accept an IOS that it can't use to boot, just for the purpose of allowing other devices to copy it. So if you had five 3750 switches at a location, you could transfer (FTP, TFTP, etc.) the IOS to the local router, then have each 3750 TFTP copy the IOS from that router.

The TFTP server command can provide an alias to each filename (to simplify the copy) and apply an ACL. This example allows the IOS to be copied as its real name or as "3825-boot" and applies ACL 1 to limit only 10.*.*.* devices access: &.&";41#>1# .?24, +DON8;!">$!+1R:;<eH@NQ;@@HBDHF!' 2?!24 DON8;F$$& @ 2++144;?!4& @ "1#<!& @6H6H6H6 6HN88HN88HN88

Routing (General)

Router "Network" Statements When you specify a network via the '1&*$#R statement in eigrp, rip, etc., that triggers the software to perform two related but slightly different tasks: 1. Run that protocol on the interfaces included within the network command (broadcast routing updates, look for neighbors, etc.)

2. To incorporate that network into the protocol's database. This means that this route will be advertised in updates.

However connected routes also include static routes that use a next-hop interface (if you look via 4,$* !" #$%&1 a static route with a next hop of an interface shows as "connected").

Passive Interface There are times when you want a route advertised by a routing protocol, but you don't want to actually run that protocol over the interface. For example, let's say you have a router where Ethernet 0 has an address of 192.168.33.1/24. Let's say the router is running RIP. There will be cases where you want to advertise the 192.168.33.0/24 network via RIP, yet you don't want to actually run RIP on Ethernet 0. That is, in this case you don't want to send and receive updates on this interface. In this case use the '1&*$#R @:NH@EOHDDH6 command in RIP to include that network in your routing, but also use "244!>1;!'&1#.2+1 1&,1#'1& 6 command in RIP to prevent updates from being sent out Ethernet 0.



Note: For protocols such as OSPF and EIGRP the "244!>1;!'&1#.2+1

command prevents sending or receiving routing updates out an interface. This is because those protocols must first form neighbor relationships (which require sending and receiving). However for RIP this command prevents sending routing updates, but it does not prevent receiving updates. To prevent receiving updates from these protocols, use filtering (route-maps, distribute-lists, etc.) See "Distribute List In" on page 47 for an example of this.

Default Metrics All routing protocols use metrics. Few, if any, routing protocols have metrics that are compatible with the metrics of other routing protocols. Thus when one protocol is redistributed into another, there is a problem with metrics. There are two basic ways to solve this issue. One is to use the <1&#!+ keyword with the redistribute command. This sets the (new) metric on all routes that are redistributed with that command. The other solution is to use a =1.2%?&;<1&#!+ command in the routing protocol that will be accepting the redistributed routes. This command basically says "if redistributed routes do not have the metric set in the redistribute command, use this metric."

Both solutions work well, though you need to use one or the other for proper redistribution.

Split Horizon Split Horizon prevents loops by blocking the sending of any updates on an interface where the "next hop" for that route is located out that interface. Split Horizon is set on a physical interface, but that setting also applies to any subinterfaces of that interface (such as Frame Relay subinterfaces).

RIP and EIGRP use split horizon. Often split horizon is turned off on a physical Frame Relay interface. Often on a remote router you will want to turn this on (to prevent the remote from advertising to the hub routes it has learned from the hub).

Often split horizon is turned on on a Frame Relay point-to-point or multipoint subinterface. Often on the hub router you will want to turn this off (to advertise to one subinterface routes learned on a different subinterface).

It is a good practice when using a protocol that runs split-horizon (IP RIP, IP EIGRP, etc.), to manually set the split-horizon to the way you need it, regardless of the default. For RIP use the -'$/ !" 4"?!&;,$#!e$'

command. For EIGRP, use the -'$/ !" 4"?!&;,$#!e$' 1!(#" @

command.



SSH

Secure Shell (SSH) is effectively an encrypted (secure) Telnet session - it allows a remote connection to the router or switch's console. SSH operates in a client/server mode. The Cisco router or switch acts as a server when it is receiving an SSH session from an end-station (or another router, etc.) that are acting as clients. The Cisco router or switch acts as a client when it is initiating an SSH session to another router or switch.

SSH requires an image that supports DES or triple DES (3DES). If SSH is required in the lab they will certainly have the correct image loaded, but this is important to note if you are practicing SSH in your home lab.

To configure SSH server you must configure a hostname and domain name, create an RSA key and enable the SSH server:

!" ,$4&'2<1 #$%&1#@ !" =$<2!';'2<1 ?2FH'1& +#K"&$ R1K (1'1#2&1 #42 !" 44,

The !" 44, command has the optional keywords &!<1$%& 2) !$%2 and 2%&,1'&!+2&!$';#1&#!14 $'"()*. The timeout refers to the time for SSH negotiation. It can be set anywhere up to the default of 120 seconds. Retries refers to the number of authentication retires a client receives. It can be set from 1 to 5 and defaults to 3. The key generation command is required and it requires a hostname and domain-name configured.

The 4,$* !" 44, command shows the status, version and settings of the SSH server. The 4,$* 44, command shows the active SSH connections (if any). Once an SSH session connects it is treated as a virtual terminal session (a "vty" session) and receives all the configuration parameters set in the ?!'1 >&K 6 Q portion of the config. As such the &#2'4"$#& !'"%&

2?? command is required or SSH must be included in the &#2'4"$#& !'"%&

command in the ?!'1 >&K 6 Q config.

Tips & Tricks The lab should provide colored pens and pencils. However these are about the only thing you actually can bring into the lab with you (and even with these you should probably check in advance). It might be a good idea to bring good erasers, pens and sharpened, colored pencils. I don't recommend bringing in stencils for your diagram (though one person did the day I took my exam). You probably won't have that much time!

Remember that +$'&#$?;4,!.&;E +$'&#$?;4,!.&;E will not break to the terminal server but rather send a break to the actual router the terminal server is connected to. This is very handy. For example, you can set up an extended ping of 1000 pings (that are failing) so that you can troubleshoot



what is happening on other routers (shows, debugs, etc.) Once you have solved or identified the issue (or given up!) go back to the router doing the pinging and type +$'&#$?;4,!.&;E +$'&#$?;4,!.&;E to break from the extended ping.

If you have a serial cross-over cable and you don't know which end is DCE or DTE, connect each end to routers and do:

4,$* +$'&#$??1#4 41#!2? 676

Usually in about the second line it will tell you which end of cable it is (DCE or DTE):

B14&ZA$%&1#Z@04,$* +$'&#$??1#4 41#!2? 676 ^m %'!& 6T !=F h 6W:GDOIT =#!>1# 4&#%+&%#1 2& 6W:36@6 F%..1# 4!e1 @8NQ ^m %'!& 6T H7IB DJ; ()KG&T +?$+R#2&1 @666666

If it is the DTE end, no configuration is necessary. If it is the DCE end, use:

!'&1#.2+1 )1#!2?676 +?$+R #2&1 @666666

Practice Speed Knowing all the information required to pass the CCIE lab exam is only part of what you need. Many people could pass the CCIE if they were given more time. A critical skill you will need to pass the exam is speed. The more speed you have on certain aspects of the exam, the more time you will have to search the documentation and think about the answer on other portions of the exam. However you know certain scenarios are likely on the exam. Repeatedly practice these tasks and time yourself. Begin each speed drill with very basic router configs. Draw the relevant configuration info (IP addresses, OSPF area numbers, BGP ASN's, etc.) on a piece of paper. Then time yourself and begin configuring. Actually write down how long an exercise took to complete. Repeat the exercise over several days and see how much you can improve your time. Remember, accuracy is more important than speed, but speed is a close second!

Here are some configs on which you should practice your speed:

· Configure a hub-and-spoke Frame Relay network of 3 or 4 routers with a mix of physical and subinterfaces

· Configure three routers for BGP using the same ASN. Configure one router to be a route reflector for the other two routers.

· Configure three routers for OSPF. Use at least two OSPF areas, change the OSPF network type on one network and have one OSPF area summarize a couple of routes to the other OSPF area



· Configure a routing protocol such as RIP or EIGRP. Configure it to run on two or more interfaces of router 1, one of which connects to router 2. On router 2 configure that same protocol on the interface that connects to router 1. On router 2 also configure OSPF. On router 2 redistribute the protocol into OSPF as metric-type 1, metric of 50, include subnets and use a route-map to only allow 1 of the routes from the other protocol to go into OSPF

· Run BGP between two routers using different ASN's. Use a route- map on one to set the MED and a community on advertised routes. On the other router use a filter to only accept routes from that AS and a route-map to only accept routes where the community is set correctly.

· Configure two 3560's, connected via two trunk connections. Pass four VLAN's across the trunk, have 3560-1 route for the first VLAN, have 3560-2 route for the second VLAN. Have both 3560-1 and 3560-2 run HSRP (with 3560-2 acting as the primary) for the third VLAN. Have the fourth VLAN simply switched (not routed). Configure 3560-1 as the Spanning Tree root for the first and fourth VLANs and 3560-2 as the root for the second and third VLANs.

· Create your own "common" lab scenarios and practice your speed!IP Subnetting

It is important that you become familiar and fluent with IP subnetting. You should have a solid understanding of subnet masks (255.255.255.192), the number of subnet bits (/26) and the number of hosts allowed (64). At the beginning of my exam I took a piece of extra paper and quickly jotted down the table shown in Table 8: IP Subnetting Summary. Creating a table like this prevents you from forgetting any information, like accidentally skipping 255.255.255.248.

Table 8: IP Subnetting Summary

Subnet Mask Number of Number of IP Addresses Subnet Bits

255.255.255.0 /24 256 255.255.255.128 /25 128 255.255.255.192 /26 64 255.255.255.224 /27 32 255.255.255.240 /28 16 255.255.255.248 /29 8 255.255.255.252 /30 4 255.255.255.254 /31 2 255.255.255.255 /32 1 This column This column This column begins at 256 simply needs to begins at /24 and gets cut in half with be memorized and increases each row by 1 each row



Using this table I can quickly get the information I need, whether that is:

· The correct subnet mask for an interface (such as 255.255.255.128)

· The correct number of subnet bits (/25) for a prefix list · The correct number of hosts (128) in the event the exam requires

you to create a subnet that will support 120 hosts, for example

If necessary I also create a similar table going in the other direction. For example, the first two lines of that table would be:

Subnet Mask Number of Number of IP Addresses Subnet Bits

255.255.254.0 /23 512 255.255.252.0 /22 1024 etc.

Access Lists For access-lists:

· BGP uses TCP port 179

· RIPv1 uses UDP port 520 and dest. address 255.255.255.255 · RIPv2 uses UDP port 520 and dest. address 224.0.0.9 · OSPF uses protocol 89 and dest. address 224.0.0.5

· EIGRP uses protocol 88 and dest. address 224.0.0.10 · ESP (IPSec) uses protocol 50 · AH (IPSec) uses protocol 51 · GRE uses protocol 47

· ISAKMP uses UDP port 500

For netbios host name access lists, "1#<!& a is the "permit any." For mac-address lists "1#<!& 6666H6666H6666 ....H....H.... is the "permit any."

At the end of an access-list place a "=1'K 2'K 2'K ?$(" to send rejected packets to the log. This will help determine what packets may be getting blocked that are causing other things not to work (routing protocols, tunnels, IPSec, etc.). Then do a "show log" to determine what packets are being blocked.

Logging In order to send all messages to the on-board logging buffer (including the blocked packets mentioned, above) make sure you have the ?$((!'(

F%..1#1= command in your configuration. This command allows you to specify the size of the buffer, though I've always found the default size to



be sufficient. Use the 4,$* ?$( command to view the messages in the buffer.

The ?$((!'( +$'4$?1 (or '$ ?$((!'( +$'4$?1) command controls whether messages are sent to the console. This is enabled (?$((!'( +$'4$?1) by default. In order to have messages sent to a telnet session, you need both the ?$((!'( +$'4$?1 command and the &1#<!'2? <$'!&$# command.

Console and VTY Ports Once you are familiar with console and vty commands such as no login, login local, etc. you can save time in your home lab by turning off authentication on these lines. This way when you are jumping from router to router via console or telnet, you do not get prompted for a password and you automatically get placed into exec mode. The commands you will need are:

'$ ?$(!' "#!>!?1(1 ?1>1? @8 1W1+;&!<1$%& @N6 6

I don't recommend setting 1W1+;&!<1$%& 6 6 in your home lab since I found this would occasionally cause a line to hang (plus with these commands it is very fast to re-establish a console or telnet session). If you haven't used it in 2-3 hours, having the router automatically terminate the session is probably a good idea. A sample config that will save time in your home lab:

?!'1 +$' 6 1W1+;&!<1$%& @N6 6 "#!>!?1(1 ?1>1? @8 '$ ?$(!' ?!'1 >&K 6 Q 1W1+;&!<1$%& @N6 6 "#!>!?1(1 ?1>1? @8 '$ ?$(!'

Terminal Editing +$'&#$?;X brings you to the beginning of the line +$'&#$?;5 brings you to the end of the line +$'&#$?;A repaints a line (handy if a console or debug message pops up) +$'&#$?;l is the same as "up arrow" (in case that isn't working)

Troubleshooting Remember - in the lab don't spend too much time troubleshooting a section that is only worth a few points. Its easy to get focused on solving a problem - but remember time is limited!



This section is devoted to "tools" you might use during troubleshooting. No, I don't mean software packages or ISDN simulators. I'm referring to scenarios where you may be testing or troubleshooting a problem and these "tools" - mostly techniques for doing certain things - may come in handy.

router1 router4 5*#$ (46$%7$ 5482 172.31.3.1/24 %5'%499 $&&%)-./0)/0/)%.33/.33/.33/2 %5'%466$&&:; !"'%)2<%!"# 466$&&:85&#%)2<%9$*=%%%5'%)-./0)/.20/2 2/2/2/.33%4*=%8!; OSPF 172.31.3.4/24 466$&&:85&#%)2<%'$ >5#%5'%4*=%4*=

172.31.4.1/24 area 0

OSPF area 1

router3 172.31.4.3/24

!"#$ %!&'(%) %%*$#+! ,%)-./0)/1/2%2/2/2/.33%4 $4%)

172.31.203.1/24

Figure 10: Using "Tools" To Help Troubleshooting

Extended Pings from Another Interface This tool can often help debug routing problems. If there are connectivity issues, this lets you control the source address of the pings being sent. For example, in Figure 10: Using "Tools" To Help Troubleshooting router3 has no problem pinging router4's serial interface (172.31.3.4). By default router3 uses a source address of 172.31.4.3, since that is the interface it uses to route to the 172.31.3.0/24 network. Extended pings can force router3 to use a different source address when pinging router4, such as 172.31.203.1. Here is the output from both pings:

#$%&1#D0"!'( @UNHD@HDHQ BK"1 14+2"1 41S%1'+1 &$ 2F$#&H )1'=!'( 8T @66;FK&1 dI_[ 5+,$4 &$ @UNHD@HDHQT &!<1$%& !4 N 41+$'=4J LLLLL )%++144 #2&1 !4 @66 "1#+1'& -878/T #$%'=;&#!" <!'72>(7<2W h O7@D7NO <4 #$%&1#D0 #$%&1#D0"!'( [#$&$+$? f!"gJ



B2#(1& d[ 2==#144J @UNHD@HDHQ A1"12& +$%'& f8gJ m2&2(#2< 4!e1 f@66gJ B!<1$%& !' 41+$'=4 fNgJ 5W&1'=1= +$<<2'=4 f'gJ / )$%#+1 2==#144 $# !'&1#.2+1J +,97I+796I7+ BK"1 $. 41#>!+1 f6gJ )1& m3 F!& !' d[ ,12=1#p f'$gJ P2?!=2&1 #1"?K =2&2p f'$gJ m2&2 "2&&1#' f6WXGImgJ C$$41T )&#!+&T A1+$#=T B!<14&2<"T P1#F$41f'$'1gJ )*11" #2'(1 $. 4!e14 f'gJ BK"1 14+2"1 41S%1'+1 &$ 2F$#&H )1'=!'( 8T @66;FK&1 dI_[ 5+,$4 &$ @UNHD@HDHQT &!<1$%& !4 N 41+$'=4J HHHHH )%++144 #2&1 !4 6 "1#+1'& -678/ #$%&1#D0

This tells us that (most likely) router4 does not have a route to get back to the 172.31.203.0/24 network. Analyzing router3 shows that the 172.31.203.0 network was not included in any of the network statements in the #$%&1# $4". @ configuration. Adding '1&*$#R @UNHD@HN6DH6

6H6H6HN88 2#12 @ allows both the ping and the extended ping to complete successfully, since now router4 can route the return pings back to the 172.31.203.0/24 network.

Extended Pings with High Repeat Count At times something is not working and in order to determine why you need to create a steady stream of packets that are seeing the problem. Let's take a case where router3 still cannot ping 172.31.3.4 using 172.31.203.1 as the source address, however this time routing is not the problem. If you do an extended ping as in the previous section, by the time you start figuring out what the problem is the five pings will have stopped and you'll have nothing left to troubleshoot.

In this case use an extended ping on router3 to ping 172.31.3.4 from source interface 172.31.203.1. However this time use "500" as the repeat count to keep the pings coming from router3 while you troubleshoot.

You might start with router4 and do a debug ip packet detail and notice that the pings are not being received by router4. In this case you'd probably move onto router1 to determine whether the packets where being received and sent by router1. As it turns out router1 has an !" 2++144;(#$%" @6: $%& configured on serial0 (connecting to router4), so the packets were never making it to router4. If access-list 109 had a 'log' at the end of its deny statement, you would see a message like this on router1:

#$%&1#@0



8=@:,J k)5I;E;d[XII5))CcMm[J ?!4& @6: =1'!1= !+<" @UNHD@HN6DH@ ;s @UNHD@HDHQ -676/T @ "2+R1& #$%&1#@0

This indicates that ACL 109 was blocking traffic from 172.31.203.1 to 172.31.3.4 (just as it was supposed to). Let's assume you didn't have the 'log' statement on access-list 109. One alternative is to issue the command =1F%( !" "2+R1& =1&2!? on router1. In this case router1 produces the output:

8=@:,J d[J 4h@UNHD@HN6DH@ -)1#!2?@/T =h@UNHD@HDHQ -)1#!2?6/T ?1' @66T 2++144 =1'!1=

Although this does not indicate access-list 109 is the culprit, it clearly indicates the packets in question are denied. Once that has been determined it won't take you long to figure out why.

Remember that in order to stop router3's pings (assuming you are connecting via a terminal server), use the command ctrl-shift-6 ctrl-shift-6.

Extended Pings with Large Size Packets or Large Repeat Counts There are times when small packets will be able to traverse a link without any problem, but large packets will fail. This can occur, for example, on a WAN circuit that has timing problems. This will almost never occur in the CCIE lab (then why do I care!?!!) but it can occur in the real world.

If you are troubleshooting a connectivity problem and you are able to successfully ping the opposite end of the link, consider pinging with large packet sizes (1500 bytes). If those pings fail but small pings (used by default with the "ping" command) work fine, it could well be a timing issue with the circuit. Sometimes the timing will be slightly off, yet you need a large enough packet to accumulate enough of the timing problem to actually make the packet contain errors.

Another technique I use in the "real world" is to issue a ping with a very high repeat count. I won't hesitate to ping a router interface 5000 times, even in a production environment. The only exception to this is if the destination is over a slowWAN link. Otherwise in a healthy network these 5000 pings should finish quickly with a 100% success rate. If you drop 10 or 20 packets, this probably indicates a problem.

One way to incorporate a high number of pings and a large number of pings is to have the router perform a ping with a range of sizes. I usually use 36 as the minimum and 1500 as the maximum. This creates several thousand pings in a range of sizes:

#$%&1#@0"!'( [#$&$+$? f!"gJ



B2#(1& d[ 2==#144J @UNHD@HDHQ A1"12& +$%'& f8gJ m2&2(#2< 4!e1 f@66gJ B!<1$%& !' 41+$'=4 fNgJ ;L$&'0&0 (MNN)'0% ='>* / )$%#+1 2==#144 $# !'&1#.2+1J BK"1 $. 41#>!+1 f6gJ )1& m3 F!& !' d[ ,12=1#p f'$gJ P2?!=2&1 #1"?K =2&2p f'$gJ m2&2 "2&&1#' f6WXGImgJ C$$41T )&#!+&T A1+$#=T B!<14&2<"T P1#F$41f'$'1gJ FO&&" .)'2& M5 %1P&% ='>* / )*11" <!' 4!e1 fDEgJ FO&&" N)L %1P& =+@698>* +B66 )*11" !'&1#>2? f@gJ BK"1 14+2"1 41S%1'+1 &$ 2F$#&H )1'=!'( UDN8T fDEHH@866g;FK&1 dI_[ 5+,$4 &$ @UNHD@HDHQT &!<1$%& !4 N 41+$'=4J LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL -1&+HL/

This command issues 7,325 pings: one ping for every size packet from 36 bytes to 1500 bytes (a total of 1,465 pings), repeated 5 times. If you don't want to send 7,325 pings use a A1"12& +$%'& of 1 - this will just send one ping packet of each size from 36 to 1500 bytes, a total of 1,465 pings.

Debug Becoming familiar with the debug commands is invaluable to passing - and perhaps more importantly preparing for - the CCIE. I recommend experimenting with all different types of debugs to see what happens. When you are brain-dead and tired of studying, turn on some debugs and then do things to make the router react (reset BGP neighbors, drop serial links, reboot other routers, turn off routing protocols, etc.)

Other Tools Other "tools" that may come in useful are policy routing (manually controlling the flow of packets based on rules), route maps, traceroutes (to determine the path packets are taking through the network) and tunnels (discussed below).

Tunnels You define a tunnel by configuring a source and a destination IP address. Then assign the appropriate characteristics to the tunnel (bridging, IP addresses, IP routing, etc.)

If a router learns about its tunnel destination address over the tunnel it will try to send the GRE (or whatever tunnel mode you are using) packets over the tunnel itself... that won't work! Use a distribute list to prevent each side from advertising it's tunnel source address to the other side over the tunnel. For example, perhaps two routers have a tunnel between their loopback addresses. Let's say they are using RIP to be able to route



between the loopbacks. If OSPF is enabled on the tunnel and the loopbacks, OSPF will deliver updates (through the tunnel) about the loopback networks. Since OSPF has a better admin distance than RIP, it will supercede the RIP learned routes.

Yet now the router is attempting to maintain the tunnel (route packets to the destination) through the tunnel - but it can't maintain the tunnel if the "next hop" is inside the tunnel!

In this case you will usually get a console message that the tunnel interface is down due to a routing loop.

WCCP TheWeb Cache Communication Protocol (WCCP) is a protocol developed by Cisco to redirect web traffic from a web server to a content engine (i.e., web load-balancing switch). Since content engines are not included on the lab equipment list, they can't appear on the lab exam. This makes it unlikely you'll need to configureWCCP in the lab, but since its included on the 4.0 Lab Topic Blueprint I will include a brief overview here.

WCCP is enabled and defined globally with the !" *++" *1F;+2+,1

command and enabled on an interface with the !" *++" *1F;+2+,1

#1=!#1+& !' $# $%& command.WCCP has several optional settings, including redirecting service numbers instead of web-cache traffic, setting the multicast address routers and content engines use to communicate, setting passwords and applying ACLs that control which packets match the service, which packets that are redirected, and which web caches are allowed to participate in the redirection.

Appendix A: Tera Term Macro Here is the macro I used to collect configs and routing tables. I have added comments to the macro (beginning with !) so that you can modify it for your own use. This macro assumes you are going to be connecting through a terminal server to six other routers (connected as sessions 1-6), all of which are presently in enable mode. It also assumes you are presently at the terminal server's console prompt. At the end I have included the macro without any comments.

To actually run the macro, within Tera Term choose Controlà Macro, then select the text file where you saved this (or your own) macro script.

&!<1$%& h @N6 L d. N <!'%&14 ($14 FK 2'= B1#2 B1#< !4 4&!?? *2!&!'( .$# 2 #14"$'41T L 4&$" *2!&!'( 2'= ($ 2,12= 2'= +$'&!'%1 *!&, &,1 <2+#$ -4$<1 L "#$F?1< ,24 $++%##1=/H =!#1+&$#K h wIJx_K A$%&1# +$'.!(4xw L B,!4 41&4 &,1 =1.2%?& =!#1+&$#K .$# 4&$#!'( &,1 +$??1+&1= ?$(4H



L )1& &,!4 &$ *,2&1>1# =!#1+&$#K K$% *!?? %41 .$# 4&$#!'( L +$'.!(4H Y$&1J 2?4$ 41& &,!4 2 .1* ?!'14 =$*' 24 *1?? -*,1#1 L K$% 411 u=!#1+&$#Kv/ !'"%&F$W wY2<1 $. ?$( .!?1 .$# &,!4 &14&Jw w+,1+R $%& ***HI2??!4<2H+$<w L B,!4 "#$<"&4 &,1 %41# &$ 1'&1# &,1 .!?1'2<1 $. &,!4 ?$(H L m!#1+&$#K !4 '$& '11=1= 4!'+1 &,1 =1.2%?& =!#1+&$#K -?!4&1= L 2F$>1/ *!?? F1 2==1=H d %4%2??K %41 uH=$+v 1W&1'4!$'4 $' &,1 L '2<1 -&,2& d "?2+1 !' &,!4 F$W/ 4$ &,1K *!?? 2%&$<2&!+2??K F1 L $"1'1= FK `$#=H 4&#+$'+2& =!#1+&$#K !'"%&4&# L B,!4 2==4 &,1 =!#1+&$#K $'&$ &,1 .!?1'2<1 !'"%&&1= FK &,1 %41# L -&,%4 <2R!'( 2 +$<"?1&1 .!?1'2<1/H ?$(.!?1'2<1 h =!#1+&$#K L B,!4 41&4 &,1 >2#!2F?1 u?$(.!?1'2<1v &$ F1 &,1 '2<1 $. &,1 ?$( L .!?1 -!'+?%=14 =!#1+&$#K 2'= '2<1/H =!#1+&$#K h wIJx_K A$%&1# +$'.!(4xw L B,!4 41&4 &,1 =1.2%?& =!#1+&$#K F2+R &$ *,2& K$% *2'& !& &$ F1 L 4!'+1 &,1 >2#!2F?1 u=!#1+&$#Kv t%4& ($& &,1 2+&%2? .!?1'2<1 L +#2<<1= $' &,1 1'= $. !& 2 .1* ?!'14 F2+RH j$% '11= &$ 41& &,1 L =1.2%?& =!#1+&$#K ,1#1 2'= !' &,1 41+$'= ?!'1 $. &,1 <2+#$ L -2F$>1/H J412#+,Z?$(.!?1 .!?1412#+, ?$(.!?1'2<1 !. #14%?&h6 ($&$ $"1'?$( !'"%&F$W w5'&1# '1* .!?1'2<1Jw w3!?1 2?#12=K 1W!4&4T K$% !=!$&Lw 4&#+$'+2& =!#1+&$#K !'"%&4&# ?$(.!?1'2<1 h =!#1+&$#K =!#1+&$#K h wIJx_K A$%&1# +$'.!(4xw ($&$ 412#+,Z?$(.!?1 L B,1 2F$>1 ?!'14 412#+, &$ =1&1#<!'1 !. &,1 .!?1'2<1 K$% 1'&1#1= L 2?#12=K 1W!4&4H d. !& =$14T !& "#$<"&4 K$% .$# 2 '1* '2<1H B,1 L _2+#$ +2' 2""1'= $'&$ 2' 1W!4&!'( .!?1T F%& &,2& !4 uF1K$'= &,1 L 4+$"1 $. &,!4 <2+#$Hv J$"1'?$( ?$($"1' ?$(.!?1'2<1 @ @ L B,!4 $"1'4 &,1 2+&%2? ?$(.!?1H d =$'y& #1<1<F1# *,2& &,1 u@ @v L =$14qdy< 4%#1 !&y4 !' &,1 =$+%<1'&2&!$'q 41'=?' w4,$* +?$+Rw *2!& w0w L X4R4 &,1 #$%&1# *,2& &!<1 2'= =2&1 !& &,!'R4 !& !4q -.$# L #1.1#1'+1/ 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w4,$* !" #$%&1w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ L B,!4 41'=4 &,1 +$<<2'=4 4,$*' 2F$>1 &$ &,1 &1#<!'2? 41#>1# L #$%&1# -4!'+1 &,2& !4 *,1#1 K$% 2#1 +$''1+&1= *,1' K$% F1(!' L &,1 <2+#$/H B1#< ?1' 6 !4 !<"$#&2'& 4$ &,1 #$%&1# =$14 '$& *2!& L .$# K$% &$ ,!& &,1 4"2+1F2#H [2%41 @E -@E 41+$'=4/ !4 ,2'=K L 4!'+1 !& &2R14 41>1#2? 41+$'=4 .$# &,1 N866y4 &$ (1& &,1 +$'.!(



L #12=KH j$% <2K *2'& &$ !'+#1241 &,!4 $# =1+#1241 &,!4 .$# 12+, L $. K$%# #$%&1#4 =1"1'=!'( $' *,1&,1# &,1K 2#1 .24&1# $# 4?$*1# L -!4 &,1#1 4%+, 2 &,!'( 24 4?$*1# &,2' 2 N866p Jb/ L d' 12+, +241 B1#2 B1#< !4 *2!&!'( .$# 2 0 +,2#2+&1# &$ L 2""12# -!H1HT &,1 0 .$??$*!'( &,1 #$%&1#y4 "#$<"& 9 K$% '11= &$ L F1 !' 1W1+ <$=1q/^1#1 !4 *,1#1 K$% +2' 2== *,2&1>1# +$<<2'=4 L 2#1 $. !'&1#14& &$ K$%H 41'= w@w 41'=?' 0@D *2!& w0w L B,!4 41'=4 &,1 +$<<2'= u@v &$ &,1 &1#<!'2? 41#>1#T *,!+, L !'4&#%+&4 !& &$ +$''1+& &$ 4144!$' @H B,!4 !4 *,K !&y4 L !<"$#&2'& &$ ,2>1 &,1 #$%&1#4 2?#12=K +$''1+&1= !' 4144!$'4 @;E L -$# ,$*1>1# <2'K #$%&1#4 K$% ,2>1/ #2&,1# &,2' 4144!$' @TDTQTE L -*,!+, +2' ,2""1' !. K$% =!4+$''1+& 4144!$'4T 1&+H/ d& &,1' L 41'=4 2 rA1&%#'s &$ &,1 #$%&1# -*,!+, !4 &,1 u41'=?' 0@Dv/ &$ L (1& !& &$ =!4"?2K !&y4 "#$<"&H 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w4,$* !" #$%&1w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ L X?? +$<<2'=4 2#1 '$* !44%1= &$ #$%&1#@ -$# *,2&1>1# #$%&1# !4 L 4144!$' @ $' &,1 &1#<!'2? 41#>1#/H X.&1# *1 ,2>1 !44%1= &,1 L +$<<2'=4T 41& &,1 ?1'(&, $. &,1 4+#11' &$ QN -4$<1 "1$"?1 L "#1.1# NQ/H 41'=?' 0D60zUO *2!& w0w 41'= wNw 41'=?' 0@D *2!& w0w L B,1 0D60zUO 41'=4 2 uI$'&#$?;),!.&;E Vv 4$ &,2& K$% +2' t%<" L F2+R &$ &,1 &1#<!'2? 41#>1#H d& &,1' 41'=4 2 N &$ +$''1+& &$ L 4144!$' N -*,!+, !4 &,1 '1W& #$%&1# 2'= &,1 "#$+144 4&2#&4 2?? L $>1# 2(2!'/H 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w4,$* !" #$%&1w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ 41'=?' 0D60zUO *2!& w0w 41'= wDw 41'=?' 0@D



*2!& w0w L )!<"?K +%& 2'= "24&1 &,1 2""#$"#!2&1 41+&!$' F241= $' &,1 '%<F1# $. L #$%&1#4 -2'= &,%4 &1#<!'2? 41#>1# 4144!$'4/ K$% ,2>1H 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w4,$* !" #$%&1w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ L ^1#1 2#1 &,1 +$<<2'=4 .$# #$%&1#Q -&1#<!'2? 4144!$' Q/J 41'=?' 0D60zUO *2!& w0w 41'= wQw 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w4,$* !" #$%&1w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ L ^1#1 2#1 &,1 +$<<2'=4 .$# #$%&1#8 -&1#<!'2? 4144!$' 8/J 41'=?' 0D60zUO *2!& w0w 41'= w8w 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w4,$* !" #$%&1w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ L Y$* ($ F2+R &$ &,1 &1#<!'2? 41#>1# #$%&1# .$# &,1 .!'2? &!<1J 41'=?' 0D60zUO *2!& w0w ?$(+?$41



!"#" $% &'" ()*#+ ,$&'+-& )./ )00"0 *+((".&%1 2+&" &')& 3 -%"0 ). )4$)% +5 6$7 #"8#"%".&$.9 6%'+, $8

#+-&"%7 +. )44 (/ #+-&"#%: &!<1$%& h @N6 =!#1+&$#K h wIJx_K A$%&1# +$'.!(4xw !'"%&F$W wY2<1 $. ?$( .!?1 .$# &,!4 &14&Jw wI2??!4<2 A%?14w 4&#+$'+2& =!#1+&$#K !'"%&4&# ?$(.!?1'2<1 h =!#1+&$#K =!#1+&$#K h wIJx_K A$%&1# +$'.!(4xw J412#+,Z?$(.!?1 .!?1412#+, ?$(.!?1'2<1 !. #14%?&h6 ($&$ $"1'?$( !'"%&F$W w5'&1# '1* .!?1'2<1Jw w3!?1 2?#12=K 1W!4&4Lw 4&#+$'+2& =!#1+&$#K !'"%&4&# ?$(.!?1'2<1 h =!#1+&$#K =!#1+&$#K h wIJx_K A$%&1# +$'.!(4xw ($&$ 412#+,Z?$(.!?1 J$"1'?$( ?$($"1' ?$(.!?1'2<1 @ @ 41'=?' w4,$* +?$+Rw *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w!w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ 41'= w@w 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w!w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ 41'=?' 0D60zUO *2!& w0w 41'= wNw 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w



*2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w!w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ 41'=?' 0D60zUO *2!& w0w 41'= wDw 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w!w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ 41'=?' 0D60zUO *2!& w0w 41'= wQw 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w!w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @ 41'=?' 0D60zUO *2!& w0w 41'= w8w 41'=?' 0@D *2!& w0w 41'=?' w&1#< ?1'(&, 6w *2!& w0w 41'=?' w4,$* #%''!'(;+$'.!(w "2%41 @E 41'=?' w!w *2!& w0w 41'=?' w&1#< ?1'(&, QNw *2!& w0w "2%41 @



41'=?' 0D60zUO *2!& w0w ?$(+?$41



CCIE Study sheet

Essential Configurations for Cisco Routers and Switches

by Robert Webber CCIE 6922

© Copyright 2009, Robert Webber



CCIE Study Sheet - Foreword

The CCIE test is demanding. However your mental state of mind can have a dramatic outcome on your performance. Study the material well and be confident that you will succeed. There is tremendous power in positive thinking!

At some point a few days before you take the exam (when you are relaxed) visualize passing the test. Visualize walking into the lab, seeing the rack and getting handed the test. Visualize seeing several things (core topics) on the test that you know cold. There will also be some topics you are very unfamiliar with - this is expected. Part of the CCIE testing is seeing if you can react quickly. These are usually only worth a few points and are not incredibly difficult. Don't get psyched out by the exam!

Visualize yourself completing one task, then another, then another. Visualize completing the morning with many of the configuration tasks complete. Visualize finishing the day with an hour or so left to check your work (and please check it - there will be a few "stupid" mistakes. In fact, given the option of spending the final hour trying to get something to work that has alluded you, you're probably better off spending it reviewing for completeness all the things you've finished.)

Visualize getting your CCIE number and imagine what that will feel like.

Do this entire process several times; it will help reinforce your confidence. Make up your mind that you are going to study hard, prepare well, execute beautifully and pass the test!

R.W. February 21, 2001 CCIE 6922

3560Etherchannel

Layer 2 Etherchannels (recommended): !'&1#.2+1 #2'(1 .24&1&,1#'1&67@ ;N 4*!&+,"$#& <$=1 2++144 4*!&+,"$#& 2++144 >?2' D +,2''1?;(#$%" : <$=1 $'

Layer 3 Etherchannels: !'&1#.2+1 "$#&;+,2''1? Q '$ 4*!&+,"$#& !" 2==#144 @:NH@EOH@H@ N88HN88HN88H6 L



!'&1#.2+1 #2'(1 .24&1&,1#'1&67U;O '$ !" 2==#144 '$ 4*!&+,"$#& +,2''1?;(#$%" Q <$=1 $'

show etherchannel

FallBack Bridging F#!=(1 @ "#$&$+$? >?2';F#!=(1 F#!=(1 @ "#!$#!&K @EDOQ L !'&1#.2+1 PCXY @6 !" 2==#144 @6HOEH@H@ N88HN88HN88H6 F#!=(1;(#$%" @

L !'&1#.2+1 PCXY N6 !" 2==#144 @6HOEHNH@ N88HN88HN88H6 F#!=(1;(#$%" @

L !'&1#.2+1 324&5&,1#'1&67U '$ 4*!&+,"$#& !" 2==#144 @6HOEHDH@ N88HN88HN88H6 F#!=(1;(#$%" @

L

show bridge 1 group

Ports Access Ports:

!'& .267@U 4*!&+,"$#& <$=1 2++144 4*!&+,"$#& 2++144 >?2' N66 L !'&1#.2+1 #2'(1 324&5&,1#'1& 67@;Q 4*!&+,"$#& <$=1 2++144 4*!&+,"$#& 2++144 >?2' 86 L

Trunk Ports:

!'& .267@D 4*!&+,"$#& &#%'R 1'+2"4%?2&!$' =$&@S 4*!&+,"$#& <$=1 &#%'R L

Routed Ports:

!'&1#.2+1 324&5&,1#'1&67@ '$ 4*!&+,"$#& !" 2==#144 @:NH@EOHUEHN86 N88HN88HN88H6

Spanning Tree



PVST

4"2''!'(;&#11 <$=1 ">4& L &,!4 !4 &,1 =1.2%?& L L X?? &,1 .$??$*!'( +$<<2'=4 2""?K &$ F$&, [P)B 2'= A2"!= [P)B L

"#$%%&%'()!**+,-$%+.+! )+#!&/$!0+1+ %+)2*+#$$& 4*!&+, 4"2''!'(;&#11 >?2' N #$$& 41+$'=2#K L $' &,1 F2+R;%" #$$& 4*!&+, L !'&1#.2+1 .24&1&,1#'1& 67NQ 4"2''!'(;&#11 +$4& @66 4"2''!'(;&#11 "$#&;"#!$#!&K @E

show spanning-tree active show spanning-tree detail show spanning-tree interface interface-id show spanning-tree summary

Rapid PVST

4"2''!'(;&#11 <$=1 #2"!=;">4& L 4"2''!'(;&#11 %"?!'R.24& L %41.%? .$# 1=(1 -2++144/ 4*!&+,14 4"2''!'(;&#11 F2+RF$'1.24& L %41.%? $' +$#1 4*!&+,14 L !'&1#.2+1 .24&1&,1#'1& 67NN 4"2''!'(;&#11 "$#&.24& L %41= $' "$#&4 +$''1+&!'( &$ 1'= 4&2&!$'4

MSTP

4"2''!'(;&#11 <$=1 <4& L 4"2''!'(;&#11 <4& +$'.!(%#2&!$' !'4&2'+1 @ >?2' N;@6 '2<1 #1(!$'@ #1>!4!$' @ L 4"2''!'(;&#11 <4& @ #$$& "#!<2#K L @ !4 &,1 !'4&2'+1 != 4"2''!'(;&#11 <4& @ #$$& 41+$'=2#K L @ !4 &,1 !'4&2'+1 != L !'&1#.2+1 .24&1&,1#'1& 67NQ 4"2''!'(;&#11 <4& @ +$4& @66 L @ !4 &,1 !'4&2'+1 != 4"2''!'(;&#11 <4& @ "$#&;"#!$#!&K @E

show spanning-treemst 1 show spanning-treemst interface interface-id

VTP >&" <$=1 41#>1# >&" =$<2!' ?2F >&" "244*$#= +!4+$ >&" >1#4!$' N



>&" <$=1 +?!1'& >&" =$<2!' ?2F >&" "244*$#= +!4+$ >&" >1#4!$' N

show vtp status

Access ListsStandard Access Lists

2++144;?!4& @ "1#<!& @6HNH86H6 6H6H6HN88 2++144;?!4& @ "1#<!& @6H@6H6H6 6H6HN88HN88 !'&1#.2+1 41#!2? 67@ !" 2++144;(#$%" @ !' ?!'1 >&K 6;Q 2++144;+?244 @ !'

Extended Access Lists 2++144;?!4& @66 "1#<!& !" @UNH@OH6H6 6H6HN88HN88 @:NH@EOH@H6 6H6H6HN88 2++144;?!4& @6@ "1#<!& &+" @88H@ONH@6H6 6H6H6HN88 @:NHNDDH@Q8H6 6H6H6HN88 1S ND 2++144;?!4& @6@ "1#<!& %=" @6H6H6H6 6HN88HN88HN88 (& @6ND @:NH@EOH6H6 6H6HN88HN88 2++144;?!4& @6@ "1#<!& !+<" 2'K 2'K 1+,$;#1"?K #$%&1# 1!(#" N66 =!4&#!F%&1;?!4& @6@ $%&

Named Access Lists !" 2++144;?!4& -4&2'=2#=\1W&1'=1=/ '2<1$.?!4& "1#<!& !" N6OH@QHD8H6 6H6H6HN88 2'K "1#<!& &+" @88H@ONH6H6 6H6HN88HN88 1S O6 2'K

show access-list

Reflexive Access Lists)11 u3!#1*2??4v

Aliases 2?!24 1W1+ ! 4,$* !" #$%&1

BGP #$%&1# F(" E8666 '$ 4K'+,#$'!e2&!$' '1!(,F$# @6HNH@H@ #1<$&1;24 E866@ '1!(,F$# @6HNH@H@ =!4&#!F%&1;?!4& D !' '1!(,F$# @6H@6H@86HN #1<$&1;24 E8666 '1&*$#R @6H@6H@6H6 <24R N88HN88HN88H6 '1&*$#R @86H@86H6H6 '$ 2%&$;4%<<2#K



2++144;?!4& D "1#<!& @:NH@EOH@UH6 2++144;?!4& D "1#<!& @UNH@EH6H6

show ip bgp show ip bgp neighbor show ip bgp summary debug ip bgp updates

Filtering with Route-Maps #$%&1# F(" E8@@@ '1!(,F$# @6H@6H@6H@6 #1<$&1;24 E8NNN '1!(,F$# @6H@6H@6H@6 #$%&1;<2" c%&&$AQ $%& L !" "#1.!W;?!4& c%&&$AQ 41S 8 "1#<!& @UNH@UH6H67@E ?1 DN L #$%&1;<2" c%&&$AQ "1#<!& @6 <2&+, !" 2==#144 "#1.!W;?!4& c%&&$AQ

This config uses the same name for the route-map and prefix list (OuttoR4) for simplicity. It allows any route in the entire 172.17.0.0/16 class B range to be sent to BGP neighbor 10.10.10.10, but filters all others.

Filtering by AS_PATH Filtering by AS_PATH is important because you can filter all routes originating from a given AS, any routes that have been through (transited) an AS, etc. You will want to check out "Regular Expressions" later in this document (page 175). There are two basic ways to filter by AS_PATH:

1. Use the '1!(,F$# .!?&1#;?!4& command 2. Use a route-map

In either case you will define the AS_PATH you are looking for with the !" 24;"2&, 2++144;?!4& command. Here is an example of the route-map method. This config sends out to neighbor 172.16.40.5 any routes that originated in AS 200 (but drops all other advertisements to that neighbor): #$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' '1!(,F$# @UNH@EHQ6H8 #1<$&1;24 866 '1!(,F$# @UNH@EHQ6H8 #$%&1;<2" X)866.!?&1# $%& L !" 24;"2&, 2++144;?!4& @86 "1#<!& ZN66z L #$%&1;<2" X)866.!?&1# "1#<!& @6 <2&+, 24;"2&, @86

EBGP Peers between loopback addresses This configuration shows how to peer EBGP peers between loopback addresses as well as how to load balance traffic across two T1's:

,$4&'2<1 #@



L !'&1#.2+1 C$$"F2+R6 !" 2==#144 N6EHD6H6HUO N88HN88HN88HN88 L #$%&1# F(" QN:D '$ 4K'+,#$'!e2&!$' '1!(,F$# N6OH@UNH86HQ #1<$&1;24 D8E@ '1!(,F$# N6OH@UNH86HQ 1F(";<%?&!,$" N88 '1!(,F$# N6OH@UNH86HQ %"=2&1;4$%#+1 C$$"F2+R6 L !" #$%&1 N6OH@UNH86HQ N88HN88HN88HN88 )1#!2?676 !" #$%&1 N6OH@UNH86HQ N88HN88HN88HN88 )1#!2?67@ ,$4&'2<1 #N L !'&1#.2+1 C$$"F2+R6 !" 2==#144 N6OH@UNH86HQ N88HN88HN88HN88 L #$%&1# F(" D8E@ '$ 4K'+,#$'!e2&!$' '1!(,F$# N6EHD6H6HUO #1<$&1;24 QN:D '1!(,F$# N6EHD6H6HUO 1F(";<%?&!,$" N88 '1!(,F$# N6EHD6H6HUO %"=2&1;4$%#+1 C$$"F2+R6 L !" #$%&1 N6EHD6H6HUO N88HN88HN88HN88 )1#!2?6 !" #$%&1 N6EHD6H6HUO N88HN88HN88HN88 )1#!2?@

AS_PATH Prepending (Making theAS_PATH Longer) #$%&1# F(" E8DDD '$ 4K'+,#$'!e2&!$' '1&*$#R @UNH@UHNH6 <24R N88HN88HN88H6 '1&*$#R @UNH@EH@H6 <24R N88HN88HN88H6 '1!(,F$# @:NH@EOHQH@ #1<$&1;24 E8NNN '1!(,F$# @:NH@EOHQH@ #$%&1;<2" <2R1;24;"2&,;?$'(1# $%& L 2++144;?!4& @ "1#<!& @UNH@EH6H6 2++144;?!4& N "1#<!& 2'K L #$%&1;<2" <2R1;24;"2&,;?$'(1# "1#<!& @6 <2&+, !" 2==#144 @ 41& 24;"2&, "#1"1'= E8DDD E8DDD L #$%&1;<2" <2R1;24;"2&,;?$'(1# "1#<!& N6 <2&+, !" 2==#144 N

Route Map to Set Local Preference on Incoming Updates This example uses a route map to set local preference on all updates from neighbor 192.168.11.2 to 700. This will make the entire 65001 Autonomous System prefer updates received from this neighbor rather than updates on the same networks received from any other BGP neighbor (assuming no other Local Pref is set higher):

#$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' '1!(,F$# @:NH@EOH@@HN #1<$&1;24 E8666



'1!(,F$# @:NH@EOH@@HN #$%&1;<2" 41&C$+2?[#1. !' '$ 2%&$;4%<<2#K L #$%&1;<2" 41&C$+2?[#1. "1#<!& @6 41& ?$+2?;"#1.1#1'+1 U66 L

Route Map to Set MED on outgoing updates This example sets the MED (similar to a metric) to 200 on outgoing updates for the 172.17.0.0 and 172.30.0.0 networks sent to BGP neighbor 192.168.2.1. All other updates use the default MED (0). MEDs can influence how traffic is sent into your Autonomous System:

#$%&1# F(" E8DDD '1!(,F$# @:NH@EOHNH@ #1<$&1;24 E8NNN '1!(,F$# @:NH@EOHNH@ #$%&1;<2" 41&;_5m $%& L #$%&1;<2" 41&;_5m "1#<!& @6 <2&+, !" 2==#144 @ 41& <1&#!+ N66 L #$%&1;<2" 41&;_5m "1#<!& N6 <2&+, !" 2==#144 N L 2++144;?!4& @ "1#<!& @UNH@UH6H6 2++144;?!4& @ "1#<!& @UNHD6H6H6 2++144;?!4& N "1#<!& 2'K

Route Reflector Cluster Server (64.71.100.1): #$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' '1!(,F$# EQHU@H@66HQ #1<$&1;24 E866@ '1!(,F$# EQHU@H@66HQ #$%&1;#1.?1+&$#;+?!1'& '1!(,F$# EQHU@H@66H8 #1<$&1;24 E866@ '1!(,F$# EQHU@H@66H8 #$%&1;#1.?1+&$#;+?!1'&

A Client (64.71.100.4): #$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' '1!(,F$# EQHU@H@66H@ #1<$&1;24 E866@

Aggregate Address Here all four BGP networks are summarized into one aggregate and all other advertisements (the actual /24 networks) are suppressed: !'&1#.2+1 C$$"F2+R:6 !" 2==#144 @UNHNQH@H@ N88HN88HN88H6 L !'&1#.2+1 C$$"F2+R:@ !" 2==#144 @UNHNQHNH@ N88HN88HN88H6 L !'&1#.2+1 C$$"F2+R:N !" 2==#144 @UNHNQHN8QH@ N88HN88HN88H6 L



!'&1#.2+1 C$$"F2+R:D !" 2==#144 @UNHN8HDH@ N88HN88HN88H6 L #$%&1# F(" E866N '$ 4K'+,#$'!e2&!$' F(" ?$(;'1!(,F$#;+,2'(14 '1&*$#R @UNHNQH@H6 <24R N88HN88HN88H6 '1&*$#R @UNHNQHNH6 <24R N88HN88HN88H6 '1&*$#R @UNHNQHN8QH6 <24R N88HN88HN88H6 '1&*$#R @UNHN8HDH6 <24R N88HN88HN88H6 2((#1(2&1;2==#144 @UNHNQH6H6 N88HN8QH6H6 4%<<2#K;$'?K '1!(,F$# @UNHD@HNHD #1<$&1;24 E866D '$ 2%&$;4%<<2#K

Here three aggregate advertisements are generated. All other advertisements in the 192.168.1.0/24 and 192.168.2.0/24 ranges are suppressed. An aggregate of 10.8.0.0/13 will be advertised. Any other advertisements in this range will be advertised normally. #$%&1# F(" E8NNN '$ 4K'+,#$'!e2&!$' '1&*$#R @:NH@EOH@HEQH6 <24R N88HN88HN88H@:N '1&*$#R @:NH@EOH@H@NOH6 <24R N88HN88HN88HNNQ '1&*$#R @:NH@EOHNH@:NH6 <24R N88HN88HN88HNQ6 '1&*$#R @6HOHDNH6 <24R N88HN88HN88H6 '1&*$#R @6H:H6H6 <24R N88HN88H6H6 '1&*$#R @6H@6H@E6H6 <24R N88HN88HN8QH6 2((#1(2&1;2==#144 @6HOH6H6 N88HNQOH6H6 2((#1(2&1;2==#144 @:NH@EOH@H6 N88HN88HN88H6 4%<<2#K;$'?K 2((#1(2&1;2==#144 @:NH@EOHNH6 N88HN88HN88H6 4%<<2#K;$'?K '$ 2%&$;4%<<2#K

Authentication -MD5 BGP MD5 authentication is enabled with just a single command. Two neighbors must agree on the password, but different sets of neighbors can have their own passwords:

#$%&1# F(" E866D '1!(,F$# @6H@H@H@ "244*$#= &,!4!4<K"244*4$#=

You can also assign a password for all members of a peer group. In this case all remote neighbors must use that exact password:

#$%&1# F(" E866D '1!(,F$# "11#(#$%"@ "244*$#= [244*4$#=3$#B,1[11#M#$%"

Bridging (Routers)

Global F#!=(1 @ "#$&$+$? !111 F#!=(1 @ "#!$#!&K @66



Interface !'&1#.2+1 16 F#!=(1;(#$%" @ F#!=(1;(#$%" @ "2&,;+$4& 86 !'&1#.2+1 41#!2? @ F#!=(1;(#$%" @

show bridge

DHCP Often - both when studying for the CCIE exam and even in real life (imagine that - something that is useful in both cases!), I find it useful to make the router a DHCP server. For example my laptop is configured for DHCP (for work, etc.), yet when I take my laptop home I do not have a DHCP server to assign me an address. To configure your router as a DHCP server, use the following:

L X==#14414 H@ ; H@6 2#1 %4%2??K %41= .$# '1&*$#R =1>!+14T 4$ L *1 *!?? 1W+?%=1 &,1< .#$< mÎ[J L !" =,+" 1W+?%=1=;2==#144 @UNH@EHEQH@ @UNH@EHEQH@6 L L B,1 ?1241 +$<<2'= %414 =2K4 ,$%#4 <!'%&14 24 &,1 &,#11 L R1K*$#=4H B,!4 +#12&14 @6 <!'%&1 ?12414 -6 =2K4T 6 ,$%#4T L @6 <!'%&14/H j$%y?? "#$F2F?K *2'& &$ <2R1 &,1 L ?1241 &!<1 <%+, ?$'(1#J L !" =,+" "$$? <K"$$? '1&*$#R @UNH@EHEQH6 N88HN88HN88H6 =1.2%?&;#$%&1# @UNH@EHEQH@ =$<2!';'2<1 +2??!4<2H+$< ='4;41#>1# @::HQ8HDNHDU $"&!$' @86 !" @6HDQHN@8H@ L +2' 244!(' 4"1+!.!+ mÎ[ $"&!$'4 ?1241 6 6 @6

If you need to assign your PC the exact same address every time, you can create a specific reservation within DHCP based on your MAC address. That configuration is: L B,1 w+?!1'&;!=1'&!.!1#w !4 &,1 _XI 2==#144H B,1 "$$? '2<1 +2' L F1 2'K&,!'( 9 d (2>1 !& <K '2<1 &$ #1<!'= <1 !&4 <K _XI L 2==#144H ^1#1 d *!?? 2?*2K4 #1+1!>1 2==#144 @6H8HNNH@6H L Y$&1 &,2& <K _XI 2==#144 !4 66;@6;2Q;F8;=@;=6T ,$*1>1# L &,1 +$'.!(%#2&!$' #1S%!#14 2 u6@v !' .#$'& $. &,1 L _XI 9 '$& 4%#1 *,KH L !" =,+" "$$? #$F*1FF1# ,$4& @6H8HNNH@6 N88HN88HN88H6 +?!1'&;!=1'&!.!1# 6@66H@62QHF8=@H=6 =1.2%?&;#$%&1# @6H8HNNHN86 ='4;41#>1# @88H@6OHD:HN66 =$<2!';'2<1 4&2&1H+$< ?1241 6 E



Note that only certain versions of IOS support the DHCP server functionality. In some versions you may need the "T" technology train version of IOS.

show ip dhcp binding show ip dhcp conflict

To configure a router as a DHCP relay (for use with an external DHCP server), use the interface command:

!'&1#.2+1 M!2(F!&5&,1#'1&676 !" ,1?"1#;2==#144 @6H@EH@HN

Implementing DHCP in MPLS VPNs can be complicated, since different VPNs on the same router can share the same subnets. That is, an MPLS router can have two 10.10.10.0/24 subnets - but in different MPLS VPNs. To allow for this use the following commands. Here both interfaces can service the same IP address range and use the same DHCP server (@6H@QH8EHU), but are associated with different MPLS VPNs: !" =,+" #1?2K !'.$#<2&!$' $"&!$' >"' L !'&1#.2+1 324&5&,1#'1&676 !" ,1?"1#;2==#144 >#. P[Y@ @6H@QH8EHU L !'&1#.2+1 324&5&,1#'1&67@ !" ,1?"1#;2==#144 >#. P[YN @6H@QH8EHU L

EIGRP !'&1#.2+1 41#!2?6 !" 4%<<2#K;2==#144 1!(#" @ @UEH@QH6H6 N88HN88H6H6 '$ !" 4"?!&;,$#!e$' 1!(#" @ L #$%&1# 1!(#" @ '$ 2%&$;4%<<2#K '1&*$#R NQH6H6H6 '1&*$#R @UEH@QH6H6 '1&*$#R N66H@H@88H6 =!4&#!F%&1;?!4& @6U !' 41#!2?6

debug ip routing debug ip eigrp debug ip eigrp neighbor 2 1.1.1.1 (where 2 = AS number and 1.1.1.1 = neighbor address)

Authentication -MD5 !'&1#.2+1 32676 !" 2%&,1'&!+2&!$' <$=1 1!(#" @ <=8



!" 2%&,1'&!+2&!$' R1K;+,2!' 1!(#" @ i1KI,2!'Y2<1 L R1K +,2!' i1KI,2!'Y2<1 R1K @ R1K;4&#!'( @ND@ND@ND 2++1"&;?!.1&!<1 @NJ6@J6@ {2' @ N66: !'.!'!&1 41'=;?!.1&!<1 @NJ6@J6@ {2' @ N66: !'.!'!&1

Firewalls

Context Based Access Control (CBAC)

Applying CBAC inbound on the inside interface: !" !'4"1+& '2<1 <K.!#1*2?? .&" !" !'4"1+& '2<1 <K.!#1*2?? &+" L !'&1#.2+1 5&,1#'1& 676 -!'4!=1 !'&1#.2+1/ !" !'4"1+& <K.!#1*2?? !' L !'&1#.2+1 41#!2? 676 -$%&4!=1 !'&1#.2+1/ !" 2++144;(#$%" @66 !' L 2++144;?!4& @66 =1'K !" 2'K 2'K

Applying CBAC outbound on the outside interface. Inbound traffic is allowed to host 10.20.30.250: !" !'4"1+& '2<1 .!#1*2??;@ &+" !" !'4"1+& 2%=!&;&#2!? L !'&1#.2+1 324&5&,1#'1& 67@ -!'4!=1 !'&1#.2+1/ !" 2==#144 @6HN6HD6H@ N88HN88HN88H6 L !'&1#.2+1 41#!2? N76 -$%&4!=1 !'&1#.2+1/ !" !'4"1+& .!#1*2??;@ $%& !" 2++144;(#$%" @86 !' L 2++144;?!4& @86 "1#<!& &+" 2'K ,$4& @6HN6HD6HN86 1S *1F 2++144;?!4& @86 =1'K !" 2'K 2'K

show ip inspect name firewall-name show ip inspect config show ip inspect interfaces debug ip inspect events debug ip inspect detail

Zone Based Firewall +?244;<2" <2&+,;2'K d'&1#'2?ZB#2..!+ <2&+, 2++144;(#$%" '2<1 d'&1#'2?ZB#2..!+ +?244;<2" <2&+,;2'K m_|ZB#2..!+ <2&+, 2++144;(#$%" '2<1 m_|ZB#2..!+ L "$?!+K}<2" &K"1 !'4"1+& d'&1#'2?ZB#2..!+Z[$?!+K



+?244 &K"1 !'4"1+& d'&1#'2?ZB#2..!+ !'4"1+& L "$?!+K}<2" &K"1 !'4"1+& m_|ZB#2..!+Z[$?!+K +?244 &K"1 !'4"1+& m_|ZB#2..!+ !'4"1+& L e$'1 41+%#!&K d'&1#'1& e$'1 41+%#!&K m_| e$'1 41+%#!&K d'&1#'2? L e$'1}"2!# 41+%#!&K d'&1#'1&;m_| 4$%#+1 d'&1#'1& =14&!'2&!$' m_| 41#>!+1}"$?!+K &K"1 !'4"1+& e$'1}"2!# 41+%#!&K m_|;d'&1#'2? 4$%#+1 m_| =14&!'2&!$' d'&1#'2? 41#>!+1}"$?!+K &K"1 !'4"1+& L !'&1#.2+1 M!(2F!&5&,1#'1& 676 =14+#!"&!$' d'&1#'1& !'&1#.2+1 e$'1;<1<F1# d'&1#'1& L !'&1#.2+1 M!(2F!&5&,1#'1& 67@ =14+#!"&!$' m_| !'&1#.2+1 e$'1;<1<F1# m_| L !'&1#.2+1 M!(2F!&5&,1#'1& N76 =14+#!"&!$' d'&1#'2? !'&1#.2+1 e$'1;<1<F1# d'&1#'2? L !" 2++144;?!4& 1W&1'=1= m_|ZB#2..!+ "1#<!& &+" 2'K ,$4& @6H@@H@NH@D 1S *** "1#<!& &+" 2'K ,$4& @6H@@H@NH@D 1S QQD "1#<!& &+" 2'K ,$4& @6H@@H@NHQ6 1S 4<&" L !" 2++144;?!4& 1W&1'=1= d'&1#'2?ZB#2..!+ "1#<!& &+" ,$4& @6H@@H@NH@D 2'K "1#<!& &+" ,$4& @6H@@H@NHQ6 2'K

Reflexive Access Lists !'&1#.2+1 )1#!2? @ =14+#!"&!$' X++144 &$ &,1 d'&1#'1& >!2 &,!4 !'&1#.2+1 !" 2++144;(#$%" !'F$%'=.!?&1#4 !' !" 2++144;(#$%" $%&F$%'=.!?&1#4 $%& L !" #1.?1W!>1;?!4& &!<1$%& @N6 L !" 2++144;?!4& 1W&1'=1= $%&F$%'=.!?&1#4 "1#<!& &+" 2'K 2'K #1.?1+& &+"&#2..!+ L !" 2++144;?!4& 1W&1'=1= !'F$%'=.!?&1#4 "1#<!& F(" 2'K 2'K "1#<!& 1!(#" 2'K 2'K =1'K !+<" 2'K 2'K 1>2?%2&1 &+"&#2..!+

Lock and Key Access !'&1#.2+1 41#!2? 6



!" 2==#144 @UNH@UH@H@ N88HN88HN88H6 !" 2++144;(#$%" @6@ !' L 2++144;?!4& @6@ "1#<!& &+" 2'K ,$4& @UNH@UH@H@ 1S &1?'1& 2++144;?!4& @6@ =K'2<!+ =%''$ "1#<!& !" 2'K 2'K L ?!'1 >&K 6 Q "244*$#= <K"244*$#= ?$(!' 2%&$+$<<2'= 2++144;1'2F?1

This works, however everyone who telnets to the router activates the autocommand and gets disconnected - not very useful! A better way is: %41#'2<1 F$F "244*$#= 6 +!4+$ %41#'2<1 F$F 2%&$+$<<2'= 2++144;1'2F?1 %41#'2<1 4%1 "244*$#= 6 <K"244 !'&1#.2+1 41#!2? 6 !" 2==#144 @UNH@UH@H@ N88HN88HN88H6 !" 2++144;(#$%" @6@ !' L 2++144;?!4& @6@ "1#<!& &+" 2'K ,$4& @UNH@UH@H@ 1S &1?'1& 2++144;?!4& @6@ =K'2<!+ =%''$ "1#<!& !" 2'K 2'K L ?!'1 >&K 6 Q "244*$#= <K"244*$#= ?$(!' ?$+2?

Frame Relay

Frame Relay Switching .#2<1;#1?2K 4*!&+,!'( !'&1#.2+1 46 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K !'&.;&K"1 =+1 -''! !. +$''1+&!'( &$ 2'$&,1# .#2<1 4*!&+,/ .#2<1;#1?2K #$%&1 @66 !'&1#.2+1 4@ @86 -!';=?+! $%&;!'&1#.2+1 $%&; =?+!/ +?$+R #2&1 8@N666 -!. %4!'( 2 mI5 +2F?1/

Frame Relay d'&1#.2+1 46 d" 2==#144 @UNHNQH@H@H N88HN88HN88H6 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K <2" !" @UNHNQH@HN DD6 F#$2=+24& .#2<1;#1?2K <2" !" @UNHNQH@HD DQ6 F#$2=+24&

Or&

!'&1#.2+1 46 '$ !" 2==#144 1'+2"4%?2&!$' .#2<1;#1?2K

!'&1#.2+1 46H@ "$!'&;&$;"$!'& !" 2==#144 @UNHNQH@H@ N88HN88HN88H6



.#2<1;#1?2K !'&1#.2+1;=?+! DD6

!'&1#.2+1 46HN "$!'&;&$;"$!'& !" 2==#144 @UNHNQHNH@ N88HN88HN88H6 .#2<1;#1?2K !'&1#.2+1;=?+! DQ6

Or&

!'&1#.2+1 46 '$ !" 2==#144 1'+2"4%?2&!$' .#2<1;#1?2K !'&1#.2+1 46H@ <%?&!"$!'& !" 2==#144 @:NH@EOH@H@ N88HN88HN88H6 .#2<1;#1?2K <2" !" @:NH@EOH@HN @6@ F#$2=+24& .#2<1;#1?2K <2" !" @:NH@EOH@HD @6N F#$2=+24&

debug frame packet show frame pvc show frame map

Frame Relay Traffic Shaping!'&1#.2+1 46

.#2<1;#1?2K &#2..!+;4,2"!'(

.#2<1;#1?2K +?244 1W2<"?1@ -r; .$# 2?? mCIdy4/

.#2<1;#1?2K !'&1#.2+1;=?+! @6@

+?244 1W2<"?1@ -r; $' 2 "1#;mCId F24!4/

L <2";+?244 .#2<1;#1?2K 1W2<"?1@ .#2<1;#1?2K "#!$#!&K;(#$%" U -r; "#!$#!&K S%1%!'(T $# .#2<1;#1?2K +%4&$<;S%1%1;?!4& D r; +%4&$< S%1%!'(/ .#2<1;#1?2K +!# @NO666 .#2<1;#1?2K F+ N8E666 .#2<1;#1?2K 2=2"&!>1;4,2"!'( F1+' L "#!$#!&K;?!4& U "#$&$+$? !" ,!(, "#!$#!&K;?!4& U "#$&$+$? !" '$#<2? ?!4& @86

L S%1%1;?!4& D "#$&$+$? !" @@ S%1%1;?!4& D "#$&$+$? !" @N ?!4& @86 S%1%1;?!4& D "#$&$+$? !" @6 &+" &1?'1& S%1%1;?!4& D =1.2%?& @D S%1%1;?!4& D S%1%1 @6 FK&1;+$%'& D666 S%1%1;?!4& D S%1%1 @@ FK&1;+$%'& N666 S%1%1;?!4& D S%1%1 @N FK&1;+$%'& @666 S%1%1;?!4& D S%1%1 @D FK&1;+$%'& @666

HSRP

This creates two HSRP groups on the same interface. Router A is primary for group 1; Router B is primary for group 2. Both primary routers are tracking their serial 0/0 interfaces. Should either router's serial 0/0 fail, it will drop to priority 95 (default has tracking drop priority by 10). The other



router will have (the default) priority of 100 and thus will become primary for that group as well. Group 1 also uses authentication.

Router A: 4&2'=FK @ !" @UNHNQH@H@ 4&2'=FK @ "#!$#!&K @68 4&2'=FK @ "#11<"& -($$= !=12 &$ %41 &,!4L/ 4&2'=FK @ 2%&,1'&!+2&!$' +!4+$ 4&2'=FK @ &#2+R 41#!2? 676 4&2'=FK N !" @UNHNQH@HN 4&2'=FK N "#11<"&

Router B: 4&2'=FK @ !" @UNHNQH@H@ 4&2'=FK @ "#11<"& -($$= !=12 &$ %41 &,!4L/ 4&2'=FK @ 2%&,1'&!+2&!$' +!4+$ 4&2'=FK N !" @UNHNQH@HN 4&2'=FK N "#!$#!&K @68 4&2'=FK N "#11<"& 4&2'=FK N &#2+R 41#!2? 676

show standby

ISAKMP

Note: ISAKMP uses UDP port number 500 (ACLs).

For any ISAKMP (using pre-shared keys or RSA encrypted nonces): +#K"&$ !42R<" "$?!+K @ 1'+#K"&!$' =14 ,24, <=8 2%&,1'&!+2&!$' n#42;1'+#\"#1;4,2#1o (#$%" @ -41&4 &,1 m!..1;^1??<2' (#$%"/ ?!.1&!<1 DE66

For ISAKMP using RSA encrypted nonces: +#K"&$ R1K (1'1#2&1 #42

4,$* +#K"&$ R1K <K"%FR1K #42 -&$ 4,$* K$%# "%F?!+ R1K *,!+, *24 t%4& (1'1#2&1= FK &,1 "#1>!$%4 +$<<2'=/ +#K"&$ R1K "%FR1K;+,2!' #42 2==#1441=;R1K +16#%%*)226!:6*)"!/)61))*

R1K;4&#!'( 1'(.+ 6A)06+%)$/+:+)%6#/6 !!"63+/86v4,$* +#K"&$ R1K <K"%FR1K #42v +$<<2'=

Repeat the last few commands at each peer.

For ISAKMP using pre-shared keys: +#K"&$ !42R<" R1K A)02/*+$7 2==#144 #%%*)226!:6*)"!/)61))*&

Repeat these steps at each peer with the identical key.

IPSEC



Note: The IPSec ESP and AH protocols use IP protocol numbers 50 and 51 (ACLs).

Manual IPSec security associations: +#K"&$ !"41+ &#2'4.$#<;41& <K41& 14";=14 L +#K"&$ <2" <K<2" ?$+2?;2==#144 C$$"F2+R@ +#K"&$ <2" <K<2" @6 !"41+;<2'%2? 41& "11# @6HOH@H@ 41& 4144!$';R1K !'F$%'= 14" @666 +!",1# @NDQ8EUO@NDQ8EUO 41& 4144!$';R1K $%&F$%'= 14" @666 +!",1# @NDQ8EUO@NDQ8EUO 41& &#2'4.$#<;41& <K41& <2&+, 2==#144 @66 !'&1#.2+1 41#!2? 6 +#K"&$ <2" <K<2" L 2++144;?!4& @66 "1#<!& !" @6H@HNH6 6H6H6HN88 @6HOH@H6 6H6H6HN88

ISAKMP negotiated IPSec security associations: -+$'.!(%#1 d)Xi_[T &,1'q/ +#K"&$ !"41+ &#2'4.$#<;41& <K41& 14";=14 14";4,2 +#K"&$ !42R<" R1K <K"244*$#= 2==#144 @6HOH@H@ +#K"&$ <2" <K<2" @6 !"41+;!42R<" <2&+, 2==#144 @66 41& "11# @6HOH@H@ 41& &#2'4.$#<;41& <K41& !'&1#.2+1 5&,1#'1& 6 +#K"&$ <2" <K<2" L 2++144;?!4& @66 "1#<!& !" @:NH@EOH@H6 6H6H6HN88 @UNH@EH6H6 6H6HN88HN88

If a router has more than one IPSec peer, simply add more sequences to the crypto map, one for each remote peer.

show crypto isakmp sa show crypto isakmp policy debug crypto isakmp show cryptomap %QMO (./"$M 1"%&( %)

debug crypto ipsec

IPv6

Access-Lists & Filtering !'&1#.2+1 3X67@ !">E &#2..!+;.!?&1# F?$+RZ#@ $%& L !">E 2++144;?!4& F?$+RZ#@ "1#<!& %=" 2'K 1S #!" 2'K "1#<!& %=" 2'K 2'K 1S #!"



"1#<!& &+" 2'K 2'K =1'K !+<" ,$4& @6J@6J@6JJ@ ,$4& D66JD66JD66JJD ?$(;!'"%& "1#<!& %=" 2'K 2'K 1S 8N@ "1#<!& !">E ,$4& @6J@6J@6JJ@ 2'K

EIGRP !'&1#.2+1 M!(2F!&5&,1#'1&676 !">E 2==#144 D6X6JGO66J6JIXJJ7EQ 1%!;EQ !">E 1!(#" @ L !'&1#.2+1 M!(2F!&5&,1#'1&67@ !">E 2==#144 D6X6JGO66J@JIGJJ7EQ 1%!;EQ !">E 1!(#" @ L !">E #$%&1# 1!(#" @ <1&#!+ *1!(,&4 6 N88 N88 N88 @66 @86 =!4&#!F%&1;?!4& "#1.!W;?!4& X++1"&ZA$%&14Zd' !' =!4&#!F%&1;?!4& "#1.!W;?!4& X=>1#&!41ZA$%&14Zc%& $%& #1=!4&#!F%&1 #!" ?2F L

OSPF !'&1#.2+1 41#!2? 676 !">E $4". @ 2#12 6 L !">E #$%&1# $4". @ ?$(;2=t2+1'+K;+,2'(14 =1.2%?&;<1&#!+ @666 #1=!4&#!F%&1 4&2&!+

Tunneling Router A Configuration !'&1#.2+1 C$$"F2+R 6 !" 2==#144 @UNH@EHQ8H@ N88HN88HN88H6 L !'&1#.2+1 &%''1? 6 !">E 2==#144 @J@JNJ@JJN7@NE &%''1? 4$%#+1 C$$"F2+R 6 &%''1? =14&!'2&!$' @UNHN@H@:@H@ &%''1? <$=1 !">E!" !">E #!" ,$(*2#&4 1'2F?1

Router B Configuration !'&1#.2+1 C$$"F2+R 6 !" 2==#144 @UNHN@H@:@H@ N88HN88HN88H6 L !'&1#.2+1 &%''1? 6 !">E 2==#144 @J@JNJ@JJD7@NE &%''1? 4$%#+1 C$$"F2+R 6 &%''1? =14&!'2&!$' @UNH@EHQ8H@ &%''1? <$=1 !">E!" !">E #!" ,$(*2#&4 1'2F?1

MPLS



Here is an example config of a PE router (10.10.10.10) running MPLS with another PE router (10.20.20.20) and sharing routes with a CE router (10.30.30.30) using BGP:

PE Router Config: <"?4 ?2F1? "#$&$+$? ?=" <"?4 ?=" #$%&1#;!= ?$$"F2+R6 .$#+1 L !'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @6H@6H@6H@6 N88HN88HN88HN88 L !'&1#.2+1 M!(2F!&5&,1#'1&676 =14+#!"&!$' I$''1+&!$' &$ [5 #$%&1# !" 2==#144 @6HN8HN8HN8 N88HN88HN88H6 <"?4 !" L !'&1#.2+1 M!(2F!&5&,1#'1&67@ =14+#!"&!$' I$''1+&!$' &$ +%4&$<1#@ !" 2==#144 @6HD8HD8HD8 N88HN88HN88H6 !" >#. .$#*2#=!'( +%4&$<1#@ L !" >#. +%4&$<1#@ #= E8666J@ #$%&1;&2#(1& F$&, E8666J@ L #$%&1# F(" E8666 '$ 4K'+,#$'!e2&!$' '1!(,F$# @6HN6HN6HN6 #1<$&1;24 E8666 L !GM[ $.&1' %414 ?$$"F2+R4 '1!(,F$# @6HN6HN6HN6 %"=2&1;4$%#+1 C$$"F2+R6 L 2==#144;.2<!?K >"'>Q '1!(,F$# @6HN6HN6HN6 2+&!>2&1 '1!(,F$# @6HN6HN6HN6 41'=;+$<<%'!&K 1W&1'=1= 1W!&;2==#144;.2<!?K L 2==#144;.2<!?K !">Q %'!+24& >#. +%4&$<1#@ '1!(,F$# @6HD8HD8HDE #1<$&1;24 EQ866 '1!(,F$# @6HD8HD8HDE 2+&!>2&1 '$ 4K'+,#$'!e2&!$' '$ 2%&$;4%<<2#K 1W!&;2==#144;.2<!?K

CE Router Config: !'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @6HD6HD6HD6 N88HN88HN88HN88 L !'&1#.2+1 324&5&,1#'1&676 =14+#!"&!$' I$''1+&!$' &$ [5 #$%&1# !" 2==#144 @6HD8HD8HDE N88HN88HN88H6 L #$%&1# F(" EQ866 '1!(,F$# @6HD8HD8HD8 #1<$&1;24 E8666 L 2==#144;.2<!?K !">Q '1&*$#R @:NH@EOH@8H6 <24R N88HN88HN88H6



'1!(,F$# @6HD8HD8HD8 2+&!>2&1 '$ 4K'+,#$'!e2&!$' '$ 2%&$;4%<<2#K 1W!&;2==#144;.2<!?K

show ip vrf [{brief | detail | interfaces}] vrf2 show ip route vrf vrf2 show ip protocols vrf vrf2 show ip bgp vpnv4 all debugmpls adjacency debugmpls events

MulticastIGMP

A$%&1#-+$'.!(/0!'&1#.2+1 5&,1#'1& 6 A$%&1#-+$'.!(;!./0!" !(<" t$!';(#$%" NNQH@HNHD I$'4$?1-+$'.!(/041& !(<" 1'2F?1 I$'4$?1-+$'.!(/041& <%?&!+24& #$%&1# D78 -#1S%!#1= .$# dM_[/

CGMP A$%&1#-+$'.!(/0!'&1#.2+1 5&,1#'1& 6 A$%&1#-+$'.!(;!./0!" +(<" I$'4$?1-+$'.!(/041& +(<" 1'2F?1

PIM - Dense Mode !" <%?&!+24&;#$%&!'( L !'&1#.2+1 41#!2? 6 !" "!< =1'41;<$=1 L !'&1#.2+1 1&,1#'1& 6 !" "!< =1'41;<$=1 !" !(<" t$!';(#$%" NN8H@H@H@ -"?2+1 &,!4 $' &$ &14& 9 4,$%?= F1 "!'(2F?1/

PIM - Sparse Mode (Static Rendezvous Point) !" <%?&!+24&;#$%&!'( !" "!< #";2==#144 #%%*)22&!:&*)$%)-!'2&*!'/)*& L !'&1#.2+1 41#!2? 6 !" "!< 4"2#41;<$=1 !'&1#.2+1 1&,1#'1& 6 !" "!< 4"2#41;<$=1 !" !(<" t$!';(#$%" NN8H@H@H@ -"?2+1 &,!4 $' &$ &14& 9 4,$%?= F1 "!'(2F?1/

PIM - Sparse-Dense Mode (Automatic Rendezvous Point) !" <%?&!+24&;#$%&!'( !" "!< 41'=;#";=!4+$>1#K 4+$"1 N88 -$'?K #1S%!#1= $' &,1 A[/



!" "!< 41'=;#";2''$%'+1 1&,1#'1& 6 4+$"1 N88 -$'?K #1S%!#1= $' &,1 A[/ L !'&1#.2+1 41#!2? 6 !" "!< 4"2#41;=1'41;<$=1 !'&1#.2+1 1&,1#'1& 6 !" "!< 4"2#41;=1'41;<$=1 !" !(<" t$!';(#$%" NN8H@H@H@ -"?2+1 &,!4 $' &$ &14& 9 4,$%?= F1 "!'(2F?1/

show ipmroute show ip pim neighbor show ip pim interface show ip pim rp show ip igmp groups debug ip pim

Netflow !" .?$*;1W"$#& =14&!'2&!$' @6H@H@H@ L !" .?$*;1W"$#& >1#4!$' : L -$"&!$'2?/ !" .?$* 1W"$#& 4$%#+1 C$$"F2+R6 L -$"&!$'2?/ !" .?$*;+2+,1 1'&#!14 866 L -$"&!$'2?/ L !'&1#.2+1 32676 !" .?$* !'(#144

show ip cache flow show ip cache verbose flow

Network Address Translation (NAT)

Outgoing - Source Addresses Static: !" '2& !'4!=1 4$%#+1 4&2&!+ @6H@8HN6H@ N6QH@:DHNQH8 L !'&1#.2+1 1&,1#'1&6 !" '2& !'4!=1 L !'&1#.2+1 41#!2?6 !" '2& $%&4!=1

Dynamic:

!" '2& "$$? <K"$$? N6UHNQNH@66H@ N6UHNQNH@66H86 '1&<24R N88HN88HN88H6 !" '2& !'4!=1 4$%#+1 ?!4& @ "$$? <K"$$? !-)*.!#% L !'&1#.2+1 1&,1#'1&6 !" '2& !'4!=1 L



!'&1#.2+1 41#!2?6 !" '2& $%&4!=1 L 2++144;?!4& @ "1#<!& @:NH@EOHNH6 6H6H6HN88

Incoming - Source Addresses Static:

!" '2& "$$? '1&;@6 @6H6H@H6 @6H6H@HN88 "#1.!W;?1'(&, NQ

!" '2& $%&4!=1 4$%#+1 ?!4& @ "$$? '1&;@6

L

!'&1#.2+1 1&,1#'1& 6

!" 2==#144 @U@HE:HNDNH@ON N88HN88HN88HNQ6

!" '2& $%&4!=1

L

!'&1#.2+1 1&,1#'1& @

!" 2==#144 :H@@QH@@HD: N88HN88HN88H6

!" '2& !'4!=1

L

2++144;?!4& @ "1#<!& :H@@QH@@H6 6H6H6HN88

(On inbound packets with a source address of 9.114.11.0/24, the source address is translated to the 10.0.1.0/24 range. This would be useful if the 9.114.11.0/24 range was "illegally" used within your network. In that case you would need to change the source address to be able to correctly route the packets back - rather than routing them to the duplicate 9.114.11.0 subnet within your own network.)

ip nat outside · translates the source of the IP packets source list (or that are traveling outside to inside static) · translates the destination of the IP

packets that are traveling inside to outside

ip nat inside source list · translates the source of IP packets that(or static) are traveling inside to outside

· translates the destination of the IP packets that are traveling outside to inside

show ip nat translations show ip nat statistics clear ip nat translation *

NTP



Clock and date commands #@-+$'.!(/0 +?$+R &!<1e$'1 5)B ;8 #@-+$'.!(/0 +?$+R 4%<<1#;&!<1 5mB #1+%##!'( #@-+$'.!(/0 '&" %"=2&1;+2?1'=2# (if the machine has a permanent calendar) #N0 +2?1'=2# 41& @6J68J66 Q X"#!? N666 (if the machine has a permanent calendar) #N-+$'.!(/0 +?$+R +2?1'=2#;>2?!= (if the machine has a permanent calendar) #N0 +?$+R 41& @6J68J66 Q X"#!? N66@ (only if the machine doesn't have a permanent calendar)

Using one Device as an NTP Server Server: !'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @:NH@EOHN8QH@ N88HN88HN88H6 '&" <24&1# 8

Client: '&" 41#>1# @:NH@EOHN8QH@

Restricting Access to an NTP Server Server: !'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @:NH@EOHN8QH@ N88HN88HN88H6 '&" <24&1# 8 2++144;?!4& @ "1#<!& @UNH@EHNQH@ '&" 2++144;(#$%" 41#>1 @

Client: !'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @UNH@EHNQH@ N88HN88HN88H6 '&" 4$%#+1 C$$"F2+R6 '&" 41#>1# @:NH@EOHN8QH@

Configuring NTP Authentication Server:

'&" 2%&,1'&!+2&1

'&" 2%&,1'&!+2&!$';R1K @ <=8 !(%2'2

'&" &#%4&1=;R1K @

Clients:'&" 2%&,1'&!+2&1

'&" 2%&,1'&!+2&!$';R1K @ <=8 !(%2'2

'&" &#%4&1=;R1K @ '&" 41#>1# @:NH@EOHDOHO R1K @

show clock show ntp association show ntp status

OSPFBasic

!'&1#.2+1 41#!2? 6



!" $4". '1&*$#R "$!'&;&$;<%?&!"$!'& !" $4". "#!$#!&K @6 !" $4". +$4& @86 #$%&1# $4". @66 '1&*$#R @6H@NH@Q6H@NO 6H6H6H@NU 2#12 6 '1&*$#R @86H@86H6H6 6H6HN88HN88 2#12 @ '1&*$#R @:NH@EOHOOH6 6H6H6HN88 2#12 N

show ip ospf show ip ospf neighbor show ip ospf interface debug ip ospf adjacencies debug ip routing

Summarization #$%&1# $4". 8 '1&*$#R @6HQH6H6 6H6H6HN88 2#12 6 '1&*$#R @6H@6H@Q6H@NO 6H6H6H@NU 2#12 Q 2#12 Q #2'(1 @6H@6H6H6 N88HN88H6H6 4%<<2#K;2==#144 @UNH@EHOH6 N88HN88HN8QH6 L #$%&1# #!" '1&*$#R @UNH@EH6H6

show ip ospf summary-address

Authentication - Simple (Cleartext) #$%&1# $4". @ 2#12 6 2%&,1'&!+2&!$' '1&*$#R @:NH@EOH@H6 6H6H6HN88 2#12 6 L !'&1#.2+1 1&,1#'1& 6 !" 2==#144 @:NH@EOH@H@ N88HN88HN88H6 !" $4". 2%&,1'&!+2&!$';R1K "244*$#=

Authentication -MD5 #$%&1# $4". @ 2#12 N 2%&,1'&!+2&!$' <1442(1;=!(14& '1&*$#R @:NH@EOH@H6 6H6H6HN88 2#12 N L !'&1#.2+1 1&,1#'1& 6 !" 2==#144 @:NH@EOH@H@ N88HN88HN88H6 !" $4". <1442(1;=!(14&;R1K @ <=8 "244*$#=

Note: passwords do not need to be the same for an entire area. They only need to be the same for a network (subnet) - that is, between neighboring routers. Obviously, keeping the password the same throughout an area is advisable whenever possible. Also, the command !" $4".

2%&,1'&!+2&!$' can be used to override (on an interface basis) the authentication set for an area, though this is extremely rare.

Statically Defined Neighbors



If you can't use broadcasts (as with the .#2<1;#1?2K <2" statements or if you must use !" $4". '1&*$#R "$!'&;&$;<%?&!"$!'& '$';F#$2=+24&, for example) you must manually define OSPF neighbors with the neighbor statement (usually done at the hub): !'&1#.2+1 )1#!2?6 !" 2==#144 @6H6H@H@ N88HN88HN88H6 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K ?$+2?;=?+! N66 .#2<1;#1?2K <2" !" @6H6H@HD N6N .#2<1;#1?2K <2" !" @6H6H@HQ N6D .#2<1;#1?2K <2" !" @6H6H@H8 N6Q L #$%&1# $4". @ '1&*$#R @6H6H@H6 6H6H6HN88 2#12 6 '1!(,F$# @6H6H@HD +$4& 8 '1!(,F$# @6H6H@HQ +$4& @6 '1!(,F$# @6H6H@H8 +$4& @8 B,1 .$??$*!'( !4 &,1 +$'.!(%#2&!$' .$# &,1 #$%&1# $' &,1 $&,1# 4!=1J !'&1#.2+1 )1#!2?:7N !" 2==#144 @6H6H@HD N88HN88HN88H6 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K ?$+2?;=?+! D6@ .#2<1;#1?2K <2" !" @6H6H@H@ D66 L #$%&1# $4". @ '1&*$#R @6H6H@H6 6H6H6HN88 2#12 6

Stub and NSSA Areas #$%&1# $4". @ 2#12 @ 4&%F 2#12 N 4&%F '$;4%<<2#K 2#12 D '442 2#12 Q '442 '$;4%<<2#K '1&*$#R @6H8HQH6 6H6H6HN88 2#12 6 '1&*$#R @6H8HEH6 6H6H6HN88 2#12 @ '1&*$#R @6H8HOH6 6H6H6HN88 2#12 N '1&*$#R @6H8H@6H6 6H6H6HN88 2#12 D '1&*$#R @6H8H@NH6 6H6H6HN88 2#12 Q

Virtual Link !'&1#.2+1 C$$"F2+R6 !" 2==#144 @6H@NH@NH@ N88HN88HN88H6 L !'&1#.2+1 )1#!2?@ !" 2==#144 @:NH@EOHNH@ N88HN88HN88H6 L #$%&1# $4". @6@ '1&*$#R @6H@NH@NH6 6H6H6HN88 2#12 6 '1&*$#R @:NH@EOHNH6 6H6H6HN88 2#12 @ 2#12 @ >!#&%2?;?!'R @UNH@UH@6@H@



!'&1#.2+1 C$$"F2+R6 !" 2==#144 @UNH@UH@6@H@ N88HN88HN88H6 L !'&1#.2+1 )1#!2?@ !" 2==#144 @:NH@EOHNHN N88HN88HN88H6 L #$%&1# $4". @6D '1&*$#R @UNH@UH@6@H6 6H6H6HN88 2#12 @ '1&*$#R @:NH@EOHNH6 6H6H6HN88 2#12 @ '1&*$#R @:NH@EOHU6H6 6H6H6HN88 2#12 N 2#12 @ >!#&%2?;?!'R @6H@NH@NH@

show ip ospf virtual-link

Password Recovery

Although you won't (hopefully!!) need this on the exam, I have included this section in the event you buy a used router and do not know the password.

2500/4000 Reboot router. Type BREAK (control-shift-6 b on Cisco terminal server, control-F6-break on Hyperterm, Alt-b on TeraTerm). Type o/r 0x2142 at the ">" prompt (to boot from flash). Type I at the ">" prompt to reboot the router. Answer no to all set-up questions. Type enable at the Router> prompt. Type copy start run (brings in old config)ßWatch this!! Not the other way around!! Type config term, then either enable secret <password>. or enable password <password>. Type config term, then config-register 0x2102. Verify the config now in running-config is correct. Type copy run start. (Type reload. - optional)

2600/3600/4500 Reboot router. Type BREAK (control-shift-6 b on Cisco terminal server, control-F6-break on Hyperterm). Type confreg 0x2142 at the "ROMMON>" prompt (to boot from flash). Type reset at the "ROMMON>" prompt to reboot the router. Answer no to all set-up questions. Type enable at the Router> prompt. Type copy start run (brings in old config)ßWatch this!! Not the other way around!!



Type config term, then either enable secret <password>. or enable password <password>. Type config term, then config-register 0x2102. Verify the config now in running-config is correct. Type copy run start. (Type reload. - optional)

Queuing and Traffic Shaping

There are as many Cisco variations of queuing as there are flavors of ice cream. However here are a few powerful ones that can satisfy many requirements:

Priority Queuing Bruce Caslow describes priority queuing as a "facist" queuing strategy since it is very strict in its approach. Higher queues get priority, period. Given enough high priority traffic, other queues can go for days without tranmitting. "#!$#!&K;?!4& @ "#$&$+$? !" ,!(, &+" O6 "#!$#!&K;?!4& @ "#$&$+$? !" ,!(, &+" ND "#!$#!&K;?!4& @ "#$&$+$? !" <1=!%< ?!4& @66 L 2++144;?!4& @66 "1#<!& &+" 2'K 1S QQD 2'K 2++144;?!4& @66 "1#<!& &+" 2'K 2'K 1S QQD !'&1#.2+1 41#!2? 6 "#!$#!&K;(#$%" @

Custom Queuing Custom queuing is fairer since it can allocate percentages of bandwidth to given queues. Typically this is done by assigning byte counts to queues. The default byte count for each queue is 1500 bytes. Thus to give a queue more bandwidth than other queues, assign it more than1500 bytes. There can be up to 16 queues, but only as many as are configured will be active.

The following example configures queue-list 9 (applied to serial 1/0 via the +%4&$<;S%1%1;?!4& : command). The actual queue number appears later in the S%1%1;?!4& command (such as queue 1, queue 2 and queue 4 in this example). S%1%1;?!4& : "#$&$+$? !" @ &+" ND S%1%1;?!4& : "#$&$+$? !" N ?!4& @N6 S%1%1;?!4& : S%1%1 @ FK&1;+$%'& D666 S%1%1;?!4& : =1.2%?& Q L 2++144;?!4& @N6 "1#<!& (#1 2'K 2'K 2++144;?!4& @N6 "1#<!& $4". 2'K 2'K 2++144;?!4& @N6 "1#<!& !" ,$4& @6H@HNDHQ 2'K 2++144;?!4& @N6 "1#<!& !" 2'K ,$4& @6H@HNDHQ



!'&1#.2+1 41#!2? @76

+%4&$<;S%1%1;?!4& :

You can also assign packets to queues based on their size. To assign packets over 1000 bytes to queue 3, use: S%1%1;?!4& : "#$&$+$? !" D (& @666

show queue serial 0

Frame Relay !'&1#.2+1 41#!2? 6H6 !" 2==# @UNH@EH@H@ N88HN88HN88H6 1'+2"4%?2&!$' .#2<1;#1?2K .#2<1;#1?2K &#2..!+;4,2"!'( .#2<1;#1?2K !'&1#.2+1;=?+! @6N +?244 <K+?244 <2";+?244 .#2<1;#1?2K <K+?244 .#2<1;#1?2K +!# 8E666 -=1.!'14 IdA/ .#2<1;#1?2K F+ O666 -=1.!'14 F%#4& 2<$%'& !' F!&4/ .#2<1;#1?2K F1 @E666 -=1.!'14 1W+144 F%#4& !' F!&4/ .#2(<1'& @E6 -=1.!'14 "2+R1&4 s @E6 F1 .#2(<1'&1=/ '$ .#2<1;#1?2K 2=2"&!>1;4,2"!'(

RedistributionBasic

#$%&1# $4". @ #1=!4&#!F%&1 #!" <1&#!+ @66 <1&#!+;&K"1 @ #$%&1;<2" #$F 4%F'1&4 #$%&1# 1!(#" @ #1=!4&#!F%&1 F(" E8666 <1&#!+ @666 @6 @66 @66 @866

Using Route-Maps to Control Redistribution The following configuration only allows routes within the 172.16.0.0 network to be redistributed from RIP into BGP:

#$%&1# F(" E8666 #1=!4&#!F%&1 #!" <1&#!+ E #$%&1;<2" @UN;@E;$'?K '1!(,F$# @:NH@EOH@@H@ #1<$&1;24 E866@ L !" "#1.!W;?!4& @UN;@E;$'?K 41S 8 "1#<!& @UNH@EH6H67@E ?1 DN L #$%&1;<2" @UN;@E;$'?K "1#<!& @6 <2&+, !" 2==#144 "#1.!W;?!4& @UN;@E;$'?K

OSPF Example This example shows redistributing all routes from BGP 65001 into OSPF 1. Routes are set as OSPF external type-1 routes with an initial metric of 10:

#$%&1# $4". @



#1=!4&#!F%&1 F(" E866@ <1&#!+ @6 <1&#!+;&K"1 @ 4%F'1&4 '1&*$#R @:NH@EOHN66H6 6H6H6HN88 2#12 6

This example shows redistributing static routes into OSPF 1. A route-map is configured that only allows two static routes to be redistributed. One is redistributed as a metric-type 1, the other as a metric-type 2:

#$%&1# $4". @ #1=!4&#!F%&1 4&2&!+ <1&#!+ @6 4%F'1&4 #$%&1;<2" 4&2&!+Bc$4". '1&*$#R @:NH@EOH86H6 6H6H6HN88 2#12 6 L !" #$%&1 @6H@U:H6H6 N88HN88H6H6 @6HN66H@HN !" #$%&1 @6H@O6H6H6 N88HN88H6H6 @6HN66H@HN L !" "#1.!W;?!4& @6;@U:;6;6 41S 8 "1#<!& @6H@U:H6H67@E !" "#1.!W;?!4& @6;@O6;6;6 41S 8 "1#<!& @6H@O6H6H67@E L #$%&1;<2" 4&2&!+Bc$4". "1#<!& N6 <2&+, !" 2==#144 "#1.!W;?!4& @6;@U:;6;6 41& <1&#!+;&K"1 &K"1;@ L #$%&1;<2" 4&2&!+Bc$4". "1#<!& D6 <2&+, !" 2==#144 "#1.!W;?!4& @6;@O6;6;6 41& <1&#!+;&K"1 &K"1;N L

BGP Example This example shows redistributing all routes from IGRP 1 into BGP 65001. Routes are set with a BGP community value of 11111:22222:

#$%&1# F(" E866@ '$ 4K'+,#$'!e2&!$' #1=!4&#!F%&1 !(#" @ #$%&1;<2" 41&+$<<%'!&K '1!(,F$# @:NH@EOH@@HN #1<$&1;24 E8666 '1!(,F$# @:NH@EOH@@HN 41'=;+$<<%'!&K '$ 2%&$;4%<<2#K L !" F(";+$<<%'!&K '1*;.$#<2& L #$%&1;<2" 41&+$<<%'!&K "1#<!& @6 41& +$<<%'!&K @@@@@JNNNNN

This example shows redistributing OSPF routes into BGP. By default only internal OSPF routes are redistributed into BGP. The match keyword changes this behavior. By specifying "match external 1" only external type 1 OSPF routes are redistributed into BGP (even internal OSPF routes are not redistributed):

#$%&1# F(" E8666 '$ 4K'+,#$'!e2&!$' #1=!4&#!F%&1 $4". @ <2&+, 1W&1#'2? @ '1!(,F$# @:NH@EOH@@H@ #1<$&1;24 E866@ '$ 2%&$;4%<<2#K L



Regular Expressions

^ Denotes the start of the AS path $ Denotes the end of the AS path _ Will match a white space in the AS path (space between ASNs) . Will match any single character (dot) .* Will match any number of characters (dot, asterisk)

RIP

!'&1#.2+1 5&,1#'1& 6 '1!(,F$# @6H@86H@86H@

!" #!" 41'= >1#4!$' @

!" #!" #1+1!>1 >1#4!$' @

L #$%&1# #!" >1#4!$' N '$ 2%&$;4%<<2#K L $'?K 2""?!14 !. >1#4!$' N !4 %41= '1&*$#R @6H6H6H6 '1&*$#R @D@H@8H6H6 '1&*$#R N6UHNQQH@@H6 =!4&#!F%&1;?!4& @68 !' 1&,1#'1&6

=1.2%?&;<1&#!+ 8 $..41&;?!4& @6 !' Q

L 2++144;?!4& @6 "1#<!& @6H@H::H6 6H6H6HN88

In this example a neighbor is manually defined. This will cause unicast packets to be sent to that neighbor. This can be useful for media such as Frame Relay that do not always support broadcasts. This command also applies to IGRP.

The =1.2%?&;<1&#!+ commands sets the RIP metric (hop count) for all routes redistributed into RIP.

The $..41&;?!4& increases the metric (from what was learned) by 4 for all routes that match 2++144;?!4& @6. This command also applies to IGRP and EIGRP.

The !" #!" 41'= >1#4!$' and !" #!" #1+1!>1 >1#4!$' override (on an interface basis) the version of RIP defined by the >1#4!$' router command.

debug ip rip debug ip routing

Route Maps



Note: route-map examples for redistribution are included in the "Redistribution" section (above). Route-map examples for BGP neighbors are included in the "BGP" section.

Policy Route Maps Policy routing allows you to control how specific traffic (that matches the policy) is routed by the router. It overrides how the router would otherwise route the traffic. This example matches traffic specified by ACL 102 and sets the next hop to 172.20.1.1. The router will determine which interface it will use to access 172.20.1.1, then forward traffic to that address:

!'&1#.2+1 1N76 !" "$?!+K #$%&1;<2" 1W2<"?1 #$%&1;<2" 1W2<"?1 "1#<!& @6 <2&+, !" 2==#144 @6N 41& !" '1W&;,$" @UNHN6H@H@ 2++144;?!4& @6N "1#<!& !" ,$4& @UNH@OH8EH@ @:NH@EOH@H6 6H6H6HN88

The 41& !" =1.2%?& '1W&;,$" +1,#%%*)22 command can be used to route a packet to this next hop address only if there is no explicit destination (if the default route would be used).

To enable the router to policy route for locally generated traffic (pings, telnet traffic, etc.): !" ?$+2? "$?!+K #$%&1;<2" <K<2"

Terminal Server Configuration

You are unlikely to need this on the lab, but it may come in handy if you decide to get a terminal server for your home lab.

!'&1#.2+1 ?$$"F2+R 6 !" 2==#144 @6H@H@H@ N88HN88HN88H6 !" ,$4& #@ N66@ @6H@H@H@ !" ,$4& #N N66N @6H@H@H@ !" ,$4& 4*!&+, N66D @6H@H@H@ ?!'1 @ O '$ 1W1+ &#2'4"$#& !'"%& 2??

Important notes:

· Type +$'&#$?;4,!.&;E W to send an escape sequence to the term server that will bring you back to the terminal server prompt.

· Type +$'&#$?;4,!.&;E F to send a break to a router that is being accessed via the terminal server (handy for password recovery).



· To send an escape sequence to a router that is being accessed via the terminal server, type +$'&#$?;4,!.&;E +$'&#$?;4,!.&;E. This prevents you from getting tossed all the way back to the term server. Very handy for interrupting pings or traceroutes that are not completing.

· You may even have to type +$'&#$?;4,!.&;E four times. For example, if you are using a term server to access a router, then that router is telnetted into another router. This requires +$'&#$?;4,!.&;E four times to escape.

TrunkingISL:

On Cisco routers: !'&1#.2+1 324& 5&,1#'1& 676H@ 1'+2"4%?2&!$' !4? -.#$6$'"()*

802.1Q: On Cisco routers: !'&1#.2+1 324& 5&,1#'1& 676H@ 1'+2"4%?2&!$' =$&@] -.#$6$'"()*

Tunnels

!'&1#.2+1 &%''1? 6 &%''1? 4$%#+1 @6H@66H8H@ &%''1? =14&!'2&!$' @6H@6H@6H@6 &%''1? <$=1 (#1 !" -$"&!$'2? 9 =1.2%?&4 &$ (#1/ 1&+H

show interface tunnel 0

VRRP The Virtual Router Redundancy Protocol (VRRP) is very similar to HSRP (4&2'=FK command). If you are familiar with that set of commands, VRRP is just slightly different syntax. VRRP creates a virtual IP address on a subnet that two or more routers can share, with one router (with the highest priority) being the primary and the others acting as back-ups.

Here are some notable differences between HSRP and VRRP:

· VRRP allows you to add a description. If allowed by the lab you may want to use this - perhaps to tell you which router is supposed to be primary or other useful info.

· In IOS 12.4 HSRP supports IPv6, VRRP does not.

· By default HSRP backup routers automatically learn and use the Hello and Downtime timers of the active router. VRRP can do this with the >##" 7*!'1 &!<1#4 ?12#' command, but that is disabled by default.

· VRRP requires a group number, with HSRP it is optional.



!'&1#.2+1 324&1&,1#'1& 676 !" 2==#144 @6H@:NHOHN N88HN88HN88H6 >##" @ "#!$#!&K @68 >##" @ 2%&,1'&!+2&!$' ++!1 >##" @ &!<1#4 2=>1#&!41 8 >##" @ &!<1#4 ?12#' >##" @ !" @6H@:NHOH@

show vrrp show vrrp brief show vrrp interface Fastethernet 0/0 [brief]



!'&1#.2+1 324&1&,1#'1& 676 !" 2==#144 @6H@:NHOHN N88HN88HN88H6 >##" @ "#!$#!&K @68 >##" @ 2%&,1'&!+2&!$' ++!1 >##" @ &!<1#4 2=>1#&!41 8 >##" @ &!<1#4 ?12#' >##" @ !" @6H@:NHOH@

show vrrp show vrrp brief show vrrp interface Fastethernet 0/0 [brief]


CCIE _R&S_ NOTE FROM EXPERIENCE BY ROBERT WEBBERT

Documents