You are on page 1of 179

CCIE Notes From Experience

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

by Robert Webber CCIE 6922

Copyright 2009, Robert Webber

Rob Webber's CCIE Notes from Experience

Table of Contents - Notes From Experience

Version 8.0

Introduction........................................................................................................ 8 Foreword............................................................................................................. 9 3560 ................................................................................................................... 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................................................................................................. 8 1 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 ........................................................................................................ 8 3 BGP Official Path Selection Process ..............................................................40 BGP Unofficial Path Selection Process ..........................................................41 Bridging (Routers) ........................................................................................... 42 Spanning Tree ................................................................................................42 Frame Relay ...................................................................................................42 Control Plane Policing..................................................................................... 43 Debug................................................................................................................ 44 Distance ............................................................................................................ 45 Distribute Lists................................................................................................. 47 Distribute List In ..............................................................................................47 Distribute List Out ...........................................................................................49 EIGRP ................................................................................................................ 50 EIGRP Metric.................................................................................................. 50 EIGRP Summarization.................................................................................... 50 EIGRP Default Route......................................................................................51 EIGRP Network Commands...........................................................................51 EIGRP Stub Routing.......................................................................................52 Firewalls............................................................................................................ 53 IOS Firewall (CBAC).......................................................................................53
Copyright 2009, Rob Webber 2

Rob Webber's CCIE Notes from Experience Version 8.0 Zone-Based Firewall.......................................................................................54 Frame Relay...................................................................................................... 56 Interfaces and Sub-Interfaces.........................................................................56 PVC Status .....................................................................................................56 Inverse Arp and Mapping................................................................................56 OSPF.............................................................................................................. 59 Gateway Load Balancing Protocol (GLBP).................................................... 60 Home 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 ..................................................................................................................... 68 Intrusion Prevention System (IPS) - IOS ....................................................... 69 IPSec ................................................................................................................. 69 Access lists ..................................................................................................... 70 IPSec through a Tunnel Interface...................................................................70 IPSec Example ...............................................................................................71 Verifying IPSec Connectivity...........................................................................73 IPv6.................................................................................................................... 77 Access Lists.................................................................................................... 77 Addressing...................................................................................................... 8 7 BGP ................................................................................................................ 0 8 EIGRP ............................................................................................................ 1 8 Filtering........................................................................................................... 2 8 IOS Firewall ....................................................................................................83 OSPF.............................................................................................................. 3 8 RIP.................................................................................................................. 4 8 Redistribution.................................................................................................. 5 8 Tunneling........................................................................................................ 5 8 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 ........................................................................................ 90 MPLS ................................................................................................................. 91 MPLS Overview..............................................................................................91 Terminology.................................................................................................... 91 Configuring MPLS...........................................................................................92 Configuring Multiprotocol BGP .......................................................................93 Configuring MPLS VPNs ................................................................................94 Multicast............................................................................................................ 96 IGMP/CGMP................................................................................................... 96 PIM ................................................................................................................. 97 Copyright 2009, Rob Webber 3

Rob Webber's CCIE Notes from Experience Version 8.0 Rendezvous Point (RP) ..................................................................................97 DVMRP........................................................................................................... 8 9 NTP .................................................................................................................... 98 Overview......................................................................................................... 8 9 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...................................................................................................... 105 Quality 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)........................................................................................... 8 12 Router "Network" Statements .......................................................................128 Passive Interface ..........................................................................................128 Default Metrics.............................................................................................. 129 Split Horizon................................................................................................... 129 SSH.................................................................................................................. 130 Tips & Tricks................................................................................................... 130 Copyright 2009, Rob Webber 4

Rob Webber's CCIE Notes from Experience Version 8.0 Practice Speed .............................................................................................131 IP Subnetting................................................................................................132 Access Lists..................................................................................................133 Logging......................................................................................................... 133 Console and VTY Ports ................................................................................134 Terminal Editing............................................................................................134 Troubleshooting............................................................................................. 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 ........................................................................................................... 8 13 Other Tools...................................................................................................138 Tunnels ........................................................................................................... 8 13 WCCP .............................................................................................................. 139 Appendix A: Tera Term Macro ...................................................................... 139

Study Sheet
CCIE Study Sheet - Foreword....................................................................... 147 3560 ................................................................................................................. 147 Etherchannel ................................................................................................147 FallBack Bridging..........................................................................................148 Ports ............................................................................................................. 8 14 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............................................................................................................. 150 BGP ................................................................................................................. 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 ............................................................................................................... 155 EIGRP .............................................................................................................. 156 Authentication - MD5 ...................................................................................156
Copyright 2009, Rob Webber 5

Rob Webber's CCIE Notes from Experience Version 8.0 Firewalls.......................................................................................................... 157 Context Based Access Control (CBAC)........................................................157 Zone Based Firewall.....................................................................................157 Reflexive Access Lists ..................................................................................158 Lock and Key Access ...................................................................................158 Frame Relay.................................................................................................... 159 Frame Relay Switching.................................................................................159 Frame Relay .................................................................................................159 Frame Relay Traffic Shaping ........................................................................160 HSRP ............................................................................................................... 160 ISAKMP ........................................................................................................... 161 IPSEC .............................................................................................................. 161 IPv6.................................................................................................................. 162 Access-Lists & Filtering ................................................................................162 EIGRP .......................................................................................................... 163 OSPF............................................................................................................ 163 Tunneling...................................................................................................... 163 MPLS ............................................................................................................... 163 Multicast.......................................................................................................... 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 ............................................................................................................ 166 Network 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 ............................................................................................................... 8 16 Basic............................................................................................................. 8 16 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 Copyright 2009, Rob Webber 6

Rob Webber's CCIE Notes from Experience Version 8.0 Redistribution................................................................................................. 173 Basic............................................................................................................. 173 Using Route-Maps to Control Redistribution.................................................173 OSPF Example.............................................................................................173 BGP Example ...............................................................................................174 Regular Expressions ..................................................................................... 175 RIP ................................................................................................................... 175 Route Maps..................................................................................................... 175 Policy Route Maps........................................................................................176 Terminal Server Configuration...................................................................... 176 Trunking.......................................................................................................... 177 ISL: ............................................................................................................... 177 802.1Q:......................................................................................................... 177 Tunnels ........................................................................................................... 177 VRRP ............................................................................................................... 177

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

Table of Figures
Figure 1: Switched Virtual Interfaces (SVI's) for the 3560 (Logical Routing)...... 16 Figure 2: Typical 3560 Connectivity (Physical)...................................................29 Figure 3: Typical 3560 Connectivity (Logical).....................................................30 Figure 4: Bridging Over Frame Relay.................................................................43 Figure 5: Filtering RIP Routes ............................................................................48 Figure 6: Home Lab with Internet Connectivity...................................................66 Figure 7: IPSec Using Multiple Tunnels .............................................................71 Figure 8: OSPF Summarization with RIP Redistribution .................................. 123 Figure 9: Using Route Tags .............................................................................126 Figure 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!

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience

Version 8.0

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" command s. 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.

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience

Version 8.0

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 Copyright 2009, Rob Webber 9

Rob Webber's CCIE Notes from Experience Version 8.0 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
Time Savers
!"
#$%&!'(

is not enabled by default. I recommend enabling this!

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

Copyright 2009, Rob Webber

10

Rob Webber's CCIE Notes from Experience


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

Version 8.0

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 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):
4,$* #%''!'(;+$'.!(%#2&!$' ABCD;D8E604,$ #%'

!'&

(!(2F!&5&,1#'1&

67@

G%!?=!'(

+$'.!(%#2&!$'HHH

I%##1'&

+$'.!(%#2&!$'

@6D

FK&14

!'&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&!$'

@8D

FK&14

!'&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&!$'

@8D

FK&14

!'&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

Copyright 2009, Rob Webber

11

Rob Webber's CCIE Notes from Experience


D8E6;@0
+$'. &

Version 8.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 , however the default is . 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 command.
4*!&+,"$#& <$=1 2++144 4*!&+,"$#& <$=1 =K'2<!+ =14!#2F?1 4*!&+,"$#& <$=1 2++144

The command to assign an access port to a VLAN is (you will definitely need this command): Copyright 2009, Rob Webber 12

Rob Webber's CCIE Notes from Experience


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

Version 8.0

$'"()*

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, 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, 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.
4*!&+,"$#& <$=1 =K'2<!+ 2%&$ 4*!&+,"$#& <$=1 =K'2<!+ =14!#2F?1

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) Copyright 2009, Rob Webber 13

Rob Webber's CCIE Notes from Experience Version 8.0 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 %!"#+$,$#") command). If a trunk does same VTP domain ( not come up right away its not always obvious that this is the problem!
>&" =$<2!'

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

Routing with 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
Copyright 2009, Rob Webber 14

Rob Webber's CCIE Notes from Experience Version 8.0 subnet. Use the command to create a physically routed port:
'$ 4*!&+,"$#&

!'&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 ). Cisco refers to these ports as "routed ports."
'$ 4*!&+,"$#&

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 is the default configuration, thus when this is configured on a port it will not display in the configuration.
4*!&+,"$#&

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 command:
4*!&+,"$#& <$=1 2++144

!'&1#.2+1

324&5&,1#'1&67ND

4*!&+,"$#&

2++144

>?2'

DN

4*!&+,"$#&

<$=1

2++144

'$

!"

2==#144

!'&1#.2+1

P?2'DN

!"

2==#144

@88H@ONHDNH@E

N88HN88HN88H6

Note that the VLAN assigned to the ports ( ) exactly matches the interface name ( ). 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.
>?2'

DN

P?2'DN

Copyright 2009, Rob Webber

15

Rob Webber's CCIE Notes from Experience

Version 8.0

Interface Fast Eth 0/8 Internal Router 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/20 Interface Vlan8 Interface Fast Eth 0/10 Interface Vlan3 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

Logical "SVI" Interfaces

VLAN 8 subnet147.1428.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 section).
!'&1#.2+1
P?2'VV

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

DHCP

Lastly, don't forget to enable ip routing globally (

!"

#$%&!'(

)!!

Copyright 2009, Rob Webber

16

Rob Webber's CCIE Notes from Experience Version 8.0 The switch can act as a DHCP server (see the "DHCP" section of the Study Sheet) or a normal DHCP relay ( ). However the 3560 can also provide other DHCP functions.
!"
,1?"1#;2==#144

WHWHWHW

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 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 interface command. To set an interface back to untrusted use the command.
!"
=,+" 4'$$"!'(

!"

=,+"

4'$$"!'(

&#%4&

'$

!"

=,+"

4'$$"!'(

&#%4&

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

!"

=,+"

To help prevent DoS attacks you can apply rate limiting for DHCP packets *#/) interface on an interface. Use the 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.
!"
=,+" 4'$$"!'( ?!<!& #2&1

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.

Copyright 2009, Rob Webber

17

Rob Webber's CCIE Notes from Experience Version 8.0 For further security IP Source Guard can be enabled. If DHCP Snooping has been enabled on an interface, the 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.
!"
>1#!.K 4$%#+1

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 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.
!'&1#.2+1
P?2'VV

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 command. Although desirable should work fine, I prefer "nailing" the Etherchannel on if I know I need it.
+,2''1?;(#$%" O <$=1 $'

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!

Copyright 2009, Rob Webber

18

Rob Webber's CCIE Notes from Experience Version 8.0 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

!'&1#.2+1

PCXY

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

"#!$#!&K

EQ

41&4

&,1

)H

B#11

"$#&

"#!$#!&K

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

"2&,;+$4&

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

"#$&$+$?

>?2';F#!=(1

!'&1#.2+1

PCXY

@6

!"

2==#144

@6HOEH@H@

N88HN88HN88H6

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

!'&1#.2+1

PCXY

N6

!"

2==#144

@6HOEHNH@

N88HN88HN88H6

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

!'&1#.2+1

324&5&,1#'1&67U

'$

4*!&+,"$#&

!"

2==#144

@6HOEHDH@

N88HN88HN88H6

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

Copyright 2009, Rob Webber

19

Rob Webber's CCIE Notes from Experience


L

Version 8.0

!'&1#.2+1

PCXY

@Q6

!"

2==#144

@6HOEHQH@

N88HN88HN88H6

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

!'&1#.2+1

PCXY

@86

!"

2==#144

@6HOEH8H@

N88HN88HN88H6

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

!'&1#.2+1

324&5&,1#'1&67@O

'$

4*!&+,"$#&

!"

2==#144

@6HOEHEH@

N88HN88HN88H6

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

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 ( or ). Existing SPAN and RSPAN sessions can be displayed with the command.
#WT &W

F$&,

4,$*

<$'!&$#

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 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:
1'+2"4%?2&!$' #1"?!+2&1 <$'!&$# 4144!$'

4$%#+1

!'&1#.2+1

32@767U

&W

<$'!&$#

4144!$'

=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

: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 command.
4144!$' '$ <$'!&$#

Copyright 2009, Rob Webber

20

Rob Webber's CCIE Notes from Experience


!'(#144

Version 8.0

If the monitoring device will be generating traffic (in addition to receiving it), the keyword is required. Ingress can be specified with the -.#$,+% keyword, the keyword or the -.#$,+% or just -.#$,+%) 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:
=$&@S >?2'

!4?

%'&2((1=

>?2'

>?2'

<$'!&$#

4144!$'

4$%#+1

.24&1&,1#'1&6767@

F$&,

<$'!&$#

4144!$'

=14&!'2&!$'

!'&1#.2+1

.24&1&,1#'1&67@7@N

!'(#144

%'&2((1=

>?2'

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:

<$'!&$#

4144!$'

4$%#+1

.24&1&,1#'1&67D

F$&,

<$'!&$#

4144!$'

=14&!'2&!$'

!'&1#.2+1

.24&1&,1#'1&67@:

<$'!&$#

4144!$'

.!?&1#

>?2'

O@TO8

OO

RSPAN requires first configuring the RSPAN VLAN that will carry monitored traffic between switches. If VTP is configured for 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 mode, the RSPAN VLAN can be configured on the server and it will be propagated to all client switches. The VLAN command is required:
&#2'4"2#1'& +?!1'&741#>1# #1<$&1;4"2' >?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 keyword to direct traffic to the RSPAN VLAN:
<$'!&$# #1<$&1 >?2' <$'!&$# 4144!$'

=14&!'2&!$'

#1<$&1

>?2'

@66

Copyright 2009, Rob Webber

21

Rob Webber's CCIE Notes from Experience Version 8.0 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 , it only passes through the VLAN on its trunk ports:
#1<$&1 >?2'

Switch A VLAN 25 Fa0/1/24 VLANs 25, 101

Switch B

Switch A
>&" <$=1 &#2'4"2#1'& >&" =$<2!' ++!1 L

Fa0/1/2 Fa0/1/2 Trunk VLANs 25, 101

Switch C
Fa0/1/23

Sniffer

>?2'

N8

'2<1

=2&2Z>?2'

>?2'

@6@

'2<1

>?2'Z.$#ZA)[XY

#1<$&1;4"2'

!'&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@

!'&1#.2+1

324&5&,1#'1&@767NQ

4*!&+,"$#&

2++144

>?2'

N8

4*!&+,"$#&

<$=1

2++144

'$

!"

2==#144

<$'!&$#

4144!$'

4$%#+1

.24&1&,1#'1&@767NQ

F$&,

<$'!&$#

4144!$'

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

!'&1#.2+1

324&5&,1#'1&@767@

4*!&+,"$#&

&#%'R

1'+2"4%?2&!$'

=$&@S

4*!&+,"$#&

<$=1

&#%'R

Copyright 2009, Rob Webber

22

Rob Webber's CCIE Notes from Experience


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

Version 8.0
=$&@S

N8T@6@

!'&1#.2+1

324&5&,1#'1&@767N

4*!&+,"$#&

&#%'R

1'+2"4%?2&!$'

4*!&+,"$#&

<$=1

&#%'R

4*!&+,"$#&

&#%'R

2??$*1=

>?2'

N8T@6@

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'

!'&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@

<$'!&$#

4144!$'

4$%#+1

#1<$&1

>?2'

@6@

<$'!&$#

4144!$'

=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 Copyright 2009, Rob Webber

23

Rob Webber's CCIE Notes from Experience Version 8.0 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 command.
4"2''!'(;&#11 <$=1 ">4& \ <4& \ #2"!=;">4&

Rapid PVST+ uses most of the same concepts as PVST+ (root bridge, path cost, ports go through blocking/listening/learning/forwardingstates, etc.) Rapid PVST+ also introduces the concept of "Edge Ports," implemented with the 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 /01) interface command. PVST+ also uses the Full duplex ports are assumed to be point-to-point connections; halfduplex ports are considered to use a shared connection. This can be $/01) interface command. overridden with the
4"2''!'(;&#11 "$#&.24& 4"2''!'(;&#11 ?!'R;&K"1 4"2''!'(;&#11 ?!'R;&K"1

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''!'(;

Copyright 2009, Rob Webber

24

Rob Webber's CCIE Notes from Experience -.#$,+% command or the -.#$,+% 1*+!*+/0 command.
&#11 >?2' #$$& "#!<2#K "#!$#!&K

Version 8.0
4"2''!'(;&#11 >?2'

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 -.#$,+% 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 -.#$,+% command.
4"2''!'(;&#11 >?2' "#!$#!&K Q6:E 4"2''!'(;&#11 >?2' #$$& "#!<2#K

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 !2/ command. If a port is forwarding link) using the
4"2''!'(;&#11 +$4&

Copyright 2009, Rob Webber

25

Rob Webber's CCIE Notes from Experience Version 8.0 a trunk and you only want to apply a path cost on a single VLAN, use the -.#$,+%$(" ,$ !2/ command.
4"2''!'(;&#11 >?2'

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
Copyright 2009, Rob Webber 26

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

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 command).
>&" <$=1 &#2'4"2#1'&

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 Copyright 2009, Rob Webber 27

Rob Webber's CCIE Notes from Experience Version 8.0 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 %!"#+$,$#") command on each switch). Although a same 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.
>&" =$<2!'

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

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

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

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

Copyright 2009, Rob Webber

28

Rob Webber's CCIE Notes from Experience Version 8.0 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

r13

VLAN 192 155.182.192.0/24


FA 0/5

VLAN 192 3560 155.182.192.0/24 (r16) FA 0/6


FA 0/4 FA 0/14

r4

VLAN 32 155.182.32.0/24

FA 0/23

r14

trunk VLAN 64 155.182.64.0/24 VLAN 128 155.182.128.0/24

Figure 2: Typical 3560 Connectivity(Physical)

Copyright 2009, Rob Webber

29

Rob Webber's CCIE Notes from Experience

Version 8.0

3560 Logical Diagram r6


r5
VLAN 192 155.182.192.0/24

connection type 1

r13

VLAN 32 155.182.32.0/24

connection type 3

3560 (r16)

r4

connection type 4 r14


Figure 3: Typical 3560 Connectivity (Logical)

VLAN 64 155.182.64.0/24

connection type 2

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

!'&1#.2+1

324&5&,1#'1&678

4*!&+,"$#&

2++144

>?2'

@:N

'$

!"

2==#144

!'&1#.2+1

324&5&,1#'1&67E

4*!&+,"$#&

2++144

>?2'

@:N

'$

!"

2==#144

!'&1#.2+1

324&5&,1#'1&67@Q

4*!&+,"$#&

&#%'R

1'+2"4%?2&!$'

=$&@S

4*!&+,"$#&

<$=1

&#%'R

'$

!"

2==#144

!'&1#.2+1

324&5&,1#'1&67ND

Copyright 2009, Rob Webber

30

Rob Webber's CCIE Notes from Experience


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

Version 8.0

DN

4*!&+,"$#&

<$=1

2++144

'$

!"

2==#144

!'&1#.2+1

P?2'DN

!"

2==#144

@88H@ONHDNH@E

N88HN88HN88H6

!'&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

!'&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

!'&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

!'&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

!'&1#.2+1

324&5&,1#'1&676HEQ

1'+2"4%?2&!$'

=$&@]

EQ

!"

2==#144

@88H@ONHEQH@Q

N88HN88HN88H6

!'&1#.2+1

324&5&,1#'1&676H@NO

1'+2"4%?2&!$'

=$&@]

@NO

!"

2==#144

@88H@ONH@NOH@Q

N88HN88HN88H6

!'&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!

Copyright 2009, Rob Webber

31

Rob Webber's CCIE Notes from Experience

BGP
Peers

Version 8.0

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 neighbor command.
<%?&!,$" 1F(";<%?&!,$"

1F(";

By default iBGP peers can be up to 255 hops away without requiring the command. If BGP peers (eBGP or iBGP) peer between loopback addresses they will also need the 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.
%"=2&1;4$%#+1

Advertising to Peers If a router is originating a route with the 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&*$#R #$%&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

Copyright 2009, Rob Webber

32

Rob Webber's CCIE Notes from Experience


#$%&1#

Version 8.0

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.

Copyright 2009, Rob Webber

33

Rob Webber's CCIE Notes from Experience Version 8.0 BGP peers do not always advertise BGP updates to each other. The table below summarizes how BGP advertises:

Update received from: An external BGP Peer


An external BGP Peer An internal BGP Peer An internal BGP Peer

Will I send an update to:


An external BGP Peer An internal BGP Peer An external BGP Peer An internal BGP Peer

Table 1: BGP Route AdvertisementRules

What the "next-hop" attributewill be set to

YES The advertising router will set the next hop to the value it is using for the BGP session for the router to which it is making the advertisement. This is usually the IP address on the interface connecting to the peer, but can be overridden with the command. YES By default on advertisements to iBGP peers, the advertising router maintains the next hop value that it received from the eBGP peer. Thus when the update reaches the iBGP peer, the next hop will be an IP address that is not directly connected to it! ** YES The advertising router will set the next hop to the value it is using for the BGP session for the router to which it is making the advertisement. This is usually the IP address on the interface connecting to the peer, but can be overridden with the command. NO* Normally iBGP peers do not advertise routes to iBGP peers, thus there is no next-hop attribute. This no-advertise behavior can be overridden using confederations or route-reflectors.
%"=2&1;4$%#+1 %"=2&1;4$%#+1

* - 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 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!
'1W&;,$";41?.

Copyright 2009, Rob Webber

34

Rob Webber's CCIE Notes from Experience Version 8.0 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 loopdetection 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 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.
'1!(,F$# #$%&1; #1.?1+&$#;+?!1'&

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: Copyright 2009, Rob Webber 35

Rob Webber's CCIE Notes from Experience Version 8.0 " command with only a statement in the route-map " (applies to the neighbor specified) " (applies to the entire BGP process) " with an
'1!(,F$# #$%&1;<2" <2&+,

!"

2==#144

'1!(,F$#

=!4&#!F%&1;?!4&

=!4&#!F%&1;?!4&

'1!(,F$#

.!?&1#;?!4&

!"

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 filters updates from the routing table but leaves them in the bgp table. The other two eliminate them from both.
=!4&;?!4&

The command or the can be applied to a neighbor - but not both commands to the same neighbor. Given my preference for prefix lists, I prefer the command.
'1!(,F$# "#1.!W;?!4& '1!(,F$# '1!(,F$# "#1.!W;?!4& '1!(,F$# .!?&1#;?!4&

=!4&#!F%&1;?!4&

When filtering based on AS path, use the 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&,

!DH6H6H6

@DUHD:HNDHO:

@666

86

!"#$!#%

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 command. This will send to that neighbor both: any communities that BGP routes already have (that were sent to you from
'1!(,F$# 41'=;+$<<%'!&K

@6H@DH@DH@

Copyright 2009, Rob Webber

36

Rob Webber's CCIE Notes from Experience Version 8.0 other peers and/or AS's) as well as any communities you set with a routemap. 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

41&

+$<<%'!&K

'$;1W"$#&

#$%&1;<2"

41&+$<<%'!&K

"1#<!&

N6

2++144;?!4&

"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 . Otherwise your communities look really weird!
!"
+$<<%'!&K '1*;.$#<2&

F(";

Synchronization Synchronization is a parameter that can be enabled or disabled in 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).
#$%&1#

F("

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

!@6HN6HN88HNDE7DN

@6HN6HN86HNDE

@66

ABCD3INN;@8E04,$

!"

#$%&1

F("

Copyright 2009, Rob Webber

37

Rob Webber's CCIE Notes from Experience


ABCD3INN;@8E0

Version 8.0

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!$'

[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 disable synchronization.


'$ 4%<<2#K;$'?K

4K'+,#$'!e2&!$'

command under the router BGP config to

Aggregate Address This is a useful command for summarizing an address block. Use the keyword 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 ( ) or on specific routes ( 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
F("
=1.2%?& ?$+2?;"#1.1#1'+1 41& ?$+2?; "#1.1#1'+1

Copyright 2009, Rob Webber

38

Rob Webber's CCIE Notes from Experience Version 8.0 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 or the commands&from what I'm told. Community - This attribute is sent with each routing advertisement from AS to AS. It is set with the 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
'1!(,F$#

*1!(,&

41&

*1!(,&

41&

+$<<%'!&K

Copyright 2009, Rob Webber

39

Rob Webber's CCIE Notes from Experience Version 8.0 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 lowest Multi 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.

Copyright 2009, Rob Webber

40

Rob Webber's CCIE Notes from Experience All confederation paths are considered internal paths.

Version 8.0

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 ina essible, 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, syn hronization 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 lo al preferen e. 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 Dis riminator (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 IGP metri ).

c c c c

Copyright 2009, Rob Webber

41

Rob Webber's CCIE Notes from Experience Version 8.0 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 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.
F#!=(1
@ "#!$#!&K Q6:E

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 %. + 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
.#2<1;#1?2K

<2"

F#!=(1

F#$2=+24&

Copyright 2009, Rob Webber

42

Rob Webber's CCIE Notes from Experience Version 8.0 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.

Cannot be Spanning Tree root bridge


router1

Spanning Tree root bridge


router3

S1 S0
Frame Relay

Point to Point Serial Connection

S1 Blocked by Spanning Tree S0


router2

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
43

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience Version 8.0 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'<"

!"

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&

+?244;<2"

4'<"

<2&+,

2++144;(#$%"

'2<1

4'<"

+?244;<2"

&1?'1&

<2&+,

2++144;(#$%"

'2<1

&1?'1&

"$?!+K;<2"

I[[;!'

+?244

4'<"

"$?!+1

UN666

+$'.$#<

&#2'4<!&

1W+11=

=#$"

+?244

&1?'1&

"$?!+1

+$'&#$?;"?2'1

41#>!+1;"$?!+K

show poli y-map ontrol-plane [all]

Debug

# )22,.+2/ , remember If you need to use 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 on each interface
=1F%(

c c
UN666

+$'.$#<

&#2'4<!&

1W+11=

=#$"

!'"%&

I[[;!'

!"

"2+R1&

f=1&2!?g

'$

!"

#$%&1;+2+,1

Copyright 2009, Rob Webber

44

Rob Webber's CCIE Notes from Experience Version 8.0 (especially the incoming interface for the packets in question). In a lab environment, configuring 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;+2+,1

#$%&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 other packet bold to make it easier to read:
=1F%(

!"

"2+R1&

=1&2!?H

I have made every

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 ( ) between 172.31.2.2 and 172.31.201.1. Note that this is the start of a connection (the and ). The "g=" indicates the gateway (next hop address) the router will use to forward the packet.
BI[
=4& 2'= 4#+hND

)jY

XIi

)jY

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 ( ) while the second one is a transmitted packet ( ).
#+>=

41'=!'(

F#$2=7<%?&!+24&

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

Distance
Copyright 2009, Rob Webber 45

Rob Webber's CCIE Notes from Experience Version 8.0 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 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:
=!4&2'+1 #$%&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 1 Static route EIGRP Summary 5 20 BGP (eBGP) EIGRP 90 100 IGRP 110 OSPF ISIS 115 120 RIP Copyright 2009, Rob Webber 46

Rob Webber's CCIE Notes from Experience EIGRP External 170 200 Internal BGP

Version 8.0

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

!'

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.

Copyright 2009, Rob Webber

47

Rob Webber's CCIE Notes from Experience

Version 8.0

Unwanted RIP advertisements


172.16.8.1/24 E0 172.16.1.1/24 172.16.12.1/24 R1
S0

172.16.1.2/24
S0

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 advertisements Figure 5: Filtering RIP Routes

R2

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 under the RIP process, the router will automatically (and sometimes surprisingly!) change it to simply . 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.
'1&*$#R @UNH@EH@H6 '1&*$#R @UNH@EH6H6

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 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:
"244!>1;!'&1#.2+1 56 #$%&1# #!" '1&*$#R @UNH@EH6H6 "244!>1;!'&1#.2+1 16

=!4&#!F%&1;?!4&

!'

16

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. Copyright 2009, Rob Webber 48

Rob Webber's CCIE Notes from Experience Version 8.0 Distribute List Out In the network in Figure 5: Filtering RIP Routes, RIP is automatically enabled on S0, E0 and E1 by the 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&*$#R @UNH@EH6H6 #$%&1# #!" '1&*$#R @UNH@EH6H6 =!4&#!F%&1;?!4&

$%&

)6

With either this access-list:


2++144;?!4&

=1'K

@UNH@EHOH6

2++144;?!4&

"1#<!&

2'K

Or this access-list:
2++144;?!4&

"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 only works on External Type 1 or 2 routes - not with internal OSPF routes.
=!4&#!F%&1;?!4& $%&

Copyright 2009, Rob Webber

49

Rob Webber's CCIE Notes from Experience Version 8.0 Distribution lists may not take effect immediately. You may have to bounce the interface or do a to activate them.
+?12#

!"

#$%&1

The

=!4&#!F%&1;?!4&

.+2/4

$%&

1*! )22

is very tricky. For example:


@E $%& 1!(#" @

N86@F-+$'.!(/0

#$%&1#

$4".

@6D

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

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 . 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 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 interface command.
'$ 2%&$;4%<<2#K '$ 2%&$;4%<<2#K '$

!"

4"?!&;,$#!e$'

1!(#"

EIGRP Metric When setting the EIGRP metric (via the keyword during redistribution or via the 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&#!+ =1.2%?&;<1&#!+ =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 . 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).
=1.2%?&; <1&#!+ @666 @6

N88

86

@866

EIGRP Summarization

Copyright 2009, Rob Webber

50

Rob Webber's CCIE Notes from Experience Version 8.0 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 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).
!"
4%<<2#K;2==#144 1!(#" @ @6HN6H6H6

N88HN88H6H6

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

4%F'1&4T

<24R4

m
#@0

@6HN6H6H67@E

!4

4%<<2#KT

66J66J6NT

Y%??6

You can use the 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!
!"
4%<<2#K;2==#144 1!(#" @ 6H6H6H6 6H6H6H6

You can also use a distance keyword on the 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 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 .
!"
4%<<2#K;2==#144

!"

4%<<2#K;2==#144

1!(#"

@UNH@:H6H6

N88HN88H6H6

!'&1#.2+1

)1#!2?

@76

!"

4%<<2#K;2==#144

1!(#"

@UNH@:H6H6

N88HN88H6H6

@86

EIGRP Default Route EIGRP cannot "generate" a default route (as OSPF can, for example, with the 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.
=1.2%?&;!'.$#<2&!$' $#!(!'2&1

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

Copyright 2009, Rob Webber

51

Rob Webber's CCIE Notes from Experience


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

Version 8.0

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 router command configures a remote router as a stub. This has several keywords: 1. 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. specifies a route map that allows certain EIGRP routes to be advertised (leaked) to the hub 3. automatically advertises routes that are connected to the stub router. Network statements for those subnets are still required.
1!(#" 4&%F #1+1!>1;$'?K ?12R;<2" +$''1+&1=

Copyright 2009, Rob Webber

52

Rob Webber's CCIE Notes from Experience Version 8.0 4. 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. will advertise EIGRP summary routes configured with the command (or with an automatic summary if the default, is enabled) - though I usually configure 6. advertises to the hub any routes that are redistributed into EIGRP on the stub router
4&2&!+ 4%<<2#K 4%<<2#K 2==#144 2%&$;4%<<2#K '$ 2%&$;4%<<2#K #1=!4&#!F%&1=

Firewalls

IOS Firewall (CBAC) The "Classic" IOS firewall is also known as Context Based Access Control (CBAC). The 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 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 at the end) since CBAC will automatically allow the return traffic.
!" !'4"1+&
'2<1

!"

!'4"1+&

=1'K

2'K

2'K

!"

!'4"1+&

'2<1

<K.!#1*2??

.&"

!"

!'4"1+&

'2<1

<K.!#1*2??

&+"

!'&1#.2+1

5&,1#'1&

676

-!'4!=1

!'&1#.2+1/

!"

!'4"1+&

<K.!#1*2??

!'

!'&1#.2+1

41#!2?

676

-$%&4!=1

!'&1#.2+1/

!"

2++144;(#$%"

@66

!'

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.

Copyright 2009, Rob Webber

53

Rob Webber's CCIE Notes from Experience Version 8.0 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 2)*-)* command. whatever server is configured with the
?$((!'(

!"

!'4"1+&

'2<1

.!#1*2??;@

&+"

!"

!'4"1+&

2%=!&;&#2!?

!'&1#.2+1

324&5&,1#'1&

676

-!'4!=1

!'&1#.2+1/

!"

2==#144

@6HE6HE6H@

N88HN88HN88H6

!'&1#.2+1

324&5&,1#'1&

67@

-!'4!=1

!'&1#.2+1/

!"

2==#144

@6HN6HD6H@

N88HN88HN88H6

!'&1#.2+1

324&5&,1#'1&

@76

-!'4!=1

!'&1#.2+1/

!"

2==#144

@6HU6HU6H@

N88HN88HN88H6

!'&1#.2+1

41#!2?

N76

-$%&4!=1

!'&1#.2+1/

!"

!'4"1+&

.!#1*2??;@

$%&

!"

2++144;(#$%"

@86

!'

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 5!$),$#") command, then applied to interfaces using the 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.
e$'1
41+%#!&K

e$'1;

<1<F1#

41+%#!&K

Copyright 2009, Rob Webber

54

Rob Webber's CCIE Notes from Experience Version 8.0 .#22,"#1,$#") The command creates a class-map and enters class-map configuration mode. Each class-map must use either the or keyword. Class-maps can 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 or statement, since they are more specific.
+?244;<2" &K"1

!'4"1+&

f<2&+,;2'K

<2&+,;2??g

<2&+,;2'K

<2&+,;2??

<2&+,

<2&+,

"#$&$+$?

&+"

<2&+,

"#$&$+$?

%="

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 1!.+ 0,"#1,$#") TCP traffic, for example). The command creates the policy and enters policy-configuration mode. .#22, Classes (previously configured with the "#1,$#") command) can then be configured for the inspect, pass or drop action.
"$?!+K;<2" &K"1

!'4"1+&

+?244;<2"

&K"1

!'4"1+&

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 1#*#")/)*,"#1,$#") command creates a parameter map and enters parameter-map configuration mode. Parameter maps can be applied to particular classes within a policy-map by adding it after the command:
"2#2<1&1#;<2"

&K"1

!'4"1+&

!'4"1+&

"2#2<1&1#;<2"

&K"1

!'4"1+&

<K;"2#2<1&1#;<2"

-"2#2<1&1#;<2"

+$'.!(%#2&!$'

,1#1/

"$?!+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"

5!$),1#+*, Finally, the policy map is activated by the $#") 2!'* ),5!$),$#")& %)2/+$#/+!$,5!$),$#") command and enters zone-pair configuration mode, where the 1!.+ 0,"#1,$#") command applies the policy-map between the source and destination zones. For the ,I recommend using the source zone followed by a hyphen, followed by the destination zone. So you would have a command such as & The keyword 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.
e$'1;"2!#
41+%#!&K 4$%#+1 =14&!'2&!$' 41#>!+1; "$?!+K &K"1

!'4"1+&

e$'1;"2!#;'2<1

e$'1;"2!#

41+%#!&K

$%&4!=1;!'4!=1

4$%#+1

$%&4!=1 =14&!'2&!$'

!'4!=1H

41?.

Copyright 2009, Rob Webber

55

Rob Webber's CCIE Notes from Experience

Frame Relay
=?+!

Version 8.0
.#2<1;#1?2K

Frame Relay traffic shaping always requires a command since this is where you configure the traffic shaping commands.

!'&1#.2+1;

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-topoint 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 command (preferred) or by applying a 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 pointto-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 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
.#2<1;#1?2K

!'&1#.2+1;=?+!

.#2<1;#1?2K

<2"

.#2<1;#1?2K

!'&1#.2+1;=?+!

@66

Copyright 2009, Rob Webber

56

Rob Webber's CCIE Notes from Experience Version 8.0 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 inversearp. 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.

Copyright 2009, Rob Webber

57

Rob Webber's CCIE Notes from Experience Version 8.0 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.

Copyright 2009, Rob Webber

58

Rob Webber's CCIE Notes from Experience

Version 8.0

Central Site Frame Relay rnoeufter I t r ace Issues


No subinterfaces No subinterfaces No subinterfaces

Table 2: Frame Relay Interface Types and Issues

Remote Site Frame Relay router


Interface Issues No subinterfaces Need a frame-relaymap statement for all neighbors. Need ip ospf priority 0 on all remotes. Need to enable IP split horizon. Point-Point Need frame-relayinterface-dlci subinterfaces command. OSPF network type mismatch - probably have to use ip ospf network point-to-multipoin to t make it work. Multipoint Need frame-relayinterface-dlci subinterfaces command. Need either: On remotes:a frame-relaymap statementfor all neighbors and ip ospf priority 0, or ip ospf network point-tomultipoint everywhere. No subinterfaces OSPF network type mismatch- set remotes to ip ospf network point-topoint. Remotes will be on different subnets. Need to enable IP split horizon. Point-Point Need frame-relayinterface-dlci subinterfaces command. Multipoint Need frame-relayinterface-dlci subinterfaces command. OSPF network type mismatch - set remotes to ip ospf network point-to-point. No subinterfaces Need a frame-relaymap statement for all neighbors. Need ip ospf priority 0 on all remotes. On 11.3 and lower, need ip ospf network point-to-multipointor statically defined OSPF neighbors. Need to enable IP split horizon. Point-Point Need frame-relayinterface-dlci subinterfaces command. OSPF network type mismatch - probably have to use ip ospf network point-to-multipoin to t make it work.

May need to disable IP split horizon. OSPF network type mismatch - probably have to use ip ospf network point-to-mutipoint to l make it work. May need to disable IP split horizon. Very unlikely configuration. May need to disable IP split horizon.
Need frame-relayinterface-dlci command. OSPF network type mismatch. Need frame-relayinterface-dlci command. Need frame-relayinterface-dlci command. OSPF network type mismatch. Very unlikely configuration. Need frame-relayinterface-dlci command. Need to disable IP split horizon.

Point-Point subinterfaces Point-Point subinterfaces Point-Point subinterfaces Multipoint subinterfaces

Multipoint subinterfaces

Multipoint subinterfaces

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

Very unlikely configuration.

Need frame-relayinterface-dlci command. Need either: On remotes:a frame-relaymap statementfor all neighbors and ip ospf priority 0, or ip ospf network point-tomultipoint everywhere.

OSPF

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

F#$2=+24&

Copyright 2009, Rob Webber

59

Rob Webber's CCIE Notes from Experience Version 8.0 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 on all remotes (because you want the hub router to be the designated router).
!"
$4". "#!$#!&K 6

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 at the end not using subinterfaces. If you use a combination of physical and multipoint subinterfaces, use
!"
$4". '1&*$#R "$!'&;&$;"$!'&

!"

$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 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.
(?F" "#!$#!&K

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 command can raise (for more
(?F" +?!1'&;+2+,1 <2W!<%<

Copyright 2009, Rob Webber

60

Rob Webber's CCIE Notes from Experience Version 8.0 than 2000 end-stations) or lower (to conserve memory) this default. The command executed on the AVG will display this cache.
4,$* (?F" =1&2!?

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"

!"

@6HUEHDNH@

(?F"

"#!$#!&K

@68

(?F"

"#11<"&

(?F"

2%&,1'&!+2&!$'

&1W&

Y5"2&#!$&4

7*!'1 GLBP has hello and hold timers just like HSRP and VRRP ( , 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 ( 7*!'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.
(?F" &!<1#4 (?F" &!<1#4 #1=!#1+&

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, 7*!'1,$'"()*& which is then encrypted using an MD5 hash. The 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 and password ( ) of cupcakes is applied to a router using GLBP group 8. The name links the key definition to the GLBP interface authentication:
(?F" 2%&,1'&!+2&!$' <=8

R1K;4&#!'(

f6

Ug

=$'%&4

R1K;4&#!'(

R1K

+,2!'

=$'%&4

R1K

R1K;4&#!'(

+%"+2R14

!'&1#.2+1

324&5&,1#'1&676

!"

2==#144

@UNH@EH6H@

N88HN88HN88H6

(?F"

2%&,1'&!+2&!$'

<=8

R1K;+,2!'

=$'%&4

(?F"

!"

@UNH@EH6H8

Copyright 2009, Rob Webber

61

Rob Webber's CCIE Notes from Experience Version 8.0 Unlike HSRP and VRRP, GLBP has built-in load balancing (in fact, it is the 7*!'1& appeal of GLBP). The 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 endstation 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 7*!'1& more or fewer end-stations, specified with the command.
(?F" ?$2=;F2?2'+!'( (?F"

*1!(,&!'(

7*!'1 3)+78/ command specifies the weight of each The 7*!'1 !(9) /,$'"()* GLBP member. The command simply identifies that some object with the !(9) /,$'"()* number will be tracked, and optionally a decrement value for the weight !(9) /,$'"()*& can be added to this command (default is 10). The +$/)*:# ) global command is still required to identify the actual object (interface) to be tracked, which must include either 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 7*!'1 address configured and has IP routing enabled. Optionally, the 3)+78/ command can have an upper and lower weight assigned. If tracking drops a router's weight below the 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 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.
(?F"

*1!(,&!'(

(?F"

*1!(,&!'(

&#2+R

&#2+R

!'&1#.2+1

?!'1;"#$&$+$?

!"

#$%&!'(

(?F"

*1!(,&!'(

?$*1#

show glbp [interfa e-type interfa e-number][group] [state] [brief] debug glbp errors debug glbp events debug glbp pa ets

Home Lab

c c ck

%""1#

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

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience Version 8.0 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 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.
"2#&!&!$' .?24, @ @E

Copyright 2009, Rob Webber

63

Rob Webber's CCIE Notes from Experience

Version 8.0

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.binfor an image. The "jos56i" is the feature set. This represents Enterprise Plus

Copyright 2009, Rob Webber

64

Rob Webber's CCIE Notes from Experience Version 8.0 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 for Windows).

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

Copyright 2009, Rob Webber

65

Rob Webber's CCIE Notes from Experience Version 8.0 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:
Internet

Cable Modem, DSL router, or other broadband Internet access device

192.168.123.254/24 192.168.123.10/24
10 Mb/s Ethernet

accept DHCP address from Internet NAT telnet connections to 192.168.123.10


2509, 2511 or similar terminal server router
async connection to the console

async connection to the console async connection to the console

router1

router2

router3

Automatically Logging in to All Routers


Copyright 2009, Rob Webber

Figure 6: Home Lab with Internet Connectivity

66

Rob Webber's CCIE Notes from Experience

Version 8.0

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&1 34 -0,&12*1567& 34 --0,1&1 /) 34!" 1"% %


& !"#$% & &

+#, &./$% # (.& +#, (2&


& ! &. .& ! &. .& ! &. .&

+#,

+#, &./$% # .& +#, (2&


&

#$ &'(&)*+ ,-./ 0&0 # 0123/ 1'0 #$ &4' ,-./ 0&0

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

34 - 1(2& & 138


&

+#,

+#, &. +#, &

!" %%"% %% !% % -0,&12*1567&


! &. .& #/#.

Copyright 2009, Rob Webber

67

Rob Webber's CCIE Notes from Experience server router (such as in the script above.
!"

You can repeat the portion of the script in bold for each of your routers (or 7 sends the terminal server a Ctrlother devices). The '+#, , 2 ' 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:
+#, +#, &./$% # .& +#, (2& ! &.9 ++ $/ . +#, . %;<.
! &.=.& .#,.& ! &.9 ++ $/ . +#, . %;<. +#, (2& +#, (2& ! &> & ! &. .&

-0 &1 *156
,$4& #@

@H@H@H@

N66@

Version 8.0 ) and update the names

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

34 -0--0,,1&&112*1567& /3 2-: & 34 -0,&40 & 34 -0,&4 3 -: & 34 -0,&10 & 34 -0,1?&
+#,

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

Copyright 2009, Rob Webber

68

Rob Webber's CCIE Notes from Experience

Intrusion Prevention System (IPS) - IOS

Version 8.0

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.
+12,$#") enables the IPS and may The global command # .. The +12,$#") apply an ACL using the keyword o interface command determines which interfaces will participate in the IPS.
!" !"4
'2<1 ?!4&

!"

!"4

n!'

$%&

The signature definition file (SDF) defines all the attack signatures that the IPS will watch for and defend against. The 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.
!" !"4
4=. ?$+2&!$' .?24,J@NO_GH4=.

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

!'&1#.2+1

M!(

676

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

!'&1#.2+1

32

N7676

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

F#!=(1

!#F

F#!=(1

#$%&1

!"

!'&1#.2+1

GPd@

!"

2==#144

@6HN6HD6HQ6

N88HN88HN88H6

!"

!"4

=1.1'=1#;!"4

!'

IPSec

To configure IPSec:

Then:

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

Copyright 2009, Rob Webber

69

Rob Webber's CCIE Notes from Experience Version 8.0 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 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).
+#K"&$ <2"

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 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 command (to set the peer's local IPSec peer address).
2'K +#K"&$ <2" <K<2" ?$+2?;2==#144 ?$$"F2+R 6

Copyright 2009, Rob Webber

70

Rob Webber's CCIE Notes from Experience Version 8.0 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.
r1
loopback 150 ip address 10.1.1.1/24

All intefacesin OSPF area 0

loopback 150 ip address 10.4.4.4/24

192.168.123.51/24 eth 0
192.168.123.0/24

Logical IPSec connection

r4

eth 0 172.26.77.4/24 eth 0


172.26.77.0/24

eth 0
r2
loopback 150 ip address 10.2.2.2/24

s0 172.25.33.2

s0 172.25.33.3

r3

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

Copyright 2009, Rob Webber

71

Rob Webber's CCIE Notes from Experience

Version 8.0

Step 2: Pre-shared Keys On r1: On r2: On r4:


+#K"&$ +#K"&$ +#K"&$ +#K"&$

!42R<"

R1K

++!1

2==#144

@UNHNEHUUHQ

!42R<"

R1K

++!1

2==#144

@UNHNEHUUHQ

!42R<"

R1K

++!1

2==#144

@:NH@EOH@NDH8@

!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: On r2: 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+

+#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: On r2: On r4:

2++144;?!4&

@6Q

"1#<!&

!"

@6H@H@H6

6H6H6HN88

@6HQHQH6

6H6H6HN88

2++144;?!4&

@6Q

"1#<!&

!"

@6HNHNH6

6H6H6HN88

@6HQHQH6

6H6H6HN88

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 <2&+, 2==#144 @6Q 41& "11# 41& &#2'4.$#<;41&

!"41+;!42R<"

@UNHNEHUUHQ

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

Copyright 2009, Rob Webber

72

Rob Webber's CCIE Notes from Experience

Version 8.0

Step 6: Apply the crypto map to an interface On r1:


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

On r2: On r4:

!'&1#.2+1

41#!2?

+#K"&$

<2"

<K<2"

!'&1#.2+1

5&,1#'1&

+#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 command:
4,$* +#K"&$

!"41+

42

#@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+?T

o
+,-

!"#$%

&'()"%*

+,-

!"#$%

&'(./"$*

!"#$%

012&%$

+,

!"#$%

0&()"%*

+3-

!"#$%

0&(./"$*

+3-

!"#$%

4&.15/

+3

0"R&4

+$<"#1441=J

6T

0"R&4

=1+$<"#1441=J

0"R&4

'$&

+$<"#1441=J

6T

0"R&4

+$<"#H

.2!?1=J

6T

0"R&4

=1+$<"#144

.2!?1=J

041'=

1##$#4

OT

0#1+>

1##$#4

?$+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+

!'

%41

41&&!'(4

hnB%''1?T

o
@T +#K"&$ <2"J <K<2" ?!.1&!<1

4?$&J

6T

+$''

!=J

N666T

.?$*Z!=J

42

&!<!'(J

#1<2!'!'(

R1K

-R741+/J

-QE6U::O7DDEQ/

dP

4!e1J

FK&14

#1"?2K

=1&1+&!$'

4%""$#&J

!'F$%'=

2,

424J

!'F$%'=

"+"

424J

$%&F$%'=

14"

424J

4"!J

6WX3DNE6DO-N:D:D@QNDN/

Copyright 2009, Rob Webber

73

Rob Webber's CCIE Notes from Experience


&#2'4.$#<J 14";=14 14";4,2;,<2+

Version 8.0
T

!'

%41

41&&!'(4

hnB%''1?T

o
NT
+#K"&$ <2"J <K<2" ?!.1&!<1

4?$&J

6T

+$''

!=J

N66@T

.?$*Z!=J

42

&!<!'(J

#1<2!'!'(

R1K

-R741+/J

-QE6U::O7DDEQ/

dP

4!e1J

FK&14

#1"?2K

=1&1+&!$'

4%""$#&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 after the 25 pings. You'll notice the traffic increases by the 25 packets:
4,$* +#K"&$

!"41+

42

#@0"!'(

[#$&$+$?

f!"gJ

B2#(1&

d[

2==#144J

+6787878

A1"12&

+$%'&

f8gJ

N8

2&2(#2<

4!e1

f@66gJ

B!<1$%&

!'

41+$'=4

fNgJ

5W&1'=1=

+$<<2'=4

f'gJ

)$%#+1

2==#144

$#

!'&1#.2+1J

+67+7+7+

BK"1

$.

41#>!+1

f6gJ

)1&

F!&

!'

d[

,12=1#p

f'$gJ

P2?!=2&1

#1"?K

=2&2p

f'$gJ

2&2

"2&&1#'

f6WXGI

gJ

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

41+$'=4J

[2+R1&

41'&

*!&,

4$%#+1

2==#144

$.

@6H@H@H@

LLLLLLLLLLLLLLLLLLLLLLLLL

)%++144

#2&1

!4

@66

"1#+1'&

-N87N8/T

#$%'=;&#!"

<!'72>(7<2W

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+?T

o
89-

!"#$%

&'()"%*

89-

!"#$%

&'(./"$*

!"#$%

012&%$

89

!"#$%

0&()"%*

8+-

!"#$%

0&(./"$*

8+-

!"#$%

4&.15/

8+

Copyright 2009, Rob Webber

74

Rob Webber's CCIE Notes from Experience


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 =1+$<"#144 .2!?1=J 6 041'= 1##$#4 OT 0#1+> 1##$#4 6

Version 8.0
0"R&4

?$+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+

!'

%41

41&&!'(4

hnB%''1?T

o
@T +#K"&$ <2"J <K<2" ?!.1&!<1

4?$&J

6T

+$''

!=J

N666T

.?$*Z!=J

42

&!<!'(J

#1<2!'!'(

R1K

-R741+/J

-QE6U::Q7@@68/

dP

4!e1J

FK&14

#1"?2K

=1&1+&!$'

4%""$#&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+

!'

%41

41&&!'(4

hnB%''1?T

o
NT
+#K"&$ <2"J <K<2" ?!.1&!<1

4?$&J

6T

+$''

!=J

N66@T

.?$*Z!=J

42

&!<!'(J

#1<2!'!'(

R1K

-R741+/J

-QE6U::Q7@@68/

dP

4!e1J

FK&14

#1"?2K

=1&1+&!$'

4%""$#&J

$%&F$%'=

2,

424J

$%&F$%'=

"+"

424J

#@0

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

!42R<"

42

#@04,$

+#K"&$

!42R<"

42

=4&

4#+

4&2&1

+$'';!=

4?$&

@UNHNEHUUHQ

@:NH@EOH@NDH86

]_Zd

C5

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

(#$%"

Copyright 2009, Rob Webber

75

Rob Webber's CCIE Notes from Experience


?!.1&!<1 UN66 +#K"&$

Version 8.0
14";=14 14";4,2

!42R<"

R1K

++!1

2==#144

@UNHNEHUUHQ

+#K"&$

!"41+

&#2'4.$#<;41&

#@;#Q41&

+#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&

!"

2==#144

@:NH@EOH@NDH86

N88HN88HN88H6

+#K"&$

<2"

<K<2"

#$%&1#

$4".

'1&*$#R

@:NH@EOH@NDH6

6H6H6HN88

2#12

'1&*$#R

@6H@H@H6

6H6H6HN88

2#12

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&

!"

2==#144

@:NH@EOH@NDH8N

N88HN88HN88H6

!'&1#.2+1

41#!2?

!"

2==#144

@UNHN8HDDHN

N88HN88HN88H6

+#K"&$

<2"

<K<2"

#$%&1#

$4".

'1&*$#R

@:NH@EOH@NDH6

6H6H6HN88

2#12

'1&*$#R

@UNHN8HDDH6

6H6H6HN88

2#12

'1&*$#R

@6HNHNH6

6H6H6HN88

2#12

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&

Copyright 2009, Rob Webber

76

Rob Webber's CCIE Notes from Experience


+#K"&$ <2" <K<2"

Version 8.0

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&

!"

2==#144

@UNHNEHUUHQ

N88HN88HN88H6

+#K"&$

<2"

<K<2"

#$%&1#

$4".

'1&*$#R

@UNHNEHUUH6

6H6H6HN88

2#12

'1&*$#R

@6HQHQH6

6H6H6HN88

2#12

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 global configuration command.
!">E
%'!+24&;#$%&!'(

Access Lists ;<=6$#") command, Access lists are created with the where 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 ;<=6$#") command there formatted. That is, after the 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
!">E
2++144;?!4&

XICZ'2<1

!">E

2++144;?!4&

Copyright 2009, Rob Webber

77

Rob Webber's CCIE Notes from Experience Version 8.0 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 command:
41S%1'+1

N8

"1#<!&

&+"

2'K

2'K

#D04,$

#%'

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

#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,$

#%'

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

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

$%&

?!'1

>&K

!">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.341.1.10.145.248.1!!" Now its not quite .
Copyright 2009, Rob Webber 78

Rob Webber's CCIE Notes from Experience Version 8.0 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:9812101E 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.

Copyright 2009, Rob Webber

79

Rob Webber's CCIE Notes from Experience Version 8.0 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

41+$'=4J

LLLLL

)%++144

#2&1

!4

@66

"1#+1'&

-878/T

#$%'=;&#!"

<!'72>(7<2W

@N7@N7@N

<4

BGP

#@0

For BGP, routers run a single autonomous system (such as ), 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 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 " " and both IPv4 and IPv6 neighbors will be shown. However, you need to type " " or " " 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.
#$%&1#

F("

E8666

2==#144;.2<!?K

!">E

4,$

!"

F("

'1!(,F$#4

4,$*

F("

!">E

%'!+24&

4,$*

F("

2??

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

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&!$'

Copyright 2009, Rob Webber

80

Rob Webber's CCIE Notes from Experience


#1=!4&#!F%&1 #!" &14& <1&#!+ @ 1W!&;2==#144;.2<!?K L 2==#144;.2<!?K

Version 8.0

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

A look at an IPv6 routing table displays:


#@04,$

!">E

#$%&1

d[>E

A$%&!'(

B2F?1

1'&#!14

I$=14J

I$''1+&1=T

C$+2?T

)&2&!+T

Ad[T

GM[

d@

d)d)

C@T

dN

d)d)

CNT

dX

d)d)

!'&1#2#12

B!<1#4J

l"&!<175W"!#14

@66J@66JJ@7@NO

f676g

>!2

JJT

C$$"F2+RN66T

66J66J@U7'1>1#

@66J@66JJ7EQ

f676g

>!2

JJT

C$$"F2+RN66T

66J66J@U7'1>1#

@:NJ@EOJJ@7@NO

f676g

>!2

JJT

)1#!2?6T

66J68JDO7'1>1#

@:NJ@EOJJ7EQ

f676g

>!2

JJT

)1#!2?6T

66J68JQ@7'1>1#

N66JN66JJ7EQ

f@N67Ng

>!2

35O6JJN56JG633J3588JG6D8T

)1#!2?6T

66J6@JQO766J6NJDQ

D66JD66JJ78E

fN67@g

>!2

@:NJ@EOJ@NDJJ8NT

5&,1#'1&6T

66J66JNE7'1>1#

35O6JJ7@6

f676g

>!2

JJT

Y%??6T

66J68JQ@7'1>1#

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 #2,$'"()*&command, there are no commands. Instead EIGRP is #2,$'"()* interface enabled on each interface with the 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.
!">E
#$%&1# 1!(#" '1&*$#R

!">E

1!(#"

Copyright 2009, Rob Webber

81

Rob Webber's CCIE Notes from Experience Version 8.0 Filtering EIGRP routes requires the router command - using a route-map to filter routes is not supported in EIGRP as it is with some IPv6 routing protocols.
=!4&#!F%&1;?!4& "#1.!W;?!4&

EIGRP summary ranges can be configured on an interface - very similar to IPv4. Apply the interface command to Fa0/0 to only advertise a summary for all routes falling within the range out interface Fa0/0 for EIGRP process 100.
!">E
4%<<2#K;2==#144 1!(#" @66 86@NJX66QJ@J@JJ7EQ

86@NJX66QJ@J@JJ7EQ

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 #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 #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 #2,$'"()*&2) !$%2 and be modified with the #2,$'"()*&2) !$%2 interface commands.
'$

!">E

'1W&;,$";41?.

1!(#"

'$

!">E

4"?!&;,$#!e$'

1!(#"

!">E

,1??$;!'&1#>2?

1!(#"

!">E

,$?=;&!<1

1!(#"

To make a router an EIGRP stub (similar to IPv4) use the


$'?K \ +$''1+&1= \ 4&2&!+ \ 4%<<2#K \

router command (see IPv4 Stub routing on page 52 for detailed explanation of keywords).
#1=!4&#!F%&1=g

4&%F

f#1+1!>1;

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 interface command, such as .
&#2..!+;.!?&1#

!">E

&#2..!+;.!?&1#

F?$+RZ#@

!'

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

#$%&1#

#!"

&14&

!">E

#$%&1#

#!"

&14&

=!4&#!F%&1;?!4&

"#1.!W;?!4&

G?$+RZAd[

!'

)1#!2?6

!">E

"#1.!W;?!4&

G?$+RZAd[

41S

=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

Copyright 2009, Rob Webber

82

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

!">E

#$%&1

BGP filtering can be applied just as it is in IPv4 - distribute lists, neighbor route-maps, neighbor prefix-lists, etc. The line command can be applied to vty, aux and con lines, just like with IPv4.
!">E
2++144;+?244 &1?'1&

#14&#!+&;

!'

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

&+"

!'&1#.2+1

324&5&,1#'1&676

=14+#!"&!$'

d'4!=1

!'&1#.2+1

!">E

2==#144

D6X6JGO66J6JIXJJ7EQ

1%!;EQ

!'&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_[

!'

!">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 , unlike IP OSPF config ( ).
!">E
#$%&1# $4". @ #$%&1# $4". @

Copyright 2009, Rob Webber

83

Rob Webber's CCIE Notes from Experience Rather than using


!">E
$4". @ '1&*$#R 2#12 6

Version 8.0

statements in the router ospf configuration, 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 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).
!">E
$4". @ 2#12 6

When running IPv6 over NBMA (Frame Relay) networks OSPF neighbors must be defined manually. Do this by using the s command, where <address> is the link-local address of the neighbor. Identify the link-local by performing a " " command on the neighbor. Once this is displayed I recommend copying & pasting the link local address into the opposite router's configuration.
!">E
$4". '1!(,F$#
r2==#144

4,$*

!">E

!'&

F#!1.

!'&1#.2+1

41#!2?

676

!">E

$4".

2#12

1'+2"4%?2&!$'

.#2<1;#1?2K

.#2<1;#1?2K

<2"

!">E

35O6JJX6UGJU

!">E

$4".

'1!(,F$#

35O6JJX6UGJU

33J3566J:G@8

@66

33J3566J:G@8

IPv6 OSPF can generate a default route with the command in the router configuration mode. Use the 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:
=1.2%?&;!'.$#<2&!$' $#!(!'2&1

!">E

#$%&1#

$4".

2?*2K4

#N04,$

!">E

#$%&1

d[>E

A$%&!'(

B2F?1

@U

1'&#!14

I$=14J

I$''1+&1=T

C$+2?T

)&2&!+T

Ad[T

GM[

[1#;%41#

)&2&!+

#$%&1

d@

d)d)

C@T

dN

d)d)

CNT

dX

d)d)

!'&1#2#12

c)[3

!'&#2T

cd

c)[3

!'&1#T

c5@

c)[3

1W&

@T

c5N

c)[3

1W&

:;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 interface command. You do not use the 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.
!">E
#!" &14& '1&*$#R

1'2F?1

Copyright 2009, Rob Webber

84

Rob Webber's CCIE Notes from Experience Version 8.0 In fact the only things you can actually configure in the router configuration are things that will look fairly familiar: distance, distribute lists, split horizon (yes, RIPng still uses split horizon!), timers, etc.
!">E
#$%&1# #!" &14&

Configuring routing summaries with IPv6 RIP is similar to EIGRP. Rather than summarizing in the process, RIP summaries are defined on the interface with the 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.
d[>E

#$%&1#

#!"

&14&

!">E

#!"

&14&

4%<<2#K;2==#144

@:NJ@EOJJ7DN

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 command will be required on each one.
!">E
#!" =1.2%?&;!'.$#<2&!$' $#!(!'2&1

&14&

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 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.
#1=!4&#!F%&1

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

Copyright 2009, Rob Webber

85

Rob Webber's CCIE Notes from Experience Version 8.0 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 . 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 . 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 . 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 . 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 . 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!"

&%''1?

<$=1

(#1

!">E

&%''1?

<$=1

!">E!"

2%&$;&%''1?

N66NJF$#=1#;#$%&1#;d[>Q;2==#144JJ7QO

&%''1?

<$=1

!">E!"

E&$Q

&%''1?

<$=1

!">E!"

!42&2"

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

Copyright 2009, Rob Webber

86

Rob Webber's CCIE Notes from Experience Version 8.0 - it may make it easier to remember which tunnel you are working on. The tunnel source is defined with the interface command and the tunnel destination is either configured with the interface command or determined dynamically. The tunnel type is then configured with the interface command.
&%''1? 4$%#+1 &%''1? =14&!'2&!$' &%''1? <$=1

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

!'&1#.2+1

&%''1?

!">E

2==#144

@J@JNJ@JJN7@NE

&%''1?

4$%#+1

C$$"F2+R

&%''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

!'&1#.2+1

&%''1?

!">E

2==#144

@J@JNJ@JJD7@NE

&%''1?

4$%#+1

C$$"F2+R

&%''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.
Copyright 2009, Rob Webber

87

Rob Webber's CCIE Notes from Experience Version 8.0 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: Verify all interfaces are up, up Verify all Frame Relay PVCs are and 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 are my commands:
2H

FH

CcIXC

XIBdP5

2?!24

1W1+

4,$*

!"

#$%&1

2?!24

1W1+

4,$*

#%''!'(;+$'.!(

2?!24

1W1+

4,$*

!"

!'&

F#!1.

2?!24

1W1+

4,$*

!"

$4".

2?!24

1W1+

&

+$'.!(

&1#<

'$

!"

=$<2!';?$$R%"

!"

+?244?144

!"

&+"

4K'*2!&;&!<1

?!'1

+$'4$?1

?$((

4K'

1W!&

?!'1

>&K

?$((

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
Copyright 2009, Rob Webber

88

Rob Webber's CCIE Notes from Experience Version 8.0 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 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,$*

!"

#$%&1

2?!24

1W1+

4,$*

!"

$4".

Thus when you enter: o o int o nei etc.

The router will display: show ip ospf show ip ospf interfaces show ip ospf neighbors 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
Copyright 2009, Rob Webber

89

Rob Webber's CCIE Notes from Experience

Version 8.0

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:

Router r1 r2 r3 r4

Table 3: Sample Loopback Address Assignments

Loopback Address 128.128.201.1/24 128.128.202.1/24 128.128.203.1/24 128.128.204.1/24

Copyright 2009, Rob Webber

90

Rob Webber's CCIE Notes from Experience r5 r6 128.128.205.1/24 128.128.206.1/24

Version 8.0

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

Copyright 2009, Rob Webber

91

Rob Webber's CCIE Notes from Experience

Version 8.0

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 ) as well as the newer commands (such as ). 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.
&2(;4*!&+,!'(

!"

<"?4

!"

Configuring MPLS In order to configure MPLS, you must enable MPLS on the interfaces that will run MPLS ( ). Note that MPLS requires cef, so be sure 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 interface command. If all interfaces run ldp (recommended), you can use the global 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 command. Labels are created using an LSR's MPLS router-id. I recommend setting this to the loopback address with the command. Optionally you can have LSRs authenticate by using the
<"?4

!"

!"

+1.

<"?4

!"

<"?4

?2F1?

"#$&$+$?

?="

<"?4

?="

'1!(,F$#

&2#(1&1=

<"?4

?="

#$%&1#;!=

?$$"F2+R6

.$#+1

<"?4

Copyright 2009, Rob Webber

92

Rob Webber's CCIE Notes from Experience


?="

Version 8.0
"244*$#=

(where 10.1.1.1 is the neighbor address).


<"?4 ?2F1? "#$&$+$? ?=" <"?4 ?=" #$%&1#;!= ?$$"F2+R6 .$#+1 L

'1!(,F$#

>#.

+%4&$<1#@

@6H@H@H@

1#223!*%

command

!'&1#.2+1

M!(2F!&5&,1#'1&676

<"?4

!"

!'&1#.2+1

M!(2F!&5&,1#'1&67@

<"?4

!"

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

Configuring Multiprotocol BGP Multiprotocol BGP is simply a specialized config within BGP. As such, it #2$, defining neighbors, starts with the normal BGP config +1,#%%*)22 etc. However for each MPLS BGP neighbor, the 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("

'1!(,F$#

2+&!>2&1

#$%&1#

F("

E866@

'$

4K'+,#$'!e2&!$'

'1!(,F$#

@6H@H@H@

#1<$&1;24

E866@

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 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!
'1!(,F$# 41'=;+$<<%'!&K

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

Rob Webber's CCIE Notes from Experience

Version 8.0

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).
-*:,$#"). In the lab A VRF is defined simply with the command 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 *!'/),/#*7)/, !""'$+/0 command to allow routes to be passed within a
!"
>#. #= #$%&1;&2#(1&

F$&,

Copyright 2009, Rob Webber

94

Rob Webber's CCIE Notes from Experience

Version 8.0

VRF. Finally, enable a particular interface (facing the CE) to be a member of that customer's VRF. For example: Customer 1
!"
>#. +%4&$<1#@ #=

Customer 2
!"
>#. +%4&$<1#N #=

E8666J@

E8666JN

#$%&1;&2#(1&

F$&,

E8666J@

#$%&1;&2#(1&

F$&,

E8666JN

!'&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 -*:,$#") keyword, as it will have configuration. The PE requires the 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:
2==#144;.2<!?K

!">Q

>#.

#$%&1#

F("

E866@

'$

4K'+,#$'!e2&!$'

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&!$'

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 configuration with its RIP config:
.2<!?K

2==#144;

!">Q

#$%&1#

#!"

Copyright 2009, Rob Webber

95

Rob Webber's CCIE Notes from Experience


L 2==#144;.2<!?K

Version 8.0

!">Q

>#.

+%4&$<1#@

>1#4!$'

'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 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.
'$

!"

<#$%&1;+2+,1

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 interface command to force a router to join the 230.0.0.1 multicast group.
!" !(<"
t$!';(#$%"

ND6H6H6H@

Copyright 2009, Rob Webber

96

Rob Webber's CCIE Notes from Experience

Version 8.0

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


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

!"

PIM (Protocol Independent Multicast) is one of the leading multicast standards and Cisco's preferred multicast 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 a multicast 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 sparse mode 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
Copyright 2009, Rob Webber 97

Rob Webber's CCIE Notes from Experience


!"
"!< #";2==#144

Version 8.0

a statically defined RP, using the 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 autoRP 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:
!"

!!"##$%&#'()(*"+,&'(-./010101(10-220-220-22((

"!<

41'=;#";2''$%'+1

1&,1#'1&676

4+$"1

@E

(#$%";?!4&

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 preferred multicast 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
Copyright 2009, Rob Webber 98

Rob Webber's CCIE Notes from Experience

Version 8.0

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 clientserver 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: (on the client router) Peer mode: (on both routers)
'&" 41#>1# @6H@6H:QH@ '&" "11# @6H@6H:QH@

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

Advanced Commands
Copyright 2009, Rob Webber 99

Rob Webber's CCIE Notes from Experience

Version 8.0

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 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.
'&" <24&1#

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

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 command.
'&" 4$%#+1 ?$$"F2+R 6

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

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 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.
!"
$4". "#!$#!&K 6

You don't need . OSPF does not summarize by default you must configure summarization manually (see Summarization, below).
'$ 2%&$;4%<<2#K

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 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:
'1&*$#R

Placing the loopback in its own area and summarizing:


100

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience


!'&1#.2+1
?$$"F2+R6

Version 8.0

!"

2==#144

@:NH@EOHN8DH@

N88HN88HN88H6

#$%&1#

$4".

'1&*$#R

@:NH@EOHN8DH6

6H6H6HN88

2#12

2#12

#2'(1

@:NH@EOHN8DH6

N88HN88HN88H6

!" !"

Or (much easier!) defining the ospf network type as point-to-point:


?$$"F2+R6 2==#144 @:NH@EOHN8DH@

!'&1#.2+1

N88HN88HN88H6

$4".

'1&*$#R

"$!'&;&$;"$!'&

Network Types OSPF uses four network types as shown in Table 4: OSPF Network Types: Network Type

Broadcast Point-to-Point Non-Broadcast Point-toMultipoint

Hello/Dead Timer (seconds) 10/40 10/40 30/120 30/120

Table 4: OSPF Network Types

Is DR/BDR Used? Yes No Yes No

Example

Ethernet T1 using HDLC or PPP Frame Relay, ATM Hub & Spoke 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 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.
!"
$4". "#!$#!&K

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 Copyright 2009, Rob Webber 101

Rob Webber's CCIE Notes from Experience

Version 8.0

discussed earlier, point-to-point circuits make connectivity easier in almost every way. OSPF over Frame Relay.
d[

$4".

'1&*$#R

"$!'&;&$;<%?&!"$!'&

is my preferred way to run

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 detect WAN port speeds automatically. Thus the command must be used to specify the bandwidth. If no bandwidth is specified on a WAN port, the router assumes T1 speed (1.544 Mb/s).
F2'=*!=&,

The cost can be changed on an interface via the interface command. To change the cost on all interfaces (such as increasing all costs by a factor of 10), use the 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.
!"
$4". +$4& 2%&$;+$4& #1.1#1'+1;F2'=*!=&, @666

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 keyword in the redistribute command. Either type (type 1 or type 2) can be given an initial metric with the 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.
<1&#!+;&K"1 @ <1&#!+

Router ID
Copyright 2009, Rob Webber 102

Rob Webber's CCIE Notes from Experience


#$%&1# $4".

Version 8.0

Each OSPF router uses a router ID to identify itself to other routers. When the OSPF process is started (with the 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 router command, though this is not too common. Distance Using the 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).
#$%&1#;!= =!4&2'+1 $4".

Summarization When you use an 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.
2#12 @ #2'(1

When you use the 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.
4%<<2#K;2==#144 @UNH@UH6H6

N88HN88H6H6

However the OSPF 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
4%<<2#K;2==#144

Copyright 2009, Rob Webber

103

Rob Webber's CCIE Notes from Experience


4%<<2#K;2==#144

Version 8.0

example, OSPF can use the 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.
Area Type area 1 stub area 1 stub nosummary area 1 nssa area 1 nssa nosummary
Gets External Gets InterGets a default routes? Area Routes? route? no yes yes no no yes
no no
2#12 @

Table 5: OSPF Stub and NSSA Area

Can generate Ext Routes?


no no

yes
no
4&%F

no yes

yes yes

Use a stub area ( ) to block external (type 1 and type 2) routes from being sent to the stub area. Use a stub area with no summary ( ) 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).
2#12 @ 4&%F '$;4%<<2#K

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 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.
2#12 @ >!#&%2?;?!'R @8QH@EHDNH@

If area 0 is using authentication, you must add either the $ or to the command. Additionally you must add 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).
R1K
<1442(1;=!(14&;R1K 2#12 >!#&%2?;?!'R 2#12 6 2%&,1'&!+2&!$'
f<1442(1;=!(14&g

2%&,1'&!+2&!$';

For the following network:


Copyright 2009, Rob Webber 104

Rob Webber's CCIE Notes from Experience


A@ ;;; 2#12 6 ;;; AN ;;; 2#12 @ ;;; AD ;;; 2#12

Version 8.0
N
;;; AQ ;;; 2#12

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

2) !$%2

command has an optional keyword of that will specify the length of the graceful restart.

f#14&2#&;!'&1#>2?

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 command on your routers.
'4.

!1&.

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 and keywords. The keyword matches a mask that is greater than or equal to the network specified. The keyword matches a mask smaller than or equal to the one specified.
?1 (1 ?1 (1

(1

So 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).
NU
?1

D6

In this following example:


Copyright 2009, Rob Webber 105

Rob Webber's CCIE Notes from Experience


!"
"#1.!W;?!4& <K?!4& 41S @6 "1#<!& @UNH@EH6H67@E (1

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

Copyright 2009, Rob Webber

106

Rob Webber's CCIE Notes from Experience

Version 8.0

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 example Weighted Fair Queuing (WFQ) and Weighted Random Early Detection (WRED) can both use IP Precedence bits to determine how to treat packets.

IP Precedence Bits 0 (000) 1 (001) 2 (010) 3 (011) 4 (100) 5 (101) 6 (110) 7 (111)
Copyright 2009, Rob Webber

Table 6: IP Precedence Classes

Name of Service Class routine priority immediate flash flash-override critical internet control (reserved) network control (reserved)
107

Rob Webber's CCIE Notes from Experience

Version 8.0

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.

DSCP Value Default Forwarding Assured Forwarding - Class 1 - 4 Expedited Forwarding

Table 7: DSCP Classes

Forwarding Class 000000 001010 through 100110 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 or 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'K <2&+,;2?? <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"/

Copyright 2009, Rob Webber

108

Rob Webber's CCIE Notes from Experience


<2&+, >?2'

Version 8.0

-]$)/

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 how Weighted Random Early Detection (WRED) treats packets in a congestion situation. Setting the CoS value is not as useful since it is not maintained from endto-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

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

&2F?1;<2"

+$4;&$;"#1+1=1'+1;&2F?1

<2"

.#$<

&$

<2"

.#$<

&$

Copyright 2009, Rob Webber

109

Rob Webber's CCIE Notes from Experience


<2" .#$<

Version 8.0

&$

<2"

.#$<

&$

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-Based Weighted Fair Queuing (WFQ) Class-Based Weighted Fair Queuing (CBWFQ) Distributed Weighted Fair Queuing (DWFQ) Distributed Class-Based Weighted Fair Queuing (DCBWFQ) The first two types are designed for the standard IOS routers. The distributed types are simply the same implementations as the nondistributed types, but designed for the Route Switch Processor (7000 series) or the Versatile Interface Processor (VIP) (7500 series). In this guide unless otherwise noted WFQ will denote both WFQ 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

Copyright 2009, Rob Webber

110

Rob Webber's CCIE Notes from Experience

Version 8.0

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, and WFQ 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 use Weighted 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 command to limit the bandwidth used by that traffic:
F2'=*!=&,
"$?!+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 ( ) as well as other modification. With CBWFQ, you can define as many classes as you'd like, each with their own bandwidth configuration.
?!<!&

S%1%1;

Low Latency Queuing (LLQ) is a part of CBWFQ - it introduces strict priority queuing (for traffic such as voice and video) within CBWFQ. Classmaps are still used to identify traffic and a policy-map is used with the class included. However rather than using the command, one class can be configured with the command. This specifies the
F2'=*!=&,
"#!$#!&K

Copyright 2009, Rob Webber

111

Rob Webber's CCIE Notes from Experience

Version 8.0

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 ( for 768 Kb/s) or as a percentage of the link ( 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 UEO "#!$#!&K "1#+1'&

N8

"$?!+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

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=4000bytes) 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
Copyright 2009, Rob Webber 112

Rob Webber's CCIE Notes from Experience

Version 8.0

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 way WFQ 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 ( ) Creating a traffic policy ( ) to define the actions to be taken on the traffic ( ) ) Applying the policy to an interface (
+?244;<2" "$?!+K;<2" "$?!+1 41#>!+1;"$?!+K +?244;<2" "$";1<2!? <2&+, 2++144;(#$%" @66 L "$?!+K;<2" ?!<!&;1<2!?

Copyright 2009, Rob Webber

113

Rob Webber's CCIE Notes from Experience


+?244 "$";1<2!? "$?!+1 @NO666 @E666

Version 8.0
&#2'4<!& 1W+11=; =#$"

DN666

+$'.$#<;2+&!$'

2+&!$'

41&;S$4;&#2'4<!&

>!$?2&1;2+&!$'

!'&1#.2+1

41#!2?

676

41#>!+1;"$?!+K

!'"%&

?!<!&;1<2!?

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 in the class-map or an 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.
<2&+, 2'K

!"

2'K

2'K

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
Copyright 2009, Rob Webber 114

Rob Webber's CCIE Notes from Experience

Version 8.0

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

"$?!+K;<2"

,$%4&$'

+?244

N8ER

4,2"1

2>1#2(1

N8E666

!'&1#.2+1

41#!2?

41#>!+1;"$?!+K

$%&"%&

,$%4&$'

Copyright 2009, Rob Webber

115

Rob Webber's CCIE Notes from Experience


+?244 <2";+?244

Version 8.0
<2";

To configure Frame Relay Traffic Shaping create a class with the command. Apply the to an interface, subinterface or DLCI using the command (or the command, depending on the config mode you are in).
+?244 .#2<1;#1?2K +?244

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"!'(

!'&1#.2+1

)1#!2?@H@

"$!'&;&$;"$!'&

.#2<1;#1?2K

+?244

8@NiZPI4

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6@

!'&1#.2+1

)1#!2?@HN

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6N

!'&1#.2+1

)1#!2?@HD

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6D

!'&1#.2+1

)1#!2?@HQ

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6Q

+?244

N8EiZPI4

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

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

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

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

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience


!"
#4>"

Version 8.0
F2'=*!=&,

@+$/)*:# ), RSVP is enabled on an interface with the 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&+, <2&+, <2&+,

)2#24$&2;&#2..!+

2++144;(#$%"

@6@

!
@

!'"%&;!'&1#.2+1

41#!2?

"#$&$+$?

!"

"$?!+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!'(

`A5

#2&,1#

&,2'

&,1

=1.2%?&T

&2!?

=#$"/

!'&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&

"#$&$+$?

!"

&+"

O6

-BI[

"$#&

O6

&$

S%1%1

N/

S%1%1;?!4&

"#$&$+$?

!"

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

FK&1;+$%'&

@666

-FK&1

+$%'&

@666

!'

S%1%1

N/

PQ:
"#!$#!&K;?!4&

"#$&$+$?

!"

,!(,

?!4&

or

"#!$#!&K;?!4&

!'&1#.2+1

1&,1#'1&

@76

?$*

or

"#!$#!&K;?!4&

"#$&$+$?

!"

<1=!%<

%="

@E@

!'&1#.2+1

41#!2?

@76

"#!$#!&K;(#$%"

2++144;?!4&

"1#<!&

@:NH@EOH@H6

6H6H6HN88

LLQ: Copyright 2009, Rob Webber 117

Rob Webber's CCIE Notes from Experience


+?244;<2" >$!+1;1'2F?1= <2&+, 2++144;(#$%" @86

Version 8.0

"$?!+K;<2"

",$1'!W

+?244

>$!+1;1'2F?1=

"#!$#!&K

@NO

!'&1#.2+1

41#!2?

41#>!+1;"$?!+K

$%&"%&

",$1'!W

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

***

"$?!+K;<2"

42?1<

+?244

&1?'1&;+?244

41&

!"

"#1+1=1'+1

+?244

*1F;+?244

41&

!"

=4+"

1.

!'&1#.2+1

41#!2?

@7@

41#>!+1;"$?!+K

!'"%&

42?1<

!"

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

***

Policing:
+?244;<2" .&" <2&+, 2++144;(#$%" @6@ L "$?!+K;<2" ?!<!&;.&" +?244 .&"

"$?!+1

N8E666

DN666

DN666

+$'.$#<;2+&!$'

&#2'4<!&

1W+11=;2+&!$'

=#$"

>!$?2&1;2+&!$'

=#$"

!'&1#.2+1

41#!2?

676

41#>!+1;"$?!+K

!'"%&

?!<!&;.&"

Copyright 2009, Rob Webber

118

Rob Webber's CCIE Notes from Experience


2++144;?!4& @6@ "1#<!& &+" 2'K 2'K 1S .&";=2&2

Version 8.0

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+&$#

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

"""

<%?&!?!'R

"""

<%?&!?!'R

!'&1#?12>1

"""

<%?&!?!'R

.#2(<1'&;=1?2K

D6

<%?&!?!'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"!'(

!'&1#.2+1

)1#!2?

D76H@

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

OD

"""

P!#&%2?;B1<"?2&1@

+?244

.#2<1;">+

!'&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

<2";+?244

.#2<1;#1?2K

.#2<1;">+

.#2<1;#1?2K

+!#

:E666

.#2<1;#1?2K

F+

@666

.#2<1;#1?2K

F1

'$

.#2<1;#1?2K

2=2"&!>1;4,2"!'(

Copyright 2009, Rob Webber

119

Rob Webber's CCIE Notes from Experience LFI using FRF.12:


!'&1#.2+1
+?244

Version 8.0

41#!2?

@7@

.#2<1;#1?2K

&#2..!+;4,2"!'(

.#2<1;#1?2K

!'&1#.2+1;=?+!

@68

3A;.#2(<1'&

<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"!'(

!'&1#.2+1

)1#!2?@H@

"$!'&;&$;"$!'&

.#2<1;#1?2K

+?244

8@NiZPI4

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6@

!'&1#.2+1

)1#!2?@HN

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6N

!'&1#.2+1

)1#!2?@HD

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6D

!'&1#.2+1

)1#!2?@HQ

"$!'&;&$;"$!'&

.#2<1;#1?2K

!'&1#.2+1;=?+!

@6Q

+?244

N8EiZPI4

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

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

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

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 120

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience

Version 8.0

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 command rather than using . The command allows more precise control over which networks are given to a routing process.
'1&*$#R #1=!4&#!F%&1 +$''1+&1= '1&*$#R

The command makes a route internal to a routing process, whereas makes a route external to a routing process (such as EIGRP or OSPF).
'1&*$#R #1=!4&#!F%&1

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 command you need to explicitly configure the EIGRP metric (otherwise no routes get redistributed). You can do this by:
#1=!4&#!F%&1 #$%&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

Copyright 2009, Rob Webber

121

Rob Webber's CCIE Notes from Experience

Version 8.0

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 keyword, such as (or the 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.
<1&#!+ <1&#!+

=1.2%?&;<1&#!+

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 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&#!+;&K"1 @ #$%&1#

F("

E8666

#1=!4&#!F%&1

$4".

<2&+,

!'&1#'2?

1W&1#'2?

1W&1#'2?

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.
Copyright 2009, Rob Webber 122

Rob Webber's CCIE Notes from Experience

Version 8.0

For example, examine the diagram in Figure 8: OSPF Summarization with RIP Redistribution:
router4

RIP router3 router1 router2

172.16.10.0/24 172.16.8.0/24 172.16.9.0/24 OSPF Area 1

172.16.254.0/24
OSPF Area 0

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 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.
2#12 @ #2'(1 @UNH@EHOH6

Figure 8: OSPF Summarization with RIP Redistribution

N88HN88HN8QH6

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
123

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience

Version 8.0

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!$'

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 Copyright 2009, Rob Webber 124

Rob Webber's CCIE Notes from Experience

Version 8.0

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 distributelist) 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 Copyright 2009, Rob Webber 125

Rob Webber's CCIE Notes from Experience

Version 8.0

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

&,!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
172.16.1.1/24
hostname R1 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 192.168.200.0

R3

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!$'

Figure 9: Using Route Tags

#1=!4&#!F%&1

4&2&!+

<1&#!+

#$%&1;<2"

4&2&!+Bc#!"

'1&*$#R

@:NH@EOH@@H6

'1&*$#R

@UNH@EH6H6

'$

2%&$;4%<<2#K

#$%&1;<2"

4&2&!+Bc#!"

"1#<!&

@6

<2&+,

!"

2==#144

"#1.!W;?!4&

4&2&!+Bc#!"

41&

&2(

NNNN

!"

"#1.!W;?!4&

4&2&!+Bc#!"

41S

"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 Copyright 2009, Rob Webber 126

Rob Webber's CCIE Notes from Experience

Version 8.0

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

#$%&1;<2"

#!"Bc1!(#"

"1#<!&

@6

<2&+,

&2(

NNNN

Router Services
FTP

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. 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 command can be used.
+$"K .?24,

.&"

!"

.&"

%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 (traffic entering) command or the (traffic leaving) command. Netflow requires cef. Cef is on by default ( ), 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 command. In order to send NetFlow to a receiving host, use the 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.
!"
.?$*

!'(#144

!"

.?$*

1(#144

!"

+1.

!"

.?$*;1W"$#&

>1#4!$'

!"

.?$*;

1W"$#&

=14&!'2&!$'

@6H@H@H@

Copyright 2009, Rob Webber

127

Rob Webber's CCIE Notes from Experience There are several optional and commands used to customize Netflow. These are optional.
!"
.?$*;+2+,1

Version 8.0
!"
.?$*;1W"$#&

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 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 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 command in RIP to include that network in your routing, but also use command in RIP to prevent updates from being sent out Ethernet 0.
'1&*$#R 4,$*

!"

#$%&1

'1&*$#R

@:NH@EOHDDH6

"244!>1;!'&1#.2+1

1&,1#'1&

Copyright 2009, Rob Webber

128

Rob Webber's CCIE Notes from Experience

Version 8.0
"244!>1;!'&1#.2+1

Note: For protocols such as OSPF and EIGRP the 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 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 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."
<1&#!+ =1.2%?&;<1&#!+

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 command. For EIGRP, use the command.
-'$/

!"

4"?!&;,$#!e$'

-'$/

!"

4"?!&;,$#!e$'

1!(#"

Copyright 2009, Rob Webber

129

Rob Webber's CCIE Notes from Experience

Version 8.0

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

2) !$%2 and command has the optional keywords $'"()*. 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.
!"
44, &!<1$%& 2%&,1'&!+2&!$';#1&#!14

The command shows the status, version and settings of the SSH server. The 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 portion of the config. As such the command is required or SSH must be included in the command in the config.
4,$*

!"

44,

4,$*

44,

?!'1

>&K

&#2'4"$#&

!'"%&

2??

&#2'4"$#&

!'"%&

?!'1

>&K

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 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
+$'&#$?;4,!.&;E +$'&#$?;4,!.&;E

Copyright 2009, Rob Webber

130

Rob Webber's CCIE Notes from Experience

Version 8.0

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 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,!.&;E +$'&#$?;4,!.&;E 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 ^

%'!&

6T

!=F

6W:GDOIT

=#!>1#

4&#%+&%#1

2&

6W:36@6

F%..1#

4!e1

@8NQ

%'!&

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 Copyright 2009, Rob Webber 131

Rob Webber's CCIE Notes from Experience

Version 8.0

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 routemap 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.
Subnet Mask
255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248 255.255.255.252 255.255.255.254 255.255.255.255 This column simply needs to be memorized
Table 8: IP Subnetting Summary

Number of Subnet Bits /24 /25 /26 /27 /28 /29 /30 /31 /32 This column begins at /24 and increases by 1 each row

Number of IP Addresses
256 128 64 32 16 8 4 2 1 This column begins at 256 and gets cut in half with each row 132

Copyright 2009, Rob Webber

Rob Webber's CCIE Notes from Experience

Version 8.0

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
255.255.254.0 255.255.252.0 etc.

Number of Subnet Bits /23 /22

Number of IP Addresses
512 1024

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, is the "permit any." For mac-address lists is the "permit any." At the end of an access-list place a " " 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 command in your configuration. This command allows you to specify the size of the buffer, though I've always found the default size to
"1#<!&

"1#<!&

6666H6666H6666

....H....H....

=1'K

2'K

2'K

?$(

?$((!'(

F%..1#1=

Copyright 2009, Rob Webber

133

Rob Webber's CCIE Notes from Experience


be sufficient. Use the buffer.
?$((!'( 4,$* ?$(

Version 8.0

command to view the messages in the


+$'4$?1

The (or ) command controls whether messages are sent to the console. This is enabled ( ) by default. In order to have messages sent to a telnet session, you need both the command and the command.
+$'4$?1 '$ ?$((!'( ?$((!'( +$'4$?1 ?$((!'( +$'4$?1 &1#<!'2? <$'!&$#

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 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:
1W1+;&!<1$%& 6 6 ?!'1 +$' 6 1W1+;&!<1$%& @N6 6 "#!>!?1(1 ?1>1? @8

'$

?$(!'

?!'1

>&K

1W1+;&!<1$%&

@N6

"#!>!?1(1

?1>1?

@8

'$

?$(!'

Terminal Editing brings you to the beginning of the line brings you to the end of the line repaints a line (handy if a console or debug message pops up) is the same as "up arrow" (in case that isn't working)
+$'&#$?;X +$'&#$?;5 +$'&#$?;A +$'&#$?;l

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!

Copyright 2009, Rob Webber

134

Rob Webber's CCIE Notes from Experience

Version 8.0

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.

% ' &(46:68$%&&7:#; -!24"82%$*0=/%!"#5'%) /0)/ 0 2/2 2&/:8 %&4#* %28 '$ 5'%4* %4*
5*#$ 5 %499 5 %46 $ 466$ 5 / .33 466$ 5 !"#$ %*

$ 5 &%) ./0)/ )%.33/.33/.33/2 ' )2< %) <%9 % -. .2 2 / = !; %) <% >5#% = =

172 1 4 1/24

.3 . .

router1

172 1 1/24

Figunre her sningerfaces e r ub esh ing Ex ended ings fr


10: U
"Tool " To H lp T o l oot

% $#+%!, (%- 0 /1 2% 2/ 4

&' ) %) ./ ) / 2/ 2/.33%4 $ ) %

router

3 .3 . .3

O area 1

SPF

.3 .3.

O 172 1 4/24 area 0

SPF .3 .3.

router4

172 1 4 /24

172 1 20 1/24

.3 . 3.

P om A ot I t 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: sing "Tools" To elp Troubleshooting router has no problem pinging router4's serial interface (172. 1. .4). By default router uses a source address of 172. 1.4. , since that is the interface it uses to route to the 172. 1. .0/24 network. Extended pings can force router to use a different source address when pinging router4, such as 172. 1.20 .1. ere is the output from both pings:

#$%&1#D0"!'(

@UNHD@HDHQ

U3 3 3H 3 3 3 3 333 H
&$
2F$#&H
5+,$4

BK

"1

14+2"1

41S%1'+1

)1'=!'(

8T

@66;F

&1

dI_[

&$

@UNHD@HDHQT

&!<1$%&

!4

41+$'=4J

LLLLL

)%++144

#2&1

!4

@66

"1#+1'&

-878/T

#$%'=;&#!"

<!'72>(7<2W

7@D7N

<4

#$%&1#D0

#$%&1#D0"!'(

[#$&$+$?

Copyright 200 , Rob Webber

f!"gJ

1 5

Rob Webber's CCIE Notes from Experience


B A m B
2#(1&
d[

Version 8.0

2==#144J

@UNHD@HDHQ

1"12&

+$%'&

f8gJ

2&2(#2<

4!e1

f@66gJ

!<1$%&

!'

41+$'=4

fNgJ

5W&1'=1=

+$<<2'=4

f'gJ

)$%#+1

2==#144

$#

!'&1#.2+1J

+,97I+796I7+

BK m C

"1

$.

41#>!+1

f6gJ

)1&

F!&

!'

d[

,12=1#p

f'$gJ

P2?!=2&1

#1"?

=2&2p

f'$gJ

2&2

"2&&1#'

f6WXGI

$$41T

)&#!+&T

gJ

1+$#=T

!<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;F

33 3 3 3 3ings3wi h igh Re ea un Ex ended 3 3 3 3L 3 3 3 H 33 3 3 9 9 3


41+$'=4J
HHHHH

&1

dI_[

5+,$4

&$

@UNHD@HDHQT

&!<1$%&

!4

)%++144

#2&1

!4

"1#+1'&

-678/

#$%&1#D0

This tells us that (most likely) router4 does not have a route to get back to the 172. 1.20 .0/24 network. Analyzing router shows that the 172. 1.20 .0 network was not included in any of the network statements in the configuration. Adding allows both the ping and the extended ping to complete successfully, since now router4 can route the return pings back to the 172. 1.20 .0/24 network.
#$%&1# $4".
@ '1&*$#R @UNHD@HN6DH6 6H6H6HN88

2#12

P t H p t Co t 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. et's take a case where router still cannot ping 172. 1. .4 using 172. 1.20 .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 router to ping 172. 1. .4 from source interface 172. 1.20 .1. owever this time use "500" as the repeat count to keep the pings coming from router 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 configured on serial0 (connecting to router4), so the packets were never making it to router4. If access-list 10 had a 'log' at the end of its deny statement, you would see a message like this on router1:
!"

2++144;(#$%"

@6:

$%&

#$%&1#@0

Copyright 200 , Rob Webber

1 6

Rob Webber's CCIE Notes from Experience


8=@:,J k)5I;E;d[XII5))

33 L 9 9 L 3 3 9 3r arge Re ea un s Ex ended ingswi h arge i e acke s


C
cM

Version 8.0
;s

[J

?!4&

@6:

=1'!1=

!+<"

@UNHD@HN6DH@

@UNHD@HDHQ

-676/T

"2+R1&

#$%&1#@0

This indicates that AC 10 was blocking traffic from 172. 1.20 .1 to 172. 1. .4 (just as it was supposed to). et's assume you didn't have the 'log' statement on access-list 10 . One alternative is to issue the command on router1. In this case router1 produces the output:
=1F%( !" "2+R1& =1&2!? 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 10 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 router 's pings (assuming you are connecting via a terminal server), use the command ctrl-shift-6 ctrl-shift-6.

P t L Sz P t o L p t Co t 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 slow WAN 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 6 as the minimum and 1500 as the maximum. This creates several thousand pings in a range of sizes:
#$%&1#@0"!'(
[#$&$+$?

Copyright 200 , Rob Webber

f!"gJ

1 7

Rob Webber's CCIE Notes from Experience


B A m B
2#(1&
d[

Version 8.0

2==#144J

@UNHD@HDHQ

1"12&

+$%'&

f8gJ

2&2(#2<

4!e1

f@66gJ

!<1$%&

!'

41+$'=4

fNgJ

;L$&'0&0

(MNN)'0%

='>*

)$%#+1

2==#144

$#

!'&1#.2+1J

BK m C
F

"1

$.

41#>!+1

f6gJ

)1&

F!&

!'

d[

,12=1#p

f'$gJ

P2?!=2&1

#1"?

=2&2p

f'$gJ

2&2

"2&&1#'

f6WXGI

$$41T

)&#!+&T

O O

gJ

1+$#=T

!<14&2<"T

P1#F$41f'$'1gJ

&&"

.)'2&

M5

%1P&%

='>*

)*11"

<!'

4!e1

fDEgJ

&&"

N)L

%1P&

=+@698>*

66

33 3 Debug her s
)*11"
!'&1#>2? f@gJ

BK
!4

"1

14+2"1

41S%1'+1

&$

2F$#&H

)1'=!'(

UDN8T

fDEHH@866g;F

&1

dI_[

5+,$4

&$

@UNHD@HDHQT

&!<1$%&

41+$'=4J

LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

-1&+HL/

This command issues 7, 25 pings: one ping for every size packet from 6 bytes to 1500 bytes (a total of 1,465 pings), repeated 5 times. If you don't want to send 7, 25 pings use a A of 1 - this will just send one ping packet of each size from 6 to 1500 bytes, a total of 1,465 pings.
1"12& +$%'&

Ot

un e s
l

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

Tool 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).
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! se 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. et's say they are using RIP to be able to route

Copyright 200 , Rob Webber

U L 9

1 8

Rob Webber's CCIE Notes from Experience

Version 8.0

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.

CCP

The Web 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 configure WCCP in the lab, but since its included on the 4.0 ab Topic Blueprint I will include a brief overview here. WCCP is enabled and defined globally with the command and enabled on an interface with the 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 AC s that control which packets match the service, which packets that are redirected, and which web caches are allowed to participate in the redirection.
!"

App

L enedeix e aerao eer o oaecr o a o a e a e M


*++" *1F;+2+,1
!"

*++"

*1F;+2+,1

#1=!#1+&

!'

$#

$%&

H r is th m cr I us d t c ll ct c nfigs nd r uting t bl s. I h v 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 acro, then select the text file where you saved this (or your own) macro script.
&!<1$%&
h @N6

A: T

T mM

d.

<!'%&14

($14

2'=

1#2

1#<

!4

4&!??

*2!&!'(

.$#

#14"$'41T

4&$"

*2!&!'(

"#$F?1<

=!#1+&$#

,!4

41&4

Copyright 200 , Rob Webber

2'=

($

2,12=

2'=

+$'&!'%1

*!&,

&,1

<2+#$

-4$<1

,24

$++%##1=/H

wIJx_

K A

$%&1#

+$'.!(4xw

&,1

=1.2%?&

=!#1+&$#

.$#

4&$#!'(

&,1

+$??1+&1=

?$(4H

39

Rob Webber's CCIE Notes from Experience


L

Version 8.0
$%
*!??

)1&

&,!4

&$

*,2&1>1#

=!#1+&$#

K K
2

%41

.$#

4&$#!'(

+$'.!(4H

Y$&1J

2?4$

41&

&,!4

.1*

?!'14

=$*'

24

*1??

-*,1#1

K B m

$%

411

u=!#1+&$#

Kv

!'"%&F$W

wY2<1

$.

?$(

.!?1

.$#

&,!4

&14&Jw

w+,1+R

$%&

***HI2??!4<2H+$<w

,!4

"#$<"&4

&,1

%41#

&$

1'&1#

&,1

.!?1'2<1

$.

&,!4

?$(H

!#1+&$#

K K

!4

'$&

'11=1=

4!'+1

&,1

=1.2%?&

=!#1+&$#

2F$>1/

*!??

F1

2==1=H

%4%2??

%41

uH=$+

'2<1

-&,2&

"?2+1

!'

&,!4

F$W/

4$

&,1

-?!4&1=

1W&1'4!$'4

$'

&,1

*!??

2%&$<2&!+2??

F1

$"1'1=

`$#=H

4&#+$'+2&

=!#1+&$#

B B B

!'"%&4&#

,!4

2==4

&,1

=!#1+&$#

$'&$

&,1

.!?1'2<1

!'"%&&1=

&,1

%41#

-&,%4

<2R!'(

+$<"?1&1

.!?1'2<1/H

?$(.!?1'2<1

=!#1+&$#

K
u?$(.!?1'2<1

,!4

41&4

&,1

>2#!2F?1

.!?1

-!'+?%=14

=!#1+&$#

=!#1+&$#

wIJx_

K A

&$

F1

&,1

'2<1

$.

&,1

?$(

2'=

'2<1/H

$%&1#

+$'.!(4xw

,!4

41&4

&,1

=1.2%?&

=!#1+&$#

4!'+1

&,1

>2#!2F?1

u=!#1+&$#

Kv

F2+R

&$

*,2&

$%

*2'&

!&

&$

F1

t%4&

($&

&,1

2+&%2?

.!?1'2<1

+#2<<1=

$'

&,1

1'=

$.

!&

.1*

?!'14

F2+RH

j$%

'11=

&$

41&

&,1

=1.2%?&

=!#1+&$#

,1#1

2'=

!'

&,1

41+$'=

?!'1

$.

&,1

<2+#$

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

4&#+$'+2&

=!#1+&$#

1W!4&4T

$%

!=!$&Lw

!'"%&4&#

?$(.!?1'2<1

=!#1+&$#

=!#1+&$#

wIJx_

K A

K
+$'.!(4xw

$%&1#

($&$

412#+,Z?$(.!?1

,1

2F$>1

?!'14

412#+,

&$

=1&1#<!'1

!.

&,1

.!?1'2<1

2?#12=

K
$.

1W!4&4H

d.

!&

=$14T

!&

"#$<"&4

$%

1'&1#1=

$%

.$#

'1*

'2<1H

_2+#$

+2'

2""1'=

$'&$

2'

1W!4&!'(

.!?1T

F%&

&,2&

!4

uF1

4+$"1

&,!4

<2+#$H

v
@

,1

$'=

&,1

J$"1'?$(

?$($"1'

?$(.!?1'2<1

,!4

$"1'4

&,1

2+&%2?

?$(.!?1H

=$'y&

#1<1<F1#

*,2&

&,1

u@

=$14qdy<

4%#1

!&y4

!'

&,1

=$+%<1'&2&!$'q

41'=?'

w4,$*

+?$+Rw

*2!&

w0w

X4R4

&,1

#$%&1#

*,2&

&!<1

2'=

=2&1

!&

&,!'R4

!&

!4q

-.$#

#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

,!4

41'=4

&,1

+$<<2'=4

4,$*'

2F$>1

&$

&,1

&1#<!'2?

41#>1#

#$%&1#

&,1

<2+#$/H

.$#

$%

4!'+1

!&

Copyright 200 , Rob Webber

-4!'+1

&,2&

!4

*,1#1

$%

2#1

+$''1+&1=

*,1'

$%

F1(!'

1#<

?1'

!4

!<"$#&2'&

4$

&,1

#$%&1#

=$14

'$&

*2!&

&$

,!&

&,1

4"2+1F2#H

[2%41

@E

-@E

41+$'=4/

!4

,2'=

&2R14

41>1#2?

41+$'=4

.$#

&,1

N866y4

&$

(1&

&,1

+$'.!(

140

Rob Webber's CCIE Notes from Experience


L

Version 8.0
&,!4 $#
=1+#1241

#12=

$.

j$%

<2

K B

*2'&

&$

!'+#1241

&,!4

.$#

12+,

$%#

#$%&1#4

=1"1'=!'(

$'

*,1&,1#

&,1

K
0

2#1

.24&1#

$#

4?$*1#

-!4

&,1#1

4%+,

&,!'(

24

4?$*1#

&,2'

N866p

Jb/

d'

12+,

+241

1#2

B
0

1#<

!4

*2!&!'(

.$#

+,2#2+&1#

&$

2""12#

-!H1HT

&,1

.$??$*!'(

&,1

#$%&1#y4

"#$<"&

F1

!'

1W1+

<$=1q/^1#1

!4

*,1#1

2#1

$.

!'&1#14&

&$

$%

'11=

&$

$%

+2'

2==

*,2&1>1#

+$<<2'=4

$%H

41'=

w@w

41'=?'

0@D

*2!&

w0w

,!4

41'=4

&,1

+$<<2'=

u@

v K

&$

&,1

&1#<!'2?

41#>1#T

*,!+,

!'4&#%+&4

!&

&$

+$''1+&

&$

4144!$'

@H

!<"$#&2'&

&$

,2>1

&,1

#$%&1#4

2?#12=

-$#

,$*1>1#

<2'

K K

,!4

!4

*,

K
!'

!&y4

+$''1+&1=

4144!$'4

@;E

#$%&1#4

$%

,2>1/

#2&,1#

&,2'

4144!$'

@TDTQTE

-*,!+,

+2'

,2""1'

!.

41'=4

$%

=!4+$''1+&

4144!$'4T

1&+H/

d&

&,1'

1&%#'s

&$

&,1

#$%&1#

-*,!+,

!4

&,1

u41'=?'

0@D

&$

(1&

!&

&$

=!4"?2

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

X??

+$<<2'=4

2#1

'$*

!44%1=

&$

#$%&1#@

-$#

*,2&1>1#

#$%&1#

!4

4144!$'

$'

&,1

&1#<!'2?

41#>1#/H

X.&1#

*1

,2>1

!44%1=

&,1

+$<<2'=4T

41&

&,1

?1'(&,

$.

&,1

4+#11'

&$

QN

-4$<1

"1$"?1

"#1.1#

NQ/H

41'=?'

0D60zU

*2!&

w0w

41'=

wNw

41'=?'

0@D

*2!&

w0w

,1

0D60zU

41'=4

uI$'&#$?;),!.&;E

4$

&,2&

K
&$

$%

+2'

t%<"

F2+R

&$

&,1

&1#<!'2?

41#>1#H

d&

&,1'

41'=4

+$''1+&

&$

4144!$'

-*,!+,

!4

&,1

'1W&

#$%&1#

2'=

&,1

"#$+144

4&2#&4

2??

$>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'=?'

0D60zU

*2!&

w0w

41'=

wDw

41'=?'

0@D

Copyright 200 , Rob Webber

141

Rob Webber's CCIE Notes from Experience


*2!&
w0w

Version 8.0
41+&!$' F241=

)!<"?

+%&

2'=

"24&1

&,1

2""#$"#!2&1

$'

&,1

'%<F1#

$.

#$%&1#4

-2'=

&,%4

&1#<!'2?

41#>1#

4144!$'4/

$%

,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

^1#1

2#1

&,1

+$<<2'=4

.$#

#$%&1#Q

-&1#<!'2?

4144!$'

Q/J

41'=?'

0D60zU

*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

^1#1

2#1

&,1

+$<<2'=4

.$#

#$%&1#8

-&1#<!'2?

4144!$'

8/J

41'=?'

0D60zU

*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

Y$*

($

F2+R

&$

&,1

&1#<!'2?

41#>1#

#$%&1#

.$#

&,1

.!'2?

&!<1J

41'=?'

0D60zU

*2!&

w0w

?$(+?$41

Copyright 200 , Rob Webber

142

Rob Webber's CCIE Notes from Experience


" " " " " "

Version 8.0
".

!"#

$%

&'

()*#+,$&'+-&

)./

)00

*+((

.&%1

2+&

&')& 3

-%"0

).

)4 )% $

+5

6$7

#"8#"%

&$.9

6%'+,

$8

#+-&

%7

+. )44

(/

#+-&"#%:

&!<1$%&

@N6

=!#1+&$#

wIJx_

K A K

$%&1#

+$'.!(4xw

!'"%&F$W

wY2<1

$.

?$(

.!?1

.$#

&,!4

&14&Jw

wI2??!4<2

%?14w

4&#+$'+2&

=!#1+&$#

!'"%&4&#

?$(.!?1'2<1

=!#1+&$#

=!#1+&$#

wIJx_

K A

K
+$'.!(4xw

$%&1#

J412#+,Z?$(.!?1

.!?1412#+,

?$(.!?1'2<1

!.

#14%?&h6

($&$

$"1'?$(

!'"%&F$W

w5'&1#

'1*

.!?1'2<1Jw

w3!?1

2?#12=

4&#+$'+2&

=!#1+&$#

1W!4&4Lw

!'"%&4&#

?$(.!?1'2<1

=!#1+&$#

=!#1+&$#

wIJx_

K A

K
+$'.!(4xw

$%&1#

($&$

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'=?'

0D60zU

*2!&

w0w

41'=

wNw

41'=?'

0@D

*2!&

w0w

41'=?'

w&1#<

Copyright 200 , Rob Webber

?1'(&,

6w

14

Rob Webber's CCIE Notes from Experience


*2!&
w0w

Version 8.0

41'=?'

w4,$*

#%''!'(;+$'.!(w

"2%41

@E

41'=?'

w!w

*2!&

w0w

41'=?'

w&1#<

?1'(&,

QNw

*2!&

w0w

"2%41

41'=?'

0D60zU

*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'=?'

0D60zU

*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'=?'

0D60zU

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

*2!&

w0w

"2%41

Copyright 200 , Rob Webber

?1'(&,

QNw

144

Rob Webber's CCIE Notes from Experience


41'=?'
0D60zU

Version 8.0

*2!&

w0w

?$(+?$41

Copyright 200 , Rob Webber

145

Rob Webber's CCIE Notes from Experience

Sinaes nti guratwii ntcshesr isc R utersand


CCIE tudy sheet
l Co f
S

Version 8.0

o fo C o o

Cop

breb t Wy eb er R yright R bert Web er


o CCIE 6922
2009, o
146

Copyright 200 , Rob Webber

Rob Webber's CCIE Notes from Experience

CCIE S

The CCIE test is demanding. owever 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!

tudy he t - F rewH rd
S

Version 8.0

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. o 't t p o t t m!
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. ake up your mind that you are going to study hard, prepare well, execute beautifully and pass the test! R.W. February 21, 2001 CCIE 6 22

D n ge syched u by he exa

M E hercLhan e L3
3560
t
'$ !"

l ayer 2 Etherchannels (recommended):


#2'(1
.24&1&,1#'1&67@
;N <$=1

!'&1#.2+1

4*!&+,"$#&

2++144

4*!&+,"$#&

2++144

>?2'

+,2''1?;(#$%"

<$=1

$'

ayer Etherchannels:
4*!&+,"$#& 2==#144

!'&1#.2+1

Copyright 200 , Rob Webber

"$#&;+,2''1?

@:NH@E

H@H@

N88HN88HN88H6

147

Rob Webber's CCIE Notes from Experience


!'&1#.2+1

Version 8.0
O

#2'(1

.24&1&,1#'1&67U;

Fa ack ridging
'$ !" '$

2==#144

4*!&+,"$#&

+,2''1?;(#$%"

<$=1

$'

show etherchannel

llB

F#!=(1

"#$&$+$?

>?2';F#!=(1

F#!=(1

"#!$#!&

@ED

!'&1#.2+1

XY

@6

!"

2==#144

@6H

EH@H@

N88HN88HN88H6

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

!'&1#.2+1

XY

N6

!"

2==#144

@6H

EHNH@

N88HN88HN88H6

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

!'&1#.2+1

324&5&,1#'1&67U

'$

4*!&+,"$#&

Po t

rs

!"

2==#144

@6H

EHDH@

N88HN88HN88H6

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

show bridge 1 group

Access Ports:
!'&

.267@U

4*!&+,"$#&

<$=1

2++144

4*!&+,"$#&

2++144

>?2'

N66

!'&1#.2+1

#2'(1

324&5&,1#'1&

67@;Q

4*!&+,"$#&

<$=1

2++144

4*!&+,"$#&

2++144

>?2'

86

Trunk Ports:
!'&

.267@D

4*!&+,"$#&

&#%'R

1'+2"4%?2&!$'

=$&@S

4*!&+,"$#&

<$=1

&#%'R

Sp

Copyright 200 , Rob Webber

an ing re
'$ !"

Routed Ports:
!'&1#.2+1

324&5&,1#'1&67@

4*!&+,"$#&

2==#144

@:NH@E

HUEHN86

N88HN88HN88H6

148

Rob Webber's CCIE Notes from Experience

Version 8.0

PVST
4"2''!'(;&#11
<$=1 ">4&

&,!4

!4

&,1

=1.2%?&

X??

&,1

.$??$*!'(

+$<<2'=4

2""?

K K

&$

F$&,

[P)

2'=

2"!=

[P)

"#$%%&%'()!**+,-$%+.+!
4"2''!'(;&#11 >?2'
N

)+#!&/$!0+1+ %+)2*+
L

#$$&

4*!&+,

#$$&

41+$'=2#

$'

&,1

F2+R;%"

#$$&

4*!&+,

!'&1#.2+1

.24&1&,1#'1&

67NQ

4"2''!'(;&#11

+$4&

@66

4"2''!'(;&#11

"$#&;"#!$#!&

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

M
L L L L

4"2''!'(;&#11

%"?!'R.24&

%41.%?

.$#

1=(1

-2++144/

4*!&+,14

4"2''!'(;&#11

F2+RF$'1.24&

%41.%?

$'

+$#1

4*!&+,14

!'&1#.2+1

.24&1&,1#'1&

67NN

4"2''!'(;&#11

"$#&.24&

%41=

$'

"$#&4

+$''1+&!'(

&$

1'=

4&2&!$'4

STP
<$=1 <4& <4&

4"2''!'(;&#11

4"2''!'(;&#11

+$'.!(%#2&!$'

!'4&2'+1

>?2'

N;@6

'2<1

#1(!$'@

#1>!4!$'

4"2''!'(;&#11

<4&

#$$&

"#!<2#

!4

&,1

!'4&2'+1

!=

4"2''!'(;&#11

<4&

#$$&

41+$'=2#

!4

&,1

!'4&2'+1

!=

!'&1#.2+1

.24&1&,1#'1&

67NQ

4"2''!'(;&#11

<4&

+$4&

@66

!4

&,1

!'4&2'+1

!=

4"2''!'(;&#11

<4&

"$#&;"#!$#!&

@E

show spanning-tree mst 1 show spanning-tree mst interface interface-id

VTP

>&"

<$=1

>&"

=$<2!'

>&"

"244*$#=

>&"

>1#4!$'

Copyright 200 , Rob Webber

41#>1#

?2F

+!4+$

14

Rob Webber's CCIE Notes from Experience

Version 8.0

St

Ex ended c es is s
!'&1#.2+1 !"

candeasrd cisetss is s
>&"
<$=1

+?!1'&

>&"

=$<2!'

?2F

>&"

"244*$#=

+!4+$

>&"

>1#4!$'

show vtp status

2++144;?!4&

L t
@ @

"1#<!&

@6HNH86H6

6H6H6HN88

2++144;?!4&

"1#<!&

@6H@6H6H6

6H6HN88HN88

41#!2?

67@

2++144;(#$%"

!'

?!'1

>&

6;Q

2++144;+?244

2++144;?!4&

L t

!'

@66

"1#<!&

!"

@UNH@

H6H6

6H6HN88HN88

@:NH@E

H@H6

6H6H6HN88

2++144;?!4&

@6@

"1#<!&

&+"

@88H@

NH@6H6

6H6H6HN88

@:NHNDDH@Q8H6

6H6H6HN88

1S

ND

Na ed c es is s Ref exi e c es is s
6H6HN88HN88

2++144;?!4&

@6@

"1#<!&

%="

@6H6H6H6

6HN88HN88HN88

(&

@6ND

@:NH@E

H6H6

2++144;?!4&

@6@

"1#<!&

!+<"

2'

2'

1+,$;#1"?

#$%&1#

1!(#"

N66

=!4&#!F%&1;?!4&

@6@

$%&

m A
!"

2++144;?!4&

L t

-4&2'=2#=\1W&1'=1=/

'2<1$.?!4&

"1#<!&

!"

N6

H@QHD8H6

6H6H6HN88

2'

)11

Al

B P

iGases

"1#<!&

&+"

@88H@

K
1S

NH6H6

6H6HN88HN88

2'

show access-list l v A v L t
u3!#1*2??4

2?!24

1W1+

4,$*

!"

#$%&1

#$%&1#

F("

E8666

'$

'+,#$'!e2&!$'

'1!(,F$#

@6HNH@H@

#1<$&1;24

E866@

'1!(,F$#

@6HNH@H@

=!4&#!F%&1;?!4&

!'

'1!(,F$#

'1&*$#R

'1&*$#R

'$

2%&$;4%<<2#

Copyright 200 , Rob Webber

@6H@6H@86HN

#1<$&1;24

E8666

@6H@6H@6H6

<24R

N88HN88HN88H6

@86H@86H6H6

150

Rob Webber's CCIE Notes from Experience


2++144;?!4&

Version 8.0

"1#<!&

@:NH@E

H@UH6

2++144;?!4&

"1#<!&

@UNH@EH6H6

Fi eringwi h R u e a s
lt
#$%&1#
F("
E8@@@ '1!(,F$# '1!(,F$#

show ip bgp show ip bgp neighbor show ip bgp summary debug ip bgp updates t o t -M p
@6H@6H@6H@6

#1<$&1;24

E8NNN

@6H@6H@6H@6

#$%&1;<2"

c%&&$

$%&

!"

"#1.!W;?!4&

c%&&$

41S

"1#<!&

@UNH@UH6H67@E

?1

DN

#$%&1;<2"

c%&&$

"1#<!&

@6

<2&+,

!"

2==#144

"#1.!W;?!4&

c%&&$

Fi erinFgbey U
lt
'$

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.

AS_PATH ilt ring by AS_PATH is im rt nt b c us y u c n filt r ll r ut s 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_PAT : 1. se the command 2. se a route-map In either case you will define the AS_PAT you are looking for with the command. ere 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$#

.!?&1#;?!4&

24;"2&,

2++144;?!4&

po a e a e o a e a o e H H H
866

!"

#$%&1#

F("

E866@

'+,#$'!e2&!$'

'1!(,F$#

@UNH@EHQ6H8

#1<$&1;24

E G e rs be ween backad res es 9


L
!"

'1!(,F$#

@UNH@EHQ6H8

#$%&1;<2"

X)866.!?&1#

$%&

24;"2&,

2++144;?!4&

@86

"1#<!&

ZN66z

#$%&1;<2"

X)866.!?&1#

"1#<!&

@6

<2&+,

24;"2&,

@86

B PP t loop 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

#@

Copyright 200 , Rob Webber

151

Rob Webber's CCIE Notes from Experience


L
!'&1#.2+1

Version 8.0

$$"F2+R6

!"

2==#144

N6EHD6H6HU

N88HN88HN88HN88

#$%&1#

F("

QN:D

'$

'+,#$'!e2&!$'

'1!(,F$#

N6

'1!(,F$#

N6

'1!(,F$#

N6

O O O

H@UNH86HQ

#1<$&1;24

D8E@

H@UNH86HQ

1F(";<%?&!,$"

N88

H@UNH86HQ

%"=2&1;4$%#+1

$$"F2+R6

!"

#$%&1

N6

!"

#$%&1

N6

O O

H@UNH86HQ

N88HN88HN88HN88

)1#!2?676

H@UNH86HQ

N88HN88HN88HN88

)1#!2?67@

,$4&'2<1

#N

!'&1#.2+1

$$"F2+R6

!"

2==#144

N6

H@UNH86HQ

N88HN88HN88HN88

#$%&1#

F("

D8E@

'$

'+,#$'!e2&!$'

'1!(,F$#

'1!(,F$#

'1!(,F$#

!"

#$%&1

!"

#$%&1

AS_PATH P p
#$%&1#
'$

'1&*$#R

re ending aking he nger


N6EHD6H6HU

N6EHD6H6HU

N6EHD6H6HU

O O O

#1<$&1;24

QN:D

1F(";<%?&!,$"

N88

%"=2&1;4$%#+1

$$"F2+R6

N6EHD6H6HU

N6EHD6H6HU

O O

N88HN88HN88HN88

)1#!2?6

N88HN88HN88HN88

)1#!2?@

(M
O O

F("

E8DDD

t AS_PATH Lo
N88HN88HN88H6 N88HN88HN88H6

'+,#$'!e2&!$'

@UNH@UHNH6

<24R

'1&*$#R

@UNH@EH@H6

<24R

'1!(,F$#

@:NH@E

HQH@

#1<$&1;24

E8NNN

'1!(,F$#

@:NH@E

HQH@

#$%&1;<2"

<2R1;24;"2&,;?$'(1#

$%&

2++144;?!4&

"1#<!&

@UNH@EH6H6

2++144;?!4&

"1#<!&

2'

K
"1#<!& @6

R u e a e9 ca reference n nc ing da es L 9
<2&+, !"

#$%&1;<2"

<2R1;24;"2&,;?$'(1#

2==#144

41&

24;"2&,

"#1"1'=

E8DDD

E8DDD

#$%&1;<2"

<2R1;24;"2&,;?$'(1#

"1#<!&

N6

<2&+,

!"

2==#144

o t M p to S t Lo l P o I om Up t This example uses a route map to set local preference on all updates from neighbor 1 2.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 ocal Pref is set higher):
#$%&1#
F("
E866@ '$

'+,#$'!e2&!$'

'1!(,F$#

@:NH@E

H@@HN

#1<$&1;24

E8666

Copyright 200 , Rob Webber

152

Rob Webber's CCIE Notes from Experience

Version 8.0
41&

R u e 9a e ED n Mu g ing u d3aes M M
'1!(,F$# @:NH@E '$

2%&$;4%<<2#

H@@HN

#$%&1;<2"

$+2?[#1.

!'

#$%&1;<2"

41&

$+2?[#1.

"1#<!&

@6

41&

?$+2?;"#1.1#1'+1

U66

o t M p to S t M o o t o p t This example sets the ED (similar to a metric) to 200 on outgoing updates for the 172.17.0.0 and 172. 0.0.0 networks sent to BGP neighbor 1 2.168.2.1. All other updates use the default ED (0). EDs can influence how traffic is sent into your Autonomous System:
#$%&1#
F("
E8DDD '1!(,F$# @:NH@E '1!(,F$# @:NH@E

O O m

HNH@

#1<$&1;24

E8NNN

HNH@

#$%&1;<2"

41&;_5

$%&

#$%&1;<2"

41&;_5

"1#<!&

@6

<2&+,

!"

2==#144

41&

<1&#!+

N66

R u e Ref ec r us er
<2&+, !"

#$%&1;<2"

41&;_5

"1#<!&

N6

2==#144

2++144;?!4&

"1#<!&

@UNH@UH6H6

2++144;?!4&

"1#<!&

@UNHD6H6H6

2++144;?!4&

"1#<!&

2'

o t

l to Cl t Server (64.71.100.1):
#$%&1#
F("
E866@ '$

'+,#$'!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'&

g regHa e d res
#$%&1#
F("
'$

A Client (64.71.100.4):
E866@

'+,#$'!e2&!$'

'1!(,F$#

EQHU@H@66H@

#1<$&1;24

E866@

t A ere all four BGP networks are summarized into one aggregate and all other advertisements (the actual /24 networks) are suppressed:
!'&1#.2+1

C C C

$$"F2+R:6

!"

2==#144

@UNHNQH@H@

N88HN88HN88H6

!'&1#.2+1

$$"F2+R:@

!"

2==#144

@UNHNQHNH@

N88HN88HN88H6

!'&1#.2+1

!"

2==#144

Copyright 200 , Rob Webber

$$"F2+R:N

@UNHNQHN8QH@

N88HN88HN88H6

15

Rob Webber's CCIE Notes from Experience


!'&1#.2+1

Version 8.0

$$"F2+R:D

!"

2==#144

@UNHN8HDH@

N88HN88HN88H6

#$%&1#

F("

E866N

'$

'+,#$'!e2&!$'

F("

?$(;'1!(,F$#;+,2'(14

'1&*$#R

@UNHNQH@H6

<24R

N88HN88HN88H6

'1&*$#R

@UNHNQHNH6

<24R

N88HN88HN88H6

H
A t

'1&*$#R

@UNHNQHN8QH6

<24R

N88HN88HN88H6

'1&*$#R

@UNHN8HDH6

2((#1(2&1;2==#144

@UNHNQH6H6

'1!(,F$#

@UNHD@HNHD

'$

2%&$;4%<<2#

ere three aggregate advertisements are generated. All other advertisements in the 1 2.168.1.0/24 and 1 2.168.2.0/24 ranges are suppressed. An aggregate of 10.8.0.0/1 will be advertised. Any other advertisements in this range will be advertised normally.
#$%&1#
F("
E8NNN '$

9 39
<24R N88HN88HN88H6

N88HN8QH6H6

4%<<2#

;$'?

#1<$&1;24

E866D

'+,#$'!e2&!$'

'1&*$#R

@:NH@E

'1&*$#R

@:NH@E

'1&*$#R

@:NH@E

'1&*$#R

@6H

u hen icaMi n- D
'1&*$#R '1&*$#R '$

O O O

H@HEQH6

<24R

N88HN88HN88H@:N

H@H@N

H6

<24R

N88HN88HN88HNNQ

HNH@:NH6

<24R

N88HN88HN88HNQ6

HDNH6

<24R

N88HN88HN88H6

@6H:H6H6

<24R

N88HN88H6H6

@6H@6H@E6H6

<24R

N88HN88HN8QH6

2((#1(2&1;2==#144

@6H

H6H6

N88HNQ

2((#1(2&1;2==#144

@:NH@E

2((#1(2&1;2==#144

@:NH@E

2%&$;4%<<2#

O O

H6H6

H@H6

N88HN88HN88H6

4%<<2#

HNH6

N88HN88HN88H6

4%<<2#

K K

;$'?

;$'?

K K

t to M 5 BGP D5 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*$#=

rG ibdaging R uters
#$%&1#
F("
E866D '1!(,F$#

&,!4!4<

"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:
"11#(#$%"@ "244*$#= [244*4$#=3$#

,1[11#M#$%"

( o
@ @

)
!111 @66

lo l

F#!=(1

F#!=(1

Copyright 200 , Rob Webber

"#$&$+$?

"#!$#!&

154

Rob Webber's CCIE Notes from Experience

I t

DH
HCP
L

n erface
L L
!"

Version 8.0

!'&1#.2+1

16

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

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

"2&,;+$4&

86

!'&1#.2+1

41#!2?

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

show bridge

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 D CP server. For example my laptop is configured for D CP (for work, etc.), yet when I take my laptop home I do not have a D CP server to assign me an address. To configure your router as a D CP server, use the following:
X==#14414
H@ ; H@6

2#1

%4%2??

*1

*!??

1W+?%=1

&,1<

.#$<

%41=

.$#

'1&*$#R

=1>!+14T

4$

^I[J

=,+"

1W+?%=1=;2==#144

@UNH@EHEQH@

@UNH@EHEQH@6

,1

?1241

+$<<2'=

%414

=2

R1

*$#=4H

,$%#4

<!'%&14

24

&,1

&,#11

,!4

+#12&14

@6

<!'%&1

?12414

-6

=2

@6

<!'%&14/H

j$%y??

"#$F2F?

4T

,$%#4T

*2'&

&$

<2R1

&,1

?1241

&!<1

<%+,

?$'(1#J

!"

=,+"

"$$?

<

"$$?

'1&*$#R

@UNH@EHEQH6

N88HN88HN88H6

=1.2%?&;#$%&1#

@UNH@EHEQH@

=$<2!';'2<1

+2??!4<2H+$<

='4;41#>1#

@::HQ8HDNHDU

$"&!$'

@86

!"

@6HDQHN@8H@

+2'

?1241

@6

If you need to assign your PC the exact same address every time, you can create a specific reservation within D CP based on your AC address. That configuration is:
L

244!('

4"1+!.!+

,1

w+?!1'&;!=1'&!.!1#w

!4

&,1

_XI

2==#144H

F1

2'

&,!'(

(2>1

!&

<

2==#144H

^1#1

*!??

2?*2

Y$&1

&,2&

<

K K

^I[

$"&!$'4

,1

"$$?

'2<1

+2'

'2<1

&$

#1<!'=

<1

!&4

<

_XI

#1+1!>1

2==#144

@6H8HNNH@6H

_XI

2==#144

!4

66;@6;2Q;F8;=@;=6T

,$*1>1#

&,1

+$'.!(%#2&!$'

#1S%!#14

u6@

_XI

'$&

4%#1

*,

!'

.#$'&

$.

&,1

!"

=,+"

"$$?

#$F*1FF1#

,$4&

@6H8HNNH@6

N88HN88HN88H6

+?!1'&;!=1'&!.!1#

6@66H@62QHF8=@H=6

=1.2%?&;#$%&1#

='4;41#>1#

=$<2!';'2<1

?1241

Copyright 200 , Rob Webber

@6H8HNNHN86

@88H@6

HD:HN66

4&2&1H+$<

155

Rob Webber's CCIE Notes from Experience

Note that only certain versions of IOS support the D CP 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 D CP relay (for use with an external D CP server), use the interface command:
!'&1#.2+1

!"

Implementing D CP in P S VPNs can be complicated, since different VPNs on the same router can share the same subnets. That is, an P S router can have two 10.10.10.0/24 subnets - but in different P S VPNs. To allow for this use the following commands. ere both interfaces can s rvic th s m IP ddr ss r ng nd us th s m HCP s rv r ( ), but are associated with different P S VPNs:
@6H@QH8EHU

EI

GR

!"

H H H ML H MLML e e e a e a e a ea e eM aL e D e e
M!2(F!&5&,1#'1&676
,1?"1#;2==#144
@6H@EH@HN =,+"

Version 8.0

#1?2

!'.$#<2&!$'

$"&!$'

>"'

!'&1#.2+1

324&5&,1#'1&676

!"

,1?"1#;2==#144

>#.

P[Y@

@6H@QH8EHU

!'&1#.2+1

324&5&,1#'1&67@

!"

,1?"1#;2==#144

>#.

P[YN

@6H@QH8EHU

P
41#!2?6
!"

!'&1#.2+1

4%<<2#

;2==#144

1!(#"

@UEH@QH6H6

N88HN88H6H6

'$

!"

4"?!&;,$#!e$'

1!(#"

#$%&1#

1!(#"

'$

2%&$;4%<<2#

'1&*$#R

NQH6H6H6

'1&*$#R

@UEH@QH6H6

'1&*$#R

N66H@H@88H6

=!4&#!F%&1;?!4&

@6U

!'

41#!2?6

A t

Copyright 200 , Rob Webber

u hen ica i n- D 9
t to
!" !'&1#.2+1

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)

M 5
32676
<$=1

2%&,1'&!+2&!$'

1!(#"

<=8

156

Rob Webber's CCIE Notes from Experience

Version 8.0
@ i1

Firneewxa assed c es n r
!"

2%&,1'&!+2&!$'

R1

;+,2!'

1!(#"

I,2!'Y2<1

R1

+,2!'

i1

R1

I,2!'Y2<1

R1

;4&#!'(

@ND@ND@ND

2++1"&;?!.1&!<1

@NJ6@J6@

{2'

N66:

!'.!'!&1

41'=;?!.1&!<1

@NJ6@J6@

{2'

N66:

!'.!'!&1

ll

Co t t B A Co t ol (CBAC) Applying CBAC inbound on the inside interface: K


!" !'4"1+& '2<1 <

.!#1*2??

.&"

!"

!'4"1+&

'2<1

<

.!#1*2??

&+"

!'&1#.2+1

5&,1#'1&

676

-!'4!=1

!'&1#.2+1/

!"

!'4"1+&

<

.!#1*2??

!'

!'&1#.2+1

41#!2?

676

!"

2++144;(#$%"

@66

2++144;?!4&

@66

=1'

Applying CBAC outbound on the outside interface. Inbound traffic is allowed to host 10.20. 0.250:
!" !'4"1+& '2<1

.!#1*2??;@

!"

!'4"1+&

2%=!&;&#2!?

3
K K

-$%&4!=1

!'&1#.2+1/

!'

!"

2'

2'

&+"

!'&1#.2+1

324&5&,1#'1&

67@

-!'4!=1

!'&1#.2+1/

!"

2==#144

@6HN6HD6H@

N88HN88HN88H6

!'&1#.2+1

41#!2?

N76

-$%&4!=1

!'&1#.2+1/

!"

!'4"1+&

.!#1*2??;@

$%&

!"

2++144;(#$%"

@86

!'

2++144;?!4&

@86

"1#<!&

&+"

2'

2++144;?!4&

@86

=1'

!"

2'

,$4&

@6HN6HD6HN86

1S

*1F

2'

Zo B

Copyright 200 , Rob Webber

ne ased Firewa 9
+?244;<2"
<2&+,

show ip inspect name firewall-name show ip inspect config show ip inspect interfaces debug ip inspect events debug ip inspect detail

ll
K
d'&1#'2?Z

<2&+,;2'

B B

#2..!+

2++144;(#$%"

'2<1

d'&1#'2?Z

+?244;<2"

<2&+,;2'

K m

_|Z

#2..!+

#2..!+

<2&+,

2++144;(#$%"

'2<1

_|Z

#2..!+

"$?!+

K}

<2"

&

"1

!'4"1+&

d'&1#'2?Z

#2..!+Z[$?!+

157

Rob Webber's CCIE Notes from Experience


+?244

Version 8.0

&

"1

!'4"1+&

d'&1#'2?Z

#2..!+

!'4"1+&

"$?!+

K}

<2"

&

+?244

&

"1

!'4"1+&

"1

!'4"1+&

_|Z

m B

_|Z

#2..!+Z[$?!+

#2..!+

!'4"1+&

e$'1

41+%#!&

e$'1

41+%#!&

e$'1

41+%#!&

K K m K K K

d'&1#'1&

_|

d'&1#'2?

e$'1

} }

"2!#

41+%#!&

41#>!+1

} }

"$?!+

&

e$'1

"2!#

41+%#!&

41#>!+1

"$?!+

&

K K K m K
"1 "1

d'&1#'1&;

_|

4$%#+1

d'&1#'1&

=14&!'2&!$'

_|

!'4"1+&

_|;d'&1#'2?

4$%#+1

_|

=14&!'2&!$'

d'&1#'2?

!'4"1+&

!'&1#.2+1

M!(2F!&5&,1#'1&

676

=14+#!"&!$'

d'&1#'1&

!'&1#.2+1

e$'1;<1<F1#

d'&1#'1&

!'&1#.2+1

M!(2F!&5&,1#'1&

67@

=14+#!"&!$'

e$'1;<1<F1#

m m

_|

!'&1#.2+1

_|

!'&1#.2+1

M!(2F!&5&,1#'1&

N76

=14+#!"&!$'

d'&1#'2?

!'&1#.2+1

e$'1;<1<F1#

d'&1#'2?

!"

2++144;?!4&

1W&1'=1=

"1#<!&

&+"

2'

Ref exi e c es is s
"1#<!&

"1#<!&

&+"

2'

&+"

2'

K K K

_|Z

#2..!+

,$4&

@6H@@H@NH@D

1S

***

,$4&

@6H@@H@NH@D

1S

QQD

,$4&

@6H@@H@NHQ6

1S

4<&"

!"

2++144;?!4&

1W&1'=1=

d'&1#'2?Z

"1#<!&

&+"

,$4&

@6H@@H@NH@D

2'

"1#<!&

&+"

,$4&

@6H@@H@NHQ6

2'

K K

#2..!+

l v A
!" !"

!'&1#.2+1

)1#!2?

L t

=14+#!"&!$'

X++144

&$

&,1

d'&1#'1&

>!2

&,!4

!'&1#.2+1

2++144;(#$%"

!'F$%'=.!?&1#4

!'

2++144;(#$%"

$%&F$%'=.!?&1#4

$%&

!"

#1.?1W!>1;?!4&

&!<1$%&

@N6

!"

2++144;?!4&

1W&1'=1=

$%&F$%'=.!?&1#4

"1#<!&

&+"

2'

K K
2'

2'

K K
2'

#1.?1+&

&+"&#2..!+

Lo

Copyright 200 , Rob Webber

ck and ey c es 9
!"

2++144;?!4&

1W&1'=1=

!'F$%'=.!?&1#4

"1#<!&

F("

2'

2'

"1#<!&

1!(#"

=1'

!+<"

2'

2'

1>2?%2&1

&+"&#2..!+

K A

!'&1#.2+1

41#!2?

158

Rob Webber's CCIE Notes from Experience


!"

Version 8.0

2==#144

@UNH@UH@H@

N88HN88HN88H6

!"

2++144;(#$%"

@6@

!'

2++144;?!4&

@6@

"1#<!&

&+"

2'

2++144;?!4&

@6@

,$4&

@UNH@UH@H@

1S

&1?'1&

'2<!+

=%''$

"1#<!&

!"

2'

2'

?!'1

>&

"244*$#=

<

"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*$#=

<

"244

!'&1#.2+1

41#!2?

!"

2==#144

@UNH@UH@H@

N88HN88HN88H6

FFrraa eReeRaey awiy ching


L

!"

2++144;(#$%"

@6@

!'

2++144;?!4&

@6@

"1#<!&

&+"

2'

2++144;?!4&

@6@

,$4&

@UNH@UH@H@

1S

&1?'1&

'2<!+

=%''$

"1#<!&

!"

2'

2'

?!'1

>&

"244*$#=

<

"244*$#=

?$(!'

?$+2?

.#2<1;#1?2

l S tK

4*!&+,!'(

!'&1#.2+1

46

Fra e Re ay
=?+!/

1'+2"4%?2&!$'

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

K K

!'&.;&

K
-''! !.

"1

=+1

+$''1+&!'(

&$

2'$&,1#

.#2<1

4*!&+,/

#$%&1

@66

!'&1#.2+1

4@

@86

-!';=?+!

$%&;!'&1#.2+1

$%&;

+?$+R

#2&1

8@N666

-!.

%4!'(

I5

+2F?1/

d'&1#.2+1

46

d"

2==#144

@UNHNQH@H@H

N88HN88HN88H6

1'+2"4%?2&!$'

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

K K

K
DD6
F#$2=+24&

<2"

!"

@UNHNQH@HN

<2"

!"

@UNHNQH@HD

DQ6

F#$2=+24&

Or&
!'&1#.2+1

46

'$

!"

2==#144

1'+2"4%?2&!$'

!'&1#.2+1

!"

2==#144

Copyright 200 , Rob Webber

.#2<1;#1?2

46H@

"$!'&;&$;"$!'&

@UNHNQH@H@

N88HN88HN88H6

15

Rob Webber's CCIE Notes from Experience


.#2<1;#1?2

Version 8.0

!'&1#.2+1;=?+!

DD6

!'&1#.2+1

46HN

"$!'&;&$;"$!'&

!"

2==#144

@UNHNQHNH@

N88HN88HN88H6

.#2<1;#1?2

!'&1#.2+1;=?+!

DQ6

Or&
!'&1#.2+1

46

'$

!"

2==#144

1'+2"4%?2&!$'

.#2<1;#1?2

!'&1#.2+1

46H@

<%?&!"$!'&

!"

2==#144

@:NH@E

.#2<1;#1?2

Fra e Re ay raf ic ha ing


.#2<1;#1?2
<2" !"

K K

H@H@

N88HN88HN88H6

<2"

!"

@:NH@E

@:NH@E

O O

H@HN

@6@

F#$2=+24&

H@HD

@6N

F#$2=+24&

debug frame packet show frame pvc show frame map

l T
46

!'&1#.2+1

S p

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

K K K

&#2..!+;4,2"!'(

+?244

1W2<"?1@

-r;

.$#

2??

mC

Idy4/

!'&1#.2+1;=?+!

@6@

+?244

1W2<"?1@

-r;

$'

"1#;

mC

Id

F24!4/

<2";+?244

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

K K K K K

"#!$#!&

K K

1W2<"?1@

;(#$%"

-r;

"#!$#!&

S%1%!'(T

$#

+%4&$<;S%1%1;?!4&

r;

+%4&$<

S%1%!'(/

+!#

@N

666

F+

N8E666

2=2"&!>1;4,2"!'(

F1+'

"#!$#!&

"#!$#!&

K K

;?!4&

"#$&$+$?

!"

,!(,

;?!4&

"#$&$+$?

!"

'$#<2?

?!4&

@86

HS P

S%1%1;?!4&

"#$&$+$?

!"

@@

S%1%1;?!4&

"#$&$+$?

!"

@N

?!4&

@86

S%1%1;?!4&

"#$&$+$?

!"

@6

&+"

&1?'1&

S%1%1;?!4&

=1.2%?&

@D

S%1%1;?!4&

S%1%1

@6

S%1%1;?!4&

S%1%1

S%1%1;?!4&

S%1%1

S%1%1;?!4&

S%1%1

This creates two SRP 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 5 (default has tracking drop priority by 10). The other

Copyright 200 , Rob Webber

H9

@@

@N

@D

K K K K

&1;+$%'&

D666

&1;+$%'&

N666

&1;+$%'&

@666

&1;+$%'&

@666

160

Rob Webber's CCIE Notes from Experience

Version 8.0

router will have (the default) priority of 100 and thus will become primary for that group as well. Group 1 also uses authentication. RouterK : A
4&2'=F 4&2'=F 4&2'=F 4&2'=F 4&2'=F
@ !" @UNHNQH@H@

4&2'=F

4&2'=F

K K K K K K

"#!$#!&

@68

"#11<"&

-($$=

!=12

&$

%41

&,!4L/

2%&,1'&!+2&!$'

+!4+$

&#2+R

41#!2?

676

!"

@UNHNQH@HN

"#11<"&

RouterK B:
4&2'=F 4&2'=F 4&2'=F 4&2'=F 4&2'=F

!"

@UNHNQH@H@

4&2'=F

4&2'=F

K K K K K K

"#11<"&

-($$=

!=12

&$

%41

&,!4L/

2%&,1'&!+2&!$'

+!4+$

!"

@UNHNQH@HN

"#!$#!&

@68

"#11<"&

&#2+R

41#!2?

676

show standby

ISAKMP
+#
"&$

Note: ISAK P uses DP port number 500 (AC s). For any ISAK P (using pre-shared keys or RSA encrypted nonces): K K
!42R<" "$?!+ @

1'+#

"&!$'

,24,

<=8

2%&,1'&!+2&!$'

(#$%"

?!.1&!<1

For ISAK P using RSA encrypted nonces:


+# 4,$* +#

K K K

"&$

R1

"&$

R1

(1'1#2&1=

+#

"&$

R1

2==#1441=;R1

R1

<

;4&#!'(

"%FR1

#42

Repeat the last few commands at each peer. For ISAK P using pre-shared keys:
+#

"&$

!42R<"

Repeat these steps at each peer with the identical key.

IPSEC

Copyright 200 , Rob Webber

M '( M 9
@

MM U
=14 -41&4

n#42;1'+#\"#1;4,2#1o

&,1

!..1;^1??<2'

(#$%"/

DE66

K K K K K
<

(1'1#2&1

"%FR1

&,1

K K +16#%%* 6!:6* "! 61 * v .+ 6A 6+% +:+ %6# 6 !!"63+ 6


"%FR1 ;+,2!'

+$<<2'=

R1

)0 )$/ )22) / ) /) ))/8 )02/ $7 )22 ) /) ))


#42

#42

-&$

4,$*

$%#

"%F?!+

R1

*,!+,

*24

t%4&

"#1>!$%4

+$<<2'=/

#42

4,$*

+#

"&$

R1

KA

*+

2==#144

#%%*

6!:6* "!

61

*&

161

Rob Webber's CCIE Notes from Experience

L M
+#

Note: The IPSec ESP and A protocols use IP protocol numbers 50 and 51 (AC s). anual IPSec security associations:
K K K
"&$ !"41+

Version 8.0

&#2'4.$#<;41&

<

41&

14";=14

+#

"&$

<2"

<

+#

"&$

<2"

<

K K

<2"

?$+2?;2==#144

$$"F2+R@

<2"

@6

!"41+;<2'%2?

41&

"11#

@6H

H@H@

41&

4144!$';R1

41&

4144!$';R1

K K

!'F$%'=

14"

@666

+!",1#

@NDQ8EU

@NDQ8EU

$%&F$%'=

14"

@666

+!",1#

@NDQ8EU

41&

&#2'4.$#<;41&

<

<2&+,

!'&1#.2+1

+#

2++144;?!4&

ISAK P negotiated IPSec security associations:


-+$'.!(%#1 d)Xi_[T

+#

+#

+#

K K K

"&$

"&$

@NDQ8EU

41&

2==#144

@66

41#!2?

"&$

<2"

<

<2"

@66

"1#<!&

!"

@6H@HNH6

6H6H6HN88

@6H

H@H6

6H6H6HN88

&,1'q/

!"41+

&#2'4.$#<;41&

<

!42R<"

R1

"&$

<2"

<

<

41&

14";=14

14";4,2

"244*$#=

2==#144

@6H

H@H@

<2"

@6

!"41+;!42R<"

<2&+,

2==#144

@66

41&

"11#

@6H

O K

H@H@

41&

&#2'4.$#<;41&

<

41&

!'&1#.2+1

5&,1#'1&

+#

"&$

<2"

<

<2"

2++144;?!4&

@66

"1#<!&

!"

@:NH@E

H@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 crypto map O debug crypto ipsec
%QM
(./"$M

IPv6
A

Copyright 200 , Rob Webber

c es is s& Fi ering 9
!'&1#.2+1

1"%&(

%)

-L t

lt

3X67@

!">E

&#2..!+;.!?&1#

F?$+RZ#@

$%&

!">E

2++144;?!4&

F?$+RZ#@

"1#<!&

%="

2'

"1#<!&

%="

2'

K K

1S

#!"

2'

2'

1S

#!"

162

Rob Webber's CCIE Notes from Experience

Version 8.0
D66JD66JD66JJD ?$(;!'"%&

E GR
I

"1#<!&

&+"

2'

=1'

K K

2'

K
,$4&

!+<"

,$4&

@6J@6J@6JJ@

"1#<!&

%="

2'

2'

1S

8N@

"1#<!&

!">E

,$4&

@6J@6J@6JJ@

2'

P
!'&1#.2+1

M!(2F!&5&,1#'1&676

!">E

2==#144

D6X6JG

66J6JIXJJ7EQ

1%!;EQ

!">E

1!(#"

!'&1#.2+1

M!(2F!&5&,1#'1&67@

!">E

2==#144

D6X6JG

66J@JIGJJ7EQ

1%!;EQ

!">E

1!(#"

OSP

F un eRingu er nfigura i n R u er nfigura i n


<1&#!+

!">E

#$%&1#

1!(#"

*1!(,&4

N88

N88

N88

@66

@86

=!4&#!F%&1;?!4&

"#1.!W;?!4&

X++1"&Z

$%&14Zd'

!'

=!4&#!F%&1;?!4&

"#1.!W;?!4&

X=>1#&!41Z

$%&14Zc%&

$%&

#1=!4&#!F%&1

#!"

?2F

!'&1#.2+1

41#!2?

676

!">E

$4".

2#12

!">E

#$%&1#

$4".

?$(;2=t2+1'+

;+,2'(14

=1.2%?&;<1&#!+

@666

#1=!4&#!F%&1

4&2&!+

!'&1#.2+1

o t A CC o
2==#144

to
6

$$"F2+R

!"

@UNH@EHQ8H@

N88HN88HN88H6

!'&1#.2+1

&%''1?

!">E

2==#144

@J@JNJ@JJN7@NE

&%''1?

4$%#+1

$$"F2+R

&%''1?

=14&!'2&!$'

@UNHN@H@:@H@

&%''1?

<$=1

!">E!"

!">E

#!"

,$(*2#&4

1'2F?1

!'&1#.2+1

o t B CC o
2==#144

to
6

$$"F2+R

!"

@UNHN@H@:@H@

N88HN88HN88H6

!'&1#.2+1

&%''1?

!">E

2==#144

@J@JNJ@JJD7@NE

&%''1?

4$%#+1

$$"F2+R

&%''1?

=14&!'2&!$'

@UNH@EHQ8H@

&%''1?

<$=1

!">E!"

!">E

#!"

MPLS

Copyright 200 , Rob Webber

,$(*2#&4

1'2F?1

16

Rob Webber's CCIE Notes from Experience

H333
<"?4

Version 8.0

ere is an example config of a PE router (10.10.10.10) running P S with another PE router (10.20.20.20) and sharing routes with a CE router (10. 0. 0. 0) using BGP:

ML

PE Router Config:
?2F1?
"#$&$+$?

?="

<"?4

?="

#$%&1#;!=

?$$"F2+R6

.$#+1

!'&1#.2+1

?$$"F2+R

!"

2==#144

@6H@6H@6H@6

N88HN88HN88HN88

!'&1#.2+1

M!(2F!&5&,1#'1&676

=14+#!"&!$'

I$''1+&!$'

&$

[5

#$%&1#

!"

2==#144

@6HN8HN8HN8

N88HN88HN88H6

<"?4

!"

!'&1#.2+1

M!(2F!&5&,1#'1&67@

=14+#!"&!$'

I$''1+&!$'

&$

+%4&$<1#@

!"

2==#144

@6HD8HD8HD8

N88HN88HN88H6

!"

>#.

.$#*2#=!'(

+%4&$<1#@

!"

>#.

+%4&$<1#@

#=

E8666J@

#$%&1;&2#(1&

F$&,

E8666J@

#$%&1#

F("

E8666

'$

'+,#$'!e2&!$'

'1!(,F$#

@6HN6HN6HN6

#1<$&1;24

E8666

!GM[

$.&1'

%414

?$$"F2+R4

'1!(,F$#

@6HN6HN6HN6

%"=2&1;4$%#+1

$$"F2+R6

2==#144;.2<!?

>"'>Q

'1!(,F$#

@6HN6HN6HN6

2+&!>2&1

'1!(,F$#

@6HN6HN6HN6

41'=;+$<<%'!&

1W!&;2==#144;.2<!?

K
%'!+24&
>#.

1W&1'=1=

2==#144;.2<!?

!">Q

+%4&$<1#@

'1!(,F$#

@6HD8HD8HDE

#1<$&1;24

EQ866

'1!(,F$#

@6HD8HD8HDE

2+&!>2&1

'$

'+,#$'!e2&!$'

'$

2%&$;4%<<2#

1W!&;2==#144;.2<!?

CE Router Config:
!'&1#.2+1

?$$"F2+R

!"

2==#144

@6HD6HD6HD6

N88HN88HN88HN88

!'&1#.2+1

324&5&,1#'1&676

=14+#!"&!$'

I$''1+&!$'

&$

[5

#$%&1#

!"

2==#144

@6HD8HD8HDE

N88HN88HN88H6

#$%&1#

F("

EQ866

'1!(,F$#

2==#144;.2<!?

'1&*$#R

Copyright 200 , Rob Webber

@6HD8HD8HD8

#1<$&1;24

E8666

!">Q

@:NH@E

H@8H6

<24R

N88HN88HN88H6

164

Rob Webber's CCIE Notes from Experience


'1!(,F$# @6HD8HD8HD8

Version 8.0

2+&!>2&1

'$

'+,#$'!e2&!$'

'$

2%&$;4%<<2#

1W!&;2==#144;.2<!?

M l

I MP A
A

C MPA
A

PIM

PIM Sp
!" !"

PIM Sp
!" !"

Copyright 200 , Rob Webber

Gu ticast G - Dense de - arse de a icRe)22nde us)$ )in'2 '/) - arse Dense de u a icRende us in 9
$%&1#-+$'.!(/0!'&1#.2+1
5&,1#'1& 6

show ip vrf [{brief | detail | interfaces}] vrf2 show ip route vrf vrf2 show ip protocols vrf vrf2 show ip bgp vpnv4 all debug mpls adjacency debug mpls events

$%&1#-+$'.!(;!./0!"

!(<"

t$!';(#$%"

NNQH@HNHD

I$'4$?1-+$'.!(/041&

!(<"

1'2F?1

I$'4$?1-+$'.!(/041&

<%?&!+24&

#$%&1#

D78

-#1S%!#1=

.$#

dM_[/

$%&1#-+$'.!(/0!'&1#.2+1

5&,1#'1&

$%&1#-+$'.!(;!./0!"

+(<"

I$'4$?1-+$'.!(/041&

+(<"

1'2F?1

Mo

!"

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

!'&1#.2+1

41#!2?

!"

"!<

=1'41;<$=1

!'&1#.2+1

1&,1#'1&

!"

"!<

=1'41;<$=1

!"

!(<"

t$!';(#$%"

NN8H@H@H@

-"?2+1

&,!4

$'

&$

&14&

4,$%?=

F1

"!'(2F?1/

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

Mo (St t
41#!2?

zvo

Po t)
%

"!<

#";2==#144

#%%*

&!:&*

-!

&*!

*&

!'&1#.2+1

!"

"!<

4"2#41;<$=1

!'&1#.2+1

1&,1#'1&

!"

"!<

4"2#41;<$=1

!"

!(<"

t$!';(#$%"

NN8H@H@H@

-"?2+1

&,!4

$'

&$

&14&

4,$%?=

F1

"!'(2F?1/

Mo (A tom t
K

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

zvo Po t)
-$'?

"!<

41'=;#";=!4+$>1#

4+$"1

N88

&,1

#1S%!#1=

$'

[/

165

Rob Webber's CCIE Notes from Experience


!" "!<

Version 8.0
6

41'=;#";2''$%'+1

1&,1#'1&

4+$"1

N88

-$'?

&,1

#1S%!#1=

$'

[/

!'&1#.2+1

41#!2?

!"

"!<

4"2#41;=1'41;<$=1

!'&1#.2+1

1&,1#'1&

!"

"!<

4"2#41;=1'41;<$=1

!"

!(<"

t$!';(#$%"

NN8H@H@H@

-"?2+1

&,!4

$'

&$

&14&

4,$%?=

F1

"!'(2F?1/

Net w Nuetgwingrk- durcreesd rersaenss ati n N


flo
L L
!"

show ip mroute show ip pim neighbor show ip pim interface show ip pim rp show ip igmp groups debug ip pim
.?$*;1W"$#&

=14&!'2&!$'

@6H@H@H@

!"

.?$*;1W"$#&

>1#4!$'

-$"&!$'2?/

!"

.?$*

1W"$#&

4$%#+1

$$"F2+R6

-$"&!$'2?/

!"

.?$*;+2+,1

1'&#!14

866

-$"&!$'2?/

!'&1#.2+1

32676

!"

.?$*

!'(#144

show ip cache flow show ip cache verbose flow

o A
'2&

l o ( AT)
@6H@8HN6H@ N6QH@:DHNQH8

O t o

Static:
!"

So

!'4!=1

4$%#+1

4&2&!+

!'&1#.2+1

1&,1#'1&6

!"

'2&

!'4!=1

!'&1#.2+1

41#!2?6

!"

'2&

$%&4!=1

Dynamic:
!" '2& "$$? <

"$$?

N6UHNQNH@66H@

N6UHNQNH@66H86

N88HN88HN88H6

!"

'2&

!'4!=1

4$%#+1

?!4&

"$$?

<

"$$?

!- *.!#%

!'&1#.2+1

!"

'2&

!'4!=1

Copyright 200 , Rob Webber

1&,1#'1&6

'1&<24R

166

Rob Webber's CCIE Notes from Experience

Version 8.0

I om
!" !"

nc ing - urce d res es


!'&1#.2+1

41#!2?6

!"

'2&

$%&4!=1

2++144;?!4&

"1#<!&

@:NH@E

HNH6

6H6H6HN88

Static:
"$$?

So

'2&

'1&;@6

@6H6H@H6

@6H6H@HN88

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

NQ

'2&

$%&4!=1

4$%#+1

?!4&

"$$?

'1&;@6

!'&1#.2+1

1&,1#'1&

!"

2==#144

@U@HE:HNDNH@

N88HN88HN88HNQ6

!"

'2&

$%&4!=1

!'&1#.2+1

1&,1#'1&

!"

2==#144

:H@@QH@@HD:

N88HN88HN88H6

!"

'2&

2++144;?!4&

!'4!=1

"1#<!&

:H@@QH@@H6

6H6H6HN88

(On inbound packets with a source address of .114.11.0/24, the source address is translated to the 10.0.1.0/24 range. This would be useful if the .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 .114.11.0 subnet within your own network.) ip nat outside source list (or static) ip nat inside source list (or static)

translates the source of the IP packets that are traveling outside to inside translates the destination of the IP packets that are traveling inside to outside translates the source of IP packets that 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 *

TP

Copyright 200 , Rob Webber

167

ck and da ec ands anee Dae ice as an N er er sing Res ric ing c es an N er er


Clo
t omm
#@-+$'.!(/0
+?$+R

Rob Webber's CCIE Notes from Experience


&!<1e$'1
5)

B
5

;8

#@-+$'.!(/0

+?$+R

4%<<1#;&!<1

mB

#1+%##!'(

#@-+$'.!(/0

'&"

%"=2&1;+2?1'=2#

(if th m chin h s

#N0

+2?1'=2#

41&

@6J68J66

X"#!?

N666

#N-+$'.!(/0

+?$+R

+2?1'=2#;>2?!=

#N0

c l nd r)

+?$+R

41&

@6J68J66

X"#!?

N66@

(if th m chin h s rm n nt c l nd r) (if th m chin h s rm n nt c l nd r) ( nly if th m chin d sn't h v rm n nt

o v Server:
!" '&"

TP S v
6

ee aa ee aa aa ppee aa ee aa ee aa o e a e oe a e a pe a e
rm n nt c l nd r)

Version 8.0

!'&1#.2+1

?$$"F2+R

2==#144

@:NH@E

HN8QH@

N88HN88HN88H6

<24&1#

Client:
'&"

41#>1#

@:NH@E

HN8QH@

t t A Server:
!" '&"

to

TP S v
6

!'&1#.2+1

?$$"F2+R

2==#144

@:NH@E

HN8QH@

N88HN88HN88H6

<24&1#

2++144;?!4&

"1#<!&

@UNH@EHNQH@

'&"

2++144;(#$%"

41#>1

Co

'&"

'&"

nfiguringN u hen ica i n


!'&1#.2+1

Client:
!" '&" '&"

?$$"F2+R

2==#144

@UNH@EHNQH@

N88HN88HN88H6

4$%#+1

$$"F2+R6

41#>1#

@:NH@E

HN8QH@

Server:

TP A t
K
@

t to
@ <=8

2%&,1'&!+2&1

2%&,1'&!+2&!$';R1

!(%2'2

'&"

&#%4&1=;R1

Clients:
'&"

2%&,1'&!+2&1

'&"

'&"

OSP
B

asicF

2%&,1'&!+2&!$';R1

&#%4&1=;R1

<=8

!(%2'2

'&"

41#>1#

@:NH@E

HD

O O
H

R1

show clock show ntp association show ntp status

!'&1#.2+1

Copyright 200 , Rob Webber

41#!2?

168

Rob Webber's CCIE Notes from Experience


!"

Version 8.0

$4".

'1&*$#R

"$!'&;&$;<%?&!"$!'&

!"

$4".

"#!$#!&

@6

!"

$4".

+$4&

@86

#$%&1#

$4".

@66

'1&*$#R

@6H@NH@Q6H@N

6H6H6H@NU

2#12

'1&*$#R

@86H@86H6H6

6H6HN88HN88

2#12

'1&*$#R

@:NH@E

O OO
H

H6

6H6H6HN88

2#12

S mm z t o
#$%&1#
2#12
Q

u ari a i n
'1&*$#R '1&*$#R

show ip ospf show ip ospf neighbor show ip ospf interface debug ip ospf adjacencies debug ip routing
$4".
8 @6HQH6H6 6H6H6HN88

2#12

@6H@6H@Q6H@N

6H6H6H@NU

2#12

#2'(1

@6H@6H6H6

N88HN88H6H6

A t

A t

u hen ica i n- i e ear ex u hen ica i n- D


4%<<2#
;2==#144 @UNH@EH

H6

N88HN88HN8QH6

#$%&1#

#!"

'1&*$#R

@UNH@EH6H6

show ip ospf summary-address

t to
2#12

#$%&1#

$4".

S mpl (Cl t t)
@ @:NH@E

2%&,1'&!+2&!$'

'1&*$#R

H@H6

6H6H6HN88

2#12

!'&1#.2+1

1&,1#'1&

!"

2==#144

@:NH@E

H@H@

N88HN88HN88H6

!"

$4".

2%&,1'&!+2&!$';R1

"244*$#=

t to
2#12

M 5
@

#$%&1#

$4".

2%&,1'&!+2&!$'

<1442(1;=!(14&

'1&*$#R

@:NH@E

H@H6

6H6H6HN88

2#12

!'&1#.2+1

1&,1#'1&

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 dvis bl wh n v r ssibl . Als , th c mm nd can be used to override (on an interface basis) the authentication set for an area, though this is extremely rare. St t ll o
!"

Copyright 200 , Rob Webber

a a e e e e po e o e o a a ica yDefined Neighb rs 9


!"

2==#144

@:NH@E

H@H@

N88HN88HN88H6

!"

$4".

<1442(1;=!(14&;R1

<=8

"244*$#=

$4".

2%&,1'&!+2&!$'

16

Rob Webber's CCIE Notes from Experience


.#2<1;#1?2
<2" !"

Version 8.0
'$';F#$2=+24&

K If you can't use broadcasts (as with the statements or if you must use , for example) you must manually define OSPF neighbors with the neighbor statement (usually done at the hub):
$4".
'1&*$#R "$!'&;&$;<%?&!"$!'& !'&1#.2+1

)1#!2?6

!"

2==#144

@6H6H@H@

N88HN88HN88H6

1'+2"4%?2&!$'

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

K K K K
@

K
N6N

?$+2?;=?+!

N66

<2"

!"

@6H6H@HD

<2"

!"

@6H6H@HQ

N6D

<2"

!"

@6H6H@H8

N6Q

#$%&1#

$4".

'1&*$#R

@6H6H@H6

6H6H6HN88

2#12

'1!(,F$#

@6H6H@HD

+$4&

'1!(,F$#

@6H6H@HQ

+$4&

@6

'1!(,F$#

@6H6H@H8

+$4&

@8

,1

.$??$*!'(

!4

&,1

+$'.!(%#2&!$'

.$#

&,1

#$%&1#

$'

&,1

$&,1#

4!=1J

!'&1#.2+1

)1#!2?:7N

!"

2==#144

@6H6H@HD

N88HN88HN88H6

St

ub and N reas
.#2<1;#1?2 .#2<1;#1?2

1'+2"4%?2&!$'

.#2<1;#1?2

K K

K
D66

?$+2?;=?+!

D6@

<2"

!"

@6H6H@H@

#$%&1#

$4".

'1&*$#R

@6H6H@H6

6H6H6HN88

2#12

#$%&1#

SSA A
@ N

$4".

2#12

4&%F

2#12

4&%F

'$;4%<<2#

K K
2#12
6

2#12

'442

V t lL
L

ir ua ink
!" !"

2#12

'442

'$;4%<<2#

'1&*$#R

@6H8HQH6

6H6H6HN88

'1&*$#R

@6H8HEH6

6H6H6HN88

2#12

'1&*$#R

@6H8H

H6

6H6H6HN88

2#12

'1&*$#R

@6H8H@6H6

6H6H6HN88

2#12

'1&*$#R

@6H8H@NH6

6H6H6HN88

2#12

!'&1#.2+1

$$"F2+R6

2==#144

@6H@NH@NH@

N88HN88HN88H6

!'&1#.2+1

)1#!2?@

2==#144

@:NH@E

HNH@

N88HN88HN88H6

#$%&1#

$4".

'1&*$#R

'1&*$#R

2#12

>!#&%2?;?!'R

Copyright 200 , Rob Webber

@6@

@6H@NH@NH6

6H6H6HN88

2#12

@:NH@E

HNH6

6H6H6HN88

2#12

@UNH@UH@6@H@

170

Rob Webber's CCIE Notes from Experience


C

Version 8.0

!'&1#.2+1

$$"F2+R6

!"

2==#144

@UNH@UH@6@H@

N88HN88HN88H6

!'&1#.2+1

)1#!2?@

!"

2==#144

@:NH@E

HNHN

N88HN88HN88H6

as w rd Rec ery
#$%&1# $4".
@6D '1&*$#R '1&*$#R @:NH@E '1&*$#R @:NH@E

@UNH@UH@6@H6

6H6H6HN88

2#12

O O

HNH6

6H6H6HN88

2#12

HU6H6

6H6H6HN88

2#12

2#12

>!#&%2?;?!'R

@6H@NH@NH@

2500/ 000 Reboot router. Type B AK (control-shift-6 b on Cisco terminal server, control-F6-break on yperterm, Alt-b on TeraTerm). Type o/ 0 21 2 at the ">" prompt (to boot from flash). Type I at the ">" prompt to reboot the router. Answer no to all set-up questions. Type l at the Router> prompt. Type op t t (brings in old config) Watch this!! Not the other way around!! Type o t m, then either l t <p o . or l p o <p o . Type o t m, then o t 0 2102. Verify the config now in running-config is correct. Type op t t. (Type lo . - optional) 2600/3600/ 500 Reboot router. Type B AK (control-shift-6 b on Cisco terminal server, control-F6-break on yperterm). Type o 0 21 2 at the "RO ON>" prompt (to boot from flash). Type t at the "RO ON>" prompt to reboot the router. Answer no to all set-up questions. Type l at the Router> prompt. Type op t t (brings in old config) Watch this!! Not the other way around!!
Copyright 200 , Rob Webber

4 H RE
o

show ip ospf virtual-link

ov

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.

renabxe 4 cwc nrdyfigs aaersr rwunrd> enab esecre as w rd> enab e as cc nfyigruners ar c nfig regis er x r4 e ad H creRsnEefreg x 4 MM MM ecnaby se ar run 9

171

Rob Webber's CCIE Notes from Experience

P o t Q Bruce Caslow describes priority queuing as a "facist" queuing strategy since it is very strict in its approach. igher queues get priority, period. Given enough high priority traffic, other queues can go for days without tranmitting.
"#!$#!& "#!$#!& "#!$#!&

cwc nnrdffiigg aeesrr w rd>c nfigenreagbiseesrecxre as w rd> enab e as c y run s ar raendad ra ic ha ing ueuing H ri ri y ueuing H
Type o t m, then either l t <p p o <p o . Type o t m, then o t 0 2102. Verify the config now in running-config is correct. Type op t t. (Type lo . - optional)

Version 8.0

. or

T ff S p

There are as many Cisco variations of queuing as there are flavors of ice cream. owever here are a few powerful ones that can satisfy many requirements:

K K K

;?!4&

"#$&$+$?

!"

,!(,

&+"

;?!4&

"#$&$+$?

!"

,!(,

&+"

ND

;?!4&

"#$&$+$?

!"

<1=!%<

?!4&

@66

C tom Q

us ueuing
!'&1#.2+1 "#!$#!&

2++144;?!4&

@66

"1#<!&

&+"

2'

2++144;?!4&

@66

"1#<!&

&+"

2'

K K

1S

QQD

2'

2'

1S

QQD

41#!2?

;(#$%"

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 (applied to serial 1/0 via the command). The actual queue number appears later in the command (such as queue 1, queue 2 and queue 4 in this example).
+%4&$<;S%1%1;?!4&
:

S%1%1;?!4&

S%1%1;?!4&

"#$&$+$?

!"

&+"

ND

S%1%1;?!4&

"#$&$+$?

!"

?!4&

@N6

S%1%1;?!4&

S%1%1

&1;+$%'&

D666

S%1%1;?!4&

=1.2%?&

2++144;?!4&

2++144;?!4&

2++144;?!4&

2++144;?!4&

Copyright 200 , Rob Webber

@N6

"1#<!&

(#1

2'

2'

@N6

"1#<!&

$4".

2'

2'

K
2'

@N6

"1#<!&

!"

,$4&

@6H@HNDHQ

@N6

"1#<!&

!"

2'

,$4&

@6H@HNDHQ

172

Rob Webber's CCIE Notes from Experience


!'&1#.2+1

Version 8.0

41#!2?

@76

+%4&$<;S%1%1;?!4&

qay Fra e Re
m l
!" '$

You can also assign packets to queues based on their size. To assign packets over 1000 bytes to queue , use:
S%1%1;?!4&
: "#$&$+$? !"

(&

@666

show ueue serial 0


!'&1#.2+1

41#!2?

6H6

2==#

@UNH@EH@H@

N88HN88HN88H6

1'+2"4%?2&!$'

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

Raesdicistributi n
<2";+?244

+?244

<

K K

K
@6N

&#2..!+;4,2"!'(

!'&1#.2+1;=?+!

+?244

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

.#2<1;#1?2

K K K

<

+?244

+!#

8E666

-=1.!'14

Id

F+

666

-=1.!'14

F%#4&

2<$%'&

!'

F!&4/

F1

@E666

-=1.!'14

1W+144

F%#4&

!'

F!&4/

.#2(<1'&

@E6

-=1.!'14

"2+R1&4

@E6

F1

.#2(<1'&1=/

.#2<1;#1?2

2=2"&!>1;4,2"!'(

sing R u e a s n r Redis ribu i n


#$%&1# $4".
@

#1=!4&#!F%&1

#!"

<1&#!+

@66

<1&#!+;&

"1

#$%&1;<2"

#$F

4%F'1&4

#$%&1#

1!(#"

#1=!4&#!F%&1

F("

E8666

<1&#!+

@666

@6

@66

@66

@866

o t -M p to Co t ol t to 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&#!+

#$%&1;<2"

@UN;@E;$'?

OSP

F Exa e
L
!"

'1!(,F$#

@:NH@E

H@@H@

#1<$&1;24

E866@

"#1.!W;?!4&

@UN;@E;$'?

41S

"1#<!&

@UNH@EH6H67@E

?1

DN

#$%&1;<2"

@UN;@E;$'?

"1#<!&

@6

<2&+,

!"

2==#144

"#1.!W;?!4&

@UN;@E;$'?

mpl 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".

Copyright 200 , Rob Webber

17

Rob Webber's CCIE Notes from Experience


#1=!4&#!F%&1
F("
E866@ <1&#!+ @6 <1&#!+;& '1&*$#R @:NH@E

Version 8.0
K
"1 @

4%F'1&4

HN66H6

6H6H6HN88

2#12

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&!+

'1&*$#R

@:NH@E

c$4".

H86H6

6H6H6HN88

2#12

!"

#$%&1

@6H@U:H6H6

N88HN88H6H6

@6HN66H@HN

!"

#$%&1

@6H@

6H6H6

N88HN88H6H6

@6HN66H@HN

!"

"#1.!W;?!4&

@6;@U:;6;6

41S

"1#<!&

@6H@U:H6H67@E

!"

"#1.!W;?!4&

@6;@

6;6;6

41S

"1#<!&

@6H@

6H6H67@E

#$%&1;<2"

4&2&!+

c$4".

"1#<!&

N6

B P

G Exa e
41&
L
<2&+,

<2&+,

!"

2==#144

"#1.!W;?!4&

@6;@U:;6;6

<1&#!+;&

"1

&

"1;@

#$%&1;<2"

4&2&!+

c$4".

"1#<!&

D6

!"

2==#144

"#1.!W;?!4&

@6;@

41&

<1&#!+;&

"1

&

6;6;6

"1;N

mpl 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@ '$

'+,#$'!e2&!$'

#1=!4&#!F%&1

!(#"

#$%&1;<2"

41&+$<<%'!&

'1!(,F$#

@:NH@E

'1!(,F$#

@:NH@E

'$

2%&$;4%<<2#

K K

O O

H@@HN

#1<$&1;24

E8666

H@@HN

41'=;+$<<%'!&

!"

F(";+$<<%'!&

'1*;.$#<2&

#$%&1;<2"

41&+$<<%'!&

41&

+$<<%'!&

"1#<!&

@6

@@@@@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 '$

'+,#$'!e2&!$'

#1=!4&#!F%&1

$4".

<2&+,

1W&1#'2?

'1!(,F$#

'$

2%&$;4%<<2#

Copyright 200 , Rob Webber

@:NH@E

H@@H@

#1<$&1;24

E866@

174

Regu ar x res i ns * R
l Ep o
^ $ _ . .

Rob Webber's CCIE Notes from Experience

Version 8.0

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)

IP
!" !"

!'&1#.2+1

5&,1#'1&

'1!(,F$#

@6H@86H@86H@

#!"

41'=

>1#4!$'

#!"

#1+1!>1

>1#4!$'

#$%&1#

#!"

>1#4!$'

'$

2%&$;4%<<2#

$'?

2""?!14

!.

>1#4!$'

!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&#!+

$..41&;?!4&

@6

!'

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 commands sets the RIP metric (hop count) for all routes redistributed into RIP.
=1.2%?&;<1&#!+

The increases the metric (from what was learned) by 4 for all routes that match . This command also applies to IGRP and EIGRP.
$..41&;?!4&
2++144;?!4&
@6

R ute a s
!"

The and interface basis) the version of RIP defined by the command.
#!"
41'= >1#4!$'
!"

#!"

#1+1!>1

>1#4!$'

>1#4!$'

override (on an router

debug ip rip debug ip routing

Mp

Copyright 200 , Rob Webber

175

Rob Webber's CCIE Notes from Experience

Version 8.0

Pol

icy R u e a s
!'&1#.2+1 !" "$?!+

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.

o t Mp 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 AC 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:
1N76

#$%&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@

T m l S v Co f
!'&1#.2+1

er ina er er n igurati n
!"

+1,#%%* The 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).
41&
!" =1.2%?& '1W&;,$"

)22

H8EH@

@:NH@E

H@H6

6H6H6HN88

To enable the router to policy route for locally generated traffic (pings, telnet traffic, etc.):
?$+2?
"$?!+

#$%&1;<2"

<

<2"

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.
?$$"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 to send an escape sequence to the term server that will bring you back to the terminal server prompt. Type to send a break to a router that is being accessed via the terminal server (handy for password recovery).
+$'&#$?;4,!.&;E W +$'&#$?;4,!.&;E

Copyright 200 , Rob Webber

176

Rob Webber's CCIE Notes from Experience

Version 8.0
+$'&#$?;4,!.&;E

ISL:

802.1Q:

runking $ $' () $ $' () un e s R e a Ro e Re a oo o R e


+$'&#$?;4,!.&;E

To send an escape sequence to a router that is being accessed via the terminal server, type . 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 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 four times to escape.
+$'&#$?;4,!.&;E +$'&#$?;4,!.&;E

On Cisco routers:
!'&1#.2+1

324&

5&,1#'1&

676H@

1'+2"4%?2&!$'

!4?

-.# 6

"

On Cisco routers:
!'&1#.2+1

324&

5&,1#'1&

676H@

1'+2"4%?2&!$'

=$&@]

-.# 6

"

!'&1#.2+1

&%''1?

&%''1?

4$%#+1

@6H@66H8H@

&%''1?

=14&!'2&!$'

@6H@6H@6H@6

&%''1?

<$=1

(#1

!"

-$"&!$'2?

=1.2%?&4

&$

(#1/

1&+H

show interface tunnel 0

Th Virtu l ut r dund ncy Pr t c l (V P) is v ry simil r t HS P K 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.

4&2'=F

ere are some notable differences between SRP 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 SRP supports IPv6, VRRP does not. By default SRP backup routers automatically learn and use the ello and Downtime timers of the active router. VRRP can do this *! 1 with the command, but that is disabled by default. VRRP requires a group number, with SRP it is optional.
>##"

Copyright 200 , Rob Webber

H7 ' H 9

&!<1#4

?12#'

H H

ao R

177

Rob Webber's CCIE Notes from Experience


!'&1#.2+1

Version 8.0

324&1&,1#'1&

676

!"

2==#144

@6H@:NH

>##"

"#!$#!&

HN

N88HN88HN88H6

@68

>##"

2%&,1'&!+2&!$'

++!1

>##"

&!<1#4

2=>1#&!41

>##"

&!<1#4

?12#'

>##"

!"

@6H@:NH

H@

show vrrp show vrrp brief show vrrp interface Fastethernet 0/0 [brief]

Copyright 200 , Rob Webber

178

Rob Webber's CCIE Notes from Experience


!'&1#.2+1

Version 8.0

324&1&,1#'1&

676

!"

2==#144

@6H@:NH

>##"

"#!$#!&

HN

N88HN88HN88H6

@68

>##"

2%&,1'&!+2&!$'

++!1

>##"

&!<1#4

2=>1#&!41

>##"

&!<1#4

?12#'

>##"

!"

@6H@:NH

H@

show vrrp show vrrp brief show vrrp interface Fastethernet 0/0 [brief]

Copyright 200 , Rob Webber

178

You might also like