10 VLANs 10.1 Tutorial 10.2 Lab Abstract 10.3 Lab Scenario 11 WAN Protocols 11.1 Tutorial 11.2 Lab Abstract 11.3 Lab Scenario 1. What to Know 1.1 Exam Description The CCNA exam is the qualifying exam available to candidates pursuing a single-exam option for the Cisco Certified Network Associate CCNA certification. The CCNA (640-801) exam will test
materials from the new Interconnection Cisco Network Devices (ICND) course as well as the new Introduction to Cisco Networking Technologies (INTRO) course. The exam will certify that the successful candidate has important knowledge and skills necessary to select, connect, configure, and troubleshoot the various Cisco networking devices. The exam covers topics on Extending Switched Networks with VLANS, Determining IP Routes, Managing IP traffic with Access Lists, Establishing Point-to-Point connections, and Establishing Frame Relay Connections. 1.2 Exam Topics The following information provides general guidelines for the content likely to be included on the Introducing Cisco Network Design Exam. However, other related topics may also appear on any specific delivery of the exam. 1.3 Planning & Designing
• Design a simple LAN using Cisco Technology • Design an IP addressing scheme to meet design requirements • Select an appropriate routing protocol based on user requirements • Design a simple internetwork using Cisco technology • Develop an access list to meet user specifications • Choose WAN services to meet customer requirements
1.4 Implementation & Operation
• Configure routing protocols given user requirements • Configure IP addresses, subnet masks, and gateway addresses on routers and hosts • Configure a router for additional administrative functionality • Configure a switch with VLANS and inter-switch communication • Implement a LAN • Customize a switch configuration to meet specified network requirements • Manage system image and device configuration files • Perform an initial configuration on a router • Perform an initial configuration on a switch • Implement access lists • Implement simple WAN protocols
1.5 Troubleshooting
• Utilize the OSI model as a guide for systematic network troubleshooting • Perform LAN and VLAN troubleshooting • Troubleshoot routing protocols • Troubleshoot IP addressing and host configuration • Troubleshoot a device as part of a working network • Troubleshoot an access list • Perform simple WAN troubleshooting
1.6 Technology
• Describe network communications using layered models • Describe the Spanning Tree process • Compare and contrast key characteristics of LAN environments • Evaluate the characteristics of routing protocols • Evaluate TCP/IP communication process and its associated protocols • Describe the components of network devices • Evaluate rules for packet control • Evaluate key characteristics of WANs
The purpose of this tutorial is to introduce you to Cisco router operation. This tutorial will also help you study for several topic areas that may be tested in Cisco certification exams including IOS basics, Router CLI, and troubleshooting. This tutorial is divided into four sections: Overview of Cisco Router Hardware and Software, Basic Router IOS, Basic Router Configuration, and Basic Router Maintenance and Troubleshooting. There are also Appendices that include review questions (with answers) and additional material that you may find useful. 2.1 Tutorial Introduction Today Cisco Systems(r) has become the world's foremost developer and manufacturer of internetworking equipment and software. Cisco(r) develops and manufactures over 80% of the routing equipment that controls the flows of information traveling on the Internet and private internetworks. With this market dominance comes a huge demand for engineers and administrators that understand Cisco's routers and other products. One way that you can demonstrate understanding of Cisco routers and internetworking fundamentals is to pass the Cisco Certified Network Associate (CCNA(tm)) exam ( is not associated with Cisco). In July 2000 Cisco retired the CCNA 1.0 exam (640-407) and in August began offering the CCNA 2.0 exam (640-507). The new exam has a new list of objectives that are broader in scope than previous objectives and in fact are no longer really objectives but recommended topic areas for study. You can find these new topic areas here: http://www.cisco.com/warp/public/10/wwtraining/certprog/testing/pdf/ccna_507.pdf. ( is not associated with Cisco.) The purpose of this Tutorial is to introduce you to Cisco router operation. This paper will also help you study for several topic areas that may be tested in the CCNA 2.0 exam including IOS basics, Router CLI, and troubleshooting. This paper is divided into four sections: Overview of Cisco Router Hardware and Software, Basic Router IOS, Basic Router Configuration, and Basic Router Maintenance and Troubleshooting. There are also Appendices that include review questions (with answers) and additional material that you may find useful. Overview of Cisco Router Hardware and Software Hardware and Software Components of the Cisco 2501 Router You could say that a router is nothing more than a small PC with a smaller operating system and no direct user interface hardware, such as keyboards or video monitors. If you look at what a router does for networking, it is essentially the same as a personal computer. A router looks and acts like a PC in many ways. Like a PC, the router is built with input/output (I/O) ports, it has a processor and memory chips, it provides a set of instructions that tells the router what to do, and it has an operating system that runs the router. This paper will focus on the components and functions of one of Cisco's entry-level router models, the Cisco 2501. Throughout this text when a router configuration or setup is described we will be speaking of a 2501 unless the statement specifically refers to another router model or number. The 2501 router is a member of the 2500 series family of Cisco routers. It has a single Ethernet interface and two serial interfaces and is powered by a Motorola processor running at 25MHz. The 2501 router is the router of choice for most people getting started with hands-on Cisco router experience; however the Cisco 1600 router, with only one serial port, is adequate and costs a lot less. You can purchase refurbished 2501s for around $900 from various Web auction sites or network hardware resellers that specialize in Cisco equipment. The Cisco 1600 router should cost about $700. Let's take a closer look at the Cisco 2501 starting at the back of the router (see Figure 1). On the far left is one 10 megabit Ethernet AUI connector used for LAN connections. You will need an Ethernet transceiver/adapter attached to this port so that you can change this port from AUI to RJ45 and make it Category 5 compliant for a typical 10baseT or 100baseT network cable. To the right of the AUI connector are two high-density 60-pin serial connectors. These serial connectors
are used for WAN connections. Next to the serial ports are interfaces marked CONSOLE and AUX. Both of these interfaces look like telephone wall jacks that you plug your phone into. We'll discuss the purpose of these ports soon. To the right of the AUX port is small green LED. If this light does not come on when the router is turned on, your router may have a bad memory card or processor. On the far right is the connector where the power cord plugs in.
Figure 1. Cisco 2501 Router Front and Rear Views As you can see, the 2501 router has three types of interfaces. Interfaces are where the router meets the outside world and are the means by which a router receives or sends information. Serial interfaces are mostly used to connect long-distance as in a WAN (Wide-Area Network). Later in this paper we will describe how to connect routers together using their serial ports via DTE/DCE cables to simulate various WAN connections. Besides Ethernet, you can have other LAN interfaces on a router, such as Token Ring or FDDI (Fiber Distributed Data Interface) interfaces. For example, the Cisco router 2502 has two serial interfaces and one Token Ring interface instead of an Ethernet interface. See Appendix B for descriptions of various Cisco routers and the type of interfaces they have. Note: The interfaces discussed show how on a Cisco 2500 series router each interface is designated by interface type and number, such as ethernet0. On newer, modular routers and switches you will run into other interface notations. If the device is modular, it will have slots, cards, and ports on those cards, and you will run into interface notations such as ethernet 1/0 or serial 2/1/1. Remember that all slots and interfaces start at 0 and count up from there. In the case of ethernet 1/0, this represents the first port on the second slot interface card. This two-level representation is seen on all 2600 and 3600 routers, as well as on Catalyst 5000 series switches. Cisco 7200, 7500 and 12000 routers can have cards called Versatile Interface Processor that can accommodate multiple port adapters on a single slot. Where you have multiple port adapters with multiple ports in a single slot, you will see a three-level notation. Where you see a three-level notation, such as serial 2/1/0, this represents the first port on theon the second slot interface card. This two-level representation is seen on all 2600 and 3600 routers, as well as on Catalyst 5000 series switches. Cisco 7200, 7500 and 12000 routers can have cards called Versatile Interface Processor that can accommodate multiple port adapters on a single slot. Where you have multiple port adapters with multiple ports in a single slot, you will see a three-level notation. Where you see a three-level notation, such as serial 2/1/0, this represents the first port on the second card in the third slot. Each level simply means a more granular description of which port you are looking at. As you work on more routers, you will encounter this more frequently, and it will become more apparent. As the 2500 series routers become more frequently replaced by the 2600 series routers, this will become commonplace notation
There are two kinds of interfaces on a router, fixed interfaces and modular interfaces. The three interfaces we just described are fixed interfaces -- they are connected directly to the motherboard and can't be removed. Modular interfaces can be dynamically added or removed by plugging add-in modules or cards into the modular router bus interface. In Cisco routers, the type of bus depends on the model (or family) of router. In a 3600 router, the bus is a PCI bus; in a 7200, it is dual independent PCI buses; in the 7500 series, it is a CyBus. For more information about these types of bus architectures, you can consult the Cisco web site ( is not associated with Cisco.) A name and a number denote each of the interfaces on a Cisco router. The first of any of the interface types starts numbering at zero instead of one. For example, the 2501 router has two serial interfaces and one Ethernet, so we would have interface serial 0, interface serial 1, and interface ethernet 0. RAM, ROM, NVRAM, and Flash in Cisco Routers In order to understand what a router does, it helps to know where the basic components are found on the motherboard. In the following paragraphs we will describe the physical characteristics and the position of each component and give a brief explanation of each component's function. There are three main parts of a router: central processing unit (CPU), memory, and interfaces. The CPU is basically the same as that of a PC; it controls the execution of commands and instructions and directs the flow of information inside and out of the router. The memory comprises four different memory elements: Random Access Memory (RAM), Read-Only Memory (ROM), Non-Volatile RAM (NVRAM), and Flash memory. Notice the position of the several memory cards and chips in Figure 2. On the left, you can have up to two Flash memory cards. The Flash memory is where the IOS images are located. Cisco routers are almost completely useless without the Cisco IOS, also known as the system software image. Flash memory is a type of erasable, programmable, read-only memory and is available on most Cisco routers as a Flash memory chip, and on some models as a PCMCIA Flash card.
Figure 2. Cisco 2503 Motherboard Situated at the top-right is the Primary memory, which is a DRAM SIMM memory card, and right below this card are soldered chips called shared memory. There are two types of DRAM memory in the Cisco 2500 series routers: primary and shared (packet). Primary memory is used to store the operating configuration, routing tables, caches, and queues. Shared memory is used to store incoming and outgoing packets. If you have an extra 16 or 8 MB SIMM card lying around from an old 486, it should work fine as an upgrade for Primary memory.
The RAM we just talked about is used strictly for running operations and will get erased with every power off or reload. Router RAM is used just like the RAM in your PC. It stores the running configuration and is where all working information is stored. The running configuration is a partner to the startup configuration. After a router boots, the startup configuration is delivered to the running configuration and it's with this configuration that you typically work to make changes. After you're finished with the running configuration, you then save your changes to the more permanent startup configuration. If you could view the RAM after the router starts up, what you would see is the following: a cached subset of operating system commands, a copy of the startup configuration for running access, all route tables and anything else that dictates how the router behaves. NVRAM is different from RAM. The contents of NVRAM can be changed, modified, or erased at the user's command. NVRAM will not lose its contents when the router is turned off. The startup configuration file is stored in NVRAM or on the network. The startup configuration file is the instruction set the router uses to boot with. NVRAM is not in a socket. It is part of the motherboard, which makes it difficult to upgrade and hard to find. Both Flash and Primary memory can be upgraded by simply snapping in new cards. The amounts of Flash memory and Primary memory are typical configuration elements that describe a particular 250x router when advertised. You may see or hear of a router advertised as having an 8 by 8 configuration. This means that the router has 8 MB of Flash RAM and 8 MB of Primary memory. The Cisco router ROM is stored on memory chips that are located on the motherboard. Just underneath Primary memory are two ROM chips. Much like in a PC, the ROM stores the most elemental functions a router must perform to begin operation. ROM is a form of permanent memory used by the Router to store the "Power-On Self-Test" that checks the Router on boot up and the "Bootstrap Startup Program" that gets the Router going. In addition, ROM contains a very basic form of the Cisco IOS software, which is used during certain occasions. In order to upgrade ROM you have to remove and replace chips. The two ROM chips easily pop right out. Router Boot Sequence It is important to know the router's boot process. In the event of a boot problem, you may need to spot where the problem is occurring in order to correct it. When a router is powered up, there is a predefined sequence of events that must take place for the router to complete the booting process. First is the Power-On Self-Test (POST), where a test routine is run on the CPU, memory, and interface electronics to make sure there are no circuitry problems. The boot sequence steps are listed below:
1. The "Power-On Self-Test" checks the Router Hardware. This includes the CPU (Central Processing Unit), memory, and interfaces.
2. The "Bootstrap Program," which is stored in ROM, runs itself. 3. The "Bootfield" from the configuration register (discussed later) is read to find out the
proper Operating System source. 4. The "IOS software image" is loaded into RAM. The IOS software image can be loaded
from Flash, TFTP, or ROM. 5. The Startup Configuration File is read from NVRAM or a TFTP server and then loaded
into the RAM. The Configuration File is then executed one line at a time and starts the processes to run the router according to that file.
6. If no "Startup Configuration File" is found in NVRAM, the Cisco IOS will offer you the chance to use the "System Configuration Dialog" or commonly called the "Setup Script." This is a set of questions for you to answer to create a basic configuration.
To see how the boot sequence relates to the four types of memory we discussed earlier, refer to Figure 3. Some of the descriptions in the figure may contain terms you're not familiar with yet, but we'll explain those later in the paper. It is important to understand the relationship between memory and boot sequence for troubleshooting purposes, which we'll also discuss later.
Figure 3. Router Memory Types and Their Functions IOS Options Cisco is a hardware vendor company, but if you ask anyone at Cisco, they will likely tell you they are a software company. Their hardware is nothing more than an expensive boat anchor without the IOS software. Knowing this, we can see why knowledge of IOS system software manipulation is crucial to success in working with Cisco routers. Cisco routers have evolved much over the past 15 years. The IOS software has evolved along with them. In this evolution, Cisco has incorporated different features and functionality with every new release and version. IOS software images are bundled based on feature sets. Each feature set contains support for a certain protocol, group of protocols, or added feature. Some examples include the Desktop feature set that bundles most of the basic LAN networking protocols together, such as IP, IPX, AppleTalk, DECnet, bridging, WAN protocols, etc. Other feature set capabilities you may wish to implement include:
• IP means the router can manage protocols for the Internet. • IPX means the Novell protocols can be handled. • AT stands for the AppleTalk protocol for Macintoshes. • DEC stands for the Digital Equipment Corp. protocols. • APPN is for the Advanced Peer to Peer Networks (IBM). • PLUS means NAT (Network Address Translation) can be performed. • IPSEC is an Internet SECurity feature (encryption) usually not found or needed in typical
WANs. • RAS is an alternate security solution. • FW means there are firewall capabilities built into the IOS.
Basic Router IOS Let's now cover how we access the Cisco router and its operating system through the user interface (UI). Router Access through the Console Port Since a router doesn't come with a video monitor, you need to use your computer monitor as the router's screen. When you use your monitor like this you call it a terminal. The terminal has an interface called the user interface (UI), which is text command line based instead of a mouse-operated graphic user interface (GUI).
First, let's look at how we can access the UI on a Cisco router. If you receive a Cisco router in the box, there will be a couple of things that accompany the router itself. There will be a black cable called a console cable. If you don't have the black cable, you can use any category 5 cable. Both ends of the black console cable have an RJ45 pin, which looks like a phone plug. Also included is a 9-pin or 25-pin serial adapter to be attached to one end of the black cable that you then connect to the serial port on your computer. The RJ45 end of the cable goes into the Console port on your router. Now you're ready to deal with the terminal program that will allow your computer to become the router's terminal window. You will need to use some sort of terminal emulation program, such as Hyper Terminal for Windows 95. If you have not used Hyper Terminal, click Start->Programs->Accessories->Hyper Terminal. Once the folder with Hyper Terminal comes up, double click on Hypertrm.exe. As shown in Figure 4, Hyper Terminal will come up and ask you to enter a name for your connection. Type in direct to com1 and hit Enter.
Figure 4. Name Your Connection On the next screen, there will be a drop-down list box titled "Connect using." Click on the arrow at the right and choose Direct to com1 and hit Enter.
Figure 5. Enter Connection Method The next screen will be the settings for how the terminal emulation program communicates with the console port on the router. The settings should be as shown in the following diagram, bits per second is set to 9600, data bits is 8, parity is none, stop bits is 1, and flow control is hardware. Click OK.
Figure 6. Enter Settings for the Serial Connection Once you are done with your session, you can close Hyper Terminal. When you do, you will be asked if you want to disconnect. Answer "yes." After this, you will be asked if you would like to save the session. You can go ahead and save this if you'd like, or you can say "no." If you say "no," however, you will have to go through this configuration again every time you go into Hyper Terminal. If you do save the session, when you bring up Hyper Terminal from the start menu, there will be an icon in that folder that will act as a shortcut to get around having to do the configuration steps every time. Router Access through Telnet Once a router has been initially configured and has basic network connectivity, the UI can be accessed remotely via Telnet instead of just through the console port. To Telnet from a Windows 95/98 or NT machine, click Start->Run. When the Run box comes up, type in the word "Telnet," and hit Enter. This will run the basic Telnet utility that comes with Microsoft Windows products. Once the Telnet utility program has come up, click Connect from the menu, then Remote System. Enter the IP address of the remote router to which you wish to Telnet and hit Enter. From there on, the interface will be mostly the same as a console connection. We will cover this again after we show you how to perform initial configuration on a Cisco router. Telnet access to any router can only be accomplished after initial configuration has been performed (from the Console port). Command Interpreter Once the router is booted, the Cisco IOS command interpreter, called the Exec, is ready to accept your commands. If you are familiar with DOS, the Exec is much like COMMAND.COM. In
the Exec command interpreter, there are two modes of operation: user mode and privileged mode. User Mode User mode is denoted by a greater than (>) sign after the router prompt, like this: Router> It allows the user to enter and execute some limited and basic monitoring commands. For example, you can only do things like view basic router information, check status of the router and routing tables, and test simple connectivity. There are no configuration permissions and only limited troubleshooting commands available in user mode. Privileged Mode Privileged mode is denoted by a pound (#) sign after the router prompt, like this: Router# In privileged mode, the user has access to all commands available in user mode, all commands necessary to troubleshoot and debug, as well as access to router configuration mode, which is where all router configuration commands are entered. We discuss router configuration mode later in this chapter. Commands in the Exec are entered via the Command Line Interface (CLI). This is not a new or different access level with its own prompt, rather it's the set of tools associated with the Exec modes. CLI Help The CLI has some functions that will give the user a little extra help in entering commands, troubleshooting, and configuring the router. An editing feature of the CLI is that you can arrow back and forward on a line to edit misspellings. There is one caveat, however. The backspace and delete keys do the same thing in the Cisco CLI. If you have access to a Cisco router and tried these commands, you probably noticed the --more-- notation when you entered the show version command. You have three options when you see --more--:
• If you press the [space] bar, the command interpreter will display another full screen of information.
• If you press the Enter key, you will get one more line of output. • If you want to exit before seeing the rest, you can press any other key. The [q] key is
most often used. Inline Help -- Words Another CLI feature that is a very helpful tool is inline help, also known as the question mark, which provides us with context-sensitive help. Context-sensitive help can be used in two ways, command syntax and word help. Let's try one of the above commands on a Cisco router and see what the ? will do for us: Router# show v? version vines vpdn Router# show v This is called word help. The output will be a line of data with several possible commands to complete the word that starts with the letter v. As you can see, the outcome was version vines vpdn, but what you might not notice is the second show v on the next command line. When using context sensitive help, the CLI will automatically repeat the command to where you left off to save you from having to re-enter that text. When using word help, make sure to fill in as many of the letters as you can, then immediately follow that with the question mark (?). Make sure not to leave a space. This inline help can be used in all levels and positions of a command.
Inline Help -- Command Syntax Help with command syntax can be attained from the question mark as well. If you are configuring the IP address of an Ethernet interface, but are not sure of the syntax, you can use the (?) to help you along: Router(config-if)# ip add ? A.B.C.D IP address Router(config-if)# ip add 192.168.1.1 ? A.B.C.D IP subnet mask Router(config-if)# ip add 192.168.1.1 255.255.255.0 ? secondary Make this IP address a secondary address <cr> Here we used the command syntax help to get us all the way through setting the IP address for the ethernet0 interface. You will notice that each step along the way gets us a little closer to where we want to be, and each step gives us a little different information. The last step shown with a question mark shows a couple of responses. The key one to notice here is that the <cr> symbol means that we have fulfilled the necessary command requirements and we can now simply hit the Enter key to execute it. (The <cr> stands for carriage return, i.e., the Enter key). Command Line Completion Another CLI feature is command line completion, the function of the [tab] key. Let's take the show version command and try it again, but this time let's put the [tab] key in the place of the question mark: Router# show v[tab] Router# show ve[tab] Router# show version The tab key will fill in with the command that matches the text you enter. If the amount you typed isn't enough, like the first line above, the CLI will make a sound and do nothing but duplicate what you have typed on the next line. This means that the command was too ambiguous, in other words there is more than one command that starts with the typed letter(s). The Cisco router IOS is actually derived from a Unix operating system kernel. From this origin, the Cisco CLI gained the ability to accept truncated commands. As long as the truncated command you enter is enough of the command to distinguish it from any other command with similar text, the CLI will accept it and the Exec will process it. As an example, let's look at the show version command from earlier. To accomplish the same thing, you could also type in sh ve. This is an easy way to get what you want done while conserving the maximum number of keystrokes, and as every Unix-head knows, that is the key to slowing the rapid expansion of the universe. In the text of this Tutorial, you will see terse versions of each command, but if you would like to see the full command, get some time in front of a router and hit the [tab] key a lot. If you truncate the command you are typing too much, and there is a command that has the same beginning, you will see the following error: Router# con % Ambiguous command: "con" Router# con? configure connect Router# con As you can see, there are two commands that begin with "con," and you must specify which one you wish to use. In this case you can type "con?" and get the two options available to you. Syntax Checking Automatic syntax checking is built into the CLI. If a command is improperly spelled, or is not a valid command, the router will respond by placing a caret symbol below the errant letter, word, or argument. If you were to type in show versoin like this example, here is what you would receive in response: Router# show versoin
^ % Invalid input detected at '^' marker. Hot Keys Used for Editing Hot keys are built into the CLI editor to help with simple editing functionality. If you are familiar with Unix, you will recognize quite a few of these: Table 1. IOS CLI Hot Keys
Hot Key Function
Delete Removes one character from the right of the cursor.
Backspace Removes one character from the left of the cursor.
Tab Fills in remaining text of a partial command.
Ctrl-a Moves to beginning of current line.
Ctrl-r Redisplays a line.
Ctrl-u Erases all characters on current line from cursor left.
Ctrl-w Erases word (all characters left of cursor up to next space character).
Ctrl-z Ends config mode (same as end command in config mode).
Up arrow Scrolls through previously entered commands.
Down arrow Scrolls forward through former commands (after using Up arrow).
Advanced Editing If the end of a line goes too long, it will not automatically wrap to the next one. Instead the Cisco IOS command shell gives you a dollar sign ($) at the beginning or end of the line. This indicates that you are an over-achiever and have typed too much, at least too much to be shown on the screen. If you type in a very long command, your line would now look like this: Router#$ this is a way too long line that is full Note that the $ goes after the Router Prompt. If you keep typing the line will shift over as you type, hiding more of the beginning of the sentence. Router#$ is full of sound and fury, signifying nothing! You can get back to the beginning of your novel by pressing [CTRL-A], and this would be the effect: Router# For Demo Only this is a long line that is full $ If you want to you can turn off these Advance Editing Tools by simply typing in terminal no editing at the prompt. A reason to turn off the Advanced Editing is that the tools are often incompatible with computer-executed scripts. Since this would be a silly thing to do if you are typing things in yourself, please turn them back on by typing in terminal editing. Command History The CLI keeps a history of the most recent commands entered, accessible by pressing the up arrow. For an example, let's say that a user entered the following three commands: show version show clock show user If that user decided that she wanted to show the version once again, she could press the up arrow key three times, and that command would show up on the CLI. Now just press the Enter key.
The Router keeps the last 10 commands you issued in its HISTORY, which is a special memory buffer that holds the "Command History." If you are using the VT-100 Emulator we talked about before, simply do the following.
• Press the UP Arrow key to go to the next most recent command. • Press the DOWN Arrow key to go back down through the previous commands (after
pressing UP arrow). If you are a poor unfortunate without VT-100, you can use these instead:
• CTRL-P takes you to the "Previous" command. • CTRL-N takes you to the "Next" commands.
Typing the command show history at the prompt gives you the list of the last 10 commands you have entered. Router# show history 1. Command One 2. Command Two 3. Command Three 4. Command Four 5. Command Five 6. Command Sixx - (with a mistake!) 7. Command Six - (fixed now) 8. Command Eight - "There is No Command 7!" 9. Command Nine 10. Command Ten You can increase the size of your History buffer by using the command terminal history size. The command below would give you 99 commands to play with. Router# terminal history size 99 Basic Router Configuration There are two ways to configure a router, manually and through the Setup script. If you have a router that has never been turned on or has recently had the configuration file erased, the router will launch the Setup script, also known as the System Configuration Dialog (much easier to say "Setup script"). Manual configuration is quicker and more flexible, but the Setup script is easier for beginners because it steps you through the whole configuration process. Let's walk through a Setup script as if we have just booted a new router that has never been configured before. Setup Mode Setup mode is intended only for minimal configuration of an out-of-the-box newly arrived router. Do not fall into the trap of using it routinely. Almost any real-world configuration will require configuration features that are not available in setup. The first part of the data capture here is from the system boot process: System Bootstrap, Version 11.0(10c), SOFTWARE Copyright (c) 1986-1996 by cisco Systems 2500 processor with 14336 Kbytes of main memory Notice: NVRAM invalid, possibly due to write erase. F3: 8022188+98780+316356 at 0x3000060 Restricted Rights Legend Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) of the Commercial Computer Software - Restricted Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS sec. 252.227-7013. cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706 Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 11.2(18), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Mon 05-Apr-99 20:23 by jaturner Image text-base: 0x03040270, data-base: 0x00001000 cisco 2500 (68030) processor (revision N) with 14336K/2048K bytes of memory. Processor board ID 06160684, with hardware revision 00000000 Bridging software. SuperLAT software copyright 1990 by Meridian Technology Corp). X.25 software, Version 2.0, NET2, BFE and GOSIP compliant. TN3270 Emulation software. 1 Ethernet/IEEE 802.3 interface(s) 2 Serial network interface(s) 32K bytes of non-volatile configuration memory. 16384K bytes of processor board System Flash (Read ONLY) Note that we have been given a notice that NVRAM is invalid. This is not a problem since this router has never been configured. All it means is that NVRAM is empty, and there is no configuration to run from. That being the case, the Cisco router defaults to running the Setup script. As the system configuration dialog prompts you, there will always be a default answer to the question being asked in [brackets]. If this is the answer you want, you can just hit the Enter key. Let's continue: Notice: NVRAM invalid, possibly due to write erase. --- System Configuration Dialog --- At any point you may enter a question mark '?' for help. Use ctrl-c to abort configuration dialog at any prompt. Default settings are in square brackets '[]'. Would you like to enter the initial configuration dialog? [yes]: y First, would you like to see the current interface summary? [yes]: y Any interface listed with OK? value "NO" does not have a valid configuration Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned NO unset up up Serial0 unassigned NO unset down down Serial1 unassigned NO unset down down Configuring global parameters: Enter host name [Router]: Router
The enable secret is a one-way cryptographic secret used instead of the enable password when it exists. Enter enable secret: cisco The enable password is used when there is no enable secret and when using older software and some boot images. Enter enable password: cisco2 Enter virtual terminal password: cisco Configure SNMP Network Management? [yes]: n Configure LAT? [no]: n Configure AppleTalk? [no]: n Configure DECnet? [no]: n Configure IP? [yes]: y Configure IGRP routing? [yes]: n Configure RIP routing? [no]: y Configure CLNS? [no]: n Configure IPX? [no]: n Configure Vines? [no]: n Configure XNS? [no]: n Configure Apollo? [no]: n Configure bridging? [no]: n Let's summarize what the Setup script has asked and told us so far. The first thing it asked is if we want to enter the Setup script. Then the script asked us if we'd like to see an interface summary. This is not a necessary evil on a 2500, but could be useful with a 3600 or higher router that has a flexible configuration. Now the Setup script asked us for the router name. This will be the name of the router that you see at the IOS prompt. Do not confuse this with a DNS name -- this router name will be locally significant only. Next it asked us for the enable secret and the enable password. The reason the Setup script does this is stated in its block of text above, that some older software images cannot understand the encryption used on enable-secret passwords. This problem is prevalent in cases where people or businesses are using older routers that have older IOS images in the boot ROMs of their routers. Next we will be prompted for the virtual terminal password, which is long hand for "Telnet password." Configure SNMP, LAT, AppleTalk, DECnet, CLNS, IPX, XNS, Apollo, bridging are all other routable protocols that can be configured through the Setup script. For this example, we are only going to set up IP with RIP routing protocol. Now we will move on to configuring the physical interfaces on the router: Configuring interface parameters: Configuring interface Ethernet0: Is this interface in use? [yes]: y Configure IP on this interface? [yes]: y IP address for this interface: 192.168.1.1 Number of bits in subnet field [0]: 0 Class C network is 192.168.1.0, 0 subnet bits; mask is /24 There is a statement here in the Setup script that sometimes causes confusion. The question is the number of bits in the subnet field. This is not the same as the subnet mask! As shown above, the IP address for the interface is an address in a Class C network (192.168.1.0). The Setup script asks us for the number of bits in the subnet field. This means anything beyond the normal Class C mask of 24 bits or 255.255.255.0. If we were to decide that we wanted to subnet this
network with a subnet mask of 255.255.255.192 (equivalent to 26 bits), we would respond to that question with the number 2. For another example of this, we could say that we entered an IP address of 10.1.1.1, and we wanted it subnetted with the same size network that a Class C network has. This mask would be 24 bits, or 255.255.255.0. Since 10.1.1.1 is an address in a Class A network, the Setup script would consider the network mask to be 8 bits or 255.0.0.0. If we wanted the 24-bit mask, we would respond to this subnet field question with the answer 16. 8+16=24, and that gives us the 255.255.255.0 subnet mask. Subnet masking is covered in more detail in the CCNA Tutorial on IP Addressing. Now, back to the configuration: Configuring interface Serial0: Is this interface in use? [no]: y Configure IP on this interface? [no]: y Configure IP unnumbered on this interface? [no]: n IP address for this interface: 192.168.2.1 Number of bits in subnet field [0]: Class C network is 192.168.2.0, 0 subnet bits; mask is /24 Configuring interface Serial1: Is this interface in use? [yes]: n The following configuration command script was created: hostname Router enable secret 5 $1$gTpr$wimCV1ieyQAMEP/vfkEeF1 enable password cisco2 line vty 0 4 password cisco no snmp-server ! no appletalk routing no decnet routing ip routing no clns routing no ipx routing no vines routing no xns routing no apollo routing no bridge 1 ! interface Ethernet0 ip address 192.168.1.1 255.255.255.0 no mop enabled ! interface Serial0 ip address 192.168.2.1 255.255.255.0 no mop enabled ! interface Serial1 shutdown no ip address ! router rip network 192.168.1.0
network 192.168.2.0 ! end Use this configuration? [yes/no]: y Building configuration... Use the enabled mode 'configure' command to modify this configuration. Now we are done with the Setup script, and the router has entered the configuration commands to setup the router the way we specified. All that is left now is to reboot the router, and we are done. After you answer "yes" to the "Use this configuration?" question, a bunch of stuff will happen. This is okay. What is happening is that the router is doing a quick reset and implementing the configuration you just entered. Press RETURN to get started! %LINK-3-UPDOWN: Interface Ethernet0, changed state to up %LINK-3-UPDOWN: Interface Serial0, changed state to down %LINK-3-UPDOWN: Interface Serial1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down %LINK-5-CHANGED: Interface Serial0, changed state to down %LINK-5-CHANGED: Interface Serial1, changed state to administratively down %SYS-5-RESTART: System restarted -- Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 11.2(18), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Mon 05-Apr-99 20:23 by jaturner At this point, the router will appear to be hung up, but don't worry, it's just waiting for you to push it along. Press the Enter Key here and you will see the router prompt show up. If you followed the configuration above, notice the router prompt when you do hit the Enter key, it should look like this: <cr> Router> Manual Router Configuration Right after running the Setup script, or whenever you need to change your router's configuration, the best way to get the most out of a Cisco router configuration is to do it manually via the CLI and config mode. Let's pretend that we didn't go through the Setup script as shown in the last section. Through our terminal emulation program, we will see the router boot up just like before. When we get the prompt asking if we'd like to enter the initial configuration dialog, we can simply type "n" as shown below and then press the Enter Key. The router will ask us if we want to terminate autoinstall. Our answer to this will be "yes." If we were to say "no," the router would spend a lot of time looking for configuration files from network servers. (We'll discuss this more in a later section.) As shown in the Setup script instructions, another way to get out of the Setup script is to just press [Ctrl-c] at any point in the script. Notice: NVRAM invalid, possibly due to write erase. --- System Configuration Dialog ---
At any point you may enter a question mark '?' for help. Use ctrl-c to abort configuration dialog at any prompt. Default settings are in square brackets '[ ]'. Would you like to enter the initial configuration dialog? [yes]: n Would you like to terminate autoinstall? [yes]: y Press RETURN to get started! %LINK-3-UPDOWN: Interface Ethernet0, changed state to up %LINK-3-UPDOWN: Interface Serial0, changed state to down %LINK-3-UPDOWN: Interface Serial1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down %LINK-5-CHANGED: Interface Ethernet0, changed state to administratively down %LINK-5-CHANGED: Interface Serial0, changed state to administratively down %LINK-5-CHANGED: Interface Serial1, changed state to administratively down %SYS-5-RESTART: System restarted -- Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 11.2(18), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Mon 05-Apr-99 20:23 by jaturner As you can see here, a couple things happen when you exit from the Setup script. Nothing that happens here is very complicated or problematic. This is a simple system reset that occurs as the router tries to boot. You'll notice above that the router tells you to Press RETURN to get started! This means that the router will wait for your input to present you with a prompt. Once you exit the Setup script, you can manually configure the router. In order to configure the router via the CLI, you must do three things: first login to user mode, then login to privileged mode, and then enter configuration mode. After exiting the Setup script (and pressing Enter), you will be presented the Router> prompt. This is the prompt of the user exec mode and it's like the DOS prompt on a PC. As described in an earlier section, user exec mode has limited functionality and no configuration access. From this prompt, you must enter the command enable, or in CLI shorthand, en. Once you have done this, you will be presented the Router# prompt (privileged exec mode prompt). Since we are looking at this as if there were no previous configuration on the router, we shouldn't be prompted for a password because currently there are no passwords associated with logging in or entering enable mode. We will cover that after we finish the initial configuration section. Now that we have entered privileged mode, we can proceed to configuration mode, also known as config mode. From the Router# prompt, type in the command configure terminal, in shorthand, conf t, and press the Enter key. In config mode, you will see the Router(config)# prompt. From this config prompt, we can enter any configuration commands to setup the router to fit our needs. If you remember the Setup script that we went through, we will show the exact same configuration, but step by step as we go through the initial manual configuration. In the previous configuration, we configured the router to do the following:
• Set router name • Set passwords • Configured interfaces and IP addressing (for Ethernet 0 and Serial 0 interfaces) • Configured RIP routing for IP • Committed the configuration to memory (NVRAM)
Now, we will do this via the CLI and router config mode. To begin, once again, we will login to the router, enter enable mode and then begin config mode. The following sequence will get us to this point: <cr> Router> en Router# conf t Router(config)# Now that we are in config mode, we will run through the configuration items listed above. In each of these command sequences, you will see an abbreviated version of the command. If you'd like to see the full text version of the commands, remember that you can hit the [tab] key to fill in the rest of the command. In order to rename the host, you need to use the command host followed by the name you want for the router. In this case we picked "Router". To set the router name we follow this sequence: Router(config)# host Router Router(config)# Setting Router Passwords Security is important on a router. Remember that you can access a router from connections other than the console. There are five separate passwords you can set to protect your router: Console: protects the Console Port Enable Password: guards the use of the Enable mode super-user status Enable Secret: an encrypted secret form of the above (better!) VTY: protects against unauthorized Telnet port logons Auxiliary: protects the AUX Port (for your modem) The Console Password As we continue with our manual reconfiguration tasks, your very next step should be to set the password for the Console Port. Starting from the Router(config)# prompt you need to put in the following series of commands to create the password. Router(config)# line console 0 Router(config-line)# login Router(config-line)# password cisco Router(config-line)# Ctrl-Z Router# Notice that the Router prompt changes to Router(config-line) when you put in the line console 0 command. It's important to know that line is a major command that puts you into "sub-command" mode. This is similar to another "sub-command" mode used for configuring interfaces Router(config-if). Only in the Router(config-line)# mode can you configure individual "lines." Also note that the Ctrl-Z (also written ^Z) ends your session, and brings you back up to the Router# prompt. The Enable Password and Enable Secret Password There are two different passwords that allow access to privileged mode, the enable password and the enable secret password. The purpose of the enable password is to prevent unauthorized access to the privileged mode and configuration mode of the router. You can set this password from configuration mode like this: Router(config)# enable password cisco2
The "enable secret" password is a "one-way cryptographic secret password." In other words, once you put in the plain text password, the Cisco IOS takes the text and encrypts it so that no one, not even you, can ever read it again. This is why it is good advice not to forget your enable secret password. Also, the router doesn't like the enable secret to be the same as the enable (as we'll see soon). You can set this password from configuration mode like this: Router(config)# enable secret cisco While you can configure both of these passwords, you can only use one of these passwords at a time on your router. If you choose the enable secret password (and you should because it uses an encryption algorithm to keep your password secure), the enable password will not be used. Even though you may have set your enable password and see it in your configuration file, if you also set the enable secret password your enable password will be ignored. The only time you should rely only on the enable password is if you are working with an old version of the Cisco IOS (prior to version 10.3) or if your router has an older boot ROM that doesn't recognize the enable secret command. In other words, if your router is new, use the enable secret password. If you entered the same password for enable secret as you did for enable password, you would receive the following message: Router(config)#enable secret cisco The enable secret you have chosen is the same as your enable password. This is not recommended. Re-enter the enable secret. The IOS gives you this warning because your enable password is listed in clear text right in your configuration file, which anyone can see from user exec mode. If your enable secret password is the same as your enable password and your enable password is shown in your configuration file, you've essentially given away your enable secret password to anyone who guesses that they may be the same. The VTY Password VTY ports are not real ports. In other words, you won't find a port on the back of your router labeled VTY. They are also called "Virtual Ports" and they wait for a remote connection, usually using Telnet, to log in. So the virtual terminal password is essentially the same as a Telnet password. Configuring the VTY password is very similar to configuring the Console. The only difference is that there are five VTY virtual ports, which are named 0, 1, 2, 3, and 4. You can use the shortcut 0 4 (a zero, a space, and 4) to set all five passwords at the same time. In order to set the virtual terminal (vty) password, you must enter the following configuration commands: Router(config)# line vty 0 4 Router(config-line)# pass cisco Router(config-line)# exit Router(config)# Notice we see the config-line text after the router prompt. When you see this, the commands you are entering here are specific to a certain line interface. If you are in an interface or line configuration mode, you can get back out to the global config mode by typing in exit and pressing Enter instead of using CTRL-Z (^Z). By the way, it is not necessary to exit back to the global config mode every time you are finished configuring one interface. You can travel from one interface to another by giving the next interface command. The Auxiliary Line Password You can set the Auxiliary Line Password for external modem connections by entering the following commands: Router# config t Router(config)# line aux 0 Router(config-line)# login Router(config-line)# password cisco3 Router(config-line)# Ctrl-Z Router#
And now your Router has a password protecting the AUX port. Now that you have successfully entered all the passwords your router needs, this is a good time to do a quick practice session. To leave the enable mode you need to type in the word disable (the opposite of enable, the command that got you into this mode). Remember again that enable mode is formally called "Privileged Exec Mode." Router# disable This will leave you at the User Exec Mode prompt, Router >. Now you are going to leave User Exec Mode by typing quit or exit: Router> exit (or type quit) You will now see the friendly message: Press ENTER to get started. At this point press the ENTER key. The next thing you will see on the screen will be: User Access Verification Password (please type in your User Password here) Router> You quickly recognize the "Router >" as the User Exec Mode prompt. Now type in your Enable Secret Password. Router> cisco2 If you typed in your enable Secret Password correctly, you should now be in the Privileged Exec Mode. Router# Congratulations! You have now set up your router, created passwords, and successfully logged back into it. Now don't forget your passwords! Configuring an IP Address As we continue with the manual reconfiguration of our router, we will now configure two interfaces: Ethernet0 and Serial0. To configure IP routing and then configure Ethernet0 and Serial0 interfaces with IP addresses we enter the following: Router(config)# ip routing Router(config)# int e0 Router(config-if)# ip add 192.168.1.1 255.255.255.0 Router(config-if)# no shutdown Router(config-if)# int s0 Router(config-if)# ip add 192.168.2.1 255.255.255.0 Router(config-if)# no shutdown Router(config-if)# You can see that we entered commands for the Ethernet0 and Serial0 interfaces without having to exit back to the global config mode between interface commands. Notice that we are in the global config mode when we turn on IP routing. However, turning on IP routing is not necessary on any Cisco router, because IP routing is enabled by default. We enter the interface "subcommand" mode with int e0 (interface Ethernet0). We must specify the subnet mask when entering an IP address. Notice that we are using the full sense of the 24-bit mask with three 255s, where each 255 represents 8 bits. Remember we entered a zero when we ran the Setup script, because the Setup script uses zero to represent subnet mask defaults, and in this case, the default subnet mask for this Class C network is 24 bits. Notice the use of the command no shutdown. Use this command to change the state of the interface to up. Remember that an interface is always "shut down" by default and it is a good idea to enter no shutdown just to be on the safe side. If your Ethernet 0 interface is plugged in correctly and you enter a no shutdown, you will see the following appear on the screen that tells you that your newly configured Ethernet0 interface is working: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up %LINK-3-UPDOWN: Interface Ethernet0, changed state to up
Since we enabled IP routing, we must turn on some type of routing protocol for IP route tables to propagate through the network. One such routing protocol is RIP, Routing Information Protocol. To enable RIP for IP, we enter: Router(config)# router rip Router(config-router)# network 192.168.1.0 Router(config-router)# network 192.168.2.0 Router(config-router)# In the above example, RIP is advertising two networks, 192.168.2.0 and 192.168.1.0, so other connected routers can build routing tables. Note: Now that we finished reconfiguring the most important parts of the router's configuration, let's learn about other configuration features that are either necessary for router maintenance or act as enhancements for day-to-day operations. Configuring Banners An IOS banner is used to give information to users or administrators when they log in to a router via a terminal line. We are going to cover three types of banners: • MOTD (Message Of The Day) • Login • Exec An MOTD banner is sent to a terminal as soon as the terminal's connection becomes active. A login banner is also sent to a terminal when a terminal becomes operative. The login banner is displayed after an MOTD banner if there is one. An exec banner is displayed to a terminal immediately after a person has successfully logged in. We use the global configuration mode command banner to create a banner. Router# banner {exec | login | motd} dc message dc The argument dc is a delimiting character. The delimiting character can be any character as long as it is not part of the message, and it must be the same at the end as it is at the beginning of the message. The banner command should include one of the arguments exec, login, or motd. All three types of banners can be created by issuing the banner command three times, once for each type. To create a banner, type the command including the first delimiting character, and press Enter. On the next blank line type the rest of the banner message. Banners can have multiple lines (that's the reason for using a dc). When you have finished with the banner message, just type the delimiting character and press Enter again. In the following three examples we will use the percent sign (%) as the delimiting character. Everything between the percent signs is the banner. When the configuration is displayed, IOS uses its own standard delimiter (^C). Router(config)# banner motd % Enter TEXT message. End with the character '%'. This is the motd banner. Remember to meet in cafeteria for Norman's party. % Router(config)# banner login % Enter TEXT message. End with the character '%'. This is the login banner. You have accessed a private system. Unauthorized access is prohibited. % Router(config)# banner exec % Enter TEXT message. End with the character '%'. This is the exec banner. We just added a new IOS to all routers. % Router(config)#
Committing Configuration Changes to NVRAM All configurations entered through the configuration mode are done dynamically, and stored in regular RAM (volatile RAM) as the current running configuration. Now that we are done with the configuration, we must exit config mode and save our changes. To exit configuration mode you Note: Notice the from/to syntax of the copy command. This is a critical concept to understand, and there can be serious repercussions if the command is written incorrectly. With copy run start you are telling the IOS that you want to copy from the running-config to the startup-config. This will effectively save the configuration you've been changing to the more permanent startup-config in NVRAM. However, if you were to type copy start run, you are telling the IOS that you want to copy from the startup-config to the running-config. This restores your running-config to the way it looked when your router booted (or to the most recently saved startup configuration) erasing any changes you've made to your running-config. So remember, with the copy command the syntax is always from/to! can either enter the command end, or press the [Ctrl-z] key combination. Later in the paper we'll discuss other examples of the copy command where the from/to syntax still applies. In order to commit these changes to non-volatile RAM (NVRAM) so that they will be enabled every time the router is restarted, we must "write" this running configuration to memory. Remember that the saved configuration in NVRAM is called the "Startup Configuration." Previous to IOS version 10.3, there was only one command to enter, write memory, or wr mem. In IOS versions 10.3 and later we can use either the old command wr mem or the newer command copy running-config startup-config, with the shorthand version being copy run start. This newer command is preferred by Cisco and is the one you will see most often in textbooks, courses, and exams. Here are two ways you can exit configuration mode and commit your changes to NVRAM: Router(config)# end Router# wr mem or Router(config)# ^Z (just pressed [ctrl-z]) Router# copy run start When you commit the running config to memory on a 2500 series router, you will have a little pause while the router saves the config into NVRAM. When it is done, the router will respond to you with the congenial message Building configuration. . .[OK]. To summarize the whole configuration we have just gone through, here are all the commands to accomplish the above without interruptions: <cr> Router> en Router# conf t Router(config)# host Router Router(config)# ena sec cisco Router(config)# ena pass cisco2 Router(config)# line vty 0 4 Router(config-line)# pass cisco Router(config-line)# exit Router(config)# Router(config)# ip routing Router(config)# int e0 Router(config-if)# ip add 192.168.1.1 255.255.255.0 Router(config-if)# no shut Router(config-if)# int s0
Router(config-if)# ip add 192.168.2.1 255.255.255.0 Router(config-if)# no shut Router(config-if)# router rip Router(config-router)# network 192.168.1.0 Router(config-router)# network 192.168.2.0 Router(config)# ^Z (just pressed [ctrl-z]) Router# copy run start Building configuration... [OK] Now that we are done with creating the configuration and saved it, we can view it by entering the command show running-config or sh run. Here's what it will look like: Router# sh run Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname Router ! enable secret 5 $1$r.0I$4MbN8jBZLXq9siy9R1ELR1 enable password cisco2 ! ! interface Ethernet0 ip address 192.168.1.1 255.255.255.0 ! interface Serial0 ip address 192.168.2.1 255.255.255.0 no fair-queue ! interface Serial1 no ip address shutdown ! router rip network 192.168.1.0 network 192.168.2.0 ! no ip classless ! ! line con 0 line aux 0 line vty 0 4 password cisco login ! end If your configuration looks like this, GOOD JOB! Configuring Clock Rate
We'll end this chapter on Basic Router Configuration with a brief description of what clock rate is and how to configure it.
Figure 7. Diagram of Two Routers Connected to Note: Probably one of the most confusing things about building a network is trying to figure out how everything connects together. While this is primarily a physical cabling issue outside the scope of this paper, it is important to understand that the way you physically connect your equipment can affect the way you need to configure your routers. Devices that communicate over a serial interface are either DCE or DTE. Some devices are always DCE like modems, CSU/DSUs, and multiplexers. Data terminals are always DTE (thus the name). However, routers, hubs, and switches can be either DCE or DTE. Believe it or not, the end of the serial cable that's plugged into the router determines whether it is DCE or DTE. Generally, the female end of the serial cable makes the router the DCE. Likewise, the male end of the serial cable makes the router the DTE. If the router is the DCE, it needs to set the clock rate for the circuit. This shows that physical connections can sometimes impact your router configuration. For a more in-depth explanation of what serial cables to use in what circumstances, see "Serial Cables."( is not associated with Cisco.) Each Other Clock rate is the command you enter to supply the clock signal that paces the communications on a circuit. For instance, imagine that we wanted to connect two routers together as in Figure 7. In this case, we will connect the routers together with a serial cable (for more information on making connections with serial cables, see "Let's Connect: Your Serial Cable Guide". ( is not associated with Cisco.) If we wanted this link to simulate a 56K circuit, we could enter the following commands in Router2: Router2# config t Router2(config)# int s0 Router2(config-if)# clock rate 56000 Router2(config-if)# [ctrl-z] Because Router2 is providing the clock for the circuit between itself and Router1, it is known as the Data Communications Equipment (or Data Circuit-terminating Equipment (DCE) depending on how you want to think about it). Router1 accepts this clock rate from Router2, which makes Router1 the Data Terminal Equipment (DTE). Basic Router Maintenance and Troubleshooting Backing up Router Configuration Files There are several ways to back up the configuration files you've worked so hard to create. The safest and most common way to do these backups is by using a Trivial File Transfer Protocol (TFTP) server. (This is different from the FTP protocol.) The TFTP server serves as a central configuration repository. This one location can store the router configurations of all the routers in your network. This can be handy in the case of a router failure that causes it to lose its configuration or even if the router itself breaks and you have to get a replacement from Cisco. In these instances, it is possible to retrieve the configurations from a TFTP server and quickly have your router running with your most recently saved configuration.
A TFTP server can run on almost any computer with nearly every operating system. If you are interested in trying out a simple TFTP server for learning purposes, you can get one from the Cisco web site without having to log in. ( is not associated with Cisco.) This TFTP server will run on Windows 95/98/NT and is very simple to install and setup. Of course there are other shareware TFTP server programs on the Web that you can try. In order to save the configuration of your router to the TFTP server, you must first have some sort of network connectivity that will allow you to get to the TFTP server. The computer with the TFTP server running on it needs to be on the same Ethernet segment as your router. The easiest way to accomplish this is to have them both connected to a hub. This means that your router's AUI port will need an Ethernet transceiver with an RJ45 port. With this in place, you can save and retrieve configuration files to and from the TFTP server. Note In addition to storing router configurations on a central server, you can also use a core router in your network as a TFTP server. For example, consider a typical hub-and-spoke network configuration that has a 7500 series router at the hub. On this central router you could outfit the router processor card with a decent size PCMCIA Flash card and use this as a storage compartment for all remote site router configuration files. Also, when each router boots each could be configured to retrieve its configuration from that 7500 series router, acting as a TFTP server. If the TFTP server IP address is 192.168.1.100, the procedure to save the configuration file to the TFTP server is as shown below. We first want to ping the IP address of the TFTP server to ensure that there is connectivity between the router and the server, and then we use the command copy running-configuration tftp or copy run tftp. Router# ping 192.168.1.100 Type escape sequence to abort. Sending 5 100-byte ICMP echos to 192.168.1.100, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms Router# copy run tftp Host or network configuration file [host]? <cr> Address of remote host [255.255.255.255]? 10.1.1.1 Name of configuration file{}? My-config <cr> Now here's what the commands look like if you wanted to retrieve your configuration from the TFTP server to your router. Router# copy tftp run Host or network configuration file [host]? <cr> Address of remote host [255.255.255.255]? 10.1.1.1 Name of configuration file{}? My-config <cr> Configure using My-config from 10.1.1.1? [confirm] <cr> Loading My-config....from 10.1.1.1 (via Ethernet0): [OK - 717/32732] Router# Building configuration... This just copies a saved configuration from the TFTP server to your currently running configuration, not your startup configuration. You can either do a copy run start to save this configuration to your startup configuration or you can load a saved configuration copy from the TFTP server directly to your startup configuration located in NVRAM. However, in order for this configuration to become your active configuration, you would then have to copy the startup configuration to the running configuration by reloading your router.
Router# copy tftp start Host or network configuration file [host]? <cr> Address of remote host [255.255.255.255]? 10.1.1.1 Name of configuration file [My-config]? <cr> Configure using My-config from 10.1.1.1? [confirm] <cr> Loading My-config ... Note Instead of reload, you could use the command copy start run without requiring a reset. The problem with copy start run is that it actually merges the two configuration files and doesn't make a clean copy. This is not recommended unless you're sure you know what you're doing. Another alternative to the reload command is to use the command conf mem (short for configure memory), which executes the commands stored in NVRAM. Now you need to put the saved configuration in startup back into the running configuration by resetting the router. The command to do this is reload, and it's this simple. Router# reload And now you know two methods of backing up your router's configuration files. Why would you want to do this? Well, it is good for resetting the router back to square one if you make a mistake. It is also good for doing a practice Lab a second time. Which brings us to the ultimate of all configuration commands: erase startup-config. This command erases your NVRAM so that the next time you reload, you have a completely blank router. You can use this command to practice the Setup Script covered in an earlier section. Do Note: Another way you can back up your router configuration files is to save them to your router's Flash memory. Configuration files are relatively small and there is usually plenty of Flash space on a new router. To see how much Flash space your router has and the names and number of files located there, type show flash in the global configuration mode. You can save your configurations to Flash by typing copy run flash or copy start flash depending on which configuration files you wish to save. The IOS will prompt you to name the file you are about to save. not use this on a production router, as this will bring down your network and likely your job. While saving your configuration files to Flash is an option if you don't have a TFTP server, a TFTP server is a safer backup method. Since it is located on a device other than your router it is still available in case something catastrophic happens to your router. Also, the files stored on a TFTP server can be included in regular network backups. Backing Up IOS Software Images You can also save your router's Flash memory, where the Cisco IOS is stored, to a TFTP server. The following shows the commands to copy Flash to the TFTP server. Notice that you are asked for the IP address of the TFTP server and the name of the file that contains the Cisco IOS on your router. You can find the name of this file by using the show flash command in the global configuration mode. Router# copy flash tftp File Length name/status 11233404 c2500-ajs40-1_113-5_T.bin [11233468 bytes used, 5543748 available, 16777216 total] Address or name of remote host [255.255.255.255]? 10.1.1.1 Source file name? c2500-ajs40-1_113-5_T.bin Destination file name[c2500-ajs40-1_113-5_T.bin]? <cr> You can do it the other way and copy Flash from the server to the router. Router# copy tftp flash **** NOTICE **** Flash load helper v1.0
This process will accept the copy options and then terminate the current system image to use the ROM based image for the copy. Routing functionality will not be available during that time. If you are logged in via Telnet, this connection will terminate. Users with console access can see the results of the copy operation. ---- ******** ---- Proceed? [confirm] <cr> System Flash directory: File Length Name/status 1 8121000 c2500-js-l.112-18.bin [8121064 bytes used, 8656152 available, 16777216 total] Address or name of remote host [255.255.255.255]? 192.168.1.100 Source file name? c2500-js-l.112-18.bin Destination file name [c2500-js-l.112-18.bin]? <cr> Accessing file 'c2500-js-l.112-18.bin' on 192.168.1.100... Loading c2500-js-l.112-18.bin from 192.168.1.100 (via Ethernet0): ! [OK] Erase Flash device before writing? [confirm] <cr> Flash contains files. Are you sure you want to erase? [confirm] <cr> Copy 'c2500-js-l.112-18.bin' from server as 'c2500-js-l.112-18.bin' into Flash WITH erase? [yes/no] y 00:10:59: %SYS-5-RELOAD: Reload requested %SYS-4-CONFIG_NEWER: Configurations from version 11.3 may not be correctly understood. %FLH: c2500-js-l.112-18.bin from 192.168.1.100 to Flash ... System Flash directory: File Length Name/status 1 8121000 c2500-js-l.112-18.bin [8121064 bytes used, 8656152 available, 16777216 total] Accessing file 'c2500-js-l.112-18.bin' on 192.168.1.100... Loading c2500-js-l.112-18.bin from 192.168.1.100 (via Ethernet0): ! [OK] Erasing device... eeeeeeeeeeeeeeeeeee ...erased Loading c2500-js-l.112-18.bin from 192.168.1.100 (via Ethernet0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!! (There may be many more or fewer of
these ! marks on your screen.) [OK - 8121000/16777216 bytes] Verifying checksum... OK (0x5996) Flash copy took 0:04:10 [hh:mm:ss] %FLH: Re-booting system after download (Here the router reboots like normal.) You may have noticed that the router had to reboot in order to copy the image into Flash. This is okay, but we should investigate the reason why this happens. Because this is a 2500 series router that runs the IOS straight from Flash, copying a file to Flash while the IOS is running from Flash will not work. In order to make software copies and updating as painless as possible, Cisco created the Flash Load Helper. The Flash Load Helper assists in setting the configuration register to run from ROM, reboots the router, copies the image into Flash, changes the configuration register back, then reboots the router again. The Flash Load Helper was an optional feature in Cisco routers until software version 10.3. If you happen to be working with a router with earlier software, you must manually set the configuration register to boot with the default software in ROM, then perform the image copy, then change the configuration register back and reboot the router. We'll discuss the configuration register later in the paper. Most other router models run the IOS from RAM, so this may not be an issue if you are using another router model. Show Commands While making changes to your router's configuration, it is a good idea to frequently monitor your work before going on. The privileged mode is where we can examine our work by using certain verification (show) commands. After performing several manual configuration tasks either in the global configuration mode or other deeper "subcommand" configuration modes, you should slip back into the privileged mode to check things out. If you're at the Router# prompt, just type exit, and that will send you back to the Router> prompt, which is where you need to be to use the verification commands. We will examine the following verification commands and the information they provide. The show command is the portal that allows us to view anything we want on the router. If you'd like to see what show options are available, type show ? at the exec prompt. We will discuss the more common show commands. It's useful to know older commands from Cisco IOS version 10.3 or lower that are equivalent to those in recent software versions. Table 2 displays equivalent commands between newer and older software version. Table 2. Equivalent Commands
Higher than Version 10.3 Version 10.3 or lower
Show startup-configuration Show configuration
Show running-configuration Write term
Erase startup-configuration Write erase
Copy running-config startup-config Write mem
Most show commands can be viewed from the regular User Exec mode. Some show commands can only be viewed from the Privileged Exec (Enable) mode. If you've been busily configuring interfaces and protocols in config mode and forget to change back to the Router# or Router> prompt, using a show command will not work. None of the show commands can be used from config mode. This will just give you an error, and you will feel very silly. If you type in the command show, a space, and then a question mark at the Enable Mode "Router#" prompt, the Help function will give you a long list of show commands.
Router# show ? show access-expression show access-list show apple interface show apple route show appletalk show atm show bridge show cam show cam dynamic show cdp neighbors show config ... ...and so on going down through the entire alphabet. Luckily, you do not need to memorize all these right away for the tests. There are, however, two important show commands that allow you to see your router's full configurations and you'll want to remember: show running-configuration and show startup-configuration. show startup-config shows you the configuration commands stored in the Router's NVRAM, the place where configurations live when the power is off. The show running-config command shows you the configuration as you have changed it since turning on the router. We used this command earlier in the paper to show the changes we made to the router. This command shows the configuration that is actually running right now on your router, in RAM. For security reasons, these commands are not available from the user prompt. If you do a show run or show start from the Router> prompt, you'll get an error message. The reason for this is that the enable password (but not the enable secret password) is shown in clear text by these commands. Basic Show Commands You are apt to use most or all of the information in these commands when doing routine troubleshooting. Show Version The show version command gives you information on the version of the Cisco Internetwork Operating System that your router is using. It also gives you lots of other basic information such as how long the router has been up, how the system was started, what processor your router uses, how much memory your router has, and from where the system image file was loaded. show version will also show you what interfaces the router has. router# show version Cisco Internetwork Operating System Software IOS (tm) 3000 software (IGS-I-L, Version 11.1(11) RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by Cisco Systems, Inc. Compiled Tue 24-Jun-97 12:20 by jaturner Image text-base: 0x0301E644, data-base 0x00001000 ROM: System Bootstrap, Version 11.0(10c), SOFTWARE ROM: 3000 Bootstrap Software (IGS-BOOT-R), Version 11.0(10c) RELEASE SOFTWARE (fc1) Router uptime is 12 minutes System restarted by power-on System image file is "Flash:igs-i-l.110-16", booted via Flash cisco 2500 (68030) processor (revision N) with 2048K/2048K bytes of memory. Processor board ID 06267777, with hardware revision 00000000
Bridging software X.25 software, Version 2.0, NET2,, BFE and GOSIP compliant. 1 Ethernet/IEEE 802.3 interface. 2 Serial network interfaces. 32K bytes of non-volatile configuration memory. 8192K bytes of processor board System Flash (Read ONLY) Configuration register is 0x2102 Show Interfaces The show interfaces command is like the Swiss Army knife of troubleshooting. It gives you information on all the interfaces in your router. Since the interfaces are where all the real work takes place, being able to see what they are doing is very helpful. In the example below, we are using a Cisco Router 2503, which includes two additional ISDN ports (BRI0:1 and BRI0:2). One of the most important ways to check the health of a Cisco router interface is on the first line of this output. In this case, the serial interface is administratively down, and the line protocol is down. This means that the interface is in "shutdown" mode, and whoever is configuring this router wants that interface to remain shut down. If that line were to say that the interface was down instead of administratively down, that means that we have a problem with the physical connectivity on that line. Another basic status we could get on this interface is that the interface is up, but the line protocol is down. A lot of times this means that the OSI model Layer 1 is up but Layer 2 is down. Yet another status is that the line is up and the line protocol is up. This is how it should be, and it means everything is okay on that interface. Router> show interfaces BRI0 is administratively down, line protocol is down Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 5 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions BRI0:1 is administratively down, line protocol is down Hardware is BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, Encapsulation HDLC, loopback not set reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set
Show Protocols A protocol is an agreed-upon set of rules for speaking to others. It's sort of like having a conference call and everyone agreeing to speak German. The show protocols command lets you know if everyone is speaking properly. If they are not, then the router will tell you, "Line Protocol is down." Even if the interface is up, if the line protocol isn't working, nothing works. All of our interfaces will be listed as administratively down since we have not yet turned any of them on. In fact, since we are only doing the basic setup of one router in this tutorial, we don't actually have anyone else with whom to speak. Router> show protocols Global values: Internet Protocol routing is enabled BRI0 is administratively down, line protocol is down BRI0:1 is administratively down, line protocol is down BRI0:2 is administratively down, line protocol is down Ethernet0 is administratively down, line protocol is down Serial0 is administratively down, line protocol is down Serial1 is administratively down, line protocol is down Serial2 is administratively down, line protocol is down Serial3 is administratively down, line protocol is down Show Flash The show flash command tells you how many bytes are used and available in Flash memory and what files are stored there. Router> show flash System Flash directory: File Length Name/status 1 11780820 12-04T.bin [11780884 bytes used, 4996332 available, 16777216 total] 16384K bytes of processor board System Flash (Read ONLY) Advanced Show Commands These commands do give some information that may be useful on a day-to-day basis, but much of the information they show is meaningful only to Cisco technical support. Technical support has access to router code, detailed internal data structures, and other information not provided to customers. This sort of confidential information is needed to understand the full meaning of advanced displays. Show Memory The show memory command shows what memory is allocated by the management system for which purposes. There are two memory charts that get shown by the command: a Summary and a Detailed Block by Block memory chart. Router> show memory Summary: Head Total(b) Used(b) Free(b) Lowest(b) Largest(b) Processor EA90C 5326580 2056220 3270360 3270360 3231192 I/O 600000 2097152 465264 1631888 1579032 1631720 A Detailed Block-by-Block memory chart: Allocator PC Summary for: Processor pc=0x031FDE54, size=000963416, count=000056, name=List Elements pc=0x031D8060, size=000462508, count=000312, name=*Packet Data* pc=0x03217BAE, size=000287992, count=000068, name=Interrupt Stack
pc=0x031D8028, size=000178496, count=000312, name=*Packet Header* pc=0x031DCDEC, size=000115040, count=000008, name=Fair Queueing pc=0x031C2BD2, size=000049196, count=000001, name=Exec pc=0x031DDBA8, size=000044660, count=000011, name=*Hardware IDB* pc=0x031957E4, size=000040840, count=000010, name=TTY data pc=0x03214150, size=000033516, count=000063, name=Process pc=0x0322E6F4, size=000032808, count=000001, name=Cfg EEPROM Copy pc=0x031DDBBE, size=000025124, count=000011, name=*Software IDB* pc=0x034A829A, size=000014468, count=000001, name=Init pc=0x034A81F4, size=000014464, count=000001, name=Init pc=0x03AA68C2, size=000013644, count=000001, name=Init pc=0x03A772B6, size=000013644, count=000028, name=ATMSIG-SHOW pc=0x031A2D10, size=000013512, count=000197, name=Parser 01:13:41: %SYS-3-CPUHOG: Task ran for 2008 msec (19/19), process = Exec, PC = 31 7A068. -Traceback= 320F2A6 317A070 318F4A4 31904A2 318F54C 31C2EBE 31C3028 31C3332 31A18F0 31B605C Linkage pc=0x031368E0, size=000012044, count=000001, name=Init pc=0x0320BCD8, size=000012032, count=000084, name=Watched Boolean pc=0x032B17D0, size=000011420, count=000001, name=DHCPD Message Workspace pc=0x0320BEE8, size=000011040, count=000064, name=Process Events --More- Right now, we are only concerned with a few of the columns in this output. The Total, Used and Free columns give us a sense of how much operating memory the router has, how much is being used right now by the processor and the I/O subsystem, and how much is free to each. The (b) on each of these columns means that this information is expressed in bytes. If you are interested in seeing how much memory each process running in the router is taking, you may want to look at the rest of the output from the sh mem command. We must warn you, this is a lot of information, and gets somewhat boring to look at. Show Processes A process is part of a program, or if it is small, it can be the entire program. It's sort of like having a troupe of jugglers: each item they toss up in the air is one process. As long as they keep them all going, everything is fine. If not, you can use show processes to do a little troubleshooting. The show processes command shows you all the active processes in the form of a chart containing the following information in columns: PID - The ID number of each process. Q - The Queue priority TY - This is the status of the process PC - Program Counter. Runtime - The amount of CPU time in milliseconds used by the process Invoked - This is the amount of time the process has been invoked. uSecs - The CPU time in milliseconds for each process invocation. Stacks - This shows both the "low water mark" / "total stack space" in bytes. TTY - Shows you which terminal controls the process. Process - Finally, this actually gives you the name of the process. Pay particular attention to the first line, which shows CPU utilization. While there are no hard and fast rules, you generally don't want a router that does dynamic routing to average much more than 50-60% of utilization over 5-minutes. Router> show processes CPU utilization for five seconds: 7%/7%; one minute: 9%; five minutes: 12%
Show Buffers A buffer is a portion of memory in which data can rest while it waits to catch the next bus out. Buffers are sort of like bus stops, but some are bigger (like a bus station); and some of them are very large, like an airport! The show buffers command lets you see the size of the small, middle, big, very big, large, and huge buffers. It also gives statistics on their usage, kind of like baseball scores. Router> show buffers Buffer elements: 500 in free list (500 max allowed) 128 hits, 0 misses, 0 created Public buffer pools: Small buffers, 104 bytes (total 56, permanent 50): 54 in free list (20 min, 150 max allowed) 87 hits, 2 misses, 0 trims, 6 created 0 failures (0 no memory) Middle buffers, 600 bytes (total 28, permanent 25): 28 in free list (10 min, 150 max allowed) 76 hits, 1 misses, 0 trims, 3 created 0 failures (0 no memory) Big buffers, 1524 bytes (total 50, permanent 50): 47 in free list (5 min, 150 max allowed) 19 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) VeryBig buffers, 4520 bytes (total 10, permanent 10): 10 in free list (0 min, 100 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Large buffers, 5024 bytes (total 0, permanent 0): 0 in free list (0 min, 10 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Huge buffers, 18024 bytes (total 0, permanent 0): 0 in free list (0 min, 4 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Interface buffer pools: Ethernet0 buffers, 1524 bytes (total 32, permanent 32): 8 in free list (0 min, 32 max allowed) 24 hits, 0 fallbacks 8 max cache size, 8 in cache BRI0 buffers, 1524 bytes (total 4, permanent 4): 3 in free list (0 min, 4 max allowed) 3 hits, 0 fallbacks 1 max cache size, 1 in cache
BRI0:1 buffers, 1524 bytes (total 16, permanent 16): 12 in free list (0 min, 16 max allowed) 12 hits, 0 fallback 4 max cache size, 4 in cache BRI0:2 buffers, 1524 bytes (total 16, permanent 16): 12 in free list (0 min, 16 max allowed) 12 hits, 0 fallbacks 4 max cache size, 4 in cache Serial0 buffers, 1524 bytes (total 32, permanent 32): 7 in free list (0 min, 32 max allowed) 25 hits, 0 fallbacks 8 max cache size, 8 in cache Serial1 buffers, 1524 bytes (total 32, permanent 32): 7 in free list (0 min, 32 max allowed) 25 hits, 0 fallbacks 8 max cache size, 8 in cache Serial2 buffers, 1524 bytes (total 8, permanent 8): 6 in free list (0 min, 8 max allowed) 6 hits, 0 fallbacks 0 max cache size, 0 in cache Serial3 buffers, 1524 bytes (total 8, permanent 8): 6 in free list (0 min, 8 max allowed) 6 hits, 0 fallbacks 0 max cache size, 0 in cache CD2430 I/O buffers, 1524 bytes (total 20, permanent 20): 10 in free list (0 min, 20 max allowed) 10 hits, 0 fallbacks Show Processes CPU Much like the memory output, the show processes cpu command contains a lot of good information but the most important part is the first line. This line shows some the running utilization of the router's CPU. This router has a 5- minute average utilization of 10%, which is not too bad. If you see a router with a 5-minute utilization of over 60%, you might want to do some serious investigating. If you see a router with a 5-minute utilization of over 95%, you may not be able to get processor time to do any investigating. Router# sh proc cpu CPU utilization for five seconds: 14%/11%; one minute: 10%; five minutes: 10% PID Runtime Invoked uSecs 5Sec 1Min 5Min TTY Process (ms) 1 92 2297 40 0.00% 0.00% 0.00% 0 Load Meter 2 1128 163 6920 1.39% 0.31% 0.27% 0 Exec 3 17676 384 46031 1.80% 0.22% 0.14% 0 Check heaps 4 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager 5 4 2 2000 0.00% 0.00% 0.00% 0 Timers 6 4 194 20 0.00% 0.00% 0.00% 0 ARP Input 7 0 1 0 0.00% 0.00% 0.00% 0 SERIAL A'detect 8 0 192 0 0.00% 0.00% 0.00% 0 IP Input 9 20 1152 17 0.00% 0.00% 0.00% 0 CDP Protocol
10 4 22 181 0.00% 0.00% 0.00% 0 MOP Protocols 11 256 11693 21 0.00% 0.00% 0.00% 0 IP Background 12 40 2301 17 0.00% 0.00% 0.00% 0 TCP Timer 13 0 1 0 0.00% 0.00% 0.00% 0 TCP Protocols 14 4 1 4000 0.00% 0.00% 0.00% 0 Probe Input 15 0 1 0 0.00% 0.00% 0.00% 0 RARP Input 16 4 1 4000 0.00% 0.00% 0.00% 0 BOOTP Server 17 20 192 104 0.00% 0.00% 0.00% 0 IP Cache Ager 18 0 192 0 0.00% 0.00% 0.00% 0 NBF Input 19 0 2 0 0.00% 0.00% 0.00% 0 SPX Input 20 0 2 0 0.00% 0.00% 0.00% 0 DDR Timers 21 0 1 0 0.00% 0.00% 0.00% 0 SNMPConfCopyProc --More- Show CDP Neighbors The show cdp neighbors command shows you all the Cisco equipment to which your router has a direct physical connection. It is used once you have connected your router to other Cisco routers on your network. It uses the Cisco Discovery Protocol, which is proprietary to Cisco and is why it only finds Cisco devices. The command is very useful for troubleshooting networks. If show cdp neighbors doesn't show a connection, basically you aren't connected (to a Cisco device). CDP is a layer 2 protocol. It is only used for informational updates on directly connected links. What this means to us is that when we look at CDP information on a Cisco router, it will tell us a lot of information about the other Cisco equipment connected directly to the same networks as the router at which we are looking. Since this is a layer 2 protocol, all communications for CDP are broadcast-based, and these broadcasts are sent out every 60 seconds by default. Let's take a look at what we can see from our test network environment. The sh cdp ? command shows us what command arguments are available: Router# sh cdp ? entry Information for specific neighbor entry interface CDP interface status and configuration neighbors CDP neighbor entries traffic CDP statistics <cr> The real value of the sh cdp commands is being able to see the status of the network, the devices to which you are connected, and what their capabilities are. Each CDP status will show us three basic things: accessibility, capabilities, and device type. A simple example on the router from our example shows the following: Router# sh cdp nei Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge, S - Switch, H - Host, I - IGMP, r - Repeater Device ID Local Holdtme Capability Platform Port ID Intrfce Router2 Ser 0 144 R 2500 Ser 1 066538247 Eth 0 159 T B S WS-C5505 4/8 Router# What this shows us is basic connection information about to what a router is locally connected and with what it is communicating. At the moment of this capture, Router1 is connected to a 2500 router named Router2, as well as being connected to a WS-C5505, which is a Catalyst 5505 switch. As you can see, you can get connectivity information on all Cisco products that have CDP enabled. As of IOS version 10.3 and later, CDP is enabled by default on all interfaces.
To look at an individual entry in the CDP neighbor table, use the command where name is the router name or other Cisco device found in the neighbor table. The name is case sensitive. This command is useful if the neighbor table is large and you want to get detailed information about a single neighbor without having to view the details of all neighbors. Router# show cdp entry Router1 Device ID: Router1 Entry address(es): IP address: 192.168.2.2 Platform: cisco 2500, Capabilities: Router Interface: Serial0, Port ID (outgoing port): Serial1 Holdtime : 147 sec Version : Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 11.2(18), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Mon 05-Apr-99 20:23 by jaturner The show cdp neighbors detail command gives the same output as show cdp entry, except it shows detail for the connected routers and other devices. Router# sh cdp nei det Device ID: Router1 Entry address(es): IP address: 192.168.2.2 Platform: cisco 2500, Capabilities: Router Interface: Serial0, Port ID (outgoing port): Serial1 Holdtime : 147 sec Version : Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-JS-L), Version 11.2(18), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. Compiled Mon 05-Apr-99 20:23 by jaturner Device ID: 066538247(GCD5505) Entry address(es): IP address: 10.200.1.5 Platform: WS-C5505, Capabilities: Trans-Bridge Source-Route-Bridge Switch Interface: Ethernet0, Port ID (outgoing port): 4/8 Holdtime : 161 sec Version : WS-C5505 Software, Version McpSW: 5.1(1) NmpSW: 5.1(1) Copyright (c) 1995-1999 by Cisco Systems Showing the CDP neighbor detail statistics is a very handy troubleshooting tool if you know you are having problems with a certain IOS software version. You can use this command on core routers to check the software versions of each directly connected router. If you want to see what the timer settings are for CDP broadcast updates, you can enter the following: Router# sh cdp int
Ethernet0 is up, line protocol is up Encapsulation ARPA Sending CDP packets every 60 seconds Holdtime is 180 seconds Serial0 is up, line protocol is up Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds Serial1 is administratively down, line protocol is down Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds The CDP timers (update interval and hold time) are global parameters. When they are changed, all interfaces running CDP are changed. The command to change the periodic update interval uses seconds. Without using the command the default value is 60. The command to change the hold time also uses seconds. The default value is 180. Remember that when timers are changed on one device, they should be changed on all the rest of the devices to help prevent neighbor-table synchronization problems. Router# cdp timer seconds Router# cdp holdtime seconds CDP can be enabled and disabled either on individual interfaces or globally. If you want to turn off CDP on an individual interface, use the interface configuration mode command no cdp enable. To turn it back on, issue the cdp enable command. To turn off CDP on all interfaces simultaneously, issue the global configuration command no cdp run. Issue the cdp run command to turn CDP back on. Debug Commands Just as the show commands are useful for verifying router status and diagnosing configuration problems, the various debug commands can be helpful too. The debug command allows us to see what the IOS is doing as things happen, and it is normally used for troubleshooting and experimenting. We can turn on many different types of debug activities. Each one shows us something different about what is going on inside a router. To see the possible variations of the debug command, use the inline, context-sensitive help. Start by typing debug ?, and extend the command from there. Debug output, by default, is logged to the console line and to terminal lines that have the monitor capability turned on. When we want to view debug output in a Telnet session, we can give our VTY the monitor capability by issuing the command terminal monitor in privileged mode. There are a lot of debug commands that you can safely use in a classroom or test lab to show you what a router actually does while routing. Here's a tip: before doing any debug commands, type in the no debug all command. That way if something does go wrong while debugging and your router starts spewing out so much information that you can not type anything into the command line, all you need to do is to hit the UP arrow and press Enter. That'll turn the debug off. To see all the debug commands just type debug, a space, and a question mark. Router# debug ? aaa AAA Authentication, Authorization and Accounting access-expression Boolean access expression all Enable all debugging alps ALPS debug information apollo Apollo information apple Appletalk information arap Appletalk Remote Access arp IP ARP and HP Probe transactions aspp ASPP information
async Async interface information backup Backup events bri-interface bri network interface events bsc BSC information bstun BSTUN information callback Callback activity cdp CDP information chat Chat scripts activity clns CLNS information cls CLS Information cns CNS Debugging compress COMPRESS traffic condition Condition confmodem Modem configuration database cpp Cpp information custom-queue Custom output queueing decnet DECnet information dhcp DHCP client activity dialer Dial on Demand dlsw Data Link Switching (DLSw) events dnsix Dnsix information domain Domain Name System drip DRiP debug information dspu DSPU Information dxi atm-dxi information eigrp EIGRP Protocol information entry Incoming queue entries ethernet-interface Ethernet network interface events frame-relay Frame Relay fras FRAS Debug fras-host FRAS Host Debug funi FUNI interface packets gssapi GSSAPI debugs interface interface ip IP information ipx Novell/IPX information isdn ISDN information isis IS-IS Information kerberos KERBEROS authentication and authorization lapb LAPB protocol transactions lat LAT Information ldap LDAP debug commands lex LAN Extender protocol list Set interface or/and access list for the next debug command llc2 LLC2 type II Information lnm Lan Network Manager information lnx generic qllc/llc2 conversion activity local-ack Local ACKnowledgement information management Management applications debugging modem Modem control/process activation mop DECnet MOP server events nbf NetBIOS information ncia Native Client Interface Architecture (NCIA) events
netbios-name-cache NetBIOS name cache tracing nhrp NHRP protocol ntp NTP information nvram Debug NVRAM behavior packet Log unknown packets pad X25 PAD protocol pcbus PCbus interface information ppp PPP (Point to Point Protocol) information printer LPD printer protocol priority Priority output queueing probe HP Probe Proxy Requests qllc qllc debug information radius RADIUS protocol rif RIF cache transactions rtr RTR Monitor Information sdlc SDLC information sdllc SDLLC media translation serial Serial interface information sgbp SGBP debugging smf Software MAC filter smrp SMRP information sna SNA Information snapshot Snapshot activity snmp SNMP information source Source bridging information spantree Spanning tree information sscop SSCOP standby Hot standby protocol stun STUN information tacacs TACACS authentication and authorization tarp TARP information tbridge Transparent Bridging Telnet Incoming Telnet connections tftp TFTP debugging token Token Ring information translate Protocol translation events tunnel Generic Tunnel Interface v120 V120 information vg-anylan VG-AnyLAN interface information vines VINES information vpdn VPDN information vprofile Virtual Profile information vtemplate Virtual Template information x25 X.25, CMNS and XOT information x28 X28 mode xns XNS information xremote XREMOTE As you can see, there are lots of debug commands to choose from. The command debug all is too verbose -- it makes the information you're looking for hard to find in all the detailed data about literally everything in the router. We need to narrow down our focus a bit. Let's say we've been having a problem with our Ethernet interface. If we do a debug ethernet-interface command we can see what is going on. Router# debug ethernet-interface Ethernet network interface debugging is on Router#
00:29:07: %LANCE-5-LOSTCARR: Unit 0, lost carrier. Transceiver problem? 00:29:17: %LANCE-5-LOSTCARR: Unit 0, lost carrier. Transceiver problem? 00:29:27: %LANCE-5-LOSTCARR: Unit 0, lost carrier. Transceiver problem? As you can see, the Ethernet interface is definitely not working. Discovering what is not working is the whole key to troubleshooting. In this case, we know it's because the Ethernet is not connected to a network segment. Fallback You can define a fallback sequence of "boot system" commands that specify alternate ways for your router to boot if your router can't find the IOS on the first try. The boot system commands are placed in the startup configuration file and will only be used if the router is configured for normal boot sequence. For instance, the boot system commands can specify that the router will load first from Flash memory, next from a TFTP server, and finally from ROM. In this case, the TFTP server is a fallback in case the Flash memory is corrupted and ROM is a fallback in case the TFTP server is unavailable. After the Bootstrap Startup Program during the boot process (see Router Boot Sequence, above), the router scans the startup configuration in NVRAM for boot system commands to find out whether it should get its IOS image from a location other than the first file in Flash memory. If it finds boot system commands, it executes them in sequence until it finds a valid image that it can load. If there are no boot system commands, the router will attempt to load the first IOS image it finds in Flash. Finally, if that fails, it will use the image in ROM as a fallback. This minimally featured image will allow IP addresses to be assigned to interfaces and will allow you to use ping and TFTP, but there's not much else in there. The prompt is Router(boot)> The ROM monitor is an unfriendly place to be, the commands are arcane, and the prompts give you no help. We'll discuss how to write boot system commands in the next section. The Configuration Register During the boot process we can have the router look into the startup configuration for where to find the IOS image or we can have the router bypass this step and have it look in a specific place. The primary method for dictating how a router behaves on startup is the configuration register, also known as the config register. The config register on a Cisco router is a 16-bit register that tells the router what to do when booting. note Another reason the config register is important is that when we forget our password, the config register plays a major part in password recovery. This is a topic for another Tutorial, but in the meantime the Cisco web site has more information about password recovery. ( is not associated with Cisco.) With the config register, you can force the router to boot in ROM monitor mode, select boot source and filename, enable and disable the break function during boot, control broadcast address mapping, and control the load source of IOS. It is for this last reason that we will examine the last 4 bits of the configuration register. These last 4 bits are called the "boot field." Since the configuration register is shown in hexadecimal numbers, the last 4 bits will be represented by only one digit. If the boot field is set to hex 00, then the router will boot to the ROM monitor mode on reload or power up. If this field is set to hex 01, the system will boot fully and load the first IOS image in Flash memory. A hex value of 02 is the most flexible, it allows default image booting from Flash
as well as enabling "boot system" commands in the startup-config file. Table 3 shows the values and functions of the boot field. Table 3. Boot Field Positions and Functions
Boot field value Function
00 Boot to ROM monitor mode
01 Boot with default software contained in ROM
02-0F Enables default booting from Flash, then enables "boot system" commands, then implicitly describes a default netboot filename
When the boot field is between 02 and 0F, the router boots from Flash. If it doesn't find an IOS image in Flash it will look to the boot system commands in the startup configuration. If it doesn't find one there, it can look outside of the router to the network. In this last case, the router will need a network filename or netboot filename. The default netboot filename is derived by taking the boot field value and pairing that up with the processor name (name=cisco<n>-processor_name where n is some number between 2 and 15). If we put all these possibilities together, the config register will become 0x2102. Then the IOS will boot from Flash if a valid file exists or will enable "boot system" commands in the config file; if there is no valid software image in Flash, it will attempt to netboot the file name cisco2-2500. By the way, to display the content of the configuration register, use the show version command. (See Show Version, above.) Changing the Configuration Register In order to modify the config register on your router, you must be connected to the console port. This cannot be performed via a telnet session to the router. There are a couple of methods for changing the config register on a Cisco router. One of those methods can be done through regular config mode on the router. In order to change the config register, you must login to the router, enter privileged mode, and then enter config mode. Once there, you will simply enter a single command, config-register, that changes the config register (by the way, the shorthand for this is conf). In this command, the expected input is expressed in hex. Since there is no difference between decimal and hex until digits get above 9, the way to denote hexadecimal notation is with the prefix 0x. For example, the notation for the configuration that would boot the router normally but ignore NVRAM is 0x2142, as shown below: Router> en Router# config t Router(config)# config-register 0x2142 Router(config)# ctrl-z Router# This command sequence will change the router's config register from whatever it is to 0x2142. Now let's check to verify; type sh ver, Enter, and then hit the [space] bar. This will show the software version as well as the config register. At the bottom of the second screen of output, you will see the line Configuration register is 0x2102 (will be 0x2142 at next reload). If you make a change to the config register, you will see the latter parenthesized statement. If you enter the config register command in config mode, but do not actually change the register, you will not see this output. The config register we have entered will cause the router to boot without reading NVRAM for the startup config, and we don't really want that, so let's change it back: Router> en Router# config t Router(config)# config-register 0x2102
Router(config)# ctrl-z Router# Now when we perform a sh ver, we will see that the configuration register is 0x2102. There will no longer be the added statement telling us what the config register will be on the next reload. NOTE: For heavens sake, if you do change the configuration register for any reason, be sure to set it back to what it was before so the router will use its proper configuration and find its IOS image properly the next time it boots up. Booting from ROM (Boot Field = 01) If the boot field of the config register is set to 01 (example: 0x2101) the router will boot from a default IOS image that is stored in ROM. In most cases, the software that is loaded in ROM is an earlier version and only has limited functionality. The reason for having this capability is in the case of a problem with the IOS software that resides in Flash. If you have a problem with that image, you can boot to the default image and TFTP a new image to the router. If for some reason you are working on a router and happen to see a (boot) prompt (example: Router(boot)>), this means that the router is running in ROM monitor mode. This will give you a very quick check to see what the problem is with the router. Check the router and see what the config register value is. If it is 0x2101, then change the config register and reboot. If the config register is 0x2102, you know that something has happened to the software image loading from Flash. Booting from Flash (Boot Field = 02) If the config register has the boot field set to a value of 02, the router will boot from Flash. It is possible to have multiple images in Flash, as well as multiple partitions in Flash. If the boot field is set to 02, the router will look at the startup config to see if there is a boot system command telling it what file to load from Flash. If there are no boot system commands, the router will use the first valid system image in Flash. If there are no valid system images in Flash, then the router will attempt a netboot. With a value of 02 in the boot field, a Cisco 2500 will send out broadcasts on the directly connected networks to retrieve an IP address and look for a TFTP server with the file cisco2-2500 on it. If none of the above circumstances are met, then the bootstrap program will check the 13th bit of the config register. If the 13th bit has an "on" value, the router will load the default software out of ROM. If there are multiple valid system images in Flash, boot system commands can be entered into the startup configuration to tell the router which one to use. The following is the syntax for configuring the router to boot from Flash and look for c2500-d-l.120-5.bin first, c2500-d-l.112-19.bin second, then boot from ROM: Router# conf t Router(config)# boot sys Flash c2500-d-l.120-5.bin Router(config)# boot sys Flash c2500-d-l.112-19.bin Router(config)# boot sys rom Router(config)# [ctrl-z] Router# copy run start Boot system commands will be executed on startup in the order in which they are entered. In the above example, the system will try to boot with the 12.0 release software first, then the 11.2 software, and then revert to ROM. There is another boot system command that tells the router to boot from the network (from a TFTP server). The syntax is similar, and the following will load the same images from a TFTP server with the IP address of 192.168.1.100. Router# conf t Router(config)# boot sys tftp c2500-d-l.120-5.bin 192.168.1.100 Router(config)# boot sys tftp c2500-d-l.112-19.bin 192.168.1.100 Router(config)# boot sys rom
Router(config)# [ctrl-z] Router# copy run start In this example, we explicitly told the router to look for the TFTP server at IP address 192.168.1.100. If the TFTP server was located on a LAN local to the router, we could have left this information off, and the router would have sent out a broadcast and located the server on its own. Another note regarding this type of configuration is that since there are options to booting, the router has a fallback. If the first option doesn't work, it can fall back on the second option, then the third, which is boot with the default software image in ROM. (See Fallback, above). Appendix A. Review Questions and Answers Review Questions (Answers are provided at the end.) Answer the following questions as either True or False. 1. The most common method for a router to find the configuration commands are the ones saved in NVRAM. 2. You can specify enabled config-mode boot system commands to enter fallback sources for the router to use in sequence. 3. In order to check any config-register setting you use either the show running-config or show startup-config commands. 4. The system image in ROM contains the full set of Cisco IOS software, which is equal to the one found in Flash. 5. The system image stored in Flash memory can be copied to ROM with the command copy flash rom. 6. By default, Cisco routers are DTE devices, but sometimes we need to turn them into DCE devices. 7. The configure console command is used to configure manually from the console terminal. 8. You can configure a message-of-the-day banner to be displayed on all connected terminals using the banner config command. 9. The first global parameter for which you are prompted by a router during Setup allows you to set the router's host name. 10. If Flash memory is corrupted, or its IOS is missing and the network server fails to load an IOS image, booting from ROM is the final bootstrap option in software. 11. During router Setup you are not prompted for parameters for each installed interface, you must enter these separately using the configure interfaces command. 12. During router setup you need not enter an enable secret password, but you must enter just the enable password. 13. Flash memory holds the operating system image and microcode, allowing updates to software without removing and replacing chips on the processor. 14. CDP runs over a data link layer, connecting lower physical media and upper-network-layer protocols. 15. Default values for CDP timers set the frequency between CDP updates and for aging CDP entries. 16. The show version command displays information about the Cisco IOS software version that is currently running on the router. 17. CDP can only discover information about directly connected Cisco devices if they are using the same protocol suite. 18. The TFTP server can be another router, or it can be a host computer system. 19. If no free Flash memory space is available, or if the Flash memory has never been written to, the erase routine is usually required before new files can be copied to it. 20. A router can only have one incoming Telnet session at a time. 21. The terminal editing command enables advanced editing. 22. Commands available in privileged mode are a subset of the commands available in the user mode. 23. From the user mode, you can also access global configuration mode and the other specific configuration modes. 24. You can press Control-C to terminate the setup process and start over at any time.
25. For many of the prompts in the system configuration dialog of the setup command facility, default answers appear in square brackets ([ ]) following the question. Review Answers 1. True 2. False 3. False 4. False 5. False 6. True 7. False 8. False 9. True 10. True 11. False 12. False 13. True
Appendix B. Cisco Router Series It can be useful to think of Cisco routers as having been introduced in several product generations. This isn't completely pure, because some devices called "switches" actually route. In general, however, it's useful to think of:
• First generation routers: totally obsolete proof-of-concept • Second-generation: IGS, CGS, MGS, and AGS (which ran a recognizable IOS) • Third-generation: 2500, 4000, and 7000, running at least IOS 9.0 • Fourth-generation: broadband access routers for ISDN, xDSL, CATV, etc., (all running
IOS), 1600, 2600, and advanced 7100/7200, 7500. "Layer 3 switching" in 5000/5500 switches.
• Fifth-generation: very high capacity including 10000 and 12000; Layer 3 switching in 6000/6500/8500 switches.
Having looked at the most common Cisco router, we can now discuss the different models of Cisco routers and give some particulars about each one. There are several varieties of Cisco routers. The relevant router models are the 2500, 4000, 7000, and 7500 series. The 4000 is the next step up after the 2500 series in Cisco's product line. The following lists show some of the Cisco routers and give their primary uses. When the description of any Cisco router series includes the term "slot" you should think of an opening where a removable card or component can be inserted. Series 700 This family of products is ISDN dial-on-demand routers for home offices and telecommuters (base $400 to $800).
• 761 - One Ethernet port plus ISDN BRI S/T • 762 - One Ethernet port plus ISDN BRI NT1 • 765 - One Ethernet port plus ISDN BRI S/T plus two POTS • 766 - One Ethernet port plus ISDN BRI NT1 plus two POTS • 771 - Four Ethernet ports plus ISDN BRI S/T • 772 - Four Ethernet ports plus ISDN BRI NT1 • 775 - Four Ethernet ports plus ISDN BRI S/T plus two POTS • 776 - Four Ethernet ports plus ISDN BRI NT1 plus two POTS
Series 1600 This family of routers is a slightly scaled down version of the more expensive and popular 2500 Series family. Generally, it has one serial and one Ethernet port rather than two like the 2500 has. Unlike most of the 2500 family, the 1600's have a WAN module slot for flexibility.
• 1601 - One Ethernet port and one serial port • 1602 - One Ethernet port and one 56K CSU/DSU
• 1603 - One Ethernet port and one ISDN BRI S/T • 1604 - One Ethernet port and one ISDN BRI NT1 • 1605R - Two Ethernet ports
Series 2500 The 2500 Series is the world's most popular small-to mid-sized router. There are so many types of routers available in this series that it is helpful to organize the list into several groups as is done below: Single LAN
• 2501 - One Ethernet port, two serial ports • 2502 - One Token Ring port, two serial ports • 2503 - One Ethernet port, two serial ports, one ISDN BRI • 2504 - One Token Ring port, two serial ports, one ISDN BRI • 2520 - One Ethernet port, two serial ports, one ISDN BRI, 2 low speed serial • 2521 - One Token Ring port, two serial ports, one ISDN BRI, 2 low speed serial • 2522 - One Ethernet port, two serial ports, one ISDN BRI, 8 low speed serial • 2523 - One Token Ring port, two serial ports, one ISDN BRI, 8 low speed serial
Dual LAN • 2513 - One Ethernet, one Token Ring, two serial ports • 2514 - Two Ethernet ports, two serial ports • 2515 - Two Token Ring ports, two serial ports
Router/Hub Combo • 2505 - Eight-port Ethernet hub, two serial ports • 2507 - 16 port Ethernet hub, two serial ports • 2516 - 14 port Ethernet hub, one ISDN BRI, two serial ports
Access Servers • 2509 - One Ethernet, eight asynch, two serial ports • 2511 - One Ethernet, 16 asynch, two serial ports • 2512 - One Token Ring, 16 asynch, two serial ports
Series 2600 This family of routers is very comparable to the popular 2500 series, except they have slots, including one Module slot for features like voice and fax, and two WAN slots for options like built-in CSU/DSU, ISDN, serial ports, asynch ports, and so forth.
• 2610 - one Ethernet, one Module slot, two WAN slots • 2611 - two Ethernet, one Module slot, two WAN slots • 2612 - one Ethernet, one Token Ring, one Module slot, two WAN slots • 2613 - one Token Ring, one Module slot, two WAN slots • 2620 - one Ethernet 10/100, one Module slot, two WAN slots • 2621 - two Ethernet 10/100, one Module slot, two WAN slots
Series 3600 The 3600 Series is a multifunction platform that combines dial access, routing, LAN-to-LAN services, and multifunction integration of voice, video, and data in the same device. It is somewhat similar to the 2600 Series in regard to available slot options except it has a much richer list of those options. Also, the 3600 is a router meant to be installed in a larger network, like a WAN headend where the core of the WAN is located. Series 4000 The third-generation Cisco 4000 series consists of the Cisco 4000-M, the Cisco 4500-M, and the Cisco 4700-M. The Cisco 4000 series is used in middle-size networks and at the distribution layer of large internetworks. All models provide a configurable modular router platform using network processor modules including FDDI, ISDN BRI, ISDN PRI, Ethernet 100baseT, Token Ring, HSSI, and ATM. The Cisco 4000 series routers support up to three network processor modules at a time. The Cisco 4700-M contains a 133-MHz RISC microprocessor, 16 to 64 MB main memory, and a 512-KB secondary cache. The faster speed of the Cisco 4700-M allows higher throughput
for high-speed interfaces. The 512-KB secondary cache is useful for process switching applications such as compression and encryption. In new installations, the 4000 series has been superceded by the 3600 series. Be sure to pay attention to the model number. The routers are the 4000, 4500, and 4700. There is a new series of gigabit layer 2 switches called the 4000 series. AGS+ and Series 7000 Some Cisco routers were the most powerful of their time, but have been superceded by newer models. The AGS+ is a "second generation" router, which you may find available cheaply. It generates substantial heat and noise, and will run IOS versions no later than early 11. Nevertheless, many certification candidates find it cost-effective in their labs. Be sure that you buy a version with the CSC/4 processor if you expect to run any recent IOS. The AGS+ was the first Cisco router that could use different processors for path determination and packet forwarding. The third-generation replacement for the AGS+ was the Cisco 7000 series of multi-protocol routers, including the Cisco 7000 and the Cisco 7010. The 7000 and 7010 differ only in their number of card slots, Network interfaces reside on modular interface processors, which provide a direct connection between the high-speed Cisco Extended Bus (CyBus) and the external network. Distributed processing is accomplished by the Route Processor (RP), Switch Processor (SP), and Silicon Switch Processor (SSP). Series 7100 and 7200 The fourth-generation Cisco 7200 series of multi-protocol routers delivers the performance, port density, and availability typically associated with high-end systems. This router is used as a high-speed backbone aggregation router for high-speed enterprise interconnectivity. It is used for a WAN edge concentrator at the backbone and IBM interconnectivity. The 7100 has additional hardware to assist it in encryption for virtual private networks. Series 7500 and 10000 The Cisco 7500 was designed to meet the demands of emerging high-end application environments -- in terms of density, performance, and system availability. Like the 7200 series, this series is used for high-speed backbone aggregation needed for high-speed enterprise interconnectivity. It is used for a WAN edge concentrator at the backbone. Series 12000 Cisco's new family of gigabit switch routers (GSR) provides high-performance solutions ranging from five to 60 Gbps for Internet and large-scale WAN intranet backbone applications. 2.2 Lab Abstract In this lab you will complete the following tasks: � Back up a router configuration file to a TFTP server � Back up a router IOS software image to a TFTP server � Restore a router configuration file from a TFTP server � Restore a router IOS software image from a TFTP server 2.3 Lab Scenario Complete this lab to practice what you learned in the Basic Router Operation Tutorial. Objectives In this lab you will complete the following tasks: • Back up a router configuration file to a TFTP server • Back up a router IOS software image to a TFTP server • Restore a router configuration file from a TFTP server • Restore a router IOS software image from a TFTP server Setup Your router should have at least a basic configuration from either completing the router's setup script or manually configuring your router similar to the sample configuration in the Basic Router Operation Tutorial. note
Many TFTP server implementations require you to access files, for both upload and download, by their fully qualified name -- not their name relative to a directory You should also install and configure a TFTP server in your lab network. This is fairly easy to do, and any PC or laptop can function as your TFTP server for the purposes of this lab. For more information about finding TFTP software, see Backing Up Router Configuration Files in the Basic Router Maintenance and Troubleshooting section of the Basic Router Operation Tutorial. Scenario You've configured your router, and now you want to save your configuration somewhere other than NVRAM. You also want to back up your router's IOS software image in case your router suffers a critical failure. Finally, you want to test these backups by restoring them to your router. Task 1: Back up a router configuration file to a TFTP server Step 1-1 Enter privileged EXEC mode. Step 1-2 Save your running configuration to NVRAM. What command saves your running configuration to NVRAM? ______________________________ Step 1-3 Backup your running configuration to the TFTP server. What command will back up your running configuration to the TFTP server? ______________________________ Refer to the Backing Up Router Configuration Files section of the Basic Router Operation Tutorial for the correct responses to the router questions. Make sure you enter the IP address you configured for your TFTP server when prompted for the address of the remote host. Give your configuration file a unique name. Step 1-4 Find and view your configuration file on the TFTP server. What is different about the configuration file on the TFTP compared to your original running configuration? (Do a show run on your router if necessary.) ______________________________ Task 2: Back up a router IOS software image to a TFTP server Step 2-1 Look at the contents of Flash memory. What command shows you the contents of Flash memory? ______________________________ How many files are currently in Flash memory? ______________________________ List the files currently in Flash memory: ______________________________ What file, ending in .bin, will always be found in the Flash memory of newly configured routers? ______________________________ How many bytes of Flash memory is the .bin file taking up? ______________________________ How many bytes of Flash memory are left? ______________________________ Step 2-2 Back up your IOS software image to your TFTP server. What command backs up your IOS software image to your TFTP server? ______________________________ Refer to the Backing Up Software Images section of the Basic Router Operation Tutorial for the correct responses to the router questions. Make sure you enter the IP address you configured for your TFTP server when prompted for the address of the remote host. Use the name of the .bin file you wrote above as the source file name.
Step 2-3 Find your IOS software image on the TFTP server to verify that it transferred correctly. Task 3: Restore a router configuration file from a TFTP server Step 3-1 Restore the configuration you saved to the TFTP server in Task 1 to your router's current running configuration. What command restores the configuration you saved to the TFTP server in Task 1 to your router's current running configuration? ______________________________ Refer to the Backing Up Router Configuration Files section of the Basic Router Operation Tutorial for the correct responses to the router questions. Make sure you enter the IP address you configured for your TFTP server when prompted for the address of the remote host. Use the name you gave your configuration file. What command would you enter to restore the configuration from the TFTP server directly to your router's startup configuration? ______________________________ Task 4: Restore router IOS software image from a TFTP server Step 4-1 Restore the IOS software image you saved to the TFTP server in Task 2 to your router's Flash memory. What command restores the IOS software image you saved to the TFTP server in Task 2 to your router's Flash memory? ______________________________ Refer to the Backing Up Software Images section of the Basic Router Operation Tutorial for the correct responses to the router questions. Make sure you enter the IP address you configured for your TFTP server when prompted for the address of the remote host. Use the name of the .bin file you wrote in above as the source file name. Why would the router need to erase Flash memory in order to restore an IOS software image from a TFTP server? ______________________________ How does the router indicate that Flash memory is being erased? ______________________________ How does the router indicate that the IOS is being copied? ______________________________ Solutions Task 1, Step 2. - copy run start Task 1, Step 3. - copy run tftp Task 1, Step 4. - The configuration file on the TFTP server will have no comments [lines beginning with an exclamation point (!)] in it. The comments get stripped out when being transferred to the TFTP server. You can add them back in on your TFTP server with a regular text editor. Task 2, Step 1. - show flash The number and name of files currently in Flash will vary from router to router. On newly configured routers the only file in Flash is the system image file (the file that ends in .bin). The number of bytes of Flash memory that the system image file takes up will vary from router to router. There should be at least several megabytes of Flash memory still available, however. Task 2, Step 2. - copy flash tftp Task 3, Step 1. - copy tftp run - copy tftp start Task 4, Step 1.
- copy tftp flash Note the size of the IOS software image from Task 2, Step 1. If there is not enough room in Flash memory to save a second copy of the IOS software image, it will need to erase the Flash to make room. The letter 'e' is output to the screen to indicate that Flash memory is being erased. Exclamation points are output to the screen to indicate that the IOS is being copied 3 IP Addressing IP Addressing There are several related areas you must understand before you can make a router do useful things. You must understand: (1) how hosts and routers connect to physical media; (2) the potential relationships among physical media (and simulated physical media) to logical media; and (3) the conventions for IP and IPX addressing that involve setting up identifiers for points on logical media, and how to code these identifiers into routers. In this tutorial, the author begins with a review of topologies and then reviews IP addressing in a more binary and classless way, finally mapping into the decimal and classful way. 3.1 Tutorial Introduction Wernher von Braun is said to have described research as "that which you do when you don't know what you are doing, and know you don't know." When beginners to Internet Protocol (IP) addressing start dealing with it, all too often they assume some of its quirks are part of extremely subtle and thoughtful original design ideas. In reality, many of IP's quirks exist because researchers made a best guess based on the experience of the time. Some things have remained true over time. A network address is always hierarchical. The higher-order part identifies a medium, and the lower-order part identifies a host on that medium. The routing system makes decisions about forwarding based on the high-order prefix part of network addresses. Network addresses therefore not only identify devices, but also give hints on the path to take to get to them. End hosts have network addresses and transport layer identifiers that tell how to get to a specific software process once a packet reaches that host. Routers have collections of interfaces, each interface with its own logical address. With experience, many of the guesses made for the first IP addresses turned out to be less than optimal. By the time the industry gained this experience, however, the software that implemented this code was too widely deployed to be easily changed. Current Addressing The current version of IP is Version 4 (IPv4). A new version, IPv6, has been developed, built on 15-plus years of experience with IPv4. Given the very large installed base of IPv4 systems, it is unclear how quickly, if at all, IPv6 will replace IPv4. The trend to v6 is accelerating in new networking industries. Third-generation wireless networks have selected IPv6, so commercial products in 2002 or 2003 seem likely. In other words, don't worry about IPv6 in the near term. There are several related areas you must understand before you can make a router do useful things. You must understand how hosts and routers connect to physical media. You must understand the potential relationships among physical media (and simulated physical media) to logical media. You must learn the conventions for IP and IPX addressing that involve setting up identifiers for points on logical media, and how to code these identifiers into routers. Cisco no longer publishes specific objectives for exams. Probably the most reliable reference on the CCNA, however, is the curriculum for the first four semesters of the Networking Academy. Intended to qualify students for the CCNA, this curriculum includes the following:
• Describe data link and network addresses and identify key differences between them. (a3)
• Define and describe the function of a MAC address. (g15) • Describe the two parts of network addressing, then identify the parts in specific protocol
address examples. (d2) • Describe the different classes of IP addresses [and subnetting]. (d3) • Configure IP addresses. (d4)
• Verify IP addresses (d5) You will find additional material on IP-related objectives in the CCNA Tutorials on IP Routing and Network Security. Unfortunately, IP addressing is one of those areas where there is a right way, a wrong way, and a Cisco way. The Cisco way for CCNA IP addressing objectives is based on obsolete classful principles, which will be explained below. Many, if not most, introductions to IP persist in using the decimal and classful approach, which is neither the way Internet addresses actually are assigned, nor a straightforward way to learn. In this paper, I review IP addressing in a more binary and classless way, and then map the methods into the decimal and classful way. While some consider this an unconventional means of teaching, I have used it with hundreds of students and find they learn addressing faster and more accurately. The addressing presentations in Cisco's CID and ACRC courses are drawn from an internal briefing I did using this approach. So, if you have learned the classful way and are expecting a review in the same manner in which you learned things, I ask for a bit of patience while I show you how to understand even better. If you are a beginner, you don't have bad habits! Topologies Routing has two main components, drawing the map (i.e., path determination) and moving packets, step by step, onto media one hop closer to the destination (i.e., packet forwarding). The logical destination addresses in routed packets give information about the appropriate next-hop medium to which the router will forward. In routing, you relay packets from a sending host to its local medium, from the local medium to a local router, from the local router via another medium to intermediate router(s), and eventually to the egress router. The egress router sends the packet onto the medium where the destination host lives. If you didn't notice it, let me make it explicit. Routing is based on the relationships among a set of media. There are several different kinds of medium topology. In data communications usage, topology refers to the number of devices that can connect to a physical or logical medium, and the ways in which they interconnect on that medium. From basic data communications, you should be familiar with simple point-to-point lines -- no more complex than a cable -- and with LANs. All hosts connected to the same LAN segment can reach one another using layer 2 protocols. Table 1. Possible Topology Types for Various Media
Technology Physical Topology
Logical Topology Endpoint address
Ethernet and 802.3 10Base5, 10Base2 bus, star bus 48-bit MAC address
Ethernet 10BaseT Star bus 48-bit MAC address
Token Ring star ring 48-bit MAC address
FDDI dual ring ring 48-bit MAC address
FDDI single point-to-point ring 48-bit MAC address
Dialup, ISDN point-to-point point-to-point or NBMA
National telephone number conforming to ITU-T E.163 or E.164 (for ISDN)
X.25 point-to-point point-to-point or NBMA Up to 14 byte X.121
You may also be familiar with partial mesh, virtual circuit media such as Frame Relay and ATM. In this section, we will formalize your knowledge, and give you the background to understand how you apply addressing to different medium types. A slight bit of formalism will tighten up any discussion of topology. Adjacency and connectivity are terms from mathematical graph theory, which are extremely useful in discussing network topology. A graph is a set of nodes with paths among them. Terms discussed in this section, such as adjacency and connectivity, are as relevant to switches at layer 2 as to routers at layer 3. In Figure 1. Basic Topology, router garlic has two directly connected neighbors, ginger and spearmint. ginger has a neighbor of its own, cinnamon. Assume there are magical routing mechanisms in place that let each router learn about destinations on the other routers, so a host on garlic can reach one attached to an interface on cinnamon.
Figure 1. Basic Topology Two nodes that are adjacent are also connected, but not all connected nodes are adjacent. In routing, the number of hops between two points is the number of routers between the two endpoints. In Figure 1. Basic Topology, there are two hops on the path between cinnamon and spearmint. Application hosts butterscotch and strawberry believe they are directly connected at the application layer, but, as indicated by the dashed line, this is a virtual relationship mapped onto a lower layer. In like manner, routers garlic and spearmint think they are directly connected, but actually have a virtual relationship through the layer 2 switches gorgonzola and brie. A more technical term for routers that are neighbors -- that are connected by a common medium -- is that they are adjacent or that they have adjacency. Routers that must go through intermediate routers to reach other destinations have connectivity, but not adjacency, with the destination. Connectable is a synonym for reachable -- it may be achieved either with connection-oriented or connectionless protocols.
More common terms are that adjacent things are neighbors, while connectable things are reachable through a network(s). There are multiple meanings of "connection" in networking, and we are only using the topological meaning here! You can have logical connectivity between endpoints even if you don't have physical connectivity. For this to happen, the underlying transmission system has to be able to reach each successive link on the path between source and destination. Technologies such as dynamic routing may make the path change over time, but there always must be a set of reachable links for logical connectivity to exist. Two points have connectivity when they can exchange information, but not necessarily directly. Intermediary things (e.g., the telephone network) may be needed to carry out the information exchange. In Figure 1, the application hosts are unaware of the routers. Butterscotch thinks it is talking directly to Strawberry. The routers are unaware of the switches. Garlic thinks it is talking directly to Spearmint. There are different topologies at each protocol layer. MAC Addressing 48-bit Medium Access Control (MAC) addresses are used for all current LANs. The ordering of bits inside a frame differs between Ethernet-style and Token Ring/FDDI style. The most significant bit can appear as the leftmost (the "canonical" Ethernet style) or rightmost (non-canonical, Token Ring) bit of the first byte of the MAC address. This bit is set to 1 when the address describes a multicast or broadcast group address and to 0 if the address is for a unicast individual address. Bit 2 is set to 1 when the address conforms to the global IEEE convention and to 0 if it is locally administered. Under global addressing, the first six hexadecimal digits of the address (i.e., its first 24 bits, of which 22 represent a vendor code and 2 bits are used in protocol functions)
• System administration practices associate a certain MAC address with a specific user or location. In such cases, the addressing system would be useless if a MAC address changed whenever a board was changed for maintenance. Locally administered MAC addresses can be set with an IOS command "mac-address address". This is most often used on Token Ring interfaces.
• Some network layer protocols, including those of DECnet, XNS, Novell, and Banyan, modify some or all MAC addresses to reflect layer 3 information.
Several non-IP protocols (DECnet, Novell IPX, XNS, and Banyan VINES) may change the MAC addresses of router interfaces, as part of their particular way of avoiding the need to ARP. These strategies can cause compatibility problems in multi-protocol environments. Logical and Physical Relationships: Topologies Throughout this paper, there are references to logical and physical topology. You will find more detail about these relationships as you go along. Figure 2 shows the various relationships.
Figure 2 As mentioned above, adjacent nodes share a common medium. Nodes that are connected can have a path traced between them, but that path may go through multiple routers and media. One-to-One Relationships The simplest one-to-one network topology is a direct connection between two entities. Both users in a pure one-to-one relationship are zero hops from each other. Several simple topologies can be created with direct lines between nodes. When speaking in terms of graphs, do not confuse the abstraction of a line with a physical, one-to-one transmission facility such as a "telephone line." In practical terms, however, a persistent one-to-one relationship is nicely illustrated by a cable, while a telephone call is a good example of a transient one-to-one relationship. To consider more complex relationships, you will want to generalize the idea of a one-to-one topology to a one-to-many topology. Relationships beyond 1:1 If a set of nodes either shares a common broadcast medium, or point-to-point connections exist among all of them, they are in a full mesh relationship. Figure 3 shows a full mesh.
Figure 3. Full Mesh The most general topology is full mesh. All stations have many-to-many connectivity to one another. It is the basic model of a LAN. This may be a valid model for application connectivity, but simply does not scale well at the levels actually concerned with moving bytes. The need for all workstations to know the name and location of all other workstations would present, as the number of users grew, an overwhelming maintenance and performance penalty. It is worth noting that a given station may belong to several different topological relationships. Tightly controlled hierarchies often are most reliable for the infrastructure task of maintaining the network itself, while more meshed structures are a better fit for the user view for interapplication communications. Even at the application level, there will often be hierarchy not visible to the end user. A local workstation, for example, may interact with a local server. The local server interacts with other servers only when it needs to, on behalf of a number of local workstations. The network is more scalable when every workstation does not need to communicate directly with every server.
When all nodes in a graph are directly connected, a mesh is formed. A mesh is a many-to-many topology. In actuality, a mesh is made up of multiple one-to-many relationships. Mathematically, each of the N nodes needs (N-1) links to all other nodes. These links can be point-to-point, or operate over a shared medium. In the top part of Figure 3, tarragon, parsley, basil, and dill are connected by a logical full mesh made up of point-to-point media. If any medium fails, the relationship among the routers is no longer point to point. In the bottom part of Figure 3, the same nodes are joined to a common broadcast-capable medium. LANs exhibit full mesh behavior because they operate over a common medium. While it is possible to build full meshes out of WAN links, the reality is that WAN links occasionally fail, turning the full mesh into a partial mesh. Partial Meshes Partial mesh topologies are extremely common in modern networks, but they were not anticipated by the original IP addressing model. That original model assumes that if another address is in the same subnet, you will have layer 2 connectivity to it. If it is in a different subnet, you will need a router to reach it. A wide range of issues occurs on nonbroadcast multiaccess (NBMA) media such as Frame Relay, ATM, and X.25. Many of these issues come from the way in which these media violate an early assumption in IP architecture called the local versus remote assumption. Figure 1. Basic Topology shows how the router assumes that hosts on the same subnet share layer 2 connectivity, but an intervening router is necessary to reach a host on a different subnet. This is a perfectly reasonable assumption on fully meshed broadcast media such as LANs. The assumption is a non-issue on point-to-point lines.
Figure 4. NBMA As shown in Figure 4. NBMA, there is a problem in routers interconnected on NBMA partial mesh media. Parsley does not know it needs to forward to tarragon to reach basil.
Figure 5. Partial Mesh Problem In general, partial meshes should be avoided among routers. A danger is that you may have a partial mesh occur not because you have designed for it, but due to a failure as shown in Figure 5. The most common workaround is to create subinterfaces for each virtual circuit, and treat the virtual circuits as logical point-to-point subnets with a /30 prefix. Each subinterface needs its own set of buffers, so large numbers of virtual circuits can require excessive amounts of memory. You can also declare point-to-multipoint subinterfaces, as shown in Figure 6. Point-to-Multipoint. Point-to-multipoint is feasible in a hub-and-spoke topology. In addition to subinterfaces, OSPF has an alternative way of defining point-to-multipoint networks.
Demand Circuits Originally, IP addressing assumed there was a long-term relationship between the physical and logical address. Think, however, of a dial connection to an ISP. You dial a main number, but the specific dial-in port to which you will connect varies from session to session. A physical relationship that only exists when commanded to do so is a demand circuit. At higher levels of certification, when you work on Cisco remote access, you will see many references to dial on demand routing (DDR). Logical and Physical: Mappings For your network to work, both hosts and routers need to associate physical/media addresses with logical addresses. Table 2. Relationships among Logical Addresses, Transmission System Addresses, and Mapping between Them
Logical IP
Mapping ARP IPCP, static
IPCP, static Static
Inverse ARP, static
Inverse ARP, static
ARP, static
ARP, static
Tech-nology LAN Dial ISDN X.25 Frame ATM AAL SMDS LANE
Protocol type ID
LLC, SNAP or Ether-type
PPP IPCP
PPP IPCP
RFC 1355
RFC 2427
RFC 2684, RFC 2225
LLC, SNAP or Ether-type
LLC, SNAP or Ether-type
Persistent endpoint identifier (i.e., medium)
MAC E.163 E.164 X.121 NSAP MAC MAC
Transient connection identifier
[1] [2] TEI LCN
DLCI
VPI & VCI N/A [3]
Next Lower Layer
LAN PHY Analog ISDN
PHY serial serial SONET, etc.
DS1, DS3, ATM
ATM
[1] Connectionless [2] There is no specific identifier because analog lines do not carry any complex signaling. There is effectively a connection identifier, but it tends to be physical. Think of a multi-button key telephone, on which a button blinks for incoming calls, and stays on when a line is in use. That button is the connection identifier. [3] The ATM VC identifier does not specifically point to the MAC address. Instead, it points to the LAN Emulation Client to which the MAC address is connected. Basic Mappings Briefly, the most basic relationship between a logical and physical medium is one to one. Historically, IP made the local versus remote assumption: if one IP host was on the same logical medium (i.e., subnet or prefix), it was assumed to have layer 2 connectivity with all other hosts on the same logical medium. If it were on a different logical medium, the host would have to use a router to get to the other host. This situation can be addressed by using secondary addresses, which map multiple logical addresses to a single physical address, giving an interface the ability to be on more than one logical medium at a time. The next refinement is typified by virtual LANs (VLANs), although its characteristics are shared by WAN media using virtual circuits, such as ATM and Frame Relay. In this refinement, several
physical media are linked by a trunking mechanism that gives the impression of a single seamless physical medium. Finally, secondary addresses can be combined with virtual networking. Doing so will allow you to have multiple logical networks mapped onto multiple physical networks. Multiple Logical per Physical Medium: Secondary Addressing In secondary addressing, detailed later, you assign more than one logical medium to a single physical medium. Nortel/Bay refers to this process as multinet addressing. Secondary addressing is often not necessary in more modern environments, but it can solve many addressing and routing problems found in the classful style of addressing that CCNA candidates will encounter.
Multiple Physical Treated as Single Logical: Basic VLAN A VLAN, discussed in the CCNA LAN Switching Tutorial, creates a layer 2 relationship among multiple physical media, so users connected to different physical segments can appear as part of the same logical network. VLANs do more than simple bridging, because they can carry traffic belonging to several logical networks on a shared high-speed trunk. Trunks are generally 100 Mbps or faster, and are used to link wiring closets in different floors or buildings. Multiple Physical with Multiple Logical: VLAN with secondaries Combining secondary addressing with VLANs allows you to have users at an arbitrary location belong to one of several logical networks, to which they are not physically connected.
What do Routers do with Addresses? Routers make forwarding decisions based on destination addresses in packets. These decisions are made on some number of high-order (i.e., leftmost) bits in the address. Routers rarely use all bits in an address to make a routing decision. They look at high-order bits to find the medium on which the destination is located. The low-order bits identify the specific host destination on a medium. A Telephone Analogy Think of a telephone number, considering all fields that may be used with a telephone number. The highest-order digits of a telephone number form a country code. In North America, the next three digits define the area code, the next three digits specify an exchange, and the final four digits define the actual line within an exchange, to which a telephone is connected. Figure 7. Telephone Hierarchy shows the topological decisions made as a result of the structure of a telephone number.
Figure 7. Telephone Hierarchy Your local telephone switch first considers the country code prefix if a country code is present. It compares the country code to its own country, and, if the two codes do not match, it sends the call to an international switch. The local switch does not evaluate fields below the country code when processing international calls. If the call is in the same country, the switch then evaluates the area code prefix digits. When the area code does not match the area code of the switch, the call is transferred to a long-distance switch. The local switch, on finding that the destination of a call is not in the same area code, does not evaluate fields below the area code level. It merely considers the three-digit area code prefix. When the call is in the same area code, the switch then compares the exchange prefix digits with its own exchange. If these digits do not match, the switch passes the call to a switch that services that exchange. To find that exchange, it considers six digits, the exchange within an area code.
Only if the exchange codes match does the switch look at the line field and complete the call to the actual destination. In completing that call, it maps the software-defined line number, at the logical level, to a physical pair of wires that leads to a telephone. Network Addresses and Routing You can think of network addresses as having two basic parts shown in Figure 8. Prefix and Host. The prefix tells the router how to get closer to the ultimate destination medium. The host part tells the final router interface how to reach the specific destination on the final medium. In modern IP practice, prefixes can be of different lengths.
Figure 8. Prefix and Host The prefix may have multiple internal levels, much as a telephone number can. In the approach to addressing that you will use at the CCNA level, the prefix will be divided into two major parts: the network part and the subnet part. We will discuss these parts in detail later, but, at this point, assume that the network part is administratively defined by a central authority, while the subnet part is an extension to the network part, and is defined by enterprise-level network administrators. Figure 9. Classful Routing parallels the telephone number analogy of Figure 7. Telephone Hierarchy.
Figure 9. Classful Routing Matching Routes If an existing entry in a router's routing table matches a new route, but is less specific, the just-received route is added. "Less specific" means that the route in the Routing Information Base (RIB) matches the destination with a lesser number of prefix bits than does the new route. Another way of putting this is that a more specific route has a subnet mask with more one bits: 255.255.0.0 is more specific than 255.0.0.0. For example, assume your routing table contains: 10.0.0.0/8 (mask 255.0.0.0), outgoing interface S0 and the router receives 10.1.0.0/16 (mask 255.255.0.0), outgoing interface e0 The new routing table will contain: 10.0.0.0/8 s0 10.1.0.0/16 e0 When routing a packet, routers use the longest match in their routing table to select the outgoing interface. In the routing table example above, 10.1.0.0 is more specific than 10.0.0.0, so traffic to 10.1.0.0 will exit on Ethernet 0. One important special case is the default route. A Special Case: The Default Route and ip classless By convention, the address 0.0.0.0/0 is the default route, the least specific possible route. Cisco sometimes uses the term pseudonetwork to refer to 0.0.0.0/0. It is the route that you go to when you don't have anyplace else to go. When it came time to pick softball teams in my high school physical education classes, I was the default route. As opposed to being something to put in right field and forget, default routes are quite useful in networking. Default routes can be declared with static routes, or they can be learned from dynamic routing protocols. While static routes are more a technique for the CCNP than the CCNA level, here's a quick example. To create a static route to define the local default, code: ip route 0.0.0.0 0.0.0.0 {next_hop_IP | outgoing_interface} Created as a static route with an administrative distance less than dynamic routing, a default route in the next-hop-ip format will be used for the local router box, but not advertised unless it is explicitly redistributed (or you use the outgoing interface form of the static route command).
Statically declared default routes of the interface-name format will be advertised as if they were directly connected. Local configuration is not the only way your router can learn the 0.0.0.0/0 default route. It can be learned from dynamic routing protocols such as OSPF and RIP. See a more detailed discussion in the CCIE Routing Principles Tutorial. ip classless While default routes are not a major issue at the CCNA level, you should be aware of a change in behavior of more recent releases that have the ip classless option. In a routing table under the no ip classless option, where the router has learned about 10.1.0.0/16 from another router, it assumes that if a subnet of 10.0.0.0 is reachable through e0, so is any other part of 10.0.0.0. 10.1.0.0/16 e0 0.0.0.0/0 s1 Where will a packet destined for 10.2.0.0 go? With no ip classless, it should leave on Ethernet port 0. When the ip classless option is coded, the router does not assume that if it knows how to reach a subnet, it can use that subnet's output interface to reach any other subnet of the major network. With this option, a packet destined to 10.2.0.0 will not match the more specific subnet entry, and will leave on Serial 1. 10.1.0.0/16 e0 0.0.0.0/0 s1 You may run across several terms that are often (and incorrectly), considered synonymous: default routes, default gateways (default routers), default networks, and gateways of last resort. These terms refer to slightly different mechanisms, all of which are useful. Knowledge of them is generally required at the CCNP level. Default Gateway The default gateway is specifically intended for the situation when no IP routing is enabled. It has the specific next hop address of the gateway router. You would use this on a switch, or a router box that is only doing bridging, so the box can reach network management servers not on the same subnet. Another application for the default gateway comes during booting from ROM, to find the TFTP server. In the IOS, you configure an IP default gateway with the command ip default-gateway gateway-address where gateway-address is the address of a router interface on a subnet to which your router is physically connected. Default Network The default network, used by IGRP and EIGRP, has only a prefix -- a network or subnet -- so unless internal assumptions are made, there's no way to know the specific next hop address. To specify a default network for IGRP, for EIGRP, or that will be known locally on your router, code: ip default-network ip-prefix The ip-prefix is not a host address as used in the next hop field of an ip route statement, or as the argument of ip default-gateway. It is a network or subnet address (i.e., with zeroes in all the host bit positions). Gateway of Last Resort The gateway of last resort (GOLR) is selected by the process that actually installs routes in the routing table. The GOLR represents the default destination that comes from the source of default that has the lowest administrative distance (AD). So if you had a default static route, it would become the GOLR regardless of anything you received from any routing protocol. If you received a default network from EIGRP or IGRP, that network would become GOLR in preference to anything from RIP or OSPF, unless you changed the administrative distance for RIP or OSPF. An OSPF default would be preferred to anything from RIP. An OSPF Type 1 default would be preferred over an OSPF Type 2 default. IPv4 Evolution The original IP specification, RFC760, did not use classes. The network number was defined to be the first octet. That early "network number" was a prefix. Prefixes are the key to understanding
how addressing and routing really work. Routers really don't care about hosts, but care about prefixes only. Prefixes identify blocks of potential host numbers, and it is to prefixes that routers route. Any IPv4 address is 32 bits long. Routers make decisions based on some number of contiguous bits of this address, starting with the most significant bit on the left. This part of the IP address is called the prefix. Some hosts and older router implementations will let you enter noncontiguous masks. Don't be tempted, because addresses based on noncontiguous masks are both hard to maintain and will break addressing features (e.g., VLSM summarization) beyond the scope of this Tutorial Note: Just because you can do something, it isn't necessarily a good idea. Formally, according to RFCs 1517 and 1518, a prefix is "an IP address and some indication of the leftmost contiguous significant bits within this address." That indication of the leftmost contiguous part - the prefix - has conventionally been done with subnet masks (e.g., 10.1.0.0 with mask 255.255.0.0, the one bits of the mask corresponding to the prefix positions in the address), or more recently with a length indication (e.g., 10.1.0.0/16, the 16 indicating the prefix length). All RFC760-style prefixes, therefore, could have been written as N.0.0.0/8. One bits in the mask must be contiguous from the left. In RFC1812, the current "Requirements for IPv4 Routers" document, patterns such as 255.0.255.0 are now specifically illegal, although earlier specifications were vague on this point [RFC1812]. The three customary IP address classes each define a prefix of a certain length. Ignoring subnetting for the moment, a Class A address has a prefix length of 8, a Class B has a prefix length of 16, and a Class C has a prefix length of 24. Early IP implementations, such as that in BSD 4.2 UNIX, stored no prefix information. Instead, they inferred a prefix length from the class of the address. Later implementations did store a specific subnet mask and thus supported subnetting but still associated one mask value with every address in a specific classful network number. A useful convention in interpreting addresses comes from my book, Designing Addressing Architectures for Routing and Switching:
• P is a prefix bit, used in making routing decisions by the router we are talking about. In classful addressing, the type you will deal with as a CCNA candidate, the prefix bits are composed of the combination of network and subnet bits.
• S is a subnet or sub-prefix bit that identifies a specific medium or group of media within a larger prefix. In the North American telephone hierarchy, area codes are a subdivision of the country code, and in turn have subdivisions called exchange codes.
• X is a "don't care" bit from the perspective of routing at the point of topology we are examining.
• H is a host bit used to locate a specific host on a medium, or to indicate the medium itself (rather than prefix for it) or the broadcast address for that medium.
Think of a postal address, which consists superficially of a street with a building number on the street. It is the job of routers to deliver packets to the final street (medium) on which a destination host -- the building -- will recognize packets. Assume we route based on a single-bit prefix. The notation convention for this length is a /1 prefix. This notation convention was introduced with the current practice for global Internet addressing, Classless Inter-Domain Routing (CIDR). See Chapter 6 of [Berkowitz 1999a] for a discussion of the motivations for CIDR in scaling the Internet. At this point, simply accept that the prefix length notation introduced with CIDR is very useful. I find that the older notation, subnet masks, is harder for beginners to grasp. We will cover subnet masks once the underlying principles are clear. Routers and Prefixes In a router, if the value of the prefix is 0, the packet will leave the router via interface 0. See Figure 10. One Bit Address. If the value of the prefix is 1, the packet will leave the router via
interface 1. In other words, only the first bit of these IP addresses is considered in making routing decisions. The path taken in Figure 10 will be: 0 R1.int0, R1.1.int0 1 R1.int0, R1.1.int1
Figure 10. One Bit Address A single-bit prefix gives us only two possible values. Staying with an essentially trivial example, assume that we have a two-bit prefix and four possible destinations. Each of these destinations is identified by a value of the /2 prefix. These destinations could be reached with four interfaces on one router, or with a tree of three routers.
Figure 11. Two Bit Address Real-world IP addresses have at least 8 bits in their prefixes, and usually many more. Practical routers associate many prefixes with each outgoing interface. In Figure 11, an X in one of the first 8 bits represents a don't-care bit position in making forwarding decisions for this particular routing scenario. Another way to look at the don't-care mechanism is to remember that an IP address is always 32 bits long. If the prefix length (e.g., /8) is subtracted from 32, the result is the number of don't-care bits for router decision making. In other words, decisions are made only on the prefix length number of bits. The information shown in Figure 11 is stored internally in a router as a routing table, also called a Forwarding Information Base (FIB) or Routing Information Base (RIB). A minimal routing table contains a list of destinations and the output interface that should be used to reach them The path taken in Figure 11 will be: 00 R1.int0, R1.1.int0 01 R1.int0, R1.1.int1 10 R1.int1, R1.2.int0 11 R1.int1, R1.2.int1 In these examples, the part of the IP address not included in the prefix bits used for decision making is composed of bits that identify the host on the destination medium, or of bits that will be used for path determination hierarchically lower in the routing fabric. The very first method of assigning prefixes, which was obsolete almost as soon as it was defined, was to define all prefixes as a fixed 8-bit length, as shown in Figure 12. Fixed Prefix
Figure 12. Fixed Prefix This fixed prefix length meant that the remaining 24 bits could be used for host addresses. It was assumed that all host addresses in a given prefix were managed by a central computer such as a mainframe, or were on the same LANs. In 1981, LANs were still primarily a research curiosity, as was the newly introduced personal computer. Unfortunately, interconnection requirements grew quickly, and there were soon more than 200 networks. The first enhancement to the method of assigning prefixes was classful addressing. In 1981, a new convention, RFC 791, was developed to have three standard prefix lengths of 8, 16, and 24 bits, shown in Figure 13.
Figure 13. Classful Addressing Note Pay careful attention to this, because it will affect terminology later on: The original IP address prefix was fixed. With the introduction of different prefix lengths, it was no longer fixed, but variable. Variable-length prefixes have been with us since almost the beginning of IP. Classes RFC 791 controlled the values of the most significant bits (i.e., leftmost) in the prefix to determine the prefix length. These bits were overloaded in that they were part of the address but also encoded how long the prefix was. The encodings are: (Memorize this table!) Table 3. Class Prefixes
IPv4 addresses were (and are) 32 bits long. The three standard unicast prefix lengths meant, respectively, there could be host fields 24, 16, and 8 bits long. Getting Address Space In the original model for assigning IP addresses, the high-order part of the prefix -- the /8, /16, or /24 -- was assigned by a single administrative body. This high-order part was called a network number. Organizations assigned network numbers then would define subnets under them. When we speak of "bits of subnetting," we mean the number of bits to the right that the prefix is extended. Without getting into details of the administrative processes involved, IP addresses are either globally unique (registered), or they belong to the private address space defined in RFC 1918. Three regional registries allocate large blocks of address space:
• American Registry for Internet Numbers (ARIN), serving the Americas and some other locations that do not yet have a regional registry: www.arin.net
• RIPE Network Coordination Centre (NCC) for Europe: www.ripe.net • Asia-Pacific Network Information Center (APNIC): www.apnic.net
Provider Assigned Address Space In practice, most enterprises will receive a part of their upstream provider's registered address space to be used for as long as they are a subscriber of that provider. This is called provider assigned (PA) address space, as opposed to provider independent (PI) address space allocated directly by one of the registries. In general, an organization needs to demonstrate it will have 8000 or more Internet-connected hosts before it becomes eligible for PI space. The reality that most organizations will use PA space means that when you design networks, you should assume that they will be periodically renumbered, for example, if you change providers. Private Addresses Three blocks of addresses are reserved for "private use." Private use means that these addresses should never be seen on the public Internet [RFC 1918]. These blocks are normally described in dotted decimal:
• 10.0.0.0/8, the "8-bit block" that contains the range of addresses 10.0.0.0 to 10.255.255.255
• 172.16.0.0/12, the "12-bit block" that contains the range of addresses 172.16.0.0 to 172.31.255.255
• 192.168.0.0/16, the "16-bit block" that contains the range of addresses 192.168.0.0 to 192.168.255.255.
IP Addresses: Computer Views, Human Views The original IPv4 specification (RFC 760) was issued, with the intention of both being compatible with existing ARPANET addresses and providing growth for the future. Growth, in this context, meant the ability to interconnect over 200 networks. Before discussing the structure of addresses, it is worthwhile to discuss the ways we talk about addresses. You, as a person, are unique. You, however, are addressed differently at different times by different people, in a manner appropriate to the context. Someone might be addressed as "William," "Big Bill," or "Stinky" in different addressing contexts. In like manner, there are different ways to "say" the meaning of an address. The abstract semantics of an address deal with the meaning of address (e.g., its membership in a specific hierarchy). The semantics of an IP address indicate the way it is reached in an IP routing system. Abstract syntaxes deal with human-readable notation for addresses. For IP addresses, this is the "dotted decimal" format. Encodings are machine-readable forms of the address used in protocol data units. IP is encoded as a 32-bit string. Dotted-Decimal Notation is for People, not Routers
Different architectures use these different ways according to their individual rules. All use some form of hierarchy to make addresses. Hierarchical organization may be intended simply to organize network administration, or additionally to maintain worldwide address uniqueness. IPv4 proper is encoded as a 32-bit binary string. Its abstract syntax, however, is called dotted decimal. Dotted decimal, unfortunately, is one of those things that seemed a good idea at the time, but definitely tends to confuse the situation. Its use is so widespread that it's impractical to phase it out directly. IP version 6 uses hexadecimal, a much more rational notation. Admittedly, dotted decimal is easier to remember than binary. Principles of Dotted Decimal Even though the actual IP address is a 32-bit string, with prefix and host field sizes of arbitrary lengths, the dotted decimal convention splits the address into four 8-bit octets such as 160.65.2.66. These octets only have meaning in terms of human convenience and the administrative process of address assignment. The octets really are not seen separately by the routing process. If we begin with the binary string 10100000010000010000001001000010 we can split it into four octets 10100000 01000001 00000010 01000010 • Binary 10100000 has a decimal value of 160 • binary 01000001 has a decimal value of 65 • binary 00000010 has a decimal value of 2 • binary 01000010 has a decimal value of 66 These four eight-bit values are written out as their decimal equivalents, separated by dots: 160.65.2.66 Historically, the class-based assignments of network numbers were done on an octet-aligned basis. This is obsolete. Most confusion about IP addressing comes from (incorrectly) implying meaning to the octets. Here's another example, using the private address space. In binary, we can expand the 8-bit 10.0.0.0 block: 00001010 XXXXXXXX XXXXXXXX XXXXXXXX or the range of values 00001010.00000000.00000000.00000000 to 00001010.11111111.11111111.11111111 These binaries translate to the dotted decimal range 10.0.0.0 through 10.255.255.255. Weighted Binary There are some non-obvious conventions in converting between dotted decimal and binary. Look at the last octet in this example, 01000010, the decimal equivalent of which is 66. Let's assume that, for some reason, we need to split it into two 4-bit fields. If you are a reasonably rational human being, proficient in binary and decimal arithmetic, you will come to the apparently reasonable conclusions that the two fields would be 0100 and 0010, which, respectively, would have the decimal values 6 and 2. This would be perfectly rational, and it also would be wrong for the first field. Dotted decimal notation uses what is called the weighted binary convention. When a field is extracted from an octet, its bits must be evaluated in the same position, relative to the most significant bit on the left, in which the field started. So in this case, the leftmost 4 bits must be evaluated as if they were: 01000000 and the right 4-bit field must be evaluated as if it were: 00000010 The proper value for these fields, if they were to be expressed as part of a dotted decimal expression, would be, respectively, 64 and 2. Subnetting versus Subnet Masks The limited range of three prefix lengths still proved inadequate, and subnetting was introduced as a means of providing more prefix lengths. Subnetting is the general process of extending a
prefix to the right. With classful addressing, subnetting means you are borrowing host bits to extend the prefix. This creates more prefix space. In practice, the original prefix is known at a high level of the hierarchy, and the extended prefixes are usually known only in the lower parts of the hierarchy. "Traditional" subnetting (See Figure 14. Traditional Subnetting) introduced several terms that tend to be quite confusing. If one looks at the process introduced in RFC 950 not as a subdividing -- subnetting -- of existing networks, but more correctly as a general mechanism of prefix extension, the terminology becomes much simpler.
Figure 14. Traditional Subnetting The additional, yet confusing, terms are:
• The process of subnetting: the general process of extending the prefix to the right • Bits of subnetting: the number of bits to the right that a classful network prefix is
extended. • Subnet masks: one means of conveying the total length of the prefix.
In the classic RFC 950 method, subnetting is the process of further subdividing an assigned network number into a set of user "streets." It is a specific form of prefix addressing, based on "classful" addressing, where addressing authorities assign network numbers to organizations, and the user organization extends the routing-relevant part by adding bits from the user field. In a classful system, the original allocation will be /8, /16, or /24. The number of bits of subnetting (m) is the number of bits the prefix is extended by the network administrator, from the prefix assigned by higher authority. When n is the number of basic prefix bits, m =< (30 - n). The basic prefix (n) is assigned by a higher-level administrative authority and given to a network administrator. Subnet masks are really used in two ways:
• Whether you use CIDR or not, the most efficient way to extract prefixes is to build a 32-bit string that is binary ANDed to the address, the result being the network prefix.
• Subnet masks are also a way of telling people or routers what prefix length should be used at a given interface. Either the /slash notation or dotted decimal masks can serve this purpose.
Each traditional class has a "natural" or "default" mask that can be inferred from the value of the first few bits. See Table 4. Table 4. Natural/default Masks
High-order bits Class First Octet Range in Dotted Decimal Natural or default mask
Note: Confusingly, it is said that IP addresses are always associated with a subnet mask, even if the network associated with that address is not subnetted -- that is, extended from a preassigned, ierarchically higher prefix. I far prefer to use the term prefix length, because every IP address has a prefix length, whether subnetted or not. Prefix Length Display Formats Subnet masks are one technique of prefix length notation. The slash or CIDR "/bitcount" format is superior as a notation, but is not as widely deployed in software configuration tools. As of IOS 11.0, most show commands default to using the bitcount, not the subnet mask, convention for showing prefix lengths. You can change back and forth between the subnet mask and "slash" notations by entering the command: terminal ip netmask decimal and change back with terminal ip netmask bitcount Again, remember these are not configuration editor commands, but entered while in the general exec. Extracting Prefixes from Addresses The binary value of a subnet mask, as opposed to the use of subnet masks for a prefix length notation, is the basis of extracting prefixes from the destination address fields of packets to be forwarded.
Figure 15. Extracting Prefixes You extract the prefix from an IP address by a bit-by-bit logical AND operation between the 32 bits of the IP address and the 32 bits of the subnet mask. Essentially, the subnet mask is a bit pattern that will zero out the host field of an IP address. The number of one bits in the mask is the length of the prefix. Reviewing the AND operation When you AND two binary bits together, the result will be zero unless the value of both bits is 1. The truth table for binary AND is: Table 5. Logical AND Operation
Logically ANDing the two binary strings has the effect of zeroing out all bits in the host field of the address, producing the prefix. When a router looks at a specific host destination address in an incoming packet, it uses this logical operation to extract the prefix. The router finds destinations in the routing table not with specific host addresses, but with prefix values. Using the prefix value, rather than the specific host value, is one of the fundamental strengths of routing. If specific host values were used, the router would have to track each address in the network. By using prefixes, the router only needs to track the much smaller number of prefixes, which are associated with destination media. Relationships between subnet masks and prefix lengths are shown, in a classless way, in Table 6, derived from RFC 1878. Table 6. Masks and Prefixes
Table 6 above is fully general for classless addressing. Tables 7 and 8 are more specific for Class B and Class C addresses, using classful assumptions about the all-zeroes and all-ones subnets. Table 7. Class B (/16) Subnetting
Hosts Subnets Subnet Mask
2 32766 255.255.255.252
6 16382 255.255.255.248
14 8190 255.255.255.240
30 4094 255.255.255.224
62 2046 255.255.255.192
126 1022 255.255.255.128
254 510 255.255.255.0
510 254 255.255.254.0
1022 126 255.255.252.0
2046 62 255.255.248.0
4094 30 255.255.240.0
8190 14 255.255.224.0
16382 6 255.255.192.0
32766 2 255.255.128.0
64534 1 (not subnetted) 255.255.0.0
Note that a subset of the subnet masks forms the Class C table. Table 8. Class C (/24) Subnetting
When a host field of m bits is defined, 2m-2 values are available for actual host addresses. In this context, a host can either be an ordinary end host or a router interface. Two values are reserved and have special meaning. An all-zeroes value in the host field, sometimes called "this subnet," effectively identifies the medium itself as opposed to any host on it. It is the all-zeroes value -- the "name of the wire" -- that is stored in routing tables as the destination address. Routers will forward packets to that medium to reach any host on it. Packets sent to the all-ones host field address under a given prefix are broadcast onto the associated medium, assuming the medium is broadcast capable. This value is called the local broadcast address of 32 one bits, usually written as the dotted decimal value 255.255.255.255. All hosts receiving such a packet can "hear" and respond to it as if it were sent to them specifically. When a packet has the local broadcast address as its destination address, it will be broadcast onto the medium on which it originates, but will not be propagated to other media by routers. Cisco provides a feature called ip helper that can forward local broadcasts when there is a good reason to do so, in a well-controlled manner. A broadcast sent to a specific prefix is called a directed broadcast. Directed, as opposed to local, broadcasts are routable. Packets with a directed broadcast address flow through the network based on their prefix but are converted to a local broadcast when they reach the final destination medium. While the CCNA exam will almost certainly ask about directed broadcast addresses, which, on any subnet, are the subnet prefix with all ones in the host field, be very careful about using them in real networks. Applications for distributed broadcasts, in modern networks, seem to be limited to specialized internal functions such as host initialization (e.g., with DHCP and DNS), network management, and possibly database mirroring. Mirroring can be done better with multicasting rather than broadcasting. A very common and nasty, malicious, hacking attack called smurfing depends on directed broadcast to do its damage. As of IOS 12.0, consistent with IETF recommendations, Cisco changed the default behavior on all its interfaces to no ip directed broadcast. You must explicitly enable directed broadcasts if you need them. There is never a good reason to receive a directed broadcast from a packet arriving from the general Internet. So one wise policy is to enable directed broadcasts only on interfaces where they are needed and couple their use to filters that deny any packet with a source outside your internal network. Such filtering should be backed up by filters on all your interfaces coming in from the Internet that also deny packets with source addresses associated with your internal networks. Prefix Practice Try extracting a prefix: given the Class A address, 10.169.100.20/13, with 5 bits of subnetting. You are also given the subnet mask of 255.248.0.0, which is equivalent to 5 bits of subnetting extended from the natural Class A mask. What is the prefix associated with this address? To extract the prefix, write out the binary equivalent of 10.169.100.20 with the binary equivalent of the subnet mask immediately below it: 00001010.10101001.01100100.00010100 11111111.11111000.00000000.00000000 applying a logical AND results in 00001010.10101000.00000000.00000000 10 . 168 . 0 . 0 Let's put the 10.168.0.0 prefix we have just extracted in context: Prefix 10.168.0.0 Host value 0.1.0.0 (address 10.169.0.0) -- Identifies the medium Host values 0.1.0.1 (10.169.0.1) through 0.1.255.254 (10.169.255.254) -- Available for hosts Host value 0.1.255.255 (10.169.255.255) -- Directed broadcast to this specific prefix
Setting Up Simple Address Plans In this section we will begin by examining a single-site addressing system and then look at addressing for basic inter-site connectivity. This simple example does not deal with methods for reducing routing table size, which are discussed in [Berkowitz 1998a].
Figure 16. Single Router Example Let's begin with the configuration shown in Figure 16. Single Router Example, a single router that interconnects four LANs. This router might interconnect four floors or workgroups inside a single building. Assume that there are 40 user workstations and two print servers in each LAN. Workstations and servers are both hosts in IP terminology, so at least 42 host addresses are needed. Remember that a router usually does not have a single network address of its own, but is treated as a collection of interfaces, one on each directly connected medium. This is true of IP, and most protocol families, with the exceptions of DECnet and Banyan VINES. In our IP case, there will need to be a router interface on each medium, bringing the total host requirement to 43. Consider reasonable growth. If we assumed that there might be 25% growth of user hosts, we would need space for an additional 10 hosts, for a total of 53. What kind of network? What Mask? You may be told, as part of a problem, whether to use a Class B or Class C network as your starting point. In either case, or if the decision is yours, you will need to decide first on the size of the host field. There are several things you should consider in this decision:
• Two addresses are not available for hosts: the all-zeroes and all-ones values. Think of the all-zeroes as the identifier for the medium itself, and the all-ones as the broadcast to everyone on that medium but nowhere else -- the "local fire alarm."
• If any traffic will leave the net, you will need at least one address for a router, unless any application hosts can route.
• While you may or may not have growth as part of a CCNA question, it's usually prudent to allow for growth in any addressing plan. While every enterprise will be different, a rough guideline is to allow 20-25% growth. If your organization is applying for its own allocation of address space, you will need to document your assumptions about growth.
In many real-world cases, you would receive several Class C blocks before you would receive a Class B, but effective use of multiple Class C's treated as a unit is beyond the scope of CCNA.
Look at Table 8 to find the number of host field bits that will contain this number of hosts. Table 6 contains the same information in a more general, classless way. Either table will tell you that a six-bit host field will suffice. You have justified a prefix length of /26 to locate this specific medium. In traditional subnet mask notation, this prefix length has a subnet mask of 255.255.255.192. This equates to two bits of subnetting on a Class C, which has a natural mask of 255.255.255.0 or a /24 prefix. When using traditional classful addressing, which assigns addresses only on class A, B, or C boundaries, you would have to round your requirement for a /26 up to a class C /24 block. The more modern CIDR convention assigns not just on "classful" boundaries, but on the boundary justified by your addressing requirements. Addressing Simple Interconnected LANs You have four LANs connected to the router, so you will need four media prefixes, each a /26. You will need two bits to identify four prefixes. Together, the host field and the medium identification bits take up eight bits. The 32-bit IP address, less these eight bits, justifies a /24 prefix. In traditional terms, this /24 is a Class C block with two bits of subnetting. A better way to think of it, however, is that it is a /24 block containing four contiguous /26 blocks (i.e., subnets). We can say these four subnets summarize into the /24. For the prefix 192.168.64.0/24, address assignments are shown in Table 9. Another way to describe this assignment is two bits of subnetting on a Class C. Table 9. Address Assignments for /26 inside a /24
Binary Value of Address Dotted decimal Usage
00000000 192.168.64.0 Identifies the first subnet
First host on first subnet
00000001 through 00111110
192.168.64.1 through 192.168.64.62
Last host on first subnet
01111111 192.168.64.63 Broadcast for first subnet
01000000 192.168.64.64 Identifies second subnet
First host on second subnet
01000001 through 01111110
192.168.64.65 through 192.168.64.126
Last host on second subnet
01111111 192.168.64.127 Broadcast for second subnet
10000000 192.168.64.128 Identifies third subnet
First host on third subnet
10000001 through 10111110
192.168.64.129through 192.168.64.190
Last host on third subnet
10111111 192.168.64.191 Broadcast for third subnet
11111110 192.168.64.254 Last host on fourth subnet
11111111 192.168.64.255 Broadcast for fourth subnet
Configuring IP Addresses into Cisco Routers Actually configuring IP addresses into routers is not very complicated. The difficult part is deciding what addresses to use! Configuration commands will become more complex when you are setting up filtering or dynamic routing, but basic interface addressing is not complicated. Basic interface statments The basic method to configure an IP address on a router is as a subcommand of an interface command: no ip subnet-zero interface e0 ip address 192.168.1.1 255.255.255.0 interface s0 ip address 192.168.0.1 255.255.255.252 You are configuring a host address on an interface, not a subnet address even though the interface belongs to a router. Note that you must configure both the address and a subnet mask, and write them in dotted decimal notation. At the CCNA level, all interfaces belonging to the same classful network must have the same mask. If you attempt to enter an address that, when masked, would have an all-zeroes or all-ones value in the subnet field, the router will return an error message, usually "bad mask." You will also get an error message if you try to code an all-zeroes or all-ones host field value. In your testing, you will probably want to use loopback addresses so you have more interfaces on which you can practice. Cisco loopback interfaces exist only as a result of software definition, but you can configure and use them much like any physical interface. You can delete them, but not shut them down. An example of adding interfaces to show connection to two subnets each on two major networks: no ip subnet-zero interface loop0 ip address 10.1.0.1 255.255.0.0 interface loop1 ip address 10.2.0.1 255.255.0.0 interface loop2 ip address 171.16.5.5 255.255.255.0 interface loop3 Note: Stupid hosts and Classful Addressing When you assign more than one subnet to the same medium, as in Figure 17. Secondary Addressing, you may have performance problems. The router knows perfectly well that multiple subnets map to the same medium, but the hosts may not. As a consequence, the hosts may not send directly to other hosts on the switched medium. Instead, they may insist on sending to the router and having the router forward the packet to the destination. This behavior is especially common on older UNIX hosts, and on Apple hosts that use MacTCP rather than Open Transport. Doing this means the packet must traverse the wire twice, and be handled by the router twice. There are "hacks" you can apply to work around the problem [Berkowitz 1998a]. You can reduce the performance hit on the router by coding ip route-cache same-interface on interfaces where the in-and-out behavior is expected. ip address 171.16.42.42 255.255.255.0
In the long run, this and other problems go away only when you accept completely classless structure for your addressing, and remove all hardware and software that does not understand classless addressing Secondary Addressing Classful addressing is inefficient, because it tends to force users into receiving allocations that are too large (Class B), wasting space, or that are too small (Class C). Having multiple Class C blocks actually works fairly well, but even that doesn't always work because large switched networks often need 500 or more hosts in a single broadcast domain. Until the much more flexible methods of classless addressing are much more widely accepted, workarounds are necessary, One technique widely used is to map more than one logical address (secondary addresses) to the same physical interface, as shown in Figure 17. Secondary addresses are coded much like regular addresses, with the additional keyword secondary: no ip subnet-zero interface ethernet0 ip address 10.1.0.1 255.255.0.0 ip address 10.3.0.1 255.255.0.0 secondary In Figure 17. Secondary Addressing, secondary addresses are being used to make more than 500 interfaces available on the switched subnet.
Figure 17. Secondary Addressing A few other caveats apply to using secondary addressing. All routers connected to the same medium should have the same set of secondary addresses. Do not put one secondary address on one router and two secondaries on the others. The primary address should be in the same subnet on every router and the secondaries should be in the same order: if 192.168.2.0/24 is the first secondary address on one router and 192.168.3.0/24 is the second, do not put 192.168.3.0 as the first secondary address on a different router connected to the same medium. Subinterfaces Subinterfaces might at first seem similar to secondary addresses, but they are significantly more flexible. You most commonly use subinterfaces with NBMA services such as Frame Relay.
Note: When you use point-to-point subinterfaces, the most efficient use of address space is to give them /30 prefixes (i.e., the mask 255.255.255.252). Variable-length subnet masks are most common for providing this address space. Subinterfaces solve quite a number of problems with the interactions of NBMA media and routers. See the CCNA WAN Protocols Tutorial for more detail on their use. As a quick example, if you had a single serial interface over which three Frame Relay virtual circuits were established, you would code: no ip subnet-zero interface s0 encapsulation frame-relay interface s0.1 point-to-point bandwidth 128 ! the CIR in Kbps ip address 192.168.1.5 255.255.255.252 interface s0.1 point-to-point ip address 192.168.1.9 255.255.255.252 bandwidth 64 interface s0.1 point-to-point ip address 192.168.1.13 255.255.255.252 bandwidth 512 Conclusion IP addressing is one of the most fundamental skills in networking. Addressing techniques have continued to evolve, but the CCNA focuses on the obsolete classful methods. Whenever you take a Cisco examination, be sure, on every question involving addressing, whether the assumption is that the problem is defined for a classful or classless environment. One good tip is that the environment is classless if the ip subnet-zero option is coded. There are a few other commands that become involved in classless routing, such as no auto-summary and ip classless, but they are beyond the scope of this discussion. References [Berkowitz, 1998a] Berkowitz, H. Designing Addressing Architectures for Routing and Switching. Indianapolis, IN: Macmillan Technical Publishing, 1998. [Huitema] Huitema, C. Routing in the Internet. Englewood Cliffs: Prentice-Hall, 1995. [RFC0760] J. Postel. "DoD standard Internet Protocol." 1980. [RFC0791] J. Postel. "Internet Protocol." 1981. [RFC0950] J. Mogul, J. Postel. "Internet Standard Subnetting Procedure." J1985. [RFC1517] R. Hinden. "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)." September 1993. [RFC1518] Y. Rekhter, T. Li. "An Architecture for IP Address Allocation with CIDR" 1993. 3.2 Lab Abstract 1. Implement an addressing plan. Compare your configuration with the suggested configuration. 2. You are told that the Ethernet in the previous example must provide address space for at least 500 hosts. A second Ethernet will interconnect two of the routers, and must have address space for no more than 126 hosts. Develop a configuration that shows appropriate subnetting. Write a configuration that reflects efficient subnetting for the two Ethernets. Serial line interfaces do not change. Provide correct ip host statements 3.3 Lab Scenario IP Addressing Lab Scenarios Objective 1 Implement up the addressing plan shown in Figure 1. Compare your configuration with the suggested configuration.
Figure 1 Sample Configuration Router allspice no ip subnet-zero hostname allspice ! int e0 description shared Ethernet ip address 172.16.1.4 255.255.255.0 ip directed-broadcast int s0 description serial link to bay ip address 192.168.255.5 255.255.255.252 int s1 description serial link to chives
ip address 192.168.255.13 255.255.255.252 router rip network 172.16.0.0 network 192.168.255.0 ip host bay 172.16.1.1 ip host chives 172.16.1.3 no ip domain-lookup no service config Router bay no ip subnet-zero hostname bay ! int e0 description shared Ethernet ip address 172.16.1.1 255.255.255.0 ip directed-broadcast int s0 description serial link to allspice ip address 192.168.255.6 255.255.255.252 int s1 description serial link to chives ip address 192.168.255.9 255.255.255.252 router rip network 172.16.0.0 network 192.168.255.0 ip host allspice 172.16.1.4 ip host chives 172.16.1.3 no ip domain-lookup no service config Router chives no ip subnet-zero hostname chives ! int e0 description shared Ethernet ip address 172.16.1.3 255.255.255.0 ip directed-broadcast int s0 description serial link to chives ip address 192.168.255.14 255.255.255.252 int s1 description serial link to bay ip address 192.168.255.10 255.255.255.252 router rip network 172.16.0.0 network 192.168.255.0
ip host allspice 172.16.1.4 ip host bay 172.16.1.1 no ip domain-lookup no service config Practice with commands Fill in the following table:
Description Subnet address Broadcast address
Allspice-Bay
Allspice-Chives
Bay-Chives
What are the MAC and IP addresses that allspice will use to ping the serial 1 interface on chives? Do a show interface on an Ethernet interface and note the counter values. What happens if you ping to the broadcast address? Objective 2 You are told that the Ethernet in the previous example must provide address space for at least 500 hosts. A second Ethernet, shown in Figure 2, will interconnect Bay and Chives, and must have address space for no more than 126 hosts. Develop a configuration that shows appropriate subnetting. Write a configuration that reflects efficient subnetting for the two Ethernets. Serial line interfaces do not change. Provide correct ip host statements.
Sample Configuration Router allspice no ip subnet-zero hostname allspice ! int e0 description shared Ethernet ip address 172.16.2.33 255.255.254.0 ip directed-broadcast int s0 description serial link to bay ip address 192.168.255.5 255.255.255.252 int s1 description serial link to chives ip address 192.168.255.13 255.255.255.252 router rip network 172.16.0.0 network 192.168.255.0 no ip domain-lookup no service config Router bay no ip subnet-zero hostname bay ! int e0 description shared Ethernet ip address 172.16.3.34 255.255.254.0 ip directed-broadcast int e1 description backup Ethernet ip address 172.17.1.129 255.255.255.128 int s0 description serial link to allspice ip address 192.168.255.6 255.255.255.252 int s1 description serial link to chives ip address 192.168.255.9 255.255.255.252 router rip network 172.16.0.0 network 172.17.0.0 network 192.168.255.0 no ip domain-lookup no service config Router chives no ip subnet-zero
hostname chives ! int e0 description shared Ethernet ip address 172.16.2.35 255.255.254.0 ip directed-broadcast int e1 description backup Ethernet ip address 172.17.1.130 255.255.255.128 int s0 description serial link to chives ip address 192.168.255.14 255.255.255.252 int s1 description serial link to bay ip address 192.168.255.10 255.255.255.252 router rip network 172.16.0.0 network 172.17.0.0 network 192.168.255.0 no ip domain-lookup no service config Questions Did you avoid subnet zero? Remember, CCNA looks for classful addressing. Why are there only two network statements on allspice? 4 IP Routing IP Routing, 2nd Edition This Study Guide covers the base level routing knowledge required of CCNA candidates when attempting the CCNA written exam. This is not an exhaustive coverage of these concepts; however, the information contained in this Tutorial will greatly prepare you for questions relating to routing concepts and the distance vector routing protocols RIP (both RIPv1 and RIPv2) and EIGRP. Note: This Study Guide gives a thorough coverage of RIP, EIGRP, Distance Vector routing protocols, and general routing concepts. It does not, however, directly address IGRP, which is still (as of November 2002) listed as covered on Cisco's CCNA exam (EIGRP is not). Cisco has stated publicly that EIGRP will be covered on future versions of the CCNA exam and that IGRP will eventually be phased out. In the meantime, for information about IGRP, see the first edition of the IP Routing Study Guide. 4.1 Tutorial There have been several changes recently to the CCNA (640-607) written examination. Most notable of these changes is the inclusion of simulated router configuration tasks and added emphasis on RIPv2 and EIGRP. This Tutorial will present all the information necessary to help you understand these protocols and also prepare you for this exam. There's No Such Thing as Routing Let's begin by discussing what a "router" does. A definition that occasionally shocks people, but that actually will prepare you best for modern routing, is that there is no single thing called "routing." Instead, there are two closely related functions: path determination and packet forwarding. Cisco sometimes calls packet forwarding switching or packet switching. Both
functions traditionally have been implemented in a single box called a "router," but newer techniques may split them into different processors in the same box, or even different boxes. If you think of a packet taking an automobile journey, path determination is the preparation for travel, the drawing of the map. Packet forwarding is the actual drive, both handling the car in traffic and knowing when to change lanes and which exits to take. Another, more formal way to look at what a router does, in a manner that makes it much more comparable to bridges and switches, is to think of it as a relay. While the term relay is not widely used in the industry, the definition here comes from little-known extensions to the original OSI model that dealt specifically with routing. Relaying Sales information and the trade press have thoroughly confused the terminology for devices that relay frames and packets inside networks. To bring some clarity to the issue, let's do away with the terms router and switch. Instead, we have relays that operate at different layers. A relay accepts a Protocol Data Unit (PDU) associated with its layer on incoming interface(s), and either drops the PDU or forwards it out one or more incoming interfaces. "Pure routers" are Network Layer relays. "Pure bridges (or LAN switches)" are Data Link Layer relays. In this Tutorial we are concerned with Layer 3 relays. What the industry historically calls "routers" determine paths based on Layer 3 information. What the industry historically calls "bridges" determine paths Note’ What Is a Switch, Anyway? based on Layer 2 information. (See Table 1.) There really is no rigorous definition of "switches." In the context of Layer 2, a LAN switch is a bridge that microsegments, i.e., connects each device to its own physical port, giving the impression that devices are no longer contending for access to bandwidth. "Layer 3" or "multilayer" switches most commonly are devices that distribute the forwarding function into specialized integrated circuits, improving performance over those that forward in general-purpose computer chips. In other words, a Layer 3 or multilayer switch is really a marketing term for a router with hardware assistance, and possibly enhanced Layer 2 services (e.g., Cisco 3550 and 6500). At any given layer, relaying has two parts:
• Path determination, in which the "map" of the network is, in effect, examined for best paths. The relay may learn of a potential route from several sources and choose the route it considers "best." Path determination creates a Routing Information Base (RIB). On Cisco routers, you display the RIB with the show ip route command. RFC 1812 defines the basic rules for route preference, but all major router implementations have additional rules.
• Forwarding, in which PDUs move from one router or switch port to another, in microseconds or nanoseconds. Layer 3 relays use a Forwarding Information Base (FIB) to look up the destination and find the outgoing interfaces. You can display FIBs with various show route-cache commands specific to the switching mode in use.
Routed, Routing, and Transport Protocols Routed protocols, such as IP, are the protocol messages handled by Layer 3 forwarding. Routing protocols are carried inside routed protocol packets and convey information about the map of the network. Most discussions of routing protocols focus on those protocols that exchange routing information between routers. This information exchange is usually hidden from end hosts. In basic discussions of routing information exchange, we are talking about routing inside a set of routers under common administration. Such a set is called a routing domain, or, more recently, a routing realm. Routing information exchange protocols that operate within a single domain are called Interior Gateway Protocols (IGPs). Routing information exchanges between domains under different administrations and with different policies are the much more advanced functions carried out by exterior gateway
protocols. The only exterior protocol in significant use is the Border Gateway Protocol, version 4 (BGP-4). BGP is not an alternative to IGPs. It serves different functions and cooperates with IGPs. Basic discussions of routing exchange also deal with drawing the appropriate network map for unicast packets. As with exterior routing, there are additional protocols that build on top of unicast IGPs for drawing multicast routing tables. The details of multicast routing are far beyond the CCNA level, but you should be aware that multicast routing protocols exist. Internet Control Message Protocol (ICMP) There are also routing interactions between end hosts and routers, such as Internet Control Message Protocol (ICMP). ICMP is a required part of every IP implementation. It would be difficult to troubleshoot a network without ICMP, which forms the basis of the ping command. When you issue the ping command from a Cisco router, the IOS starts a timer and sends an ICMP echo request message to the destination. When the destination IP address receives the echo request, it responds with an echo reply. When the original sender receives the reply, it stops the timer and displays its value. ICMP also is the means by which hosts and routers signal many error messages such as destination unreachable. Routers signal destination unreachable when the destination of a packet cannot be found in their routing tables. Hosts issue the message when the TCP or UDP service requested by the packet is not supported on that destination host. Like destination unreachable, the ICMP time to live exceeded message has different meanings when issued by a router or by an end host. In every IP header is a Time-to-Live (TTL) field, which is really a counter. Each router in a path, when it forwards a packet, decrements the TTL field by 1. When the TTL field reaches 0, the packet is assumed to be in an infinite loop. The router discards the packet and sends a TTL exceeded message to the source address in the packet's IP header. TTL exceeded also is used by hosts. When a packet is fragmented into multiple smaller packets, the destination host starts a TTL timer on receiving the first of the packets. If it does not receive all of the fragments before the timer expires, it throws away the fragments it has, and then sends TTL exceeded back to the originator. Transport Where routed protocols describe your car, and routing protocols give the directions, transport protocols are concerned with your end-to-end journey. Historically, the Transport Layer in Internet stacks was called the end-to-end or host-to-host layer, but common practice today is to call it the Transport Layer. The main Transport Layer protocols in the Internet stack are the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP is connection-oriented and provides flow control and error control using retransmission, while UDP is connectionless and provides only error detection. If you work with voice or video applications, you may see references to the Real Time Protocol (RTP). RTP has an associated Real Time Control Protocol (RTCP) whose acronym is unfortunate, because RTCP has nothing to do with TCP. RTP actually runs over UDP. What's the Problem You Are Trying to Solve? Routing, as opposed to bridging, splits the enterprise network into logical segments isolated from one another's Layer 2 overhead. Since routers track only the segments, not the individual host MAC addresses of bridging, routing is more scalable. In general, the workload involved in routing is proportional to the number of segments, while in bridging, the workload is proportional to the number of devices. Hierarchical routing reduces the workload even further and increases stability. In hierarchical routing, the router groups together blocks of segments, and often can safely ignore the details of the segments. At the CCNA level, you see hierarchical routing in the idea of summarizing subnets into networks. Routers help you control traffic, especially broadcast and multicast traffic. If you think of segments as media, routers also help in converting from one medium type, such as Ethernet, to another, such as serial or Fast Ethernet.
Broadcast Control What you will find most important is that "local" broadcasts -- those with a destination address of 255.255.255.255 (which equates to 32 one bits in binary) -- will not be forwarded across a router interface:
Figure 1. In Figure 1, devices on subnet 172.16.1.0/24 do not see broadcasts on 172.16.2.0/24. Since broadcasts can place a heavy load on CPU performance, this is a good thing for 172.16.1.0/24. Note: IP may not be your most important problem. If you are sharing the physical Ethernet, to which the logical network 172.16.2.0/24 is mapped, between IP and NetBEUI, there will be a great many How Many Broadcasts Is a Lot? Well-designed IP stacks do not generate huge numbers of broadcasts. They will perform DHCP and DNS queries to find their own addresses and those of servers, and they will ARP to find destinations. Some IP application protocols, especially ones that run over UDP, generate lots of broadcasts. For some strange reason, medical applications seem to include more broadcasts than any other IP application. NetBEUI broadcasts Media Conversion Another major benefit of routing is its ability to convert smoothly between different medium types. The Network Layer with which routers deal is logically independent of the underlying medium type. In the CCNA objectives, Cisco asks you to "define and explain the 5 conversion steps of data encapsulation." Reasonably, you might ask, what happened to seven? As is common practice, the Cisco objective has the hidden assumption that the upper layers are a single unit.
"User data" Application programs, which are not the same as the application layer, produce this data. The upper layers produce user data appropriate for transmission over a communications network.
Frames When a router receives a frame, it strips off the data link information and passes the packet it contains to the routing function. When the routing function forwards a packet, it sends it to an outgoing logical interface. At this interface, the packet is wrapped into a frame type appropriate to the destination medium. The incoming and outgoing media, therefore, are completely independent.
Bridge/switch
Physical Layer Bits Repeaters, hubs
Introducing Hierarchy Routers introduce one level of hierarchy by summarizing the set of hosts on a segment into an address for the segment as a whole, the IP subnet address. There can be additional levels of hierarchy. The early, classful IP routing system assumed that there were three natural network types. Table 2. Classful Addresses
A classful router, as shown in Figure 2, sends a routing announcement onto a different major network and summarizes all subnets into a single announcement for the network as a whole.
Figure 2. Basic Summarization Modern addressing and routing summarizes at multiple and arbitrary levels, not just the network/subnet level. (See "Summarization Issues.") Routers remain the fundamental devices that implement summarization. Review of "Traditional" Distance Vector Protocols The original form of routing protocols was based on distance vector routing principles. Both RIP and EIGRP are based on distance vector algorithms, although EIGRP is considered an advanced distance vector routing protocol. In distance vector routing protocols, each node advertises (usually by broadcasting) all the destinations it knows to its neighbors (any routers that may be reached directly, without passing through other routers). The reachability information is announced in the form of:
• Distance -- The cost of reaching the particular destination (do not confuse with cost as used in link state protocols, such as OSPF; here, cost means the path length or distance, which may be measured, for example, in hops or delay).
• Vector -- The direction packets should take to reach that destination (expressed as the next-hop address).
The distance vector algorithm, referred to as the Bellman-Ford or Ford-Fulkerson algorithm, requires that a router maintain a single routing table of routes from itself to the destination network associated with their metric and forwarding path (denominated by the router's outgoing port and/or the neighbor's incoming port address). Routing information is augmented with a path characteristic. (Different implementations use different information.) Distance vector protocols can
be distinguished by the fact that they advertise distance and vector information for each network and use this information to update their routing tables. The basic algorithm uses a principle of advertising every known route to all directly connected neighbors and choosing the path with the best metric. Because more than one neighbor router may exist on the directly connected network (in the case of multi-access networks, such as LANs) and the information advertised to them is identical, sending separate messages to each of them is inefficient. Therefore, broadcasting or multicasting is used when a sending router simply sends a single message to the multi-access segment without knowing how many routers are actually listening. Distance vector protocols may suffer from temporary routing loops; several remedies described later were added to prevent this. Distance Vector Protocol Operation The router starts building its routing table just after the initial configuration information (i.e., information about the directly connected segments) is provided by the administrator. Hence the very first routing table reflects only limited knowledge of the outside world (with the minimum metric for connected links: 0 or 1 hops). The following information relates to all distance vector routing protocols, but we will use RIP as the example in our focus. When the protocol is enabled on a router (or RIP is enabled on an interface), or when the router is started up with the appropriate RIP configuration, the router will first send a request for a routing update (copy of the routing table) from its (so far unknown) neighbors (any RIP speakers that may be reached directly, without passing through other routers). Unlike EIGRP, earlier distance vector routing protocols such as RIP do not maintain any formal relations with neighbor routers. They do not need to store information about neighbors in a separate database. Thus they perform no neighbor discovery and do not have a mechanism separate from periodic update to check the reachability of neighbors. More modern protocols such as EIGRP have a hello subprotocol, which allows update-only transmissions since the sending router knows the remote router is still active. When sending a routing update to its neighbors, the router uses their corresponding Network Layer address. When neighboring routers receive the routing message, they use the source network address from that packet header as the next-hop address. Once the router hears from its neighbors, it will start periodic broadcasts of routing updates. The routing information of this new router will be broadcast to all its neighbors (that is, a local broadcast address will be used, e.g., 255.255.255.255 for IP). Note that RIP does not "broadcast in the blind," but starts periodic broadcasts only after it receives a RIP message. For the following, let's consider the simple situation when a single distance vector routing protocol (for a routed network protocol) is enabled, and thus the routing table will contain only the information derived via this distance vector routing protocol. Otherwise, if multiple routing protocols were enabled for a network protocol, the candidate route for entry into a routing table would be determined by:
• New route -- If the route is not in the table, or is more specific than any existing route, it will be added.
• Prefix -- The most specific (longest prefix) route will be selected when a router has to choose among different routes presented to the routing table maintenance task by different routing processes. For example, a summary route from the latest, greatest OSPF implementation will be overridden by a RIP subnet route from an old UNIX box.
• Administrative distance (trustworthiness of the routing information source based primarily on its quality) -- The information on the route to a particular distance coming from the most trustworthy source will enter the routing table. For example, consider a network that is running both RIP and IGRP. Both routing protocols discover different routes to the same network. The router will use the route advertised by the routing protocol with the lowest Administrative Distance (AD) -- in this case IGRP with an AD of 100, as the AD of RIP is 120.
• Metric -- Administrative distance alone is not sufficient to decide whether to replace an existing route of the same administrative distance and specificity, if the source of that
route is a dynamic interior routing protocol. To make the installation decision in that case, the metric is considered.
Building Network Knowledge The steps in building a routing table on router startup are shown in Figure 3. First, the three participating routers in the distance vector routing process will have their initial routing tables manually built by their administrator. These initial routing tables contain only the information about the routes to directly connected networks.
Figure 3. Initial Stage of DV Routing After proper configuration of the particular routing protocol, the routers perform the first exchange of routing tables by broadcasting them to their neighbors. The situation after the first exchange is shown in Figure 4.
Figure 4. First Exchange of DV Routing Tables Only after the next exchange of routing tables will all routers in this simple network get to know about all the reachable networks and know what neighbor to use for forwarding the packets with the particular destination address. Their complete routing tables are shown in Figure 5. After that,
the routers will periodically exchange routing tables to be kept up to date about the reachable networks and available neighbors.
Figure 5. Convergence of DV Routing At a certain moment the router will "know" the internetwork, but only from its limited point of view: it will know it can get to the destination networks via its neighbors. However, it will have no idea of the overall network topology, as the information gathered and computed says only what neighbor will be contacted to forward packets to the destination and what the distance is. The router is therefore capable of routing while knowing only routes via its neighbors, not considering and knowing the network topology. Due to this way of passing the routing information, distance vector Note: Routing Update Processing A router compares new information from its neighbor(s) with its routing table and updates it accordingly: If there is no such route, it adds a newly learned route (increasing the metric received from the neighbor by the distance to the neighbor, i.e., one hop, the length of the path to the neighbor) and starts its aging timer. If there is a route via the same neighbor, it updates the route metric and starts its aging timer. routing is colloquially called routing by rumor. If there is a route via different neighbors, it compares the metrics. If the new metric is better, it replaces the former routing table entry with the new one and starts its aging timer. If the metric is the same, depending on the particular distance vector protocol, the new route may be added as a parallel route to the destination for load balancing. If the metric is worse, it is ignored. Change in Topology The process of passing the updated information and the steps required before routers converge are shown in Figure 6.
Figure 6. Distance Vector Routing -- Steps after a Change in Network Topology Upon receipt of different metric information included in a routing update from a neighbor, the router has to decide how to handle the information. Unless the current router's information about the network is that it is unreachable, it will always prefer the new route if it is shorter (with better metric) and will replace the older information with the new route. Other cases are shown in the sidebar. Once a route is added to the routing table, it starts aging, and every time an update is received for the route, the aging starts over. If the age timer expires, the route is marked as unreachable (using an infinity metric, such as 16 in the case of IP RIP), and the so-called garbage collection timer starts. Such routes are advertised to neighbors as unreachable and removed from the routing table after garbage collection expires. Until then they are used also for packet forwarding (no better route is known at this stage). A new update on that route or a new route will override the routing table entry. Note: Periodic vs. Triggered Updates Periodic updates contain the entire routing table and are sent at specified intervals. Triggered updates are sent after a topology change occurs, e.g., an interface goes up or down, a route becomes unreachable or reachable, or a new route is added. They contain only information on modified routes. To avoid floods of triggered updates in case of flapping interface(s), distance vector routing protocols' implementations limit their frequency (after 1 to 5 seconds following the last triggered update). Routing Updates In the initial version of distance vector routing protocols, only periodic exchange of routing information was used even if some changes in the network occurred during the specified period. Later it became possible to send triggered updates (sometimes called flash updates) on some changed situation in the network (link added or down, etc.). Broadcasting the current networks is not the behavior of choice: in a large network, periodic broadcasts may result in a significant volume of overhead traffic. More selective multicasting of the routing information is employed in RIPv2. The routing updates are then sent to the reserved multicast address assigned to routers participating in the routing protocol operation within the network. Periodic updates make RIP easy to troubleshoot.
Once a router calculates each of its distance vectors, it sends the information to each of its neighbor routers on a regular basis, such as every 30 to 90 seconds. If any changes have occurred in the network, the receiving router will modify its routing table and transmit it to each of its neighbors. Typical distance vector routing protocols send the whole routing table. Advanced distance vector protocols send only incremental updates. This process will continue until all routers have converged on the new topology. Note: A good discussion on the distance vector routing algorithm, its operation, and solutions to problems can be found in RFC 2453 ( http://www.ietf.org/rfc/rfc2453.txt). Note: Characteristics of Distance Vector Protocols Summarized Simple implementation; well proven in internetwork history Simple metric (usually with some limit in terms of path length) Broadcast of routing information (routing table), which could be wasteful of bandwidth Susceptibility to routing loops Slow topology convergence in large networks Distance Vector Routing Issues Distance vector routing is extremely simple; however, with this simplicity come many potential problems. Due to periodic exchange of routing tables between neighbors, the routing information permeates through the network very slowly, step by step, which contributes to slow network convergence. Note: Convergence is the process of agreement by all routers on network Network Convergence topology (and, in effect, optimal routes). When a network event causes routes to either halt operation or become newly available, routers distribute routing update messages. Routing update messages permeate networks, stimulating recalculation of routing tables and eventually causing all routers to agree on existing routes. Routing algorithms that converge too slowly can cause routing loops or network outages Convergence As the measure of common understanding of the network topology shared by all routers, convergence time is a major benchmark of routing protocols. Loss of convergence, leading to network downtime, can be caused by a change in the status of either a router or a link. The process of (re)gaining convergence may require recalculating the routing tables if there is a topology change. Therefore, routers must converge quickly before those routers with incorrect information misroute data packets into dead ends. Network size and hop count limitations are the main factors determining distance vector routing protocol convergence. Loop Detection and Prevention While IP routing protocols attempt to establish loop-free routes, almost all protocols can lead to looping during transient conditions, for example, during the period immediately following the failure of a link. There are two basic ways to tackle loops:
• Loop prevention -- preventing the formation of a looping path before any packets are sent on it
• Loop detection -- taking steps to minimize the negative effects of loops Since most IP routing protocols cannot prevent the formation of transient loops, IP forwarding uses the detection approach. The Time-to-Live (TTL) field in any IP datagram is decremented at every IP hop; if it reaches 0, the packet is assumed to be looping and is discarded. When packets stuck in loops are discarded, the routers in the looping path are not overwhelmed with packets that must be forwarded, and they can devote their resources to updating the routing tables. Once the routing tables are stable, the loop should be broken (unless a configuration error has been made in one of the routers).
As we introduced TTL here, note that routing packets (as opposed to packets with user data) go only to neighbors. The IP TTL should be set to 1 or 2: both RIPv1 and v2 set the TTL to 2. TTL in the IP header has nothing to do with hop count, which is encapsulated in the distance vector protocol messages. The router has two jobs: path determination and packet forwarding. Hop count has to do with the former and affects what goes in the routing table, while TTL affects the latter. Routing Loop Prevention Unless a remedy is provided inherently by the protocol, a routing loop might easily occur in a mesh network (a network allowing multiple paths between destinations). A routing loop disallows some packets from being properly routed due to the incorrect routing information circulating in the network. The symptom of such a routing loop is counting to infinity (see Figure 7): while routing updates on an unreachable network are incorrectly replaced by the older routing information, the metric when passed from router to router gradually increases. Unless some limit is put onto the metric indicating that the network is unreachable (for IP RIP it is 16 hops), the routing loop will be infinite. However, this infinity determines the maximum diameter of the particular network, and the network administrator should carefully check whether this limit fits the network reality.
Figure 7. Routing Loop Creation Three modifications to the distance vector protocol have been developed in an attempt to reduce the chance of routing loops:
• Split horizon -- Prevents loops between adjacent routers. Rule: Never advertise a route out of the interface through which you learned it!
• Poison reverse -- Prevents larger loops. Rule: Once you learn of a route through an interface, advertise it as unreachable back through that same interface!
• Holddown timer -- Prevents incorrect route information from entering routing tables. Rule: After a route is advertised as down, do not listen to routing updates for that route for a specific period of time!
Each of the above mechanisms may be used in combination with the others. Indeed, Cisco supports both split horizon and poison reverse (setting the metric to infinity or 16) in its IP RIP implementations. Split Horizon Split horizon is a technique used to reduce the chance of routing loops. Split horizon states that it is never useful to send information about a route back in the direction from which the information came and therefore routing information should not be sent back to the source from which it came. In fact, only the interfaces are considered for the direction, not the neighbors.
Note that this rule works well not only for routes learned via a distance vector routing protocol but also for routes installed in a routing table as directly connected networks. As they reside on the same network, the neighbors do not need any advertisements on a path to that shared network. The split horizon rule helps prevent two-node (two-neighbor) routing loops and also improves performance by eliminating unnecessary updates. Poison Reverse Whereas split horizons should prevent routing loops between neighbor routers, poison reverse updates are intended to defeat larger routing loops. While the simple split horizon scheme omits routes learned from a neighbor in updates sent to that neighbor, split horizon with poison reverse includes such routes in updates, but sets their metrics to infinity. Poison reverse thus establishes a single direction through which routes can be reached via a particular interface. Such an interface should not be traversed in the opposite direction to reach a particular destination. Poison reverse ensures this single direction by blocking the other way (by poisoning it with a high cost, such as infinity in the case of RIP). Its effect is best seen in the following situation: once a router discovers it has lost contact with a neighboring router, it will immediately forward a routing update with the inoperable route metric set to infinity. Additionally, the router will broadcast the route, with an infinite metric, for several regular routing update periods to ensure that all other routers on the internetwork have received the information and gradually converge. Cisco also employs so-called route poisoning. This technique is used, upon learning about the unreachable destination, to advertise the information on the failed route by sending a route update with an infinite metric. Poison reverse is usually used in conjunction with split horizon; thus the mechanisms work together to prevent routing loops (a potential danger with distance vector routing). Poison reverse is also used in conjunction with holddown timers. Holddown Timer Holddown is a process in which a router, after receiving destination unreachable information from a neighbor router, will not accept new routing information from that router for a specified period of time in order to prevent regular update messages from inappropriately reinstating a route that has gone bad. It is used due to the possibility that a device that has yet to be informed of a network failure may send an invalid regular update message (indicating that a route that has just gone down is still good) to a device that has just been notified of a network failure. In this case, the latter device now contains (and potentially advertises) incorrect routing information. In other words, holddown means: let the rumors calm down and wait for the truth. Note: Holddown Timer After learning that a route to a destination has failed, a router enters a holddown state while it waits for a certain period of time (controlled by a holddown timer) before believing and accepting any other routing information about that destination. This helps prevent transient routing loops caused, for example, by unstable (flapping) routes Holddown operates as follows: once a route is marked as unreachable, the router starts the holddown timer instead of the garbage collection timer (discussed later in this Tutorial). The route in a holddown, however, is still used for packet forwarding. When a routing update is received for a route in holddown, the update is ignored. As a consequence, the network routers cannot converge on alternative paths until the holddown for the route expires on all relevant routers. On expiration of the holddown timer, the route goes into garbage collection (unless an update for that route arrives). A holddown timer tells routers to hold down any changes that might affect routes recently advertised as unreachable for some period of time. The holddown period is usually calculated to be just greater than the period of time necessary to update the entire network with a routing change. Holddown prevents the counting to infinity problem (gradually increasing metric due to ping-pong of routing updates between neighboring routers pointing to one another for a route). An additional benefit of holddown is that it prevents a situation where routers begin thrashing,
attempting to converge. This is a common occurrence where a link is flapping from operable to inoperable and back in a short period of time. Holddown timers help in handling new routing updates for recently announced unreachable networks (marked as such in the routing table) in the following way:
• If an update arrives from a different neighboring router with a better metric than originally recorded for the network (before it became unreachable), the router removes the network from unreachable state, uses the new metric for the route, and stops the holddown timer.
• If an update is received from other than the originating neighbor with a poorer metric, it is ignored (this could be the routing information looped in the internetwork before all routers converge as shown in Figure 7 above).
While holddown helps inhibit the formation of routing loops, it may have an adverse impact on the convergence. Due to this side effect, holddown is not used commonly in all distance vector routing protocols; however, Cisco's implementation of IP RIP does use it. Other Timers Besides the holddown timer, distance vector protocols utilize other timers to allow for network convergence and for accurate routing tables (these will be discussed in more detail later in relation to RIP):
• Routing update timer -- The period after which each router will send a complete copy of its routing table to all its neighbors.
• Route invalid (expiration) timer -- Determines how much time must expire without a router having heard about a particular route before that route is considered invalid. When a route is marked invalid, neighbors are notified of this fact.
• Route flush (garbage collection) timer -- After it expires, the route is removed from the routing table.
Invalid and garbage collection timer values must be chosen to achieve a trade-off between the rapid recognition of a failed router and the prevention of a spurious failure indication, which can generate extra routing traffic. If the expiration timer is too short, after a single routing update is missed, routing messages are broadcast into the network about a dead route. At the other extreme, too long an expiration timer may cause an undetected dead router, which can become a potential black hole in the network. Note: Summary of Distance Vector Pros and Cons Advantages -- Simplicity of implementation (configuration and administration) Disadvantages -- Routing loop danger (cured by embedded mechanisms); periodic overhead (network load; slow convergence) How Do Routes Get into the Routing Table? The general mechanism for installing any route in the main routing table is discussed in the more advanced "Routing Principles and IOS Implementation" Tutorial. It's worth reviewing several points here, however, focusing on the parts that an IGP will encounter. It is the routing table installation task, not the individual routing protocols, that makes the Note: RIBs and FIBs In high-performance routers, the "routing table" is not really a single memory area. When you do a show ip route, you are really displaying what is properly called a Routing Information Base (RIB). When you do show ip bgp, you are seeing potential inputs to the RIB. decisions on which routes to install. A RIB is optimized for updating by routing protocols. It complements the Forwarding Information Base (FIB), which is optimized for high-speed destination lookup. Cisco has a variety of FIBs; some are simply lookup-optimized tables in main memory, and others are in hardware-assisted lookup chips. See the Tutorial "Routing Principles and IOS Implementation" for more detail. Previously Unknown Route
First, when the routing table installation task receives a potential route, it will install it if the destination was not previously known. "Not previously known" means that the destination address matched no entry in the RIB (except a default route, if present). More Specific Route If an existing entry matches the route, but is less specific, the route just received is added. "Less specific" means that the route in the RIB matches the destination with a lesser number of prefix bits than does the new route. Another way of putting this is that a more specific route has a subnet mask with more one bits: 255.255.0.0 is more specific than 255.0.0.0. For example, assuming your routing table contains 10.0.0.0/8 (mask 255.0.0.0), outgoing interface S0 and the router receives 10.1.0.0/16 (mask 255.255.0.0), outgoing interface e0 the new routing table will contain 10.0.0.0/8 s0 10.1.0.0/16 e0 Lower Administrative Distance Most router vendors have preference factors that can be set for different sources of routing information. Cisco calls its preference an Administrative Distance (AD), which is an 8-bit number. The lower the administrative distance, the more preferable the source of information. Table 3. Default Administrative Distances
Source of Information Default AD
Directly connected 0
Static routes in the form interface-name 0
Static routes in the form next-hop-ip* 1
EIGRP summary 5
External BGP 20
EIGRP 90
IGRP 100
OSPF 110
ISIS 115
RIP 120
EGP 140
External EIGRP 170
Internal BGP 200
Floating static (less preferred than dynamic) 201 - 254
Untrusted 255
* Can be manually configured to any value 1 - 255. The basic rules for selecting routes are based on specifications in RFC 1812. Cisco, like most vendors, has defined additional selection mechanisms. Be aware that the additional criteria for selection, particularly the preference given to different dynamic routing protocols, vary among vendors.
A very common error, which I've committed many times, is forgetting that the specificity of the prefix is always preferred to administrative distance. A summary route from the latest, greatest BGP implementation will be overridden by a RIP subnet route from an old UNIX box. Load Balancing Load sharing is an intuitively appealing feature, and definitely can be useful. Beginners often overstate its utility or expect it to do things that current load-sharing technologies cannot. Let me distinguish between load balancing and load sharing. Load balancing is much harder to realize. Load balancing is a strict distribution of traffic equally over several resources. Load sharing is, at best, approximate. Formally, load balancing is deterministic while load sharing is statistical. From the router perspective, the most limiting factor in load balancing is that current technology cannot be aware of the load on links or routers beyond the direct neighbor. Today's routers commonly load share onto paths that are heavily congested several hops away, while less congested paths exist. See Chapter 14 of [Berkowitz 1999] for a discussion of emerging multipath techniques for better load sharing. Cisco routers have two main modes of load sharing: per-packet and per-destination. Contrary to urban legend, it is not the routing protocol that makes a set of routes eligible for load balancing, but the routing table installation task. Routing protocols and static routes simply identify potential equal-cost routes. IGRP and EIGRP can recognize routes with different metrics as effectively equal, as long as the ratio between their metrics is less than or equal to the variance parameter. The mode of load balancing -- per-packet (round robin) or per-destination -- depends not on the routing protocol but on the settings of the outbound interfaces. Per-packet is slower and higher in overhead, but it gives the best bandwidth utilization and also can significantly improve convergence time in RIP and IGRP. Per-packet is also likely to increase the number of out-of-sequence packets, increasing workload on receiving hosts and even making some features unusable, such as Fast Sequenced Transport for Remote Source Route Bridging. Per-packet load balancing also requires process switching on other than the highest-end routers, and process switching is 8 to 12 times more router processor intensive than fast switching. Per-destination is faster and has lower overhead, but, especially with small numbers of destinations, can result in inefficient bandwidth use. If you go to per-destination load balancing, and there are a small number of destinations, there is always a danger that a disproportionate number of destinations will be cached on one interface. Even if the destination addresses spread evenly over the interfaces, if certain destinations have much more traffic than others, you might wind up with the heaviest-traffic destinations all running over the same interface. Remember that you can do load sharing with things other than pure routing, such as LocalDirector and DistributedDirector. There's a nice general discussion in RFC 2391 on Load-Sharing NAT. On the left side of Figure 8, there is a router with a sequence of packets to send to two destinations. Both destinations are reachable through either interfaces s0 or s1. The various load-sharing modes will distribute the traffic differently across the interfaces.
Figure 8. Basic Load Balancing Per-packet load sharing will distribute the outgoing packets strictly, alternating between s0 and s1 by packet order. As soon as a packet is dispatched to s0, another packet can be dispatched to s1, which causes good bandwidth utilization because the interfaces are transmitting concurrently. Destination host load, however, is likely to increase because packets are likely to be delivered in other than their original sequence. The more source-destination pairs -- flows -- across the set of shared interfaces, the more likely it is to get out-of-sequence packets because the average length of packets in different flows varies. Per-destination load sharing is faster and less likely to get packets out of sequence, but, if there are few destinations, bandwidth efficiency can be low because several high-traffic destinations become associated with the same interface. Per-destination load sharing is not traffic-aware. Default Items You will run across several terms that are often, and incorrectly, considered synonymous: default routes, default gateways (default routers), default networks, and gateways of last resort. These terms refer to slightly different mechanisms, all of which are useful. This section explains what each mechanism does. Default Route By convention, the address 0.0.0.0/0 is the default route, the least specific possible route. Cisco sometimes uses the term pseudonetwork to refer to 0.0.0.0/0. It is the route that you go to when you don't have anyplace else to go. This reminds me of the times at school when being picked for the cricket team -- I was invariably the default route! As opposed to being something to put in right field and forget, default routes are quite useful in networking. They can be declared with static routes, or they can be learned from dynamic routing protocols. To create a static route defining the local default, code: ip route 0.0.0.0 0.0.0.0 {next_hop_IP | outgoing_interface}
Created as a static route with an administrative distance less than that for dynamic routing, a default route in the next-hop-ip format will be used for the local router box, but not advertised unless it is explicitly redistributed (or unless you use the outgoing interface form of the static route command). Statically declared default routes of the interface-name format will be advertised as if they were directly connected. Local configuration is not the only way your router can learn the 0.0.0.0/0 default route. It can be learned from dynamic routing protocols such as OSPF and RIP. In the more recent IOS releases, you can originate default from any of these routing processes with the default-information-originate command. When you do this, the process will advertise default to other routers, although it might itself use the static route. default-information-originate has an optional parameter, the always keyword. If you don't use always, the router will advertise default only if it itself has an active default route. With always, the router will always advertise default and will blackhole routes to unknown destinations if there is no default. A typical application for always would be where you have a single ISP link to which you default, so you might as well blackhole if you can't get to it. Default Gateway The default gateway is specifically intended for the situation when no IP routing is enabled. It has the specific next-hop address of the gateway router. You would use this on a switch, or a router box that is only doing bridging, so that the box can reach network management servers that are not on the same subnet. Another application for the default gateway comes during booting from ROM, to find the TFTP server. In the IOS, you configure an IP default gateway with the command ip default-gateway gateway-address where gateway-address is the address of a router interface on a subnet to which your router is physically connected. Default Network The default network, used by IGRP and EIGRP, has only a prefix -- a network or subnet -- so unless internal assumptions are made, there's no way to know the specific next-hop address. Always remember the KISS (Keep It Simple, Stupid) rule. Once you understand what command is intended to do something, it isn't always useful to keep looking for commands that might do the same thing. The major reason to look for obscure command interpretations is that they may be the cause of problems you are troubleshooting. To specify a default network for IGRP or EIGRP, or that will be known locally on your router, code ip default-network ip-prefix The ip-prefix is not a host address as used in the next-hop field of an ip route statement, or as the argument of an ip default-gateway. It is an actual network or subnet address (i.e., with zeroes in all of the host bit positions). Gateway of Last Resort The Gateway of Last Resort (GOLR) is selected by the process that actually installs routes in the routing table. The GOLR represents the default destination that comes from the source of default that has the lowest Administrative Distance (AD). So if you had a default static route (with an AD of 0 or 1), it would become the GOLR regardless of anything you received from any routing protocol. If you received a default network from EIGRP or IGRP, that network would become GOLR in preference to anything from RIP or OSPF, unless you changed the administrative distance for RIP or OSPF. An OSPF default would be preferred to anything from RIP. An OSPF Type 1 default would be preferred over an OSPF type 2 default. Summarization Issues There are certain issues that arise when dealing with classful routing protocols such as RIPv1. The following discusses the more common issues and potential solutions or workarounds that are available.
The Problem -- Discontiguous Networks In classful routing, the only way a router can know a subnet length is from the mask configured on local interfaces. Since classful routing protocols do not pass prefix lengths, the only way a router that receives a route not configured on a local interface can know the prefix length is to assume it from the class of the address.
Figure 9. Example of a Discontiguous Network Everything has worked well in this small enterprise network. Each router is able to build a routing table that tells it the next-hop interface for each destination subnet. The routers are happy and content, cheerfully examining packets and forwarding them out the appropriate interface based on unambiguous information in their routing table. In this happy childhood of routing, each router advertises all its subnets to its peer. Subnet-level announcements are understood because each router has locally configured prefix length (i.e., subnet mask) information. Let us assume that all these addresses are in the 10.0.0.0 prefix. Puberty and adolescent confusion strike the routing system when the enterprise merges with another and the new company becomes responsible for WAN connectivity. The new WAN organization uses its own network number for WAN links, 192.168.0.0/24. Classful routing protocols do not make subnet-level announcements on interfaces with a different major network prefix. The underlying logic of this is that the distant peers would not have the subnet mask information to understand the subnet level. So, in Figure 9, neither R1 nor R2 make subnet-level announcements to their new peer, R3. Router R3 does know that elements of network 10.0.0.0/8 have been announced to interfaces S0 and S1 of R3. 10.0.0.0/8 is now a discontiguous network. 192.168.0.0/24 is the partitioning prefix. Note: An Occasional Gotcha On some versions of the IOS, if you have different ordering of secondary addresses on multiple routers' interfaces connected to the same subnet, weird errors can take place. Do not, for example, code hostname r1 interface ethernet 0 ip address 192.168.1.1 255.255.255.240 ip address 192.168.2.1 255.255.255.248 secondary ip address 192.168.3.1 255.255.255.240 secondary hostname r2 interface ethernet 0 ip address 192.168.1.2 255.255.255.240 ip address 192.168.3.2 255.255.255.240 secondary [Berkowitz 1999] ip address 192.168.2.2 255.255.255.248 secondary
Workarounds The more common methods of dealing with discontiguous networks include secondary addressing, tunneling, and the use of ip unnumbered interfaces. Secondary Addresses We said that a router couldn't know the prefix length of a route for a classful network that is not locally configured. Logically enough, if we can manually add relevant prefix length information to a router, the discontiguous network problem for the relevant network disappears. You can do this by configuring secondary addresses. Secondary addresses do have the disadvantage of potentially wasting address space, and may force traffic through a slower path in the router. Of course, the administrators of all involved routers have to agree to the changed configuration. interface ethernet 0 ip address 192.168.1.1 255.255.255.240 ip address 192.168.2.1 255.255.255.248 secondary ip address 192.168.3.1 255.255.255.240 secondary
Figure 10. Healing Discontiguous Networks with Secondary Addressing Tunneling A technique with a variety of applications, one of which is healing discontiguous subnets, is tunneling the protocols with a problem address inside IP packets with an address that does not confuse the classful routing system. Various tunneling protocols have been implemented, including Cisco's Generic Route Encapsulation (GRE; RFC 1701, RFC 1702). In tunneling, a payload packet is prefixed with a brief header for the tunneling overhead and then is wrapped in the carrier protocol. In tunneling for the purpose of healing a discontiguous subnet, the payload packet is an IP packet originating and terminating on addresses inside the classful prefix that has been made discontiguous. An appropriate analogy for this concept is kangaroos. Young kangaroos (known as joeys) are carried around in the pouch of the parent kangaroo over long distances to a destination they are not familiar with and then let roam locally when they arrive. The older kangaroo is similar to the carrier protocol and the joey is similar to the payload packet. We could call this the 'roo tunneling protocol!
Figure 11. IP Tunneling The core routers see the packet as like any other with an address in the space used by the carrier protocol. The edge routers are in the address space used by the [payload packet], with the exception of those edge routers that interface to the tunnels. Those tunneling routers will need configuration information both from the carrier and [payload] address spaces. Points in a tunneled network are available for network management, but in a less than totally integrated way. traceroute from inside the [payload] address space will see the entire tunnel as a single point-to-point medium. traceroute in the carrier address space will not see the passenger address space. A network management function in the carrier address space will not be able to ping passenger address points... These limitations still permit tighter network management than an older technique, IP unnumbered. [Berkowitz 1999] IP Unnumbered There is little argument that assigning a point-to-point medium to a prefix large enough to accommodate a LAN wastes address space. Again, in the words of the old doctor, if raising your elbow over your head and slapping it hurts, "Don't do that!" If assigning a single, fixed-length prefix to point-to-point media is inefficient, use arbitrary-length prefixes to assign more appropriate length addresses. IP-over-IP tunneling is a reasonably elegant solution. Alternatively, you can "borrow" the IP address of an interface on a LAN medium. In Figure 12, the serial interfaces have no addresses of their own. Configuration commands in each router cause every incoming packet on the serial interface to be delivered to the Ethernet, and every packet on the Ethernet to be sent over serial 0.
Classless Issues We have seen previously the common issue that can occur with classful routing; now we will look at two of the most commonly misunderstood configuration options in IP routing: the use of the all-zeroes subnet and also classless routing configuration. ip subnet-zero If a network address is subnetted, the first subnet obtained after subnetting the network address is called subnet-zero. When a network address is subnetted, the last subnet obtained is called the all-ones subnet. RFC 950 made the statement "It is useful to preserve and extend the interpretation of these special (network and broadcast) addresses in subnetted networks. This means the values of all zeroes and all ones in the subnet field should not be assigned to actual (physical) subnets." Traditionally the use of subnet-zero was discouraged due to the possibility of confusion in having a network and also a subnet with the same address. Using the all-ones subnet was also seen as a potential issue because the broadcast address of the network and the subnet are again the same. From RFC 1878: "This practice (of excluding all-zeroes and all-ones subnets) is obsolete! Modern software will be able to utilize all definable networks." This RFC effectively obsoletes the statement in RFC 950 and, since IOS version 12.0, the use of subnet-zero is enabled by default. In earlier versions of IOS, subnet-zero can be used, but it must be explicitly enabled with the ip subnet-zero global configuration command. ip classless ip classless is a concept whereby, if a Cisco router should receive a packet destined for a subnet and that subnet is not in the routing table, the router will forward the packet to the best available supernet. If ip classless is disabled by issuing the no ip classless global configuration command, the router in this situation will drop the packet. This can be a somewhat confusing concept that an example will clarify. If we disable classless forwarding: Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#no ip classless Router(config)#^Z Router#show ip route 150.0.0.0/16 is variably subnetted, 2 subnets, 2 masks R 150.1.0.0/22 [90/4,879,540] via 1.1.1.2 S* 0.0.0.0/0 [1/0] via 1.1.1.3 If we, in our minds, pass packets through this router with the destination address of 150.1.1.1, the router would forward the packet to 1.1.1.2. On the other hand, if a packet is received with destination address 150.1.100.1 (which is outside of the 150.1.0.0/22 subnet), the router will send the packet to the default gateway -- right? The surprising answer is no, the router will drop the packet. This is because the 150.1.100.1 address is part of the known major network, 150.1.0.0/16, but the router doesn't contain information about the specific 150.1.100.1 destination. This is known as classful routing behavior. Note: What about the Default Route?Always remember that in classful routing, the router will only use the default route if there is no reference to the destination major network at all! RIPv1 Review RIP was designed for homogeneous small to moderate-sized networks. Its original application was in LANs, where all links operated at the same speed. In this capacity, RIP is still quite useful, especially with RIP version 2 modifications. However, in larger, more complicated internetworks, RIP has several drawbacks:
• RIPv1 is a classful routing protocol summarizing at the network boundary and not supporting Variable-Length Subnet Masks (VLSM) or Classless Interdomain Routing
(CIDR). RIPv2 partially removes this limitation, but you still will not have the flexibility of Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (ISIS).
• The maximum path is limited to 15 routers (hops), so destinations cannot be more than 15 hops away, which may be a serious constraint for implementers in large enterprise networks. Note that in a hierarchical network design this limits you to seven hops from the single core router to the access networks.
• RIP can cause excessive bandwidth utilization due to periodic broadcasting or multicasting of routing tables.
Due to these and other inadequacies related to the early adoption of the distance vector routing algorithm, RIP has been replaced in many installations with more modern routing protocols. Initially the Cisco proprietary (but still distance vector) Interior Gateway Routing Protocol (IGRP) was aimed at resolving the major problems with RIP (improving metric and path length limit and lowering the network load with periodic broadcasts). The trend has been not to use RIP in new complex networks, but rather to go with either more advanced distance vector routing protocols such as the Cisco proprietary Enhanced Interior Gateway Routing Protocol (EIGRP), with its underlying advanced distance vector Diffusing Update Algorithm (DUAL), or link state protocols such as OSPF. EIGRP and OSPF/ISIS, although they use different routing algorithms (diffusing update and shortest path, respectively), have the following major advantages over RIP:
• Support for CIDR and VLSM • Sending routing updates only when network topology changes, instead of sending the
entire routing table at regular intervals • Fast convergence -- often instantaneous due to the topology database (a concept not
known in RIP) • Protection against potential routing loops • No or very high limit for the maximum routed network diameter
What are the advantages of RIP, then? For simple networks not stretched by the RIP path length limit (15 routers maximum between any reachable networks) and not using VLSM, the major benefits of RIP remain extremely easy configuration and administration. The local broadcasts RIPv1 uses to transmit its updates have an Note on Broadcast Impact associated cost. Every computer system on multi-access networks (e.g., Ethernet or Token Ring) will receive the broadcast. Non-router systems will process the received frame through the interface data link driver, the Network Layer software, and, in the case of RIP, even the Transport Layer software before determining that the packet should be discarded. Executing all this software and finally discarding the packet is wasteful. RIP Routing Operation RIP is based on the distance vector routing algorithm, which provides only a limited view of the internetwork topology to each router running RIP. RIPv1 operation follows step by step the operation of the distance vector algorithm described earlier. It is important to note that when a router starts running RIP, it first broadcasts a request packet. Adjacent RIP routers must reply with a RIP update, allowing the new router to join a network without waiting for the periodic RIP update. The reply to a request is not broadcast -- it is sent only to the requesting router (unicast), and split horizon is not performed on the routes in the reply packet. RIP sends periodic routing update messages at regular intervals. Every 25.5 to 30 seconds (time varies to avoid update synchronization [Floyd 1994] a Cisco router will send a RIP update out every interface that has a RIP network attached to it. The variance (randomization) in time between the updates is called RIP jitter. Update synchronization might be a problem if it occurs on Ethernet LANs. If routing updates are all sent at the exact same time, they tend to "synchronize," or collide. Periodic updates, in the form of complete routing tables, are broadcast to neighbor routers from primary and secondary addresses, reflecting the appropriate source IP address. To be precise,
the vector (list) of up to 25 routes (limitation given by the RIP packet format as described later) is broadcast to each of the neighboring routers. RIPv1 mostly uses the local broadcast address 255.255.255.255, which translates at the Data Link Layer to a broadcast MAC address of 0xFF-FF-FF-FF-FF-FF. Some RIP implementations, however, send routing tables to destination IP address 0.0.0.0 or to the network address (where the host portion is set to 0), but all the implementations use a broadcast address of 0xFF-FF-FF-FF-FF-FF at the MAC Layer. RIP transmits a "distance," in the form of a hop count, with each route. Cisco routers increment metrics upon transmission, which means that the cost of the outgoing link (directly connected networks are stored in the routing table with a cost of 0) is added to the metric when a routing advertisement is constructed. The route metrics in received routing updates are stored directly in the routing table. When a RIP-enabled interface goes down, the relevant directly connected network is removed from the routing table and all RIP-derived routes via the interface start a garbage collection timer (unless the timer's value is 0, in which case the routes will be dropped from the routing table right away). Note: Triggered UpdatesA triggered update is sent immediately when a route has failed rather than waiting for the update timer to expire. Used in conjunction with route poisoning, this ensures that all routers know of failed routes before any holddown timers can expire. An extension to the distance vector algorithm allows for immediate reaction to a topology change (route added, changed, or expired) in the form of a triggered update (flash update). For example, when a router loses a route to a network behind it, it announces that it cannot get to the network by sending a triggered update that lists the route to the network with a distance of 16. Triggered updates are introduced with the following characteristics and impact:
• Updates are sent independent of periodic updates and do not affect their timing. • Updates include only routes that have changed since the last update. • There must exist some mechanism to limit the frequency of triggered updates to prevent
network malfunction. Sending and Receiving Updates Before a router sends updates to another router, it checks whether the subnet information is part of the same major network as the interface that will be used as a source for such an update. If this is not the case, the router summarizes the route at the major net boundary and advertises only the network. In the opposite case, the router checks the subnet mask next. If the network has the same subnet mask as the interface that will be sourcing the update, the router advertises the subnet; otherwise it advertises the host route (/32 routes). Upon receipt of an update, a RIP router performs certain checks before accepting the update and applying the subnet mask. If the subnet received in the update is on the same major network as the interface that received the update, the receiving router applies the mask of the interface that received the update. If the advertised network has a host bit set in the host portion of the update, the router applies the host mask (/32). If the update does not correspond with the network the receiving interface connects, the router checks whether any subnets of this major network already exist in the routing table, known from interfaces other than the one that received the update. If they exist, the router ignores the update; otherwise, the router applies a classful mask to the update. Each entry in a RIP routing table provides a variety of information derived from periodic and triggered routing protocol updates:
• The IP address of the destination network • The IP address of the next hop (nearest router to reach the destination) • The local interface used to reach the next hop
• The distance metric (distance in number of hops to the destination with no merit for link quality features, such as bandwidth, path delay, or load)
• The route timers (update, invalid, holddown, garbage collection) • The route change flag
RIP keeps track of only the routes currently in use. Unlike more modern routing protocols, it has no capability of storing information about potential routes. If RIP decides a route has gone down, it must wait until another router updates it with a new route to the destination. Metric RIP uses hop count as its simple metric. Hop count is the number of routers that a packet must traverse to reach the destination network. Each network link is, by default, considered to be one hop. A directly connected network has a metric of 0 (zero hop count); the longest route may have a metric of 15, and an unreachable network has a metric of 16. RIP does not factor the speed of a link or "circuit cost" into route computation. This lack of information often results in RIP making suboptimal routing decisions. The most notable examples are illustrated in remote routing environments where a mix of T1 and fractional T1 links is available. In such cases, a RIP router will always choose the shortest route in terms of hop count, not the shortest route with regard to network delay. In Figure 13, RIP bases its routing decisions on hop count, choosing to route traffic from X to Y through A-D. RIP does not understand (much less take into account) that route A-B-C-D is much faster since the interconnecting links are running at T1 speed instead of 19.2 Kbps.
Figure 13. Hop Count Metric Drawbacks The restrictive metric field of a RIP message does not allow for routes longer than 15 routers. In large, especially hierarchical, networks it is often a problem for network administrators to guarantee that the 15-metric barrier will not be exceeded. Routing Table RIP maintains only the best route to a destination in its routing table. (In the case of multiple routes with the same prefix, administrative distance, and metric, all will be entered in the routing table.) When new information provides a better route, this information replaces old route information. When network topology changes occur, they are reflected in routing update messages. For example, when a router detects a link failure or a router failure, it recalculates its routes and sends routing update messages. Each router receiving a routing update message that includes a change updates its tables and propagates the change. The routing table may contain information on the default route (0.0.0.0 with 0.0.0.0 mask). A default route is used when it is not convenient to list every possible network in the RIP updates, and when one or more closely connected routers in the internetwork are prepared to handle traffic to networks that are not listed explicitly. These routers should create RIP entries for the address 0.0.0.0, just as if it were a network to which they are connected. The entries for 0.0.0.0 are handled by RIP in exactly the same manner as if there were an actual network with this address. However, the entry is used to route any datagram whose destination address does not match that of any other network in the table. Typically, only one router will have the default route configured, while all other routers will get the default route through routing update propagation with a respective added metric (ip classless enabled on a Cisco router). Note:
Version is 1 but reserved fields are nonzero Criteria for Declaring RIP Updates Invalid Metric > 16 (i.e., infinite value from the RIP standpoint) Update refers to a route to 127.x.x.x Network field is 0 Up to 25 routing entries are permitted in any single IP RIP packet, as the maximum length of RIP packet is 512 octets. In other words, up to 25 destinations may be listed in any single RIP packet. Multiple RIP packets are used to convey information from larger routing tables, which may add significant overhead to network traffic. A routing table that contains 1000 routes will require the transmission of 40 RIP messages. The RIPv1 message does not specify the destination network address mask; therefore there is no mechanism to advertise the subnets beyond the IP network boundary. Hence classful routing does not support address aggregation by network address prefix. For the same reason, no support for VLSM can be expected from RIP. Caution must be taken in cases where the network (classful) is not contiguous, as the routers in another network could receive two or more pieces of information on the route to the particular network, each of which would in fact not provide access to all the network subnets. See Figure 15 for an example of this concept. Stability Features and Timers RIP employs a number of mechanisms and timers designed to make its operation more stable in the face of rapid network topology changes. RIP permits a maximum hop count of 15. Any destination greater than 15 hops away is tagged as unreachable. RIP's maximum hop count greatly restricts its use in large internetworks, but prevents counting to infinity from causing endless network routing loops. RIP implements split horizon with poisoned reverse to avoid potential routing loops. Basically, when an update is sent out an interface, any routes learned from that interface are flagged as unreachable. RIP operates with two types of user devices: active and passive. Active RIP users, typically routers, advertise their routes via a broadcast over their networks. Passive RIP users, typically hosts, listen and update their routes based on the RIP information, but do not advertise routes. RIP employs a number of timers (update, holddown, invalid, and garbage collection) to regulate its performance and to avoid routing loops. Each timer has a default value in seconds that is suitable for most implementations. However, Cisco IOS allows for interlinked changing of the timer(s). The RIP routing update timer is generally set to 30 seconds, ensuring that each router will send a complete copy of its routing table to all neighbors every half minute. Cisco modifies the update timer by an arbitrary number of milliseconds on each update to prevent unwanted synchronization, discussed above as a potential flaw of periodic updates of distance vector protocols. The timer is first set when a new route is added to a table; it is reset every time an update is received for the route. Each routing table entry has a route-timeout timer associated with it. When the route-timeout timer expires, the route is marked invalid and retained in the table. This is controlled by a route invalid (timeout, expiration) timer, which determines how much time must expire without a router having heard about a particular route before that route is considered invalid. This timer is set to 180 seconds (three times the value of the update timer) for RIP. The invalid timer is used to detect failures on network media where there is no clear indication that a neighbor router has failed or that the connection to it has been lost. When a route is marked invalid, neighbors are notified of this fact. This notification must occur prior to expiration of the route garbage collection (flush) interval. If the invalid timer is not reset for a route within 180 seconds, the garbage collection timer is started. The garbage collection timer on Cisco will run for another 60 seconds (even though the RFC-defined interval is 120 seconds, four times the update interval) after the invalid timer expires. During this period, the route is advertised as unreachable (metric of 16). If no update is received by the time the timer expires,
the route is deleted. Taking the invalid and garbage collection timers together, if the route has failed and is still unavailable after 240 seconds (without any update), the router removes the routing table entry and the route is removed from the routing updates.
The holddown timer helps prevent routing loops and the spread of incorrect routing information throughout the internetwork by ensuring that any route update on a route that has become unreachable will not be believed again until 180 seconds (three times the value of the update timer) after the route failure. This prevents a router from using any new routing information until all routers in the network have had a chance to learn about the topology change. Holddown also prevents a flapping route from causing turmoil in a network. If a link goes down, then comes up, goes down again, then comes up again, all in quick succession, there is no need (in fact it is inadvisable) to spread the instant routing information exchanges throughout the network. Limiting the distribution of flapping routes adds stability to the network and reduces the overhead of routing information. Holddown timers must be used even when a triggered updating regime is used by the protocol alongside the periodic updates. As triggered updates do not happen instantaneously, routers that have not received them yet might issue a regular update in the meantime, causing the wrong route to be reinserted in a neighbor's table. With the holddown timer, the neighbor would not accept such information as valid. The values for these timers might be changed in different router configurations (although invalid, holddown, and flush timers should always be longer than update timers), but all routers in the network must use the same timer settings. Otherwise, problematic routing updates may occur: that is, a router with a shorter update interval expects to receive updates from its neighbors within the same interval. Hence, it can easily expire routes from neighbors with longer update intervals, perhaps even upon missing a single routing update packet. RIPv1 and Subnet Masks RIPv1 allows only a single subnet mask to be used within each network number because it does not provide subnet mask information as part of its routing update messages. In the absence of this information, RIPv1 is forced to make very simple assumptions about the mask that should be applied to any of its learned routes. Note: Subnet Masks within RIPRIPv1 is limited to a single subnet mask for each network number. How does a RIPv1-based router know if it should include the subnet number bits in a routing table update to a RIPv1 neighbor? A router executing RIPv1 will advertise the subnet number bits on another port only if the update port is configured with a subnet of the same network number. If the update port is configured with a different subnet or network number, the router will advertise only the network portion of the subnet route and will zero out the subnet number field. Consider the following example: assume that Port 1 of a router has been assigned the IP address 130.24.13.1/24 and Port 2 has been assigned the IP address 200.14.13.2/24. If the router learns about network 130.24.36.0 from a neighbor, it applies a /24 mask because Port 1 is configured with another subnet of the 130.24.0.0 network. However, when the router learns about network 131.25.0.0 from a neighbor, it assumes a default classful /16 mask because it has no other
Note: Does not provide support for VLSM, prefix routing, authentication, or multiple-path routing. RIP Version 1 at a Glance Distance vector routing protocol with hop count metric. Broadcasts routing table every 30 seconds. The longest route (RIP-routed network diameter) is limited to 15 hops. A metric of 16 hops indicates an unreachable network.
masking information available. Note: RIPv1 can support host routes (/32) as an optional implementation. However, there are many advantages to allowing more than one subnet mask to be assigned to a given IP network number: multiple subnet masks permit more efficient use of an organization's assigned IP address space and permit route aggregation, which can significantly reduce the amount of routing information at the backbone level within an organization's routing domain. Multiple subnet masks are achieved through VLSM and are supported by more advanced routing protocols, including RIPv2 (but not RIPv1). IP RIPv1 Configuration on Cisco Routers RIP is very easy to configure. You need to enable RIP and then add the network numbers of all directly connected networks. The following are optional parts of RIPv1 configuration:
• Allowing unicast updates for RIP • Applying offsets to routing metrics • Adjusting timers • Enabling or disabling split horizon
Basic RIP Configuration: Enabling RIP Router(config)#router rip This command starts a RIP routing process. (Use the no router rip command to shut down the routing process, clearing all RIP-related configuration.) Router(config-router)#network network-number This router subcommand associates a network with a RIP routing process. All interfaces (or rather their related major networks) that are meant to participate in RIP routing must be specified using this command. Directly connected networks specified in this command will be announced in RIP messages. If no other routers are attached to a particular interface, there is no need to list the interface network in the command, as it would be useless to broadcast RIP or listen for RIP on this interface. If a RIP message is received on an interface not enabled for RIP (not included in the network command), it is ignored. Note that you should enter the network number, not a subnet number (although Cisco routers permit entry of subnet numbers here, they automatically "aggregate" these number classfully)! Hence, in some cases, a single network command will be sufficient (when the router connects only to a single network, yet to a number of its subnets). To remove a network from the list, use the no network network_address router subcommand.
Figure 14. RIP Configuration Example Also note that, unlike the case for other interior routing protocols, there is no keyword following the router rip command. No autonomous system number or other identifier is required. Not specific to RIP, the router subcommand passive-interface interface type/number can be used to cause the router to listen for RIP and advertise the connected networks without actively sending RIP updates out of the interface. Optional RIP Configuration Commands Configuring a Default Route in RIP If the router has a directly connected interface onto the default network, the dynamic routing protocols running on that router will generate or source a default route. When default information is being passed along through the dynamic routing protocol, no further configuration is required. In the case of RIP, there will be only one choice: network 0.0.0.0. The default route appears as a gateway of last resort in a display of the EXEC command show ip route. The Cisco IOS software will advertise the default network if a default was learned by RIP or if the router has a gateway of last resort and RIP is configured with a default metric. RIP works well with both of the following global commands: Router(config)#ip route 0.0.0.0 0.0.0.0 {next_hop_address | local_router_interface} ! Default network configuration: Router(config)#ip default-network network_address Cisco IOS software will source the default network with RIP if one of the following conditions is met:
• The ip default-network global configuration command is configured. • The default-information originate router RIP configuration command is configured to
enforce default route announcement even if the router itself does not have the default route.
• The default route is learned via another routing protocol or static route and then redistributed into RIP. Note: From IOS release 12.0T, RIP does not advertise the default
route if it is not learned via RIP. Therefore, it may be necessary to redistribute the route into RIP or use the default-information originate command.
• The next-hop address network address must exist in the routing table; the local router interface must be in the up/up state.
Controlling Broadcasts and Multicasts Router(config-router)#neighbor ip-address This command enables specifying neighbors to which the RIP messages will be unicast, in order for RIP routing updates to traverse nonbroadcast networks. Modifying Timers Router(config-router)#timers basic update invalid holddown flush [sleeptime] Using only this command, all RIP-related timers can be changed:
• Update timer -- The rate (time in seconds between updates) at which routing updates are sent (default 30 seconds)
• Invalid timer -- The interval (in seconds) after which a route is declared invalid (default 180 seconds)
• Holddown timer -- The interval (in seconds) during which routing information regarding the route is suppressed (default 180 seconds)
• Flush timer -- The amount of time (in seconds) that must pass before a route is removed from the routing table (0 means immediately; default 240 seconds)
• Sleeptime (optional) -- The amount of time (in milliseconds) for which routing updates will be postponed after a triggered update before sending a periodic broadcast
The current and default timer values can be seen using the show ip protocols EXEC command. Applying Offsets to Routing Metrics Router(config-router)#offset-list [access-list-number | name] {in | out} offset [type number] This command is used to increase the value of routing metrics instead of a default increase by 1 at every hop. An offset list is the mechanism for increasing incoming and outgoing metrics to routes learned via RIP to reflect other route qualities (such as bandwidth) beyond simple distance in number of hops. Optionally, the offset list may be made more granular by using either an access list or an interface to identify the routes to be modified. The offset value range is between 0 and 16. If the access list number is 0, all routes are considered; if no interface is specified, the offset list applies to all interfaces, both in and out. Disabling Split Horizon Router(config-if)#no ip split-horizon With Nonbroadcast Multiaccess Networks (NBMAs), such as X.25 and Frame Relay, it may be necessary to disable split horizon on a point-to-multipoint interface to enable proper exchange of routing updates. In Cisco routers, split horizon is enabled by default on all interfaces except on physical interfaces supporting Frame Relay or Switched Multimegabit Data Service (SMDS) where it is disabled. A router configured with a primary IP address and secondary addresses on a given interface behaves differently when sending updates out that interface, depending on whether split horizon is enabled. Tables 4 and 5 (from the Cisco document "How Split Horizon Affects RIP/IGRP Routing Updates when Secondary Addresses Are Involved," ( http://www.cisco.com/warp/customer/105/41.html) list the differences in the updates. Table 4. RIP Updates with Secondary Address on Different Major Network than Primary
Split Horizon
Update Source
Update Contents
Enabled Primary Subnets of primary (if known through non-source interfaces). Other major networks (including secondary network), known through non-
source interface, summarized to major net boundary.
Enabled Secondary Subnets of secondary (if known through non-source interface). Other major networks (including primary network), known through non-source interface, summarized to major net boundary.
Disabled Primary All known subnets of primary. Other major networks (including secondary network) summarized to major net boundary.
Disabled Secondary All known subnets of secondary. Other major networks (including primary network) summarized to major net boundary.
Table 5. RIP Updates with Secondary Address on Same Major Network as Primary
Split Horizon
Update Source
Update Contents
Enabled Primary Subnets of primary/secondary (if known through non-source interfaces). Other major networks, known through non-source interface, summarized to major net boundary.
Enabled Secondary None -- no updates sourced from secondary.
Disabled Primary All known subnets of primary/secondary. Other major networks summarized to major net boundary.
Disabled Secondary All known subnets of primary/secondary. Other major networks summarized to major net boundary.
RIPv2 RIP version 2 (RFC 2453 http://www.ietf.org/rfc/rfc2453.txt), the current IP RIP standard, builds on RIPv1 and enhances it in the following areas: Subnet masks -- Inclusion of subnet masks was the original intent of opening the RIP protocol for improvement. As long as the subnet mask was fixed for a network and well known by all the nodes on that network, a heuristic approach could be used to determine if a route was a subnet route or a host route. With the advent of VLSM, CIDR, and supernetting, it was no longer possible to reliably distinguish between network, subnet, and host routes. By using the 32-bit field immediately following the IP address in a RIPv2 routing entry, it became possible to positively identify a route's type. As RIPv2 sends a subnet mask with each update, it supports arbitrary length prefixes as needed for VLSM and CIDR. Although RIPv2 itself can carry classless information, the network statement to turn RIP on for an interface is classful. Next-hop addresses -- A router can advertise a route but direct any listeners to a different router on that same subnet in case the other router has a better route; this capability allows specifying a router closer to the destination regardless of whether multiple routing protocols are running on a router or network. This leads to optimization of routing in an environment that uses multiple routing protocols. For example, if RIPv2 were being run on a network along with another interior protocol, and one router ran both protocols, then that router could indicate to the other RIPv2 routers that a better next hop than itself existed for a given destination. Note that this is not a recursive algorithm; it works to eliminate only a single extra hop from the path. Note: octet = 8 bits (same as a byte) Authentication -- Optional cryptographic authentication of routing updates represents a significant improvement of RIPv2 over RIPv1. Essentially, it is the same extensible mechanism provided by OSPF. Plaintext password was initially defined for authentication. While the authentication mechanism specified in RIPv2 is less than ideal, it does prevent anyone who
cannot directly access the network (i.e., someone who cannot sniff the routing packets to determine the password) from inserting bogus routing information. The specification does allow for additional types of authentication to be incorporated into the protocol, e.g., MD5 authentication is proposed in RFC 2082 (http://www.ietf.org/rfc/rfc2082.txt) and further security enhancements are drafted. MD5 authentication, used also with OSPF and BGP, is similar to plaintext authentication (default), but the key is never sent over the wire. Instead, the router uses the MD5 algorithm to produce a message digest of the key, which is then sent over. The amount of space available for providing authentication information with RIP is only 20 octets, including the 4-octet authentication type; however, for MD5 authentication, data is appended in the RIP message trailer. For both authentication types, 24 routing entries are available in an authenticated Note: Support for VLSM, prefix routing, authentication, and multiple-path routing RIP Version 2 at a Glance Distance vector routing protocol with hop count metric. Multicasts routing table every 30 seconds or at change. The longest route (RIP-routed network diameter) is limited to 15 hops. A metric of 16 hops indicates an unreachable network. message (the first entry is used for authentication information). Multicasting -- RIPv2 packets are multicast (every 30 seconds) instead of being broadcast. The use of an IP multicast address reduces the load on hosts that do not support routing protocols. It also allows RIPv2 routers to share information that RIPv1 routers cannot hear. This is useful since a RIPv1 router may misinterpret route information because it cannot apply the supplied subnet mask. The multicast address used by RIPv2 is 224.0.0.9, which is translated at the link layer to destination multicast MAC address 0x01-00-5E-00-00-09. This reduces the amount of processing required on non-RIP-speaking hosts on a common subnet. For backward compatibility with RIPv1, the messages sent to local broadcast are still processed by RIPv2. External route tags -- May be used to propagate information acquired from an exterior routing protocol (for example, an AS number). The use to which the exterior routing puts the information is transparent to RIPv2. RIPv2 is required only to store the received information in the routing table and to include it in the update messages. The Cisco implementation of RIP version 2 supports plaintext and MD5 authentication, route summarization, and VLSMs. RIPv1 vs. RIPv2 The main features of RIP version 1 and version 2 are compared in Table 6. Table 6. Comparison of RIP Versions 1 and 2
Characteristic RIP Version 1 RIP Version 2
Routing algorithm Distance vector Distance vector
Routing updates Regularly (every 30 seconds) Regularly (every 30 seconds) and on change (triggered updates)
Broadcast/multicast Broadcast to IP address 255.255.255.255 (mapped onto broadcast MAC address 0xFF-FF-FF-FF-FF-FF)
Multicast to IP address 224.0.0.9 (mapped onto multicast MAC destination address 0x01-00-5E-00-00-09)
Main limitation Scalability (15-hop maximum path) Scalability (15-hop maximum path)
RIP Summarization Principles RIP is a typical classful IP routing protocol that summarizes addresses at the IP network (address class) boundary (to a Class A, B, or C address). Routes advertised by RIP may be default, network, or subnet routes. Exterior routes can be injected into RIP from other routing processes. These routes are treated as network routes and are sent to RIP neighbors as if they originate from RIP (no source flag is attached to them). The primary difference between RIP version 1 and RIP version 2 is that in version 2 the subnet routes have their associated subnet mask included in the routing update and variable-prefix subnets are permitted and advertised. Summary IP addresses function more efficiently than multiple individually advertised IP routes because the summarized routes in the RIP database are processed first and any associated child routes that are included in a summarized route are skipped as RIP looks through the routing database, reducing the processing time required. Cisco routers can summarize routes in two ways:
• Automatically (autosummary) -- Summarizing subprefixes to the classful network boundary when crossing classful network boundaries. (Cisco enables autosummary for both RIP versions by default, and only for RIPv2 it can be disabled.) EIGRP (see below) will also automatically summarize at classful network boundaries unless no auto-summary is configured. This is done to maintain compatibility with IGRP, which is completely classful.
• Manually based on specific configuration -- RIPv2 only. Basic RIPv2 Configuration on Cisco Routers For commands for starting RIP on the router's interfaces, see the section on RIPv1 configuration. Router(config-router)#version {1 | 2} The router will receive and send only RIPv1 or v2 packets, as specified. The RIP version number is not specified in the global router rip command. Instead it requires its specific router configuration subcommand. By default, Cisco receives both RIPv1 and v2 packets, but sends only v1 packets. To display the current RIP version in use, enter the show ip protocols command. Migration from RIPv1 to RIPv2 requires some planning. RIPv1 sends updates to the broadcast address, whereas RIPv2 uses a multicast. A RIPv1-only router and a RIPv2-only router will not succeed in exchanging routing information. To migrate to RIPv2, one option is to migrate all routers at the same time. This might not be a reasonable political or administrative option, however. If not, then some coexistence between RIPv1 and RIPv2 is required. The ip rip send version command can be used to overcome the problem. Essentially, the configuration tells the router whether to send RIPv1-style updates, RIPv2-style updates, or both for each interface. Further commands are available only for RIPv2. Optional Configuration Commands RIP Authentication This command configures the interface to use MD5 digest authentication or let it default to plaintext authentication. Router(config-if)#ip rip authentication mode {text | md5} This command specifies the set of authentication keys that can be used on an interface. Key number and key string have to match on all neighbor authenticated routers. Key chain is only
locally significant for the router on which it is defined, hence it does not have to have a match anywhere in the network. Router(config-if)#ip rip authentication key-chain name-of-chain Only RIP version 2 supports authentication. While sending and receiving RIPv2 packets, RIP authentication can be enabled on an interface. The key chain determines the set of keys that can be used on the interface. If a key chain is not configured, no authentication is performed on that interface, not even the default authentication. Therefore, the configuration tasks related to managing authentication keys must also be performed. Cisco supports two modes of authentication on an interface for which RIPv2 authentication is enabled: plaintext authentication and MD5 authentication. The default authentication in every RIP version 2 packet is plaintext authentication, which means that an unencrypted authentication key is sent in every RIP version 2 packet. To achieve a real security, MD5 authentication should be used. Example (connected routers A-B over serial line): RouterA#sh run key chain praga key 1 key-string 234 ! interface Loopback0 ip address 80.70.70.70 255.255.255.255 ! interface Serial2 ip address 140.108.0.10 255.255.255.252 ip rip authentication mode md5 ip rip authentication key-chain ritapu ! router rip version 2 network 140.108.0.0 network 80.0.0.0 RouterB#sh run key chain brunnae key 1 key-string 234 ! interface Loopback0 ip address 90.80.80.1 255.255.255.0 ! interface Serial1/0 ip address 140.108.0.9 255.255.255.252 ip rip authentication mode md5 ip rip authentication key-chain ritapu clockrate 64000 ! router rip version 2 network 140.108.0.0 network 90.0.0.0 Controlling Support of RIP Version(s) Router(config-if)# ip rip {send | receive} version 1 An interface will send/accept only RIPv1 packets. Router(config-if)# ip rip {send | receive} version 2 An interface will send/accept only RIPv2 packets.
Router(config-if)# ip rip {send | receive} version 1 2 An interface will send/accept both RIPv1 and v2 packets. These commands are used to configure the software to send and/or receive packets of only one protocol version, either on the whole router (all its interfaces) or specifically per interface. By default, Cisco receives both RIP version 1 and version 2 packets, but sends only version 1 packets. You can configure the interface to receive and send only version 1 packets or to receive and send only version 2 packets. Summarization Autosummary Autosummary addressing always summarizes to the classful address boundary, while the ip summary-address rip command (see next section) summarizes addresses on a specified interface. If autosummary addressing is enabled, autosummarization is the default behavior for all interfaces on the router, with or without the ip summary-address rip interface subcommand present. This command disables autosummarization (RIPv2 only): Router(config-router)# no auto-summary You need not configure anything for RIP autosummary to be enabled because, for both RIP versions, Cisco performs automatic summarization by default. Only for RIPv2, the autosummary may be disabled. Autosummarization may make parts of the network unreachable, such as in the case of discontiguous networks. IP subnet design traditionally has not allowed discontiguous networks. A contiguous network is a single Class A, B, or C network for which all routes to subnets of that network pass through only other subnets of that same single network. Discontiguous networks refer to the concept that, in a single Class A, B, or C network, there is at least one case in which the only routes to one subnet pass through subnets of a different network. Discontiguous has a meaning similar to unconnected. In Figure 15, there could be a PVC between the two routers that uses a subnet of network 10.0.0.0, but that PVC may be down, causing the discontiguous network. The discontiguous network can be overcome with the use of RIPv2, which transmits masks, because the rule of discontiguous subnets can be ignored when using a routing protocol that transmits masks while disabling the autosummarization.
Figure 15. Autosummarization Problem Overriding Autosummarization of RIP Router(config-if)# ip summary-address rip network mask This interface command, new as of IOS 12.0(6)T, requires split horizon to be disabled.
Example: The major network is 10.0.0.0. The summary address 10.2.0.0 overrides the autosummary address of 10.0.0.0, so that 10.2.0.0 is advertised out interface e1 while 10.0.0.0 is advertised elsewhere. router int e1 ip address 10.1.1.1 255.255.255.0 ip summary-address rip 10.2.0.0 255.255.0.0 router rip network 10.0.0.0 no ip split-horizon Supernetting Supernet advertisement (advertising any network prefix less than its classful major network) is not allowed in RIP route summarization, other than advertising a supernet learned in the routing tables. Supernets learned on any interface that is subject to configuration are still learned. For example, the following summarization is invalid: interface E1 [...] ip summary-address rip 10.0.0.0 252.0.0.0 [invalid supernet summarization] Each route summarization on an interface must have a unique major net, even if the subnet mask is unique. RIP Route Summarization Verification router# show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 8 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Redistributing: rip Default version control: send version 2, receive version 2 Automatic network summarization is not in effect Address Summarization: 12.11.0.0/16 for Ethernet2 Advanced Distance Vector Protocols There are different generations of distance vector routing protocols. These are based on a hierarchy as follows: First Generation -- The first generation of distance vector protocols is typified by protocols such as RIPv1 and AppleTalk RTMP. In these first-generation protocols, hop count is the only metric used, which means that routing is only optimized when the network consists of links of the same bandwidth. These protocols also employ count-to-infinity rules and split horizon techniques for loop avoidance. First-generation distance vector protocols send the entire routing table by default at periodically defined intervals. Second Generation -- IGRP is a good example of a second-generation distance vector routing protocol. IGRP can make use of more than just the hop count as a metric and can take into account multiple link characteristics, such as bandwidth and delay. Second-generation DV protocols also have additional loop avoidance techniques built in and generally send updates and not full tables. Third Generation -- The classic example of a third-generation distance vector routing protocol is EIGRP. EIGRP retains the characteristics of IGRP and furthermore makes use of a hello subprotocol to increase response time after link failures. The hello protocol employed also serves to reduce routing traffic on the network. Third-generation DV protocols tend to emphasize loop prevention techniques rather than loop avoidance techniques. DUAL is the algorithm that EIGRP uses to provide this loop prevention functionality. Introduction to EIGRP Cisco Systems originally developed IGRP in the 1980s as a replacement routing protocol for the then widely deployed Routing Information Protocol (RIP). RIP gained popularity for a number of
reasons, but one of the most telling was the fact that RIP was provided free on several vendors' operating systems. Another reason is that it was, and remains, simple to configure. Notwithstanding its popularity, RIPv1 had several severe limitations, including excessive bandwidth utilization, slow convergence times, and network diameter limitations. IGRP was developed by Cisco to address these limitations. The success of IGRP was not long lived, as some of the limitations of RIP persisted, even if those limitations were not as severe. OSPF and ISIS were developed in the late 1980s by network architects and implemented as the preferred IGPs for large enterprise networks, which led Cisco to respond by developing of EIGRP. Cisco first delivered EIGRP in IOS version 9.21. It is a common misconception that EIGRP is just an enhancement to IGRP. It is easy to see how EIGRP's name can propagate this misunderstanding; however, EIGRP actually bears only minimal resemblance to its predecessor and provides much more functionality and scalability than IGRP. EIGRP has four main components, three of which are distinctly different from those of other IGPs:
• Protocol Dependent Modules (PDMs) -- EIGRP has a separate module for each of the three routed protocols it supports, namely IP, IPX, and AppleTalk. The choice of routed protocol determines which PDM EIGRP uses.
• Reliable Transport Protocol (RTP) -- The Reliable Transport Protocol (RTP) is responsible for guaranteed delivery of EIGRP packets and also ensures that packets are delivered in order. EIGRP packets are sent via the multicast address 224.0.0.10. Cisco has implemented a concept of reliable multicast, where each received multicast packet is acknowledged via a unicast packet to the sender. Ordered delivery is ensured by the use of sequence numbers in the EIGRP header. Cisco has patented this methodology.
• Diffusing Update Algorithm (DUAL) -- EIGRP uses the DUAL algorithm to calculate the best path to a destination while guaranteeing a loop-free topology. This algorithm was developed outside of Cisco. [Garcia-Luna-Alceves 1993] DUAL will not be discussed in depth in this Tutorial. For detailed information about EIGRP's use of DUAL see the CCNP/CCIE-level Study Guide on EIGRP.
EIGRP also uses the following mechanism, common to other advanced routing protocols: • Hello subprotocol -- EIGRP employs a hello subprotocol for neighbor discovery and
recovery, which will be discussed in more detail later in this Tutorial. OSPF uses a similar protocol.
EIGRP Terminology Table 7. EIGRP Topological Elements and Parameters Neighbor A router running the same routing protocol with which communication has been
made and some required values match. Neighbors do not need to be physically adjacent.
Neighbor table
A database maintained by EIGRP that lists each adjacent neighbor discovered by that router via the hello subprotocol.
Topology table
A database maintained by EIGRP of routing information.
Successor A neighbor selected as the next hop.
Reported distance
The distance from the successor to the destination. This is the same as the term advertised distance, commonly used in Cisco literature and training courses.
Feasible distance
The current best distance to a destination.
Feasibility condition
A step in the DUAL algorithm. The feasibility condition is satisfied when the minimum of the neighbors' costs to the destination plus the cost of the link to that neighbor is less than the current best cost to the destination.
A neighbor that satisfies the feasibility condition. EIGRP stores the successor or best path and all paths that are closer to the destination.
Table 8. EIGRP Protocol Concepts
Hello A message of a routing protocol used for neighbor discovery and tracking. In EIGRP, hello packets are sent to the multicast address of 224.0.0.10.
Acknowledgements Acknowledgements are sent in response to hello packets. This is how EIGRP guarantees reliable delivery and receipt.
Hello timer The interval between hello packets. In EIGRP the default is 5 seconds or 60 seconds depending on the underlying media.
Hold timer The amount of time a router waits without receiving a hello from a neighbor before marking it as no longer available.
Update An update is a protocol message. An update is sent when any of the following occurs:
• When a neighbor first comes up • When a router moves from active to passive state for any
destination • When there is a metric increase for a given destination.
Query Sent to all neighbors when a router enters a destination into the active state. The router will remain in the active state unless it receives replies from all its neighbors.
Reply Required response to a query. If the neighbor doesn't have the information, it will in turn send a query to its neighbors.
Active state A router enters a destination into the active state when it has lost its successor to that destination and has no feasible successor. The router must compute a new route to the destination.
Passive state A destination is said to be in the passive state when it has a feasible successor in the router's topology table.
Stuck-in-Active (SIA)
A state where the router has not had a response from a query packet for a predetermined time. The default time is 3 min.
EIGRP Operation EIGRP Neighbors EIGRP routers do not exchange routing information until they form a neighbor relationship. To do this, EIGRP uses its version of the hello protocol. Periodically EIGRP routers will multicast a hello packet to the address 224.0.0.10 out of all configured interfaces. Note that hellos are sent or received via the primary IP address configured on an interface. EIGRP cannot form a neighbor relationship with secondary address routers. An EIGRP router receiving hello packets will attempt to form a neighbor relationship with the sender (provided that they have common compatible parameters such as Autonomous System numbers, etc.). Once the neighbor relationship, or adjacency, is established, the two routers exchange full routing information. After the initial exchange of routing information, the routers will exchange only routing information when a topology change is detected. This is known as triggered updates. Hello packets are sent and received at periodic intervals to track neighbors. Hello packets are also used to identify when a neighbor is no longer available. EIGRP keeps track of the hello packets it receives from its neighbors and, if it doesn't hear from a neighbor for a certain amount of time, it will drop the neighbor relationship. That causes all information learned from that neighbor, such as routing and topology information, to be flushed. If the router
subsequently hears from the neighbor again, it will reestablish the adjacency and again exchange routing information. EIGRP uses two timers to with respect to the hello mechanism: the hello and hold timers. Table 9. Hello and Hold Timers
Hello The hello timer specifies how often hello packets are sent. The default is 5 seconds for most interfaces. The exceptions are low-speed NBMA interfaces (such as frame relay, X.25, and ATM) that default to 60 seconds. The default hello time can be modified with the ip hello-interval eigrp interface configuration command.
Hold The hold timer specifies how long a router will wait without hearing from a neighbor before clearing the adjacency. It defaults to 3 times the Hello timer (15 seconds for most interfaces and 180 seconds for NMBA interfaces). Having the hold time equal to 3 times the hello timer allows for a hello packet or two to be lost without the router clearing the adjacency. The default hold time can be modified with the ip hold-time eigrp interface configuration command.
The neighboring router's hello timer in the hello packet specifies the hold time. This allows neighbors with different settings for their timers to interoperate successfully. For example, examine Figure 16.
Figure 16. EIGRP Hello and Hold Timers When Router A establishes its adjacency with Router B, it informs Router B that its hello time is 5 seconds. Router B then sets its hold timer for Router A to be 15 seconds -- allowing it to quickly detect a downed link. Router A, in turn, will wait 180 seconds, due to Router B's longer hello time. EIGRP Metrics All routing protocols have some concept of a metric, the value used to calculate the best path to a destination. EIGRP uses a composite metric based on a number of link parameters. Although there are five parameters that are tracked by EIGRP for metric computation, it is important to note that only two of these are used by default (bandwidth and delay) and one is not actually used for calculating metrics at all (MTU). These are as follows: Table 10. EIGRP Metrics Bandwidth This is the bandwidth of the link in Kb. Note that the default bandwidth on serial
interfaces is 1544 Kb regardless of the actual link speed configured. The use of the bandwidth statement is needed to correct EIGRP operation. We will discuss this in more detail under the configuration section. Bandwidth is used by default by EIGRP in calculating its composite metric.
Delay This is the propagation delay of the link in question in tens of microseconds. EIGRP uses delay by default to calculate the composite metric.
Reliability Reliability is a measure of how reliable a link is based on historical data pertaining to the amount of time a link has been available to pass data. This is a value from 1 to 255. A value of 255 indicates that a link is 100% reliable. This
Load This metric is used to determine how utilized a link is at any given time. Unlike bandwidth or delay, load is not a static number and changes as network traffic load changes. Load is a value from 1 to 255, with 255 meaning a link is 100% utilized. This is not a metric that EIGRP uses by default.
Maximum Transfer Unit (MTU)
The minimum MTU to a destination is tracked by EIGRP, and is often mistaken as a parameter in the calculation of the composite metric. MTU is tracked by EIGRP for internal loop avoidance purposes only. The formula that is used to calculate the composite metric is shown in the following section and does not use the MTU.
Table 11 displays the standard Cisco values for bandwidth and delay for various interface types. Please note that this assumes that the interface bandwidth or delay commands have not been used to modify the default values: Table 11. Default Bandwidth and Delay for Interface Types
Interface Bandwidth (Kbps) Delay (microseconds)
10-Mbps Ethernet 10,000 1,000
100-Mbps Ethernet 100,000 100
1000-Mbps Ethernet 1,000,000 10
Token Ring 16,000 630
Fast Ethernet 100,000 100
Serial 1,544 20,000
Channelized T1 (or E1) 1,536 20,000
Fractional T1 (or E1) (# channels) * 64 20,000
ISDN BRI or PRI 64 20,000
Loopback 8,000,000 5,000
EIGRP Route Selection Mechanism When EIGRP calculates the best path or feasible distance to a destination, it makes use of the composite metric. The full formula used to calculate this composite metric is complex and beyond the scope of this paper. For detail, see the EIGRP Study Guide. The minBandwidth is the lowest of any bandwidth along the path to the destination. It is not the bandwidth on the local outgoing interface, but is computed from the minBandwidth for each destination in the update message. Delay is measured in tens of microseconds. Note that the output of the show interfaces command displays delay in milliseconds. K constants are passed in the hello packets and must match between neighbors. Using default values for the K constants results in the following, much simplified, formula: CompMetric = [(107 / minBandwidth) + sum of interface delays] * 256 EIGRP uses this formula of metric computation to accomplish two things:
• On routes of few hops, the route with the greatest minimum bandwidth is usually preferred.
• On routes with many hops, the route with the least total delay is usually preferred. It must be noted here that EIGRP implements an upper hop count limit of 224 hops to a destination. Above that, EIGRP will mark the route to that destination as unreachable.
The following example will help clarify the use of the composite metric in the EIGRP route selection process. Consider the following network topology with some arbitrary values assigned.
Figure 17. EIGRP Composite Metric PC1 sends a packet to PC2. Router A receives the packet, which has a destination network of LAN 2. There are two possible paths to LAN 2, which are via Router B and Router C. Router B has reported a distance of 110 to get to LAN 2. That, plus the 50 to get to Router B, gives a total distance of 160. Router C has reported a distance of 110 to get to LAN 2. That, plus the 100 to get to Router C, gives a total distance of 210. Since the path through Router B has the lower cost, it is chosen as the best path to LAN 2. Let's look at the same example again. This time we replace the arbitrary values with actual link values of bandwidth and delay:
Figure 18. EIGRP Composite Metric with Real Values Once again, PC1 is attempting to communicate with PC2. Router A must determine the best path to the destination LAN 2. Based on the fact that we are only using the default metrics of bandwidth and delay, the following formula is used to calculate the composite metric via each path: CompMetric = [ (107 / minBandwidth ) + sum of interface delays ] * 256 The path via Router B has a minimum bandwidth of 384 Kbps and a total delay of 40,100. The composite metric is: [ (107 / 384 ) + 40,100 ] * 256 = 16,932,267 Similarly, the path via Router C has a minimum bandwidth of 256 Kbps and a total delay of 40,100. The composite metric for this path is: [ (107 / 256 ) + 40,100 ] * 256 = 20,265,600 It is easy now to see that the path with the best composite metric is via Router B. EIGRP Internal Mechanisms -- The Databases There are two databases that are used by EIGRP to store information. These are fundamental to the operation of EIGRP and are described below.
Neighbor Database Neighbors are discovered via the EIGRP hello subprotocol. When an EIGRP router forms an adjacency with another EIGRP router, it stores this neighbor information in the neighbor database. The show ip eigrp neighbors command can be used to display the information stored in this database. Sample output is show in Figure 19.
Figure 19. The EIGRP Neighbor Database Topology Database EIGRP routers store not only the best route to a destination, they store up to five alternative routes as well. The next hop, along with other necessary information such as feasible distance and reported distance, is stored in the topology database. The information stored in the topology database can be viewed by issuing the show ip eigrp topology command. The following display details the output from this command: RouterA>show ip eigrp topology IP-EIGRP TOPOLOGY TABLE FOR AS(90)/ID(10.1.18.2) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 0.0.0.0/0, 0 successors, FD is Inaccessible via 172.16.1.3 (307200/281600), Ethernet1/0 via 172.16.1.2 (307200/281600), Ethernet1/0 P 203.18.188.70/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 203.18.188.78/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 203.57.207.0/24, 1 successors, FD is 307200 via 172.16.1.2 (307200/281600), Ethernet1/0 P 172.16.254.0/30, 1 successors, FD is 793600 via 172.16.1.3 (793600/551936), Ethernet1/0 P 192.168.37.0/24, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 202.12.242.105/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 202.12.242.106/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0
It is also possible to view a summarized version of the topology database by adding the summary keyword to the show ip eigrp topology command: RouterA>show ip eigrp topology summary IP-EIGRP TOPOLOGY TABLE FOR AS(90)/ID(10.1.18.2) HEAD SERIAL 13, NEXT SERIAL 25 6 ROUTES, 0 PENDING REPLIES, 0 DUMMIES IP-EIGRP ENABLED ON 3 INTERFACES, NEIGHBORS PRESENT ON 2 INTERFACES QUIESCENT INTERFACES: SE0/1 SE0/0 Tip How to View All Routes to a Destination Learned via EIGRP The topology database actually contains all routes (known to EIGRP) to a destination, though only successors and feasible successors are displayed with the show ip eigrp topology command. To see all of the routes (including nonfeasible successors), use the show ip eigrp topology all-links command. The summary command can offer some quick insight into your routing process, including the following:
• Total number of routes • Number of routes pending replies • Total number of interfaces and neighbors • Head serial and next serial -- every time a change is made to the topology database, the
next serial is incremented by 1 (head serial is where it started). This is a direct reflection on the stability of your network. If the difference between the head serial and the next serial is great, it can indicate network instability.
To see detailed information about a route, specify the route in the show ip eigrp topology route statement. For example: RouterA>show ip eigrp topology 10.1.5.0 255.255.255.0 IP-EIGRP TOPOLOGY ENTRY FOR 10.1.5.0/24 STATE IS PASSIVE, QUERY ORIGIN FLAG IS 1, 1 SUCCESSOR(S), FD IS 7693056 ROUTING DESCRIPTOR BLOCKS: 10.1.18.1 (SERIAL0/0), FROM 10.1.18.1, SEND FLAG IS 0X0 COMPOSITE METRIC IS (7693056/5514496), ROUTE IS INTERNAL VECTOR METRIC: MINIMUM BANDWIDTH IS 384 KBIT TOTAL DELAY IS 40100 MICROSECONDS RELIABILITY IS 240/255 LOAD IS 1/255 MINIMUM MTU IS 1500 HOP COUNT IS 2 10.1.17.1 (SERIAL0/1), FROM 10.1.17.1, SEND FLAG IS 0X0 COMPOSITE METRIC IS (11026432/5514496), ROUTE IS INTERNAL VECTOR METRIC: MINIMUM BANDWIDTH IS 256 KBIT TOTAL DELAY IS 40100 MICROSECONDS RELIABILITY IS 240/255 LOAD IS 1/255 MINIMUM MTU IS 1500 HOP COUNT IS 2 Note that with each route, not only is the composite metric shown, but the individual components used to compute the metric are shown as well (collectively, these are known as the vector metric). This brings up an interesting point: when a router sends an EIGRP route to a neighbor, it does not include its composite metric, but instead it includes all of the components (vector metric). The receiving router then uses the vector metric to compute not only its own metric, but the reported distance as well.
Additional EIGRP Features Unequal-Cost Load Balancing EIGRP also supports unequal-cost load balancing with the variance command. Consider the following network.
Figure 20. EIGRP Unequal-Cost Load Balancing Router A has two paths to LAN 1. However, since the metrics are not equal, only one path will be used. This is the path through Router C. However, you can use the variance command to cause EIGRP to share the load over the two links as though they were equal-cost. Configuring EIGRP unequal-cost load balancing will be discussed in more depth in the "EIGRP Unequal-Cost Load-Balancing Configuration" section of this Tutorial. There are a few aspects to consider about unequal-cost load balancing.
• A secondary route can be considered for unequal-cost load balancing only if it is a feasible successor. (This is the most common oversight. Often, the secondary link is not a feasible successor).
• By default, the load balancing is proportional to the link speed. For example, if the primary link is twice as fast, it will get twice the traffic. However, this can be changed with the traffic-share command.
• Traffic will be load-balanced across up to six paths, provided that they all fall within the variance. This number can be modified, though, with the maximum-paths command. By default EIGRP will use up to four maximum paths.
• Only the best route will appear in the routing table. You will not see the other routes. Summarization EIGRP is a fairly CPU- and memory-intensive protocol. It gets particularly resource-hungry during link failure conditions. It is possible to overload even the largest of CPUs with EIGRP processing alone. Route summarization is one of the tools provided to relieve some of this burden. Observe the following network. Two major (10.0.0.0 /8 and 172.16.0.0 /16) networks in the same Autonomous System meet at Router D.
Figure 21. EIGRP Summarization Without summarization, every 10.0.0.0 subnet appears in the routing table of Routers X, Y, and Z. For example, the following is the routing table from the perspective of Router Z:
RouterZ#show ip route CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2 E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, * - CANDIDATE DEFAULT U - PER-USER STATIC ROUTE, O - ODR GATEWAY OF LAST RESORT IS NOT SET 172.16.0.0/24 IS SUBNETTED, 4 SUBNETS D 172.16.0.0 [90/2195456] VIA 172.16.2.2, 00:08:24, SERIAL0 D 172.16.1.0 [90/2681856] VIA 172.16.2.2, 00:08:24, SERIAL0 [90/2681856] VIA 172.16.3.1, 00:08:24, SERIAL1 C 172.16.2.0 IS DIRECTLY CONNECTED, SERIAL0 C 172.16.3.0 IS DIRECTLY CONNECTED, SERIAL1 10.0.0.0/24 IS SUBNETTED, 6 SUBNETS D 10.1.8.0 [90/8253696] VIA 172.16.2.2, 00:08:24, SERIAL0 D 10.1.5.0 [90/2198016] VIA 172.16.2.2, 00:08:24, SERIAL0 D 10.1.19.0 [90/6049536] VIA 172.16.2.2, 00:08:24, SERIAL0 D 10.1.18.0 [90/8228096] VIA 172.16.2.2, 00:08:24, SERIAL0 D 10.1.17.0 [90/11561472] VIA 172.16.2.2, 00:08:24, SERIAL0 D 10.1.16.0 [90/6049536] VIA 172.16.2.2, 00:08:24, SERIAL0 Quite clearly, this is an inefficient routing table. Routers X, Y, and Z in this example only need to know to send all packets destined for any 10.0.0.0 network to Router D. This can be accomplished with route summarization. Instead of advertising the individual 10.0.0.0 /24 networks to the 172.16.0.0 network, Router D summarizes them all into one route: 10.0.0.0 /8. This one route is then propagated throughout the 172.16.0.0 network. After summarization, the routing table on Router Z looks like this: RouterZ#show ip route CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2 E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, * - CANDIDATE DEFAULT U - PER-USER STATIC ROUTE, O - ODR GATEWAY OF LAST RESORT IS NOT SET 172.16.0.0/24 IS SUBNETTED, 4 SUBNETS D 172.16.0.0 [90/2195456] VIA 172.16.2.2, 00:40:47, SERIAL0 D 172.16.1.0 [90/2681856] VIA 172.16.2.2, 00:40:47, SERIAL0 [90/2681856] VIA 172.16.3.1, 00:40:47, SERIAL1 C 172.16.2.0 IS DIRECTLY CONNECTED, SERIAL0 C 172.16.3.0 IS DIRECTLY CONNECTED, SERIAL1 D 10.0.0.0/8 [90/2198016] VIA 172.16.2.2, 00:00:09, SERIAL0 Route summarization can be automatic or manual. Bandwidth Use By default, EIGRP will use a maximum of 50% of the configured bandwidth of an interface. It is critical for proper EIGRP operation to the set the correct interface bandwidth via the bandwidth command. An example is in order here to highlight how not setting the correct bandwidth can cause EIGRP to function incorrectly. Assume we have a standard serial interface running HDLC but that it is being provided clocking from a DCE device at 64 Kbps. The network operator configuring this link forgets that the default bandwidth of a serial interface is 1.544 Mbps and thus does not use the bandwidth 64000 statement on the serial interface. EIGRP will attempt to use 0.5 * 1544, or 772 Kbps, higher than the capacity of the link. Thus, EIGRP operation could potentially saturate this link. It is important to get into the habit of configuring the correct interface bandwidth when using EIGRP; this is, in fact, excellent practice even if you are not working with EIGRP.
The default bandwidth that EIGRP will attempt to use can be modified via the ip bandwidth-percent eigrp interface configuration command. EIGRP Limitations Stuck-In-Active Events Stuck-in-Active (SIA) events are the number one issue when designing and maintaining EIGRP topologies. An SIA event occurs when a query packet gets no reply for a predetermined time (by default, 3 minutes). Figure 22 illustrates an SIA event.
Figure 22. EIGRP SIA Router A needs to find a new route to LAN 1 and it does not have a feasible successor. The first thing Router A does is mark current route to LAN 1 active in the EIGRP topology table. An active route is one that has a query about it outstanding. Router A then sends a query to its neighbor, Router B, for a new route to LAN 1. If the SIA timer expires and Router A still has not heard a response from router B, it removes its adjacency with Router B and continues the query/response process. The route is now called stuck-in-active. The query/response process will probably now complete successfully, but the adjacency with Router B was lost! Any route learned from Router B is removed from the routing table, and new query/response processes are started to find new routes to these destinations (at least until the adjacency is reestablished by the hello protocol). Solving the SIA Problem Solving the SIA problem in an enterprise environment requires careful network design. This is well beyond the scope of this Tutorial; however, we will touch on some possible resolutions here. Some of the more popular ways of avoiding SIA events include the following:
• Increasing the SIA timer • Route summarization • Default routing • EIGRP stub routing
Although increasing the SIA timer may seem the simplest option to resolve SIA events, on closer examination it is usually the least effective. As the network grows, SIA events will return and hence this will only provide a short-term or "Band-Aid" solution. Route summarization and default routing both involve placing limits on how far queries are propagated. If route summarization is used, a carefully planned hierarchical design is required. Default routing may be used, combined with route filters, to accomplish what can be done better with stub networks. Basic EIGRP Configuration Configuring a basic EIGRP setup is a trivial task. This is one of the strengths of EIGRP. The following output shows the basic commands required to configure classful EIGRP: (config)# router eigrp AS_number (config-router)# network IP_network Figure 23 shows a sample network topology and the necessary configuration commands required to enable EIGRP for this network. It also reveals how easy EIGRP is to configure.
Figure 23. Enabling EIGRP As with configuring any IGP on a Cisco router, the network command is used to enable the routing protocol on any interface configured within that network space. To determine what interfaces are participating in EIGRP, use the show ip eigrp interfaces command. RouterA#sh ip eigrp interfaces IP-EIGRP interfaces for process 90 Xmit Queue Mean Pacing Time Multicast Pending Int Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0/1 1 0/0 230 2/95 1235 0 Se0/0 1 0/0 1494 1/63 7531 0 This command shows not only which interfaces are configured for EIGRP, it also shows how many neighbors or peers are on each interface. To discover information relating to the peers, use the show ip protocols command. RouterA>show ip protocols routing protocol is "eigrp 90" outgoing update filter list for all interfaces is incoming update filter list for all interfaces is default networks flagged in outgoing updates default networks accepted from incoming updates eigrp metric weight k1=1, k2=0, k3=1, k4=0, k5=0 eigrp maximum hopcount 100 eigrp maximum metric variance 1 redistributing: eigrp 90 automatic network summarization is in effect routing for networks: 10.0.0.0 routing information sources: gateway distance last update (this router) 5 00:52:55 10.1.18.1 90 00:52:33 10.1.17.1 90 00:52:33 distance: internal 90 external 170 Additional EIGRP Configuration Tasks Several configuration examples have been provided in this Tutorial so far. This section is intended to provide some configuration information for some of the more common scenarios. Automatic Summarization Route summarization is enabled by default on Cisco routers. The process works as follows:
1. Whenever more than one major (classful) network is defined with the EIGRP network statements, summarization will occur.
2. For each classful network defined, a summary route pointing to the NULL0 interface is entered into the routing table. This route has an administrative distance of 5 and the minimum metric of all subnets being summarized.
3. Only the summarized route (from step 2) is advertised to neighbors on different classful networks.
Figure 24. EIGRP Automatic Summarization Both networks, 10.0.0.0 and 172.16.0.0, are defined in the EIGRP configuration. Router D creates the summary routes and then advertises the 10.0.0.0 route out interface F0/1 and the 172.16.0.0 out interfaces S0/0 and S0/1. The final result is the following: Routers A, B, and C will have a single route to 172.16.0.0/16 in their routing tables via Router D. Routers X, Y, and Z will have a single route to 10.0.0.0/8 in their routing tables, again via Router D. Full connectivity is established with a minimum of routes. Overriding Automatic Summarization Instead of automatically summarizing networks and distributing classful addresses, manual summarization provides stricter control and solves the problem of discontiguous subnets. Manual summarization consists of two configuration tasks.
• Disable automatic summarization: This is done in router configuration mode with the no auto-summary command:
• (config-router)# no auto-summary • Manually summarize on a per-interface basis: This is performed in interface
configuration mode. You configure the summary address that you want advertised from the interface. Only the summary network configured will be advertised, and all subnets within that summary will be suppressed. It is crucial to remember that manual summarization of EIGRP is configured on a per-interface basis, unlike the case with other IGPs.
Manual summarization works like automatic summarization in that a route for the summarized network pointing to the NULL0 interface is inserted into the routing table. This route is then distributed to the neighbors. Figure 25 shows the sample network that we used for our automatic summarization example.
Figure 25. Disabling Automatic Summarization The following configuration can be used to disable automatic summarization and enable manual summarization: hostname routerd interface serial0/0 ip address 10.1.16.1 255.255.255.0 ip summary-address eigrp 90 172.16.0.0 255.255.0.0 interface serial0/1 ip address 10.1.19.1 255.255.255.0 ip summary-address eigrp 90 172.16.0.0 255.255.0.0 interface fastethernet0/1 ip address 172.16.0.1 255.255.255.0 ip summary-address eigrp 90 10.1.0.0 255.255.0.0 router eigrp 90 network 10.0.0.0 network 172.16.0.0 no auto-summary A summary route to 172.16.0.0 /16 is sent to Routers B and C. There is no change from autosummarization as there are no discontiguous subnets. A summary route to 10.1.0.0 /24 is sent to Router X. In this manner it is possible for the 10.2.1.0 route to coexist in that network. Autosummarization must, of course, be disabled on Router Y for this to work. The resulting routing table on Router Y is shown below: RouterY#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set 172.16.0.0/24 is subnetted, 4 subnets D 172.16.0.0 [90/2195456] via 172.16.1.2, 00:22:52, Serial0
C 172.16.1.0 is directly connected, Serial0 D 172.16.2.0 [90/2681856] via 172.16.1.2, 00:22:52, Serial0 C 172.16.3.0 is directly connected, Serial1 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.2.1.0/24 is directly connected, Ethernet0 D 10.1.0.0/16 [90/2198016] via 172.16.1.2, 00:17:24, Serial0 Router Y sees its directly connected network (10.2.1.0) but does not summarize it. It also sees a route to 10.1.0.0 /24, which originates from Router D. Configuring Bandwidth Use Configuring the maximum bandwidth that EIGRP can use for routing updates is simple. If, for example, we were using a serial interface using frame relay encapsulation at 256 Kbps, and we wished to limit the maximum amount of bandwidth EIGRP would use to 64 Kbps, then we could use the following commands: RouterA(config-if)#bandwidth 256 RouterA(config-if)#ip bandwidth-percent eigrp as_number 25 Note that 64 Kbps is 25% of 256 Kbps, hence the last number in the above configuration. Also of importance is the setting of the interface bandwidth, as serial lines default to 1.554 Mbps in the absence of a configured bandwidth. Load Balancing RIP and EIGRP Load Balancing -- Equal Cost By default, RIP and EIGRP load-balance over a maximum of four equal-cost links. This default can be changed to a maximum of six paths with the command maximum-paths under the EIGRP process. Let's look at a simple case of a router with two equal-metric paths to a destination.
Figure 27. RIP and EIGRP Equal-Cost Load Balancing Router A has two paths to LAN 1 through Router B and through Router C. Since both paths have the same composite metric, they are used alternatively. In other words, they are evenly load-balanced. The precise load-balancing flow depends on the packet switching mechanism used by the router.
• Process switching -- Load-balances on a per-packet basis • Fast switching -- Load-balances on a per-network prefix basis (as do optimum
switching, silicon switching, and Netflow switching) • Cisco Express Forwarding -- Load-balances on a "source-destination pair" basis
Figure 28. Load Balancing Using Variance Router A has two paths to LAN 1. By default, since the metrics are not equal, only one path appears in the routing table (the one through Router C). However, with the variance router configuration command, the load can be shared over the two links. The command syntax is: RouterA(config)# router eigrp as_number RouterA(config-router)# variance multiplier The multiplier is the factor by which the lesser route must be within the primary route. For example, if the multiplier is 2 and the primary route metric is 100, the secondary route must have a metric of 200 or less to be used for load balancing. Conclusions and Summary This Tutorial has attempted to cover the base level knowledge required of CCNA candidates when attempting the CCNA written exam. This has been by no means an exhaustive coverage of these concepts; however, the information contained in this Tutorial will greatly prepare you for questions relating to routing concepts and the distance vector routing protocols RIP and EIGRP. Both RIP and EIGRP are forms of distance vector routing protocols. This Tutorial has highlighted the main aspects of these routing protocols and has provided the necessary information required to pass the CCNA Routing and Switching certification exam. For further study of these routing protocols, please see Rita Puzmanova's RIP Study Guide and Jason Sinclair's EIGRP Study Guide. These are both CCNP/CCIE level guides that are available on . References [Berkowitz 1999] Berkowitz, H. Designing Routing and Switching Architectures for Enterprise Networks. Macmillan, 1998. [Dijkstra 1980] Dijkstra, E. W., and Scholten, C. S. "Termination Detection for Diffusing Computations," Information Processing Letters, 11(1), 1980. http://www.cse.ucsc.edu/research/ccrg/publications/jj.dual.ton93.pdf. [Floyd, 1994] S. Floyd and V. Jacobson. "The Synchronization of Periodic Routing Messages." IEEE/ACM Transactions on Networking, V.2 N.2, p. 122-136, April 1994. [Garcia-Luna-Alceves] Web site of J. J. Garcia-Luna-Alceves, http://www.cse.ucsc.edu/~jj/. [Garcia-Luna-Alceves 1993] Garcia-Luna-Alceves, J. J. "Loop-Free Routing Using Diffusing Computations," IEEE/ACM Transactions on Networking, 1(1), February 1993. http://www.cse.ucsc.edu/research/ccrg/publications/jj.dual.ton93.pdf. [Retana 1999] Retana, A., White, R., and Slice, D. CCIE Professional Development: Advanced IP Network Design. Cisco Press, 1999. [Retana 2000] Retana, A., White, R., and Slice, D. EIGRP for IP: Basic Operation and Configuration. Addison-Wesley, 2000. [RFC 950] "Internet Standard Subnetting Procedure." 1985. http://www.ietf.org/rfc/rfc950.txt. [RFC 1058] "Routing Information Protocol." 1988 (historic). http://www.ietf.org/rfc/rfc1058.txt. [RFC 1581] "Protocol Analysis for Extensions to RIP to Support Demand Circuits." 1994 (informational). http://www.ietf.org/rfc/rfc1581.txt. [RFC 1582] "Extensions to RIP to Support Demand Circuits." 1994 (proposed standard). http://www.ietf.org/rfc/rfc1582.txt.
[RFC 1721] "RIP Version 2 Protocol Analysis." 1994 (informational). http://www.ietf.org/rfc/rfc1721.txt. [RFC 1722] "RIP Version 2 Protocol Applicability Statement." 1994 (standard). http://www.ietf.org/rfc/rfc1722.txt. [RFC 1724] "RIP Version 2 MIB Extension." 1994 (draft standard). http://www.ietf.org/rfc/rfc1724.txt. [RFC 1878] "Variable Length Subnet Table for IPv4." 1995. http://www.ietf.org/rfc/rfc1878.txt. [RFC 2080] "RIPng for IPv6." 1997 (proposed standard). http://www.ietf.org/rfc/rfc2080.txt. [RFC 2081] "RIPng Protocol Applicability Statement." 1997 (informational). http://www.ietf.org/rfc/rfc2081.txt. [RFC 2082] "RIP-2 MD5 Authentication." 1997 (proposed standard). http://www.ietf.org/rfc/rfc2082.txt. [RFC 2091] "Triggered Extensions to RIP to Support Demand Circuits." 1997 (proposed standard). http://www.ietf.org/rfc/rfc2091.txt. [RFC 2092] "Protocol Analysis for Triggered RIP." 1997 (informational). http://www.ietf.org/rfc/rfc2092.txt. [RFC 2453] "RIP Version 2." 1998 (standard). http://www.ietf.org/rfc/rfc2453.txt. [Zinin 2002] Zinin, A. Cisco IP Routing: Packet Forwarding and Intradomain Routing Protocols. Addison-Wesley, 2002. 4.2 Lab Abstract This Lab Abstract will familiarize you with basic IP routing configurations. It starts by having you enable and disable use of the all-zeroes subnets. Then you configure RIPv1, RIPv2, and EIGRP. Finally, you look at some of the pitfalls that can be encountered when using these routing protocols. 4.3 Lab Scenario Introduction The aim of this Lab Scenario is to familiarize you with basic IP routing configurations. Initially, you will enable and disable use of the all-zeroes subnets. The Labs will then lead you through the configuration of RIPv1, RIPv2, and EIGRP and highlight some of the pitfalls that can be encountered when using these routing protocols. The information contained in this Lab Scenario will provide the foundation you need to successfully pass the Simulated R3 components of the CCNA Routing and Switching Exam. Goals
• Configure use of all-zeroes and all-ones subnets • Configure basic RIPv1 • Add RIPv2 support • Disable RIPv2 automatic summarization • Configure basic EIGRP • Disable EIGRP automatic summarization
Equipment • Two back-to-back DTE-DCE serial cables • One Cisco router with two serial interfaces and one Ethernet interface • Two Cisco routers, each with one serial and one Ethernet interface
Initial Configuration Tasks Task 1: Configure ip subnet-zero Note: This task only makes use of R1.
1. Disable the use of the all-zeroes and all-ones subnets by issuing the following command: 2. R1#conf t 3. Enter configuration commands, one per line. End with CNTL/Z. 4. R1(config)#no ip subnet-zero 5. R1(config)^Z 6. R1#
7. Now attempt to add the IP address 10.0.0.1/24 to the loopback 0 interface: 8. R1#conf t 9. R1(config)#int loopback 0 10. R1(config-if)#ip address 10.0.0.1 255.255.255.0 11. Bad mask /24 for address 10.0.0.1 12. R1(config-if)#^Z
The reason for the highlighted error message is that you are trying to configure the interface loopback 0 with the all-zeroes subnet 10.0.0.0/24. If we enable the use of subnet-zero then the router will allow us to configure this address: R1#conf t R1(config)#ip subnet-zero R1(config)#int loopback 0 R1(config-if)#ip address 10.0.0.1 255.255.255.0 R1(config-if)#^Z Note that the error message is not displayed and the router now allows us to configure this address. This is the technique used to enable or disable use of the all-ones or all-zeroes subnets on a Cisco router.
Task 2: Assign IP Addresses and Enable RIPv1 on All Routers 1. Assign the following IP addresses to the routers:
Serial 0 Serial 1 Ethernet 0
R1 192.168.12.1/24 Shutdown 172.16.1.1/16
R2 192.168.12.2/24 192.168.23.2/24 Shutdown
R3 192.168.23.3/24 Shutdown 10.3.3.3/8
2. Configure RIPv1 on all three routers and add the configured interfaces to the RIP routing process.
3. Verify that the routing process is correctly configured. Issue the command show ip protocols on all three routers. The following is sample output from R1:
4. R1#show ip protocols 5. Routing Protocol is "rip" 6. Sending updates every 30 seconds, next due in 14 seconds 7. Invalid after 180 seconds, hold down 180, flushed after 240 8. Outgoing update filter list for all interfaces is 9. Incoming update filter list for all interfaces is 10. Redistributing: rip 11. Default version control: send version 1, receive any version 12. Interface Send Recv Key-chain 13. Ethernet0 1 1 2 14. Serial0 1 1 2 15. Routing for Networks: 16. 172.16.0.0 17. 192.168.12.0 18. Routing Information Sources: 19. Gateway Distance Last Update 20. 192.168.12.2 120 00:00:22 21. Distance: (default is 120) 22. Issue the command show ip route on all three routers. An entry for all the networks
configured should be listed. Sample output from R1 follows: 23. R1#show ip route 24. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 25. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 26. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 27. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
28. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 29. U - per-user static route, o - ODR 30. 31. Gateway of last resort is not set 32. 33. C 192.168.12.0/24 is directly connected, Serial0 34. C 172.16.0.0/16 is directly connected, Ethernet0 35. R 10.0.0.0/8 [120/2] via 192.168.12.2, 00:00:22, Serial0 36. R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:22, Serial0 37. Ensure that you have full IP connectivity by use of the extended ping command. You
should be able to ping the Ethernet 0 interface on R3 (10.3.3.3) using R1's Ethernet interface as the source address (172.16.1.1):
38. R1# ping 39. Protocol [ip]: 40. Target IP address: 10.1.1.1 41. Repeat count [5]: 42. Datagram size [100]: 43. Timeout in seconds [2]: 44. Extended commands [n]: y 45. Source address or interface: Ethernet0 46. Type of service [0]: 47. Set DF bit in IP header? [no]: 48. Validate reply data? [no]: 49. Data pattern [0xABCD]: 50. Loose, Strict, Record, Timestamp, Verbose[none]: 51. Sweep range of sizes [n]: 52. Type escape sequence to abort. 53. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: 54. !!!!! 55. Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms 56. R1# 57. Challenge configuration -- Now configure a Loopback 0 interface on R1 with the
address 10.1.1.1/24. Add this network to your RIP configuration. Will you be able to ping the Ethernet address on R1 (10.1.1.1/8) from R3? Do not read the next section until you have tried the challenge configuration or have decided that you need some help. (Scroll down to continue...)
This space intentionally left blank ;) ... The answer is no. The reason for this is that RIPv1 is a classful routing protocol and only includes one subnet mask per classful network in its routing updates. Verify this behavior by issuing the show ip route command on R3: R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:09, Ethernet0 R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:09, Ethernet0 C 10.0.0.0/8 is directly connected, Ethernet0 C 192.168.23.0/24 is directly connected, Serial0 Note that there is no entry in the routing table for 10.1.1.0/24. The following task will reveal one method of solving this problem inherent in RIPv1.
Task 3: RIPv2 Configuration and Disabling Automatic Summarization
1. Add support for RIPv2 on all three routers and verify configuration by issuing the show ip protocols command. A sample output from R1 is once again listed:
2. R1#show ip protocols 3. Routing Protocol is "rip" 4. Sending updates every 30 seconds, next due in 23 seconds 5. Invalid after 180 seconds, hold down 180, flushed after 240 6. Outgoing update filter list for all interfaces is 7. Incoming update filter list for all interfaces is 8. Redistributing: rip 9. Default version control: send version 2, receive version 2 10. Interface Send Recv Key-chain 11. Ethernet0 2 2 12. Loopback0 2 2 13. Serial0 2 2 14. Routing for Networks: 15. 10.0.0.0 16. 172.16.0.0 17. 192.168.12.0 18. Routing Information Sources: 19. Gateway Distance Last Update 20. 192.168.12.2 120 00:00:17 21. Distance: (default is 120) 22. 23. Issue the show ip route command on R3. Note that there is still no entry for the network
10.1.1.0/24: 24. R3#show ip route 25. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 26. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 27. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 28. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 29. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 30. * - candidate default, U - per-user static route, o - ODR 31. P - periodic downloaded static route 32. 33. Gateway of last resort is not set 34. 35. R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:25, Ethernet0 36. R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:25, Ethernet0 37. C 10.0.0.0/8 is directly connected, Ethernet0 38. C 192.168.23.0/24 is directly connected, Serial0 39. The reason that route 10.1.1.0/24 is still not visible in R3's routing table is automatic
summarization. Disable autosummary on all three routers using the no auto-summary command under the RIP routing process. You should now see the entry for 10.1.1.0/24 on R3, and you will also be able to ping the interface 10.1.1.1 from R3:
40. R3#show ip route 41. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 42. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 43. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 44. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 45. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 46. * - candidate default, U - per-user static route, o - ODR 47. P - periodic downloaded static route 48. 49. Gateway of last resort is not set 50.
51. R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:14, Serial0 52. R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:14, Serial0 53. 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks 54. R 10.1.1.0/24 [120/2] via 192.168.23.2, 00:00:14, Serial0 55. C 10.0.0.0/8 is directly connected, Ethernet0 56. C 192.168.23.0/24 is directly connected, Serial0 57. 58. 59. R3#ping 10.1.1.1 60. Type escape sequence to abort. 61. Sending 5, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds: 62. !!!!! 63. Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
The reason that you are now able to ping the Ethernet address of R3 successfully is that RIPv2 is a classless routing protocol that includes subnet mask information in its updates about all networks in the update, and that you have also disabled automatic summarization, which is the default behavior of RIPv2 on Cisco routers.
Task 4: Configure Basic EIGRP Note: We will only use R1 and R2 for this task.
1. Erase the existing configuration from R1 and R2. 2. Configure IP addresses on the serial and Ethernet as follows:
Serial 0 Ethernet 0
R1 192.168.12.1/24 10.1.1.1/24
R2 192.168.12.2/24 10.2.2.2/24
3. Enable EIGRP on both routers using the autonomous system number 123. 4. Ensure that EIGRP is enabled for both interfaces on both routers. 5. You should now be able to ping R2's Ethernet interface (10.2.2.2) from R1. Actually this
will not be possible. A review of R1's routing table will reveal why: 6. R1#show ip route 7. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 8. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 9. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 10. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 11. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 12. U - per-user static route, o - ODR 13. 14. Gateway of last resort is not set 15. 16. C 192.168.12.0/24 is directly connected, Serial0 17. 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks 18. C 10.1.1.0/24 is directly connected, Ethernet0 19. D 10.0.0.0/8 is a summary, 00:03:44, Serial0
Note the summary address that EIGRP has added to the interface Null0. You may be thinking, "Wait a second, I thought EIGRP was a classless routing protocol!" That is correct; however, once again, automatic summarization has caused us problems. The following task will show you how to resolve this issue.
Task 5: Disable EIGRP Automatic Summarization 1. Disable automatic summarization on R1 and R2 by issuing the no auto-summary
configuration command. Verify that the 10.2.2.0/24 route is now visible in R1's routing table:
2. R1#show ip route 3. Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
4. D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 5. N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 6. E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 7. i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 8. U - per-user static route, o - ODR 9. 10. Gateway of last resort is not set 11. 12. C 192.168.12.0/24 is directly connected, Serial0 13. 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks 14. C 10.1.1.0/24 is directly connected, Ethernet0 15. D 10.2.2.0/24 [90/409600] via 192.168.12.2, 00:03:44, Serial0 16. Ping R2's Ethernet address from R1. The attempt should now be successful. 17. R1#ping 10.2.2.2 18. 19. Type escape sequence to abort. 20. Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: 21. !!!!! 22. Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Do not read the next section until you have completed the Tasks or have decided that you need some help. (Scroll down to continue...) This space intentionally left blank ;) ...
Solutions Task 1 R1 Configuration R1#show run Building configuration... Current configuration: ! version 12.0 ! hostname R1 ! enable secret cisco ! ip subnet-zero ! ! ! interface Loopback0 ip address 10.0.0.1 255.255.255.0 no ip directed-broadcast ! interface Ethernet0 no ip address no ip directed-broadcast ! interface Serial0 no ip address ! ip classless ! ! line con 0 transport input none line vty 0 4 login password certzone
! end Task 2 R1 Configuration R1#show run Building configuration... Current configuration: ! version 12.0 ! hostname R1 ! enable secret cisco ! ip subnet-zero ! interface Loopback0 ip address 10.1.1.1 255.255.255.0 ! interface Ethernet0 ip address 172.16.1.1 255.255.0.0 ! interface Serial0 ip address 192.168.12.1 255.255.255.0 no ip directed-broadcast ! router rip network 10.0.0.0 network 172.16.0.0 network 192.168.12.0 ! ip classless ! line con 0 transport input none line vty 0 4 login pass certzone ! end R1 Route Table R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 C 172.16.0.0/16 is directly connected, Ethernet0 10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Loopback0 R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:06, Serial0 R2 Configuration R2#show run Building configuration... Current configuration: ! version 12.1 ! hostname R2 ! enable secret cisco ! ip subnet-zero ! interface Ethernet0 no ip address ! interface Serial0 ip address 192.168.12.2 255.255.255.0 ! interface Serial1 ip address 192.168.23.2 255.255.255.0 ! router rip network 192.168.12.0 network 192.168.23.0 ! ip classless ! line con 0 transport input none line aux 0 line vty 0 4 password certzone login ! end R2 Route Table R2#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:25, Serial0 R 10.0.0.0/8 [120/1] via 192.168.23.3, 00:00:18, Serial1 [120/1] via 192.168.12.1, 00:00:25, Serial0
C 192.168.23.0/24 is directly connected, Serial1 Note: R2 learns about 10.0.0.0/8 from R1 and R3, although R1 is configured with a /24 mask. This is due to the classful nature of RIPv1. R3 Configuration Building configuration... Current configuration : 805 bytes ! version 12.2 ! hostname R3 ! ip subnet-zero ! interface Ethernet0 ip address 10.3.3.3 255.0.0.0 ! interface Serial0 ip address 192.168.23.3 255.255.255.0 ! router rip network 10.0.0.0 network 192.168.23.0 ! ip classless ! line con 0 transport input none line vty 0 4 password certzone login ! end R3 Route Table R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:13, Serial0 R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:13, Serial0 C 10.0.0.0/8 is directly connected, Ethernet0 C 192.168.23.0/24 is directly connected, Serial0 Task 3 R1 Configuration R1#show run Building configuration... Current configuration:
! version 12.0 ! hostname R1 ! enable secret cisco ! ip subnet-zero ! interface Loopback0 ip address 10.1.1.1 255.255.255.0 no ip directed-broadcast ! interface Ethernet0 ip address 172.16.1.1 255.255.0.0 ! interface Serial0 ip address 192.168.12.1 255.255.255.0 ! router rip version 2 network 10.0.0.0 network 172.16.0.0 network 192.168.12.0 no auto-summary ! ip classless ! ! line con 0 transport input none line vty 0 4 password certzone login ! end R1 Route Table R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 C 172.16.0.0/16 is directly connected, Ethernet0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks R 10.0.0.0/8 [120/2] via 192.168.12.2, 00:00:02, Serial0 C 10.1.1.0/24 is directly connected, Loopback0 R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:02, Serial0 R2 Configuration R2#show run
Building configuration... Current configuration: ! version 12.1 ! hostname R2 ! enable secret cisco ! ip subnet-zero ! interface Serial0 ip address 192.168.12.2 255.255.255.0 ! interface Serial1 ip address 192.168.23.2 255.255.255.0 ! router rip version 2 network 192.168.12.0 network 192.168.23.0 no auto-summary ! ip classless ! line con 0 transport input none line aux 0 line vty 0 4 password certzone login ! end R2 Route Table R2#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:05, Serial0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks R 10.1.1.0/24 [120/1] via 192.168.12.1, 00:00:05, Serial0 R 10.0.0.0/8 [120/1] via 192.168.23.3, 00:00:21, Serial1 C 192.168.23.0/24 is directly connected, Serial1 R3 Configuration R3#show run Building configuration...
Current configuration : 833 bytes ! version 12.2 ! hostname R3 ! enable secret cisco ! ip subnet-zero ! interface Ethernet0 ip address 10.3.3.3 255.0.0.0 ! interface Serial0 ip address 192.168.23.3 255.255.255.0 ! router rip version 2 network 10.0.0.0 network 192.168.23.0 no auto-summary ! ip classless ! line con 0 transport input all line vty 0 4 password certzone login ! end R3 Route Table R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:02, Serial0 R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:02, Serial0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks R 10.1.1.0/24 [120/2] via 192.168.23.2, 00:00:02, Serial0 C 10.0.0.0/8 is directly connected, Ethernet0 C 192.168.23.0/24 is directly connected, Serial0 Task 4 R1 Configuration R1#show run Building configuration...
Current configuration: ! version 12.0 ! hostname R1 ! enable password cisco ! ip subnet-zero ! interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ! interface Serial0 ip address 192.168.12.1 255.255.255.0 ! router eigrp 123 network 10.0.0.0 network 192.168.12.0 ! ip classless ! ! line con 0 transport input none line vty 0 4 password certzone login ! end R1 Route Table R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.1.0/24 is directly connected, Ethernet0 D 10.0.0.0/8 is a summary, 00:08:06, Null0 R2 Configuration R2#show run Building configuration... Current configuration: ! version 12.1 ! hostname R2 !
enable secret cisco ! ip subnet-zero ! interface Ethernet0 ip address 10.2.2.2 255.255.255.0 ! interface Serial0 ip address 192.168.12.2 255.255.255.0 ! router eigrp 123 network 10.0.0.0 network 192.168.12.0 ! ip classless ! ! line con 0 transport input none line aux 0 line vty 0 4 password certzone login ! end R2 Route Table R2#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:09:39, Null0 C 10.2.2.0/24 is directly connected, Ethernet0 Task 5 R1 Configuration R1#show run Building configuration... Current configuration: ! version 12.0 ! hostname R1 ! enable password cisco ! ip subnet-zero
! interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ! interface Serial0 ip address 192.168.12.1 255.255.255.0 ! router eigrp 123 network 10.0.0.0 network 192.168.12.0 no auto-summary ! ip classless ! ! line con 0 transport input none line vty 0 4 password certzone login ! end R1 Route Table R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route, o - ODR Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 2 subnets D 10.2.2.0 [90/1764352] via 192.168.12.2, 00:00:02, Serial0 C 10.1.1.0 is directly connected, Ethernet0 R2 Configuration R2#show run Building configuration... Current configuration: ! version 12.1 ! hostname R2 ! enable secret cisco ! ip subnet-zero ! interface Ethernet0 ip address 10.2.2.2 255.255.255.0 ! interface Serial0
ip address 192.168.12.2 255.255.255.0 ! router eigrp 123 network 10.0.0.0 network 192.168.12.0 no auto-summary ! ip classless ! line con 0 transport input none line aux 0 line vty 0 4 password certzone login ! end R2 Route Table R2#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set C 192.168.12.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 2 subnets D 10.1.1.0 [90/2195456] via 192.168.12.1, 00:00:48, Serial0 C 10.2.2.0 is directly connected, Ethernet0 5 ISDN and DDR This Tutorial attempts to cover all ISDN/DDR material likely to be on the CCNA exam. As a result of your ISDN studies, you should be able to answer any test questions about ISDN, PPP, and DDR. In addition to helping you pass the exam, learning ISDN well will give you a very important foundation for further progress in your internetworking knowledge and career. It's worth remembering that ATM, ISDN, and Frame Relay were all developed as part of the same standards process, a process that followed and drew from the OSI model development. 5.1 Tutorial Introduction One of the more difficult problems to overcome when preparing for the CCNA 2.0 exam is the lack of an official exam blueprint. This White Paper will attempt to cover all material likely to be on the exam based on several sources including the exam blueprint for version 1.0 of the exam, Leigh Ann Chisholm's "CCNA V2.0 Exam Objectives" White Paper, and some material from the old ACRC course objectives. An important question to ask yourself is "Why do I need to learn this material?" The obvious answer is to pass the test, but the not so obvious answer is that learning ISDN well will give you a very important foundation for further progress in your internetworking knowledge and career. It's worth remembering that ATM, ISDN, and Frame Relay were all developed as part of the same standards process, a process that followed and drew from the OSI model development. As a result of your ISDN studies, you should be able to answer any test questions about ISDN, PPP, and DDR. You should come away with a deeper understanding of
the networking puzzle in general and just how the ISDN piece fits in. With these thoughts in mind, let's get started. ISDN Where do we start our ISDN knowledge quest? As you might expect, the ancient answer is "at the beginning" of course! What exactly is ISDN? ISDN stands for Integrated Services Digital Network and was developed as a digital solution to carry data, voice, and video traffic over a circuit-switched connection using the existing PSTN infrastructure. Some good questions to ask are "what do we mean by circuit-switched?" and "how is this different from packet-switched?" Circuit switching uses a dedicated physical circuit path between the sender and the receiver for the duration of the "call." You have been using circuit switching for years with your phone at home. Just like your telephone, when you use ISDN, you "place a call." Packet switching, on the other hand, does not require calls to be set up and torn down. With packet switching, various nodes share bandwidth with each other by sending packets. ISDN is commonly used in the home and small office market for Internet access, telecommuting, and for backing up dedicated WAN circuits such as frame relay or T-1 circuits. ISDN comes with three different types of channels, although only the first two are commonly seen. The three types of channels are as follows:
B Channel 64 Kbps
D Channel 16 Kbps (BRI) or 64 Kbps (PRI)
H0 Channel 384 Kbps (PRI Only)
A single D channel is used for control and signaling information to set up and tear down B and H channels, although a D channel can also support user data transmission under certain circumstances. B channels are used for end user voice, video, and data traffic. H channels are only used by PRI interfaces for high bandwidth services such as videoconferencing and are equivalent to 6 B channels. You should also note that a single D channel can carry signaling for multiple B channels at the same time, allowing end users a full 64 Kbps clear channel unlike the overhead associated with ATM. These channels are combined to form Basic Rate Interface (BRI) and Primary Rate Interface (PRI) circuits.
BRI 2 B Channels + 1 16 Kbps D Channel
PRI (US & Japan) 23 B Channels + 1 64 Kbps D Channel
PRI (Europe & Australia) 30 B Channels + 1 64 Kbps D Channel
The BRI Physical Layer specification is International Telecommunication Union Telecommunication Standardization Sector (ITU-T) (formerly the Consultative Committee for International Telegraph and Telephone [CCITT]) I.430. The PRI Physical Layer specification is ITU-T I.431. ISDN Primary Rate Interface (PRI) service offers 23 B channels and one D channel in North America and Japan, yielding a total bit rate of 1.544 Mbps (the PRI D channel runs at 64 Kbps). ISDN PRI in Europe, Australia, and other parts of the world provides 30 B channels plus one 64 Kbps D channel and a total interface rate of 2.048 Mbps. Standards Although work began on ISDN in the 1960s, the first set of standards was not published until 1984 by the CCITT. Subsequently, the CCITT became the International Telecommunications Union Telecommunication Standardization Sector (ITU-T). The ITU-T maintains the standards today and divides them into several different protocol series.
E-Series The E series of ISDN standards recommends telephone network standards such as E.163 (the International Telephone Numbering Plan) and E.164 (International ISDN Addressing). I-Series The I series of ISDN standards deals with concepts, terminology, and general methods. Examples of I series protocols include I.100 (General ISDN concepts, structures, and terminology), I.200 (Service aspects of ISDN), I.300 (Network aspects of ISDN), and I.400 (User to Network Interfaces (UNI)). Q-Series The Q series of ISDN standards covers switching and signaling operation. Examples of Q series protocols include Q.921, and Q.931. Q.921 describes the LAPD ISDN data link processes, while Q.931 describes the OSI Layer 3 functions of ISDN. Reference Points and Functions The ISDN architecture was developed after the basic OSI model work was completed and supplements it. ISDN architecture reflects the strong service provider orientation of its designers, with greater initial emphasis on management and control. Functional Model In contrast to OSI, the ISDN reference models define not just protocols and services, but functional groups that define sets of common capabilities, and reference points that define the interactions of different kinds of functional groups. ISDN components include terminal equipment, terminal adapters, and terminating equipment. ISDN terminal equipment comes in two types, TE1 and TE2. Equipment that meets the ISDN standard, such as ISDN terminals and ISDN phones, are known as terminal equipment type 1 (TE1) equipment. Equipment that does not meet ISDN standards is referred to as terminal equipment type 2 (TE2). TE1s use a four-wire, twisted-pair digital link to connect to the ISDN network. TE2s connect to the ISDN network through a terminal adapter or TA. An ISDN TA can be either a standalone device or a daughter card inside the TE2. If the TE2 is implemented as a standalone device, it connects to the TA via a standard physical-layer interface such as EIA/TIA-232-C (formerly RS-232-C), V.24, or V.35. After the TE1 and TE2 devices, the next connection point in the ISDN network is the network termination type 1 (NT1) or network termination type 2 (NT2) device. In the US, the NT1 is a customer premises equipment (CPE) device. In most other parts of the world, the NT1 is part of the network provided by the carrier. The NT2 is typically found in digital private branch exchanges (PBXs). An NT1/2 device can also be found as a single device that combines the functions of an NT1 and an NT2.
Figure 1. ISDN specifies a number of reference points that define logical interfaces between functional groupings, such as Terminal Adapters (TAs) and NT1s. ISDN reference points include the following as seen in Figure 1: R - The reference point between a TE2 device and a TA. S - The reference point between the CPE and the NT2. T - The reference point between the NT1 and NT2 devices. (Note: When no NT2 device is used, as is normally the case for BRIs, the CPE-to-carrier interface is called the S/T interface). U - The reference point between NT1 devices and line-termination equipment in the carrier network. (Note: The U reference point is relevant only in North America, where the carrier network does not provide the NT1 function.) Equipment Requirements Using Cisco Routers Because there is not a single ISDN switch standard defined, you must explicitly define the ISDN switch type on each router. In general, you can define two different classes of ISDN switches, BRI (basic rate switches) and PRI (primary rate switches). Note that prior to IOS version 11.3, only a single ISDN switch type was supported, so you cannot mix BRI and PRI interfaces in the same router chassis. With the release of IOS version 11.3, however, multiple switch types in a single Cisco IOS chassis are now supported. ISDN Switch Types ISDN configuration requires that the router communicate with the central office switch. Until this communication is established, you cannot effectively continue configuring the router. The central office ISDN switch provides two functions: local termination and exchange termination. Local termination deals with the transmission facility and termination of the local loop. Exchange termination deals with the switching portion of the local exchange.
The first step in configuring ISDN on a Cisco router is to identify the correct ISDN switch type using a global command. For a practical example, examine the output of the switch type command. router(config)#isdn switch-type ? basic-1tr6 1TR6 switch type for Germany basic-5ess AT&T 5ESS switch type for the U.S. basic-dms100 Northern DMS-100 switch type basic-net3 NET3 switch type for UK and Europe basic-ni1 National ISDN-1 switch type basic-nwnet3 NET3 switch type for Norway basic-nznet3 NET3 switch type for New Zealand basic-ts013 TS013 switch type for Australia ntt NTT switch type for Japan vn2 VN2 switch type for France vn3 VN3 and VN4 switch types for France Notice that the ISDN switch types most commonly seen in the US are the basic-ni1, basic-dms100, and basic-5ess switches. Europe and the rest of the world use different ISDN switches, such as the basic-net3. Note that some switches deactivate Layer 2 of the D channel when no calls are active, so the router must be configured to perform TEI negotiation at the first call instead of at router power-up (the default). To enable TEI negotiation at the first call, use the global configuration isdn tei-negotiation first-call. PRI switches are configured in a similar manor as seen by the sample output below: router(config)#isdn switch-type ? primary-4ess AT&T 4ESS switch type for the U.S. primary-5ess AT&T 5ESS switch type for the U.S. primary-dms100 Northern Telecom switch type for the U.S. primary-net5 European switch type for NET5 primary-ntt Japan switch type primary-ts014 Australia switch type One of the major differences in configuring the router for a PRI instead of a BRI physical interface is the controller. You will need to configure the router as follows for a PRI. Notice that you have to define the framing type (sf or esf), you have to define the linecode (b8zs or ami), and you have to define the number of B and D channels. Note that PRI channels 0-23 map to pri-group timeslots 1-24. The same +1 mapping is used on E1-based PRI. controller T1 0 framing esf linecode b8zs pri-group timeslots 1-24 There is another difference in configuring BRIs and PRIs: the BRI physical interface is represented by an interface named BRI, but the PRI physical interface is represented by an interface named serialX:23 since the last channel of a PRI is the D channel. For example: with a BRI, your might see interface BRI 0, but with a PRI, you will see something similar to interface Serial0:23. Note: There is no standard format for SPID numbers. Consequently, SPID numbers vary depending on the switch vendor and the carrier. Service Profile Identifiers (SPIDs) An essential difference between US ISDN switches and the ISDN switches the rest of the world uses is whether a Service Profile Identifier (SPID) is used. For example, DMS-100 and National ISDN-1 switches require SPIDs. An AT&T 5ESS switch might also require SPIDs depending upon the current software version. A SPID is a number provided by the ISDN carrier that identifies the line setup and configuration information of the ISDN BRI. When a device attempts to connect to the ISDN network, it performs a D channel Layer 2 initialization process that causes a TEI to be
assigned to the device. You can observe this by enabling the debug isdn q921 command. The device then attempts D channel Layer 3 initialization. If SPIDs are necessary but not configured, or configured incorrectly on the device, the Layer 3 initialization fails and the ISDN services cannot be used. The AT&T 5ESS switch supports up to eight SPIDs per BRI. Because multiple SPIDs can be applied to a single B channel, multiple services can be supported simultaneously. For example, the first B channel can be configured for data, and the second B channel can be configured for both voice (using an ISDN telephone) and data. DMS-100 and National ISDN-1 switches support only two SPIDs per BRI: one SPID for each B channel. If both B channels will be used for data only, configure the router for both SPIDs (one for each B channel). You cannot run data and voice over the same B channel simultaneously. The absence or presence of a channel's SPID in the router's configuration dictates whether the second B channel can be used for data or voice. A typical Cisco IOS SPID configuration is: interface BRI0 isdn spid1 0835866201 8358662 isdn spid2 0835866401 8358664 These commands also specify the local directory number (LDN), which is the seven-digit number assigned by the service provider and used for call routing. The LDN is not necessary for establishing ISDN-based connections, but it must be specified if you want to receive incoming calls on B channel 2. The LDN is required only when two SPIDs are configured (for example, when connecting to a DMS or NI1 switch). Each SPID is associated with an LDN. Configuring the LDN causes incoming calls to B channel 2 to be answered properly. If the LDN is not configured, incoming calls to B channel 2 may fail. PPP Although ISDN can use numerous encapsulation protocols including PPP, HDLC, V.120, and X.25, PPP is by far the most common encapsulation. Note that X.25 can also be used for datagram delivery over the D channel. You can see an everyday example of X.25 using the D channel when you visit the ATM to withdraw cash at the bank. PPP is defined in RFC 1661. It is the most commonly used encapsulation because it supports multiple routed protocols and provides an excellent means for negotiating and authenticating compatible link and protocol configurations. The PPP standard defines several major components including: • Framing • Link Control Protocol (LCP) • Authentication • Network Control Protocol (NCP) • PPP Multilink Over Synchronous Physical Media Dial-on-Demand Routing (DDR) provides network connections across Public Switched Telephone Networks (PSTNs). Dial-on-Demand Routing provides session control for wide-area connectivity over circuit switched networks, which in turn provides on-demand services and decreased network costs. DDR can be used over synchronous serial interfaces with V.25bis and DTR dialing for Switched 56 CSU/DSUs, ISDN terminal adapters (TAs), or synchronous modems. Over Asynchronous Physical Media Although Cisco's IOS supports asynchronous serial lines by using conventional modems on the auxiliary port of Cisco routers or on dedicated Cisco communication servers such as the AS5300, this topic is beyond the scope of this paper. The rest of the paper will deal strictly with ISDN BRI interfaces. Over ISDN DDR is supported over ISDN using BRI and PRI interfaces.
LCP Capabilities / Options PPP Link Control Protocol (LCP) provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. LCP goes through four distinct phases:
1. First, link establishment and configuration negotiation occurs. Before any network-layer packets can be exchanged, LCP first opens the connection and negotiates configuration parameters. When a configuration-acknowledgment frame has been both sent and received, this phase is complete and link quality determination can take place.
2. The next possible step is link quality determination, but this phase is optional. In this phase, the link is tested to determine whether the link quality is sufficient to bring up network-layer protocols. LCP can delay transmission of network-layer protocol information until this phase is complete.
3. Following link quality determination, network-layer control protocol (NCP) configuration negotiation occurs. After LCP has finished the link-quality determination phase, network-layer protocols can be configured separately by the appropriate NCP and can be brought up and taken down at any time. A practical example would be configuring the ISDN connection for simultaneous use of both IP and AppleTalk. Each routable protocol would require a separate NCP configuration negotiation. If LCP closes the link, LCP informs the network-layer protocols so that they can take appropriate action.
4. The final phase is link termination. Although LCP can terminate the link at any time, link termination usually occurs at the request of a user. Termination can also happen because of a physical event, such as the loss of carrier or the expiration of an idle-period timer.
There are three classes of LCP frames: link establishment frames, link termination frames, and link maintenance frames. Link establishment frames are used to establish and configure a link, link termination frames are used to terminate a link, and link maintenance frames are used to manage and debug a link. Configuring PPP The first step in configuring PPP is to specify PPP as the encapsulation method. Note that if you use dialer profiles (a topic we will cover later in this tutorial) you must specify encapsulation ppp on both the physical BRI interface and the logical dialer interface. Once we have enabled encapsulation ppp, we can next configure authentication, although this is an optional step. You do not necessarily have to use authentication. Authentication PPP has excellent authentication features, including both Password Authentication Protocol (PAP) and Challenge Authentication Protocol (CHAP). PAP uses a two-step process where the password is transmitted in clear text form similar to the way you would see it in FTP or Telnet. The disadvantage to using PAP is that the password is vulnerable to interception since it is transmitted in the clear. I have never seen PAP used in a production network because of this vulnerability. CHAP, on the other hand, is a much more secure authentication protocol because the password is never passed over the network as clear text. Unlike PAP, CHAP uses a three-step process and uses the MD5 hashing algorithm for much greater security. This process is documented more thoroughly in RFC 1994. Now that we understand what the two most common authentication options are under IOS, how do we actually configure authentication on a Cisco router? The first step in configuring authentication on a Cisco router is to configure a user password database. There are several choices to be made here. We can configure the user password database on a remote server using Tacacs+ or Radius, or we can configure the local user password database directly on the router. A Tacacs+ or Radius discussion is beyond the scope of this paper, so we will only use the local user password database option. Before we configure the user password database, we need to make a decision. Do we want to simply use the host name of the router as the username or do we want to have one or more different usernames? Using the router host name lets us configure authentication in the simplest fashion, but does not give us as
much flexibility. We might want to use different usernames for added security or to configure the router for multiple ISDN connections. Let's start by taking a look at the simplest case where the router uses its hostname in the user password database. Note that the user password database is configured in the global configuration mode and is a requirement for proper configuration of authentication. The password entered must be the same on both routers participating in authentication. Here is a practical example:
Figure 2. First, we enter the username and password on R1, then on R2. Notice that in each case, the username entered is the host name for the other router. You can also see that there are two options for the password. We can enter an unencrypted password or a hidden password. I usually just enter an unencrypted password. Once we complete the configuration, the password will be converted to the type 7 (hidden) format anyway. r1(config)#username r2 password 0 cisco r2(config)#username r1 password cisco ? 0 Specifies an UNENCRYPTED password will follow 7 Specifies a HIDDEN password will follow LINE The UNENCRYPTED (cleartext) user password r2(config)#username r1 password 0 cisco Now, suppose we want to use the second option and configure a username other than the router's hostname. The configuration of the database is nearly identical to the procedure above; we just use a different username. For example, let's use a hostname of CCNA1 for router 1 and CCNA2 for router 2. As we will shortly see, configuring authentication will require an additional interface command in this case. Let's complete the configuration for the first case and then examine the second. Here is the rest of the configuration to configure CHAP authentication using the first case. Once the user password database has been created, we need to enter three interface configuration commands: encapsulation PPP (The default encapsulation on a BRI is still HDLC) ppp authentication chap (For PAP we would use ppp authentication pap) dialer map protocol next-hop-address name router_ppp_authentication_name Note that if you need to configure authentication using dialer profiles then the ppp authentication chap command must be applied under both the physical BRI interface and the logical dialer interface. Observe these commands using our first example: Router 1 interface BRI0/0 ip address 172.19.1.6 255.255.255.252 encapsulation ppp dialer map ip 172.19.1.5 name r2 broadcast 8358662 dialer-group 1 isdn switch-type basic-ni ppp authentication chap Router 2 interface BRI0 ip address 172.19.1.5 255.255.255.252 encapsulation ppp dialer map ip 172.19.1.6 name r1 broadcast 8358661 dialer-group 1
isdn switch-type basic-ni ppp authentication chap Now let's look at our second example. In this case, we need to use an additional interface command on each router to specify the alternate chap hostname, ppp chap hostname username. Notice that we use the hostname we want to send to the other router in configuring the command: Router1 r1(config-if)#ppp chap hostname ? WORD Alternate CHAP hostname r1(config-if)#ppp chap hostname CCNA1 Router2 r2(config-if)#ppp chap hostname CCNA2 This discussion of authentication should bring up a question in your mind about how to tell if authentication is working correctly. Luckily, there is a dead giveaway for an authentication problem as well as an excellent debugging command, debug ppp authentication. The dead giveaway for an authentication problem occurs when you observe the following: 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 1d16h: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 1d16h: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 1d16h: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down When you observe the interface connecting, going up, and then down, you know you need to turn on debug ppp authentication. This command is extremely helpful because it shows you exactly what the problem is. Let's take a look at a couple of examples: Example 1 - The username database is not configured. Notice that the debug output is telling us that there is no username password database entry for r2. r1#debug ppp authentication PPP authentication debugging is on r1#ping 172.19.1.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.19.1.5, timeout is 2 seconds: 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 1d16h: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 1d16h: BR0/0:1 PPP: Treating connection as a callout 1d16h: BR0/0:1 CHAP: O CHALLENGE id 11 len 23 from "r1" 1d16h: BR0/0:1 CHAP: I CHALLENGE id 1 len 23 from "r2" 1d16h: BR0/0:1 CHAP: Username r2 not found 1d16h: BR0/0:1 CHAP: Unable to authenticate for peer. 1d16h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down Example 2 - The dialer map statement is not configured correctly. No remote PPP authentication name is specified, just the next hop address and dial string. r2#ping 172.19.1.56 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.19.1.6, timeout is 2 seconds: %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up.
PPP BRI0: B-Channel 1: Send CHAP challenge id=1 to remote PPP BRI0: B-Channel 1: CHAP challenge from r1 PPP BRI0: B-Channel 1: Failed CHAP authentication with remote. Remote message is: Authentication failure %ISDN-6-DISCONNECT: Interface BRI0: B-Channel 1 disconnected from 8358661 , call lasted 1 seconds %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to down %LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up. PPP BRI0: B-Channel 1: Send CHAP challenge id=1 to remote PPP BRI0: B-Channel 1: CHAP challenge from r1 PPP BRI0: B-Channel 1: Failed CHAP authentication with remote. Remote message is: Authentication failure %ISDN-6-DISCONNECT: Interface BRI0: B-Channel 1 disconnected from 8358661 , call lasted 1 seconds Example 3 - Here is a successful authentication using the alternate CHAP hostname. Notice also that the outbound challenge is from CCNA2 and the inbound challenge is from CCNA1. 00:13:40: BR0:1 PPP: Treating connection as a callout 00:13:40: BR0:1 PPP: Phase is AUTHENTICATING, by both 00:13:40: BR0:1 CHAP: Using alternate hostname CCNA2 00:13:40: BR0:1 CHAP: O CHALLENGE id 2 len 28 from "CCNA2" 00:13:40: BR0:1 CHAP: I CHALLENGE id 13 len 28 from "CCNA1" 00:13:40: BR0:1 CHAP: Using alternate hostname CCNA2 00:13:41: BR0:1 CHAP: O RESPONSE id 13 len 28 from "CCNA2" 00:13:41: BR0:1 CHAP: I SUCCESS id 13 len 4 00:13:41: BR0:1 CHAP: I RESPONSE id 2 len 28 from "CCNA1" 00:13:41: BR0:1 CHAP: O SUCCESS id 2 len 4 Example 4 - Wrong password on one of the routers. PPP BRI0: B-Channel 1: Send CHAP challenge id=1 to remote PPP BRI0: B-Channel 1: CHAP challenge from r2 PPP BRI0: B-Channel 1: Failed CHAP authentication with remote. Remote message is: MD compare failed As we can see, there are outstanding tools to debug authentication. Now that we understand authentication, let's look at another PPP feature: compression. Compression The Point-to-Point (PPP) Compression Control Protocol (CCP) is an Internet Engineering Task Force (IETF) draft RFC that defines a method for negotiating data compression over PPP links. Cisco implements CCP using the interface command compress interface at both ends of the ISDN link. There are two possible compression options: Stacker (LZS) compression and Predictor (RAND) compression. The Stacker algorithm is the preferred algorithm for PPP encapsulation but can also be used with LAPB as well. The Predictor algorithm can be used for either HDLC or PPP encapsulation. Error Detection Error detection with PPP normally uses the final two bytes (16 bits) of the PPP frame, known as the Frame Check Sequence (FCS). It is possible to use a 4 byte (32-bit) implementation if both ends of the connection support this option. Multilink PPP If you have multiple links to the same destination, you may want to enable PPP Multilink for load balancing or in response to different bandwidth requirements. You can set an inbound load threshold, an outbound load threshold, or both to bring up multiple links. Note that PPP Multilink supports packet fragmentation and sequencing in accordance with RFC 1717, allowing packets to be fragmented and the fragments to be sent at the same time over multiple point-to-point links to the same destination address. Although you can use multilink PPP on asynchronous, BRI, and
PRI interfaces, this tutorial will discuss configuration of only a single BRI interface. The configuration for PPP Multilink begins by configuring the BRI just as you would for normal DDR. The configuration differs because, at this point, you must use the interface command ppp multilink and define a load threshold for bringing up additional links. You also need to make sure that you configure any additional dialer map statements. Here is an example of the configuration: interface BRI0/0 ip address 172.19.1.6 255.255.255.252 no ip directed-broadcast encapsulation ppp dialer map ip 172.19.1.5 name r2 broadcast 8358662 dialer map ip 172.19.1.5 name r2 broadcast 8358664 dialer load-threshold 40 either dialer-group 1 isdn switch-type basic-ni isdn spid1 0835866101 8358661 isdn spid2 0835866301 8358663 ppp authentication chap ppp multilink Notice the dialer load-threshold 40 either command. This command is telling the router to bring up the additional B channel when the load for either inbound or outbound traffic reaches 40%. You can also see that there are two dialer maps configured -- one for each of the B channels on router r2. Dial-on-Demand Routing Although IOS provides internetworking services primarily for ISDN switched connections, these services also exist for other switched connections such as PSTN. One of the questions commonly seen regarding what equipment is needed to simulate an ISDN connection is, "Can I connect two BRI interfaces on two routers back-to-back like I can with serial interfaces?" Unfortunately, the answer is no. You must use an ISDN switch simulator or actual ISDN switch to practice an ISDN connection. It is possible, however, to use the aux ports and two modems over the PSTN to practice DDR. Additional information on this can be found by searching the archives at http://www.groupstudy.com/. Cisco's IOS has two DDR implementations, legacy DDR and dialer profiles. The difference between the two is that legacy DDR applies commands directly to the physical ISDN interface, whereas a dialer profile applies most commands to a virtual dialer interface and only a minimal set of commands directly to the physical ISDN interface. Basic Operation Before we examine Dial on Demand Routing (DDR) in detail, let's look at the basic flow so that we understand what is occurring. This flow chart applies to DDR in general, so the same basic process occurs regardless of whether you are using floating static routes, legacy DDR, or dialer profiles. Each individual step will be covered in detail shortly -- this is the "big picture" view of what is happening. The first step in the DDR process is that an outbound packet arrives at the router and is examined to see if it represents interesting traffic, that is, a type of packet for which you want to bring up the ISDN line. For example, you are very likely to want to bring up an ISDN line to pass IP traffic, but not Cisco Discovery Protocol (CDP) traffic since CDP sends traffic every 60 seconds. As you will see shortly, the dialer list is used to define what traffic is interesting. Let's examine a case where the outbound packet is a CDP packet, but only IP traffic is interesting. When the outbound packet is examined and found to be uninteresting, the router will next check to see if the router is currently connected to the remote router. If the router is currently connected, the CDP traffic will be sent. However, if the router is not currently connected, the packet will be dropped since CDP packets are not interesting and we don't want to bring up the ISDN link for uninteresting traffic. Let's next examine the case where the traffic is interesting.
In this example, let's assume that we are trying to ping the IP address of the remote router's BRI interface. Since IP traffic is defined to be interesting by the dialer-list, the router will next check to see if the ISDN line is already connected to the remote router. If it is already connected, then the router will reset the idle timer and send the packet. The idle timer determines when the ISDN call will be disconnected. When the idle timer expires with no further interesting traffic, the ISDN call will be disconnected. What happens, however, if the ISDN line is not already connected? In this case, the router will next check to see if it has a dial string configured in some way so that the router knows how to dial the remote router. If no dial string is configured, the packet is just dropped. If a dial string is configured, however, the router will place a call to the remote router, reset the idle timer, and send the packet. This process repeats with each outgoing packet until the dial idle timer expires and the connection is torn down due to a lack of interesting traffic. The process is illustrated in the following flow chart.
Figure 3. DDR Process Flow Chart Now that we understand the overall process of what is happening with DDR, let's examine each step in greater detail. Configuring DDR Dynamic or Static Routing? When configuring DDR, one is faced with several choices. The first choice you need to make is whether to use static routing or dynamic routing. Static routing is simple and avoids filling up the link with routing information, but also creates a problem because a static route will always exist regardless of whether or not you can actually route packets using that static route. What would happen, for example, if the line from the central office to the remote ISDN router were cut? With static routes, you would have no way to adjust to this type of change. The router would use the static routing information and attempt to send packets out the BRI interface even though no connection to the remote router was made. Of course, there is a way around this type of problem -- dynamic routing protocols. Dynamic routing protocols such as RIP, however, have their own advantages and disadvantages.
Let's look at two different cases of dynamic protocols: distance-vector protocols (such as RIP or IGRP) and link state protocols (such as OSPF). With a distance vector protocol, the entire routing table will be periodically broadcast at a given interval. This creates an acute problem because the ISDN link will be brought up every so often to broadcast routing updates, even if no other traffic is present. This keeps the link constantly going up and down. Link state protocols create a similar problem with their hello timers. The periodic hello packets will keep the line up unnecessarily as well. Both distance vector and link state protocols, however, have the advantage that they are dynamic routing protocols and can adjust to network changes. If we examine the case we discussed above with a cut line to the remote router, we can see that a dynamic routing protocol would be advantageous because it would detect that there is no route available across the ISDN link and will keep the router from sending packets across a non-existent link. With static routes, routes are entered manually, eliminating the need for a routing protocol to broadcast routing updates across the DDR connection. As you can see, it comes down to a situational judgment. Static routes can be used quite effectively in small networks that do not change often. Another problem with static routes is that one usually needs to configure redistribution of the static routes into the dynamic routing protocol to ensure end-to-end connectivity. For example, to redistribute the static route to other networks using RIP, use the following configuration commands: router rip network 192.168.1.0 redistribute static Dynamic routing protocols would not require this type of route redistribution. Since it is obvious that both static and dynamic routes have their pros and cons, a logical question to ask is if there are ways around these problems? The answer is that of course there are, but they are beyond the CCNA-level scope of this paper. I'll just briefly mention that one of the solutions to DDR problems caused by distance vector protocols is to use snapshot routing and one of the solutions to DDR problems caused by the OSPF link state protocol is to use OSPF demand-circuit. See the CCIE-level White Paper on ISDN for details on these topics. Now that we understand some of our routing options, let's take a step-by-step look at how to configure DDR. Specifying Interesting Traffic DDR configuration begins by configuring a dialer-list to define interesting traffic, that is, traffic for which you wish to bring up the ISDN connection. We define a dialer-list in global configuration mode and then apply the dialer-list using the interface configuration command dialer-group. When I am configuring ISDN DDR, I like to first define my dialer lists very broadly using IP until I have all features working such as call setup and teardown, authentication, callback, etc. Once I have basic features working correctly, then I make the dialer list more granular, if necessary, using an access-list. Here is an example that shows traffic that can be defined as interesting using a broad dialer list: Router(config)#dialer-list 1 protocol ? Appletalk Appletalk Bridge Bridging Clns OSI Connectionless Area Services Clns_es CLNS End System Clns_is CLNS Intermediate System Decnet DECnet Decnet DECnet node Decnet_router-L1 DECnet router L1 Decnet_router-L2 DECnet router L2 Ip IP Ipx Novell IPX Llc2 LLC2 Vines Banyan Vines Xns XNS Using the above syntax, the first dialer list I like to configure is:
Router(config)#dialer-list 1 protocol ip permit Next, I apply the dialer list to the BRI interface using the dialer-group command: interface bri0 dialer-group 1 Configuring Dialer Maps For one router to connect to another router via ISDN, we must have some way to configure the number to dial since ISDN is a circuit switched technology and requires that a call be placed to complete the connection. The simplest way to configure the number to dial is to use the dial string command. Here is an example: dialer string 384000 This method of configuring the dial string is inefficient and doesn't support routing very well. For that, we need to use a more difficult method with dialer maps. If you want to understand dialer maps well, take a close look at how frame-relay map statements are used. Often there is confusion about when to use dialer strings and when to use dialer maps. You do not use both methods, you use only one or the other. If you already have a dialer string configured, remove the dialer string and enter a dialer map statement to see the difference. Dialer maps are more flexible because you can have dialer map statements for multiple router protocols and for multiple destination routers. Here are some sample dialer map statements so you can get a feel for the syntax of the dialer map command: dialer map ip 172.16.5.2 name r2 broadcast 4930622 dialer map appletalk 201.2 name r2 broadcast 4930622 dialer map ipx 125.0000.0c92.8ab3 name r2 broadcast 4930622 Notice how the dialer map specifies the protocol to be mapped, the next hop address of the neighboring router, followed by the host name of the neighboring router, the broadcast parameter, and the dial string of the neighboring router. Note: one of the mistakes I see people make when configuring ISDN is to omit the broadcast parameter. If you want to run a dynamic routing protocol over the ISDN link, then you must use the broadcast parameter because RIP and IGRP, for example, broadcast periodic routing table updates. Other protocols, such as OSPF or EIGRP, may actually use a multicast address, but you will find that these multicast updates are not sent over the ISDN line unless the broadcast parameter is set. Bandwidth-On-Demand IOS has a number of features that support bandwidth-on-demand. The two most commonly used are dialer load-threshold and dialer idle-timeout. PPP Multilink, another bandwidth-on-demand feature, was discussed earlier in this tutorial. The dialer load-threshold command sets the maximum load before the dialer places another call to a destination. The load can be set based on the outbound load, the inbound load, or the load in either direction. dialer load-threshold load [outbound | inbound | either] The dialer idle-timeout command is used to specify the idle time before the line is disconnected. The syntax of this interface command is as follows: dialer idle-timeout seconds Verifying Dial-On-Demand Routing Operation There are many techniques for verifying correct DDR operation. Here are a few of my favorites. ping I like to use ping to provide interesting traffic. By pinging the destination router, I can check the dialer-lists as well as observe the sequence of the call by enabling debug dialer events and debug isdn q931. show dialer show dialer provides a summary of DDR configuration parameters as well as the current status of DDR interfaces. If the interface in question is currently active, the show dialer command will also show why the call was initiated. show isdn active
The show isdn active command displays current call information, including the called number and the time until the call is disconnected. Here is a sample display: Router# show isdn active ------------------------------------------------------------------------------- ISDN ACTIVE CALLS ------------------------------------------------------------------------------- History Table MaxLength = 320 entries History Retain Timer = 15 Minutes ------------------------------------------------------------------------------- Call Calling Called Duration Remote Time until Recorded Charges Type Number Number Seconds Name Disconnect Units/Currency ------------------------------------------------------------------------------- Out 8001234567 Active(10) r2 11 u(E) Out 8001234567 Active(34) r2 115 5 u(D) ------------------------------------------------------------------------------- show isdn status show isdn status is one of my favorite commands when I am troubleshooting or just verifying an ISDN connection. With this command you can instantly tell whether or not the router is communicating with the ISDN switch in the central office. This information is important because unless the router is communicating with the central office switch, you cannot go any further in your ISDN configuration. Returning to our BRI configuration, once we enter the switch type and no shut the BRI interface, then we can see whether we are communicating with the ISDN switch by using the show isdn status command. The example below shows what you should see if no ISDN switch type is defined. You can also check to see that your switch is defined correctly: r1#sh isdn stat **** No ISDN Switchtype currently defined **** ISDN BRI0 interface Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 The example below shows what you should see when the router is communicating correctly with the switch: Router#show isdn status The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 64, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 calls Activated dsl 0 CCBs = 0 Total Allocated ISDN CCBs = 0 Notice that Layer 1 is active and Layer 2 has a state of "MULTIPLE_FRAME_ESTABLISHED". Let's compare these results to those seen in an example where the router is not communicating with the switch correctly. Notice that Layer 1 is deactivated and Layer 2 is "TEI_ASSIGNED". Router#show isdn status
The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: DEACTIVATED Layer 2 Status: TEI = 64, SAPI = 0, State = TEI_ASSIGNED Layer 3 Status: 0 Active Layer 3 calls Activated dsl 0 CCBs = 0 Total Allocated ISDN CCBs = 0 show ip route I use the show ip route command to make sure that DDR is working correctly. Do routing table entries appear in the routing table as they should? For example, is a given OSPF routing table entry marked Do Not Age (DNA)? debug isdn q921 In the following example, we enable debug isdn q921 and observe the initial communication with the ISDN switch when the interface is no shut. Notice from the arrows that information is being both transmitted and received by the router. r2#debug isdn q921 ISDN Q921 packets debugging is on r2#conf t r2(config)# r2(config)#int bri 0 r2(config-if)# no shut %LINK-3-UPDOWN: Interface BRI0, changed state to up ISDN BR0: TX -> IDREQ ri = 33114 ai = 127 ISDN BR0: RX <- IDDENY ri = 33114 ai = 127 ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 ISDN BR0: TX -> IDREQ ri = 38651 ai = 127 ISDN BR0: RX <- IDREM ri = 0 ai = 82 ISDN BR0: RX <- IDREM ri = 0 ai = 83 ISDN BR0: TX -> IDREQ ri = 1708 ai = 127 ISDN BR0: RX <- IDASSN ri = 1708 ai = 85 ISDN BR0: TX -> SABMEp sapi = 0 tei = 85 ISDN BR0: RX <- UAf sapi = 0 tei = 85 ISDN BR0: TX -> INFOc sapi = 0 tei = 85 ns = 0 nr = 0 i = 0x08007B3A0A30383335383636323031 ISDN BR0: RX <- INFOc sapi = 0 tei = 85 ns = 0 nr = 1 i = 0x08007B080382E43A ISDN BR0: TX -> RRr sapi = 0 tei = 85 nr = 1 ISDN BR0: TX -> IDREQ ri = 29037 ai = 127 ISDN BR0: RX <- IDASSN ri = 29037 ai = 86 ISDN BR0: TX -> SABMEp sapi = 0 tei = 86 ISDN BR0: RX <- UAf sapi = 0 tei = 86 ISDN BR0: TX -> INFOc sapi = 0 tei = 86 ns = 0 nr = 0 i = 0x08007B3A0A30383335383636343031 ISDN BR0: RX <- INFOc sapi = 0 tei = 86 ns = 0 nr = 1 i = 0x08007B080382E43A ISDN BR0: TX -> RRr sapi = 0 tei = 86 nr = 1 r2(config-if)# ^Z r2# debug isdn q931
The following example is from a failed call. This occurred because the router on the far end is not configured. The call is initiated with a ping. We can observe that the router attempts to setup the call, but then the call is released. r2#debug isdn q931 ISDN Q931 packets debugging is on r2#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echoes to 172.16.1.1, timeout is 2 seconds: ISDN BR0: TX -> SETUP pd = 8 callref = 0x10 Bearer Capability i = 0x8890 Channel ID i = 0x83 Called Party Number i = 0x80, '8358661' ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x90 Cause i = 0x82EF - Protocol error, unspecified ISDN BR0: Event: incoming ces value = 1. debug dialer events The debug dialer events command is another command that can be very useful for troubleshooting. Notice in the sample debug trace below that we can see the reason for dialing, the number the router is attempting to dial, that the interface obtains an up state, and that the call is connected. r1#debug dialer events Dial on demand events debugging is on r1#ping 172.19.1.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.19.1.5, timeout is 2 seconds: 00:33:37: BRI0/0 DDR: Dialing cause ip (s=172.19.1.6, d=172.19.1.5) 00:33:37: BRI0/0 DDR: Attempting to dial 8358662 00:33:158913789952: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 00:33:158913790016: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 00:33:37: BRI0/0:1 DDR: dialer protocol up. 00:33:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state to up.. 00:33:43: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 .. Success rate is 0 percent (0/5) Note: One of the questions I see a lot is "What ISDN simulator should I use?" For this example I used an Arca EmutelLite ISDN simulator. They cost approximately $1750 and make a good small lab simulator. Teltone also makes some good ISDN simulators that are relatively inexpensive Legacy DDR Let's examine an ISDN configuration in its most basic form. This is the minimum configuration needed to connect to another router. That router would have a similar configuration, although the dial string would be different. router1#show run Version 11.3 Hostname router1 ! isdn switch-type basic-ni1 !
interface bri0 ip address 192.168.1.1 255.255.255.0 dialer string 384000 dialer-group 1 ! dialer-list 1 protocol ip permit router2#show run Version 11.3 Hostname router2 ! isdn switch-type basic-ni1 ! interface bri0 ip address 192.168.1.2 255.255.255.0 dialer string 384020 dialer-group 1 ! dialer-list 1 protocol ip permit We can then test the configuration by pinging the other router's IP address for the BRI interface. Notice that we have defined a dialer string. Without the dialer sting, dialing cannot occur. Legacy DDR works great in simple situations such as a point-to-point circuit between two routers, but presents problems in other, more complex situations such as a central hub with two spokes. Examine the above configuration and imagine that router1 also needs to be able to dial another router, router3. There is only one dial string. How can you possibly dial router3? Could you configure another dial string for router3? Yes, you could, but the router will still dial the strings in order. You won't be able to connect to router3 from router1 until the router dials router2 first. A similar type of problem might occur if you needed to support both IP and AppleTalk or IPX, but need the IPX support only between router1 and router3. It is for these reasons that ISDN configuration evolved and another solution was developed: dialer profiles. Dialer Profiles Dialer profiles allow us to create a logical interface and apply various parameters to it instead of the actual physical BRI interface. In way, when a call needs to be made, the logical dialer interface is bound to the physical BRI interface. Dialer profiles allow us to apply a minimal configuration to the physical BRI interface, but also allow us to apply extensive configuration parameters to the logical dialer interface. This results in numerous differences from legacy DDR such as requirements to enable ppp authentication and encapsulation on both the physical and logical interfaces. Additional differences occur when using backup interface configurations because, with dialer profiles, only the logical dialer interface is placed into a standby mode. To configure dialer profiles, first we need to configure the physical interface, then we need to configure the logical dialer interface. Before we begin the configuration, however, we need to remove the legacy DDR configuration. If we later need to change from dialer profiles to legacy DDR, then we will need to remove the dialer profile configuration. What happens if we do not remove these configurations? We get error messages as seen below: Example 1 - Entering a dialer profile command on a legacy DDR interface R1(config-if)#dialer pool-member 1 %Remove Legacy DDR Configuration first Example 2 - Entering a legacy DDR command on an interface configured for dialer profiles R1(config-if)dialer-group 1 %Remove Dialer Profile Configuration first
Removing Legacy DDR Commands Before we configure the physical BRI interface for dialer profiles, we first need to remove all legacy DDR commands including dialer map statements, dialer group statements, and network layer addresses. Next, we need to assign the physical interface to a dialer pool as seen below. A physical interface can be assigned to multiple dialer pools, but a logical dialer interface can be assigned to only a single dialer pool. dialer pool-member number [priority priority] [min-link minimum] [max-link maximum]
• number refers to the dialer pool number, 1 through 255 • priority refers to the priority of this interface within the dialing pool, in the range 0 (lowest)
to 255 (highest). Interfaces with the highest priority are selected first for dialing out. The default is 0.
• minimum refers to the minimum number of B channels reserved for this dialer pool in the range 0 to 255. The default is 0.
• maximum refers to the maximum number of B channels reserved for this dialer pool in the range 0 to 255. The default is 255.
Configuring A Logical Dialer Interface To configure the logical dialer interface, we first need to create a logical dialer interface in the same way we create other logical interfaces such as loopback interfaces. Next, we associate a dialer pool with the dialer interface using the dialer pool number command, where the number is the same number configured using the dialer pool-member command. Next, we add a dialer-group statement to define interesting traffic and a dialer string to call. Finally, we add a dialer remote-name command to specify the authentication name of the remote router. Let's look at an example: interface BRI0 no ip address encapsulation ppp ppp authentication chap dialer pool-member 1 ! interface Dialer0 ip address 172.19.1.5 255.255.255.252 encapsulation ppp dialer remote-name r1 dialer string 8358661 dialer pool 1 dialer-group 1 ppp authentication chap ! dialer-list 1 protocol ip permit ISDN profiles do not use static dialer maps as used in legacy DDR. Instead, dialer profiles use dynamic dialer maps, which are created at the time a call is placed. Here is an example: r1#sh dialer maps Dynamic dialer map ip 172.19.1.5 name CCIE2 () on Dialer0 We can tell that dialer profiles are being used by observing messages as seen below where the logical dialer interface is bound to the physical BRI interface at the time of the call: 4d00h: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 4d00h: %DIALER-6-BIND: Interface BRI0/0:1 bound to profile Dialer0 4d00h: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 4d00h: BRI0/0:1 DDR: dialer protocol up. We can also use the show dialer command to observe that the dialer profile is included: r1#show dialer
BRI0/0 - dialer type = ISDN Dial String Successes Failures Last DNIS Last status 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. BRI0/0:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle BRI0/0:2 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle Dialer0 - dialer type = DIALER PROFILE Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is idle Number of active calls = 0 Dial String Successes Failures Last DNIS Last status 8358662 15 0 00:03:58 successful Default As you can see dialer profiles can solve some problems, but are more difficult to configure than legacy DDR. Conclusion ISDN is a complex and difficult topic to learn. This paper has only touched briefly on the most basic concepts. I would like to urge anyone studying for the CCNA exam to completely review the configuration guides for IOS and read the RFC for PPP. These two references may be beyond the scope of the material required to pass the CCNA test. However, if you need to understand ISDN well for real-world application, then they will help you understand exactly how PPP works and how many different ISDN options are available to you as an internetworking engineer to solve real-world problems. These references will only give you a leg up when it comes to your studies for either the CCNP exams or the CCIE exams. Finally, I would like to point out that your complete understanding of ISDN and PPP would help you understand other topics more easily. For example, did you know that Asynchronous Transfer Mode (ATM) uses the q.2921 and q.2931 protocols, and that these protocols are direct descendants of ISDN's q.921 and q.931 protocols? A solid knowledge of ISDN DDR and PPP will also help in other areas as well. If you understand PPP CHAP authentication, then you will find it much easier to understand routing protocol authentication methods and authentication, authorization, and accounting (AAA) down the road. Remember that CCNA is just the first step in a long journey as you seek to build a greater understanding of internetworking. Don't be afraid of the CCNA exam either. If you think that you might be ready, just go take it. At worst, you might fail, but you will learn a great deal about what the exam is like. You can then pass the exam the next time you try and move on to more advanced certifications such as the CCNP or CCDP. Good luck and have fun as you study and learn! 5.2 Lab Abstract 1 This lab is designed to walk you through a basic ISDN DDR configuration. This lab will show you what commands to type in and how to check that you have configured things correctly step-by-step. 5.3 Lab Abstract 2
This lab is designed to walk you through a basic dialer profile configuration and the special requirements this places on PPP CHAP authentication. This lab will show you what commands to type in and how to check that you have configured things correctly step by step. Some of the steps that were covered in great detail in the first lab scenario will not be covered as thoroughly in this scenario, so refer to the first lab as needed. 5.4 Lab Scenario 1 Introduction This lab is designed to walk you through a basic ISDN DDR configuration. This lab will show you what commands to type in and how to check that you have configured things correctly step-by-step. Network Specifications When you are finished building this network, it should meet the following specifications:
1. Each router should be able to dial the other. 2. Dialing should occur any time you ping the other router, but should not dial to send any
routing updates. 3. You should use only static routes but the administrative distance should be something
other than 0 or 1. 4. You should only be able to see the neighboring router with Cisco Discovery Protocol if
the ISDN link is already up. The Starting Configurations You will need to adjust the lab contents to fit your ISDN simulator and/or routers as necessary. You MUST use an ISDN simulator or actual ISDN lines. There is no way to configure ISDN using crossover cables or something similar The actual equipment used in developing this lab included a Cisco 1604 router and a Cisco 2610 router. The ISDN simulator was a Teltone ISDN Demonstrator with two U interfaces. You can use any router with suitable ISDN interfaces. Some good recommendations might include Cisco 2503s, 2504s, or 2522s. Here is the basic starting point for cabling your equipment: ISDN Information for Router1: isdn switch-type basic-ni isdn spid1 0835866101 8358661 isdn spid2 0835866301 8358663 ISDN Information for Router2: isdn switch-type basic-ni isdn spid1 0835866201 8358662 isdn spid2 0835866401 8358664
Figure 1. Configuration Tasks 1. Configure the ISDN switch type on each router. Before we begin, perform a write erase on each router to make sure that we are starting from scratch. After you enter the write erase command, reload the router. When you receive a prompt to configure the router, enter ctrl-c and the router will continue to boot up. Once this is done, enter exec mode by typing enable. You will see the following: Router> Router>enable Router# Once this is complete, check that no configuration exists by entering the write command followed by show configuration. (Note: you can use show configuration instead of show run because you just saved the configuration. This displays the current configuration faster than show run would.) You should not see any configured IP addresses, routing statements, or ISDN configurations of any kind. You can check this by using the show isdn status command to see that no ISDN switchtype is defined. Here is an example: router#sh isdn stat **** No ISDN Switchtype currently defined **** ISDN BRI0 interface Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 Since we have no ISDN switch type configured, our first step should be to configure one. We can use the ? to help us find the correct syntax for our switch type, basic-ni1. We will need to use the isdn switch-type global command on each router as follows: Router# Router#configure terminal (you can use conf t for short) Router(config)# r1(config)#isdn switch-type ? basic-1tr6 1TR6 switch type for Germany basic-5ess AT&T 5ESS switch type for the U.S. basic-dms100 Northern DMS-100 switch type basic-net3 NET3 switch type for UK and Europe basic-ni1 National ISDN-1 switch type basic-nwnet3 NET3 switch type for Norway basic-nznet3 NET3 switch type for New Zealand basic-ts013 TS013 switch type for Australia ntt NTT switch type for Japan vn2 VN2 switch type for France vn3 VN3 and VN4 switch types for France router(config)#isdn switch-type basic-ni1 router(config)#^Z router# 00:23:38: %SYS-5-CONFIG_I: Configured from console by console Now that we have configured the ISDN switch type, let's check it by using the show isdn status command. If you configured your routers correctly, you should see the following: router#sh isdn stat
The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: DEACTIVATED Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 2. "No shut" the BRI interfaces to make sure that the router is talking to the ISDN switch. router(config)#int bri 0 router(config-if)#no shut router(config-if)#^z 00:23:54: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down 00:23:54: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down 00:23:54: %LINK-3-UPDOWN: Interface BRI0, changed state to up Once we no shut the BRI interface, we should see it come up and check that the router is communicating with the ISDN switch by examining the layer 1 status to make sure it is ACTIVE and checking the layer 2 status to make sure it reads MULTIPLE FRAME ESTABLISHED. Here is what it will look like: router#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 70, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: No Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 Total Allocated ISDN CCBs = 0 We now know that we have correctly defined the ISDN switch type and that our router is talking to the ISDN switch on the D channel. The next step is to configure the SPIDs, if necessary. Remember, not all ISDN switch-types require SPIDs, especially non-US ISDN switches. 3. Configure SPIDs (If Necessary) The example below shows how SPIDs are entered as well as how we can check that they are configured correctly. Note that the SPIDs are configured as an interface command. router(config-if)#isdn spid1 ? WORD spid1 string router(config-if)#isdn spid1 0835866201 ? WORD local directory number <cr> router(config-if)#isdn spid1 0835866201 8358662 router(config-if)#isdn spid2 0835866401 8358664 Before we show an example where the SPIDs have been configured correctly, let's look at what you might see when there is a problem. router#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status:
DEACTIVATED Layer 2 Status: Layer 2 NOT Activated Spid Status: TEI Not Assigned, ces = 1, state = 1(terminal down) spid1 configured, spid1 NOT sent, spid1 NOT valid TEI Not Assigned, ces = 2, state = 1(terminal down) spid2 configured, spid2 NOT sent, spid2 NOT valid Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 Notice that there is a message for each SPID saying that the SPID has not been sent and is not valid. There are a number of ways to fix this problem, but the one I like to use is to bounce the interface by simply shutting down the interface and then no shutting the BRI interface. If you still see the same message (that the SPIDs have not been sent and are not valid), you should check to make sure that you are configuring the correct SPIDs on the correct router. One other thing you can try is to use the clear interface bri 0 command. Now, let's look at an example where the SPIDs have been configured correctly, sent, and are valid. This will not occur unless the router's configuration matches the configuration of the ISDN switch exactly. router#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 76, State = MULTIPLE_FRAME_ESTABLISHED TEI = 77, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: spid1 configured, spid1 sent, spid1 valid spid2 configured, spid2 sent, spid2 valid Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 In the following example, we enable debug isdn q921 and observe the initial communication with the ISDN switch when the interface is no shut. Notice that the packets are being transmitted and received as indicated by RX and TX. router#debug isdn q921 ISDN Q921 packets debugging is on router#conf t router(config)# router(config)#int bri 0 router(config-if)# no shut %LINK-3-UPDOWN: Interface BRI0, changed state to up ISDN BR0: TX -> IDREQ ri = 33114 ai = 127 ISDN BR0: RX <- IDDENY ri = 33114 ai = 127 ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 ISDN BR0: TX -> IDREQ ri = 38651 ai = 127 ISDN BR0: RX <- IDREM ri = 0 ai = 82 ISDN BR0: RX <- IDREM ri = 0 ai = 83 ISDN BR0: TX -> IDREQ ri = 1708 ai = 127 ISDN BR0: RX <- IDASSN ri = 1708 ai = 85 ISDN BR0: TX -> SABMEp sapi = 0 tei = 85 ISDN BR0: RX <- UAf sapi = 0 tei = 85 ISDN BR0: TX -> INFOc sapi = 0 tei = 85 ns = 0 nr = 0
i = 0x08007B3A0A30383335383636323031 ISDN BR0: RX <- INFOc sapi = 0 tei = 85 ns = 0 nr = 1 i = 0x08007B080382E43A ISDN BR0: TX -> RRr sapi = 0 tei = 85 nr = 1 ISDN BR0: TX -> IDREQ ri = 29037 ai = 127 ISDN BR0: RX <- IDASSN ri = 29037 ai = 86 ISDN BR0: TX -> SABMEp sapi = 0 tei = 86 ISDN BR0: RX <- UAf sapi = 0 tei = 86 ISDN BR0: TX -> INFOc sapi = 0 tei = 86 ns = 0 nr = 0 i = 0x08007B3A0A30383335383636343031 ISDN BR0: RX <- INFOc sapi = 0 tei = 86 ns = 0 nr = 1 i = 0x08007B080382E43A ISDN BR0: TX -> RRr sapi = 0 tei = 86 nr = 1 router(config-if)# ^Z router# 4. Use a dialer-list to define interesting traffic. A dialer-list is used to define "interesting traffic" (traffic for which you wish to bring up the ISDN connection). We define a dialer-list in global configuration mode then apply the dialer-list using the interface configuration command dialer-group. When I am configuring ISDN DDR, I like to first define my dialer lists very broadly using IP until I have all features working, such as call setup and teardown, authentication, callback, etc. Once I have basic features working correctly, then I will make the dialer list more selective, if necessary, using an access-list. Here is an example that shows traffic that can be defined as interesting using a broad dialer list: Router(config)#dialer-list 1 protocol ? Appletalk Appletalk Bridge Bridging Clns OSI Connectionless Area Services Clns_es CLNS End System Clns_is CLNS Intermediate System Decnet DECnet Decnet DECnet node Decnet_router-L1 DECnet router L1 Decnet_router-L2 DECnet router L2 Ip IP Ipx Novell IPX Llc2 LLC2 Vines Banyan Vines Xns XNS Using the above syntax, the first dialer list I like to configure is Router(config)#dialer-list 1 protocol ip permit Next, I apply the dialer list to the BRI interface using the dialer-group command: interface bri0 dialer-group 1 A logical question is "How do I troubleshoot a dialer-list problem?" The answer is to use two debug commands together: debug ip packet and debug dialer packet. We can see in the following example that although CDP is not interesting because it is not defined in the dialer-list, IP traffic is interesting because it is defined in the dialer-list: r1#debug ip packet IP packet debugging is on r1#debug dialer packet Dial on demand packets debugging is on 00:25:25: BRI0/0 DDR: cdp, 10 bytes, outgoing uninteresting (no list matched) 00:25:25: BRI0/0 DDR: cdp, 10 bytes, outgoing uninteresting
(no list matched) r1#ping 172.19.1.5 00:25:44: BRI0/0 DDR: ip (s=172.19.1.6, d=255.255.255.255), 52 bytes, outgoing interesting (ip PERMIT) 00:25:44: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 -- failed, not connected 00:25:44: IP: s=172.19.1.6 (local), d=255.255.255.255 (BRI0/0), len 52, encapsulation failed 00:25:195430010384: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to up 00:25:193273528384: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 00:25:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1, changed state to up 00:25:46: BRI0/0 DDR: cdp, 275 bytes, outgoing uninteresting (no list matched) 00:25:46: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 00:25:46: BRI0/0 DDR: cdp, 275 bytes, outgoing uninteresting (no list matched) 00:25:46: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 00:25:46: BRI0/0 DDR: cdp, 275 bytes, outgoing uninteresting (no list matched) 00:25:46: BRI0/0 DDR: sending broadcast to ip 172.19.1.5 00:25:51: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected to 8358662 5. Check our work to date by configuring a dial string. At this point, we need to configure only dial strings on each router to test basic connectivity. Let's examine an ISDN configuration in its most basic form. This is the minimum configuration needed to connect to another router. Each router should have a similar configuration, although the dial strings will be different. router1#show run Version 11.3 Hostname router1 ! isdn switch-type basic-ni1 ! interface bri0 ip address 172.19.1.6 255.255.255.0 dialer string 384000 dialer-group 1 ! dialer-list 1 protocol ip permit router2#show run Version 11.3 Hostname router2 ! isdn switch-type basic-ni1 ! interface bri0 ip address 172.19.1.5 255.255.255.0 dialer string 384020
dialer-group 1 ! dialer-list 1 protocol ip permit We can now check our work by pinging from router1 to router2 and vice versa. router1#ping 172.19.1.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.19.1.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms 6. Configure a Floating Static Route Floating static routes are a very popular way of implementing DDR because they do not keep an ISDN link up constantly as a dynamic routing protocol would. Floating static routes do not keep the link up because they do not generate any traffic on the link. They allow you to control what traffic will bring up the ISDN link in a very selective fashion. However, floating static routes do have drawbacks. One of the key drawbacks is that you must configure them very carefully. Let's look at an example to illustrate this problem. With static routes, there are two possibilities. The first possibility references a destination using a local interface address, e.g., ip route 0.0.0.0 0.0.0.0 bri 0 The second possibility references the next hop IP address: ip route 0.0.0.0 0.0.0.0 172.16.1.5 The difference between the two possibilities comes into play when we talk about redistribution. With the first possibility, the static route will appear as a connected route in the routing table and is automatically redistributed by routing protocols whose network statements include the address of the BRI interface. The second possibility, however, appears in the routing table with an administrative distance of 1, so it must be manually redistributed into dynamic routing protocols. This can cause problems because you may end up keeping the ISDN line up anyway if you use a static route that references an outbound interface as in the first possibility. 7. Encapsulation PPP Notice that until now, we have not been using PPP. In fact, the default encapsulation for a BRI or serial interface is HDLC. This creates a problem because we want to configure PPP CHAP authentication later. In order to do this, we need to change the encapsulation type to PPP using an interface configuration command under the physical BRI interface. We will need to do this on each router. Here is an example: Router1# Router1#conf t Router1(config)# Router1(config)#interface BRI0/0 Router1(config-if)#encapsulation ppp How can we verify that we are configured for PPP encapsulation? Although there are a number of ways, the easiest is to view the running configuration, but an alternative is to use the show interface command as follows: Example 1 - Default HDLC encapsulation ts#sh int bri 0/0 06:21:23: %SYS-5-CONFIG_I: Configured from console by console Bri0/0 is administratively down, line protocol is down Hardware is HD64570 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec) Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=down DSR=down DTR=down RTS=down CTS=down Now we configure PPP encapsulation and observe the difference. Example 2 - PPP encapsulation ts#sh int bri 0/0 06:21:38: %SYS-5-CONFIG_I: Configured from console by console Bri0/0 is administratively down, line protocol is down Hardware is HD64570 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set, keepalive set (10 sec) LCP Closed Closed: CDPCP Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 3 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=down DSR=down DTR=down RTS=down CTS=down 8. Configure Dialer Maps Since the dial string is very limited, we will first remove the dialer string and reconfigure with a more scalable solution instead: dialer maps. Dialer maps are very similar to frame relay maps in configuration and function. Note that dialer maps and dialer strings are mutually exclusive, so you must use one or the other, not both. If you try to configure a dialer map when a dialer string currently exists on the interface, you will see an error message: Router1(config-if)#dialer map ip 172.16.1.5 384000 %cannot change dialer map when dialer string is present What we do first is remove the dialer string as follows: router1(config-if)#no dialer string 384000 Next, we add the dialer map. These two steps need to be performed on both routers. In its simplest form, the dialer map would be configured like the example below, but in live networks, you will rarely see this because most people do configure authentication. The best way to configure the dialer map for authentication will be discussed in the next section of the lab. Router1(config-if)#dialer map ip 172.16.1.5 384000
9. Configure PPP CHAP authentication To configure authentication with ISDN and PPP, we have two options: PAP and CHAP. PAP is rarely used because the password is transmitted in the clear and can easily be seen with a sniffer. For this reason, we will use CHAP instead. The first step in configuring CHAP authentication is to set up local user databases on each router. What we need to do is to enter the username for the opposite router and a common password using a global configuration command. Don't forget that the passwords are case sensitive. For example, on router1, we would enter the following: Router1(config)#username router2 password cisco On router2, we would similarly enter: Router2(config)#username router1 password cisco Once the database has been created, we only have three more commands that must be entered, but this time they are in interface configuration mode. The commands are entered as follows: encapsulation ppp (if we didn't already configure it) ppp authentication chap dialer map protocol next-hop-address name remote_ppp_authentication_name dialer-string The first two commands are self explanatory, but the last will be more obvious if we use an example such as router1's configuration. Router1(config)# interface bri 0 Router1(config-if)#encapsulation ppp Router1(config-if)#ppp authentication chap Router1(config-if)#dialer map ip 172.16.1.5 name router2 384000 Router2 would have a similar configuration. How can we test our configuration? We can simply ping from one router to the other. If we get a successful ping, then everything is working correctly. We can immediately see if we have an authentication problem because we will see the link going up and down repeatedly. We can then troubleshoot the cause of the problem by enabling debug ppp authentication. We will demonstrate this in the next lab with dialer profiles. Now that we have configured basic legacy DDR with dialer maps and authentication, let's look at the final configurations for router1 and router2. If you look at the static routes carefully, you will see that we demonstrated two different methods. The first method uses a default static route to send all non-local traffic to router2. The second method configures specific static routes on router2 for each network on router1. Notice also that the administrative distances have been changed to something other than 0 or 1. SOLUTION REVEALED Router 1's Final Configuration version 12.0 ! hostname router1 ! username router2 password 0 cisco ! ip subnet-zero ! isdn switch-type basic-ni ! interface Ethernet0/0 ip address 10.10.11.1 255.255.255.0 no ip directed-broadcast ! interface Serial0/0 no ip address shutdown ! interface BRI0/0
ip address 172.19.1.6 255.255.255.252 no ip directed-broadcast encapsulation ppp isdn switch-type basic-ni isdn spid1 0835866101 8358661 isdn spid2 0835866301 8358663 dialer map ip 172.16.1.5 name router2 8358660 ppp authentication chap dialer-group 1 ! ip classless ! ip route 0.0.0.0 0.0.0.0 172.16.1.5 2 ! dialer-list 1 protocol ip permit ! line con 0 transport input none line aux 0 line vty 0 4 login ! no scheduler allocate end Router 2's Final Configuration version 12.0 ! hostname router2 ! username router1 password 0 cisco ! ip subnet-zero ! isdn switch-type basic-ni ! interface Ethernet0/0 ip address 10.10.12.1 255.255.255.0 no ip directed-broadcast ! interface Serial0/0 no ip address shutdown ! interface BRI0/0 ip address 172.19.1.5 255.255.255.252 no ip directed-broadcast encapsulation ppp isdn switch-type basic-ni isdn spid1 0835866001 8358660 isdn spid2 0835866201 8358662 dialer map ip 172.16.1.6 name router1 8358661 ppp authentication chap dialer-group 1 !
ip classless ! ip route 172.16.1.4 255.255.255.252 172.16.1.5 100 ip route 10.10.11.1 255.255.255.0 172.16.1.5 100 ! dialer-list 1 protocol ip permit ! line con 0 transport input none line aux 0 line vty 0 4 login ! no scheduler allocate end 5.5 Lab Scenario 2 Introduction This lab is designed to walk you through a basic dialer profile configuration and the special requirements this places on PPP CHAP authentication. This lab will show you what commands to type in and how to check that you have configured things correctly step by step. Some of the steps that were covered in great detail in the first lab scenario will not be covered as thoroughly in this scenario, so refer to the first lab as needed. Network Specifications When you are finished building this network, it should meet the following specifications:
1. Each router should be able to dial the other using dialer profiles. 2. Each dialer interface should use PPP CHAP authentication. You should use the names
CCNA1 and CCNA2 rather than the router host names router1 and router2 respectively. Use the password cisco.
3. You should only be able to see the neighboring router with Cisco Discovery Protocol if the ISDN link is already up.
4. Configure routing using RIP version 2 so that each router can see the other router's Ethernet subnets. Note that this will cause your ISDN connections to come up every 30 seconds to transmit the RIP routing tables. This illustrates one of the problems with dynamic routing protocols such as RIP and IGRP when used with DDR. Fixing this problem using techniques other than static routes is possible, but beyond the scope of the CCNA exam.
The Starting Configurations The equipment that I used in developing this lab included a Cisco 1604 router, and a Cisco 2610 router. The ISDN simulator was a Teltone ISDN Demonstrator with two U interfaces. You will need to adjust the lab contents to fit your ISDN simulator and/or routers as necessary. You MUST use an ISDN simulator or actual ISDN lines. There is no way to configure ISDN using crossover cables or something similar. You can use any router with suitable ISDN interfaces, but be aware of whether you have U interfaces or S/T interfaces. If you have S/T interfaces, then you will need an NT1. Here is the basic starting point for cabling your equipment: (The following information will vary depending upon your ISDN simulator or actual ISDN lines) ISDN Information for Router1: isdn switch-type basic-ni isdn spid1 0835866101 8358661 isdn spid2 0835866301 8358663 ISDN Information for router2: isdn switch-type basic-ni
Figure 1. Configure Global Commands 1. Configure the ISDN switch type on each router Before we begin, perform a write erase on each router to make sure that we are starting from scratch. After you enter the write erase command, reload the router. When you receive a prompt to configure the router, enter ctrl-c and the router will continue to boot up. Once this is complete, check that no configuration exists by entering the write command followed by show configuration. (Note: you can use show configuration instead of show run because you just saved the configuration. This displays the current configuration faster than show run would.) You should not see any configured IP addresses, routing statements, or ISDN configurations of any kind. Enter the IP addresses for the Ethernet interfaces, no shut them, and use the no keep-alive command, if necessary, in case you don't have the Ethernet interfaces plugged into a hub or switch. Since we have no ISDN switch type configured, our first step should be to configure the ISDN switch type. We can use the ? to help us find the correct syntax for our switch type, basic-ni1. We will need to use the isdn switch-type global command on each router as follows: Router1# Router1#configure terminal (you can use conf t for short) Router1(config)# router1(config)#isdn switch-type ? basic-1tr6 1TR6 switch type for Germany basic-5ess AT&T 5ESS switch type for the U.S. basic-dms100 Northern DMS-100 switch type basic-net3 NET3 switch type for UK and Europe basic-ni1 National ISDN-1 switch type basic-nwnet3 NET3 switch type for Norway basic-nznet3 NET3 switch type for New Zealand basic-ts013 TS013 switch type for Australia ntt NTT switch type for Japan vn2 VN2 switch type for France vn3 VN3 and VN4 switch types for France router1(config)#isdn switch-type basic-ni1 router1(config)#^Z router1# 00:23:38: %SYS-5-CONFIG_I: Configured from console by console Now that we have configured the ISDN switch type, let's check it using the show isdn status command. If you configured your routers correctly, you should see the following: Router1#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: DEACTIVATED
Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 The Free Channel Mask: 0x80000003 Total Allocated ISDN CCBs = 0 2. No shut the BRI interfaces No shut the BRI interfaces to make sure that each router is talking to the ISDN switch: Router1(config)#int bri 0 Router1(config-if)#no shut Router1(config-if)#^z 00:23:54: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down 00:23:54: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down 00:23:54: %LINK-3-UPDOWN: Interface BRI0, changed state to up Although we are no shutting the physical interface, we are doing it only to check that the global command for the ISDN switch type is correct. Once we no shut the BRI interface, we should see it come up. Check that the router is communicating with the ISDN switch by examining the layer 1 status to make sure it is ACTIVE and checking the layer 2 status to make sure it reads MULTIPLE FRAME ESTABLISHED. Here is what you will look see: router#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 70, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: No Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 Total Allocated ISDN CCBs = 0 We now know that we have correctly defined the ISDN switch type and that our router is talking to the ISDN switch on the D channel. The next step is to configure the user password database so we can use this information for authentication. 3. Configure the Username Password Database The first step in configuring CHAP authentication is to set up local user databases on each router. What we need to do is to enter the username for the opposite router and a common password using a global configuration command. Since the instructions specified that we should use the usernames CCNA1 and CCNA2 instead of the router hostnames we used in Lab 1, we need to configure the correct usernames. Don't forget that the passwords are case sensitive. For example, on router1, we would enter the following: Router1(config)#username CCNA2 password cisco On router2, we would similarly enter: Router2(config)#username CCNA1 password cisco The next step in our configuration is to define interesting traffic. 4. Define Interesting Traffic Using Dialer Lists A dialer-list is used to define "interesting traffic" (traffic for which you wish to bring up the ISDN connection). We define a dialer-list in global configuration mode then apply the dialer-list using an interface configuration command dialer-group. When I am configuring ISDN DDR, I like to first define my dialer lists very broadly using IP until I have all features working, such as call setup and teardown, authentication, callback, etc. Once I have basic features working correctly, then I will
make the dialer list more selective, if necessary, using an access-list. Here is an example that shows how traffic can be defined as interesting using a broad dialer list: Router1(config)#dialer-list 1 protocol ? Appletalk Appletalk Bridge Bridging Clns OSI Connectionless Area Services Clns_es CLNS End System Clns_is CLNS Intermediate System Decnet DECnet Decnet DECnet node Decnet_router-L1 DECnet router L1 Decnet_router-L2 DECnet router L2 Ip IP Ipx Novell IPX Llc2 LLC2 Vines Banyan Vines Xns XNS Using the above syntax, the first dialer list I like to configure is Router1(config)#dialer-list 1 protocol ip permit We will cover applying the dialer-list later when we cover the dialer interface commands. For now, our next task is to configure our routing protocol, RIP Version 2. 5. Configure the Rip version 2 routing protocol Configuring RIP is very simple, but we need to be aware of the differences between Version 1 and Version 2. Can you remember them off the top of your head? The two major differences are 1) RIP version 1 is classful whereas RIP version 2 is not, and 2) RIP version 2 supports VLSM. Another difference is that RIP version 2 supports route authentication. We will not cover route authentication here, just be aware that it exists and should not be confused with PPP authentication. To configure RIP Version 2, all we have to do is enable the RIP routing process, define the participating networks, and specify version 2. This will be done on each router as follows: Router2(config)#router rip Router2(config)#network 10.0.0.0 Router2(config)#network 172.19.0.0 Router2(config)#version 2 We can check that RIP version 2 is enabled using the show ip protocols command on each router. Now that we have completed the global configuration commands, our next step is to configure the physical BRI interface. For our final step, we will create and configure logical dialer interfaces. Configure Physical Interface Commands 1. Enable encapsulation PPP With dialer profiles, we must specify encapsulation PPP on both the physical BRI interface and the logical dialer interface. Here is an example: Router2(config)#interface bri 0 Router2(config-if)#encapsulation ppp Since we are going to use PPP CHAP authentication, we must configure it, also, on both the physical and the logical interfaces. 2. Specify ppp authentication chap Router2(config)#interface bri 0 Router2(config-if)#ppp authentication chap Although we are going to use dialer profiles, we still need to configure SPIDs under the physical BRI interface.
3. Configure SPIDs (If Necessary) The example below shows how SPIDs are entered as well as how we can check that they are configured correctly. Router2(config-if)#isdn spid1 ? WORD spid1 string Router2(config-if)#isdn spid1 0835866201 ? WORD local directory number <cr> router2(config-if)#isdn spid1 0835866201 8358662 router2(config-if)#isdn spid2 0835866401 8358664 Now, let's look at an example where the SPIDs have been configured correctly, sent, and are valid. This will not occur unless the router's configuration matches the configuration of the ISDN switch exactly. Router2#sh isdn stat The current ISDN Switchtype = basic-ni1 ISDN BRI0 interface Layer 1 Status: ACTIVE Layer 2 Status: TEI = 76, State = MULTIPLE_FRAME_ESTABLISHED TEI = 77, State = MULTIPLE_FRAME_ESTABLISHED Spid Status: spid1 configured, spid1 sent, spid1 valid spid2 configured, spid2 sent, spid2 valid Layer 3 Status: 0 Active Layer 3 Call(s) Activated dsl 0 CCBs = 0 4. Assign the physical BRI interface to a dialer pool Since we are going to configure dialer profiles, our configuration differs at this point from legacy DDR. Because we can create many logical dialer interfaces, but have a fixed number of physical BRI interfaces, we need a method to assign the physical interface to the desired logical dialer interface. The reasons for this become clearer when you think of a situation where you have only two physical BRI interfaces, but need to use four logical dialer interfaces to connect other routers. The first BRI interface may be in use by one of the logical dialer interfaces when we need to place an additional call. By defining both physical BRI interfaces as members of the same dialer pool, the next available physical BRI interface will be dynamically bound to the logical dialer interface at the time of the call. Before we configure the physical BRI interface for dialer profiles, we first need to remove all legacy DDR commands, including dialer map statements, dialer group statements, and network layer addresses. This step should not be necessary for this lab because we write erased the routers at the beginning of the lab. Here is an example of how we assign the physical interface to a dialer pool. A physical interface can be assigned to multiple dialer pools, but a logical dialer interface can only be assigned to a single dialer pool. Router1(config)#interface bri 0 Router1(config-if)#dialer pool-member 1 Now that we have assigned the physical BRI interface to a dialer pool, we have completed the interface commands for the physical BRI interface. The next step is to create a logical dialer interface. Configure Logical Dialer Interface Commands So far, the global and physical BRI interface commands have been relatively simple. The most complicated portion of the overall configuration consists of the creation of the logical dialer
interface and the more extensive commands applied to it. Here is an overview of the remaining steps. First, we need to create the logical dialer interface. Next, we need to associate a dialer pool with the dialer interface using the dialer pool number command, where number is the same number previously used with the dialer pool-member command. Next, we add a dialer-group statement to define interesting traffic and a dialer string to call. Since we want to use alternate CHAP hostnames, we need to configure them using the ppp chap hostname command. Finally, we add a dialer remote-name command to enable creation of a dynamic dialer map to the remote router. We also need to repeat the encapsulation ppp and ppp authentication chap commands we used on the physical BRI interface. 1. Create the logical dialer interface To configure the logical dialer interface, we first need to create a logical dialer interface in the same way we create other logical interfaces such as loopback interfaces. Router1(config)#interface dialer 0 2. Assign an IP address to the dialer interface Router1(config-if)#ip address 172.19.1.6 255.255.255.252 3. Enable PPP Encapsulation Router1(config-if)#encapsulation ppp 4. Configure the Dialer Interface for PPP Authentication CHAP To configure PPP CHAP authentication, we first need to use the same command we used under the physical BRI interface. We then need to use a new command, ppp chap hostname, to specify the hostname we want to use for authentication. This can be totally different from the router's own hostname and is, in our case, CCNA1 or CCNA2. Here is an example: Router1(config-if)#ppp authentication chap Router1(config-if)#ppp chap hostname CCNA1 Next, we need to tell the logical dialer interface what dialer-list to use to define interesting traffic. 5. Apply the dialer-list to define interesting traffic Since we are using dialer profiles, we need to apply the dialer list we created previously to the dialer interface, rather then the physical BRI interface, using the dialer-group command: Router1(config)#interface dialer0 Router1(config-if)#dialer-group 1 6. Specify which dialer-pool to use Next, we need to tell the logical dialer interface which dialer pool to use. Although we can only specify a single dialer pool to use under the logical dialer interface, the dialer pool can contain multiple physical BRI interfaces. Router1(config)#interface dialer 0 Router1(config-if)#dialer pool 1 7. Configure the dialer remote name and string Dialer profiles use dynamic dialer maps, which are created automatically at the time a call is placed, to dial the remote router. We use a combination of a dialer string and dialer remote name to enable the creation of the dynamic dialer maps. Router1(config)#interface dialer0 Router1(config-if)#dialer remote-name router2 Router1(config-if)#dialer string 8358662 8. Check our work At this point, our configuration is complete. We can now check our work by pinging from router1 to router2 and vice versa.
transport input none line aux 0 line vty 0 4 login ! no scheduler allocate end router1#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route Gateway of last resort is not set 10.0.0.0/8 is subnetted, 1 subnets C 10.10.11.1 is directly connected, Ethernet0 R 10.10.12.0/24 [120/2] via 172.19.1.5, 00:02:46, BRI0/0 172.19.0.0/16 is subnetted, 1 subnets C 172.19.1.4 is directly connected, BRI0/0 Router2's Final Configuration version 12.0 ! hostname router2 ! username router1 password 0 cisco ! ip subnet-zero ! isdn switch-type basic-ni ! interface Ethernet0/0 ip address 10.10.12.1 255.255.255.0 no ip directed-broadcast ! interface Serial0/0 no ip address shutdown ! interface BRI0/0 encapsulation ppp isdn switch-type basic-ni isdn spid1 0835866001 8358660 isdn spid2 0835866201 8358662 ppp authentication chap dialer pool-member 1 ! interface dialer 0 ip address 172.19.1.5 255.255.255.252 encapsulation ppp dialer remote-name router1 dialer string 8358660
dialer pool 1 dialer-group 1 ppp authentication chap ppp chap hostname CCNA2 ! ip classless ! router rip version 2 network 10.0.0.0 network 172.19.0.0 ! dialer-list 1 protocol ip permit ! line con 0 transport input none line aux 0 line vty 0 4 login ! no scheduler allocate end Router2#sh ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route Gateway of last resort is not set 10.0.0.0/8 is subnetted, 1 subnets C 10.10.12.1 is directly connected, Ethernet0 R 10.10.11.0/24 [120/2] via 172.19.1.6, 00:02:46, BRI0 172.19.0.0/16 is subnetted, 1 subnets C 172.19.1.4 is directly connected, BRI0 6 LAN Switching As voice, video, and data networks continue to converge, LAN switching will continue to become a valuable asset within scalable network systems. LAN switches offer an inexpensive solution to many of today's internetworking challenges - bandwidth, security, and quality of service. This Study Guide helps you to understand general design issues with respect to Ethernet and Token Ring networks, and to be able to differentiate between LAN segmentation methods. It also examines all topics associated with LAN switching in the CCNA exam. 6.1 Tutorial Introduction Data networking has seen explosive growth in the past few years, with much advancement taking place in the development of LAN switching. As voice, video, and data networks continue to converge, LAN switching will continue to become a valuable asset within scalable network systems. LAN switches offer an inexpensive solution to many of today's internetworking challenges -- bandwidth, security, and quality of service.
This paper looks at LAN switching from the CCNA perspective. We have published a CCIE Tutorial on bridging. The content of that Tutorial overlaps some of the topics in this Tutorial, but the CCIE paper presents the topics at a level beyond the understanding required by a CCNA candidate. It is not the intent of this Tutorial to present a functional guide for network design. However, it is important to understand general design issues with respect to Ethernet and Token Ring networks, and to be able to differentiate between LAN segmentation methods. This Tutorial examines all of the topics in the LAN switching objectives of Cisco's CCNA exam. It is intended to provide familiarity with the objectives -- but should not be considered as the sole source of information for the exam. After reading this Tutorial, you should be able to:
- Describe the advantages of LAN segmentation - Describe LAN segmentation using bridges - Describe LAN segmentation using routers - Describe LAN segmentation using switches - Name and describe two switching methods - Describe full and half-duplex Ethernet operation - Describe Network congestion problems in Ethernet networks - Describe the benefits of network segmentation with bridges - Describe the benefits of network segmentation with switches - Describe the features and benefits of Fast Ethernet - Describe the guidelines and distance limitations of Fast Ethernet - Distinguish between cut-through and store-and-forward LAN switching - Describe the operation of the Spanning Tree Protocol and its benefits - Describe the benefits of virtual LANs - Define and describe the function of MAC addresses
To provide a solid foundation to understanding LAN switching, you need to understand the problems that various technologies are trying to solve. A high-level view begins with the premise that it is desirable that a network not be a single "flat" structure, but rather that it be divided into manageable, scalable pieces. Such pieces often are called segments. Bridges are pure OSI layer 2 devices that segment networks. Routers are pure OSI layer 3 devices that segment networks. LAN switches can also be used to segment a network; however, the definition of a "switch" is less precise; there is no formal standards-body definition. Generally speaking, a layer 2 switch microsegments an existing network, providing separate physical segment connections for each
connected device. LAN switches may provide traffic management functionality such as Virtual LANs (VLANs) for defining controlled broadcast domains, a mechanism to improve or aggregate bandwidth-increasing fault tolerance (such as Cisco's Fast/Gigabit EtherChannel technology) as well as a variety of other features designed to increase network availability and performance. Switching can be defined as the act of receiving an incoming frame on one interface and delivering it out through another interface. A router, by definition, "switches" packets using layer 3 addressing information. The term "switching" with reference to layer 3 routers has been commonplace for many years -- well prior to the creation of the LAN switch. When reviewing documents that speak about routers "switching," you need to understand that what it's likely referring to is not layer 2 or 3 switch switching, but rather routing using traditional layer 3 routers. A LAN switch switches (or forwards) frames using layer 2 addressing information. How does a layer 3 switch differentiate itself from that of a layer 3 router? Layer 3 switches are even more of a vague term, but fundamentally they use layer 3 as well as layer 2 information to decide how to forward traffic. In the real world, layer 3 switches really are routers, but are presented as "switches" to buyers that believe "routers are slow." A layer 3 switch, most commonly, is a router with specialized hardware for some performance-critical functions. Layer 2 switching often will be part of the same chassis. Network Segmentation -- Bridging, Routing, and Switching Early networks were designed using a "shared bandwidth" model -- Ethernet, ARCnet, and Token Ring provided for orderly, controlled access to network medium. The mission of a network was simple -- to move files quickly between systems and enable access to shared network devices such as printers, plotters, or modems. Network traffic required significant bandwidth when communication occurred; however, transmission was infrequent. "Taking turns" proved to be an effective solution. As the numbers of users and services on the network increased, so did the demands for access to network media. Technological advancements in video and voice over data networks increased competition for bandwidth from client/server applications. Network response slowed under the pressure, and end-user productivity decreased. Network segmentation -- dividing a network into smaller, manageable entities to provide a greater ratio of bandwidth to end-nodes is one option available in a network environment. When implemented properly, a network infrastructure should embody the following characteristics: 1. Functional --Does the network empower end-users to complete their objectives, fulfilling the overall business objectives of the organization? 2. Reliable, Available, and Manageable -- Is the network available 7 days a week, 24 hours a day? Is the network able to isolate network faults quickly? Easily? Is recovery transparent to the end-user? 3. Scalable and Adaptable -- Can the network integrate new technologies or accommodate corporate expansion (corporate growth, mergers, etc.) without undergoing significant network redesign? 4. Accessible and Secure -- Does the network provide alternative forms of access such as dial-up and/or dedicated services? Is it capable of maintaining network integrity? Is the authentication process simple for the end user? 5. Efficient and Cost Effective -- Are resources well managed? Is overhead reduced optimally? Does the solution make economic sense to the organization? When a decision is made to segment a network, designers have three primary options: Bridges (OSI model layer 2 devices) provide a means of network segmentation, dividing the collision domain. The network bridge can provide limited security, filtering traffic based on MAC address. Bridges operate independently of higher-layer protocols.
Figure 1. LAN Switches (OSI model layer 2 devices) are an extension of the layer 2 bridge. They combine the functionality of a bridge with the port density of a layer 1 hub. The LAN switch offers the capability of dividing a collision domain, but also can provide a means to segment a broadcast domain with the implementation of Virtual Local Area Networks (VLANs).
Figure 2. Routers (OSI model layer 3 devices) have been the traditional workhorses of the internetwork, dividing not only the collision domain into separate segments, but also providing a means to segment the broadcast domain.
With advances in technology, all network devices have blurred the definitions of where these devices operate in the OSI model -- today's hubs support layer 2 functionality, providing MAC filtering capabilities; LAN switches extend into Layers 3 and 4; and routers are constantly pushing the envelope of what they can do. Segmenting a Network Using Bridges Bridges were once the most popular low-cost alternative for segmenting LANs. Bridges are not complex devices -- they required little knowledge of networking technology to implement within a network. They are, however, more intelligent than pure repeaters. Repeaters extend cable length, but have no role in controlling traffic flow. While the focus of this section is segmenting a network using bridges, it is important to consider their other important function -- the capability to increase the overall diameter and end-node capacity of a network. When an Ethernet network exceeds the capacity of the segment standards set by the IEEE, or when a Token Ring network requires connectivity between more than 260 nodes, a bridge can be used to interconnect collision domains, to create a larger network infrastructure. In theory, bridges could be used to extend the length of the network indefinitely; however, in practice, this is not possible. Bridges do not have the capability to segment broadcast domains. A broadcast created by a single end-device can propagate throughout the entire bridged internetwork. As the number of devices on the internetwork increase, the number of devices broadcasting increases; the bandwidth required to support the transmission of broadcasts increases; and overall network performance decreases. An end device with an interface that has started to fail may chatter endlessly, generating a substantial number of broadcast frames. As bridges do not inherently filter broadcast frames, a bridge will pass these frames to all connected segments creating a broadcast storm on the network. A bridge successfully segments a network, filtering traffic between segments, when the source and destination reside on the same network segment. A well-planned network should see segments maintaining 80% of the network traffic local to the segment, with only 20% of the traffic having to be forwarded by the bridge. Bridges operate at layer 2 of the OSI model and, as such, are able to filter frames based on any layer 2 fields within the frame. Operating at layer 2 of the OSI model means that bridges do not require knowledge of the upper layer protocols encapsulated within the frames they are responsible for forwarding -- a bridge forwards TCP/IP, IPX, or NetBEUI packets indiscriminately. This is in contrast to the operation of layer 3 routers. The default IOS distributed with new Cisco routers only routes TCP/IP. If a Cisco router is configured with a TCP/IP-only IOS, it is unaware of how to route IPX or other layer 3 protocol packets and cannot forward data to connected networks. To forward TCP/IP, IPX, or other layer 3 protocols, the router must support the routing of these protocols. Bridges introduce latency penalties due to overhead processing. The latency delay of a bridge can impact a network with a 10 to 30 percent loss of throughput. If additional filtering based on layer 2 information within data frames has been configured on the bridge, the bridge may reflect a higher latency penalty due to the additional required processing. More modern protocols have been designed to wait a longer time before retransmission when they do not get a response to a broadcast, much as Ethernet backs off its retransmission attempts Note: Broadcast storms are often caused by less-than-ideal host protocol design. One of the early experiences with broadcast storms came with UNIX workstations, which were designed to use a 10-minute ARP timer. When the timer expired, the workstation would broadcast new ARP queries for every address in its ARP cache. Inherently, the timer on all the workstations in the broadcast domain expired simultaneously. This mass of simultaneous broadcasts caused congestion in the network, which in turn caused some ARP requests and responses to be dropped. When the requesting host received no response from an ARP request, the behavior was
to immediately retransmit the request. This process served to create more broadcasts and more congestion, which slowly collapsed the network. . Ethernet networks adopted "transparent bridging," while Token Ring networks implemented "source-route bridging." These two bridging methods differ in operation, and are inherently incompatible in a network. "Translational bridging" provides a means of converting between source-route bridged networks and Ethernet networks. However, it has limitations. A Look at Ethernet and Ethernet Bridging Technology Robert M. Metcalfe and David R. Boggs originally developed Ethernet at the Xerox Palo Alto Research Center in the 1970s. Its simplicity and low cost have helped Ethernet to become the most commonly deployed physical/data-link layer Local Area Network protocol in use today. In 1980, the first formal Ethernet standard was published when DEC, Intel, and Xerox (DIX) joined together to publish a 10 Mbps Ethernet specification that would become known as Ethernet Version 1.0. In 1982, the DIX alliance updated the standard to include additional media types -- the standard now referred to as Ethernet Version 2.0. While the DIX alliance was busy publishing their specifications for Ethernet, in February of 1980, the Institute of Electronic and Electrical Engineers (IEEE) convened a committee to develop Local Area and Metropolitan Area Network standards. In 1983, the IEEE 802 LAN/MAN Standards Committee published a specification for Ethernet -- "IEEE 802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications." The IEEE 802.3 specification has undergone many updates since its initial publication, including support for unshielded twisted pair media, faster transmission speeds, and other enhancements. Today's Ethernet specifications include support for 100 Mbps (Fast) Ethernet that can be run over existing Category 3 or Category 5 twisted pair wiring (Category 5's 100BaseTX specification is the most popular 100 Mbps implementation.). Fast Ethernet provides network administrators with a simple way to increase network bandwidth. Ethernet segments can support the integration of both 10 and 100 Mbps Ethernet stations transmitting on the same network segment. The IEEE 802.3 and DIX Ethernet specifications are quite similar; however, there are some notable differences. For example, the DIX Ethernet standard spans the physical and data-link layers of the OSI model, whereas the IEEE 802 Committee stopped development of 802.3 prior to inclusion of the Data Link Layer -- Logical Link Control. Table 1. OSI Model Differences between DIX Ethernet and IEEE 802.3
The Ethernet data frame organizes data bits into logical units for transmission between computers. DIX Ethernet and IEEE 802.3 share a common frame format; however, there is one notable difference between the two. Table 2. DIX Ethernet Frame Format
Preamble - The preamble is a series of 8 bytes used by the Ethernet receiver for stabilization and synchronization between systems. The preamble consists of 62 bits of alternating 1's and 0's, with the remaining two bits (the Start of Frame delimiter) being two 1's. Preamble Start of Frame Bits (2) | /\ 1010101010101010101010101010101010101010101010101010101010101011 |____________________________________________________________| | 62 alternating 1's and 0's
Destination Address - An Ethernet hardware address is a unique 6 byte (48-bit) identifier pre-assigned to an Ethernet interface by the manufacturer. The hardware address, also referred to as a "physical" or "MAC" address, is expressed as a 12-digit hexadecimal. The first six digits are assigned by the IEEE ("Organizationally Unique Identifier" or "OUI"). The last six are assigned by the manufacturer of the interface. The following is an example of a MAC address. The OUI and hardware manufacturer component are identified: MAC address: 08-00-2E-16-5A-23 Hex: 0 8 - 0 0 - 2 E - 1 6 - 5 A - 2 3 Bits: 0000 1000 0000 0000 0010 1110 0001 0110 0101 1010 0010 0011 |_____________ _____________| |_____________ _____________| | | Organizationally Unique Vendor Assigned Identifier Identifier Note :
The MAC address is used to forward frames within a layer 2 network. The destination MAC address will always be that of a device located within the same layer 3 network. When a frame is to be forwarded to a different layer 3 network, the frame is sent by setting the destination MAC address to be the MAC address of the Ethernet interface of the directly connected router. The layer 3 destination address will be that of the final destination device. This process is discussed further in the section "Segmenting a Network Using Routers."
This process is discussed further in the section "Segmenting a Network Using Routers." The MAC address is used to forward frames within a layer 2 network. The destination MAC address will always be that of a device located within the same layer 3 network. When a frame is to be forwarded to a different layer 3 network, the frame is sent by setting the destination MAC address to be the MAC address of the Ethernet interface of the directly connected router. The layer 3 destination address will be that of the final destination device. This address is to be "globally unique," i.e., no Ethernet interface worldwide should be assigned the same address. The MAC address is commonly referred to as the Layer 2 address. Source Address -- The source address is the 6-byte (48-bit) hardware address of the source interface that generated the Ethernet frame encapsulation. Type or Length -- The DIX Ethernet frame specifies a 2-byte "type" field following the source address specifying the upper-layer encapsulated protocol. For example, the type code for an IP (TCP/IP) packet is 0x800. In the IEEE 802.3 frame, a 2-byte "length" field has replaced the 2-byte "type" field. This field indicates the number of bytes of data contained within the data field of the frame. Data -- Following the 2-byte type or length field is the actual data contained in the frame that will be passed to upper layers for processing. The size of the field is 46 to 1500 bytes. If data in the field is insufficient to fill the minimum 46-byte size, the data field is "padded" to increase its length. CRC (Cyclic Redundancy Check) -- The 4 byte Cyclic Redundancy Check value is calculated by the sending device and appended to the data frame. When the frame is received by the destination system, the Cyclic Redundancy Check is recalculated to ensure the integrity of the frame. Note: IEEE 802.3 and DIX Ethernet frames are able to co-exist on a network. Since the IEEE 802.3 frame specifies the number of bytes of data contained within the data field of the frame, the value will always be equal to or less than 1500. DIX Ethernet protocol numbering begins at a value above 1500 decimal. Carrier Sense Multiple Access with Collision Detection Robert M. Metcalfe's and David R. Boggs' "experimental Ethernet" system operated in a fairly simplistic manner. Each device on the network connected to a shared cable. When a device wished to transmit, it sensed the media to determine if the wire was currently in use. If voltage was detected, another system was transmitting. If no voltage was detected, the device could transmit. Today's Ethernet networks continue to be based on the same media-access method. The problem with Ethernet is that there is the possibility that two or more stations will attempt transmission at roughly the same time. When such an event occurs, the frames are said to have "collided." This is evident by the detection of abnormal voltage levels on the wire. The transmitting stations cease transmission, and attempt retransmission after a randomly chosen period of time has passed. When network utilization is low, stations communicate with few errors and the "contention" for access to the cable is low. As the number of devices connected to the cable increases, or as the requirements of the existing number of connected devices increases, the rate at which collisions occur increases. If a transmitting node experiences a collision of a frame that has been cleared from its buffer (late collision), the transmitting node must use the processing power of the end-station to regenerate and retransmit the frame -- a process left to the upper layers, which results in a highly inefficient system. In an attempt to limit collisions and signal attenuation, Ethernet networks limit the number of devices permitted on a network segment. Network segments, are in turn limited in terms of segment length. Individual network segments can be interconnected, increasing the physical size of the network, but this is not without limitation as well.
The Ethernet "5-4-3" rule governs the interconnection of 10 Mbps network segments within a collision domain using layer 1 (physical) devices. "Between any two communicating Ethernet devices there shall be no more than 5 segments, interconnected by 4 repeaters, 3 segments of which may be populated." A collision domain is defined as an area within which frames that have collided are propagated.
Figure 4. The following table shows the restrictions for Ethernet collision domains based on implemented media. Table 4. Maximum Size of a Collision Domain for 10 Mbps Ethernet
Copper Media Fiber Media
10Base5 (Thick Coax)
10Base2 (Thin Coax)
10BaseT (Twisted Pair)
10BaseFL 10BaseFB 10BaseFP
Cable Type 50 Ohm RG-8
50 Ohm RG-58
Category 3, 4, or 5 (Optical Fiber)
Maximum Segment Length (meters)
500 185 100 from hub to end-node
2000 (500)1
2000 (500)1
500 (300)1
Maximum Number of Devices per Segment
100 30 1,024 on all segments 2 2 33
Maximum Collision Domain (meters)
2500 2500 2500 2500 2500 2500
1 Maximum segment length when using five segments connected by four repeaters Segments operating at 100 Mbps operate under stricter requirements than segments operating at 10 Mbps. The "5-4-3" rule of 10 Mbps Ethernet has been an easily-understood generalization of Ethernet's "512 bit time rule." The 512 bit time rule serves as a guide in 100 Mbps Ethernet networks. The round-trip propagation delay in a collision domain must not exceed 512 bit times, which is a requirement for collision detection to work correctly. The maximum round-trip delay for a 10 Mbps
Ethernet network is 51.2 microseconds, while the maximum round-trip delay for a 100 Mbps Ethernet network is one-tenth the time -- 5.12 microseconds. The maximum size of a collision domain for Fast Ethernet is dependent upon the type of repeater(s) used to connect network segments. The IEEE 802.3u (Fast Ethernet) specification defines two types of repeaters: 1. A Class I repeater has a latency of 0.7 microseconds or less. Only one repeater is permitted within the collision domain. 2. A Class II repeater has a latency of 0.46 microseconds or less. A maximum of two Class II repeaters may be used within the collision domain. The maximum segment length in a Fast Ethernet network is still limited to 100 m. When using a Class I repeater, the maximum diameter of the network is limited to 200 m. When using two Class II repeaters, the repeaters, each directly connected to a 100 m segment, may be interconnected by a segment of 5 m -- thus, limiting the maximum size of a collision domain when using copper media to 205 m.
Figure 5. Alternate topologies may be possible using Fast Ethernet copper media, but the design must ensure that the round-trip propagation delay does not exceed 5.12 microseconds. Table 5. Maximum Size of a Collision Domain for 100 Mbps (Fast) Ethernet Copper Copper and Multimode Fiber Multimode Fiber
One Class I Repeater (meters) 200 260 272
One Class II Repeater (meters) 200 308 320
Two Class II Repeaters (meters) 205 216 228
Transparent Bridging Digital Equipment Corporation developed transparent bridges in the early 1980s. The transparent bridge could be used to interconnect Ethernet LAN segments, providing a simple solution to the limitations of the 5-4-3 rule, or simply, to segment an overloaded Ethernet network. The name "transparent" refers the operation of the bridge. Its operation is transparent to the end devices on the network. End-devices do not need to be configured with any information with respect to the bridge in order for the bridge to operate properly. The main advantage of transparent bridges is their simplicity. A transparent bridge operates in promiscuous mode accepting all frames on all connected segments, regardless of addressing information. The bridge effectively "hears" all frames, and forwards accordingly. This is why end-stations do not have to be configured with information regarding the location or operation of the bridge.
Transparent bridges are "learning" bridges. They learn the location of network devices by creating a forwarding table of the source address of frames received. The bridge associates each end-node MAC address with the bridge port, which helps the bridge to create a map of the network topology. A bridge receives the frame in its entirety before it makes any forwarding or discard decisions. A bridge makes the following forwarding decisions: 1. When a frame on an incoming port has a destination address associated with the same network segment as the source station, the bridge discards the frame. In this case, the bridge can safely assume that the destination has already heard the frame. 2. If the address is known to be associated with a specific port (other than the source port) on the bridge, the frame is forwarded on the port to which the end-node is connected. 3. If the address is not known to be associated with a specific port on the bridge, the frame is forwarded on all ports, except the port from which it was received. 4. If the frame is a broadcast or multicast frame, the frame is forwarded on all ports, except the port on which it was received. When a transparent bridge forwards a frame, it does not change the frame. A bridge receives the frame in its entirety before processing, and retransmits the frame. Layer 2 and layer 3 addressing information remain intact. Transparent bridges divide the collision domain, and, when implemented properly, reduce the amount of network traffic on each connected segment. With fewer end-nodes contending for network bandwidth, end-users should experience improved response times. The extent to which performance will improve is relative to the amount of inter-segment traffic that passes through the
bridge, as well as the amount of broadcast and multicast traffic on the network. Transparent bridges are not able to support multiple active parallel paths through a network. Parallel paths create a physical loop topology in which frames could loop endlessly on the network. The IEEE 802 Committee adopted the Spanning Tree Algorithm created by Radia Perlman, to prevent looped networks when using multiple bridges. The Spanning Tree Algorithm is responsible for determining which bridge ports can create a loop topology and blocks those ports, providing for a single route for data to take through the network. The Spanning Tree Algorithm is a dynamic process. If a bridge or bridge port in the network fails, the remaining devices reconfigure bridge ports, enabling all segments of the network to be accessible again. Transparent bridge tree computation after a topology change can be a slow process, taking up to 30 seconds for the internetwork to converge. When configuring Cisco networks, you will quickly discover that several versions of the Spanning Tree Algorithm have been created. The IEEE 802.1 algorithm is the most common Spanning Tree implementation. Some ancient devices that cannot speak IEEE require the DEC algorithm. There is also a proprietary IBM algorithm used in source route bridging. Note: Radia Perlman, creator of the Spanning Tree Protocol, was featured in the 25th anniversary edition of Data Communications magazine as one of the 25 people whose work has most influenced the industry. Radia's work with algorithms has also been used during the development of the algorithms used in link-state routing. Radia's book, "Interconnections, Second Edition: Bridges, Routers, Switches, and Internetworking Protocols," is an excellent information source about the Spanning Tree Algorithm, as well as other data networking topic. It is highly recommended
Radia Perlman, creator of the Spanning Tree Protocol, was featured in the 25th anniversary edition of Data Communications magazine as one of the 25 people whose work has most influenced the industry. Radia's work with algorithms has also been used during the development of the algorithms used in link-state routing. Radia's book, "Interconnections, Second Edition: Bridges, Routers, Switches, and Internetworking Protocols," is an excellent information source about the Spanning Tree Algorithm, as well as other data networking topic. It is highly recommended.
Figure 6. For the Spanning Tree Algorithm to operate correctly, all bridges on the network must support the protocol. A Look at Token Ring and Token Ring Bridging Technology In the early 1980s, the IEEE 802 Committee, which was responsible for the development of LAN and WAN standards, focused solely on the development of a standard centered on the CSMA/CD media access method. Near the end of 1980, it added a token-access method to its focus. By 1981, it had established committees to look at three media access control protocols: CSMA/CD (802.3), Token Bus (802.4), and Token Ring (802.5). Token Ring's installed base has continued to steadily decrease over the past few years. With the emergence of high-speed inexpensive technologies such as Gigabit Ethernet, it's likely this trend will continue. Note: The March 2000 Token Ring CCIE Tutorial by Richard Gosney provides an in-depth look at Token Ring. Therefore, this Switching paper will limit its coverage of Token Ring to concepts required to understand Token Ring LAN switching Unlike Ethernet's contention-based media access method in which nodes compete for transmission access without guarantee of access, Token Ring's transmission is deterministic: the maximum time that will pass before a station is able to transmit can be calculated. Token-passing networks have several benefits when compared to contention-based systems. Token-passing networks do not suffer as dramatically from network loading, and thus are more suitable for heavily populated networks. Nodes may be assigned individual priorities for media access, providing more efficient network access for time-sensitive or low-priority applications. Token Ring networks rely on the passing of a small 24-bit frame called a "token" to provide dedicated access to network media. This frame continuously circulates around the ring until it reaches a station that wants to transmit data.
IEEE 802.5 Token Frame
Start Delimiter Access Control End Delimiter
1 byte 1 byte 1 byte
When a node wishes to transmit, it waits to receive the token from its upstream neighbor. The token's bit pattern is changed, altering the frame from a token to a start-of-frame sequence. The transmitting node inserts its data, adds destination and source address information, and appends a four-byte frame-check sequence. The frame is released to the network media for circulation.
The source node retains a copy of the information sent, for error-control purposes. IEEE 802.5 Data Frame
Start Delimiter
Access Control
Frame Control
Dest. Address
Source Address Data FCS End
Delimiter Frame Status
1 byte 1 byte 1 byte 6 bytes 6 bytes >=0 bytes
4 bytes 1 byte 1 byte
Each Token Ring node connects to the ring via an active, signal-regenerating circuit that takes the incoming data from the upstream device and forwards it to the node downstream of it. Token Ring devices are connected together in a logical ring. The data always travels in the same direction around the ring. As the data frame circles the ring, each node receives the frame and checks the destination address of the frame to determine if it matches the device's own address. If a match occurs, the node copies the frame into its buffer memory and updates the frame status field. The frame status field contains two series of bits: the Address Recognized Indicator (ARI) and the Frame Copied Indicator (FCI). The ARI and FCI provide a means for the originator to identify whether the address has been recognized, and whether the data contained within the frame has been copied into the buffer of the recipient. The source node eventually receives the frame again from its upstream neighbor as it completes the circle of the Token Ring network. The source node compares its copy of the sent information with what it received on the network. It determines if the source received the frame and/or copied the information to its buffer. The source node removes the frame from the ring and regenerates a new token. Token Ring networks most commonly operate at either 4 Mbps or 16 Mbps. Unlike Ethernet, Token Ring does not offer compatibility between data rates, enabling both speeds to co-exist on the same ring. One reason why Token Ring has lost ground in the LAN protocol market is the need to upgrade all equipment when moving to faster bandwidth rings. While the 4 Mbps Token Ring network allows only one token or frame to be on the ring at any one time, 16 Mbps Token Ring's early token release allows one or more frames to be on the ring at the same time as the token. An end-node can generate a new token immediately after it has transmitted its frame rather than waiting for the frame to completely circulate the ring. Although its name implies a ring, Token Ring's topology is actually that of a physical star (logical ring). Token Ring end nodes are attached to the network via a central point called a Multistation Access Unit (MAU). The MAU functions much like a hub does in an Ethernet network. Up to 260 end-nodes can be attached to a single ring. Rings can be interconnected using bridges, LAN switches, or routers. Source-Route Bridging IBM developed source-route bridging as a means of interconnecting Token Ring segments (rings). A source-route bridge appears to other Token Ring stations as a station on the ring. The source-route bridge is responsible for forwarding frames destined for remote rings. "Source-Route Bridging" got its name from the way the bridging method operates. All sent data frames carry the complete source-to-destination routing information within a Routing Information Field (RIF). When an end-station wishes to communicate with another end-station whose destination is unknown, the source sends a local-ring test frame. If the frame returns to the sender with the indication that the frame has been received, the sender recognizes that the destination is local -- no routing information is required. When the end-station communicates with another end-station located on the same ring as the source, the first bit of the source address (the Routing Information Indicator or RII) is set to 0, indicating no RIF is present. Frames without a RIF are not forwarded. When an end-station is located on a remote network, the Routing Information Indicator bit is set to 1, indicating a RIF exists within the frame.
When an end-station that has sent a test frame onto the network receives the test frame back without indication that the end-source has seen the frame, the source assumes the destination is on a remote segment. The sending end-station then sends a route-discovery (all-routes explorer or "ARE") frame, which circles the ring. Each bridge that receives the route-discovery frame distributes the frame to all outbound ports. As the route-explorer frame passes through a bridge, the bridge adds the local ring number and bridge number into the RIF field of the frame. The RIF field contains a 2-byte Routing Control field that defines the RIF as a "specifically routed" frame, an "All Routes Explorer" frame, or a "Spanning Tree Explorer" frame. Following the 2-byte Routing Control field, the IEEE specification provides for up to 14 Route Descriptor fields. This limit on the number of routing descriptor fields limits the maximum number of hops in an IEEE 802.5 network to 13. The Route Descriptor field consists of a 12-bit Ring Number, followed by a 4-bit Bridge Number. Ring numbers must be unique within a bridged network. Bridge numbers must be unique within the local ring to which they are attached.
The first bridge the All Routes Explorer frame encounters adds the local ring number to the frame. The destination device replies to all frames received, returning the contents of the RIF to the original sender. The sender evaluates routing information in the responses and selects the best as the pathway for further communication.
Figure 7. Source-route bridging has never gained the popularity of its rival, transparent bridging. The source-route bridging standard has serious drawbacks. A source-route bridged network can quickly increase in complexity when network rings are interconnected in a mesh topology. Each source route bridge creates a copy of the All Routes Explorer packet for each bridge interface. The number of copies of All Route Explorer packets can increase dramatically, impacting network performance. Unlike transparent bridges, source-route bridges require a significant amount of configuration and are seriously limited in terms of scalability. Most importantly, however, the majority of source-route bridge products are designed in accordance with IBM's source-route bridge standards, and do not adhere to the IEEE 802.5 specification. The IBM source-route bridge standard sets the size of the RIF field to 18 bytes, limiting the Token Ring RIF to a maximum of 8 Route Designator fields (7 hops). Mixed-Media Bridging Today there are many networks that are not homogenous in nature. They often employ a mix of technologies such as Ethernet, Token Ring, FDDI, and perhaps ATM. The challenge for any network administrator is to successfully integrate these technologies into a manageable entity. As discussed earlier, source-route bridges forward frames based on the presence of the RIF field (as identified by a value of 1 in the RII). Frames without a RIF are assumed by the bridge to be local to the ring and are not forwarded. Since Ethernet frames do not carry a RIF field, a source-route bridge cannot forward Ethernet frames. This presents a challenge for the network administrator who must enable communication between Ethernet and Token-Ring clients. Source-Route Transparent Bridging To interconnect Ethernet and Token Ring networks, IBM proposed a new bridge standard to the IEEE 802 committee known as source-route transparent (SRT) bridging. Unlike source-route bridges, the source-route transparent bridge is able to run the IEEE spanning tree algorithm thus providing forwarding of Ethernet frames. The Source-Route Transparent Bridge is also capable of forwarding Token Ring frames based on RIF information. Thus, the Source-Route Transparent Bridge is capable of integrating Ethernet and Token Ring networks. Although source-route transparent bridging permits the coexistence of two incompatible bridging technologies, the source-route transparent bridge does not convert between Ethernet frames and Token Ring frame formats; the source-route transparent bridge only serves to forward packets through the hybrid network.
Source-Route Transparent Translational Bridging Source-Route Transparent Translational Bridging differs from Source-Route Transparent bridging in that a source-route transparent translational bridge will physically convert the data frame to the frame format on the destination media. For example, should a frame be forwarded from a Token Ring network to an Ethernet network, the source-route transparent translational bridge will remove the RIF field from the frame. Since Ethernet does not have corresponding functionality for many Token Ring's features, token/reservation/monitor bits will be dropped, and priority information will be discarded. The source-routed network sees the Ethernet network as a virtual Token Ring network. When a source-routed frame needs to be sent to the Ethernet network, it includes the virtual Token Ring network ring number in its RIF. While a bridge can physically connect dissimilar media (i.e. 10Base2 and 10BaseT) and may include functionality to connect dissimilar layer 2 protocols (commonly Ethernet and Token Ring, or Ethernet and FDDI), bridging between different layer 2 media is not recommended. When Ethernet transmits a MAC address, it transmits the low order bit (little endian) first. Token Ring and FDDI on the other hand, transmit the high order bit first (big endian). While the translational bridge is capable of bit-swapping the data-link layer MAC addresses, higher-level protocols such as IPX commonly use the MAC address as the node portion of the network address. Bridges are not able to bit-swap MAC address information contained within the data field of a frame. The translational bridge would be able to correctly bit-swap the Ethernet MAC address: Ethernet MAC address: 08-00-2E-16-5A-23 Hex: 0 8 - 0 0 - 2 E - 1 6 - 5 A - 2 3 Bits: 0000 1000 0000 0000 0010 1110 0001 0110 0101 1010 0010 0011 However, when a MAC address is used within the data frame as part of the layer 3 network/node address, the MAC address would be displayed as: Bits: 0001 0000 0000 0000 0111 0100 0110 1000 0101 1010 1100 0100 Hex: 1 0 - 0 0 - 7 4 - 6 8 - 5 A - C 4 Non-bit-swapped Ethernet MAC address: 10-00-74-68-5A-C4 The issue of bit swapping also affects TCP/IP. ARP replies contain MAC address information within the data portion of an Ethernet or Token Ring frame. As general rule of thumb, only non-routable protocols can be successfully translationally bridged. Translational bridges also face the issue of incompatible Maximum Transfer Unit (MTU) frame sizes. Ethernet's MTU is commonly set to 1500 bytes, whereas a Token Ring frame may be up to 17,800 bytes. Translational bridges are not able to fragment frames; any frame that is incompatible with the recipient segment's MTU is just dropped. There is currently no standard for translational bridging; each vendor creates its own proprietary version. Most, but not all, interoperate. The lesson is, if at all possible, route, rather than use translational bridging. When considering implementation of a source-route transparent translational bridged network, keep in mind that there is a higher latency penalty due to the processing involved within the bridge. Segmenting a Network Using Routers Routers are network layer 3 intermediate system devices, and as such, are able to interconnect and translate between network layer protocols, such as IP, IPX, etc. Routers, like bridges, are used to connect network segments, extending the maximum length or node-capacity of a network.
Routers are more processing-intensive than bridges. Generally router processing speeds (the rate at which packets are forwarded per second) are not as high. The latency delay of a router can impact a network throughput with loss from 20 to 40 percent. The process of forwarding (routing) packets between networks is not transparent, as was the case with transparent bridging. Each end-station must be made aware of the presence of the router (generally a client is configured with a gateway address -- the address of the router). Packets destined for end-stations not local to the network must be passed to the router, which will base its forwarding decision on network layer address information and routing information contained within its routing tables. Let's examine the process of routing, noting the level of complexity required for forwarding a packet from one network to another. In this example, IP is the network layer protocol.
Figure 8. 1. Client X is located on network 1.0.0.0 and is configured with an IP address of 1.0.0.100. 2. Client Y is located on network 2.0.0.0 and is configured with an IP address of 2.0.0.200. 3. Router A is located between Client X and Client Y and is responsible for routing packets between networks 1 and 2. 4. Client X is configured with a gateway address, the IP address of the router. For this example, we will use the IP addresses 1.0.0.1 and 2.0.0.1 as the addresses of the router's interfaces. 5. The client's TCP/IP protocol information specifies a subnet mask of 255.0.0.0. By applying the mask to its own address, it recognizes that client Y is located on another network. 6. When building the IP packet to send to Client Y, Client X adds the IP address 2.0.0.200 to the IP destination address field. 7. Client X adds its IP address 1.0.0.100 to the IP source address field. 8. Client X must now determine the Ethernet addressing information. The responsibility of layer 2 of the OSI model is to move data along a network segment. Client Y is not located on the same segment as Client X. Client X selects the router's layer 2 MAC address as the destination address within the frame. If the router's MAC address does not exist within Client X's ARP cache, Client X will broadcast an ARP request, looking for the MAC address that belongs to IP address 1.0.0.1. The router's MAC address is DD-DD-DD-DD-DD-DD. 9. Client X adds its own layer 2 MAC address to the frame in the source field. Client X's MAC address is AA-AA-AA-AA-AA-AA. 10. The frame is now ready to be sent to the router for processing.
11. The router receives the frame, strips off the framing information, and is left with the contents of the IP packet. 12. The router processes the IP packet according to its filter rules, and prepares to send the packet to Client Y. 13. The router does not change the IP address information within the IP packet. The source address is still Client X; the destination is still Client Y. 14. The router creates an Ethernet frame containing the layer 2 MAC address of Client Y. Client Y's MAC address is BB-BB-BB-BB-BB-BB. 15. The router adds its own layer 2 MAC address as the source address. The router adds the MAC address EE-EE-EE-EE-EE-EE to the source field. 16. The frame is now ready to be sent to the client. While the process of forwarding packets is far more complex than forwarding frames using bridges, the benefits gained from network-address forwarding and packet filtering make routers a better alternative in an internetwork. Additionally, the capability of a router to divide not only the collision domain, but also the broadcast domain can significantly improve performance on an overloaded network. Routers provide network administrators with greater control over path selection, and network topologies can support multiple paths. Many network routing protocols support load balancing over multiple connections. Routers are able to provide translational services converting between Ethernet, Token Ring, and FDDI networks. Remember that bridges cannot. Segmenting a Network Using LAN Switches LAN switches have replaced bridges in the marketplace as the preferred layer 2 segmentation option and have gained in popularity, replacing layer 1 Ethernet hubs and Token Ring MAUs, in shared media environments. LAN switching offers network administrators a simple way to increase bandwidth availability to end users, providing dedicated bandwidth on each switch port. Today's LAN switches offer the functionality of their predecessor, but have incorporated new features, which make LAN switches truly powerful network tools. The beginning of this Tutorial introduced five characteristics of a well-designed infrastructure: 1. Functional 2. Reliable, Available, and Manageable 3. Scalable and Adaptable 4. Accessible and Secure 5. Efficient and Cost Effective The selective deployment of LAN switches within a network can help a network administrator design a network that embodies each of these characteristics. With an intelligent network fabric, LAN switches can provide for a multitude of alternate pathways, backing up each switch path within an internetwork, and at a cost well below that of conventional routers that have traditionally been used to provide redundancy. LAN switches can be part of the network infrastructure that provides sufficient bandwidth for end-users, is capable of automatic recovery from failure with little or no impact on end-users, is scalable and adaptable, and cost-effective yet secure. The transition from shared-media networks such as Ethernet or Token Ring to dedicated-media switched networks can be compared to the transition experienced by telephone companies when party lines (shared telephone networks) were replaced by dedicated subscriber access. Although now generally obsolete, early telephone networks often utilized "party lines" to provide access to the public telephone system. Like shared media networks, a party line was shared by several subscribers and could be used by only one person at a time; other subscribers had to wait until the line was available. The party line lacked privacy -- an intrusive neighbor could listen in on a conversation simply by picking up any handset connected to the party line. Shared media Ethernet and Token Ring share the same susceptibility of uninvited intrusion of network information by network neighbors.
Figure 9. The dedicated-service telephone system used by most of us today provides dedicated, on-demand access to the telephony network, and offers a degree of protection from unwanted intrusion. LAN switches provide a similar type of dedicated communication, within a local area network environment. Each port on a LAN switch provides a dedicated connection, or collision domain. The switch can be used as a collapsed backbone -- interconnecting hubs or repeaters -- or can be used to provide dedicated connection to end-nodes. Ethernet Switching An Ethernet switch is essentially a multi-port transparent bridge that incorporates all of the functionality of a traditional transparent bridge, but brings forth new, innovative enhancements to create a powerful networking tool. Today's Ethernet LAN switches typically operate at speeds of 10 and 100 Mbps. However, switch vendors have started offering Gigabit (1,000 Mbps) Ethernet uplink capability in their switch products. Some switches offer port configurations that support either 10 or 100 Mbps operation. Each port can operate at 10 or 100 Mbps, with the selected data rate operating independently of the data rate of its neighboring ports (asymmetric switching). These switches are capable of converting between 10 and 100 Mbps data rates, providing connectivity between different bandwidth segments. One of the most attractive features with respect to adding LAN switches to an existing Ethernet network infrastructure, is that deployment does not require changing cabling, network interface cards, re-configuring routers, etc. Autonegotiation When a switch has a port capable of operating at either 10 or 100 Mbps, typically the port will support autonegotiation, i.e., the port will be able to determine the type of Ethernet signal of the end-system and will select the appropriate Ethernet implementation. When a network interface card has been configured for 10Base-T operation, it will send a single pulse, called a Normal Link Pulse (NLP) to the switch port, testing the integrity of the link. If the link is operational, the indicator light on the NIC (if present) will light. If a switch receives an NLP, it recognizes that the end-station is only capable of 10 Mbps operation. If this process does not identify the Ethernet implementation, the switch port can transmit a Fast Link Pulse (or FLP)
identifying the highest performance Ethernet implementation it has available. The FLP consists of a series of up to 33 pulses (17 clocking pulses interspersed with up to 16 signal pulses) that forms a 16-bit code word. The end-station also transmits an FLP identifying its maximum capability. The two end-points compare 16-bit code words, determining the highest compatible speed. The IEEE has established a priority system ranking from the most desirable mode of Ethernet operation to least desirable. It is: - 100BASE-TX full duplex - 100BASE-T4 - 100BASE-TX - 10BASE-T full duplex - 10BASE-T Switching Mechanisms Like bridges, the operation of a LAN switch is transparent to the end-user. LAN switches operate like transparent bridges. The switch creates a forwarding table of the source addresses of frames received. The switch associates each end-node MAC address with the switch port on which the source MAC address was identified, creating a map of the network topology. However, unlike a bridge, the LAN switch does not need to receive the frame in its entirety before it makes the decision to forward. Store-and-Forward Switching Store-and-forward switching is the traditional frame forwarding method used by bridges. When using store-and-forward switching, the switch receives the entire frame before the frame is forwarded. The switch reads the destination and source addresses, and computes a cyclic redundancy check value on the frame received to determine the integrity of the frame. If the CRC value is bad, the frame is discarded. Otherwise, the switch applies all relevant filters then switches according to the information contained in its addressing table. Latency for store-and-forward switching is dependent on the frame size, i.e., the time it takes to receive a 64 byte frame is different from the time it takes to receive a 1518 byte frame. Latency values for store-and-forward switching can be calculated using the data rate of the port: • For a 10 Mbps port, latency can be between 51.2 microseconds to receive a minimum-length Ethernet frame (64 bytes) and 1.21 milliseconds for a full-length Ethernet frame (1518 bytes). • For a 100 Mbps port, latency can be between 5.12 microseconds to receive a minimum-length Ethernet frame (64 bytes) and 121 microseconds for a full-length Ethernet frame (1518 bytes). Latency values must also take into consideration the latency of the switching process itself. A Cisco Catalyst 1900 series switch requires from 3 to 7 microseconds to switch a frame between ports when using store-and-forward. Cut-Through Switching The technique of cut-through switching was originally pioneered by Kalpana and was implemented on Kalpana switches. In December 1994, Cisco acquired Kalpana and Kalpana's cut-through functionality. Cut-through switching improves throughput performance by beginning to forward frames before the entire frame has been received. Since the port does not wait to receive the CRC at the end of the frame, it cannot determine the integrity of the data received. Switches operating in cut-through mode can propagate invalid frames through a network. Cut-through switches can perform a CRC check as the frame passes through the switch, keeping track of the number of bad frames the port receives. Some switches support the capability for a port to automatically switch from cut-through packet switching to store-and-forward switching if error rates exceed a user-defined threshold. When the error rate falls below the user-defined value, switching reverts back to cut-through switching. FastForward cut-through switching begins forwarding a frame as soon as the destination address is read and determined to be a valid address. FragmentFree cut-through switching waits until the first 64 bytes of the frame have been received. Most collisions occur within the first 64 bytes of
the frame. FragmentFree switching attempts to reduce the number of collision frames (and runt frames -- illegal frames less than 64 bytes in length) it propagates through a network. Note:FragmentFree is the default switching mode on the Catalyst 1900 series switch Latency for cut-through switching is relatively simple to calculate: • For FastForward switching, a port receives 14 bytes before it begins forwarding the frame. For a 10 Mbps port, latency is 11.2 microseconds. For a 100 Mbps port, latency is one-tenth the time or 1.12 microseconds. • For FragmentFree switching, a port receives 64 bytes before it begins forwarding the frame. For a 10 Mbps port, latency is 51.2 microseconds. For a 100 Mbps port, latency is one-tenth the time or 5.12 microseconds. The latency period of the switching process when cut-through switching is used can be quite a bit higher than the latency of the switching process for store-and-forward switching. For example, a Cisco Catalyst 1900 series switch requires 70 microseconds to switch a frame between 10 Mbps ports. A major constraint of cut-through switching, is that it does not support 10 Mbps to 100 Mbps port switching. A 10 Mbps Ethernet switch cannot utilize cut-through switching on 100 Mbps or FDDI uplink ports, nor cut-through switch with a peer port operating at 100 Mbps. Not all switches, and not all Cisco switches, support cut-through switching. This mode of switching is seen primarily on edge rather than core switches. Half-Duplex and Full-Duplex Ethernet Ethernet's original design was based around a single media -- thick coaxial cable. Unlike today's twisted pair media, separate transmit and receive circuits did not exist. A single pathway existed to carry data; access to the media had to be controlled to prevent more than one node from transmitting at the same time. Ethernet was designed as a half-duplex technology. Half-duplex transmission provides for transmission of a signal in either direction, but only one direction at a time. Half-duplex operation is similar to radio operation between a pilot and a control tower. When a pilot wishes to speak, he presses the transmitter on his microphone, and addresses the control tower. When the control tower responds to the pilot, the air traffic controller depresses his transmitter on his microphone, and addresses the pilot. When the two attempt to transmit at the same time, neither side receives the transmission. All that is heard, is a loud tone indicating the transmissions have collided. An Ethernet controller must, however, be able to listen to the data channel while it is transmitting -- in much the same manner that the pilot and air traffic controller must continue to monitor their surroundings to detect the tone signaling that both are attempting to speak at once When the Ethernet specifications were updated to include support for twisted-pair and fiber-optic media, separate circuits for sending and receiving data existed, but network devices (or end-nodes) were still connected together via repeaters or hubs, in a logical bus topology. When a collision occurred, it was still propagated along the entire length of the bus. When a network is segmented, i.e., when a collision domain is split into two or more collision domains using a layer 2 device, the logical bus topology is segmented. When a layer 2 bridge or switch is added to the network, each port divides the collision domain into separate segments. Should a switch be used between two end nodes, each node exists in its own collision domain. No other device is in contention for the media. In such a configuration, where an end-node is the only device in a collision domain, it is possible for the device to transmit and receive simultaneously. The ability to transmit and receive simultaneously is known as full-duplex operation. Note:
An Ethernet controller can only detect collisions while it is in transmit mode. After the transmission of a data frame, an Ethernet controller must wait a minimum of 9.6 microseconds before attempting to transmit a second frame. The 9.6 microsecond interframe gap serves a two-fold process: 1) to provide an opportunity for another device to transmit its data; 2) to ensure the Ethernet controller remains in transmit mode long enough for a collision to propagate back to it from the farthest point on the wire. Full-duplex increases Ethernet's throughput by creating two collision-free 10 Mbps paths or two collision-free 100 Mbps paths -- one for sending and one for receiving. The collision detection on the Ethernet interface is not required, and is thus disabled. There are a few important points that must be remembered with respect to the operation of full-duplex Ethernet: 1. Full-duplex Ethernet is a point-to-point, dedicated link between switches, or end-nodes. Hubs or repeaters are shared media devices, and are not capable of supporting full-duplex Ethernet. 2. Although two 10 Mbps or two 100 Mbps pathways may exist, end-systems typically are either client systems (receive more data than is sent) or are server systems (send more than they receive). As the balance of transmissions to/from end-systems are generally not equal, devices often are not able to benefit from the full 20 Mbps/200 Mbps available bandwidth. 3. The Ethernet controllers of each end-device must be capable of supporting full-duplex operation. Not all Ethernet network cards in use today have drivers that support this functionality. While full-duplex transmission is a simple way of increasing network bandwidth, it can readily create network congestion problems when switches are deployed without regard for the bandwidth requirements for any given port on a switch – Note: Fast EtherChannel is a technology that supports the "bundling" of Fast Ethernet connections, grouped together to increase bandwidth up to 400% (up to 800 Mbps). especially the uplink ports that provide dedicated bandwidth to servers. Consider the case of the 24 port, 10 Mbps Ethernet switch with a 100 Mbps Ethernet uplink port. Each port provides dedicated 10 Mbps access to 24 end-stations. The theoretical aggregate bandwidth of the 24 10 Mbps ports is 240 Mbps. If each port is operating in full-duplex mode, the theoretical aggregate bandwidth increases to 480 Mbps. The uplink to the server is only capable of 100 Mbps -- 200 Mbps when operating in full-duplex mode. It is very important to monitor bandwidth usage on ports to ensure that actual aggregate bandwidth does not exceed the bandwidth of the uplink or any port where throughput requirements may exceed available bandwidth. When congestion does occur, LAN switches have several techniques that can be used to control or minimize congestion. Note that not all congestion control features are available on all switches. Token Ring Switching Token Ring LAN switches offers the same performance benefits as Ethernet switches: improved network throughput through microsegmentation, dedicated media access, and low latency for inter-segment communication. They also offer robustness in that transparent bridging, source-route bridging, and source-route transparent bridging standards are supported. Additionally, like the Source-Route bridge, the Token Ring switch is capable of supporting multiple redundant paths through the network fabric. Deployment of Token Ring switches, however, has lagged significantly behind the deployment of Ethernet switches in the network fabric. While Ethernet's demand for inexpensive segmentation options to control collisions has fuelled their demand, Token Ring switches have generally lacked a "killer application" -- something that would make them indispensable for every Token Ring network. Token Ring's ability to prioritize data has helped Token Ring networks keep up with the demand for bandwidth better than Ethernet networks, but as today's networks continue to
implement real-time protocols for voice and video, Token Ring switch deployment will help maintain the quality of service required of these protocols. There are two options for deploying a Token Ring LAN switch within an existing Token Ring network infrastructure: 1) the LAN switch can directly connect end-stations to its switch ports (sometimes referred to as port switching) or 2) the switch can be connected to a port on a MAU, acting as a multi-port bridge joining an existing ring (sometimes referred to as segment switching). When port switching is implemented, all ports on the Token Ring LAN switch have the same ring number. When the switch examines a RIF field of a Token Ring frame, the switch never modifies the RIF field of the frame so the ring number outbound frame will always be the same as the inbound frame.
Figure 10. A Token Ring LAN switch learns only the MAC addresses of all stations connected to its ports. The switch also checks the Route Descriptor field for information concerning the next hop ring and bridge number. When a Token Ring switch receives a frame that contains a RIF, it switches the frame based on the RIF information. If a frame does not contain a RIF field, it is transparently bridged according to MAC address information. If the MAC address does not exist within the switch's directly-connected MAC address table, the frame is forwarded to the next hop. Virtual LANs The evolution of the LAN switch from traditional bridge to a full-featured layer 2 device has brought forth significant advances in the capabilities and functionality of network segmentation. While the traditional LAN switch divides the collision domain, the implementation of Virtual Local Area Networks, or VLANs further divide the network, providing for logical segmentation of the broadcast domain. VLANs provide a flexible, scalable network solution.
VLANs enable a network administrator to create groups of users or end-system devices based on user-defined criteria such as department, project teams, or software application, without regard to their physical location. The logical grouping capability of VLANs provides for a simulated local network infrastructure containing the broadcast domain. Broadcasts are not passed to devices outside of the VLAN grouping.
Figure 11. Implementing a VLAN requires a VLAN-capable switch. Not all LAN switches provide this functionality. Each port on the LAN switch can be assigned a VLAN identification number, analogous to a layer 3 IP network. End-devices or existing hubs can be connected to the VLAN ports, enabling the existing infrastructure to become part of the VLAN architecture.
Figure 12. Moving an end-station requires a simple reconfiguration of the switch port, a process that may be accomplished manually or dynamically, depending on the implementation method selected by the network administrator. This process requires no re-wiring of existing infrastructure, or reconfiguration of the network router, which greatly simplifies the relocation process. Limiting the
broadcast traffic to specified groups helps to reduce the overall number of broadcasts received by each end-station on the network. Summary Proper network design is the most important aspect of any network infrastructure. Today's network administrator has a wide variety of options available to improve network performance. We have looked at creating more bandwidth per user through segmentation of the network, and touched on features within LAN switching that can be used to improve performance. Each segmentation method has its strengths and its weaknesses. Choosing when to implement a specific solution is often dependent on how much the organization can afford. The challenge for a network administrator is to strike the right balance between network performance and budget. 6.2 Lab Abstract 1 Integrating Network Infrastructures - The presented situation is that the organization you work for has recently merged with another organization. A team has begun integrating existing systems with a goal of creating a seamless, transparent network infrastructure. You need to: 1. Create a logical network diagram outlining your addressing scheme. 2. Create configurations for three Cisco 1600 series routers. 3. Document any needed changes (using Cisco IOS commands) for the routers. 4. Identify the process by which client workstations from two cities will connect to the network. 6.3 Lab Scenario Issue The organization you work for has recently merged with another organization. A team has begun integrating existing systems with a goal of creating a seamless, transparent network infrastructure. The head office of the new organization is located in Fort Worth, Texas. Your Chief Information Officer has concerns about application security, and has decided that Fort Worth will be the only location hosting an accounting server. End-users in Seattle and Minneapolis require some way of accessing the accounting server in Fort Worth. Background Seattle and Minneapolis currently have a wide area network connection that operates at 10 Mbps. This service is a managed service provided by the XYZ Telecommunications Company. As a managed service, XYZ owns the Cisco 4500 routers, and is solely responsible for their configurations. Upon request, XYZ will configure the routers with any provided routing or access-list filtering. The Cisco 3600 router at Fort Worth is part of a managed network service contract, and is also owned by the XYZ Telecommunications Company.
Action Plan Two Frame Relay links will be added to the existing network infrastructure, creating a fully meshed, fault-tolerant network. The organization will purchase 3 Cisco 1601 routers to support the Frame Relay network. Your task is to design a network configuration that connects the Frame Relay network to the existing corporate networks. To Complete This Lab 1. Create a logical network diagram outlining your addressing scheme. 2. Create configurations for all three Cisco 1600 series routers. 3. Document any needed changes (using Cisco IOS commands) for the XYZ Telecommunications Company routers. 4. Identify the process by which client workstations from Seattle and Minneapolis will connect to the 10.0.0.0 network. Things to Note 1. All routing taking place between Seattle and Minneapolis is being handled by static routing entries in the Cisco 4500 Series routers. There are no plans to change this routing policy. 2. Workstations in all cities currently have their default gateway set to the Ethernet 0 interfaces of the local XYZ Telecommunications Company-owned Cisco router. Solution There's a new twist to this month's CCNA Lab Scenario. First of all, the presented situation requires that you apply all of your CCNA knowledge in order to come up with a solution. This lab does not apply specifically to a particular month's Tutorial. Second, there can be multiple solutions, some better than others. The following is just one of several viable solutions to the problem:
Each of the new Cisco 1600 routers have had their Ethernet interfaces configured with an IP address from the existing local IP subnet. The biggest advantage of this type of configuration is that connectivity to both the new Cisco 1600 router as well as the existing Cisco 3600/4500 routers can be tested directly from any local PC using the PING utility. This will help facilitate any needed troubleshooting of the links. The existing WAN link between Seattle and Minneapolis uses static routing as the routing process. On a point-to-point link with no alternative routes, use of a dynamic routing protocol would serve no benefit. Now that new routers have been added to the network, use of a dynamic routing protocol would appear to make more sense. However, the existing service is being managed by the service provider and not by the local organization. Thus integration of the two separately managed networks under separate administrative control using a common routing protocol is unlikely. Because each WAN service is managed by separate entities, and the Frame Relay links are constrained by limited bandwidth, static routing is a suitable choice in this configuration. Each of the new Cisco 1600 routers have been configured as follows: Configuration of the Fort Worth 1600 Router Fort_Worth#sh run Building configuration... Current configuration: ! version 11.2
service timestamps debug uptime service timestamps log uptime service password-encryption no service tcp-small-servers no service udp-small-servers ! hostname Fort_Worth ! enable password enable ! no ip name-server ! ip subnet-zero no ip domain-lookup ! interface Ethernet 0 description <local Fort Worth network connection> ip address 10.12.1.2 255.0.0.0 ! interface Serial 0 no description no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial 0.1 point-to-point description <connected to Seattle> ip address 172.16.20.2 255.255.255.252 frame-relay interface-dlci 110 ! interface Serial 0.2 point-to-point description <connected to Minneapolis> ip address 172.16.20.5 255.255.255.252 frame-relay interface-dlci 120 ! ip classless ip route 192.168.1.0 255.255.255.0 172.16.20.1 ip route 192.168.2.0 255.255.255.0 172.16.20.6 ! line console 0 exec-timeout 0 0 password console login ! line vty 0 4 password console login ! end Configuration of the Seattle 1600 Router Seattle#sh run Building configuration... Current configuration:
! version 11.2 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption no service tcp-small-servers no service udp-small-servers ! hostname Seattle ! enable password enable ! no ip name-server ! ip subnet-zero no ip domain-lookup ! interface Ethernet 0 description <connected to local Seattle network> ip address 192.168.1.2 255.255.255.0 keepalive 10 ! interface Serial 0 no description no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial 0.1 point-to-point description <connected to Fort_Worth> ip address 172.16.20.1 255.255.255.252 frame-relay interface-dlci 210 ! ip classless ip route 10.0.0.0 255.0.0.0 172.16.20.2 ! line console 0 exec-timeout 0 0 password console login ! line vty 0 4 password console login ! end Configuration of the Minneapolis 1600 Router Minneapolis#sh run Building configuration... Current configuration: ! version 11.2 service timestamps debug datetime localtime
service timestamps log datetime localtime service password-encryption no service tcp-small-servers no service udp-small-servers ! hostname Minneapolis ! enable password enable ! no ip name-server ! ip subnet-zero no ip domain-lookup ! interface Ethernet 0 description <local Minneapolis network connection> ip address 192.168.2.2 255.255.255.0 ! interface Serial 0 no description no ip address encapsulation frame-relay frame-relay lmi-type ansi ! interface Serial 0.1 point-to-point description <connected to Fort_Worth> ip address 172.16.20.6 255.255.255.252 frame-relay interface-dlci 310 ! ip classless ip route 10.0.0.0 255.0.0.0 172.16.20.5 ! line console 0 exec-timeout 0 0 password console login ! line vty 0 4 password console login ! end Configuration of the Existing Managed Routers Each of the managed routers requires static routing statements to connect the existing local networks to the new Frame Relay network. The Seattle Cisco 4500 router requires the following addition to its configuration: ip route 10.0.0.0 255.0.0.0 192.168.1.2 The Minneapolis Cisco 4500 router requires the following addition to its configuration: ip route 10.0.0.0 255.0.0.0 192.168.2.2 The Fort Worth Cisco 3600 router requires the following addition to its configuration: ip route 192.168.0.0 255.255.0.0 10.12.1.2
Configuration of Client Workstations The existing client workstations require no reconfiguration. Frames destined to cross the Frame Relay network will initially be sent to the existing default gateway (the Cisco 3600/4500 routers), which will route the frame to the Cisco 1600 router. 7 Network Management Cisco has recently updated the CCNA exam and its objectives. The network management portion of the exam has been expanded much beyond its earlier scope, which makes sense in our more security-conscious networking environment. We need to understand more, even at the so-called entry-level positions, about how the network devices are configured and how the links and resulting topology can be managed. 7.1 Tutorial Introduction Cisco has recently updated the CCNA exam and its objectives. The network management portion of the exam once dealt with access lists (IP and IPX, standard and extended), telnet, and DNS; it then changed to reflect only access lists. Now it has been expanded much beyond its earlier scope, which makes sense in our more security-conscious networking environment. We need to understand more, even at the so-called entry-level positions, about how the network devices are configured and how the links and resulting topology can be managed. With a little rearrangement into groups, the nine objectives Cisco lists under the topic of network management reflect that new view:
• Manage a Single System o Load Cisco IOS software from: Flash memory, a TFTP server, or ROM o Perform backup, upgrade, and loading of Cisco IOS software and configuration
files o Manage IOS images and device configuration files o Manage configuration files from the privilege [sic] EXEC mode
• Manage Traffic on a Single System o Configure access lists to meet specified operational requirements o Monitor and verify selected access list operations on the router
• Network Operations o Configure authentication types (CHAP/PAP) on PPP links o Use CDP to identify a network topology o Use ICMP to verify network connectivity and locate network problems
Though it may not seem so at first, these nine objectives reflect what has become known as the "five smurfs" -- the network management framework described by the ISO in an annex to the famous OSI reference model for protocols. The five System Management Functional Areas (SMFA) or smurfs are:
WAN vendors seem to rearrange these, providing a handy acronym you may see in network management reference source material: FCAPS (Fault, Configuration, Accounting, Performance, Security). With a little thought, you can see that the only smurf not directly reflected in Cisco's CCNA network management objectives is Accounting management. However, without the proper configuration and performance data gathering, accounting has no information on which to report. Systems are built from constituent parts. Let's take these broad topics in the above order, starting first with how to manage the configuration of a single system, then considering how to manage the traffic flowing through that one component, and finish with network-wide operations.
Manage a Single System Though you may occasionally add hardware to a networking device (such as changing blades or adding new ones to a multi-blade switch like the Catalyst 6500 series), managing a device usually means managing its software. We use computing devices so much that it's easy to forget that, without useful software, they are merely expensive doorstops. This is reflected in the software focus of single-system management. The software of interest consists of both the operating system (OS) governing all processes on the host and the configuration files that specify how it will use the OS. Managing the software consists of being able to copy software images and configuration files between systems (to back them up or import them), and loading them on the device or configuring it to load them from a designated source. Note: Because many CCNA candidates are not yet familiar with UNIX and UNIX-like syntax, not all will recognize the UNIX origin of the router and switch command lines. If you're familiar with a Microsoft-based command line, the differences are just great enough to cause headaches and frustration when your CLI entries are not accepted. Remember that UNIX is case-sensitive and uses a slash (/) instead of a backslash (\) to delimit a file path Before you try to manage that system, you might want to know what's already on it. The command show version (note: all commands in this tutorial, unless otherwise specified, must be run from privileged exec mode) will display the following: the hardware configuration, the software version, the names and sources of the configuration files, and the boot images. With this information in hand, you can consider how you might want to modify things. Software The phrase "loading software" on a router or switch can be taken in two ways: loading the software into working memory, and loading it into the source files from which it is loaded into working memory. Both of these can be done from one of several sources. The objectives require that you understand three: flash memory already on board the device, ROM chips also on board the device, and over the network from a TFTP server. Even though we are all more-or-less familiar with these forms of storage, since the focus of this tutorial is network management, it's worth taking a step back to review the implications of these different kinds of storage. With that fresh in our minds, we can review how to perform such software loads. Operating software packages are usually known as images. An image is a file of a specific version of the software, compiled for a particular set of hardware. Image names may look cryptic at first, but they are actually quite descriptive. Try this example from IOS Release 12.2: c3640-c2is-mz.Feb24 -- "c3640" indicates the product (Cisco 3640), "c2is" indicates the feature sets supported, "mz" is actually a pair of indicators (where "m" means the image runs from RAM and "z" means the image is compressed), and the date is obvious. You may have access to several images from one source file system. That is similar to having multiple operating systems that a PC can boot into. All file system sources are forms of storage for the software image that is to be loaded into working memory (typically RAM). More than the three sources in the objectives are available: NVRAM, xmodem and ymodem dialup sources, FTP servers, rcp (the UNIX remote copy command is rcp -- and don't forget, UNIX is case-sensitive) are among the possibilities. Working memory, of course, is volatile -- when power is removed, its contents are lost. The other sources are nonvolatile. They do not require power to retain their contents, and so the contents are there even when power has been interrupted. When power is restored, the source is ready and waiting. Each source offers us different advantages and disadvantages. ROM, we all know, stands for Read-Only Memory. Instructions, once written to ROM, are fixed. This means that the software stored in ROM is likely to be the oldest of the available sources. (Given the nature of software upgrades, of course, that may also make it the most reliable.) Loading from ROM, then, often means rolling back to a previous version (or release) of software; this may result in the loss of
some features or functionality that the network needs. ROM is always present on the device, however, and so does not require a network connection or additions after the device leaves the factory. Loading from ROM, then, is the software source the first time the device is powered up. It is also often used as a source of last resort for a working network device. Flash memory is also present on the device, but, unlike ROM, it is rewritable without being volatile. PCMCIA cards are a form of flash memory. Flash and ROM both have no moving parts and therefore they load very quickly. In addition, they are local to the device. The advantage of flash over ROM is that, being rewritable, it can be updated with a new version or revision of software. This combination -- the latest software plus local and fast retrieval -- makes flash memory the first choice (typically) for loading a software image. A TFTP server is our third option (in the objectives). While a router may be configured in the IOS to act as a TFTP server, in this case, the reference more likely is to loading software from a TFTP server elsewhere on the network (whether it is what Cisco calls a "classic TFTP server" or a TFTP server on another router). Note: TFTP The Trivial File Transfer Protocol, or TFTP, suffers somewhat from the connotations of the word Trivial. The protocol is not necessarily used only for file transfers that really aren't that important. The name "Trivial" was used because of the protocol's simplicity and ease of implementation, especially compared with the File Transfer Protocol, or FTP. The current source document for TFTP is RFC1350. While FTP uses TCP on top of IP (and therefore requires a connection-oriented session between the devices involved in the file exchange), TFTP uses UDP. UDP is much less sophisticated and, as a result, operates much faster and with lower overhead. This is important when transferring very large files, such as a software image. We all remember that UDP has no guarantees of receipt, unlike TCP, with its requirement for ACKs (acknowledgments). TFTP compensates for this disadvantage with its file transfer method. Where FTP uses TCP's adjustable window to send multiple packets for each ACK, TFTP sends each fixed-length 512-Byte chunk of information one at a time, and does not send the next until that one is acknowledged. If a next packet is not received, after a timeout, the receiver repeats its last acknowledgement and the sender retransmits. The sender only has to retain one packet for retransmission instead of several, as it would using FTP and TCP; this is simpler to buffer. A packet containing less than 512 Bytes denotes the end of the file to be transferred (again, not as sophisticated as TCP's FIN, but compensating for UDP's total lack of closure). In short, despite its name, TFTP is a reliable as well as fast and low overhead means to deliver a large and complex file that must be complete -- no lost packets. An advantage of the TFTP server is that it can store many possible images as well as serve as a central repository for images for several different types of devices. You could, for example, have a TFTP server with images for several different routers, switches, hardware firewalls (such as Cisco's PIX), and so forth. Even better, of course, would be a redundant TFTP server, but network reliability is not our concern in this tutorial. In the disadvantage column, TFTP as an image source will always be slower than either ROM or flash, since the source is over the network and that does take more time to transfer the data, even if no packets are lost and must be retransmitted. Another disadvantage of TFTP is that it generally requires a working network connection -- if connectivity is lost, a reload, which can only come from that server, will fail. So, there are the three means to load software into a router or switch, and some of the implications of their characteristics. The next question is, how, exactly, do we get the software loaded? We configure the router or switch to seek out its source of system software when it boots or reloads. To display the current software configuration, as well as to modify it, we must be in. You may see references, especially when you seek help in the IOS documentation, to "Class A" or "Class B" or sometimes "Class C" flash memory. According to this source, Class A flash is used on the Cisco 7000 family, Cisco 12000 series, LightStream 1010 (LS1010) series; Class B
is used on the Cisco 1003, Cisco 1004, Cisco 1005, Cisco 2500 series, Cisco 3600 series, Cisco 4000 series, Cisco AS5200 access servers; and Class C may be found on the Cisco MC3810 multiservice concentrators, and on disk0 and disk1 of Cisco SC3640 system controllers. Loading Software onto Switches The switch's software is loaded by default from the flash file system. To confirm the source actually being used on the switch, check the current working directory by using the pwd command (this is the UNIX "print working directory" command). This "default" file system is the software source when a command has an optional field to specify a file system, and you do not do so. In other words, you could have specified an alternate software source, but since you didn't this (default) source will be used automatically. To see the available file systems you could enter the show file systems command from the privileged exec prompt. When you want to know which software load is in one of these file systems, before you order its use, use the dir command with the file system's name. For instance: Switch#dir flash: Note: Finding Help When you are actually working with Cisco products, sometimes you need to find help for that particular piece of hardware or software. The recent restructuring of Cisco's web site may seem confusing at first, but all the information you need can generally be found, with a just a little drilling down the link tree. For information on a specific software release, go to Cisco's web page (http://www.cisco.com/) and select "Products and Services," then select "IOS Software." You will get a window listing the actively supported releases. If you don't understand the nomenclature, such as the differences among T, X, S, and E releases, review this. You can work through the links on the left of this page to get the documentation on a specific release; for example, the documentation for Release 12.1. For detailed information on the switches, select "Switches" under "Products and Services." The same principle applies to routers. or Switch#dir tftp:[[//location]/directory]/filename This is UNIX directory syntax; the location is the TFTP server's IP address. To specify the file system to be used as the source for the software image, use the cd command: Switch#cd flash: or Switch#cd tftp:[[//location]/directory]/filename or Switch#cd ftp:[[//username[:password]@location]/directory]/filename etc. To copy a new software image to the switch, use one of these commands: Switch#archive download-sw /overwrite /reload tftp:[[//location]/directory]/image-name.tar or Switch#archive download-sw /leave-old-sw /reload tftp:[[//location]/directory]/image-name.tar The first choice overwrites the existing software, even if it is the same image (you might want to replace a corrupted image). The second choice leaves the old software image in place. The download algorithm will verify that the image is appropriate for the model of switch you are using, and that there is sufficient DRAM present; if either condition is not true, the switch aborts the download. In both cases, note that we are reloading the switch after bringing in the new image. The BOOT environment variable will be reset to point at the new image directory, so the reload will use the new image. To bring in a new software image from an FTP or rcp server, you must have a valid account and password on that server. Note that the username and password may very well be passed through the network unencrypted.
Loading Software onto Routers The commands for routers are similar. To bring a copy of an image from a TFTP server to flash, you should be sure there is room in flash to hold the image. To do this, use the command show flash: in privileged exec mode (don't forget the colon). Your response will look something like this: RouterA#show flash: System flash directory: File Length Name/status 1 4137888 c3640-c2is-mz [4137952 bytes used, 12639264 available, 16777216 total] 16384K bytes of processor board System flash (Read/Write)\ Based on the size of the existing file, we ought to have plenty of room for another image, although I would check the file size anyway. Notice that this also shows us the name of the image currently in flash. We can see that this particular 3640 has 16MB of flash. If you try to copy a file too large for the remaining space, the copy command will be partially executed, but the entire file will not be copied into flash. You will receive a failure message stating "buffer overflow - xxxx/xxxx"; xxxx/xxxx is the number of bytes read from the source file and the number of bytes available on the destination device. Of course, since boot normally occurs from flash memory, do not reboot the system if you do not have a valid image in flash. On Class B flash systems, you have the option of erasing the existing flash memory contents before you download, which is useful if you do not have sufficient flash memory available to copy down the image you need. Once begun, don't be interrupted -- note again the last sentence of the previous paragraph. You cannot operate the router from flash at the same time you are downloading a new image into that flash. Note that I used "that flash" -- you may be able to partition the flash and operate from one partition while downloading to another. Otherwise, you should reboot the router from another source (such as ROM) before beginning the download. We will cover that shortly. Assuming we have met all these criteria, we need the command to copy the image from a TFTP server into flash. It is this: RouterA#copy tftp:[[[//location]/directory]/filename] flash-filesystem:[filename] If you are not familiar with IOS documentation, this looks difficult, but take it a piece at a time. "copy tftp" invokes the copy routine, with a target of a TFTP server. The square brackets show us the optional inputs. The location is the TFTP server's IP address or resolvable name; it is followed by specifying (if necessary) the directory and filename. Next comes the target destination, in our case the flash file system; we may choose to save the image with another filename. If we omit the inputs in square brackets, we are prompted for the information. During the copy operation, you will see a series of symbols. Different devices have different symbols to show the progress of erasing the existing flash files; a "#" is often used. A "!" indicates the transfer of 10 packets. A "V" indicates checksum verification is being done while the file is copied into flash. An "O" indicates a packet received out of its proper order (see the TFTP sidebar for a review, if necessary). A "." (period) indicates a timeout. The final line of output during the copy indicates whether it was complete. So, we have an image on the ROM, placed there at the factory and not changeable; we have an image in flash, and we know how to get a different image into flash. When do we get the desired image into RAM? At bootup, which is when configuration (config) files are also loaded. So let's address them, first. Configuration Files Of course, you can always create a configuration file by running setup, which offers a series of prompts. That tends to provide a basic configuration file, which you will probably expand to cover other activities/services. Let's take as a given that, one way or another, there is at least one configuration file on the router or switch in question. How do we copy it to another machine, or copy one from there into the device? And how do we tell the device that we want it to use this particular config file over any others that may be present, that is, to load this config?
Note: Before we get too far into these commands, be aware that, effective with IOS Release 12.2, a number of the "classic commands" you see in books and previous articles have been changed. Although currently some of the old versions will be accepted as an alias to the new versions, Cisco does not say how long this will be available. See this page, Table 32. Copying Configuration Files You have finished modifying the running configuration and want to save it as the configuration to be used at startup/reload. The latter is stored in NVRAM on the system. The classic command was copy running-config startup config. The old command is still accepted as an alias (so far), but the new command is copy system:running-config nvram:startup-config. Notice the syntactical structure change, specifying the source and destination file system targets, and the lack of spaces after the colons. To copy the running config to or from a TFTP server, use these (new version) commands: copy system:running-config tftp:[[[//location]/directory]/filename] and copy tftp:[[[//location]/directory]/filename] system:running-config To do this with the startup config instead of the running config, simply replace the name (i.e., use startup-config instead of running-config). To use an rcp server, replace the tftp:[[[//location]/directory]/filename] in these commands with rcp:[[[//[username@]location]/directory]/filename]. Likewise, for an FTP server, use ftp:[[[//[username[:password]@]location]/directory]/filename], which has a similar syntax. Note that these commands back and forth over the network use a double slash when specifying the location -- that's an easy typo to miss and hard to spot when you are troubleshooting a command that mysteriously didn't work. To summarize, you copy from one system-specific location to another system-specific location. If it is local, such as the running config or the startup config, the syntax is system:config-name. If it is remote (over the network), you specify the protocol (tftp, rcp, ftp) followed by a separator (:) and the location description (address or resolvable name, directory, filename). If you're wondering how the config file got a name on the network server, it happened when the file was copied to the server from the network device. To see the contents of that file, instead of the old show command (such as show running-config), use the new more command, with the new location syntax: more nvram:startup-config, for instance. Now that we know how to load software images and configuration files on a single system, it's time to look at how to manage the traffic flowing through that system. Manage Traffic on a Single System Traffic management on a router is about access lists. Logically, access lists have two parts:
• Match conditions or recognition rules: "Calling all cars -- look for a white Bronco with license plates XXX"
• Actions on matching: "Maintain surveillance" or "Arrest" If you watch any police shows, you'll realize that the match conditions can be defined once and referred to in many places, but the places you watch for them need to be defined explicitly. Why bother the clerks in the windowless police record room with instructions to look for something they can't see? These are sometimes (even in broad discussions within Cisco documentation) called ACLs. An ACL (aside from being a career-ending knee injury) is an Access Control List, and it does just that -- controls user access to resources, such as a service (telnet, DNS, etc.) or a resource (a server, color laser printer, etc.). When you dig into the heart of the Cisco documentation concerning
filtering and controlling the flow of traffic, the term "access list" is used instead of Access Control List. Access lists determine which traffic is allowed to have access to the port. They do this by specifying access permission or denial based on each individual packet's content. This can be done at different levels of specificity, with the cruder forms of access lists granting or denying access only on address. Of course, that means that all traffic for that address is treated alike. More advanced access lists, however, offer much finer control, based on content further inside the packet, such as port or protocol. If an interface has no access lists applied, all traffic (the good, the bad, and the ugly) is passed, regardless of its implications for network security or performance. However, once an access list is applied to a direction on an interface (and more about that shortly), the default condition flips from permitted to denied. In other words, with no access list, all traffic is permitted by default. With any access list applied, all traffic not explicitly permitted is denied by default. This is known as the "implicit deny" rule: any traffic not explicitly permitted is implicitly denied when an access list is present. Access lists are written into the device's configuration file, then applied to a particular interface in a specific direction. If that seems confusing, think of it this way: I create a filter (access list), which may be used on more than one interface. I configure the router to apply that access list on each interface; when I do, I specify which direction of traffic I want to filter. Perhaps I simply don't care about filtering the traffic coming into the router on interface ethernet 0 (e0), but I very much care how much Ethernet traffic the router puts on that wire -- in that instance, I apply an outgoing access list. Alternatively, the interface could be serial -- a WAN link, and I don't want to send certain traffic over that link and possibly violate my Service Level Agreement and have to pay penalties. In this instance, I also filter the outgoing traffic. If I'm concerned about security, I don't want my router vulnerable to ping attacks (such as the "ping of death" -- an attack that can overwhelm a device by bombarding it with thousands of pings). I can create an access list to filter out ICMP echo requests (but not echo replies -- I want to be able to run ping myself) and apply that list to the incoming WAN interface to protect my router. When we think of access lists, we automatically think of IP; perhaps we remember to include IPX (and there are still plenty of networks using IPX/SPX as well as, or instead of, IP). But you can create and apply access lists for many more protocol suites than just these. And the identifying number of an access list specifies the protocol suite it will filter (the ones you are most likely to encounter are highlighted): Table 1. Access List Numbers
You will notice that there is some overlap among VINES and other protocols, but VINES is essentially obsolete. Access lists may also be named, rather than numbered. One advantage of using names (aside from helping you and others remember the purpose of the list) is that you can create more access lists with names than numbers. For instance, suppose you wanted to create an Ethernet type code access list, or any IPX access list -- there are only 100 of those numbered lists possible. On a small network that may be no problem at all, but on a large enterprise network it can become limiting. If you use a named list instead of a numbered one, your command syntax changes a little on the line creating the list. There are also some minor differences in your ability to edit an existing access list between named and numbered access lists. However, new entries to an existing access list will always be added at the end of the list if you edit at the CLI. Therefore, Cisco recommends (and so do I) that you create and maintain your access lists at a server, downloading them when you need to update your router. The update can come either through TFTP or through the Telnet interface. Telnet is especially convenient when you can upload and download files through your Telnet client on your workstation. It's also a good idea to put no access list number at the beginning of every access list number, so you can be sure that you aren't doing strange merges and that you are starting with a clean slate. There are some factors to take into account when creating access lists, before you apply them to an interface. Most access lists operate at Layer 3 of the OSI model. Every packet that passes through an interface that has an access list applied in that direction will be examined and tested against that access list. For instance, I have an outgoing access list on my WAN interface; every packet leaving the router on that interface will be tested against the statements in that access list. Further, each packet is tested against each line of the access list in the order in which the list is currently written and saved in the running config. Real-world access lists can be many lines long, and the order in which they are written becomes very important to router performance. This, of course, is in addition to the performance characteristics you get when you use a type of switching; some of the faster switching types (such as Distributed Switching and Cisco Express Forwarding, or CEF), cannot be used with access lists. For more on this, see this article. The reason order is so important is that the first time a packet matches a line in the access list, the action in that line is applied, and only then does the router examine the next packet. If most of your traffic is HTTP (web) traffic, and the permit statement for HTTP or TCP port 80 is the twelfth line of the list, every web packet is tested against each of the preceding eleven lines before any action is taken. If you could move that permission up to the second or third line, every one of those (majority) HTTP packets would be processed faster and the router could then consider the next packet in the queue. You may have noticed in the number list above that there are two kinds of IP and IPX access lists -- standard and extended -- along with a special kind for IPX called IPX SAP. You can think of
standard access lists, both IP and IPX, as basic filters: they have a very limited capability to discriminate among packets. Extended access lists, however, in both cases allow much finer discrimination of traffic, and are often -- but not always -- preferred. IPX SAP access lists are used to manage the flow of Service Advertising Protocol message traffic. Location, Location, Location Supposedly, there are only three things that matter when it comes to real estate: location, location, and location. Network management considers more -- much more -- than location, but where you place an access list does matter. Traffic goes through many interfaces as it travels through the network, raising the question of which interface is the best one to have a given access list. The answer, as usual in networking, is "it depends". Remember the difference between standard and extended access lists? Standard access lists operate like a club, indiscriminately whacking all traffic of the particular protocol stack (IP or IPX, for instance) traveling in a given direction. You don't want that going on except as close as possible to where it's actually needed -- standard access lists (as a rule of thumb) are placed as close as possible to where the protocol is a problem, so traffic through the rest of the network is impacted the least. Extended access lists, on the other hand, can be much more finely tuned, removing only that traffic we didn't want in the first place. Therefore, the rule of thumb for extended access lists is to place them as close as possible to where the offending data enters the network, to keep the unwanted traffic (which we're going to dump anyway) from using bandwidth en route to the bit bucket. The lab exercises will offer a chance to look at that in operation. Knowing that where we place an access list matters, here's another factor to consider: Only One Per Customer, Please! Remember, you get one list per protocol per interface per direction. In that vein, construct the list carefully. It may sound like a complicated rule, but break it into pieces: One list... per interface... per protocol... per direction That means one incoming list for IP on a given interface (that's one standard or one extended list, not one of each). There can also be one outgoing IP list. There can be one incoming IPX list and/or one outgoing IPX list. And so forth. Aces Are Wild Another item regarding access list construction: both IP and IPX access lists use a wildcard to simplify construction. The IP access list wildcard is quite flexible. When you specify an IP address, even one that's actually a network address (like the first address in a subnet), only that particular IP address will match. To save ourselves typing a line (and making the processor read through a line) for every single host on the network in question, we use the optional IP wildcard mask. It looks very similar to a subnet mask, but it doesn't work in quite the same way. Here's a comparison of the two:
IP Address: 172. 16.221.57 IP Address: 172. 16.221. 57
In a wildcard mask, the ones (when written in binary) act like wildcards, making a one or a zero acceptable in that bit place of the address. Where there's a zero in the bit place of a wildcard mask, the number must match. In our example on the right above, the first three octets being all zeroes means that an IP address must match the access list exactly in those octets; all ones means any address in this octet will match. Thus, any host in the 172.16.221.0 network will match this wildcard mask -- the aces (the binary ones in the last octet) make any number here a match. Remember this: You have configured correctly when the octet of the subnet mask, added to the octet of the wildcard mask, equals 255.
When in doubt (for instance, when you take the exam), write out the address in binary, then write out the wildcard mask in binary beneath it. Wherever the mask has a zero, the IP address in the packet must match. Wherever the mask has a one, the access list matches automatically. There are two "special" cases of the wildcard mask: the words any and host. any is a shortcut way of writing 255.255.255.255, the wildcard mask that will match against any IP address. host, on the other hand, is much more picky. It's short for 0.0.0.0, another way of saying the IP address must match exactly. The wildcard mask thus lets you define which addresses will match and which will not, without having to write a line (and consume processor time reading every packet against every one of those lines) for every address of interest. Trust, But Verify "So it is written, so let it be done" may work well in a dramatic production, but it's not such a great idea on a production network. Always verify your lists! To know which lists have been constructed, and to read them through, use the command: RouterA# show access-lists The output you get (and we'll show an example later) gives the type of access list and its number, followed by the list, statement by statement, with the number of matches against each statement since the counters were last cleared. This is where (if you turned on logging) you can see how many matches the explicit deny statement at the end of the list generated. IP Access Lists With this general knowledge in hand, let's take a more detailed look at some different kinds of access lists: Standard IP access lists and Extended IP access lists, and the three types of IPX access lists (Standard, Extended, and SAP). Standard IP Access Lists Standard IP access lists are numbered, as noted above, from 0 to 99. Their format (which you can always walk through with the interactive help at the CLI) is: RouterA(config)#access-list number {permit | deny} [source] For instance: RouterA(config)#access-list 42 deny 47.101.210.82 This would deny any IP traffic (IP because the list number is between 0 and 99) from the host at IP address 47.101.210.82, whoever that may be. Something to remember, by the way -- if this is the only line in our access list, and the access list is applied, no IP traffic will come through that interface! Remember the "implied deny any" we talked about earlier? Once an access list is applied to an interface (and the worse direction would be inbound), the only traffic of that protocol type which passes through is that which the list permits -- and we didn't permit any. Having permitted no traffic, the only way to work with this router is directly through the console port. Hope you can afford the travel... But, you didn't make that mistake, and you actually have seven hosts, conveniently grouped in a subnet (subnet mask of 255.255.255.240), whose traffic you need to deny. Remember, when you list one IP address, the line applies only to that address. To specify a network or a group of addresses, you must use a wildcard mask. Rather than typing in a line for each host, use the first address plus a wildcard mask that fits only the hosts you want (which, in our case, is a subnet whose hosts are .81-.94, with .80 as the network address and .95 as the broadcast address): RouterA(config)#access-list 42 deny 47.101.210.80 0.0.0.15 RouterA(config)#access-list 42 permit any any RouterA(config)#^z If you wanted to use a named access list in this instance, you would start the sequence with RouterA(config)#ip access-list standard devnet deny 47.101.210.80 0.0.0.15
Note: 0.0.0.15? Huh? Where did that wildcard mask (0.0.0.15) come from? Look at the host addresses on the .80 subnet in binary: the leftmost four bits are always 0101; only the four rightmost bits vary (from 0000 to 1111). .81 01010001 .82 01010010 .83 01010011 ... .94 01011110 Since those may vary, those need to be wildcarded. That means a wildcard mask of 00001111 -- the leftmost bits must match 0101 (the first four bits of the address given, .80), while the rightmost bits can be anything. You may find it very useful to memorize the decimal equivalent of contiguous strings of ones in an octet, from left to right and from right to left. For Subnet Masks For Access List Wildcard Masks Binary Decimal Binary Decimal 00000000 0 00000000 0 10000000 128 00000001 1 11000000 192 00000011 3 11100000 224 00000111 7 11110000 240 00001111 15 11111000 248 00011111 31
11111100 252 00111111 63 11111110 254 01111111 127 11111111 255 11111111 255 Notice that we identified the protocol type (IP) and the class of access list (standard). Note that, this time, we've denied IP traffic (in whichever direction the list is applied on the interface) from the hosts in the subnet 47.101.210.80, but permitted any other IP traffic. This sequence is important, because of the first match rule: if we allow any traffic from anyone, we'll never get to the denial for our problem subnet. And that, essentially, is a standard IP Access List: crude but effective, and certainly simple to create. Extended IP Access Lists Extended access lists are numbered from 100-199, and have a more detailed syntax. The number, the permit/deny statement, and both a source and a destination are required. Using a wildcard mask for the source and/or the destination, and specifying a protocol type and/or a port are optional. access-list number {permit | deny} [protocol] source destination [option] Breaking it down, the number comes from a different group, but the choice of permitting or denying traffic is in the same spot in the command. The specification of a protocol and an option allow us to take advantage of some of the characteristics of an IP packet's header. Inside the header, we have a version number (while we all may be using IPv4 now, that wasn't always the case ... and it won't necessarily be the case in the future, either). That's followed by the destination address and the source address. After that comes the protocol type: IP carries packets created by many different upper layer protocols; among them TCP, UDP, and ICMP. Try typing RouterA(config)#access-list 125 permit ? at the CLI and look at the list from which you can choose. This protocol choice, combined with the optional last field, enables you to specify exactly which traffic you don't want. Suppose you wanted to stop some streaming media traffic, which you know is carried by TCP over port 33333 (for instance). Your whole network is 47.101.210.0/24, so you could put the following in an extended IP access list: RouterA(config)#access-list 125 deny tcp any 47.101.210.0 0.0.0.255 eq 33333 or RouterA(config)#ip access-list extended media deny tcp any 47.101.210.0 0.0.0.255 eq 33333 RouterAconfig)#access-list 125 permit tcp any any The first line denies TCP traffic on port 33333 (the option eq, followed by a number, means a port number, and we specified TCP earlier in the line), from any source to the 47.101.210.0 network. The second line permits any TCP traffic from any host to any host, thereby letting the rest of it through. Another choice is to restrict certain protocols or their use, such as denying ICMP echo-requests. You may be concerned with Distributed Denial of Service (DDoS) attacks involving your network.
One method of DDoS is to direct several computers to ping one target repeatedly, tying up the target (even overwhelming its capacity) with processing the requests and replying to them. By using an Extended IP Access List, you can deny the protocol ICMP and use the option "eq echo" to prevent such disruptions: RouterA(config)#access-list 125 deny icmp any 47.101.210.0 0.0.0.255 eq echo RouterA(config)#access-list 125 permit tcp any any Do note that there are additional measures, beyond the CCNA level, that can protect against flooding, such as traffic policing. See Managing Performance and QoS Part 1, a CCIE-level cZone tutorial. If there is a type of traffic known to come in on a given port or use a certain protocol, you can also be selective about permitting or denying it with the use of the option "established". For instance, you might not want outsiders initiating HTTP traffic sessions into your network, while still being able to use the World Wide Web as long as that use originated inside the network. Use something like this, applied inbound to an edge interface: RouterA(config)#access-list 125 permit http any 47.101.210.0 0.0.0.255 established RouterA(config)#access-list 125 deny http any 47.101.210.0 0.0.0.255 The two statements look confusing at first, but take them step-by-step. The first statement permits established HTTP traffic from anyone into your network. The second denies HTTP traffic from anyone into your network. An "established" connection is one already going; it does not include the traffic that initiates a session. Only outbound traffic will be able to establish a connection; inbound will never get the chance. Therefore, a session initiated by someone inside the network is free to continue, while outsiders can never initiate one coming in. Applying IP Access Lists Once we've constructed (and proof read!) our access list, how do we apply it? That depends on where we're applying it. On a router interface, like RouterA e0, the command uses the term access-group. For instance: RouterA#config t RouterA(config)#int e0 RouterA(config-if)#ip access-group 125 in RouterA(config-if)#^z Note: In a command, "access" is followed by a hyphen (e.g. show ip access-list), but in any other discussion, the two words are separate. This sequence of commands applies the Extended IP Access List 125 (whatever its contents) to incoming traffic at interface Ethernet 0 on Router A. (And if you want to keep it, remember to copy the running configuration to the startup configuration, as shown earlier.) On a vty (virtual terminal) interface, the command is similar. A vty is referenced by line instead of interface, thus protecting the router from indirect telnet access as well as telnet through a specific interface. (Telnet could be restricted by protocol name and reference to port 23 in an extended IP access list, but the protection would only work on the interfaces to which the access list had been applied. A telnet session entering the router via another interface would be ignored.) Telnet access lists also use access-class instead of access-group: RouterA#config t RouterA(config)#line vty 0 RouterA(config-if)#ip access-class 125 in RouterA(config-if)#^z One thing to be aware of -- the access list has been applied only to the first virtual terminal port in this example (you can specify a range by stating the end points -- vty 0 4 would include the range 0-4). Some network engineers deny useful access to all but the last virtual terminal port, and leave it wide open as their last resort to get in (without making that drive across town ... across the state ... across etc.). This is not widely considered a good idea, unless you can convince management that it really shouldn't have been a problem to leave one interface wide open, even though that's how trouble got in.
IPX Access Lists IPX access lists are similar in principle, and in structure, to IP access lists. However, there are some differences and those differences could show up in exam questions. Like IP access lists, IPX access lists require you to specify the protocol and class if you use a named access list instead of a numbered one. Host addressing in the IPX/SPX suite consists of a four-byte (32-bit) network address, usually expressed in dotted hexadecimal notation (vs. the varying number of bits in an IP network address, which are expressed in dotted decimal notation). The network address is followed by a six-byte (48-bit) node address (so that a complete host address is 10 bytes, or 20 hexadecimal characters). For instance, a node with the IPX address 4b2c.1205.0000.b4be.0040 has a network address of 4b2c.1205 and a node address (usually the MAC address) of 0000.b4be.0040. In practice, IPX network addresses do not often use all four bytes. If they begin with two bytes of zeroes, those two bytes are not stated. A key to using IPX addresses (if you're not that familiar with them) is to remember the MAC address is the node, and MAC addresses are 12 hex characters. Anything to the left of that is the network address. Standard IPX Access Lists Numbering for standard IPX access lists is in the range 800-899, and a standard IPX access list has one more data field than a standard IP access list: a destination network/address. Recall the standard IP access list format: access-list number {permit | deny} [source] A standard IPX access list has this format: access-list number {permit | deny} source destination The source and destination addresses are in the form of [network][.node], which means you can state the network, or the network and specific node address, for either. While still clumsier than an extended IPX access list, it does at least let us narrow the scope of our restrictions to a destination as well as a source. It's still relatively easy to construct. An example list would be along the lines of: RouterA#config t RouterA(config)#access-list 847 deny 1205 1010 or RouterA(config)#ipx access-list standard borg1 deny 1205 1010 RouterA(config)#access-list standard borg1 permit 500 1010 RouterA(config)#int e0 RouterA(config-if)#ipx access-group borg1 out RouterA(config-if)#^z This list denies IPX traffic from network 1205 to network 1010 then permits IPX traffic from network 500 to network 1010 then (implicitly) denies all other IPX traffic. Again, the application of the access list is by the command ipx access-group number {in | out} Extended IPX Access Lists Extended IPX access lists are numbered in the range 900-999. Like extended IP access lists, they are more capable, and more complex in their construction. Their format is: access-list number {permit | deny} protocol source [socket] destination [socket] The IPX socket serves the same function as the TCP or UDP port -- it differentiates a data stream. Again, the IPX access list is a bit more sophisticated than the IP access list: the source and destination sockets can be separately identified. And, like the IP access list, a wildcard mask can be applied to the IPX source and/or destination. The sockets and protocol numbers can be found in many references. They are, for example, in Chapter 4 of Laura Chappell's Advanced Cisco Router Configuration, from Cisco Press. An interesting possibility is available regarding the protocol number: it can be 0, for any protocol, or one specific choice of protocols.
With an IPX extended access list, we can deny specific traffic that may be unnecessary for our network. For instance, in a small network where we don't need IPX NetBIOS traffic, we can deny that -- its protocol number is 20. If you specify a socket, you'll see from the CLI help that socket numbers are expressed in hexadecimal. RouterA#config t RouterA(config)#access-list 959 deny 20 1205 1010 RouterA(config)#access-list 959 permit -1 500 1010 RouterA(config)#int s0 RouterA(config-if)#ipx access-group 949 in RouterA(config-if)^z Notice in the third line, the "-1". That is a wildcard, like "any" in IP access lists. The third line permits any IPX protocol from network 500 to network 1010. SAP Filters IPX is sometimes called a "chatty" protocol suite, and much of the chatting comes from SAP, the Service Advertisement Protocol. NetWare networks are based on a client-server model, and clients request services as needed. Servers also periodically broadcast the services they provide, and routers normally forward those broadcasts so the information is disseminated. However, not all of these advertisements are useful on a given network segment. SAP Filters let you manage that traffic. Consider the situation if you have two LAN segments connected by a WAN link. A server on LAN segment 1 is a file server, an NDS server, and a print server. A server on LAN segment 2 is a print server only. Neither LAN segment really needs to know about the print services being offered on the other segment, but both need to know about the file and NDS services on segment 1. A SAP Filter, placed on either end of the WAN segment, would keep the unnecessary print service advertisements from using bandwidth needed for other things. SAP Filters are access lists numbered from 1000-1099. Their format is quite simple: access-list number {permit | deny} source service_type Only one SAP filter can be applied to an interface at a time. The one filter could be an input filter, which removes unneeded SAP entries before the router's SAP table is built; an output filter, which removes the unwanted data before the next SAP update to go out that interface is created, or a router filter, which specifies which routers this router will accept SAP updates from. A SAP filter is constructed and given a SAP filter number, then applied with the command ipx input-sap-filter number, ipx output-sap-filter number, or ipx router-sap-filter number in interface configuration mode. Sound confusing? Here are two examples. First, we want to block outgoing print advertisements from network 1201 (print service advertisements are service type 47). RouterA#config t RouterA(config)#access-list 1088 deny 1201 47 RouterA(config)#access-list 1088 permit -1 RouterA(config)#int s1 RouterA(config-if)#ipx output-sap-filter 1088 RouterA(config-if)#^z Interface serial 1 is our WAN interface. We don't want to send printer service advertisements out that port, so we apply our SAP filter on the outbound traffic. We might also have a network segment that needs to receive SAP information from one network, but not from any others. That might look like this: RouterA#config t RouterA(config)#access-list 1055 permit 1201.0000.b4be.0040 -1 RouterA(config)#access-list 1055 deny -1 RouterA(config)#int e1 RouterA(config-if)#ipx router-sap-filter 1055 RouterA(config-if)#^z
In this case, we are going to permit any (the "-1") SAP traffic from the interface at the specified address (network 1201, node 0000.b4be.0040), but deny all other SAP advertising coming in on interface ethernet 1. There is actually more that can be done with SAP filters, but that is beyond the scope of the CCNA exam. If you are working with an IPX/SPX network, here is help with IPX access lists. Verifying IPX Access Lists Just like IP access lists, you want to verify which IPX access lists are in place on a router. The commands are almost the same; we just substitute "ipx" for "ip" where necessary: show access-list displays all access lists, for any protocol show ipx access-list displays the IPX access lists on the router show ipx int s1 displays the IPX configuration of that interface (serial 1), including the IPX access list(s) which have been applied more nvram:running-config (which has replaced the old show running-config) displays the access lists by interface, in numerical order Network Operations Now that we know how to configure an individual router and manage traffic on it, it's time to have a look at managing the network. Of course, we don't want just anyone mucking about in our network, so it's useful to require authentication on your links. If those links use PPP, you can find more detailed information than we have in this tutorial (and authentication is a very deep as well as broad subject in its own right), here is a good place to begin. Configure Authentication Types The objectives for the CCNA exam require that you know how to configure PAP and CHAP on PPP links. PAP is the venerable Password Authentication Protocol. I say "venerable" because PAP is one of the two early protocols (1992) for exchanging passwords over the Internet (the other being CHAP). CHAP is the Challenge Handshake Authentication Protocol. Both were originally specified in RFC1334, which was made obsolete by RFC1994. However, the latter did not address PAP; only updating CHAP, so you may want to reference the earlier RFC. Use of PAP or CHAP on a PPP link is intended to help central routers know which remote routers may be connected. With this knowledge, if the central router or access server receives a packet destined for a particular remote router, it knows whether it can use an existing connection or must create a new one. PAP and CHAP may be configured on serial interfaces that have been configured to use PPP. Even though you may use it, PAP is not a good choice for passing user credentials over a network, even an internal network, because the user name and password are sent in the clear -- they are not encrypted. Many, many network problems result from misuse by internal personnel rather than outside attacks (though of course, there are plenty of those to go around). A simple sniffer will capture a username/password pair passed over the Ethernet link -- and remember, the local network is a shared wire, with all hosts receiving all packets; those not addressed to "this" host are just supposed to be discarded. For more about sniffers, Security Focus had a good online article. At the bottom of the page are links to some sniffer packages. On a point-to-point link, the medium is not shared. However, that does not mean it is safe to send unencrypted passwords over that link! It may exit the network before re-entering (as in traversing the WAN) or a sniffer may have been planted on one end. Therefore, even though you must know how to configure PAP on a point-to-point link, I do not recommend doing so. CHAP, on the other hand, is somewhat more secure. When a remote device connects to a router on an interface that has CHAP enabled, the router sends a challenge packet. It contains an ID, a random number, and the host name of the router. The remote device seeking authentication replies with an encrypted version of the ID, a secret password, and the random number, plus the remote host's name or the username logged on it. The router calculates what the encryption should look like and compares this to the received packet. When there is a match, the PPP session is established. While the password is never sent in clear text, CHAP does require the devices on both ends of the link to use the same encryption (it is symmetric, unlike public-private
key cryptography). When plaintext and ciphertext may be recovered together (as a sniffer on this link could, since the message formats are a known structure, and the location of the ID and random number will be deducible), the encryption may be broken. It may not be easy, and it may not be immediate, but it is immensely easier than a brute force attempt to break the encryption. That is why I called CHAP only "somewhat" more secure. Configure PAP and CHAP To configure PAP or CHAP authentication on an interface, you must first configure PPP, then the authentication type (PAP or CHAP), and then (if you are using CHAP) the username and password. The password must not include any spaces or underscores. RouterA(config-if)#encapsulation ppp RouterA(config-if)#ppp authentication {pap | chap} RouterA(config-if)#exit RouterA(config)#username name password secret RouterA(config)#^z Notice that we had to step up from interface configuration mode to global configuration mode when it came time to enter the username and password. Also, on the second line of our little example, we used either PAP or CHAP. However, it isn't entirely an either/or proposition. You can select either or you can select both and name them in the order you wish them to be used (for instance, ppp authentication chap pap). This would try to authenticate using CHAP, and then try with PAP if CHAP failed. There is a detailed description online of more possibilities, including working with AAA and/or TACACS+, compression, etc. Use CDP The Cisco Discovery Protocol (CDP) is a proprietary protocol available for Cisco routers, switches, access servers, and bridges to help you learn what you've got at what addresses -- to discover your network's topology. It works with SNMP (Simple Network Management Protocol), using the CISCO-CDP-MIB. CDP runs over layer two, using SNAP (Subnetwork Access Protocol, an extension of Ethernet). CDP-configured devices send periodic advertisements to a multicast address. Included in each advertisement is at least one interface address where the device can receive SNMP traffic. Each advertisement also specifies a hold time for this set of information (a TTL), after which the information should be discarded. This prevents out-of-date information from remaining in the network and distorting the topological view devices may create. Note: SNMP and MIBs SNMP works with network devices which have been configured as members of a community. Membership (knowing the name) acts as a form of authentication, albeit a very weak one, since the messages are not encrypted and so can be sniffed. The community is named with a string. The default string is "public," which is well known to hackers. In response, smart network administrators have changed their community string; lazy ones use "private." SNMP is intended as a protocol to be used to manage the devices that form a network. Community members send and respond to information requests and commands (called GetRequest, GetNextRequest, GetResponse, and SetRequest) and send Traps -- alerts or alarms. Each Request, Response, or Trap is identified by the host and by the object in question, known by its MIB -- which stands for Management Information Base. MIBs are arranged hierarchically, somewhat like the DNS hierarchy, starting at a root level of organization, beneath which is the ISO (among other global organizations). MIBs represent the managed objects (which may be characteristics of a device rather than the entire device -- think "object" as in "software object") of the network. Here's a generic tutorial on SNMP.
Configure CDP Here's complete CDP command information (IOS 12.2) (note that this page is unusual for Cisco -- the main frame is extremely wide; you may want to download the .pdf version via the link in the upper right corner). CDP is enabled on a router and supports interfaces by default (it is not supported on ATM interfaces); to disable it you may use either RouterA(config)#no cdp enable or RouterA(config)#no cdp run Notice that these commands were performed in global configuration mode; to affect only a given interface (perhaps you don't want CDP running over your WAN interface), perform the commands in interface configuration mode: RouterA(config)#int s0 RouterA(config-if)#no cdp run You may set the timer (frequency of updates) and the holdtime (TTL) for CDP updates. By default, updates are sent out every CDP-enabled interface every 60 seconds, with a holdtime of 180 seconds. To modify these (again, you may do so globally or on a per-interface basis; we'll show globally), use these commands: RouterA(config)#cdp timer 90 RouterA(config)#cdp holdtime 270 Notice that both times are configured in seconds, and the holdtime is set to three times the update frequency. While that is not required, it is a reasonably good practice -- it allows a packet or two to be dropped without "flapping" your topology information. If you aren't sure what your current values are, you can discover them with our old friend the show command: RouterA#show cdp You will get a result looking something like this: Global CDP information: Sending CDP packets every 60 seconds Sending a holdtime value of 180 seconds Sending CDPv2 advertisements is enabled Notice that last item. CDP version 2 has a few more advertisements than version 1: VTP Management Domain Name, Native VLAN, and full/half-Duplex. To enable use of CDPv2 advertisements, use this command: RouterA(config)#cdp advertise-v2 To turn it off, use RouterA(config)#no cdp advertise-v2 Discovering the Topology Unfortunately, running CDP will not result in a system drawing you a network diagram, but you can still learn much about your network's topology. Use this command: RouterA#show cdp neighbors You may wish to specify a particular interface, such as show cdp neighbors e1. You will get a result something like this: RouterA#show cdp neighbors e0 Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater Device ID Local Intrfce Holdtme Capability Platform Port ID lab-7206 Eth 0 157 R 7206VXR Fas 0/0/0 lab-as5300-1 Eth 0 163 R AS5300 Fas 0 lab-as5300-2 Eth 0 159 R AS5300 Eth 0 lab-as5300-3 Eth 0 122 R AS5300 Eth 0 lab-as5300-4 Eth 0 132 R AS5300 Fas 0/0 lab-3621 Eth 0 140 R S 3631-telcoFas 0/0 008024 2758E0 Eth 0 132 T CAT3000 1/2
The Device ID is a name assigned to the host or a MAC address or a serial number for the device. The local interface shows the protocol being used on the media connecting this device to the neighbors (Ethernet in this case). Holdtime is in seconds, and the Capability column symbols are explained in the output. The Platform column tells you what type of device is connected, and Port ID tells you via which port on that device. With this information from a few devices, you could reconstruct a topology (if you couldn't find one in the dusty files, under a cubicle desk, etc.). Suppose you want more information. Add detail to the command and you get it: RouterA#show cdp neighbors detail ------------------------- Device ID: lab-7206 Entry address(es): IP address: 172.19.169.83 Platform: cisco 7206VXR, Capabilities: Router Interface: Ethernet0, Port ID (outgoing port): FastEthernet0/0/0 Holdtime : 123 sec Version : Cisco Internetwork Operating System Software IOS (tm) 5800 Software (C5800-P4-M), Version 12.1(2) Copyright (c) 1986-2002 by Cisco Systems, Inc. advertisement version: 2 Duplex: half ------------------------- Device ID: lab-as5300-1 Entry address(es): IP address: 172.19.169.87 Platform: cisco AS5300, Capabilities: Router --More-- ... and so forth. If you're concerned about the amount of traffic you're putting on your links by using CDP with your current timer and holdtime values, you can check that: RouterA#show cdp traffic Total packets output: 543, Input: 333 Hdr syntax: 0, Chksum error: 0, Encaps failed: 0 No memory: 0, Invalid: 0, Fragmented: 0 CDP version 1 advertisements output: 191, Input: 187 CDP version 2 advertisements output: 352, Input: 146 And that, briefly, is CDP -- a very useful tool, especially if you just inherited a network and have to come to understand what you have. Use ICMP The Internet Control Message Protocol, ICMP, is more -- much more -- than just ping. It's even more than ping and traceroute, although those are probably the two most common uses of ICMP. Ping, in fact, is properly an acronym, PING (though no one uses it that way anymore), for Packet InterNetwork Groper. And it really is a crude tool with which to discover a network, though it is quite useful as a diagnostic. For instance, here is what it can show me:
This little ping command shows that DNS is working (otherwise, how would this system know the address for Yahoo!'s web server?). And it not only shows that I have physical connectivity, which is what many networking people assume, but also that I have connectivity all the way up to layer 3. Ping uses IP -- if you can ping, you have IP connectivity, including knowledge of how to reach the destination. The route back is known as well. Let me repeat that last item: the route back is known as well. A successful ping is, in fact, two completely independent message flows. One is an Echo (or Echo Request, depending on your source), and the other is an Echo Reply. ICMP is described in RFC792, and updated with RFC950. If we look at the information contained in the ICMP packet, we can see a whole host of uses (pardon the pun) for this protocol.
Figure 1. ICMP Packet Before we look too hard at the first four bytes (the type, code, and checksum), the last four may seem confusing. Remember the protocol's name -- Internet Control Message Protocol. Part of its intended use is to report problems delivering traffic, so the last field identifies which piece of traffic ICMP is reporting about. Now, about a successful ping being two separate messages, each of which traveled the best route from its source to its destination (and those routes may or may not be the same): there are 26 different type codes. An Echo Request is type 0 while the Echo Reply is type 8. A type 3 is Destination Unreachable (I don't know how to get there from here), while type 4 is a source quench, which probably means the router's buffer is too full to queue this packet for its next hop. That tells you that the network has congestion at the point where the source quench originated. And so forth.
The next field, the code, may take a value from 0 through 15, and these are very informative -- we'll see them being used in Cisco's extended ping shortly. They are:
ICMP Message Type Number Meaning Subcodes
0 Network unreachable
1 Host unreachable
2 Protocol unreachable
3 Port unreachable
4 Fragmentation needed but the Do Not Fragment bit was set
5 Source route failed
6 Destination network unknown
7 Destination host unknown
8 Source host isolated (obsolete)
9 Destination network administratively prohibited
10 Destination host administratively prohibited
11 Network unreachable for this type of service
12 Host unreachable for this type of service
13 Communication administratively prohibited by filtering
14 Host precedence violation
15 Precedence cutoff in effect
For more details on the ICMP message itself, if you find the RFCs a bit thick, you can download a free TCP/IP book from IBM -- but beware, it's a very large file! I have no idea of the topology between me and the web server, though a derivative of ping known as traceroute (type field of 30) can help with that:
Traceroute sends a series of UDP packets, with limited TTLs, to an invalid port address (usually, but not always, UDP 33434). For the first hop, the TTL is 1, and so the next hop sends back that the host was unreachable (since the packet's TTL has now expired when this router decrements the TTL to 0). The next packet increments the TTL by 1 (to an initial value of 2), so the first router sends the packet on but the second router can't, so it sends another unreachable reply. The next packet increments the TTL by 1 (to an initial value of 3), so the first router sends the packet on and so does the second, but the third ... you see the pattern. The hops between the source and ultimate destination are traced out by a series of failure reports. Interestingly, from my home in the Dallas suburbs, my discovery of Yahoo!'s web server (and Yahoo! is a California company, remember?) goes through AT&T's network as far as possible, since carriers keep traffic on their own links rather than paying for transit on someone else's. However, it eventually migrates to Cable & Wireless's network, and travels to Chicago and Washington, D.C., where a reply is generated by the server at "dcx" via Sterling's network. By the way, the "request timed out" line suggests that a router has been set to not reply to a ping, but it did not simply discard the packet. That is a response to denial of service attacks which are known as "ping floods." The above, of course, is an example using the Internet. Within an intranet, however, it is just as useful. In the case of a ping, I'm fairly limited on a PC -- I can ping a host by IP address or name (which depends on being able to resolve that name, of course). Assuming, for example, that a "PC" is a Windows98 machine, try ping /? -- there are many of the same options as below available, and several that aren't. If "PC" can include UNIX boxes, they're typically at least as capable as the Cisco ping, for IP anyway. For UNIX boxes, of course, you should consult the man page. pathping is another command on a Windows (XP) system; try it -- you'll see some different results, once the statistics are computed. Note that it stops at the first null reply.
On a router running the IOS, however, while I can do the same thing, I also have more options. If I just start the ping command without specifying the destination, I get some more choices: Note that I am in privileged Exec mode to use this. RouterA# ping Protocol [ip]: Target IP address: 192.168.7.27 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.7.27, timeout is 2 seconds: !!!!! Success rate is 100 percent, round-trip min/avg/max = 1/2/4 ms While IP is the default protocol, I can ping with many others: my choices are appletalk, clns, ip, novell, apollo, vines, decnet, and xns. I can change the size of the datagram if I want to test MTU or simply load the bandwidth. I can vary the timeout if I know there is some unusual delay on a particular link, and I want to see what else is happening there. We'll return to extended commands in a moment. Sweeping the range of sizes gives me the chance to explore where I may encounter a problem with MTU. A simple change in datagram size will detect the first problem with MTU at that size, but suppose I in fact have more than one, of different sizes? Using a sweep helps detect this. And don't forget, the escape sequence used to abort this command is Ctrl-^X (hold down the control and shift keys, hit the number 6 key on the keyboard, not the number pad, and then hit X). Now, about those extended commands: if we hit "y" for "yes" at that prompt, we have more choices: RouterA#ping
Protocol [ip]: Target IP address: 192.168.15.22 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.13.5 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.21.8, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/97/132 ms Note that I was able to specify a source address for the pings (192.168.13.5) that is not the address the replies are going to (192.168.21.8). I have validated from my workstation the connectivity between two other hosts. I could have specified a Type of Service, setting the Do Not Fragment (DF) bit in the header, etc. In a similar fashion, traceroute on the router is more flexible than traceroute (or tracert) on a PC. As for ping, a PC's tracert command (traceroute in UNIX) has options similar to the Cisco tracroute. RouterA#traceroute Protocol [ip]: Target IP address: 192.168.15.22 Source address: 192.168.13.5 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 192.168.15.22 1 192.168.13.2 16 msec 16 msec 16 msec 2 192.168.15.2 28 msec 28 msec 32 msec 3 192.168.15.22 32 msec 28 msec * You should be able to see the similarities to ping in terms of options. Conclusion It seems a long stretch from just getting the software onto a router, and maybe copying in a configuration file from a TFTP server, to managing the traffic on the router with access lists, to diagnosing network problems. However, all those capabilities are needed to manage the network and help it perform its business function at a reasonable cost. With some practice, you can do this. Moreover, knowing how won't hurt you on the real exam -- your job. 7.2 Lab Abstract Do you know how to figure out a network topology without disturbing network services? Can you develop access lists to protect your network? These are the tasks for this lab scenario, but it's the overall situation presented by the author that will really get you thinking about the "real world" and not just solving networking problems in a lab environment.
7.3 Lab Scenario Introduction For these two exercises, assume the following situation. Your Uncle owns a printing/publishing-on-demand business. He recently fired his network administrator for cause (a matter of a little side business being run on your Uncle's business's servers, using his business's IP address, bandwidth, etc.). Your Uncle now realizes that the former administrator did not leave any documentation of topology, configurations, etc. Knowing only that your Uncle bought Cisco networking equipment (from a reseller who, unfortunately, is no longer in business in these rough times), you've been asked to figure out the network and protect it from connections by the former administrator or its use for the unauthorized (as well as unsavory) sideline. Exercise 1 You've walked through the two buildings where your Uncle's business operates. In Building 1, there are office cubicles, organized (more or less) by department: management, finance/accounting, and composition/document setup. All wiring was artfully laid in before the drywall was installed, so you cannot trace the cables other than to know where a given one goes into or out of the wall. You do know that there are three switches, all Catalyst 2926 (though the invoice didn't say which model), and one router, a Cisco 3725, most of whose Ethernet ports are empty. In Building 2, the printing plant, you find two more Catalyst 2926s, along with a Cisco 2611 router, which you now know Cisco no longer sells, though this one seems to work just fine. All the cables between the three devices in Building 2 are neatly tied together at the router and for the next 25 feet along the overhead rack, but they are all the same color, and they were not aligned -- you can't tell for sure which cable goes where. You have to sort that out first, then you can deal with the equally lovely cable runs to the workstations from each switch. You know there is a WAN link between Building 1 and Building 2, over a circuit provided by the phone company. You also know the link to the ISP was supposed to go from Building 1 (and that fits, since the 3725 has two serial ports connected to something). Figure out the topology without disrupting service. Exercise 1 Solution You research the routers and switches, checking the data sheets for each. Unfortunately, just as often happens in real life, as opposed to your training, the 2926s have reached their End of Life -- Cisco no longer officially supports them, even though they're doing a fine job for your Uncle's business -- and no doubt many others. (Fortunately, the 2611 will at least have sotware maintenance releases for a few more years.) You have to figure their configurations out the hard way. Since you can't disrupt service while you figure out how the routers and switches are connected, you should let the devices tell you -- use CDP. On each device, try the command show cdp neighbors (in normal mode on the switches, in privileged exec on the routers). If CDP is not enabled, use the command set cdp enable on either type of device. If you do not modify any of the defaults, in 3 minutes, at most, each device will have learned about those it is connected to. The output shows the Device ID and which port for every interface where CDP can establish a session. And, of course, you didn't forget that the protocol has to be running on both ends of the link to get information. Since you want to double-check the settings, name each port with this command and learn how those ports are configured (show cdp neighbor port 2/0 on a switch, for instance, or show cdp interface e1, for instance). "Extra Credit" -- Interpret What You Learned You learned: Building 1 Router_M is connected to Router_S via serial interface 0/1; serial 0/0 has no CDP neighbors but has a cable -- it must go out to the ISP.
Router_M is connected to Switch_1 on FastEthernet 2/0, to Switch_2 on FastEthernet 2/6, and to Switch_3 on FastEthernet 2/12. Building 2 Router_S is connected to Router_M via serial 0. Router_S is connected to Switch_1 via ethernet 0/0 and to Switch_2 via ethernet 0/1 Can you draw a network topology from this? "Extra Credit" Solution
Exercise 2 Now that you know the topology, you know that Router_M in Building 1 connects to the Internet via serial interface 0/0, and to Building 2 via serial 0/1. Router_S connects to Router_M via serial 0. You have to protect the network from any activity of the former administrator's little business (which involved a web server and FTP server for material that was offensive to most tastes), but only during this weekend. The offensive material was stored on servers in both buildings; your Uncle is adamant that no more of that "stuff" gets out from his network. Unfortunately, you know several people will be working this weekend that will need access to the Internet for their own web searches, so you can't just shut down HTTP and FTP. You also need to ensure (on a more long-term basis) that the Windows machines, which still use NetBIOS for naming (since your Uncle has not migrated to Windows 2000 completely), do not abuse the limited bandwidth between the buildings with NetBIOS traffic. In addition, you have just attended a local Cisco Users' Group meeting where the topic was protecting from the latest worms, which bring in their Trojan horse payloads on the NetBIOS port, TCP 137. To summarize: 1. Protect both routers on TCP port 137 2. Protect Router_M's Internet port from incoming HTTP (at least until the offensive web service is completely purged), and from FTP. Because you're going to need to modify the protections once the offensive web service is removed, you want to create your access lists on a TFTP server, where they can be modified, and download them. The TFTP server's address is 172.18.22.7; the user account is "ralf" with a password of "big5%foot." Write the access lists for each interface, and download them to the appropriate routers. Exercise 2 Solution Create the following access lists: For Router_M (which you believe meant "master") ip access-list extended wknd-only permit http any 172.18.0.0 0.0.255.255 est ip access-list extended wknd-only deny http any any
ip access-list extended wknd-only deny ftp any any ip access-list extended wknd-only deny telnet any any ip access-list extended wknd-only deny tcp any any eq 137 ip access-list extended wknd-only permit any any ip access-list extended perm-master-in permit http any 172.18.0.0 0.0.255.255 ip access-list extended perm-master-in permit ftp any any est ip access-list extended perm-master-in deny ftp any any ip access-list extended perm-master-in deny telnet any any ip access-list extended perm-master-in deny tcp any any eq 137 ip access-list extended perm-master-in permit any any ip access-list extended perm-master-out permit http 172.18.0.0 0.0.255.255 any ip access-list extended perm-master-out deny ftp any any ip access-list extended perm-master-out deny telnet any any ip access-list extended perm-master-out deny tcp any any eq 137 ip access-list extended perm-master-out permit any any For Router_S (which you believe meant "Slave") ip access-list extended perm-slave-out permit http 172.18.0.0 0.0.255.255 any ip access-list extended perm-slave-out deny ftp any any ip access-list extended perm-slave-out deny telnet any any ip access-list extended perm-slave-out deny tcp any any eq 137 ip access-list extended perm-slave-out permit any any On Router_M, load all three access lists: Router_M(config)# copy tftp://172.18.22.7/access-lists/wknd-only system:running-config Router_M(config)# copy tftp://172.18.22.7/access-lists/perm-master-out system:running-config Router_M(config)# copy tftp://172.18.22.7/access-lists/perm-master-in system:running-config Note: for the TFTP server, you don't need username and password. You do for FTP and rcp servers. Apply the access lists: Router_M(config)#int s0/0 Router_M(config-if)#ip access-group wknd-only in Router_M(config-if)#ip access-group perm-master-out out Router_M(config-if)#^z And don't forget to save it: Router_M#copy system:running-config nvram:startup-config [On Monday, you can replace wknd-only with perm-master-in on the incoming s0/0 interface.] On Router_S, load the permanent outgoing access list: Router_S(config)# copy tftp://172.18.22.7/access-lists/perm-slave-out system:running-config Apply it: Router_S(config)#int s0 Router_S(config-if)#ip access-group perm-master-out out Router_S(config-if)#^z And don't forget to save it, too: Router_S#copy system:running-config nvram:startup-config
8 Network Security This tutorial on network security attempts to provide the information needed to answer the questions you will encounter on the CCNA exam address: � Logging into a router in both user and privileged mode � Controlling router passwords, identification, and banner � Configuring standard and extended access lists to filter IP traffic � Monitoring and verifying selected access list operations on the router 8.1 Tutorial Introduction Preparing for the CCNA exam is sometimes like eating at one of those "all you can eat" restaurants. There is an abundance of study material to choose from, and it can be difficult to decide what you really need. If you spend your whole time in the restaurant eating fried clams, you won't get the nutrition that you needed from that meal and you'll probably end up with a stomachache. Likewise, if you spend all of your study time reading books about TCP/IP, you will not get enough information to pass the exam and you'll probably wind up with a headache. A good way to make sure that you get the nutrition that you need from eating is to create a meal plan, with all of the foods selected to give you a nutritionally balanced meal. Then eat only the foods listed in the plan, and only the amounts of each food that is specified in the plan. The same approach can be taken when getting ready to take the CCNA exam. Consider the exam objectives posted online by Cisco to be your CCNA meal plan. Study the material covered by the objectives listed. Some material is stressed more heavily than other material on the exam, and that is reflected in the objectives. Some concepts are weighted heavily on the exam, and consequently appear in the objective list frequently. Other concepts are not covered much by the exam, and they appear only once or twice in the objective list. An example of this is the Network Security section of the CCNA objectives list. Notice that there are only two objectives under this heading. This would suggest that network security is not stressed too heavily on the exam, and in fact, it is not. But, do not think that you need not study this material! You do. The point is that you need to focus your study time on the material covered by the objectives listed and not waste time with other tangential material. The CCNA objective list is perhaps not as well organized as it might be. A close examination of the list shows that some material that could be listed under the Network Security section is listed elsewhere instead. In this paper, I will try to pull this material together and give you the information that you will need to know to answer the questions you will see on the exam that relate to the following objectives: • c1) Log into a router in both user and privileged mode • c6) Control router passwords, identification, and banner • f1) Configure standard and extended access lists to filter IP traffic • f2) Monitor and verify selected access list operations on the router Keep in mind that network security is an advanced discipline and really has a career path of its own. The material presented here will help you to pass the CCNA exam, but there is certainly a smorgasbord of additional network security material available. Now, let's get on to the meat and potatoes! A very brief mention of security principles may help get us started. Much more discussion of this material is available in some of the references at the end of this paper. Accessing real or virtual consoles, in formal security terms, is a problem of authentication: determining that the purported user is actually who he or she claims to be. Most authentication systems are what security experts call two-factor, the two factors being who you are and something only you know or have. "Who you are" is your user ID, while the password is something you know. Other second factors include one-time passwords from smart token cards or password lists, or biometric identifiers such as fingerprint or retinal scanners. The general routing access lists described in this paper are means of access control: permitting or denying traffic based on certain criteria. Access control lists, in general terms, consist of a
pattern to match and an action, such as permitting flow, that takes place when the pattern is matched. A broader industry term is Access Control Lists, or ACLs. ACLs are available on both hosts and routers. A complete security solution will use them in both places, as well as host-level authentication and other security functions. The Router Console Most Cisco routers run the Cisco IOS software to perform all of their functions. The IOS interface with which you interact is called Exec or the Command Line Interpreter (CLI). This is the command interpreter that accepts your configuration commands and acts upon them. You can access the Exec command line in a number of ways: through the console port, through a modem connected to the auxiliary port, or through a virtual terminal session on one of the router's appropriately configured network interfaces. IOS Exec Modes Cisco IOS operates at different levels called Exec Modes. Each mode allows you to perform certain tasks. Once you gain access to the Exec command line, you can perform some actions on the router, such as view the version of the IOS software running on the router or look at the router's running configuration. To perform other actions, such as change the configuration of the router, you must be operating in a different Exec mode. The two Exec modes that you will be most concerned with are User Mode and Privileged Mode. User Mode is the Exec mode that you are in when first accessing the Exec command line. It allows you to use a limited subset of the IOS commands. To view the commands available to you in User Mode, simply type the following at the command prompt: Router>? When you press enter, you will see a list of the IOS commands that are available to you in User Mode. One command will be of particular interest to you. That command is enable. The enable command is used to enter the next level of IOS privilege, called Privileged Mode. In Privileged Mode, you have considerably more access to the router. You can access more system information and operating statistics and you can change the global configuration of the router. From Privileged Mode, you can configure the individual interfaces on the router as well as each of the protocols that the IOS software is configured to support. To see a list of the IOS commands available in Privileged Mode, first use the enable command to enter Privileged Mode and then enter the help command (?) as you did earlier in User Mode: Router>enable Password:******* Router#? This time when you type the question mark and press enter, you will see many more commands listed than you did when you performed this exercise in User Mode. From Privileged Mode you can enter other Exec modes, like Global Configuration Mode or Interface Configuration Mode. From a security standpoint, it is desirable to control access to the Exec command line itself, as well as to the Privileged Exec Mode. This is done in a number of ways. Notice that when you used the enable command in the example above, you were prompted for a password. The password protects access to the Privileged Mode on the router. The password for Privileged Mode is set using either the enable password command or the enable secret command. The enable secret command is used to create an encrypted password for access to Privileged Mode. The enable secret password is used by IOS versions 10.3 and above, and is preferred over the enable password password when both are configured. The enable password command is used to configure a password for access to Privileged Mode. The password is not encrypted unless you do so manually. This command is used in IOS versions earlier than 10.3 as the only method to configure a Privileged Mode password. With version 10.3 and higher of the IOS, this command will configure a password that will be used when no enable secret password has been configured. You can configure the enable password password and the enable secret password to be the same, but IOS will give you a warning when you do so. You can ignore this warning if you really want the two passwords to be the same.
Both the enable password and the enable secret commands are Privileged Mode commands. The router must be in Global Configuration Mode (accessed through Privileged Mode) for these commands to execute successfully. Of course, if no password has been previously configured, it should be no problem to get to the right Exec mode. The router's Initial Configuration Dialogue, if used, will prompt you to set up a Privileged Mode password. Once a Privileged Mode password has been configured, you will need to know what it is in order to change it to something else. Lost or forgotten passwords can be a bit of a pain for router administrators. Password recovery, though beyond the scope of this paper, is well documented elsewhere for various IOS versions and different Cisco hardware. It is well worth the effort to learn password recovery techniques for the Cisco devices that you must support. Note: Interpreting Prompts Notice that the Privileged Mode Exec prompt is a # sign. This is different from the User Mode > sign. Pay particular attention to the prompt to determine in which IOS mode you are operating. Some of the questions on the exam may be designed to catch your attention to detail in this regard. Watch out for answers that appear correct because they have the correct command syntax but are actually incorrect because the wrong Exec mode prompt is displayed. For example, the following is an invalid command line: Router>debug ip rip You cannot execute the debug ip rip command in User Mode. You must be in Privileged Mode for this command to execute successfully. The correct prompt would appear as follows: Router#debug ip rip It is easy to overlook this type of thing under the pressure of a live exam. Remember to take your time, stay calm, and read each answer carefully and you will be sure to spot these kinds of detractors. Securing Console Access Once you have controlled access to the Privileged Mode with a password, you will want to control access to the Exec command line itself. You will need to consider keeping the router in a secure location to control access to the console port itself, and then use the line con 0 command to configure the console port for a login password. Follow these steps to configure the console port to prompt for a password before allowing access to the Exec command line: Router>enable Router#config term Router(config)#line con 0 Router(config-line)#login Router(config-line)#password cisco Router(config-line)#^Z Securing Modem Access Additionally, you will want to configure a login password for access to the Exec command line through remote means. If you have a modem connected to your aux port, you will need to configure an auxiliary port password to control access to the router through that port. To do this, you must first configure the aux port using the line aux 0 command. This command is a Global Configuration Mode command that allows you to configure the first auxiliary port (port 0). Follow these steps to get to the correct mode and configure the aux port with a password: Router>enable Password:******* Router#config term ; puts you in Global Configuration Mode Router(config)#line aux 0 Router(config-line)#login ; Now in Line Configuration Mode Router(config-line)#password cisco
Router(config-line)#^Z ; saves changes, exits Config Mode Note: Do not actually set the password to "cisco" -- use a password that is more difficult to guess. Securing Telnet Access In addition to setting a password for the aux port, you will want to setup access to the Exec command line through Telnet sessions to virtual terminal lines on the router. These virtual terminal (vty) lines allow you to connect to the router through Telnet sessions to its network interfaces. The network interfaces must have the IP protocol configured to support Telnet sessions. The router must also have its vtys configured, and you must setup a vty password before the router will accept any incoming Telnet sessions. To do this, use the line vty 0 4 command as follows: Router>enable Password:******* Router#config term Router(config)#line vty 0 4 Router(config-line)#login Router(config-line)#password cisco Router(config-line)#^Z Cisco routers can accept up to 5 Telnet sessions (numbered 0 through 4) concurrently. The vtys for all of these sessions are configured with line vty 0 4 command. The 0 and the 4 in the command indicate the first and last session configured by the line vty command. You can configure each line individually by only specifying one vty number in the command. For example, to configure only the fourth vty line, use the following command: Router(config)#line vty 4 It is common practice to configure at least one vty with a different password from the others and to limit who has access to this vty password so that there will always be an available vty when needed. Router Identification In the configuration examples used so far, you will notice that the prompt always begins with the word "Router." This is the actual name of the router that we are configuring. If we want to change that name, we use the hostname command. It is a good idea to use a host name that is meaningful to anyone who needs to administer the router, but that does not give away too much information to someone who accesses the router without appropriate authority to do so. You might want the router's host name to indicate the location of the router, or the router's role in the internetwork, but try to do so using some sort of naming convention rather than stating it explicitly in the host name. For example, try the name fl3ar1 instead of the name 3rdFloorAccessRouter1. This may be considered a small point, but it is part of the overall security of the internetwork. Each small component works with each other to form the composite security architecture -- in other words, every little bit counts. To configure the host name on a router, follow these steps: Router>enable Router(config)hostname fl3ar1 Router(config)^Z fl3ar1> Banner Messages Another small component in the overall network security architecture is the router's banner. The banner is a message that the router displays whenever you attempt to access the Exec command line. It might be tempting to place a banner message that says something like "Welcome to the company's Cisco internetwork. Call the help desk at 555-1212 for support." This is not a very good banner message, from a security perspective. There have been cases where administrators have attempted to prosecute people who have accessed their internetworks illegally, only to find that the case shot down by the perpetrator's claim that the company's banner message gave them the impression that they were welcome there. A better banner message might be one that
indicates that unauthorized access will be prosecuted. Try something along the lines of the following: "You have accessed a private internetwork. Unauthorized access to this internetwork is prohibited and will be prosecuted in accordance with Title 18, U.S.C. -- if you are not explicitly authorized to access this internetwork, log off now!" To configure the router's banner, use the banner motd command. What the heck is "motd" you ask? It is short for message of the day. In this particular case, unless you change it yourself daily, it is more like the message of every day. To use this command successfully, you must specify a delimiter (of your choice) that indicates the end of your message. It is common to use the # sign as a delimiter. Here is an example: Router>enable Router#config term Router(config)#banner motd # Enter TEXT message. End with the character '#'. You have accessed a private internetwork. Unauthorized access to this internetwork is prohibited and will be prosecuted in accordance with Title 18, U.S.C. -- if you are not explicitly authorized to access this internetwork, log off now! # Router(config)#^Z Configuring a banner message like the one above will provide an effective indicator regarding who is allowed to access your internetwork to those who connect to your router either deliberately or accidentally. At this point, we have covered all of the material in the first two objectives we listed in the introduction. This material is fairly simple and straightforward. Now let's move on to material that is a bit more complex. Access Lists Password security is one level of an overall approach to securing your internetwork. Passwords are simple, but are also a weak level of security. Passwords are often easy to guess, and even the most complex of passwords can be derived given enough time. To take security to the next level, you will want to limit access to the router on a per packet basis. To accomplish this on Cisco routers, you use access lists. Access lists are not used for security alone. They also perform other useful functions on Cisco routers whenever certain traffic must be identified on a per-packet basis. Access lists are useful when you need to filter traffic off low-bandwidth links or to trigger certain events such as the initiation of a dial-up connection to another router. This paper will focus primarily on the security uses of access lists, since access lists are specified in the Network Security section of the CCNA exam objectives, although the basic principles for creating access lists are the same regardless of what you are trying to accomplish with them. An access list is a list of criteria used for identifying certain traffic, along with instructions for what action to take when this particular traffic is found. When access lists are executed, traffic is compared to certain patterns specified in the access list. When a match is found, then an action is taken as specified by the access list. The action to take is either to permit the traffic (allow the packet to pass through the router) or to deny it (drop the packet). Access lists are most often made up of a number of patterns for comparison, and packet information is compared to each one in turn until either a match is found, or the end of the list is reached. Before looking at the actual IOS syntax for creating access lists, let's examine how they work in general. Here is an example of an access list:
In the preceding table is a list of criteria against which each packet will be compared. If the information in the packet matches the criteria in the comparison, then the associated action will be taken. Using the table, if a packet contains a destination address on network X, then it will be denied (the packet will be dropped). No further comparisons will be made for this packet; it will simply be dropped because it matched the first line in the list. If the packet is NOT destined for network X, then it will be compared to the criteria specified in the next line. In this case, if the packet is not destined for network X, the router will determine if the destination address is that of host Y. If it is, then the packet will be allowed to flow through the router. Again, no more comparisons will be made. Once a packet matches a line in the access list, the corresponding action is taken, and no further comparisons are made. It is very important to remember the point above because it makes the order in which you specify criteria in your access list critical. Consider the following four hosts:
Hostname Address
Arthur network 1, host 1
Dipsy network 1, host 2
Kermit network 2, host 1
Kipper network 3, host 1
Assume that you have a router that connects network 1, network 2, and network 3, and that you are configuring an access list on that router. The access list will filter traffic based on the following criteria:
Criteria to compare Action to take
Traffic destined for network 1? Deny
Traffic destined for host Dipsy? Permit
Traffic destined for host Kipper? Permit
Traffic destined for network 3? Deny
Read the access list criteria in the table above, and pay attention to the order in which they are specified. Can traffic from network 2 or network 3 reach the host named Dipsy? The second line explicitly permits traffic destined for host Dipsy, so you might think that traffic could reach Dipsy. The fact is, though, that no traffic from networks 2 and 3 can reach the host Dipsy. Dipsy resides on network 1. Traffic destined for Dipsy will, of course, also be destined for network 1 in order to reach Dipsy. Any traffic destined for network 1, including traffic destined for Dipsy, will match line one of the access list. The action specified by line one is Deny, so the traffic will be dropped. No further comparisons will be made for these packets! The traffic destined for Dipsy will never be compared to the criteria specified in line two, because it will already have been dropped by matching line one. When creating access lists, the order in which you enter your criteria is critical to the effects of the access list. What happens when a packet does not match any of the criteria specified in an access list? That is a very good question. If a packet should make it past the last line of an access list and not
match any of the comparison criteria, the router needs to know whether to permit or deny it. The safest option, from a security perspective, is to deny it, and that is what Cisco routers will do. There is a term for this default action at the end of an access list -- "implicit deny any." It is never actually stated in the access list or printed in any configuration (hence the "implicit" in the name), but it is a part of every access list on a Cisco router. The "implicit deny any" ensures that any packet that does not match some explicitly stated access list criteria will be dropped once it passes the end of the list. It is important to remember the "implicit deny any." If it is your intention to allow any traffic that does not meet any of your stated criteria, you must add to the access list a line that explicitly permits this traffic. This line will be the last line of the access list, and will permit the traffic before it is dropped by the "implicit deny any." Types of Access Lists Access lists are protocol specific. There are access lists for many different protocols, including TCP/IP, IPX/SPX, AppleTalk, DECnet, and Banyan VINES. The CCNA exam will focus mainly on the access lists that are used to filter TCP/IP traffic, although there may also be some questions on IPX/SPX access lists as well. Standard and Extended IP access lists IP access lists fall into two categories: standard IP access lists and extended IP access lists. Standard IP access lists are able to examine the source address of an IP packet and take action based on the information found there. Extended IP access lists offer much more flexibility. They can take action based upon a number of different fields in the IP packet, including the source address, the destination address, and the port number. Access lists are identified by number. The access list number also indicates the type. Standard IP access lists, for example, are identified by a number within the range 1 to 99. Extended IP access lists are numbered from 100 to 199. This convention establishes a limit of 99 Standard IP access lists and 100 Extended IP access lists on the router. This limit can be overcome using named access lists, which I will discuss later in this paper. The access-list IOS command is used to create an access list. The syntax for a Standard IP access list is as follows: access-list number {deny|permit} source [source-wildcard] Each line you configure for a Standard IP access list takes this form. The access-list command indicates that you are creating an access list. The "number" parameter uniquely identifies the access-list on the router and indicates its type. The {deny|permit} parameter indicates the action to take when a match is found, and the "source" parameter indicates the criteria for comparison (in this case, a source IP address). The [source-wildcard] indicates a mask to apply to the source IP address in order to specify which bits in the address you care about matching. This mask, called the wildcard mask, allows you some granularity in specifying a match based on the source IP address. You can specify that you want all of the bits to match, indicating a specific host address, or you can specify that only certain bits need match, broadening the scope of your filter to a range of host addresses or subnet addresses. Wildcard masks are often confused with IP subnet masks. They are similar in function, but opposite in approach. When an IP subnet mask is "applied" to an IP address, all the bits in the address that correspond to bits in the mask containing ones are considered part of the network portion of the address, while the bits in the IP address that correspond to the bits in that mask that contain zeros are considered part of the host address. With a wildcard mask, any bit in the IP address that corresponds to a zero bit in the mask must match the bit in the access list criteria exactly. Any bit in the IP address that corresponds to a one bit in the mask will match the bit in the access list criteria, regardless of its value.
Note: Hint For each octet, the sum of the equivalent subnet and wildcard masks should be 255. For example, for the subnet mask 255.240.0.0: 255.240. 0 . 0 subnet mask + 0 . 15.255.255 wildcard mask --------------- 255.255.255.255 Here is an example to make this clear: access-list 1 permit 10.10.10.10 0.0.0.0 In this example, the source IP address is 10.10.10.10, and the wildcard mask is 0.0.0.0. This means that every bit in the mask is a zero. In this case, every bit in the source IP address of the packet being examined must match the bits in the address 10.10.10.10 in order for this line of the access list to be matched. This line effectively filters traffic from a specific host: 10.10.10.10, and allows it to pass through the router (thanks to the "permit" parameter). If I wanted to allow traffic originating from any host whose address contained 10 in the first three octets, I would use the following line: access-list 1 permit 10.10.10.0 0.0.0.255 Notice that we have changed the wildcard mask so that now the last octet contains all ones. In this case, if a packet is examined, and each of the first three octets of the source IP address contained the value 10, the packet would be permitted, regardless of the value of the last octet. This would obviously allow much more traffic to pass through the router than the first example. You may also have noticed that we have changed the "source" parameter to 10.10.10.0 -- the zero at the end is really only a placeholder at this point. Since the entire last octet of the wildcard mask is set to ones, any value in the last octet will be declared a match. It makes no difference what we set this value to in the "source" parameter, but it is conventional to set it to 0 in this case. We really don't care what the value is, and in fact the one bits of a wildcard mask are often called the "don't care" bits. Suppose that I want to deny traffic from every host on the 10.0.0.0 network. The following line would apply: note: Read the Fine Print One thing that you will notice as you look at access list lines is that it can become difficult to distinguish the IP address criteria from the wildcard mask. The numbers and the dots tend to blend together. The only thing that keeps the source/source wildcard pair 10.10.10.0 0.0.0.255 from being one long string is the missing period between the source IP address and the wildcard mask. Be careful when taking the exam that you read the lines of the access lists carefully. Make sure that you are certain what the mask really is before you select an answer to an access list question. It can be easy to think that a zero at the end of the "source" parameter is actually a zero in the first octet of the wildcard mask. This is one of those attention-to-detail issues again, but it can be a source of frustration for test takers. Remember to stay calm, take your time, and read the question and answers carefully before selecting an answer. access-list 1 deny 10.0.0.0 0.255.255.255 In this case we don't care what the host portion of the address is, so we can set those bit positions in the wildcard mask to ones. We want to exactly match the value 10 in the first octet, so we set the first octet in the wildcard mask to all zeros. Consider the following line: access-list 1 permit 0.0.0.0 255.255.255.255 Which traffic will this line permit? Examine the source/source wildcard pair. The IP address of 0.0.0.0 is really meaningless in this case, because the wildcard mask contains a one in every
position. What we are effectively specifying is that absolutely any address will match this line. Cisco has created a shortcut that you can use when you want to specify this address/wildcard pair. The shortcut is to use the any keyword. Using the shortcut we can rewrite the line like this: access-list 1 permit any This is a useful statement to put in an access list as the last line if you want to prevent traffic from being dropped by the "implicit deny any." Let's put a few lines together to make a more functional access list. Look at this example: access-list 1 deny 10.10.10.10 0.0.0.0 access-list 1 permit 10.10.10.0 0.0.0.255 access-list 1 deny 10.10.0.0 0.0.255.255 access-list 1 permit any Notice that each line above contains the same access list number (1). This indicates that each line belongs to the same access-list, and that the access list is a Standard IP access list. When applying this access list, the router will compare the IP source address in each packet to the criteria specified by the "source" parameter in each line of the access list. Comparisons will be made to each line of the access list, one line at a time, in the exact order in which they appear above, from top to bottom, until a match is made or until the "implicit deny any" is reached. In the example above, the implicit deny any will never be reached, because all traffic that does not match any earlier lines will be caught by the "permit any" in the last line of the access list. What does this access list do? First, it denies any traffic from the host with the IP address 10.10.10.10. This is accomplished with the 0.0.0.0 wildcard mask. Then it permits traffic from any host whose IP address contains the value 10 in the first three octets. All of the first three octets must contain the value 10 for this line to be considered a match, thanks to the 0.0.0.255 wildcard mask. Next, it denies any traffic from hosts whose IP addresses contain the value 10 in the first two octets. The values in the third and fourth octets will not matter, since we have a 0.0.255.255 wildcard mask. Finally, all other traffic will be permitted, thanks to the "permit any" line. Notice that as the access list is executed from top to bottom, the comparison criteria become more and more general. This is the best way to build an effective access list. Since the order in which you enter your criteria is critical, put your most specific criteria in the access list first, and then broaden your scope with each successive line. Once you have created an access list, there is no way to effectively edit it on the router, except to add additional lines to the end of the list. If this is not what you intend to do, you should copy the router configuration to a file and edit it with your favorite ASCII editor, then move it back to the router. Otherwise, you will need to completely re-write the access list from scratch to edit it. Before you begin to create an access list with a given number, or if you wish to completely re-write an existing access list, you should use the no access-list IOS command. For example, if you wish to create access list number 37, or if you wish to re-write access list 37 from scratch, you should first use the command: no access-list 37 This will make sure that any previously configured lines for access list 37 are removed from the router configuration before you enter any new lines. At this point in our discussion, it will be useful to briefly review some of the details of TCP/IP. This will not be a thorough discussion of the protocol suite, only a review of some of the points that are relevant to the topic of access lists. First, let's take a look at the IP packet format, which is illustrated in Figure 1.
Figure 1: IP packet format When considering the IP protocol, there are a few things to keep in mind. First, IP is a connectionless protocol. Second, in order for IP packets to be delivered correctly there must be a Source IP address and a Destination IP address declared within the packet. Finally, there should be some way to indicate the higher layer protocol that is to receive the IP packet's data. These objectives are accomplished by the Source IP address, Destination IP address, and Protocol field of the IP packet header. Extended IP Access Lists So far, while using Standard IP access lists, we have only been concerned with the Source IP address field of the IP packet header when making the decision to permit or deny. A quick examination of the packet format above shows that there may be much more information of interest to us that would allow for much greater flexibility in our filtering. In order for us to make use of this information, we need to use Extended IP access lists. Extended IP access lists allow us to use the other fields in the packet header to make filtering decisions. In the case of IP packets, we would be interested in the Destination IP address field as well as the contents of the Protocol field. It might be obvious why we find the Destination IP address field interesting. Just as we have been filtering packets so far based on their source, we might also want to filter them based on their destination. Why do we care what the contents of the Protocol field are? Extended IP access lists give us the ability to filter packets based on information contained in the layer 4 header as well. The contents of the Protocol field in the IP header will allow the router to determine what type of layer 4 header to expect. Different higher layer protocols within the TCP/IP suite require different information to be specified within the header at layer 4.The information that will be interesting to us when creating access lists starts with whether the protocol is connection-oriented or connectionless. Connection-oriented protocols will use TCP as the layer 4 protocol. Let's take a look at the TCP header:
Figure 2: The TCP header Some higher layer protocols within the TCP/IP suite use a connectionless layer 4 protocol called UDP. Here is the UDP header:
Figure 3: The UDP header In either case, the fields that concern us most are the Source Port number and the Destination Port number fields. Each of the many higher-layer protocols within the TCP/IP suite has a port number associated with it. This number is the mechanism that allows the transport layer to support multiple higher-layer protocols. The port number uniquely identifies the upper layer process that is the source or recipient of any given piece of data. Well-known port numbers are those numbers that are assigned by the Internet Assigned Numbers Authority (IANA), and are documented in RFC 1700. Some of the common port numbers that you may see include:
FTP TCP 21
TELNET TCP 23
SMTP TCP 25
DNS TCP 53, UDP 53
TFTP UDP 69
SNMP UDP 161
Figure 4: Some Well-Known Port numbers In order to filter IP traffic based on the higher layer protocol in use, you would specify the TCP or UDP port number associated with that protocol in your access list. Now that we have touched on the basics of ports, let's move on and examine the specific syntax of Extended IP access lists. The syntax for Extended IP access lists extends the syntax you've already learned for Standard IP access lists. Initially, the syntax statement can be quite an eyeful, but after close examination it becomes easy to decipher. There are slight variations depending on whether the protocol uses TCP or UDP, so we'll cover them each separately. First we'll cover TCP. Take a look: access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} tcp source source-wildcard [operator port [port]] destination destination-wildcard [operator port [port]] [established] [precedence precedence] [tos tos] [log] Confusing? No problem. Let's look at all of the new keywords and parameters and define them. Once you understand the purpose of each, this will no longer seem like such a mess. Keep in mind that not all of the keywords are appropriate all of the time. The lines in your actual Extended IP access lists will not get this complex very often. Here is a breakdown of the syntax statement above: access-list: The IOS access-list command indicates that you are configuring a line in a particular access list. access-list-number: The access list number uniquely identifies the access list on the router and also indicates its type.
dynamic dynamic-name [timeout minutes]: The optional keyword dynamic indicates that this access list is only valid for a limited time. The timeout parameter specifies the amount of time that an access list entry remains in a dynamic access list. Dynamic access lists are outside the scope of the CCNA exam, and consequently are outside the scope of this paper. deny|permit: Specifies the action to take if the conditions in the access list line are met. Lock and Key Though dynamic access lists are beyond the scope of this paper, here is a bit of information about them and a pointer to where you can find out more. Dynamic access lists are a key feature in what Cisco calls Lock-and-Key Security. The basic purpose of Lock-and-Key Security is to provide access to a specific source/destination host through a user authentication process. This process involves the creation of appropriate access lists dynamically, as needed, and the removal of these access lists after a predetermined period of time. Basically, this is how it works: 1. You initiate a Telnet session to the router. 2. You are authenticated. (This is a different authentication process than the simple vty password). 3. The router creates an entry in the dynamic access list. 4. You do whatever it is that you connected to the router to do and then end your session. 5. The access list entry is removed. Cool, huh? For more detailed information regarding dynamic access lists, refer to the Lock-and-Key Security section of the documentation for your version of IOS. For version 11.2, it can be found online. ( is not associated with Cisco.) tcp: Specifies the protocol to examine. In this case, TCP is specified. source: The IP address of the source station. source-wildcard: The wildcard mask to apply to the source IP address for additional filtering. operator: The operator field indicates which logical comparison you wish to make with the value for the source or destination port. Valid operators are: lt - less than gt - greater than eq - equal to neq - not equal to range - an inclusive range The range operator requires that you specify two port numbers; all port numbers between and including the values you specify will constitute a match. The position of the operator and port number(s) indicates whether the match is associated with the source or destination port. If they immediately follow the source and source-wildcard keywords, then they must match the source port. If they immediately follow the destination and destination-wildcard, they must match the destination port. port [port]: The port parameter indicates the port number that will constitute a match. In the case of a range, two port numbers must be specified -- a low and high value. The port parameter may be a number between 0 and 65535. For many of the well-known port values, this parameter may be a name instead of a number. Valid names include (but are not limited to) telnet, ftp, tftp, and domain. Finding Ports The Internet Assigned Numbers Authority (http://www.iana.org/) is the definitive source of port number assignments. The most commonly used port numbers are defined in http://www.isi.edu/in-notes/rfc1700.txt In the formal port assignment process, 0-1023 are assigned to "well known," standards-based services. 1024-2047 may be registered voluntarily by vendors who wish to avoid conflict with other server port numbers. Port numbers above 2047 usually -- but do not always -- suggest client ports.
destination: The IP address of the destination station. destination-wildcard: The wildcard mask to apply to the destination IP address for additional filtering. established: The established keyword causes a match to occur if the ACK or RST bits of the TCP segment are set. This would only occur if there has already been a session established. In the case of an initial session request, these bits would not be set. precedence: Matches the value of the Precedence field of the IP header. tos: Matches the value of the Type Of Service field of the IP header. log: Indicates that a message should be sent to the console when a match occurs. The log message will be sent to the console after the first match of this line, and then a summary message will be sent at 5-minute intervals thereafter, indicating the number of packets that have matched this line in the previous 5 minutes. Now that you know what each keyword and parameter means, I am sure that you feel relieved. Extended IP access lists are easy once you become familiar with them. Let's examine a few specific examples to help you put all this information into practice. Consider the following line: access-list 101 permit tcp any any This is perhaps the most basic form of an Extended IP access list. It is also probably useless in practice, as it allows all tcp traffic to flow through the router, but it is useful here to illustrate that the syntax can be fairly simple, depending on what you are trying to accomplish. Here is a more useful example: access-list 101 permit tcp 200.199.198.0 0.0.0.255 any eq 23 The access list line above permits telnet traffic to any destination from any host on the 200.199.198.0 network. How? Like this -- the access-list command indicates that we are configuring an access list entry. The number of this particular access list is 101, indicating that we are configuring an Extended IP access list. The action to take when a packet matches this line is to permit the traffic. The protocol we are to examine is TCP. The source IP address and wildcard mask is 200.199.198.0 0.0.0.255. This indicates that in order to match this line, the source IP address must contain 200 in the first octet, 199 in the second octet, and 198 in the third octet. We don't care what the value of the last octet is; therefore any host on the 200.199.198.0 network will match this line. Any destination IP address will match, thanks to the any keyword in the destination/destination wildcard mask position. Finally, the destination port number must equal 23, the well-known port number for the TELNET application. Here is another simple example: access-list 101 deny tcp any host 198.199.200.201 eq 21 This time, we are configuring an access list entry that denies all FTP requests headed toward the station with the IP address of 198.199.200.201. Here is a step-by-step breakdown of how it works. We start with the access-list 101 command, indicating that we are configuring an Extended IP access list line for access list number 101. The action to take on a match is to deny the traffic. The traffic can come from ANY source. The destination IP address must match the value 198.199.200.201, and the destination port number must equal 21 (the well-known port number for FTP). Notice that we used the shortcut "host 198.199.200.201" to indicate the destination host. We could also have written that using the standard destination/destination wildcard mask notation. If we had, the access list line would have looked like this: access-list 101 deny tcp any 198.199.200.201 0.0.0.0 eq 21 Let's look at one more, which will be on a single line in the actual configuration: access-list 101 permit tcp 198.199.200.201 0.0.0.0 200.201.202.203 0.0.0.0 eq 25 In the access list line above, we are permitting all SMTP traffic from one specific host to another only. The access-list 101 permit tcp portion of the line indicates an Extended IP access list line for access list number 101 that permits TCP traffic. The source host is 198.199.200.201 and the destination host is 200.201.202.203. We know that they are specific hosts because both the
source wildcard mask and the destination wildcard mask are 0.0.0.0, indicating that all four octets of the IP address must be matched in both cases. The destination port is 25, the well-known port number for SMTP. Suppose you want to create an access list to filter IP traffic based on information pertaining to a higher layer protocol that uses UDP as its transport. Do you think that the same syntax listed above will apply? Well, almost. There are a few differences. Here is the UDP syntax (again, it will appear on one line): access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} udp source source-wildcard [operator port [port]] destination destination-wildcard [operator port [port]] [precedence precedence] [tos tos] [log] What's the difference, you ask? First of all, the protocol keyword (right after the permit|deny keyword) has changed from "tcp" to "udp." Second, there is no "established" keyword. The reason is that UDP is a connectionless transport protocol, so there are no sessions to establish. Otherwise the syntax is the same as for TCP. Some common services that you will encounter that use UDP include TFTP (on port 69) and SNMP (on port 161). Here is a set of access list entries that will deny TFTP traffic but allow SNMP traffic: access-list 101 deny udp any any eq 69 access-list 101 permit udp any any eq 161 In addition to allowing you to filter traffic based on destination IP address, TCP or UDP port numbers, Extended IP access lists allow you to filter specific ICMP traffic as well. The syntax for this varies a bit from that of the TCP and UDP access lists we've covered so far. Here is the syntax statement for ICMP access list entries: access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} icmp source source-wildcard destination destination-wildcard [icmp-type [icmp-code] | icmp-message] [precedence precedence] [tos tos] [log] What's different here? A few things. First, as with the UDP syntax statement, there is no "established" keyword. This is due to the fact that ICMP is really a layer 3 protocol, where, of course, there would not be connections per se. Second, the "protocol" keyword is now "icmp." There are also some new keywords, as follows: icmp-type: Each ICMP packet has an ICMP message type associated with it. Each ICMP type has a number assigned to it. The icmp-type parameter specifies the number of the ICMP type that you wish to filter on. Values for this parameter include:
Figure 5: ICMP message types icmp-code: Some ICMP message types are further divided into ICMP codes that give further detail regarding the nature of the message. This code is a number that corresponds to the specific ICMP message. The icmp-code parameter holds the number associated with the specific ICMP message. Some examples are:
ICMP message type ICMP type
ICMP code Specific message name
Destination unreachable 3 0 Network Unreachable
3 1 Host Unreachable
3 2 Protocol Unreachable
3 3 Port Unreachable
3 4 Fragmentation needed and Don't Fragment bit set
5 2 Redirect Datagram for the network and Type of Service
5 3 Redirect Datagram for the host and Type of Service
Figure 6: Sample ICMP codes icmp message: This parameter holds the name of the ICMP message type in plain text rather than as a number. This is often much easier to remember than the number of the message type that you want to filter. Use either this parameter or the icmp-type parameter, but not both. Some valid ICMP message names include (but are not limited to): echo echo-reply destination unreachable redirect ttl exceeded port unreachable traceroute source quench Extended IP access lists that filter ICMP traffic are very common in the real world. You can almost count on a question or two on the exam covering an access list like this. Here are a few examples to look at: access list 101 deny icmp any any 8 The access list entry above is used to deny ICMP echo requests from flowing through the router. ICMP Echo Request and Echo Replies are used by the PING command. When you attempt to PING a particular host, you are actually sending an ICMP Echo Request message to that host. The PING reply that you receive from the target host is an ICMP Echo Reply message. The access list line above will prevent PING requests from travelling through the router. To prevent PING replies, use the following line: access list 101 deny icmp any any 0 Sometimes you may find that you do not wish to advertise to the outside world that you are filtering traffic from your network. In this case, you may wish to prevent the transmission of Destination Network Administratively Prohibited or Destination Host Administratively Prohibited messages through your router. You could use an Extended IP access list entry to deny these messages by specifying them by ICMP type and ICMP code, as shown below: access list 101 deny icmp any any 3 9 access list 101 deny icmp any any 3 10 In the access list entries above, we are filtering ICMP traffic based on specific message type (type 3) as well as more specific ICMP codes (codes 9 and 10). In most cases, you will not have a chart of ICMP message types and codes handy, and that copy of RFC 1700 keeps somehow getting away from your desk. You can also specify these parameters using ICMP message names instead of the numbers. Of course, this means that unless you have those memorized, you will still need a chart of some kind. You do have the ICMP message names memorized, don't you? Consider the effect of an access list that filters ICMP traffic on the traceroute command. The traceroute command uses ICMP messages to determine the intermediate hops between two stations. It starts by sending a message to the destination station with a TTL of 1. The TTL will, of course, be decremented to 0 by the next station to receive the packet. This station will send a reply to the originating station, indicating that the TTL was exceeded. The traceroute command will display the source information from this reply. Next, it will send another message with a TTL of 2. This time, the reply will come from the station that is the second hop in the path. The
traceroute command will display the source information of this station. This process continues until the messages finally reach the destination station. Sometimes you want to filter out PING replies, but allow traceroute traffic to flow through the router. That could be accomplished with access list entries like the following: access list 101 permit icmp any any traceroute access list 101 deny icmp any any echo-reply Notice that we used the ICMP message names in the above access list entries. This helps to make it very plain what the entries are intended to do. Numbered and Named Access Lists The use of access list numbers to identify access lists and also to specify the access list type can be limiting. Using access list numbers, you are limited to 99 (1 through 99) Standard IP access lists and 100 Extended IP access lists (100 through 199). Usually, this allows for enough access lists of each type to accomplish what you want to do with access lists. Occasionally though, this is not enough. To get around this limitation, Cisco IOS versions 11.2 and above allow you to use names to identify access lists. There are a few rules to follow when using names. No two access lists on any single router can have the same name, even if the access lists are of different types. Since the name only identifies the access list and does not specify its type, you must explicitly state the access list type when you create it. With named access lists, the syntax is necessarily changed, but the changes are only slight. The first line of any named IP access list must look like this: ip access-list {standard|extended} name The keyword "ip" must be added in order to indicate that the access list is an IP access list. The keyword "standard" or "extended" must also be added to indicate the type of IP access list that will be created. Normally this information would be implied by the access list number. After the first line of the access list is entered, each successive line is entered without the access-list command statement. Otherwise, the syntax remains the same as that for numbered access lists. Here is an example of a named IP access list. ip access-list extended StopGate deny tcp any any eq ftp deny udp any any eq tftp permit tcp any any eq domain deny tcp any any smtp permit tcp any any The first line in the example above declares that we are setting up an Extended IP access list named StopGate. The next five lines are the specific access list entries that contain the criteria we are using for filtering. Access Groups Now that you know how to go about creating IP access lists, the next thing you need to know is what to do with them. You know that access lists contain criteria for making comparisons and actions to take upon finding a match to those criteria. One additional thing you need to know is this: Access lists by themselves do nothing until they are applied. In order to apply an access list to some set of traffic, you must first use the IOS access-group command to assign the access list to a router interface. The access-group command specifies which access list to use to examine traffic on a router interface. It also specifies whether to apply the access list to incoming or outgoing traffic on that interface. The syntax for the command is as follows: ip access-group access-list-number {in|out} You may also use the access list name instead of number if you are using named access lists. You must execute the access-group command in Interface Configuration Mode. Here is an example: Router>enable Password:*******
Router#conf term Router(config)#access-list 101 deny icmp any any 8 Router(config)#access-list 101 permit tcp any any Router(config)#int s0 Router(config-if)#access-group 101 in Router(config-if)#^Z The steps listed above first enter Privileged Exec Mode using the enable command. Next, Global configuration mode is entered with the configure terminal command (abbreviated as conf term). Then an Extended IP access list numbered 101 is created to deny PING requests and to allow all TCP traffic. Once the access list has been created, Interface Configuration Mode is entered by using the int s0 command. The s0 portion indicates that we are configuring the first serial interface on the router. We apply the access list created earlier to this interface with the access-group 101 in command. The in parameter indicates that access list 101 will be used to filter traffic coming into the serial 0 interface. Inbound and Outbound Interfaces Many people who are learning about access lists and access groups have a question about the in|out keyword for the access-group command. What defines whether the traffic is inbound of outbound? It is simple, really, but sometimes it can be confusing. Traffic that enters the router on any interface is considered inbound traffic. Traffic that leaves the router on any interface is considered outgoing. The main thing to remember is that it is the direction of the traffic with respect to the interface and the routing process that determines whether the traffic is incoming or outgoing. I think that the source of confusion is the interface itself. When you consider the position of the interface alone with respect to the traffic, you start to have problems. Traffic from outside the router that enters the s0 interface via the V.35 cable connected to it would be considered incoming. What about traffic that came into the router through the Ethernet interface, and through the routing process it was determined that the next hop was connected to the router through the s0 interface? The traffic is routed to the s0 interface, and at that point it could be considered to be "incoming" from the point of view of the s0 interface. But this is not how the traffic would be referenced. The path of that traffic will lead it outside the router through the s0 interface, therefore it would be considered outbound traffic. Here is a drawing that should make it clear:
Interfaces may have only one incoming and one outgoing access list per protocol applied at any given time, though a single access list can be applied to multiple interfaces at the same time. Traffic Generated by the Router and Exterior Traffic One important thing to keep in mind is that access lists are used to filter traffic that comes from a source that is "exterior" to the router. In other words, only traffic that enters the router on one interface and leaves the router on another can be affected by an access list. The access list will either examine the traffic as it enters the router (an incoming access list on the entry interface) or it will examine it as it leaves the router (an outgoing access list on the exit interface). Access lists might examine the traffic both as it enters and as it exits the router, but the fact remains that the origin of the traffic was outside the router. Sometimes a router generates its own traffic, for example, routing protocol updates that the router sends to its neighbors. This traffic will not be affected by access lists on the router where the traffic originates. It can be examined and filtered by access lists applied to the interfaces of the
routers that receive the traffic, but access lists on the originating router will not prevent this traffic from being sent. Where to Filter In addition to the syntax of the access list command lines, and the logical order of each access list entry, there is another issue to contend with when using access lists. This issue is placement. Once you have identified the traffic that you want to filter, you must consider the best location to place that filter. Access lists are processor intensive for the router that executes them. You must make sure that the router you plan to use for filtering has the processor capacity to handle the increased load that the access lists will place on it. Deciding where to place your access lists will be determined in large part by the purpose of the access list. Consider this small scenario:
Let's say you simply want to prevent Host A from reaching Network C. You create a simple Standard Access list to filter traffic from Host A. Where do you place this access list? You must place it on Router 2. If you place the access list on Router 1, then Host A will not only be unable to reach Network C, but it will also be prevented from reaching Network B. This is probably not what you intended. You might place the access list on Router 2 as an outbound access list on the interface directly connected to Network C, and this would work. It might be better, however, to place the access list on Router 2 as an incoming access list on the interface directly connected to Network B. Why? This will deny the traffic before it enters Router 2. This reduces the impact of the traffic on Router 2 by dropping it before it goes through the routing process. It makes little sense in this scenario to allow the traffic to be routed only to drop it before it leaves the router. With Standard IP access lists, placement is somewhat easier to determine due to the fact that they can only filter traffic based on source address. Give your scenario a bit of thought, and it becomes easy to spot issues like those we identified in the simple example above. Standard IP access lists usually must be placed as close as possible to the destination in order to filter the traffic where it is unwanted, but allow that traffic to reach other points within the internetwork. Extended IP access lists offer greater flexibility in filtering, but this flexibility can make placement decisions less obvious. Sometimes access list placement issues become a trade off between network bandwidth and ease of administration. In general, placing Extended IP access lists close to the source of the traffic is a good idea in order to keep traffic that will ultimately be dropped from travelling too far through the internetwork and using up valuable bandwidth. This also helps to reduce the impact of ICMP messages that might get sent to the source in response to the traffic getting dropped. These messages include Host Unreachable and Network Unreachable messages. On the other hand, it can simplify administration to place access lists closer to the core of your network rather than distribute them out to the edge of the network. Locating the access lists closer to the core might enable you to consolidate them, giving you fewer lists to maintain. This becomes an even more important consideration as your internetwork grows. Access Lists' Impact on Performance As mentioned earlier in this paper, access lists can be very CPU intensive for the router that executes them. In addition, access lists have an impact on a router's switching function. Autonomous switching cannot be performed on any interface that uses Extended IP access lists.
Likewise, silicon switching cannot be performed on interfaces configured to use dynamic access lists. These issues need to be considered when you decide whether to use access lists and where to place them. Monitoring Access Lists It is often useful to examine the contents of the access lists on your router. To do this, use the IOS command show access-list. This command, by itself, will display the contents of all access lists that are configured on the router, regardless of type, name, or number. To view only IP access lists configured on the router, use the show ip access-list command. To view a specific IP access list, use the access list number with the show ip access-list command. For example, to view only the contents of access list 101, use the following command: Router#show ip access-list 101 Conclusion If you have read this entire paper and absorbed the material presented within it, you know now all that you will need to know to correctly answer the questions on Network Security that you will find on the CCNA exam. You may even feel comfortable setting up access lists on your own routers. Your comfort will increase as you use them and become more familiar with their application, their impact, and their performance. You will be asked to solve Network Security problems on the CCNA written exam. Are you ready to solve them? References Cheswick & Bellovin (1994). Firewalls and Internet Security: Foiling the Wily Hacker. Reading, MA: Addison-Wesley-Longman. Chapman & Zwicky (1996). Building Internet Firewalls. Sebastopol, CA: O'Reilly. RFC 2196. Site Security Handbook. Stevens (1994). TCP/IP Illustrated, Volume 1 The Protocols. Reading, MA: Addison-Wesley-Longman. Chappell (1999). Advanced Cisco Router Configuration. Indianapolis, Indiana: Cisco Press, Macmillan Technical Publishing. 8.2 Lab Abstract Currently your routers have no security features configured on them beyond enable secret passwords and login passwords on the vty lines for Telnet access. All of the vty lines share the same password. You decide to implement some security features. Here is what you want to do: 1. Configure each of the routers with passwords for Console access. 2. "Reserve" one vty line on each router for your own access by setting a different password on it. 3. Change the enable secret password on all the routers. 4. Configure access lists on each router to allow Telnet connections only from your workstation (IP address 172.18.56.14) 5. Configure access lists on each router to deny all ping requests sent to the routers from workstation (IP address 172.18.56.16) 6. Log any traffic that is denied by the access lists that you implement. 7. Make sure that no other network traffic is impacted by the implementation of these access lists. 8.3 Lab Scenario Introduction You are the network administrator for The Meely Meal company. Owned by Milton Meely, the company is a leading distributor of wheat germ and other grains and cereals. The company has three locations: 1. Corporate Headquarters in Albuquerque, New Mexico. 2. A packaging and distribution plant in Battle Creek, Michigan. 3. A small purchasing office in Lincoln, Nebraska.
A diagram of the network is included below. Milton has hired his son, Matt, as an intern for the summer. Matt tells you that he is thinking of getting his CCNA. He says that he plans to prepare by reading "the" book. You tell him that it might be a good idea to get some hands on experience before taking the test. Milton thinks is a great idea. Suddenly Matt is your new "assistant" and wants to have access to the company routers so he can play with them. Needless to say, you are concerned, and you want to limit the access that he has. You are willing to teach him IOS commands as long as you are standing with him while he connects to the local router through the console port, but you do not want him accessing the routers remotely while you are not around. Currently the routers have no security features configured on them beyond enable secret passwords and login passwords on the vty lines for Telnet access. All of the vty lines share the same password. Here is what you want to do: Objectives 1. Configure each of the routers with passwords for Console access. 2. "Reserve" one vty line on each router for your own access by setting a different password on it. 3. Change the enable secret password on all the routers. 4. Configure access lists on each router to allow Telnet connections only from your workstation (IP address 172.18.56.14). 5. Configure access lists on each router to deny all ping requests sent to the routers from Matt's workstation (IP address 172.18.56.16). 6. Log any traffic that is denied by the access lists that you implement. 7. Make sure that no other network traffic is impacted by the implementation of these access lists. Network Diagram
Solution 1. Login to each router and enter Privileged Exec mode. Enter Global configuration mode with the configure terminal command. Use the line con 0 command to configure the console line. Use the login and password commands to configure the console for login with a password. Here is an example using the Battle Creek router: Battle>enable
Password:******* Battle#conf term Battle(config)#line con 0 Battle(config-line)#login Battle(config-line)#password oatmeal Battle(config-line)#^Z 2. While logged into the router, enter Privileged Exec mode. Then enter Global Configuration mode. Use the line vty command to configure the virtual terminal lines. First configure lines 0 through 3 using the line vty 0 3 command. Assign a password to these four lines. Then configure the last line with a different password using the line vty 4 command. Here is an example on the Battle Creek router: Battle>enable Password:******* Battle#conf term Battle(config)#line vty 0 3 Battle(config-line)#login Battle(config-line)#password oatbran Battle(config-line)#^Z Battle#conf term Battle(config)#line vty 4 Battle(config-line)#login Battle(config-line)#password shellfish Battle(config-line)#^Z 3. Connect to the router, and enter Global Configuration mode. Use the enable secret command to change the enable secret password. Here is an example: Battle>enable Password:******* Battle#conf term Battle(config)#enable secret wheatgerm Battle(config)#^Z 4,5,6, and 7. Configure an Extended IP access list on each router that first permits the desired traffic, then denies the undesired traffic, then permits all other traffic. Make sure you end each access list entry with the log keyword. Assign the access list as an incoming filter on each of the routers' serial interfaces with the ip access-group in command. Here is an example of the procedure: Battle>enable Password:******* Battle#conf term Battle(config)#no access-list 101 Battle(config)#access-list 101 permit tcp host 172.18.56.14 ... any eq telnet log Battle(config)#access-list 101 deny tcp any any eq telnet log Battle(config)#access-list 101 deny icmp host 172.18.56.16 ... any eq echo-request log Battle(config)#access-list 101 permit ip any any Battle(config)#int s0 Battle(config-int)#ip access-group 101 in Battle(config-int)#int s1 Battle(config-int)# ip access-group 101 in Battle(config-int)#^Z The access list above does the following: • Line 1 allows Telnet connections from the host IP address of 172.18.56.14. • Line 2 drops all other Telnet traffic (Lines 1 and 2 meet lab objective #4). • Line 3 drops ping requests from the host IP address of 172.18.56.16 (lab objective #5).
• Line 4 allows all other traffic to pass (meeting objective #7). • All lines end with the log keyword (meeting objective #6). Router Configurations Corporate Router ! ! hostname Corporate ! enable password wheatgerm ! no ip name-server ! ip routing ! access-list 101 permit tcp host 172.18.56.14 any eq telnet log access-list 101 deny tcp any any eq telnet log access-list 101 deny icmp host 172.18.56.16 any eq echo-request log access-list 101 permit ip any any ! interface Ethernet 0 no shutdown description connected to Corporate LAN ip address 172.18.56.1 255.255.0.0 keepalive 10 ip access-group 101 in ! interface Serial 0 no shutdown description connected to Lincoln ip address 172.19.1.2 255.255.255.252 encapsulation ppp ! interface Serial 1 no shutdown description connected to Battle ip address 172.20.1.1 255.255.255.252 encapsulation ppp ! router rip network 172.18.0.0 network 172.19.0.0 network 172.20.0.0 no auto-summary ! ! ! line console 0 exec-timeout 0 0 password oatmeal login ! line vty 0 3 password oatbran login !
line vty 4 password shellfish login ! end Battle Creek Router ! service timestamps debug uptime service timestamps log uptime ! hostname Battle ! enable password wheatgerm ! no ip name-server ! ip subnet-zero no ip domain-lookup ip routing ! access-list 101 permit tcp host 172.18.56.14 any eq telnet log access-list 101 deny tcp any any eq telnet log access-list 101 deny icmp host 172.18.56.16 any eq echo-request log access-list 101 permit ip any any ! interface Ethernet 0 no shutdown description connected to Battle Creek LAN ip address 172.17.56.1 255.255.0.0 keepalive 10 ! interface Serial 0 no shutdown description connected to Corporate ip address 172.20.1.2 255.255.255.252 encapsulation ppp ip access-group 101 in ! interface Serial 1 no shutdown description connected to Lincoln ip address 172.21.1.2 255.255.255.252 encapsulation ppp ip access-group 101 in ! router rip network 172.17.0.0 network 172.20.0.0 network 172.21.0.0 no auto-summary ! ! ! line console 0
exec-timeout 0 0 password oatmeal login ! line vty 0 3 password oatbran login ! line vty 4 password shellfish login ! end Lincoln Router ! service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname Lincoln ! enable password wheatgerm ! no ip name-server ! ip subnet-zero no ip domain-lookup ip routing ! access-list 101 permit tcp host 172.18.56.14 any eq telnet log access-list 101 deny tcp any any eq telnet log access-list 101 deny icmp host 172.18.56.16 any eq echo-request log access-list 101 permit ip any any ! interface Ethernet 0 no shutdown description connected to Lincoln LAN ip address 172.16.56.1 255.255.0.0 keepalive 10 ! interface Serial 0 no shutdown description connected to Corporate ip address 172.19.1.1 255.255.255.252 encapsulation ppp ip access-group 101 in ! interface Serial 1 no shutdown description connected to Battle ip address 172.21.1.1 255.255.255.252 encapsulation ppp ip access-group 101 in !
router rip version 2 network 172.16.0.0 network 172.19.0.0 network 172.21.0.0 no auto-summary ! ! ! line console 0 exec-timeout 0 0 password oatmeal login ! line vty 0 3 password oatbran login ! line vty 4 password shellfish login ! end 9 Other VPNs The Other VPNs: It's Not All MPLS VPN has been something of a buzzword for a while, and the buzz just keeps getting louder. Businesses want more VPNs for more flexible work arrangements as well as to replace expensive dedicated circuits. How you can create that flexibility and the limitations that may impact those anticipated cost savings are the subjects of this Study Guide. We'll talk about the basic technologies as well as how they are implemented. The earlier versions of VPNs are created at Layer 2, while more recent ones, including IPSec, are implemented at Layer 3. Both are useful; which type you want will depend on how much you need to protect information and at what cost. Before beginning to understand VPNs, you must internalize, make part of your gut instincts, that almost everything in modern networking is a virtualization. Be sure to read the How to Study Virtual Private Networks Study Guide, which starts you down that path by outlining the steps involved in learning VPNs. For additional VPN discussion, see also "L3 VPNs" Study Guide by Galina Pildush, which concentrates on Level 3 provider-provisioned VPNs (PPVPNs), in which Internet service provider (ISP) equipment is included in VPN creation and management. 9.1 Tutorial Introduction VPNs have been something of a buzzword for a while, and the buzz just keeps getting louder. Businesses want more VPNs for more flexible work arrangements as well as to replace expensive dedicated circuits. How you can create that flexibility and the limitations that may impact those anticipated cost savings are the subjects of this Tutorial. At the same time, there's a lot of FUD (Fear, Uncertainty, and Doubt -- a.k.a. misinformation) out there regarding VPNs. When you get called on to implement them, or to lay out the case for or against them, you'd better know what you're talking about. It helps if you know some of the recent myths and scare stories, too. In this Tutorial we'll talk about the basic technologies as well as how they are implemented. The earlier versions of VPNs are created at Layer 2, while more recent ones, including IPSec, are at Layer 3. Both are useful; which type you want will depend on how
much you need to protect information and at what cost. We'll talk about the different protocols for creating Layer 2 VPNs (GRE, PPTP, L2F, and L2TP) along with the limitations of their kind of protection, and the cost -- primarily overhead and CPU processing -- that they incur. Then we'll have a look at a simple Layer 3 VPN approach, parallel to the Layer 2 version (IP-in-IP), and then spend much more time devoted to IPSec. The biggest reason for spending more time on IPSec is its much greater complexity. Note: Certification Applicability Of course, to make it personal to our readers, consider this: Cisco recently added the Cisco Certified Security Professional (CCSP) certification to its intermediate tier of certifications, joining the CCNP, CCDP, and CCIP. And, of course, there is the CCIE in Security. But there is also an increasing emphasis on security in the R&S arena of certifications. In fact, a recent article quoted a Cisco manager to the effect that the new CCNP exams will have a greater emphasis on "security, converged networks, quality of service (QoS), virtual private networks, and broadband technologies." [emphasis added] These new exams are expected to become live in July 2003, which means that security will no longer be a topic separate from R&S, but rather one embedded in it. VPNs are one facet of security and one topic you will need to understand for the CCNP. The Business Case for VPNs Before we dig into the technologies of VPNs, it is useful to understand two things. First, what, exactly, is a VPN? Fundamentally, it's a logically separated communication over a shared medium; the logical separation acts to provide a certain level of privacy. Because it is occurring over a non-private (shared) medium, the relative privacy is virtual. Second, in some cases, businesses have a stark choice: either use a private dedicated circuit or a VPN. Simply connecting via the Internet and exchanging traffic is not always legally acceptable. As part of our development of the business case for VPNs (and no networking gets done that doesn't support a business benefit; VPNs, like all other projects, must be worth it financially), we'll look quickly at two industries being forced to secure their traffic. When we're asked to deploy VPNs for a customer (internal or external, depending on the nature of our employment), very few of us ask why the customer wants them. Instead, we gather a certain set of information (often minimal, because said customer doesn't want to "waste" time on that); then we do a quick and dirty design, often with products we know off the top of our heads; and (when all else fails) we make sure to throw sufficient bandwidth at the problem. However, it can be useful to step back for a moment and obtain some information, because there are many ways to solve a given technical problem, and there are many technical problems to solve, but there is not necessarily a one-to-one mapping between these two sets. That's a technical description: plain English is that it helps to know what problem you're really trying to solve before you offer the solution. VPNs offer the opportunity to reduce costs -- maybe -- by replacing dedicated circuits by using bandwidth on shared circuits, such as Internet connections. Of course, we all know the Internet is inherently insecure (given the existing protocol suites used); VPNs are a means to use shared connectivity with some security, and Cisco, like all other networking vendors, is offering more security options in response to customers' demand for them. Of course, those same customers also want the most security bang for their limited bucks, so there are many possible ways to provide a VPN, with differing degrees of security. The methods range from dedicated hardware appliances at both ends to software-created tunnels using a network browser and SSL-enabled web server. With such a variety of technical means at your disposal, you no longer need to take a single-method approach: when you have more than a hammer in your kit, not every problem has to look like a nail. So try to define the problem to be solved, then fit the technology you offer to that. The financial justification, developed as part of the problem definition, should help you get the resources you need to do the job that the customer understands needs to be done.
Growing Business Deployment Lots of VPNs have been deployed, and it seems more and more are being deployed as time goes on. As for all other networking and communication choices, this trend is driven by a mix of monetary factors, technological choices, businesses' perceived needs, and biases in the choices made known to the decision makers. The early adopters, like early adopters in many technologies, were less cost-sensitive than newer adopters, but everyone is cost-sensitive now. With no ability to increase prices, businesses can only retain profit margins (or reduce operating losses) by trimming costs. Leased lines (Frame Relay or ATM circuits) are expensive, but reasonably private. VPNs offer an equivalent of that level of privacy without so much expense. That makes VPNs highly desirable right now, and that desirability won't necessarily go away when business does recover. Companies that have struggled to trim costs are unlikely to throw money at any problem for a good long time. We may take it as highly likely that cost-effective and economical solutions will be accepted for the foreseeable future; expensive and/or future-limiting ones will not. This Tutorial will hopefully arm you with knowledge of a range of VPN options to help you fit the solution to the client's needs and budget. The Importance of Getting It Right However, there's nothing like making a fundamental mistake -- even one that doesn't show up for a while -- to ruin your chances of repeat business. That is true even if there wasn't a real mistake, but only an occurrence perceived and reported as a mistake by the media. Just as first impressions may be in error, so may first reports -- witness the many "corrections" reported in the recent war in Iraq. So let's take a look at some deployments that encountered "technical difficulties" the designers apparently didn't anticipate; they were not the difficulties reported at the time. SQL Slammer Effects We all heard, at the time and for a while thereafter, about the remarkable speed of propagation of the SQL Slammer worm. Some of the media reports picked up on a few of the resulting problems that surprised both the media and network engineers. Let's look at these as a lesson for thinking through your VPN deployment. ATM Networks and the Microsoft Campus In this case, we're not talking about Asynchronous Transport Mode networks but automated teller machine networks -- remote bank terminals. In fact, banks, and their ATMs, use ATM for most communications. But their internal communications may be vulnerable. Bank of America (BofA) was (according to the media and newsgroup postings) the worst-affected bank, but it was by no means the only one. And, despite some early speculation by networking people, it wasn't that the ATM systems used the Internet to connect back to the bank via VPNs -- the problem was that the bank was connected to the Internet. In the case of BofA, some internal servers had not been patched when most SQL servers were. When those unpatched servers became infected, they spewed UDP traffic onto the internal network, congesting it so severely that the traffic from ATMs could not get through when it got inside the bank's network. The same problem occurred on the Microsoft campus: one or a few servers became infected, and the worm then denied service to large portions of the network. The weak point may have been as small as one unprotected server; neither BofA nor Microsoft will say. But Microsoft did admit that the infection spread through the Microsoft campus due to unprotected ports on the inter-building links. VPNs had nothing to do with either case, despite early press indications that the VPNs were carried over the Internet and dropped there; they made it just fine to the internal network, where the internal congestion was the problem. Seattle 911 Despite the early reports, the City of Seattle's emergency 911 system did not go down under the effects of SQL Slammer. But the 911 operators were forced to revert to manual methods for tracking and locating calls, because the networked system they relied on to automate the process was unreachable for the same general reasons as at BofA. Again, there was no use of VPNs; you
may assure your customers that more thorough investigations and the final troubleshooting have established that VPNs were not more vulnerable than any other traffic. But that is the real lesson: analyze the traffic path your VPN will take, and look at how isolated it is from other network traffic paths. If the traffic is important in terms of getting through as well as in terms of confidentiality, at least think about (and warn your customer about) the fact that problems with other traffic may degrade the VPN's performance even if there is nothing wrong with the VPN. You may look extra cautious (or paranoid, if you prefer). Then again, you may look like a prophet. Legal Liabilities One factor driving greater interest in VPNs is a set of new legal requirements. Among these are the Health Insurance Portability and Accountability Act (HIPAA) and the Gramm-Leach-Bliley Act (GLBA). These apply to the health care industry and the financial services industry, respectively, but many expect such standards to become more pervasive. In other words, electronic data transmissions of data deemed confidential will have to meet these, or similar, requirements. HIPAA In the past several months, much has been written and many seminars have been given concerning HIPAA. The final rule was published in the Federal Register (making it an official U.S. government regulation) effective in April of 2003. The rule states: "The purpose of this final rule is to adopt national standards for safeguards to protect the confidentiality, integrity, and availability of electronic protected health information. Currently, no standard measures exist in the health care industry that address all aspects of the security of electronic health information while it is being stored or during the exchange of that information between entities." Protected health information (often abbreviated PHI) is any health care information, including the means of payment for any health care, related to any individual. (For more detail, a good explanation is here.) Protection of this information is extended to its transmission over electronic media as well as its local storage. That means, for example, that the electronic filing of patient claims to insurance companies by the doctor's office must be protected. Any transmission of data within a hospital's intranet must be protected. Traffic that transits public networks must be protected, and that has generally been interpreted to mean encrypted and/or tunneled. The prescription drug industry has been dealing with these kinds of regulations for several years under Part 11, Code of Federal Regulations (CFR). In this case, the emphasis has been on verifiability and traceability -- i.e., data integrity -- rather more than privacy and confidentiality. An interesting article describing the security implications for businesses may be found here. The GLBA The GLBA applies similar rules to the financial services industry and anyone with whom financial organizations exchange data. Once again, personally identifiable information must be protected both in storage and in transmission. Storage is a topic for another Tutorial; in transmission often means using VPNs. Corporate Financial Disclosures Corporations and their financial data are a sensitive topic. Information must be exchanged internally, but such data must often be exchanged among multiple geographically separated locations. Especially under heightened scrutiny from regulators and the media, information cannot leak out prematurely. Such communications must be secured when they travel over shared media, especially (but not exclusively) the Internet. SOHO/Branch Offices/Extranets Businesses are increasingly decentralizing and moving to where the people are (or want to be) vs. consolidating everyone where the wiring is. External connectivity from the home office to corporate, from the branch office close to the customer to a more central location, or among partners developing a product or service jointly must be secure, especially when the network carries customer information. These connections are often VPNs.
Background Concepts Before we begin to dig into the technical details of VPNs, it's useful to understand some fundamental concepts. For instance, it's worth remembering that "If men were angels, no government would be necessary. If angels were to govern men, neither external nor internal controls on government would be necessary." [Madison 1788] We know humans are not angels, and some are even less angelic than others. Therefore, we must protect valuable information from being accessed by non-angels. That leads us to the cost-benefit problem: if we spend $100,000 to protect something worth $50,000, we would have been better off (financially) to accept the risk and even suffer the loss. Valuing the information in a network is hard, and so is valuing the information transiting in and out of that network. That determination is unlikely to be your problem except as it relates to budget. You are likely to have to provide the least expensive means to protect information in transit, and do so at a price less than the information's loss value (a figure you should be given). To assess whether we meet the cost-benefit relationship, we need to understand (and probably educate the customer at least a little concerning) some issues: virtual privacy, partner reliability, content integrity, and digital signatures. Not all of these issues will pertain to every VPN we need to construct; that's where the cost-benefit analysis becomes important. Virtual Privacy Privacy is an often-used term with a sort of vaguely understood meaning. Merriam-Webster's on-line dictionary calls it the quality or state of being apart from company or observation, or freedom from unauthorized intrusion. Note that the communication itself (if we're talking about privacy in communications) can't be observed, much less intruded upon; its very existence is hidden. In the past, this was generally achieved for data communications with leased circuits (Frame Relay or ATM VCs). Each VC is dedicated to a customer's traffic, and, in theory at least (as well as for all practical purposes), no one else knows whether any traffic is carried over the link or what that traffic might be. Of course, a dedicated circuit is not cheap, and in view of the need to reduce expenses, many dedicated circuits are being eliminated in favor of using an existing Internet connection. There are fundamentally two choices for obtaining virtual privacy over a shared medium: hiding who's talking (tunneling) to prevent interest in the conversation and/or hiding what's said (encryption). Tunnels Tunnels encapsulate information as payload to another chunk of information. This may be done at the Data Link Layer or the Network Layer. Of course, this does increase the overhead compared to the actual application data being transported, but that is usually considered a fair trade-off for virtual privacy. And bandwidth is rarely an issue in the current environment, though it may become one again when more media traffic is sent over the same links. However, the increase in overhead is a cost to be paid for virtual privacy. Note: Reversible vs. Nonreversible Encryption (Hash) This is sometimes known as two-way (or bidirectional) encryption vs. one-way (or unidirectional) encryption, although that is not strictly accurate. Reversible encryption refers to a process whereby you can perform the calculation in the opposite direction to recover the previous starting point (much like solving a = b + c for the value of c). Nonreversible encryption does not permit the recovery of input from the resulting output. As another simple comparison, you cannot recover the ingredients from a finished product, such as the egg yolk (input) from an omelet (output). To create a hash, some data of variable length is passed through a calculation; the data may or may not be concatenated with a seed value. A fixed-length portion of the calculation result is the hash. This is nonreversible in part because the entire outcome is not present, only the truncated portion (the algorithm used is also a factor in nonreversibility). In the case of MD5, only 128 bits result, regardless of the number of bits of input; with SHA-1, 160 bits of the result are retained.
Since a larger portion is retained under SHA-1, that algorithm is considered more reliable -- the SHA-1 output's value is less likely to be correct by chance with more bits exactly matched. Upon arrival at the destination, the recipient calculates the hash, using the same algorithm, data, and seed value. If the result is the same, the data is very unlikely to have been altered. The use of a seed value increases reliability as it alters the input to the actual calculation from that provided by the raw data. So long as the seed value is protected, a change by someone who interposed him- or herself into the conversation would result in a hash that did not match when checked at the destination. Content integrity is assumed to be present (strongly assumed, even, but we cannot state categorically that alteration did not occur, only that it is really, really, really unlikely). Encryption Encryption scrambles the conversation at the bit level. A sensible string of bits is converted to a gibberish string of bits; only with the appropriate key can sense be recovered. If done properly, encryption ensures that even if the existence of the conversation is known, only those who should understand what's said will be able to. Encryption has no effect on bandwidth per se, since it does not necessarily require a significant increase in overhead (as implemented -- as we shall see -- there is generally at least a little). However, the mathematical transformation from sensible bits to a gibberish that can be recovered (not a random sequence, however close to random it may appear) and the recovery from gibberish are both work for the CPU. More data to encrypt and decrypt leads to more CPU workload; the privacy gained must be worth the cost. Partner Reliability (Authentication) If you are going to share confidential information, whether across a public medium or not, you must be sure of the other party's identity before you divulge the data. When using a public medium such as the Internet, you must be able to authenticate the other party to a level appropriate to the data's sensitivity; otherwise you could put information in the wrong hands -- possibly greedy, unscrupulous hands. Included in the VPN design must be a means to be sure the information in fact goes where you intended. Content Integrity When traffic travels over circuits you can't necessarily identify, much less control (such as over the Internet), you may need to be able to reassure yourself somehow that the content was never altered between there and here. This is actually not a trivial problem; if we rely on checksums, for instance, how do we know that the checksum was not recalculated at the same time the data alteration occurred? One method is to use a hash calculated with a known seed value (hopefully, known only to the right parties). Note: Do I Have Digital Certificates Already? The public keys of several trusted third parties are stored in Web browsers. In Internet Explorer, go to Tools>Internet Options, the Content Tab, the Certificates button, and you have two tabs of stored certificates (Intermediary and Trusted Root). In Mozilla or Netscape, go to Edit>Preferences>expand Privacy & Security in the tree>select Certificates>Manage Certificates. There are four tabs to choose from; the Authorities tab will probably have the most certificates listed. Signatures (Nonrepudiation) When we want to be sure someone is the source of a document (a contract, an offer, a letter, etc.), we look for a signature. With a proper signature available, we know the origin of the document lies with that person. What's more, that person can't deny that he or she is responsible for the document -- the responsibility for it cannot be repudiated after the fact. If we have special concern, perhaps because the consequences of repudiation are especially important, we may require a notarized signature (a signature whose validity is attested to by a trusted third party).
Digital signatures provide nonrepudiation for electronically transmitted traffic. A digital signature requires the existence of a public-private key pair (see the "Do I Have Digital Certificates Already?" sidebar). A hash is made of the document to be signed; the hash is then encrypted with the sender's private key. Upon receipt, the other party decrypts the hash with the sender's public key and compares the result with a hash on the contents he or she separately computed. If the two hashes match, the recipient knows two things (with two caveats): first, that the purported sender is the real sender (because the public key decrypted the correct hash), and second, that the content was not altered (because the hashes match). The caveats are these: that the recipient has the correct public key (i.e., the public key he or she has is in fact the public key of the person he or she believes it belongs to) and that the sender's private key has not been compromised. Anyone can assert "this is my public key"; if it decrypts what I encrypt with my private key then it must be so. But that does not prove that "I" am who I say I am. Validation by a trusted third party -- an electronic notary equivalent -- who signs my public key with his or her private key, so that my public key is decrypted with his or her (well-known) public key, constitutes a digital certificate . Symmetric vs. Asymmetric Encryption (Public and Private Keys) One last sidebar, and we can (finally!) move into the actual VPN technologies. Let's discuss the concept of symmetric vs. asymmetric encryption, which helps explain the whole public-private key business. Symmetric encryption means that the same key is used to encrypt and decrypt information. The function can operate in either direction. You take the original information (called the plaintext), process it through an algorithm with a key, and receive ciphertext (apparent gibberish) as the output. You can also take the ciphertext and the same key, reverse the encryption through the algorithm, and thereby recover the original plaintext. Symmetric encryption is reversible. Note: Asymmetric encryption is not reversible. It uses two complementary keys, and it takes both to encrypt and then decrypt. If I use the first key to encrypt the information, I can only decrypt it using the second key. Likewise, if I encrypt with the second key, only the first can decrypt it. (For more on how this works, see the Securing Communications, Part 1 Study Guide at .) One key I keep to myself (my private key), and the other I make freely available to the world at large (my public key). This is safe because of the asymmetry: giving away my public key assures anyone who can decrypt something with it that the something came from me. Likewise, something encrypted by anyone with my public key can only be decrypted with my private key, and so only I can read it. Of course, public-private key security depends on the proper safeguarding of the private key. If that becomes compromised, the entire scheme based on that key pair becomes unreliable. The presence of a digital certificate to validate a digital signature is strong evidence that no one has intercepted, modified, and retransmitted this important information -- a man-in-the-middle attack. And if it seems that this has suddenly become a bit cumbersome, well, yes, setting up the full gamut of virtual privacy, authentication, integrity, and nonrepudiation takes work. But once it is set up, the CPUs do the hard work. As you no doubt have noted, there can be significant additional bandwidth overhead as well as CPU processing involved. That's why not all VPNs use this level of technology -- the information they protect is not that valuable. Of course, that's part of why you must consult with the customer to define what is being protected and from what, within what budget -- what problem you are trying to solve. Architecture Cisco separates VPNs into three broad types:
• Access VPNs • Intranet VPNs • Extranet VPNs
These architectures have many similarities, but the differences are worth noting.
Access VPNs Access VPNs assume secured connectivity for a single user at a time, connecting via shared resources, especially the Internet. These persons may be teleworkers or those from an office who are traveling. The access may be via a dial connection directly to the corporate network or to an ISP for transit to the corporate network. Internet access may, in turn, be dial-up or some form of broadband technology. In this sense, wireless access, though it has special problems with eavesdropping and unauthorized access, is the remote party's problem; the architecture assumes that connectivity begins with the VPN client. At the termination of the VPN (at corporate network entry point), the VPN terminates on a VPN Concentrator or a router; AAA may or may not be needed (though it is certainly recommended). Access to the corporate network (through the firewall) occurs after the VPN terminates and the user has passed AAA. The topology would look something like Figure 1.
Figure 1. Access VPN Architecture Intranet VPNs Intranet VPNs are those between corporate locations; these are the replacements (most often) for dedicated leased circuits such as Frame Relay. In this case, multiple users are potentially engaged in data exchange with the central network. The VPN client is more likely to be a hardware client acting as the firewall and local DHCP server as well as the local VPN termination. Connectivity is likely to be fixed (i.e., unlikely to vary, as it could with traveling individuals), and is frequently a business DSL circuit. AAA may or may not be needed in this instance; that would be a function of the corporation's security policy. It's still included in Figure 2, just in case.
Figure 2. Intranet VPN Architecture Extranet VPNs Extranet VPNs are architecturally similar to intranet VPNs, with a major caveat: the folks on the other end are not "us"; they belong to a different company, with different business imperatives. What's more, they feel the same way about us (or they ought to, anyway). In this case, we have two more or less similar networks that can trust each other to a very carefully defined degree, and these networks must communicate. AAA is definitely warranted in this case, on both sides, as shown in Figure 3.
Figure 3. Extranet VPN Architecture Special Issues with WLANs As mentioned above, wireless LANs require some special considerations when used in conjunction with a VPN. Specifically, the wireless portion of the connection (between the user and the base station) is a radio broadcast, subject to eavesdropping, monitoring, and intrusion. It is important to bear in mind that sharing the home network or airport hot spot may be others who are casually seeing what they can see. In the case of a wireless hot spot being used by a traveler, or a single user in a home office (if you're sure it really is a single user), the wireless security measures described in Wireless Tutorial should be sufficient (depending on the actual content exchanged, of course). However, bear in mind that many home networks employ wireless to facilitate connectivity through the household without running that nasty cable around and through the walls. If one system on that wireless network is compromised and, through privilege escalation or system hopping, can reach the system that connects through the VPN, the VPN may be compromised. This is an issue best covered in the corporate security policy, because the most likely offenders are those with the income to have multiple home systems using the latest and greatest technology -- in other words, executives. They are often also not technically knowledgeable, and so policies defined in advance are your defense; the problem was laid out and the reasons for
concern were explained then. This, of course, is actually a "Layer 8" problem rather than a Layer 2 or 3 problem, but it is likely to be your problem owing to the growing use of both VPNs and wireless in the home. Technologies As mentioned earlier, VPNs can be created using technologies from Layer 2 or Layer 3. Layer 2 technologies are simpler than one of the two Layer 3 technologies. The other Layer 3 approach actually uses the same underlying concept as the various Layer 2 approaches: a logical tunnel for the traffic to hide in. All the Layer 2 technologies, and the Layer 3 tunnel approach, are sometimes described as an "envelope-within-an-envelope" approach: they encapsulate the packet in a tunneling header, which is further encapsulated in the regular Layer 2 or Layer 3 header. The idea is to hide the contents at least a little, inside an extra layer of encapsulation, while preserving a distinct traffic identifier in the additional header. All the Layer 2 or Layer 3 traffic is multiplexed on the same wire but distinguished internally by the extra header. Layer 2 In classic leased circuits (which VPNs are tending to replace, so this capability is the minimum a customer requires), traffic was segregated by its virtual circuit (VC) number, among the many, many VCs multiplexed on a given pipe. That is, a Frame Relay DLCI or ATM VPI/VCI distinguished this circuit's traffic from all the other circuits' traffic.
Figure 4. Using Layer 2 Header to Distinguish Traffic In order to use shared connectivity, especially the Internet, we must have some way to likewise distinguish one particular set of traffic from the rest. Tunneling offers us this, with the additional effect of adding another layer of header to encapsulate the interesting traffic (hide it, at least a little), though at a cost of some more overhead. The amount of overhead varies from type to type of Layer 2 tunnel approach. We'll look at four types of Layer 2 tunneling: Generic Routing Encapsulation (GRE), Point-to-Point Tunneling Protocol (PPTP), Layer 2 Forwarding (L2F), and Layer 2 Tunneling Protocol (L2TP). Tunneling really offers limited protection, but sometimes that is all that is required. GRE Generic Router Encapsulation was originally described in RFC 1701, and is further described in RFC 2784. The former is informational, while the latter is standards track and simplifies the header structure considerably. GRE is intended to be more general-purpose than the specific encapsulations previously offered in other RFCs. It is not limited to carrying just IP traffic; the Layer 3 traffic type is announced in the GRE header (in the Protocol Type field, using the RFC 1700 Ethertypes (listed on page 168 of that RFC). The entire original data packet, known as the payload, is encapsulated into a GRE packet, which is then further encapsulated into another protocol (known as the delivery protocol, essentially the Layer 2 protocol) and forwarded. The resulting packet structure is shown in Figure 5 with the RFC 2784 GRE header (8 bytes) broken out.
Figure 5. GRE Encapsulation When IPv4 is the payload, the Protocol Type field must be set to 0x800. Forwarding of the decapsulated packet is based on the IPv4 destination, and the TTL in the IP header is decremented (no free rides). Depending on a firewall's implementation (i.e., whether or not it is able to look inside the layered encapsulations to the actual IP packet), it may be necessary to terminate a GRE tunnel at the firewall and create a new one (if necessary) from the firewall to the final destination. Several GRE sample configurations, most authored by Cisco's TAC, are here. GRE is used in many different topologies, while our other Layer 2 approaches are more often used with dial-up scenarios. GRE is also the basis for a number of other encapsulations, most of which are also performed at Layer 2. PPTP Point-to-Point Tunneling Protocol was developed by Microsoft for remote user tunneling, but Microsoft took a more decoupled approach than Cisco did with its Layer 2 Forwarding (our next topic). PPTP is intended to tunnel PPP through an IP network, using a GRE header. While it technically has been replaced by L2TP, there are still many installations where it is used, especially all-Microsoft networks. PPTP separates the many functions of the ISP's network access server (NAS) into two groups: one performed by the PPTP access concentrator (PAC), which handles the PPP operations, and one performed by the PPTP network server (PNS), which handles the TCP/IP operations (or, if you prefer, the PAC for Layer 2 operations and the PNS for Layer 3/4 operations). The PAC terminates the user-to-ISP PPP Link Control Protocol session, and provides any required multiprotocol routing and bridging between the NAS's interfaces. PPTP is a connection-oriented protocol, with the PAC and the PNS maintaining connection states for each attached user. There is a tunnel between the PAC and the PNS that carries session management datagrams using PPP. While many user sessions may be connected through this tunnel, there is a separate control connection operating over TCP within the tunnel to manage the user sessions' establishment, maintenance, and release as well as the tunnel's own operations. The control connection is initiated by either the PAC or the PNS (as needed) over TCP port 1723, and, of course, must be established first. The control connection is maintained by keepalives. The rest of the data through the tunnel consists of user sessions, which are IP traffic encapsulating GRE header-encapsulated PPP traffic (which probably carries IP traffic inside it).
Figure 6. PPTP Tunneled Packet PPTP obviously is rather "busy" on the NAS (creating the internal tunnel and maintaining it with keepalives), and it does add significant overhead per packet. However, it's easy for dial-up clients to use if they have a Microsoft OS -- and ease of use for the users likely to be least knowledgeable is often considered a good idea. PPTP is used by Cisco primarily on VPN Concentrators designed to handle the session management and encapsulation workload; a table of supported client and Cisco hardware/software combinations is at http://www.cisco.com/warp/public/707/cmatrix.shtml. This links to a number of PPTP configuration examples. L2F Layer 2 Forwarding was developed by Cisco, and is primarily useful for tunneling remote users into the network via an Internet connection. For new applications, it has been replaced by L2TP (our final Layer 2 approach, coming up next). The user sends an IP packet, which is then encapsulated for transport to the ISP in a lower-layer protocol (a Layer 2 protocol appropriate to
the connection type). L2F must be available as a protocol on the ISP's aggregation server, but this is not uncommon. The user is authenticated by the ISP as a subscriber or other valid user (via a hotel, for instance). The ISP's network access server (NAS) then initiates an L2F tunnel to the corporate gateway. The corporate gateway must authenticate the user as a valid account and (if valid) accept the tunnel. The corporate gateway establishes a virtual PPP connection with the user via the ISP. The user's data consists of IP packets encapsulated in PPP for the corporate connection, plus the ISP's appropriate link layer protocol. At the ISP's NAS, the user-to-ISP link layer framing is stripped off and the L2F header is applied. The tunneled data is then sent to the corporate gateway, which strips off the L2F framing and the PPP framing and then proceeds as though this were another IP packet arriving. Traffic from the corporate network to the user follows a reverse path.
Figure 7. L2F Tunnel L2F is upper-layer protocol independent; however, though it can support carriage of IPX or AppleTalk packets, those are less and less likely to be present. Usefully, though, L2F does support the use of private IP addressing nicely, since the logical connections are between the user and the corporate network. Connections between the user and the ISP, and between the ISP and the corporate gateway, are all conducted at Layer 2, based on physical addresses. One significant disadvantage is the possibility of cleartext passwords being passed between the user and the ISP. The corporate gateway can be configured to use the ISP's authentication of the user, and that authentication may or may not be encrypted, depending on the security consciousness of the particular ISP. The L2F header is the basis of the L2TP header; a breakout of the latter is shown in Figure 8, below. L2F uses UDP port 1701 to initiate its connections. While there is no handy set of links to L2F configurations, as there were for our two previous Layer 2 approaches, this link does offer a good example, along with links to other, more in-depth explanatory documents. L2TP Now we had a situation where Microsoft (leaders on the desktop) and Cisco (leaders in the network) had come out with different solutions to the problems presented by establishing a dial-up connection to a corporate network. In the interest of making things work, Cisco and Microsoft combined forces to make such tunneling more manageable; they created Layer 2 Tunneling Protocol, which is described in RFC 2661. Like PPTP, L2TP disaggregates the NAS's functions between two entities: the L2TP access concentrator (LAC), which services the media handling the user side of the traffic, and the L2TP network server (LNS), which manages sessions as the server side of the connection. Again, there is a logical tunnel between these two entities, which carries a control channel and the users' traffic. And once again, the control traffic is in-band.
Figure 8. L2TP Header Message traffic is distinguished by the Type flag in the L2TP header (0 = data traffic, 1 = control traffic). A priority bit is available among the flags. The control traffic messages must have sequence numbers for delivery assurance (connection-oriented delivery), while the user datagrams may or may not have sequence numbers (user sessions may be connectionless). The L2TP header is larger than the header used in other tunneling protocols; if the optional offset size field is used, the header will total 16 bytes. Control messages, which include those used to authenticate users as part of session setup, may contain encrypted data in order to hide user passwords (which would otherwise be transmitted in cleartext, like the other tunneling protocols described to this point). Encryption is based on a preexisting shared secret, with a Random Vector message preceding the message in question to establish an initialization vector for the encryption. Unlike the case with PPTP, in L2TP there may be multiple tunnels between the LAC and the LNS with different QoS values assigned to them. An example would be separate SVCs for each tunnel. Each tunnel may have as few as one user. Another difference from PPTP is that L2TP, like L2F, uses UDP port 1701 to initiate the session between the LAC and the LNS (vs. TCP 1723 in PPTP). The version number in the header is the distinguisher: L2F is version 1 and L2TP is version 2. Yet another improvement is that it is permissible for the peer's IP address or working UDP port to change over the lifetime of an ongoing session (such as in response to a network topology change). A process similar to that of L2F or PPTP is used to establish the user - corporate server connection. The details are described in [Kaeo 1999]. The complete L2TP packet has grown somewhat compared to our previous forms of tunneling.
Figure 9. L2TP Packet Another option is to use L2TP in conjunction with IPSec, if you feel a need for the added benefits of IPSec and L2TP (both covered later in this Tutorial) for some or all of the link. In one situation, the tunnel between the LNS and the LAC is encrypted with IPSec because the tunnel may go over WAN links you cannot otherwise protect. This is L2TP-in-IPSec; an example configuration for this may be found at http://www.cisco.com/warp/public/707/24.html. If it helps, remember that there is an IPSec connection carrying the L2TP inside it (for L2TP-in-IPSec). Alternatively, you can make the endpoints of the connection -- the two hosts actually communicating -- the peers, and use IPSec between them to protect the entire communications path. Then, in the portion of the path between them that uses L2TP, you have IPSec-in-L2TP. A detailed example of this, complete with debug files, is at http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/vpdnsol/ipsec.htm. There are variations on the tunnel endpoints vs. the IPSec endpoints; the key to terminology is really which protocol is engaged first and then carried inside the other. You may have IPSec protecting only a portion of the L2TP session (in which case you have L2TP-in-IPSec because the L2TP tunnel was created first, then encapsulated inside the IPSec SA), or you may have the IPSec SA initiated outside L2TP (in which case you have IPSec-in-L2TP because the L2TP will
be engaged later to carry the IPSec traffic). Figure 10 shows the tunnel portions of the connections.
Figure 10. L2TP-in-IPSec and IPSec-in-L2TP For another set of configuration examples, try here. You may have noticed that, as we have progressed through these different forms of tunneling (in a loose chronological order of their creation), we have seen an increased sophistication in the system used to create the tunnels with a commensurate increase in the overhead required. Layer 3 tunneling, however, breaks with that fine tradition. Layer 3+ Thinking about Layer 3 tunneling almost seems simple after the complexities that Layer 2 tunneling began to offer. A Layer 3 tunnel is often called IP-in-IP, though it is not restricted to that: it is also possible to perform IPX-in-IP or AppleTalk-in-IP tunneling, but we will limit ourselves to IP-in-IP. For other Layer 3 tunnels, check here. IP-in-IP IP-in-IP is another envelope-within-an-envelope encapsulation; the difference, of course, is that it occurs at the packet rather than the frame level of encapsulation, leaving the Layer 2 framing to be whatever it normally is. Configuration for IP-in-IP tunnels is similar to that used for GRE tunnels, using the command tunnel mode ipip instead of tunnel mode gre (which is the default tunnel mode). IP-in-IP encapsulation is used more by other vendors (such as Nortel) for provider-provisioned VPNs (PPVPNs), where the customer's traffic comes into a virtual router (VR) on a carrier's or service provider's large-capacity switch. The VR, which may be one of many for many different customers, is linked internally to an egress VR, which adds another IP header used only in the carrier's cloud. Upon egress from the cloud, the outer header is stripped off and the traffic is routed to the appropriate customer's VR on the egress switch, after which it departs for the customer's network at the new location. The capability for this kind of encapsulation is built into IPv6, where one of the option codes is "IPv6 packet," indicating that the payload consists of an IPv6 header and its associated payload. Figure 11 applies to both IPv4 and IPv6 as a visualization.
Figure 11. IP-in-IP Packet IPSec Far more frequent, in terms of customer-provisioned Layer 3 VPNs, is the use of IPSec. Some provider-provisioned VPNs may also use IPSec. You may have noticed that all of the tunneling technologies described previously have no means of assurance of the other party's identity (authentication), content integrity of passed traffic, or nonrepudiation. In fact, something not yet addressed is also absent: protection from replay of prior traffic by a malicious stranger. Replay is most significant when it involves repeating a sniffed username-password combination to gain access. It is for these protections that people are turning more and more to IPSec at Layer 3 and SSL tunneling at Layer 4+ (the reason for the plus sign will become clear later). IPSec is very much more complex than the Layer 2 encapsulations we've described up to now, and more complex than IP-in-IP tunneling; it is a set of standards for providing confidentiality and/or authentication services on IP packets. In fact, it offers much more confidentiality and assurance than both Layer 2 VPNs and the Layer 2 leased lines those replace. Capability and complexity go hand in hand, however, so we will need to spend more time and pixels on IPSec than we have the other technologies. IPSec's architecture and components are described in RFC 2401, "Security Architecture for the Internet Protocol." Three other RFCs govern the component pieces of the architecture (there are also a number of other RFCs dealing with IPSec, as well as a large number of Internet drafts on the subject):
Many of the pieces of IPSec are interrelated, so whichever we address first, there will be things that make more sense after we have covered them all. Given that, we'll cover the security association first. Security Associations (SAs) An SA is formed between two endpoints (which may be PCs, routers, etc., as long as they can operate at Layer 3 and have the appropriate software loaded) to manage their secure information exchange. SAs can be point-to-point or point-to-multipoint (as a series of PTP SAs with a common source). We will concern ourselves here with routers, VPN devices, and PIX firewalls (i.e., not with individual hosts). The SA defines which encryption and/or hash algorithms and which protocols will be applied to the packets that are defined to be of interest when those packets are transmitted between the two endpoints. The SA also establishes the keying material to be used in any encryption or keyed hash. The keys and algorithms that may be selected come from a predefined set. This set can be those keys and algorithms known to be available on each
end of the SA because they were manually configured, or it may be negotiated as part of an ISAKMP process. Either way, the SA can work with only the tools already present. On Cisco equipment, packets are defined to be of interest via the use of crypto access lists, as applied to the interface via a crypto map. Crypto access lists are used only to establish which packets are to be protected; they have nothing to do with permitting or blocking the passage of packets via an interface. Each IPSec SA is unidirectional. In order to have bidirectionally protected traffic, an SA must be established for each direction. Likewise, there is one SA per protocol (AH or ESP, which will be covered in more detail shortly). If you are using both protocols for bidirectional traffic, you need to establish a total of four SAs. An SA may be manually configured (in each direction), or the crypto map set can be configured so that an SA is created whenever the appropriate traffic needs it (as indicated by its presence and the fact that it matches the address/protocol criteria of the crypto access list). One hazard of manual SA configuration is that, if traffic arrives at the interface and matches the crypto access list's permit function (which means to apply IPSec procedures to it) and the crypto map set is manual, an SA must have already been correctly configured. If one does not already exist, the packets are discarded. Note IKE is globally enabled by default; if you do not intend to use automatic configuration for any SA that might be needed on a given router (that is, if you prefer manual configuration), you should disable IKE. Automatic SA configuration is established via the Internet Key Exchange (IKE), which we'll come back to after we finish laying some foundations. An SA is established when triggered and will automatically expire after a period of time or a given amount of traffic has passed. If a need for the SA continues beyond that point, it must be renegotiated between the peers. The SA is uniquely identified by its security parameter index (SPI, a 32-bit number) and its destination address. There may be multiple SAs for a given destination address (such as one for AH and one for ESP). If the SA is manually specified, the SPI is manually specified as well. If IKE is used to automatically configure an SA, the SPI is a pseudorandom number. You may need to send IPSec traffic to a series of peers as part of its travel to its ultimate destination. Intermediate firewalls may need to authenticate the traffic in order to pass it; an SA must be established for each of those steps. The ultimate destination becomes the innermost IPSec encapsulation, with the next previous peer's encapsulation coming "outside" of it, and so forth. The first IPSec hop will provide the outermost encapsulation. As the traffic passes each hop in turn, the encapsulation is read and verified, and the traffic is allowed to pass. In other words, you have a set of nested tunnels, with the first hop's tunnel outermost and the last hop's tunnel innermost. With that overview, let's turn to the IPSec protocols. IPSec Protocols The Authentication Header (AH) and Encapsulating Security Payload (ESP) are the two different types of IPSec protocols. AH authenticates without encrypting, while ESP encrypts and authenticates. However, ESP does not authenticate as much of the message as AH. As a result, when both aspects are needed, both AH and ESP may need to be used. In addition to the two types of protection, IPSec offers two independent modes of delivering the security service: transport mode and tunnel mode. Tunnel mode is the default between two gateways, such as a router or a Cisco PIX firewall, while connections with VPN clients must use transport mode. As a result, there are four types of service/protection possibilities:
• Transport mode with AH • Transport mode with ESP • Tunnel mode with AH • Tunnel mode with ESP
Service/protection types may be combined, as we shall see shortly.
IPSec, being a set of standards, does not require the use of any particular encryption or authentication algorithms. For authentication and data integrity verification, it currently supports the MD5 and SHA algorithms. For encryption, it supports DES and 3DES (described in more detail in the Tutorial on Securing Communications, Part 1) as well as IDEA, Blowfish, and RC4 (which are mathematically strong but less widely deployed than DES and 3DES). The delivery mode employed depends on the relationship of the two IPSec peers. In transport mode, the two peers are the source and destination hosts for the packets. In tunnel mode, each packet is encapsulated in an extra IP header. The host placing the extra header on the packet is the tunnel ingress, while the host that removes it is the tunnel egress. The difference is shown in Figure 12.
Figure 12. IPSec Transport and Tunnel Modes We'll see some detailed differences between the two modes when we look at AH and ESP individually. Authentication Header (AH) AH mode assures data integrity and authenticates the sender without encrypting any payload. This is useful in situations where the content does not necessarily need protection, but where we must be sure of the sender and that the message (nonconfidential though it may be) was not in any way corrupted. AH may also be used in situations where government restrictions forbid the use of encryption (which varies from one country to another, and does change over time; consult the proper legal counsel if you have any question concerning the legality of encryption in a specific case). AH mode authenticates the entire message, including the IP header, except for certain fields in the header that are mutable: TOS, TTL, Header Checksum, Header Offset, and Flags. These fields are subject to modification at every hop. To speed up processing, AH typically uses a keyed hash function (such as MD5 or SHA-1) rather than a digital signature. The header format is shown in Figure 13. The keyed hash function is known as a hashed message authentication code (HMAC): the message is combined with the key, and the result is hashed. The AH header is inserted between the IP header and the payload when operating in transport mode. In tunnel mode, the AH header is inserted between the new (ingress) IP header and the original one, which is now a part of the payload (so the AH header is still between the outer IP header and its payload).
Figure 13. AH Header In Figure 13, NH is the Next Header field and PL is the Payload Length field. Each of these is 8 bits. The next 16 bits are reserved for future use. SPI is the Security Parameter Index, described above. The Sequence Number field is a 32-bit monotonically increasing counter that is used for replay protection. Replay protection is optional; the sender always includes the sequence number, and the receiver may choose to process it or not. (The sequence number is initialized to 0 when an SA is established; since the first packet transmitted has a value of 1, at 232 - 1 the highest sequence number has been reached, and the SA must be reestablished to continue.) The next portion of the header, the authentication data, has a variable length. Included in the data is the integrity check value (ICV). For the ICV calculation, the mutable fields in the IP header are assumed to be 0. The ICV is the result of the keyed hash function. Cisco IOS 12.0 supports the MD5 and SHA HMACs, along with backward-compatible RFC 1828 transforms. A transform is a listing of a security protocol (AH or ESP, for instance) with its corresponding algorithm; for example, ah-md5-hmac is a transform that identifies the AH protocol paired with the MD5 HMAC, while ah-sha-hmac pairs the SHA-1 hashing algorithm with the AH protocol. A legal (but not recommended) transform is ah-rfc1828; this is an older version of the AH protocol. The AH protocol is IP protocol number 51. Encapsulating Security Payload (ESP) ESP is more complex than AH. It both encrypts and authenticates, but it authenticates less header information than does AH. Looking at Figure 14, we see a different structure. As with AH, in transport mode the ESP header is inserted after the IP header and before the payload. However, the header format is shorter (only the SPI and sequence number are included). The payload will be padded to align the upcoming fields appropriately in the 32-bit word, and we now have an ESP trailer (which contains a Pad Length field and a Next Header field) and then the ESP authentication data. The ESP Authentication Data field is optional; it is used only when an integrity check and authentication are a part of the SA initialization process. Note that the ESP header is authenticated but not encrypted. As with AH in tunnel mode, in ESP tunnel mode the original IP header is now a part of the payload.
Figure 14. ESP Format ESP uses separate transforms for authentication and encryption; these are listed in Table 1. ESP is IP protocol 50. Table 1. ESP Transforms
Encryption Authentication
esp-des esp-md5-hmac
esp-3des esp-sha-hmac
esp-rfc-1829*
* RFC 1829 is an older version of ESP that does not support the use of an authentication transform. IKE Negotiation When we accept the default of automatic configuration of the SA, IKE authenticates the peer involved in the relationship, negotiates the security policy, and manages the key exchange. In a manual configuration, these must be manually entered at each peer in advance of any traffic needing the session. IKE is derived from three protocols: ISAKMP (mentioned above), which provides the framework for both authentication and key exchange without directing how they are to be done; Oakley, which describes a series of key exchanges (known as modes) and lists the services each provides; and Secure Key Exchange Mechanism for Internet (SKEMI; this is
sometimes written as SKEME, where "for Internet" is not included). SKEMI offers the services of Oakley plus more rapid key refreshment. Negotiation occurs in two phases, sometimes called steps, and it occurs using UDP port 500. Phase 1 Phase 1 can be used in main mode, which provides identity protection, or aggressive mode when identity protection is not needed. The latter reduces the number of round trips. During phase 1, the two IPSec peers establish a secure channel through which they can communicate and authenticate themselves to each other. They negotiate a common algorithm for encryption and one for hashes, agree on an authentication method, and exchange information about a group on which to perform Diffie-Hellman key creation. Once these items are negotiated, the mutual authentication can be done. This may be accomplished via preshared keys, public key cryptography, or digital signatures. The latter two approaches require the use of digital certificates to verify the public-private key mappings. Once the Diffie-Hellman process of shared secret key creation is complete, phase 1 is also complete. Phase 2 At this point, the SAs required for data transfer are created (remember, AH and ESP each require their own SA). To make life more interesting, IPSec does not reuse the IKE shared key. The IPSec shared key may be derived by another iteration of Diffie-Hellman; it could also be obtained by "refreshing" the shared secret key from the IKE process by hashing it with nonces. The refreshment approach is faster, but less secure, since it is a derived key and so shares characteristics of the first (IKE) key. IPSec Usage IPSec is tremendously flexible. To give one example that employs nested tunnels and both AH and ESP modes, consider Figure 15. We have a total of three IPSec peers. IPSec host 1 needs only authentication between itself and IPSec host 2, but communication with IPSec host 3 requires both authentication and encryption. The solution is a nested connection pair. The original data is first encapsulated in ESP and AH headers, in order to provide both encryption and authentication, respectively. This is based on two unidirectional SAs from IPSec host 1 to IPSec host 3 (assuming traffic is really bidirectional, there is a parallel pair of SAs from IPSec host 3 to IPSec host 1). The data is then again encapsulated, this time in AH only, since for the hop to IPSec host 2, only authentication is required. Notice that the original data is not exposed, since the actual data is encrypted in the innermost IPSec transport. This sequence could be transport mode between each pair, or tunnel mode, or one of each. Assuming it is transport mode, the simpler of the two, each packet now has
• Original IP header • ESP encapsulation • AH encapsulation • Another AH encapsulation
When the packet arrives at IPSec host 2, it is authenticated and the information necessary for the SA between IPSec host 1 and IPSec host 2 is discarded. The packet is routed to the egress interface, where it is checked against any access lists present; there need not be a crypto access list match at this point, since we are not using an IPSec connection between 2 and 3 (there may be a crypto access list that is applied to this interface, but this packet need not be permitted -- given IPSec treatment -- under it). The connection that matters now is IPSec host 1 to IPSec host 3. Host 2 has done its job.
Figure 15. IPSec Nested Tunnels This is a simplistic example, but you can see the amount of overhead and processor power potentially required when implementing IPSec. It will be important to construct your crypto access lists and maps to burden your routers only where and when necessary. SSL VPNs After seeing the many capabilities and possibilities of IPSec, it's not surprising that some people have looked for a simpler solution, but one that retains the possibility of authentication (especially mutual authentication) and encryption. The solution is to be found higher up the stack, between Layer 4 and the upper (application-specific) layers. That solution uses the Secure Sockets Layer protocol (SSL) or Transport Layer Security (TLS). Secure Sockets Layer and Transport Layer Security are similar approaches to securing the traffic flow of an application via its flow at Layer 4 and above. In both cases, the two connection endpoints are authenticated, and the protection available is confidentiality and data integrity between two applications (but realize that is not necessarily between two specific human users). SSL is a bit older, and probably somewhat more familiar, so we will address it first. TLS is (essentially) a new, improved SSL. SSL SSL was developed by Netscape to facilitate secure communications over the Internet (something in which they obviously had a substantial interest). SSL "interposes" a layer between the Application Layer protocol (such as HTTP, LDAP, or IMAP) and the transport protocol (typically TCP). This layer is called a Secure Sockets Layer. A socket is one endpoint of a
communication between two hosts. More specifically, it is an endpoint that uniquely defines one of (potentially) many communications between a given pair of hosts. The easy view of this is that it is the unique combination of IP address and port for a given communication. For a more detailed view, see the Tutorial Securing Communications, Part 2.
Figure 16. The Secure Sockets Layer SSL uses the TCP/IP stack on behalf of the application, allowing the SSL server to authenticate itself to the client, the SSL client to authenticate itself to the server, and both to establish an encrypted connection. Note the order of these statements: the server first authenticates itself to the client, which then authenticates itself to the server. Together, they then create an encrypted session. The client -- presumably a user -- does not offer its credentials up to any server that asks until the server has established its bona fides. Data integrity is established by including a MAC with every transmission. The MAC depends not only on the content of the message unit, but also on a portion of the shared secret key that the two hosts jointly develop. Internally, SSL operates at two layers: a handshake layer and a record layer. These layers use a number of protocols, but the three most important are those used to establish a secure session (the handshake protocol), communicate during the session (the record protocol), and manage the session (the alert protocol). The handshake protocol, used to establish the session, begins with the client, typically by clicking on a link that says something like, "Sign in using our secure server."
Figure 17. Initiating the SSL Handshake The client's message includes the current time, the set of cryptographic options it supports, compression methods it supports, and a random value. The server replies with a hello message containing the current time, its cipher suite, its compression methods, and its own random number. The server then sends additional messages containing its certificate (for authentication, if that will be required), a server key exchange message if the certificate is for signing only, and a certificate request if it wishes the client to authenticate itself back to the server. The client replies with its certificate or a statement that it has none, a message indicating it has verified the server's certificate (assuming that to be so), and a client key exchange message if the server sent a server key exchange message. Note: if the server requires a client's certificate and the client sends a reply that it has none, the handshake fails and the session is terminated. The key exchange messages will be based on a public key algorithm determined to be usable by both (as a result of the prior messages). This finishes the negotiation between the two hosts to establish their identities and common ground for secure communications. Both the server's
authentication to the client and the client's authentication to the server (if required) are based on public-private key pairs. The certificate authentication includes checking the domain name in the certificate against the source of the traffic as a protection against man-in-the-middle attacks. During the negotiation, validity of the certificate is checked. If there is a problem, the client is given the option to proceed anyway.
Figure 19. Client Option to Install Invalid Certificate Next, the client sends a change cipher spec message to provide input to actually generate the shared secret (the symmetric key to be used by both for encrypting data). This is not a part of the handshake protocol per se; rather, it is managed by a separate change cipher spec protocol operating at the handshake layer. The server replies with its own change cipher spec message as its input for generating the shared secret. Both hosts are now able to encrypt message traffic with a key known to both but not itself exchanged over any medium, and they are also able to generate and calculate MACs (notice that these are Message Authentication Codes, but not hashed MACs) for integrity verification. The handshake process is now complete. The alert protocol operates at the record layer, the same layer in which the data exchange actually occurs. It is used to terminate a failed session or to transmit a warning message (such as an error detection). The data exchange is managed by the SSL record protocol. It typically encrypts the data and generates a MAC for integrity verification. SSL operates through TCP port 443 instead of TCP port 80. On a Web browser, the URL will denote Secure HTTP (https://...) instead of HTTP, and a secure session indicator will be present (such as a padlock icon in the browser's lower right corner). SSL may be used with a number of cipher suites; key exchanges are handled via the RSA key exchange algorithm:
• 3DES (168-bit) with SHA-1 MAC • RC-4 (128-bit) with MD5 MAC • RC-2 (128-bit) with MD5 MAC (RC-2 was used with SSL 2.0, but not 3.0) • DES (56-bit) with SHA-1 MAC (SSL 2.0 used MD5 with DES) • No encryption, MD5 MAC only (used when the server and client have no encryption
algorithms in common; very weak security) The most recent version of SSL was 3.0, as of 1996. Version 3.1 was offered by Netscape to the IETF to become Transport Layer Security (TLS). A version known as Fortezza is used by the U.S. government for managing sensitive but not classified information. Fortezza uses the Key Exchange Algorithm (KEA) instead of the RSA algorithm, and it adds support for the SKIPJACK 80-bit encryption algorithm. TLS RFC 2246 governs TLS. It is intended to be an Internet standard form of SSL. TLS also has a handshake and a record protocol, but no alert protocol (the function is performed by an alert protocol client within the record protocol). The record protocol is layered directly above the reliable transport protocol (normally TCP), and its operation ensures both confidentiality (through encryption) and message integrity (via a MAC). The handshake protocol operates independently above the record protocol and below the application; it ensures authentication. As with SSL, the record protocol may operate without encryption, using only content verification through the MAC. Although TLS 1.0 was based on SSL 3.0, they interoperate only to a limited extent. As in SSL, the client initiates the connection, specifying through its version number whether it is using SSL (3, 0) or TLS (3, 1). Once again TCP port 443 is used, but TLS also supports UDP datagrams (which use UDP port 443 initially). The server replies with its capability and the handshake proceeds in the same fashion as in SSL. RFC 2246 also offers a so-called "backdown" capability in which TLS can revert to SSL 3.0 capability. Data compression, encryption, and content verification all operate in a similar fashion to SSL. TLS does support Diffie-Hellman key exchange as well as RSA generation of the shared secret key. Cisco supports SSL and TLS much more extensively than SSH. The Content Server line of products (CSS 11000 series), the Secure Content Accelerator, the Cisco Cache Engine, the BBSM server, the LocalDirector product, the CiscoSecure ACS, and so on all provide SSL functionality. Specific characteristics depend on the hardware-software combination employed. For a customer's VPN deployment, some people are simply setting up an SSL- or TLS-enabled server as the access to their network, and remote users connect via that server. Cost considerations as well as complexity apply here; purchasing a certificate for the server is relatively inexpensive (starting at approximately $150 U.S. per server certificate per year; there are discounts for a multiyear purchase). A recent article compared the total costs of IPSec vs.
SSL VPNs; you may find it useful to review. The short answer is that IPSec may be somewhat more secure (the article states that it is, but much depends on the IPSec implementation -- remember, encryption is not required, and DES is not considered that strong), but SSL is more economical to deploy and maintain. SSL VPN support will be introduced in the second half of 2003 via the VPN 3000 Concentrator series. Deployment VPNs are deployed in conjunction with a number of devices, not all of which are capable of using the same approaches. The following section summarizes the devices and the types of VPNs that can be used with them. The purpose here is to assist you when part of the goal is to use already existing equipment as much as possible. Routers and NASs Cisco routers are able to form VPNs with both Layer 2 and Layer 3 technologies. These use both tunnels and (with IPSec) encrypted data streams. Routers are normally used as the tunnel ingress/egress point. When routers are the IPSec gateway (vs. a transit hop), IPSec tunnel mode is used. A NAS typically terminates a tunnel from an incoming dial connection; it need not terminate all tunnels (i.e., there may be a second tunnel inside). NASs also do not include IPSec support. As this is written, neither routers nor NASs support SSL VPN tunnels (except as transit hops, of course). PIX The Cisco PIX firewall series of appliances generally are used more with IPSec tunnels, though they can serve as the termination point for transport mode when the other endpoint is a VPN client. Layer 2 tunnels are not applicable to the PIX, as it works with information further inside the packet's encapsulation -- Layer 3 and higher headers. VPN 3000 Concentrator VPN Concentrators actually come in two series, the 3000 and 5000. The 5000 series has gone into end of life, but hardware may still be found in place (as well as at online auction sites and gray market/liquidators). Models range from the 3005, with T1/E1 access and up to 100 simultaneous sessions, to the 3060, with fractional to full T3/E3 support and up to 5,000 simultaneous sessions, and the 3080, which supports up to 10,000 simultaneous sessions. The Concentrator serves as the termination point for the incoming VPN, transferring the traffic on into the intranet. Also, though it is called the Cisco 7100 VPN Router (models 7120 and 7140), this device is listed in the product literature as a VPN hardware device. Throughput runs up to 3000 tunnels of 3DES IPSec encryption at 140 Mbps total. VPN Clients VPN clients come in two flavors: hardware and software. The VPN 3002 hardware client is a device intended to act more as a gateway to the outside for clients (workstations, etc.) behind it. It can act as a DHCP server to clients behind it as well as accepting an external address from an outside server for its egress; supports PAT; supports H.323 for NetMeeting, etc.; and (of course) is client OS agnostic (Windows, Macintosh, Linux, Solaris, etc.). It is well suited to the small office/branch office environment. Like the VPN Concentrator (and every other piece of Cisco hardware), the hardware VPN client has an associated software package. However, when most people think of a software VPN client, they're thinking more along the lines of the Cisco VPN client, which is compatible (in terms of setting up secured connections) with the VPN 3000 series Concentrators, Cisco routers running IOS 12.2(8)T and later, and the Cisco PIX Firewall software version 6.0 and later. The VPN client is compatible with many OSs: Windows 9x and NT (NT 4.0, 2000, XP), Linux (Intel), Solaris (UltraSparc 32- and 64-bit), and Mac OS X 10.1 and 10.2 (Jaguar). For situations with many users, the client can be preconfigured to simplify rollout, with policies and configurations pushed from the gateway to the client. Using the software client obviously forces the encryption and other VPN processing onto the host's CPU, so it is
worth considering the processor speed and memory available if this choice seems useful (as is often the case with traveling users). Port and Protocol Summary Now that we've covered which devices can be involved in which types of VPNs, it's worth remembering that many VPNs cross intervening routers with access lists. Especially with IPSec, assuming you use ipsec-isakmp rather than manual keys, you must allow traffic on the appropriate ports to pass through the intervening routers. Table 2. Ports and Protocols to Remember
VPN IP Protocol # Protocol Port
GRE Not used Not used
PPTP TCP 1723
L2F UDP 1701
L2TP UDP 1701
IKE UDP 500
ESP 50 TCP
AH 51 TCP
Conclusion VPNs are a growing form of networking that involves special problems. They are not necessarily a low-cost replacement for expensive leased circuits; depending on the form of VPN and the degree of protection the data requires, implementation may involve significant data overhead and complex configurations. At the same time, due to recent changes in U.S. law and user demands for privacy protection, the old plain vanilla tunnel or leased circuit may no longer be sufficient. With so many possible means of implementation, it pays to determine exactly what problem is to be solved for the customer and what that solution is allowed to cost. It is likely that compromises between what the customer would like to have and what he or she is willing to pay for will be necessary. Flexibility on your part in solving this dual problem will go a long way toward getting the job done. And, of course, Cisco wants you to know the many ways a VPN can be created when you obtain their certification as someone knowledgeable about networking. That will hold true at the professional level (CCNP, CCDP, CCSP) as well as the Internetworking Expert (CCIE) level, in both Routing and Switching and in Security. The accompanying Lab Scenarios will offer you a chance to decide which kind of VPN is appropriate to some different situations. We encourage you to design and build as many VPNs as you can in a lab environment and examine the traffic and statistics. Reading about VPNs is all well and good, but there's nothing like seeing the connection passing traffic to know you can make it work. References [Anderson 2001] Anderson, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems. John Wiley & Sons, 2001. (See especially Chapters 5 and 20.) [Cisco 1999] Cisco Systems, Inc. Cisco IOS 12.0 Network Security. Cisco Press, 1999. [Kaeo 1999] Kaeo, Merike. Designing Network Security. Cisco Press, 1999. [Kahn 1996] Kahn, David. The Codebreakers, 2nd ed. Scribner, 1996. [Knuth 1998] Knuth, Donald. The Art of Computer Programming, Volume 2: Seminumerical Algorithms. Addison-Wesley, 1998.
[Madison 1788] Madison, James 1788. Federalist No. 51. http://www.thirteen.org/federalist/paper51.html [Schneier 2000] Schneier, Bruce. Secrets and Lies: Digital Security in a Networked World. John Wiley & Sons, 2000. (See especially Chapters 6 and 7.) [Schneier 1995] Schneier, Bruce. Applied Cryptography. John Wiley & Sons, 1995. (A good reference that does get substantially mathematical.) [Smith 1997] Smith, Richard. Internet Cryptography. Addison-Wesley 1997. (A good, nonmathematical description of key and algorithm strength, along with a great deal of practical implementation information.) [Wenstrom 2001] Wenstrom, Michael. Managing Cisco Network Security. Cisco Press, 2001. 9.2 Lab Abstract This lab exercise provides practice using VPNs by presenting two design challenges for a fictional medical center. The first design challenge is to define the VPNs needed by the new surgical center. The second design challenge is to provide the surgical center doctors with the ability to access their office files from home during evenings and weekends. 9.3 Lab Scenario Introduction For practice in using VPNs, let's look at a couple of examples from the completely fictitious Barfield Surgical Centers, Inc. (BSC). This pair of scenarios is built around adding VPNs, but as part of a larger picture of networking for BSC. BSC operates outpatient and short-stay surgical centers, usually in suburban areas. This lucrative portion of the medical market is not subject to the exploding costs of trauma treatment (legal as well as medical costs), and the supply of patients is steadily growing as the Baby Boom generation ages and tries to reverse decades of sloth and indolence with ill-advised or non-advised exercise programs. Orthopedics is a major part of BSC's practice, along with cosmetic enhancements and dermatology (a specialty whose patients are rarely cured, and so keep coming back). BSC is opening a new surgical center, along with a collocated (on the same campus) set of doctors' offices in the Barfield Clinic. Among other amenities, they will provide Internet connectivity for those offices, as well as for their own administrative purposes. Being moderately IT-aware, they are already planning to be dual-homed via two separate ISPs (using separate perimeter routers, labeled PR in the figures below). They have also entered into a contract with an insurance processing firm (Medical Processors, Inc.), which serves as a "front end" to the various health insurance programs; BSC and other medical practices thus have only one link for the medical administrators to contact, rather than having to connect to all the various insurance companies. BSC intends to run a paperless record and administrative system (at least, as paperless as possible). Medical Processors has a reputation for having installed secure connections before this was required. Finally, reaching the customers -- patients -- and convincing them to use BSC rather than other competing medical facilities for these elective procedures requires a marketing campaign, so BSC has engaged Majjic Marketing LLC to develop and run BSC's advertising and community outreach program. Majjic Marketing connects to the Internet using a Cisco 1721 router over an ADSL link. They'd like to upgrade that, as their business is growing and the connection is quite busy, but they think it will be next year before they can afford to upgrade to a fractional T1 and a more capable router. Here is the topology of their connections:
Figure 1. BSC's Connectivity Scenario 1 Define the VPNs BSC needs -- with whom and with what degree of confidentiality, authentication, integrity, and nonrepudiation. If IPSec is needed, define the transform set to be used and whether or not to employ IKE or manual configuration. Where IPSec is not needed, choose and justify the technology to be used. Considerations for the choices to be made have been embedded in the previous description. Scenario 1 Solution To open the facility, BSC needs to have confidential connectivity between itself and Majjic Marketing, and between itself and Medical Processors. The degree of protection needed for these two connections is different, however. Majjic Marketing BSC and Majjic Marketing must be able to exchange documents and proposed advertising, including graphics files, but this is a routine business information exchange. There is no special degree of confidentiality required, though it would be useful to be reasonably sure that the other party is who it says it is. However, Majjic Marketing accesses the Internet with a smaller router with limited CPU capability. Although the 1721 may have IPSec capability (depending on the software package, RAM, etc., as the router is currently configured), that is not really needed here, and the 1721, as currently configured, seems to be somewhat stressed (though you are not in a position to judge if that is a bandwidth or CPU issue). Running IPSec, even just for Authentication Header, would further stress this little router. Document exchange is the major need for confidentiality here, so there are alternatives without going to the CPU load of IPSec:
1. Use e-mail attachments when files are small enough; the e-mail may be signed (for authentication) with PGP.
2. Documents too large to attach to e-mails may be exchanged via FTP, using passworded accounts on either end.
3. A tunnel may be established using PPP with CHAP over L2TP between BSC (PR1 and PR2) and Majjic Marketing (the 1721).
4. A GRE tunnel may be established between the two routers (PR1 and PR2 at BSC, and the 1721 at Majjic Marketing).
Note that two of the four solutions here do not require VPNs. Part of being a successful network engineer in business terms (that is, providing a networking solution that makes the best business problem-solving sense) is knowing when the latest technology is not required. If you, or BSC's management, do prefer a VPN, consider that you are trying to avoid workload at Majjic's end of the connection (and this may enable BSC to hint at Majjic about upgrading that 1721 sooner rather than later). A GRE tunnel is simpler, in terms of header size (8 bytes for GRE vs. 16 bytes for L2TP), for the 1721 to process; tunnel destination specification should ensure traffic flow between the two endpoints. When Majjic Marketing upgrades its connectivity (if it does; you noticed that they have not actually committed to that), you can consider using IPSec with AH to offer other-party authentication assurance.
Medical Processors This situation is different: HIPAA requires protection of protected health information (PHI) in transit, and that means encryption when the transit travels over public networks such as the Internet. Since Medical Processors works with many medical offices and insurance companies, this is no surprise to them; they are already quite comfortable using IPSec. Because they connect to so many IPSec partners, though, they are not willing to use manual configurations; they require the use of IKE to manage SAs, and they must manage the workload on their perimeter router. Therefore, they do seek to minimize the processing wherever they can. They use ESP not only for encrypting the payloads, but also for the authentication, with MD5 HMAC (at 128 bits, less of a workload than 160 bits for SHA-1). This may be a bit of a gamble on their part, since SHA-1 is significantly more secure; until some legal precedent indicates that they must go stronger, however, they intend to stick with what they've been using. That includes DES instead of 3DES; the HIPAA final rule specifies encryption but no one has set actual strength-of-encryption standards yet that they know of. At this point, they are going by §164.312(e)(1), which states: " Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network." So far, DES has seemed good enough. If they need to strengthen their encryption to 3DES, it will require a change in their transform sets. At that point, they would probably also upgrade authentication to SHA-1. You are aware that this might come to pass, and so you ensure that PR1 and PR2 (the perimeter routers for the two ISP connections) have the CPU power to handle the encryption/decryption load. You will need to configure PR1 and PR2 for ipsec-isakmp with a peer of Medical Processors' IP address, and a transform set of esp-des and esp-md5-hmac (or esp-3des and esp-sha-hmac, if Medical Processors specifies the change). The resulting VPNs look like this:
Scenario 2 BSC's center has opened quite successfully, but the doctors who have their offices at the clinic want to be able to work from home during evenings and weekends with remote access to their office files. There are currently 12 doctors, and the clinic is successful enough that an expansion to double its size is going to be put in next year. BSC anticipates no difficulty filling those offices as well. Not all doctors have broadband access, although most have been promised it by their telco or cable service provider "Real Soon Now." What kind of VPNs does BSC need to set up for the doctors' offices, and does BSC need to purchase any additional hardware at this time? Scenario 2 Solution Since the doctors may be working on files that contain PHI, the VPNs must be encrypted. You want to keep this simple for the doctors, who don't understand and don't really want to learn about networking technologies; they are also rather price-insensitive (up to a point) on their personal computers. The hospital is price-sensitive, however, and while they prefer SSH, you conclude that the doctors may find it cumbersome. IPSec VPNs or SSL VPNs are therefore required. While it would be possible to set up a SSL-capable Web server as an entry point to the hospital's record system, some doctors may have records stored locally in their offices (non-hospital patients) that they desire to access. SSL VPNs also require the hospital to purchase certificates, while IPSec does not. That leaves us with IPSec VPNs. Dial-up access can be accommodated with access over the Internet (along with that from those lucky souls with broadband); thus a NAS is not really required. The VPN clients can be software on each doctor's accessing host (and the BSC security policy should specify requirements for remote systems that access the network, such as protection from intrusion via other networks those remote hosts are attached to). While 12 user accounts could be accommodated locally on the perimeter router, it could become cumbersome administratively (there is no reason to suspect doctors remember passwords, for instance, any better than the rest of us). Especially with growth coming, it would be better to set up a AAA server (such as the CiscoSecure ACS), which need not necessarily entail buying new hardware: such a server can quite likely run on an existing Windows 2000 server or Solaris server/workstation. In addition, as BSC develops relationships with other medical institutions, access for record and information sharing can be more easily controlled. Ingress for the VPNs, however, does need a termination. Again, with 12 user accounts it could be done locally, but to avoid stressing systems as the user load increases, it may be better to use a VPN concentrator now, linked to the ACS. Then, as other doctors join the network and the new offices become occupied, you would need to perform only relatively simple additions to an existing network, rather than having to introduce a new complexity as well. Thus, while no new hardware is strictly required at this time, given that growth is coming, it may be better to organize for that growth now, while the structuring part of the problem is smaller. That's as much a Layer 8 solution as a Layer 2 and 3 one. If an ACS and VPN concentrator are acquired, the topology should include access from each perimeter router to the ACS as well as from the two ingress perimeter routers to the VPN concentrator and from the concentrator and ACS to each other. This would look like Figure 3.
10 VLANs This paper, the final tutorial in the CCNA 2.0 LAN Switching series looks at the theory and operation of Virtual Local Area Networks (VLANs). The other CCNA Study Guides on switching are Layer 2 Switching and LAN Switching. After reading this tutorial you should be able to: � Define the term "Virtual Local Area Network" or "VLAN" � Describe the benefits of implementing VLANs � Configure VLANs using Cisco Catalyst IOS-based LAN switches such as the Cisco Catalyst 1900 series switch � Identify key differences between Cisco's proprietary ISL and IEEE 802.1Q industry-standard trunking protocols � Configure trunking on a Cisco Catalyst IOS-based LAN switch such as the Cisco Catalyst 1900 series switch � Identify the purpose of the VLAN Trunking Protocol (VTP) � Configure VTP parameters including VTP domain name, VTP password, VTP operational modes (Server/Client/Transparent), and VTP pruning � Identify how Cisco's implementation of Spanning Tree Protocol operates when multiple VLANs are configured � Identify the appropriate "show" commands to verify VLAN connectivity and ensure proper Spanning Tree operation � Describe how to route between VLANs when using ISL � Identify commands to troubleshoot common VLAN issues 10.1 Tutorial Introduction This is the third in a series of Cisco Certified Network Associate (CCNA) LAN Switching White Papers published by . Since the publication of original CCNA LAN Switching White Paper in May of 2000, Cisco updated its CCNA curriculum, downshifting much of the Advanced Cisco Router Configuration (ACRC) and Cisco LAN Switching Configuration (CLSC) curriculum into the new CCNA 2.0 preparation course -- "Interconnecting Cisco Network Devices." Cisco has expanded its scope, requiring a greater in-depth knowledge of CCNA Bridging and Switching topics, particularly in the areas of "Static VLANs," "Spantree," and "Switching modes/methods." As a direct result of the increased content in these topics, decided a new LAN switching paper was required. Since the scope of the material increased dramatically, it was decided that the CCNA 2.0 LAN Switching tutorial would be divided into two separate publications. The first of the new CCNA Layer 2 Switching tutorials (published in January of 2001) covered basic Layer 2 bridging and switching technologies, examined Cisco's Catalyst series line of LAN switches, and provided an introduction to installing, configuring, and troubleshooting the Cisco Catalyst 1900 series LAN switch. This paper, the final tutorial in the CCNA 2.0 LAN Switching series looks at the theory and operation of Virtual Local Area Networks (VLANs). After reading this tutorial, you should be able to:
• Define the term "Virtual Local Area Network" or "VLAN" • Describe the benefits of implementing VLANs • Configure VLANs using Cisco Catalyst IOS-based LAN switches such as the Cisco
Catalyst 1900 series switch • Identify key differences between Cisco's proprietary ISL and IEEE 802.1Q industry-
standard trunking protocols • Configure trunking on a Cisco Catalyst IOS-based LAN switch such as the Cisco Catalyst
1900 series switch • Identify the purpose of the VLAN Trunking Protocol (VTP) • Configure VTP parameters including VTP domain name, VTP password, VTP operational
modes (Server/Client/Transparent), and VTP pruning
• Identify how Cisco's implementation of Spanning Tree Protocol operates when multiple VLANs are configured
• Identify the appropriate "show" commands to verify VLAN connectivity and ensure proper Spanning Tree operation
• Describe how to route between VLANs when using ISL • Identify commands to troubleshoot common VLAN issues
Together, the two new CCNA LAN Switching tutorials touch on all of the knowledge areas required for the CCNA 2.0 exam. For up-to-date information of what LAN switching knowledge is required to pass the CCNA 2.0 exam, consult Cisco's web site. Overview Over the years, data networking requirements have changed drastically. Character-based systems have been replaced by graphic-intensive applications. The integration of voice, video, and data has brought new challenges -- and as requirements change, infrastructure support technology has evolved. Ethernet media has moved beyond the original 10 Mbps coaxial cable standard and now supports twisted pair copper media and fiber optics. Network segmentation options have been developed in an effort to resolve today's internetworking challenges -- namely those of bandwidth, security, and quality of service. VLANs are an outgrowth of network segmentation devices. What is a VLAN? Why do I need it? Or rather, do I need it at all? What functionality does it offer me? What are the drawbacks of implementing VLANs in my network environment? The answer to all these questions begins with answering the first question, "What is a VLAN?" The definition is simple, but many network administrators fail to understand the benefits and drawbacks of implementing VLANs before they've made the decision to deploy the technology in their network. Far too often, administrators discover after the fact that they've added another layer of complexity to their network, making troubleshooting more difficult, and have not gained the anticipated results. Understanding the role that VLANs play in a network requires an examination of the problems and technologies that have led to the evolution of this technology. By looking at the problems and the technologies that have been developed to solve their respective issues, you can not only answer the question "What is a VLAN?" but will also be able to answer the questions "Why do I need it?" and "DO I (in fact) need it?" Note: While VLANs are not strictly an Ethernet technology, the CCNA 2.0 curriculum focuses on VLANs from an Ethernet perspective. For information on implementing VLANs in Token Ring or FDDI environments, refer to Cisco's Web Site or consult Cisco Certified Network Professional or Cisco Certified Internetwork Expert level material. The History of Network Segmentation It was once said that if you placed an infinite number of monkeys in a room in front of an infinite number of typewriters, they would eventually reproduce the entire works of William Shakespeare. Modernizing the "Infinite Number of Monkeys" theorem requires that the infinite number of monkeys be placed in a room in front of an infinite number of computers each connected via a Local Area Network. In a straight forward "shared-media" design, it is highly unlikely that the infinite number of monkeys would ever reproduce the entire works of William Shakespeare -- the amount of congestion on the network is likely to pale in comparison to the degree of frustration exhibited by the infinite number of monkeys. The greater the number of monkeys accessing network resources, the greater the demand for access to network media. Decreased network performance inevitably results in decreased productivity as monkeys (or end-users) wait for network-based applications to respond. On an Ethernet-based LAN, an oversubscribed segment can experience an excessive number of collisions. To control oversubscription, the Ethernet specification establishes restrictions on the maximum number of devices that can exist on a populated Ethernet segment, defines the
maximum length of a LAN segment, and limits overall diameter of the LAN topology. Even with strict adherence to these requirements, a local area network can still experience congestion. The most common method of resolving media problems due to an oversubscription of bandwidth is by segmenting the network using an OSI model Layer 2 device known as "bridge" or "switch". The deployment of a Layer 2 device reduces the number of devices contending for access to network media thereby decreasing the traffic load on the original segment. A Layer 2 device establishes separate collision domains between connected segments. By creating separate collision domains, multiple "maximum diameter Ethernet LANs" can be interconnected, effectively increasing the number of PCs that can exist within an Ethernet environment and bypassing the problems that restrict the diameter of the network.
Figure 1. Segmenting a Collision Domain Even with the deployment of Layer 2 devices in a network environment, problems with oversubscription of network media could still exist. While it is possible to control the amount of end-user data on a given segment, Layer 2 devices do not restrict the propagation of broadcast traffic between segments. Broadcast traffic from sources such as Novell's "chatty " IPX protocol or Microsoft's NetBIOS name resolution process, if not readily confined, could monopolize the bandwidth of the entire network. For example, let's look at "X Y Z Corporation." Their network infrastructure consists of over 2000 PCs configured to use IP, IPX, and NetBEUI. AppleTalk and DECnet are also configured on a handful of systems. Each department within the organization has been configured to function as either a Microsoft Workgroup or domain. The departments configured to operate as Microsoft Workgroups elected to base their server-applications on NetWare servers rather than Windows NT systems. The administration of all NetWare servers is the responsibility of the department, rather than the Information Systems team. Because there is no single authority overseeing the deployment of the NetWare systems, no common IPX network scheme exists, nor is there a corporate standard set for naming systems. It is not uncommon to see multiple frame types configured on each NetWare server and on all NetWare clients. Although the Information Systems department has deployed a number of bridges within this environment in an attempt to localize network activity, there remains a significant amount of broadcast traffic being sent between Ethernet segments. A single broadcast storm would completely disable the entire network. The Information Systems department of "X Y Z Corporation" could make an excellent case for increasing the capital expenditures budget to allow for the purchase of several Layer 3 devices known as "routers." A router would not only divide the collision domain into separate segments,
but also divide the broadcast domain keeping broadcast traffic local to each connected segment. By reducing the number of broadcasts propagated between LAN segments, the overall traffic load of each segment decreases.
Figure 2. Segmenting a Broadcast Domain It's not the router that inherently divides the collision domain, but rather it's the physical grouping of devices that limits what broadcasts appear on the LAN media. For the sake of simplicity, assume that "X Y Z Corporation" is now only deploying TCP/IP on its network. If "X Y Z Corporation" were to decide to divide its network into three IP subnets (172.16.1.0 mask 255.255.255.0, 172.16.2.0 mask 255.255.255.0, and 172.16.3.0 mask 255.255.255.0) and perform "one-arm routing" (meaning that a single router interface would route for the connected subnets), this network design would not stop the propagation of broadcasts between end-systems from different subnets. An example of this type of topology is shown in Figure 3.
Figure 3. Network Layer Segmentation without Broadcast Control
When a PC located on the 3rd floor creates a directed broadcast frame, it uses the IP address 172.16.3.255. To build the Ethernet frame to encapsulate the packet, the PC uses the broadcast MAC address of FF-FF-FF-FF-FF-FF as the destination address. Each LAN switch will receive a copy of the frame. As a Layer 2 device, each switch is only aware of the Ethernet MAC address information -- it is unable to process IP address information contained within the frame. Each LAN switch will continue to flood the broadcast frame out all ports. The directed broadcast frame will be propagated to all end-systems located in the network, however end-systems located on the first and second floors will ignore the frame because the frame is not recognized as a broadcast destined for it. Thus, the problem of broadcast propagation consuming bandwidth still exists . Note: The term "one-arm routing" is typically associated with a "router-on-a-stick" configuration. The term "router-on-a-stick" refers to a router with a single interface that performs routing for multiple networks (or subnets). If you were to draw a diagram, it would show a router with a single line coming from one of its interfaces. This depiction might remind you of a lollipop - but instead of candy at the end of the stick, it's a router!
Figure 4. Router on a Stick If "X Y Z Corporation" chose to physically segment its network by floor, using one subnet per floor, an effective broadcast domain would be created. Layer 2 devices would typically only encounter broadcasts from devices that reside on the local subnet, and propagation of these frames would be desirable.
Figure 5. Network Layer Segmentation with Broadcast Control So What Is a VLAN? In its simplest form, a VLAN is a logical grouping of end-systems that share a broadcast domain that has been defined at Layer 2. Unlike the traditional Layer 3 broadcast domain that has been created by the deployment of a device operating at Layer 3, a VLAN broadcast domain is not limited by physical location. A VLAN is able to span floors, buildings, and even wide-area networks. VLANs can be defined using any administratively selected grouping. Examples of such groupings include grouping by corporate departments, by end-user applications, or by functional groupings .
Figure 6. Virtual Local Area Networks (VLANs) Why Do I Need It? Or DO I Need It? A combination of the design of the physical cable plant of a network as well as a strategic deployment of routers within the network can effectively control broadcast traffic, but only as long as each Layer 3 network is physically separated from each other. Consider using VLANs if there is a requirement for a logical grouping of end-systems, intermixing Layer 3 networks. Prior to deploying VLAN architecture, the increased administration requirements and difficulty troubleshooting the network should be contrasted with the anticipated performance benefits. Be prepared to answer the question, "What problem am I trying to solve by deploying VLANs within my network environment"? Cisco's position on VLANs is that their deployment simplifies adds, moves, and changes of end-systems within a network -- specifically in relation to the administration required when an end-user changes locations within a building or campus environment. Wherever the end-user moves, their network-layer address information (and security policies associated with such) follows them, enabling a seamless move to their new location. Such security policies can be implemented on a user group basis as well. Since the end-user's IP address assignment does not change when they move, there is no requirement to update Access Control List (ACL) statements on the corporate router(s) in order to maintain the organization's security policy. How VLANs Work In order to implement VLAN architecture within a network environment, at least one VLAN-capable device such as a LAN switch must be used. End-systems (or multiport repeaters) that connect to a VLAN-enabled LAN switch can receive their VLAN assignments either statically (according to the connected port) or dynamically (the LAN switch determines the VLAN membership based on the source MAC address information). The interface configuration mode command note VLANs first appeared in working group 802.10 of the Institute for Electrical and Electronics Engineers. Project 802.10 was specifically trying to solve the problem of security on shared LANs, and the original 802.10 proposal included encryption at Layer 2. Subsequently, some of
the basic principles of 802.10 began to show promise in other aspects of local networking, such as simplifying moves, adds, and changes, as a means of controlling the propagation of broadcasts, and, to some extent, a way to reduce cabling cost. vlan-membership static <vlan ID> is used to statically assign a port to a VLAN (a static port can only belong to one VLAN at a time). On the Catalyst 1900 series switch, a VLAN ID can be any value in the range of 1 through 1001. If a value is not specified for the <vlan> parameter, the default VLAN ID "1" is assigned to the port. Note: Some switches, such as the Catalyst 2900XL permit an administrator to configure a port to be a member of more than one VLAN at a time when using a membership mode known as "Multi-VLAN." A Multi-VLAN port can belong to up to 250 VLANs; the actual number of VLANs to which the port can belong depends on the capability of the switch itself. Although the concept is similar, this membership mode is different from "trunking," which will be discussed shortly. In order to instruct a port that it is to receive its VLAN configuration information dynamically, the interface configuration mode command vlan-membership dynamic is used. The port retrieves dynamic VLAN membership information from an ASCII format text file containing the MAC-address to VLAN membership mapping information. This file is stored on an external server known as a VLAN Membership Policy Server (VMPS). In order for the switch to be able to contact a VMPS, the switch must be configured with an IP address. If the VMPS does not reside on the local subnet, a default gateway address must also be specified. A VMPS can be a PC configured with TFTP server software or a Catalyst 5000/5500 LAN switch that has had its VMPS feature enabled. Neither the Catalyst 1900/2820 series switches nor the Catalyst 2900XL/3500XL series switches can operate as a VMPS. To retrieve the dynamic VLAN membership information from the VMPS, the LAN switch uses the information from the global configuration command vlan-membership server ip-address [primary] from which it initiates a TFTP process to contact the VMPS. Up to four VMPS are supported by the Catalyst 1900/2820 series switch. The Multi-VLAN membership mode cannot be configured on a switch if one or more ports on the switch have been configured to trunk. For more information on this feature, search Cisco's Web Site using the keyword phrase "switchport multi." The 1900 series switch is configured with several standard VLAN numbers, which can be found on all Cisco Catalyst switches. VLAN 1 is the default VLAN -- all ports operate in VLAN 1 unless configured to participate as a member of another VLAN. When an IP address is assigned to the switch for TCP/IP management purposes, VLAN 1 is used by the IP address to communicate on the network. VLAN 1 is also used by the management protocols Cisco Discovery Protocol (CDP) and VLAN Trunk Protocol (VTP) that broadcast or multicast their information. Note: Assigning a port to more than one VLAN is quite contrary to the architecture of VLANs. Cisco introduced it to counter pressure from 3Com, but using this feature both takes away protection for shared resources, and can make many system administration tasks more difficult. For example, assume you are assigning a printer's port to two VLANs. If both VLANs use NetBEUI broadcasts to find the printer, things can work. But what if the printer is IP addressed? Can it exist simultaneously in more than one subnet? Or will you have to route to it?
Figure 7. Catalyst 1900 Default VLAN Configuration The Catalyst 1900/2820 series switch is also pre-configured with VLANs 1002, 1003, 1004, and 1005. Token Ring and FDDI networks use these VLANs. Configuring a VLAN To create a VLAN on a Catalyst 1900/2820 series switch, use the global configuration command vlan <vlan ID> [name vlan-name] to configure the VLAN with a number and name. VLAN names can be between 1 and 32 characters in length, must be unique and are case-sensitive. For example, you could create VLAN 2 using the name "engineering" and create VLAN 3 using the name "Engineering." Be careful to ensure that you are using the correct name when creating domains. If you are creating domains on multiple switches, be sure that the name of the VLAN is correct and is using the appropriate case. If no VLAN name is selected when creating the VLAN, the default is to append the VLAN number (in 4-digit format) to the word "VLAN." For example, issuing the command "vlan 15" would result in the VLAN receiving the default-generated name "VLAN0015." To modify the name of the VLAN, use the same command syntax used to create a VLAN: vlan <vlan ID> [name <vlan-name>] The switch will modify the original entry to reflect the new name. Once the VLAN has been created, the interface configuration mode command vlan-membership{static [vlan] | dynamic} can be used to assign a port to a VLAN. If this step is completed prior to the VLAN being created, the status of the port will show as "Disabled-no-vlan." The port will become active once the VLAN to which it has been assigned is created. Verifying VLAN Configuration To ensure that the created VLANs have been properly configured, use the privileged exec mode command show vlan. From this command you can determine if your VLANs have been named correctly, their status (enabled, suspended, etc.), and which ports have been assigned to which VLANs:
Figure 8. Verifying VLAN Configuration The privileged exec mode command show vlan-membership displays VLAN assignment and membership type information for all switch ports:
Figure 9. Verifying VLAN Membership Configuration VLAN Trunking As noted previously, all ports on a Catalyst switch are automatically members of VLAN 1. To forward frames between LAN switches in this type of configuration does not require any special configuration of the ports linking the switches.
Figure 10. Single Broadcast Domain VLAN In order to ensure continuing connectivity between switches, it is important to develop a redundant topology. Where redundant inter-switch links exist, Spanning Tree Protocol would be responsible for enabling and disabling ports. Spanning Tree Protocol would activate a redundant link only when the primary inter-switch link failed. To establish an inter-switch link for a VLAN other than VLAN 1 requires that the switch ports used to carry the inter-switch traffic be statically configured to operate as a member of that VLAN. No additional configuration is required. Again, redundant links between switches configured to operate as members of the new VLAN are recommended. Again, Spanning Tree Protocol would be responsible for managing the redundancy. Using static membership assignment to configure each port so that it can be used to transport traffic between switches for its specific VLAN can be effective when the number of active VLANs in the network is small. Using dedicated links to carry traffic for a single VLAN quickly becomes impractical as the number of active VLANs in the network increases. Rather than use this dedicated link type of configuration, a new scalable solution was sought. The concept of a "trunk" was created: a single switch port could be configured to carry traffic from multiple VLANs. By defining a switch port as a trunk port, the switch port becomes a member of all defined VLANs. A trunk port requires some mechanism for identifying the VLAN to which the frame belongs as it is transported over the multi-VLAN link. A LAN switch may keep track of VLAN information using either a method known as "frame filtering" or a method called "frame tagging." Frame filtering maintains a table of VLAN and MAC address information. The LAN switch forwards incoming frames based on filtering table entries. Maintaining filtering table entries can become processing intensive for some low-end switches, and requires the synchronization of filtering tables between switches. Frame filtering is sometimes referred to as "implicit tagging." Frame tagging (or more precisely, "explicit frame tagging") attaches a unique identifier tag to each frame. This tag remains with the frame as long as the frame stays within the switch fabric of the network. Once the frame arrives at the destination LAN switch port, the tag is removed. The entire process of frame tagging is transparent to the end-systems involved. Explicit frame tagging is entirely a Layer 2 process. Unlike frame filtering, it does not require a significant amount of processing to carry VLAN information between switches. Cisco supports two separate tagging protocols -- IEEE 802.1Q and its own proprietary Inter-Switch Link (ISL). 802.1Q tagging can be used with Ethernet, Token Ring, and FDDI LAN protocols. In the case of Ethernet, 802.1Q inserts four bytes into the frame: the first two bytes indicate to the receiver that an 802.1Q tag follows. This field is referred to as a "Tag Protocol Identifier" (or TPID); however, it may also be referred to as an "Ethertype field." The TPID value for this field is 0x8100.
The remaining 2-bytes create a field within the frame known as the "VLAN tag." The VLAN tag is composed of 3 bits that specify the priority of the frame, 12 bits that specify the VLAN ID (VID), with the remaining bit used to indicate whether the address is canonical (least-significant-bit-first) or non-canonical (most-significant-bit-first) in format. This bit is called the Canonical Format Indicator, or "CFI". Ethernet transmits using canonical format (identified by the presence of a 0 in the CFI). Token Ring and FDDI transmit using a non-canonical format (identified by the presence of a 1 in the CFI).
x Figure 11. 802.1Q Frame Tagging of an Ethernet II or 802.3 Frame The maximum size of an Ethernet frame is 1518 bytes (not including preamble). If the 802.1Q tag is inserted into a 1518-byte Ethernet frame, an Ethernet frame will be created that exceeds the Ethernet specification by four bytes. Should a device in the network exist that does not support the larger frame size, the device may show that a large number of baby giants have been received. The IEEE 802.3 committee has tasked the 802.3ac workgroup with the responsibility of examining options extending Ethernet's maximum frame size to 1522 bytes. IEEE 802.1Q frame tagging should be used when creating VLANs that require vendor interoperability. If all switch equipment in the network is manufactured by Cisco, Cisco recommends using ISL to tag frames. ISL operates in a manner similar to IEEE 802.1Q; it identifies the VLAN membership information for the frame to which it is attached. However, because it adds a far larger amount of information to the Ethernet frame, it provides a larger selection of options and features that Cisco Catalyst LAN switches can take advantage of. IEEE 802.1Q adds a single tag segment to the Ethernet frame. This is referred to as "one-level tagging encapsulation" or "single-tagging." ISL on the other hand, encapsulates an Ethernet frame, adding a 26-byte ISL header to the front of the frame, and a 4-byte CRC to the end of the frame. Because two tag segments are added to the Ethernet frame, ISL tagging is referred to as "two-level tagging encapsulation," or "double-tagging."
Figure 12. ISL Encapsulation of an Ethernet II or 802.3 Frame The ISL header is comprised of the following fields: Table 1. ISL Encapsulation Header Fields Field: Description
DA Multicast address (01-00-0C-00-00), indicating the frame is an ISL encapsulated frame.
Type Encapsulated LAN frame type: 0000 - Ethernet, 0001 - Token Ring, 0010 - FDDI, 0011 - ATM
User Type field extension or Ethernet priority field (0 - lowest priority, 3 - highest priority)
SA MAC address of the source Catalyst switch
Length Length of the ISL header (not including length of DA, Type, User, SA, and Length
fields of ISL header) and original Ethernet frame.
SNAP Fixed value field of AA-AA-03
HSA High-order bits of the Source Address (SA) of the originating Catalyst switch (Organizational Unique ID).
VLAN ID 15 bit field, however, only the lower 10 bits are used to identify VLAN ID (1-1024).
BPDU Value of 1 indicates the frame is a Spanning Tree BPDU frame, CDP frame, VTP frame, or CDP message.
Index Port ID of the transmitting port of the source Catalyst switch.
Reserved Used for additional information required to transport Token Ring and FDDI frames over an ISL link.
An Ethernet trunk can be configured on a Catalyst switch's Fast Ethernet or Gigabit Ethernet interface. An Ethernet trunk cannot be configured on a standard Ethernet port. Configuring ISL Trunking To configure a Catalyst 1900 series switch Fast Ethernet interface as a trunk, use the interface configuration mode command trunk {on | off | desirable | auto | nonegotiate} to enable Dynamic ISL (DISL) on the switch's FastEthernet 0/26 or FastEthernet 0/27 port. DISL was designed to simplify the management of ISL trunk establishment by synchronizing the configuration of the interconnected Fast Ethernet ports to create an ISL trunk. (The Catalyst 1900/2820 series switch does not appear to support the IEEE 802.1Q trunking protocol at this time). The following options are available when enabling DISL:
On Sets the port to trunk mode and negotiates with the connected switch port to enable trunking.
Off Disables trunking on the port and negotiates with the connected switch port to become a non-trunk port. Off is the default DISL state.
Desirable Sets the port to trunk mode if the connected port is set to the on, desirable, or auto state. If trunking is unsuccessful, the port becomes a non-trunk port.
Auto Will set the port to become a trunk if the connected switch port has initiated negotiation. The connected switch port must be set to the ON or desirable state.
Nonegotiate Sets the port to trunk. No negotiation takes place with the connected switch port.
If a connected trunk port partner does not support the DISL protocol, set the DISL state on the Catalyst switch port to nonnegotiate (or on) to enable trunking between trunk ports or off to disable trunking between ports. Note: The web management interface of the Catalyst 1900 series switch will display the status of a VLAN port in the grayed out field of the Status column on the Port Management page. If the port status is reported as "Suspended-DISL," the port is suspended due to DISL negotiation. If the port status is reported as "Suspended No-VLAN," the port is suspended because the port is not a member of a VLAN. If the port is reported as "Disabled No-VLAN," the port is disabled because the VLAN assigned to the port has not been created. Although it may be easiest to manage your Catalyst switches from the familiar CLI, it would be worthwhile to familiarize yourself with the features available from within the web management interface as well as the menu-driven options available on the switch. The Catalyst 1900/2820 has
features available from within these two management interfaces that are not available from within the CLI of the switch. Once a port has been configured to trunk state, ensure that the corresponding trunking-partner port has also been set to trunk. Should one interconnected port be set to trunk, while the trunking-partner port is set to not trunk (non-trunk mode), a condition known as an "ISL-mode mismatch" occurs. Troubleshooting ISL-mode mismatches can be difficult -- issuing the privileged exec command show spantree will show both trunk ports as actively forwarding frames. However, no communication between ports is actually taking place. To determine if an ISL-mode mismatch has occurred, use the privileged exec command show interface FastEthernet 0/26 or 0/27 (depending on which port has been set to trunk) and watch the sent and received counters of the ports to determine if these counters are incrementing. If a port is sending frames but not receiving them, it is likely an ISL-mode mismatch condition. The following table lists the possible trunk mode configurations and the resultant status of the trunk ports. Where the trunk status appears in bold italic type, an ISL-mode mismatch will occur. Table 2. Trunk Mode Combinations
Trunk Mode Combination Trunk Status
Off - Off Nontrunking - Nontrunking
Off - On Nontrunking - Trunking
Off - Desirable Nontrunking - Nontrunking
Off - Auto Nontrunking - Nontrunking
Off - No-negotiate Nontrunking - Trunking
On - On Trunking - Trunking
On - Desirable Trunking - Trunking
On - Auto Trunking - Trunking
On - No-negotiate Trunking - Trunking
Desirable - Desirable Trunking - Trunking
Desirable - Auto Trunking - Trunking
Desirable - No-negotiate Nontrunking - Trunking
Auto - Auto Nontrunking - Nontrunking
Auto - No-negotiate Nontrunking - Trunking
No-negotiate - No-negotiate Trunking - Trunking
Using Dynamic ISL will automatically configure the switch to forward frames from all VLANs across the trunk port. As an alternative to this command, the interface configuration command trunk-vlan <vlan> [<vlan> ... <vlan>] can be used to manually specify a list of up to 10 VLANs to forward member frames across the trunk port. Verifying Trunk Operation To verify that a port has been configured to trunk as expected, use the privileged exec mode command show trunk {a | b}:
DISL state: Auto, Trunking: On, Encapsulation type: ISL SwitchA#
Figure 13. ISL Trunking Status Trunk port A refers to FastEthernet 0/26 while trunk port B refers to FastEthernet 0/27. If a DISL option has been used to negotiate a connection between ports, the state of the trunk may not display the expected trunking information. For example, if you have just issued the interface configuration mode command trunk on, the command show trunk a will display the DISL state as ON while the trunking state may display as OFF but the expected trunking state is ON. The negotiation process between ports may still be in progress, wait a few seconds, and check the status of the trunk again. If a switch has not been configured with a trunk port -- and the destination device's MAC address does not reside on the local switch -- the frame is treated like a frame with an unknown address. The frame is flooded out all ports that belong to the same VLAN as the source device. Removing a VLAN from a Trunk Link If a trunk port should not carry specific VLAN traffic, modifying the trunk's "allowed-VLANs" list can restrict VLAN membership for the trunk. To remove a VLAN from a trunk link, use the interface configuration command no trunk-vlan <vlan ID> To verify that the VLAN has been removed from the trunk's "allowed-VLANs" list, use the privileged exec mode command show trunk {a | b} allowed-vlans
Figure 14. Restricting VLAN Traffic from a Trunk Link VLAN Trunk Protocol (VTP) VLAN Trunk Protocol (VTP) is a Cisco proprietary protocol that simplifies configuration of VLANs on switches by propagating VLAN configuration information to all switches in the network. When an administrator manually configures VLAN information on a switch, there's always the possibility of introducing an error that may result in unexpected performance of the network. Common problems include: confusing names with VLAN IDs (assigning the VLAN name "Marketing" to VLAN 3, rather than VLAN 4), making an error in the VLAN ID when creating a VLAN on a switch (VLAN 123 becomes VLAN 12), and not noticing that a VLAN name has been spelled incorrectly and is inconsistent among other switches. VTP information is propagated among switches that belong to the same VTP domain. A LAN switch can only belong to one VTP domain. VTP exchanges information using multicast frames sent over trunk links every five minutes or whenever there is a change in the VTP database. These announcements are sent over VLAN 1. There may be instances when disabling VLAN 1 on a trunk link is desirable. For example, the risk of a broadcast storm increases as the size and complexity of a network increases. If a broadcast storm were to occur, since VLAN 1 exists on all trunk links within the network, the broadcast storm would be propagated over every trunk link to every switch in the network. By disabling VLAN 1, user traffic from VLAN 1 is restricted from being transmitted or received across the trunk and the risk of a broadcast storm would be reduced. Management protocols such as VTP, Cisco Discovery Protocol (CDP), Port Aggregation Protocol (PAgP), and Dynamic ISL (DISL) would continue to propagate their information throughout the network.
By default, a new Catalyst switch will remain in the no-VTP-domain mode (or no-management-domain state) until it receives a multicast VTP advertisement from a neighboring switch, or until it is manually configured with a VTP domain name. Once the switch has been configured to participate as a member of a VTP domain, it is ready to receive VTP information. After being configured with a VTP domain name, the LAN switch will operate in one of three VTP modes: Note: A Cisco Catalyst switch may alter its VTP mode under certain circumstances. For example, should a switch operating as a VTP client or VTP server be configured with a multi-VLAN port, the switch will automatically reconfigure itself to operate in VTP transparent mode. Neither the VTP client option nor VTP server mode option is available when using a multi-VLAN configuration. A second instance where a Cisco Catalyst switch may alter its VTP mode is when a switch operating in VTP server mode receives a VTP announcement containing more VLAN entries than what can be held in NVRAM (the Catalyst 1900/2820 series switch can accommodate up to 128 VLAN entries). When this occurs, the Catalyst switch automatically switches its VTP mode of operation from VTP server to that of VTP client. A switch operating in VTP client mode is able to accommodate a larger number of VLAN configuration entries (up to 1005 on the Catalyst 1900/2820 series switch) because this information is not stored in NVRAM. Conversely, should a switch operating as a VTP client be reset to operate in transparent mode, which requires entries to be moved from volatile to non-volatile memory, any entries that cannot be physically accommodated in NVRAM (greater than 128 VLAN entries) will be truncated. Server mode: A switch configured as a VTP server is able to add, modify, or delete VLANs and establish other configuration parameters (such as VTP pruning eligibility -- to be discussed shortly) for its VTP domain. It stores these changes in non-volatile memory (NVRAM). VTP messages are transmitted out all trunk connections and are received by all VTP domain members that have been configured as VTP servers or VTP clients. A VTP server synchronizes its information database with other VTP servers located in the domain, storing this information in NVRAM. Client mode: A switch configured as a VTP client is not able to create, modify, or delete VLAN information. VTP-received information is stored in "read-only mode." Should the switch lose power, it will lose all learned VTP information. Unlike a VTP server, a VTP client does NOT store VTP-learned VLAN configuration information in NVRAM. Transparent mode: A switch configured to operate in VTP transparent mode is able to add, modify, or delete VLAN information from its VTP database; however, this information is not propagated to other switches in the network. A LAN switch operating in VTP transparent mode stores its VTP information in non-volatile memory, enabling the switch to recover its VLAN configuration information should the switch lose power. A Catalyst 1900/2820 series switch will operate in VTP server mode by default. In order to maintain consistent VTP information, VTP uses a configuration revision number to keep track of the most current VTP information on the network. Each time a VTP server modifies its VLAN configuration information, it increments the revision number by one. It then sends out its changes along with the new configuration revision number. VTP announcements are accepted by all VTP servers and clients whose VTP domain name (and password, if configured) match those of the advertising VTP server. If the receiving VTP server or client has a configuration revision number lower than that which is received, it knows that the sending VTP server has newer VTP information than itself, and overwrites its configuration information with that which is being advertised. Caution should always be exercised when making any changes to a switch that is operating as a VTP server. If such a switch is taken off-line for testing because of problems with the device, any changes to the VLAN configuration information cause the configuration revision number to
increment. When the switch is placed back in active duty, its new configuration revision number will be higher than what was being advertised on the network. Thus the switch's VTP information will overwrite all existing VLAN configuration information. Assume for a moment that while the VTP server switch was off-line, all VLAN information was deleted so that each port could be tested easily. Uploading this revised information into the network could have potentially disastrous effects on the operation of the network. Prior to placing any switch on the network that is operating in VTP server mode, it might be wise to reset the configuration revision number using the privileged exec mode command delete vtp. Alternatively, when taking a device off the network, change the VTP domain name to something other than the VTP domain name that is active on the network. If the device is accidentally placed back into production without the revision number being cleared, the switch will not propagate its VLAN configuration information because its domain name does not match what is currently in use. When the switch is ready to be returned to service, and the domain name has been restored to its original state, the switch automatically resets the VTP configuration revision number to 0. VTP Pruning VTP pruning can be used to control unnecessary broadcast, multicast, and flooded unicast frames flowing through the network. Enabling VTP pruning on a per-VLAN basis ensures that only broadcasts, multicasts, and flooded unicast frames are forwarded through trunk links connected to end-systems that require this information. For example, in Figure 15 a trunk link exists between Switch C and Switch D. Switch C receives broadcast frames destined for VLAN 6, however, Switch D does not have any connected end-systems that are members of VLAN 6. VTP pruning would prevent broadcast, multicast, and flooded unicast frames destined for VLAN 6 from being sent over this link.
Figure 15. VTP Pruning By pruning these unnecessary frames from the network, the bandwidth of the trunk link carries only traffic that is appropriate for the link. VTP pruning can be enabled on VLANs 2 through 1001 but cannot be enabled on the default VLANs (VLANs 1, 1002, 1003, 1004, and 1005). If you enable VTP pruning on a switch that has been configured as a VTP server, VTP pruning is enabled for the entire VTP domain. Configuring VTP Before setting a VTP domain name on a switch, know that VTP is not a requirement for VLAN operation. VTP was designed to assist a network administrator in maintaining global VLAN configuration information within a network. If a VTP domain name is not configured, VTP will not operate. VLAN configuration will be a manual process that will have to be completed on every switch not utilizing VTP functionality. The global configuration command vtp is used to set the VTP mode of operation, VTP domain name, VTP domain password, and to enable or disable the pruning capabilities of VLAN Trunk Protocol (VTP). The format of the vtp command is: vtp [server | transparent | client] [domain <domain-name>] [password <password>]
[pruning {enable | disable}] [trap {enable | disable}] When setting a VTP domain name or VTP password for the switch, note that both are case sensitive. If the domain name and domain password do not match, VTP information will not be propagated between these switches. The default operation of all Catalyst switches is that a VTP client or server does not require a VTP server to be authenticated as a member of the VTP management domain before the receiving VTP server or VTP client accepts the advertised VLAN configuration information. By default, a VTP management domain operates in a non-secure mode not requiring a password match to occur to validate the authenticity of the information being received. By configuring all VTP devices in the network with a VTP domain password, the management domain operates in a secure mode -- VTP announcements are only accepted by VTP clients and servers configured with the advertised VTP password. To configure a VTP domain password, use the global interface configuration mode command vtp password <password> A VTP password must be between 8 and 64 characters in length and is case sensitive. The vtp command is also used to enable or disable VTP SNMP traps that are generated each time a new VTP message is sent. VTP trap is enabled by default. Verifying VTP Operation To ensure that VTP has been configured correctly and is operating in the correct VTP mode, use the privileged exec mode command show vtp.
SwitchA#show vtp VTP version: 1 Configuration revision: 128 Maximum VLANs supported locally: 1005 Number of existing VLANs: 128 VTP domain name : CertZone VTP password : TEST VTP operating mode : Server VTP pruning mode : Disabled VTP traps generation : Disabled Configuration last modified by: 172.16.1.220 at 00-00-0000 00:00:00 SwitchA#
Figure 16. VTP Configuration Information Figure 16 shows "VTP version: 1." Like many other protocols, VTP was modified at some point to add extra functionality to the protocol. VTP version 1 only supports Ethernet, while VTP version 2 supports Token Ring as well. To ensure that the switch is transmitting and receiving VTP advertisements as expected, use the privileged exec mode command show vtp statistics.
Port Join Received Join Transmitted Summary Adverts received with no pruning support ---- ------------- ---------------- ------------------------ A 0 0 0 B 0 0 0 SwitchA#
Figure 17. VTP Advertisement Statistics Spanning Tree Protocol and VLANs - Cisco's Solution Cisco has implemented a proprietary Spanning Tree Protocol (STP) implementation whereby each configured Ethernet VLAN uses a separate instance of STP. The use of a single instance of STP for all VLANs poses a significant problem with respect to network scalability, stability, and design. By using separate instances of STP for each VLAN, traffic belonging to different VLANs can flow over different pathways of the switch fabric. Should a device belonging to a particular VLAN experience intermittent connectivity, the separate STP instance should confine topology recalculations to that VLAN. Recovery time during the spanning tree topology recalculation may be reduced depending on how the network has been designed.
Figure 18. Per-VLAN Instances of Spanning Tree Protocol The Catalyst 1900/2820 series switch can support up to 128 active VLANs; however, only 64 possible instances of STP are supported. The IEEE has recognized the merit of running multiple instances of STP. The 802.1 committee has formed a working group (802.1s) to look at creating a supplement to the IEEE 802.1Q Virtual LAN standard. IEEE 802.1s is still in draft form. Verifying Spanning Tree Operation To display the Spanning Tree Protocol configuration status of each port on the switch, use the privileged exec command show spantree:
SwitchA#show spantree VLAN1 is executing the IEEE compatible Spanning Tree Protocol Bridge Identifier has priority 32768, address 00B0.64D1.F740 Configured hello time 2, max age 20, forward delay 15 Current root has priority 32768, address 0002.1676.3240 Root port is FastEthernet 0/27, cost of root path is 10 Topology change flag not set, detected flag not set Topology changes 5, last topology change occurred 0d02h14m37s ago Times: hold 1, topology change 8960 hello 2, max age 20, forward delay 15 Timers: hello 2, topology change 35, notification 2 Port Ethernet 0/1 of VLAN1 is Forwarding
Port path cost 100, Port priority 128 Designated root has priority 32768, address 0002.1676.3240 Designated bridge has priority 32768, address 00B0.64D1.F740 Designated port is 1, path cost 10 Timers: message age 20, forward delay 15, hold 1 Port Ethernet 0/2 of VLAN1 is Forwarding Port path cost 100, Port priority 128 Designated root has priority 32768, address 0002.1676.3240 Designated bridge has priority 32768, address 00B0.64D1.F740 Designated port is 2, path cost 10 Timers: message age 20, forward delay 15, hold 1 . . . Port FastEthernet 0/27 of VLAN6 is Forwarding Port path cost 10, Port priority 128 Designated root has priority 32768, address 0002.1676.3246 Designated bridge has priority 32768, address 0002.1676.3246 Designated port is 27, path cost 0 Timers: message age 20, forward delay 15, hold 1
Figure 19. Spanning Tree Protocol Configuration Status Inter-VLAN Communication End-systems that are members of the same VLAN are free to communicate directly with one another. When an end-system that is a member of a VLAN tries to communicate with an end-system that is a member of a different VLAN, a Layer 3 internetworking device (such as a router or Layer 3 switch) is required.
Figure 20. Communication between VLANs Routing between VLANs using an ISL trunk link requires a router with a Fast Ethernet interface that supports ISL trunking. Currently the least expensive Cisco router that supports ISL trunking is the Cisco 2600 series router. One physical Fast Ethernet interface will suffice. To route between VLANs, create a subinterface for each VLAN to be routed. If six VLANs are to be routed, six separate sub-interfaces are required. Each VLAN should use the same subnet addressing. For example, Table 3 lists a possible VLAN schema: Table 3. VLAN Schema Example
On the router, perform the following steps: Create a subinterface for each VLAN to be routed. From global configuration mode use the following command to create a subinterface interface FastEthernet <slot>/<port>.<number> (e.g., "interface FastEthernet 0/0.1"). Enable ISL encapsulation on each subinterface being configured by using the command encapsulation isl <VLAN ID> Assign an IP address to the subinterface from the subnet range that corresponds to the VLAN to be routed on the subinterface. On the switch, enable ISL trunking on the switch port that connects to the router's Fast Ethernet interface.
Figure 21. Sample ISL VLAN Routing Configuration Summary The deployment of Virtual Local Area Networks within a network environment can provide significant benefits when logical grouping of end-systems is required or when the security benefits associated with deploying VLANs can be exploited. To deploy a successful VLAN topology requires a solid understanding of how Spanning Tree Protocol operates as well as understanding the implications of dispersing a broadcast domain throughout a network. For example, the election of a Spanning Tree root bridge may cause traffic to flow through less desirable pathways to its final destination. Spanning tree defaults may need to be tweaked for optimal network performance to occur. For additional information on LAN Switching, refer to "CCNA LAN Switching" Study Guide by Leigh Anne Chisholm or "Ethernet LAN Switching I" CCNP/CCIE-level Study Guide by Dan Farkas.
For additional information on the operation of Spanning Tree, refer to "CCNA LAN Switching" Study Guide by Leigh Anne Chisholm, "Ethernet LAN Switching I" CCNP/CCIE-level Study Guide by Dan Farkas, or "Bridging" CCIE-level Study Guide by David Wolsefer. For additional information on Virtual Local Area Networks, look for the upcoming "Ethernet LAN Switching II" CCNP/CCIE-level Study Guide by Dan Farkas. 10.2 Lab Abstract This lab is designed to walk you through a basic VLAN configuration using two Catalyst 1900 (or 2820) series switches. This lab shows you step-by-step what commands to type in and how to check that you have configured things correctly. There are seven sections included in this lab exercise. 10.3 Lab Scenario Introduction This lab is designed to walk you through a basic VLAN configuration using two Catalyst 1900 (or 2820) series switches. This lab shows you step-by-step what commands to type in and how to check that you have configured things correctly. Each switch must be configured with the Enterprise edition software. The Cisco IOS software CLI is not available if the switch has been configured with the Standard edition software. While it is possible to complete most of this lab using a single Catalyst 1900/2820 series switch, a second Catalyst 1900/2820 series switch (or Cisco switch that supports ISL) is required to complete Section 4, "Configuring an ISL Trunk Link." Section 3, "Verifying VLAN Functionality" and Section 4, "Configuring an ISL Trunk Link," require access to two PCs that can be connected directly to the switch ports of the primary switch that you will use for the lab. To successfully complete these sections, you must be able to alter the IP address configuration information on each of these PCs. To complete Section 4, "Configuring an ISL Trunk Link," you need one crossover cable to connect the switches. Section 7, "Configuring ISL Routing," requires access to a Cisco router that supports ISL trunking and that is equipped with a FastEthernet port. note IMPORTANT! Ensure you have the capability of configuring each switch via the console port prior to resetting the switch to its factory defaults. All configuration information including IP address assignment and IP default gateway will be reset. You will be unable to telnet to your switches. Preparing Your Switches Processes currently executing on the Catalyst switches involved in this lab may interfere with the expected outcome from each section of this lab. Therefore, it is recommended you begin working through these labs only after resetting the configuration of each switch to the factory defaults. To complete this process, issue the privileged exec mode command delete nvram on each switch. Once you have restored the settings on your switches to their original configuration, establish a console connection with each switch. You should see the following menu: 1 user(s) now active on Management Console. User Interface Menu [M] Menus [K] Command Line [I] IP Configuration [P] Console Password
Enter Selection: Set up the switches using the following configuration information: Primary Switch: Switch Name: SwitchA IP Address: 172.16.1.200 Subnet Mask: 255.255.255.0 Default Gateway: 172.16.1.1 Enable Password: secret
If you do not require step-by-step information on how to complete this process, then proceed to Section 1, "Configuring VLAN Trunk Protocol (VTP)." To configure the Primary Catalyst switch:
1. From the "User Interface Menu", select option "[K] Command Line". A ">" prompt will be displayed, indicating you have entered the user exec mode of the switch.
2. Enter privileged exec mode by issuing the command 3. enable
A "# "prompt will be displayed. 4. To begin configuring the switch name, IP information, and password; enter global
configuration mode by issuing the command 5. configure terminal
The prompt "(config)#" will be displayed, indicating that you have entered global configuration mode.
6. To set the name of the switch to "SwitchA," issue the command 7. hostname SwitchA
You will notice that the prompt now displays the name of the switch as well as the global configuration mode prompt: "SwitchA(config)#."
8. To set the IP address and subnet mask for the switch, issue the command 9. ip address 172.16.1.200 255.255.255.0 10. To set the default gateway for the switch, issue the command 11. ip default-gateway 172.16.1.1 12. To set the enable password to "secret," issue the command 13. enable secret secret 14. To end the configuration process, type exit. 15. Confirm your configuration by issuing the command show running-config. You should
see only: o the hostname of the switch (SwitchA) o IP address and default gateway information (ip address 172.16.1.200
255.255.255.0, ip default-gateway 172.16.1.1) o privileged exec mode password encrypted (enable secret 5
$1$FMFQ$6meDTvWbwHZeuIPKLt7Rh/) o each individual interface on your switch (Ethernet 0/1 through 0/27) o "line console"
There should not be any configuration information under the Ethernet interfaces nor line console.
Repeat this procedure on SwitchB, substituting the appropriate values for configuring the switch. Once you have completed configuring SwitchB, you are ready to begin working through the basic VLAN configuration of this lab. Section 1 - Configuring VLAN Trunk Protocol (VTP) In this section, you will set SwitchA to operate in VTP transparent mode. Recall that once a switch has been configured with a VTP domain name, its default mode of operation is that of VTP server. In order to ensure that this information is not propagated throughout the network, the VTP mode must be set to transparent before a VTP domain name is assigned.
Begin this part of the lab by configuring SwitchA. 1. On SwitchA, enter global configuration mode from the privileged exec mode prompt by
issuing the command 2. configure terminal
The prompt "SwitchA(config)#" will be displayed, indicating that you have entered global configuration mode.
3. To set the VTP mode to transparent, issue the command 4. vtp transparent 5. To set the VTP domain name to "CertZone," issue the command 6. vtp domain CertZone 7. To end the configuration process, type exit. 8. Confirm your configuration by issuing the command 9. show vtp
You should see the following output: SwitchA#show vtp VTP version: 1 Configuration revision: 0 Maximum VLANs supported locally: 1005 Number of existing VLANs: 6 VTP domain name : CertZone VTP password : VTP operating mode : Transparent VTP pruning mode : Disabled VTP traps generation : Enabled Configuration last modified by: 172.16.1.200 at 00-00-0000 00:00:00 SwitchA#
10. Optional: Issue the command 11. show vtp ?
Note that the only keyword available with the show vtp command is "statistics". 12. Optional: Issue the command 13. show vtp statistics
You should see the following output: SwitchA#show vtp statistics Receive Statistics Transmit Statistics -------------------------------- ------------------------------- Summary Adverts 0 Summary Adverts 0 Subset Adverts 0 Subset Adverts 0 Advert Requests 0 Advert Requests 0 Configuration Errors: Revision Errors 0 Digest Errors 0 VTP Pruning Statistics: Port Join Received Join Transmitted Summary Adverts received with no pruning support ---- ------------- ---------------- ------------------------ A 0 0 0 B 0 0 0 SwitchA# If the switch were operating in a mode other than VTP transparent, these counters would increment according to the information transmitted/received. If a switch were operating as a VTP client, it would be expected that "Transmit Statistics" counters would not
increment since the switch would be set up to only receive VTP information but not to transmit it.
14. Optional: On SwitchB, issue the command 15. show vtp
You should see the following output: SwitchB#show vtp VTP version: 1 Configuration revision: 0 Maximum VLANs supported locally: 1005 Number of existing VLANs: 5 VTP domain name : VTP password : VTP operating mode : Server VTP pruning mode : Disabled VTP traps generation : Enabled Configuration last modified by: 0.0.0.0 at 00-00-0000 00:00:00 SwitchB# SwitchB has not received any VTP information from SwitchA (which is to be expected). Note that SwitchB's VTP operating mode is set to "Server." Recall that once a Catalyst 1900 series switch is configured with a VTP domain name, its default VTP mode of operation is "Server."
Section 2 - Creating VLANs In this section, you will create three VLANs: Engineering, Marketing, and Production. Once these VLANs have been created, you will assign two ports to each VLAN using the static membership configuration option. Begin this part of the lab by configuring SwitchA.
1. On SwitchA, enter global configuration mode from the privileged exec mode prompt by issuing the command
2. configure terminal The prompt "SwitchA(config)#" will be displayed, indicating you have entered global configuration mode.
3. To create VLAN 2 - Engineering, issue the command 4. vlan 2 name Engineering
Note: When typing in the names of VLANs, remember that name information is case sensitive.
5. To create VLAN 3 - Marketing, issue the command 6. vlan 3 name Marketing 7. To create VLAN 4 - Production, issue the command 8. vlan 4 name Production 9. To end the configuration process, type exit. 10. Confirm your configuration by issuing the command 11. show vlan
You should see the following output: SwitchA#show vlan VLAN Name Status Ports -------------------------------------- 1 default Enabled 1-24, AUI, A, B 2 Engineering Enabled 3 Marketing Enabled 4 Production Enabled 1002 fddi-default Suspended 1003 token-ring-defau Suspended 1004 fddinet-default Suspended
12. Optional: Issue the command 13. show vlan-membership
You should see the following output: SwitchA#show vlan-membership Port VLAN Membership Type Port VLAN Membership Type ----------------------------- ----------------------------- 1 1 Static 13 1 Static 2 1 Static 14 1 Static 3 1 Static 15 1 Static 4 1 Static 16 1 Static 5 1 Static 17 1 Static 6 1 Static 18 1 Static 7 1 Static 19 1 Static 8 1 Static 20 1 Static 9 1 Static 21 1 Static 10 1 Static 22 1 Static 11 1 Static 23 1 Static 12 1 Static 24 1 Static AUI 1 Static A 1 Static B 1 Static SwitchA# Note that all ports belong to VLAN 1 by default and that the membership type of each port is static.
14. Enter global configuration mode from the privileged exec mode prompt by issuing the command
15. configure terminal The prompt "SwitchA(config)#" will be displayed, indicating you have entered global configuration mode.
16. Assign Ethernet ports 0/1 and Ethernet 0/2 to VLAN 2 - Engineering. To assign an Ethernet port membership in a VLAN, you must enter interface configuration mode. Enter interface configuration mode for Ethernet 0/1 by issuing the command interface Ethernet 0/1
17. To assign Ethernet 0/1 to VLAN 2, issue the command 18. vlan-membership static 2 19. Repeat this process, assigning ports to VLANs as follows:
Ethernet 0/2 to VLAN 2 Ethernet 0/3 to VLAN 3 Ethernet 0/4 to VLAN 3
Ethernet 0/5 to VLAN 4 Ethernet 0/6 to VLAN 4 Ethernet 0/7 to VLAN 5
20. To end the configuration process, type exit. 21. Confirm your configuration by issuing the command 22. show vlan
You should see the following output: SwitchA#show vlan VLAN Name Status Ports -------------------------------------- 1 default Enabled 8-24, AUI, A, B 2 Engineering Enabled 1-2 3 Marketing Enabled 3-4 4 Production Enabled 5-6 1002 fddi-default Suspended 1003 token-ring-defau Suspended 1004 fddinet-default Suspended 1005 trnet-default Suspended -------------------------------------- VLAN Type SAID MTU Parent RingNo BridgeNo Stp Trans1 Trans2 --------------------------------------------------------------------------- 1 Ethernet 100001 1500 0 0 0 Unkn 1002 1003 2 Ethernet 100002 1500 0 1 1 Unkn 0 0 3 Ethernet 100003 1500 0 1 1 Unkn 0 0 4 Ethernet 100004 1500 0 1 1 Unkn 0 0 1002 FDDI 101002 1500 0 0 0 Unkn 1 1003 1003 Token-Ring 101003 1500 1005 1 0 Unkn 1 1002 --More-- 1004 FDDI-Net 101004 1500 0 0 1 IEEE 0 0 1005 Token-Ring-Net 101005 1500 0 0 1 IEEE 0 0 --------------------------------------------------------------------------- SwitchA# Ethernet ports 0/1 through 0/6 appear in the VLANs as configured; however, Ethernet port 0/7 does not show it belonging to any VLAN. Why?
23. Issue the privileged exec mode command 24. show interface ethernet 0/7
You should see the following output: SwitchA#show int e 0/7 Ethernet 0/7 is Disabled-no-vlan Hardware is Built-in 10Base-T Address is 00B0.64D1.F747 MTU 1500 bytes, BW 10000 Kbits 802.1d STP State: Disabled Forward Transitions: 1 Port monitoring: Disabled Unknown unicast flooding: Enabled Unregistered multicast flooding: Enabled Description: Duplex setting: Half duplex Back pressure: Disabled Notice that Ethernet port 0/7 is reporting that it is "Disabled-no-vlan". This message appears when a port has been assigned to a VLAN that has not yet been created.
Section 3 - Verifying VLAN Functionality In this section you will test the connectivity between two end-systems connected to ports that have been configured as members of the same VLAN and then to ports that are configured as members of different VLANs.
1. Connect one of your two PCs to SwitchA's Ethernet port labeled "1x". 2. On this PC, set the following IP configuration information:
IP address: 172.16.1.20 Subnet mask: 255.255.255.0 Default Gateway: 172.16.1.1
3. Connect the second PC to SwitchA's Ethernet port labeled "2x." 4. On this PC, set the following IP configuration information:
IP address: 172.16.1.21 Subnet mask: 255.255.255.0 Default Gateway: 172.16.1.1
5. From the PC plugged into SwitchA's Ethernet port 1x, ping IP address 172.16.1.21. Were you successful? Yes or No? Why?
6. From the PC plugged into SwitchA's Ethernet port 2x, ping IP address 172.16.1.20. Were you successful? Yes or No? Why?
7. You should have been able to ping between each PC because each is a member of the same VLAN. Now without changing IP address information on the PCs, move the network cable from SwitchA's Ethernet port 2x to 4x.
8. From the PC plugged into SwitchA's Ethernet port 1x, ping IP address 172.16.1.21. Were you successful? Yes or No? Why?
9. From the PC plugged into SwitchA's Ethernet port 4x, ping IP address 172.16.1.20. Were you successful? Yes or No? Why?
10. You should not have been able to ping between PCs. The PC attached to port 1x is a member of VLAN 2, while the PC attached to port 4x is a member of VLAN 3. Note that they both exist in the same subnet.
11. Do you think you will be able to ping the IP address of the switch from either connected PC? Why or why not?
12. Try to ping the IP address of SwitchA from the PC plugged into SwitchA's Ethernet port 1x. Were you successful? Yes or No? Why?
13. Try to ping the IP address of SwitchA from the PC plugged into SwitchA's Ethernet port 4x. Were you successful? Yes or No? Why?
14. The IP address of the switch is assigned membership to VLAN 1 by default. Only a PC that resides in the same subnet as the switch that is also a member of VLAN 1 will be able to ping the switch. Now without changing IP address information on the PCs, move the network cable from SwitchA's Ethernet port 4x to 10x.
15. From the PC that is connected to SwitchA's Ethernet port 10x, attempt to ping the switch. Were you successful? Yes or No? Why?
16. You should have been able to ping the switch when you were plugged into SwitchA's Ethernet port 10x. Ethernet port 10x is configured as a member of VLAN 1. Both the switch and the PC belong to the same subnet. If two end-systems were located in the same VLAN but were located on different subnets, would they still be able to communicate? Yes or No? Why?
Section 4 - Configuring an ISL Trunk Link In this section, you will create an ISL trunk link that will carry VLAN traffic between your primary and your secondary switch. To demonstrate the functionality gained by using a trunk port rather than a dedicated link, you will begin this section of the lab using a point-to-point configuration to forward VLAN traffic between the two switches. Once you have become familiar with how to configure a standard single-VLAN link between the two switches, you will configure an ISL trunk link. Before you begin, connect the two FastEthernet A ports using a crossover cable. To ensure this lab will work as expected, first test the connection between both switches. Ping the IP address of SwitchA (172.16.1.200). You should be successful. If not, check the cable between the FastEthernet ports of both switches. Do not proceed further until you can successfully ping between switches. Begin this part of the lab by configuring SwitchB.
1. On SwitchB, enter global configuration mode from the privileged exec mode prompt by issuing the command
2. configure terminal The prompt "SwitchB(config)#" will be displayed, indicating you have entered global configuration mode.
3. Create VLAN 2, specifying the name for the VLAN as "Engineering." Note: When typing in the names of VLANs, remember that name information is case sensitive.
4. Create VLAN 3, specifying the name for the VLAN as "marketing." USE ALL lower CASE.
5. Assign Ethernet ports 0/1 and 0/2 to VLAN 2. 6. Assign Ethernet ports 0/3 and 0/4 to VLAN 3. 7. Disconnect the cable plugged into SwitchA's port labeled "10x." Connect it to SwitchB's
Ethernet port labeled 1x. 8. From either PC, attempt to ping the corresponding PC. Were you successful?
Yes or No? Why? 9. You should not have been successful. When the switch received a ping for an end-
system that was not directly connected to it, it flooded the frame out all ports that belonged to the same VLAN as the originating end-system. What is missing (but required) are ports on each switch that have been configured as a member of VLAN 2 and are directly connected to each other.
10. On SwitchB, assign FastEthernet port 0/26 to VLAN2. On SwitchA, assign FastEthernet port 0/26 to VLAN2. A pathway between both switches that can carry traffic for VLAN 2 has been created.
11. From either PC, attempt to ping the corresponding PC. Were you successful? Yes or No? Why?
From SwitchA, attempt to ping the IP address of SwitchB (172.16.1.201). Were you successful? Yes or No? Why?
13. You should not have been successful. When you changed VLAN membership assignments on FastEthernet port 0/26, you disabled VLAN 1 traffic from being propagated between both switches. Now it's time to configure a trunk link that will support traffic from all VLANs.
14. Determine the current state of trunking on FastEthernet ports 0/26 and 0/27. Issue the privileged exec commands
15. show trunk a 16. show trunk b
You should see the following output: SwitchA#show trunk a DISL state: Off, Trunking: Off, Encapsulation type: Unknown SwitchA#show trunk b DISL state: Off, Trunking: Off, Encapsulation type: Unknown SwitchA# Note that "Off" is the default DISL state. "Off" disables trunking on the port and negotiates with the connected switch port to become a non-trunk port. There is no DISL trunking mode that will force a corresponding trunk partner port to successfully establish a trunk when one of the partner ports is configured with the DISL setting of "off."
17. Set the DISL trunk state to "Desirable." The DISL state "desirable" will to set the port to trunk mode if the connected port is set to "on," "desirable," or "auto". Enter global configuration mode from the privileged exec mode prompt by issuing the command configure terminal The prompt "SwitchA(config)#" will be displayed, indicating you have entered global configuration mode.
18. Enter interface configuration mode for trunk port a by issuing the command 19. interface fastethernet 0/26 20. Issue the command 21. trunk desirable 22. To exit from interface configuration mode to privileged exec mode, issue the key
sequence Ctrl+Z. 23. Confirm your configuration by issuing the command 24. show trunk a
You should see the following output: SwitchA#show trunk a DISL state: Desirable, Trunking: Off, Encapsulation type: Unknown SwitchA# If the DISL state reports other than what is expected, wait a few seconds and check the state of the trunk again.
25. On SwitchB, set the DISL trunk state to "Auto". The DISL state "auto" will set the port to become a trunk if the connected switch port has initiated negotiation. In order to successfully establish a trunk connection with a partner port, the connected partner switch port must be set to the "on" or "desirable" state. Enter global configuration mode from the privileged exec mode prompt by issuing the command configure terminal The prompt "SwitchB(config)#" will be displayed, indicating you have entered global configuration mode.
26. Enter interface configuration mode for trunk port a by issuing the command 27. interface fastethernet 0/26 28. Issue the command 29. trunk auto
30. To exit from interface configuration mode to privileged exec mode, issue the key sequence Ctrl+Z.
31. Confirm your configuration by issuing the command 32. show trunk a
You should see the following output: SwitchB#show trunk a DISL state: Auto, Trunking: On, Encapsulation type: ISL SwitchB# If the trunking state reports a state other than what is expected, wait a few seconds -- the DISL negotiation process between ports may still be in progress. Then, check the state of the trunk again. For example, the following output was displayed the first two times the command show trunk a was issued when this lab scenario was created: SwitchB#show trunk a DISL state: Auto, Trunking: Off, Encapsulation type: Unknown SwitchB# SwitchB#show trunk a DISL state: Auto, Trunking: Off, Encapsulation type: Unknown
33. Determine if the trunk port is carrying traffic between switches for VLAN 1. Attempt to ping SwitchA from SwitchB. Ping 172.16.1.200. Were you successful? Yes or No? Why?
34. You should have been successful. The trunk link carries frames for all VLANs (by default) between switches. Determine if the trunk port is carrying traffic between switches for VLAN 2. From either PC, attempt to ping the corresponding PC. Were you successful? Yes or No? Why?
35. You should have been successful. You have created a trunk that supports ISL encapsulation that transports frames from all VLANs between your two switches.
36. From SwitchB, verify that your trunk is, in fact, configured to carry all VLAN traffic between switches. Issue the command show trunk a allowed-vlans You should see the following output: SwitchB#show trunk a allowed-vlans 1-1005 SwitchB# When the Trunk Doesn't Appear To Work Properly:
37. On SwitchA, connect the network cable from the PC with the IP address 172.16.1.20 into the switch port labeled "3x" (VLAN 3).
38. On SwitchB, connect the network cable from the PC with the IP address 172.16.1.21 into the switch port labeled "3x" (VLAN 3).
39. From the PC that is connected to SwitchA's Ethernet port 3x, attempt to ping the IP address of the neighboring PC (remember that both PCs are in VLAN 3 and the trunk has been verified to be working). Were you successful? Yes or No? Why?
40. You should not have been successful. Even though VLAN 3 exists on both switches, the VLAN name "Marketing" on SwitchA is not the same as the VLAN name on SwitchB "marketing." CaSe matters when configuring VLAN names. Using VTP to manage VLAN configuration for even two switches will help ensure VLAN naming consistency in a network.
Section 5 - More VTP Configuration In this section, you will learn more about VTP configuration. Specifically, you will see how VTP revision numbers are important in determining which VLAN configuration information is maintained, and which is overwritten. Additionally, you will learn about the implications of having a switch operate in VTP transparent mode and later decide to switch its mode of operation to VTP client or VTP server.
Begin this part of the lab by working with SwitchB. 1. On SwitchB, issue the privileged exec command 2. show vtp
You should see the following output: SwitchB#show vtp VTP version: 1 Configuration revision: 2 Maximum VLANs supported locally: 1005 Number of existing VLANs: 7 VTP domain name : VTP password : VTP operating mode : Server VTP pruning mode : Disabled VTP traps generation : Enabled Configuration last modified by: 172.16.1.201 at 00-00-0000 00:00:00 Note the Configuration revision number (2). On this switch, two VLANs were created (VLAN 2 and VLAN 3). The switch indicates that there are currently seven existing VLANs. They would be the default VLANs 1, 1002, 1003, 1004, 1005, and the administratively configured VLANs (2 and 3).
3. On SwitchA, issue the privileged exec command 4. show vtp
You should see the following output: SwitchA#show vtp VTP version: 1 Configuration revision: 0 Maximum VLANs supported locally: 1005 Number of existing VLANs: 9 VTP domain name : CertZone VTP password : VTP operating mode : Transparent VTP pruning mode : Disabled VTP traps generation : Enabled Configuration last modified by: 172.16.1.200 at 00-00-0000 00:00:00 SwitchA# Note the Configuration revision number is 0 even though on this switch four new VLANs have been created. When a switch has been configured in VTP transparent mode, the configuration revision number does not increment. The configuration revision number for a switch operating in VTP transparent mode will remain at 0.
5. On SwitchB, enable VTP operation on the switch. Set the VTP domain name to "CertZone." (Reference Section 1, "Configuring VLAN Trunk Protocol (VTP)," if you require assistance).
6. Confirm your configuration by issuing the command 7. show vtp
You should see the following output: SwitchB#show vtp VTP version: 1 Configuration revision: 1 Maximum VLANs supported locally: 1005 Number of existing VLANs: 7 VTP domain name : CertZone VTP password : VTP operating mode : Server VTP pruning mode : Disabled VTP traps generation : Enabled Configuration last modified by: 172.16.1.201 at 00-00-0000 00:00:00
SwitchB# Note that the VTP domain name is identical to the VTP domain name set on SwitchA. Also note that SwitchB is operating in VTP server mode.
8. On SwitchA, recall that there are nine existing VLANs (as noted in Step 2 of Section 5). Set the VTP mode from transparent to server. From global configuration mode, issue the command vtp server
9. Confirm your configuration by issuing the command 10. show vtp
You should see the following output: SwitchA#show vtp VTP version: 1 Configuration revision: 1 Maximum VLANs supported locally: 1005 Number of existing VLANs: 7 VTP domain name : CertZone VTP password : VTP operating mode : Server VTP pruning mode : Disabled VTP traps generation : Enabled Configuration last modified by: 172.16.1.201 at 00-00-0000 00:00:00 SwitchA# Although SwitchA had more VLANs configured, the VTP database information from SwitchB overwrote the entire VLAN configuration that had been completed previously in Section 2, "Creating VLANs." When changing a switch from vtp transparent operation to vtp client or vtp server mode, all configuration information will be lost because vtp transparent mode does not maintain a configuration revision value. Do not configure a switch offline using transparent mode operation and expect that this switch will propagate all its information into the network.
11. What happened to the static VLAN port assignments on SwitchA when the VTP database from SwitchB overwrote the VLAN configuration information on SwitchA? Issue the privileged exec command show vlan-membership You should see the following output: SwitchA#show vlan-membership Port VLAN Membership Type Port VLAN Membership Type ----------------------------- ----------------------------- 1 2 Static 13 1 Static 2 2 Static 14 1 Static 3 3 Static 15 1 Static 4 3 Static 16 1 Static 5 4 Static 17 1 Static 6 4 Static 18 1 Static 7 5 Static 19 1 Static 8 1 Static 20 1 Static 9 1 Static 21 1 Static 10 1 Static 22 1 Static 11 1 Static 23 1 Static 12 1 Static 24 1 Static AUI 1 Static A 2 Static B 1 Static Even though the VLAN configuration information from SwitchB overwrote the VLAN configuration information from SwitchA, the static VLAN assignments on SwitchA
remained as configured in Section 2, "Creating VLANs." If SwitchB had configured its VLANs differently, the end-system attached to port 7 assigned to VLAN 5 could have become a member of the "BalletSchool" rather than the "Accounting" VLAN. When you switch VTP modes, make sure you are aware of all the consequences -- seen and unseen -- prior to making the change.
Section 6 - Viewing Spanning Tree Protocol Information In this section, you will use the basic Spanning Tree Protocol (STP) command show spantree to verify STP operation. Begin this part of the lab by working with SwitchA.
1. On SwitchA, display the Spanning Tree Protocol configuration status of each port on the switch. Issue privileged exec command
2. show spantree The output of the command show spantree will display, in sequential order, STP information for all ports that are members of each VLAN, beginning with VLAN 1. When all STP information for ports that are members of VLAN 1 have been displayed, information for all ports that are members of VLAN 2 is displayed. This process continues until all STP information for all VLANs has been displayed.
Section 7 - Configuring ISL Routing In this section, you will configure inter-VLAN communication for VLANs 1, 2, and 3 in our network. The IP subnetting information for this section is as follows: 1 default 172.16.1.0 /24 2 Engineering 172.16.2.0 /24 3 marketing 172.16.3.0 /24
1. Connect one end of a standard straight-through Category 5 cable to a Cisco router's FastEthernet interface (the router must support ISL encapsulation in order for this to work properly).
2. Connect the other end of the standard straight-through Category 5 cable to Port B on SwitchA.
3. On SwitchA, set the DISL trunk mode to "On." (Reference Section 1, "Configuring VLAN Trunk Protocol (VTP)," if you require assistance).
4. On the Cisco router's FastEthernet interface, create a subinterface for each VLAN to be routed.
5. For each subinterface, enable ISL encapsulation using the subinterface configuration command
6. encapsulation isl <VLAN ID> 7. Assign an IP address to the subinterface from the subnet range that corresponds to the
VLAN to be routed on the subinterface. To route between VLANs, the configuration entered on the router should look like: RouterA#configure terminal RouterA(config)#interface fastethernet 0/0.1 RouterA(config-subif)#encapsulation isl 1 RouterA(config-subif)#ip address 172.16.1.100 RouterA(config-subif)#encapsulation isl 2 RouterA(config-subif)#ip address 172.16.2.100 RouterA(config-subif)#encapsulation isl 3 RouterA(config-subif)#ip address 172.16.3.100
8. To test routing between VLANs: on SwitchA, connect the network cable from the PC with the IP address 172.16.1.20 into the switch port labeled "1x" (VLAN 2).
9. Change the IP address of the PC connected to SwitchA port 1x to 172.16.2.20, subnet mask 255.255.255.0, default gateway 172.16.2.100.
10. Change the IP address of the PC connected to SwitchB port 3x to 172.16.3.21, subnet mask 255.255.255.0, default gateway 172.16.3.100.
11. From the PC connected to SwitchA, attempt to ping the IP address 172.16.3.21. Were you successful? Yes or No? Why?
The VLAN Wrap-Up Once you have completed the CCNA VLANs tutorial, study questions, and (this) accompanying lab, you should be able to:
• Define the term "Virtual Local Area Network" or "VLAN" • Describe the benefits of implementing VLANs • Configure VLANs using Cisco Catalyst IOS-based LAN switches such as the Cisco
Catalyst 1900 series switch • Identify key differences between Cisco's proprietary ISL and IEEE 802.1q industry-
standard trunking protocols • Configure trunking on a Cisco Catalyst IOS-based LAN switch such as the Cisco Catalyst
1900 series switch • Identify the purpose of the VLAN Trunking Protocol (VTP) • Configure VTP parameters including VTP domain name, VTP password, VTP operational
modes (Server/Client/Transparent), and VTP pruning • Identify how Cisco's implementation of Spanning Tree Protocol operates when multiple
VLANs are configured and when connecting to non-Cisco Layer 2 devices • Identify the appropriate "show" commands to verify VLAN connectivity and ensure proper
Spanning Tree operation • Describe how to route between VLANs when using ISL • Identify commands to troubleshoot common VLAN issues.
In this lab, you: • Configured VLANs on an IOS-based LAN switch • Configured trunking on an IOS-based LAN switch • Configured VTP parameters that included VTP domain name and modified operational
modes. (Consult the CCNA VLANs white paper for information on how to set the VTP password and how to enable VTP pruning).
• Identified how Spanning Tree Protocol operates when multiple VLANs are configured • Used a variety of show commands to verify VLAN connectivity, including the command
show spantree to ensure proper Spanning Tree Protocol operation. • Set up routing between VLANs using ISL • Used a variety of show commands to troubleshoot common VLAN issues.
Good luck with your exam! 11 WAN Protocols This Study Guide addresses the characteristics of a Wide Area Network (WAN), and differentiates it from a Local Area Network (LAN). These characteristics include: � The geographic area occupied by the network � The scope of control and management of the network � The transmission methods and media used to build the network � The type of traffic that crosses the network 11.1 Tutorial Introduction It's here. It's live. It's the CCNA 2.0 exam. If you are preparing for the CCNA certification exam version 2.0, you have a more difficult task than those who took the CCNA 1.0 exam. Cisco published a long list of exam objectives for the CCNA 1.0 exam. That list of objectives seemed random -- even sloppy -- to many people, but nevertheless they were published, and it was pretty clear to those preparing for the exam which material to study. For the CCNA 2.0 exam, Cisco has
taken a different approach. They have published a much-abbreviated list of exam objectives. Here is what the exam outline for CCNA 2.0 lists as WAN Protocols objectives:
WAN Protocols • ISDN • Frame Relay • HDLC • ATM
Source: Cisco ccna 507 specs (Note: is not associated with Cisco.)
For me, this list leaves a little something to be desired. Where can you get more detail regarding these objectives and what you are expected to know for the exam? Let's refer to the official course material for exam preparation. The official Cisco course that corresponds to the CCNA exam is the Interconnecting Cisco Network Devices (ICND) exam. The Cisco web site offers a course outline for the ICND course. In the area of WAN technologies, the course outline offers the following:
Extending the Network to WANs Instructs the student on methods of connecting to wide area-networks.
• Establishing Serial Point-to-Point Connections
• Completing an ISDN BRI Call • Establishing a Frame Relay PVC
Connection Source: Cisco ccna 507 specs (Note: is not associated with Cisco.)
Read it over carefully. Do you feel comfortable now that you know what information to study to be prepared for the WAN material on the CCNA exam? No? That's okay. You might notice that there are four objectives in the exam outline, but only three in the course material. ATM is mentioned as an exam topic, but not covered in the course material. Why? Cisco does not include ATM in its Interconnecting Cisco Network Devices (ICND) exam. ATM laboratory equipment is quite expensive and complex, so at the level of CCNA, it is more useful to focus on ISDN, Frame Relay, PPP, and HDLC. To put ATM in perspective, both ISDN and Frame Relay were developed as relatively small parts of the ATM specifications. To discuss ATM at even a rudimentary level would require a significant addition to the CCNA course and would warrant a separate tutorial. ATM is covered at the CCIE level and will be the topic of a forthcoming tutorial. That leaves us with ISDN, Frame Relay, and HDLC. Though there are only three items on Cisco's exam outline that refer to WAN technologies, there is a lot of material that can be extrapolated from them. This paper will attempt to do just that, as well as fill you in on some of the theory that applies to basic WAN technologies. Let's start by trying to define a WAN. What exactly is a Wide Area Network? There are certain characteristics that define, or at least typify, a Wide Area Network (WAN), and differentiate it from a Local Area Network (LAN). These characteristics include:
• The geographic area occupied by the network • The scope of control and management of the network • The transmission methods and media used to build the network • The type of traffic that crosses the network.
A WAN is a network that spans a large geographic area. While the typical LAN would span the area of one building, or sometimes only one floor in a building, a WAN would span across multiple cities, multiple countries, or even multiple continents. A corporate LAN might connect, for example, the first, second, third, and fourth floors of the corporate headquarters. The corporate WAN would connect the headquarters office in Tucson with the remote offices in Boston, Detroit, Nashville, Houston, Denver, and Los Angeles. In each of the remote offices is a LAN, and the WAN allows for each remote LAN to communicate with the corporate LAN. The WAN might also allow for communications between each of the remote office LANs directly, without each going through the corporate headquarters. In corporate LAN environments, there is usually one person or group of people that is responsible for administration of the network. These people have complete control over the LAN, since all of the equipment that is part of the network is owned and operated by the company on company property. The corporation owns all of the systems, hubs, switches, and even wires that make up the LAN. Even if some of the hardware is leased, it is still totally controlled by employees of the company, and company management is free to make all decisions regarding how the LAN should be configured and operated. In a WAN environment, this is not the case. Certain portions of the WAN are composed of company-owned equipment, while others are built from equipment owned and operated by the company that is offering the wide area communications service -- the carrier. A corporation implementing a WAN buys service from a carrier. The carrier provides service that meets certain expectations of the corporation based on an agreement between the two parties. Beyond the details of that agreement, the corporation's network management staff has no control over the carrier network. Often you will have no knowledge at all regarding the carrier network and how it is configured. The equipment that you operate and control on your company property is referred to as Customer Premises Equipment (CPE). Anything else is part of the carrier network. The point that separates your CPE from the carrier network is called the Line of Demarcation, or simply the "demarc." When you consider communication between two devices on a LAN, you typically think of the end-to-end communications between those two devices without considering any intervening devices, such as hubs, switches, or routers. You consider the protocols involved in that end-to-end communication with respect to the OSI seven-layer model. WAN communications, however, are a bit different. The end-to-end communication between two devices separated by a WAN is divided into different areas of functionality. Within each area of functionality, certain parts of the communication are accomplished. Different devices are responsible for different areas of functionality. WAN communications can be broken up into different planes of operation, all operating at the same layer, creating a 3-dimensional communications model. These planes are the User plane (U-plane), the Control plane (C-plane), and the Management plane (M-plane), and are included as part of the Broadband ISDN specification. These planes do not always map cleanly to the OSI model. Consider a simple form of WAN communications -- a telephone call. You want to talk to a friend in another city. You cannot simply pick up the phone and start talking -- you must first dial the other party's phone number. When you dial the phone, you communicate with a device at the entry point to the phone company's network. Information necessary to place the call and to keep you connected to the phone company network is transmitted at this point. This is communication on the C-plane, since this information is for call control. Next, the equipment within the phone company's network determines the end-to end path to the destination -- your friend's telephone. If a path exists, the end-to-end connection must be established within the telephone company's network. This would be M-plane communications. Once the end-to-end path is determined and the connection established, your friend answers the call and you begin your voice conversation. This communication, between you and your friend, takes place on the U-plane. Your spoken words are the User data that is transmitted over the Wide Area Network. Data communications over a WAN can be thought of in a similar way. There is communication between CPE devices at the source side of the customer network and the carrier network. Then there is communication between devices within the carrier network. Finally,
there is communication between the carrier network and the CPE at the destination side of the customer network. Consider the WAN shown in Figure 1.
Figure 1. Suppose that a computer on the Token Ring LAN at Site A wishes to communicate with another computer on the Ethernet LAN at Site B. First, the computer communicates with the Site A router. The Site A router realizes that the destination computer is not on the local network and prepares to route the traffic over the WAN, crossing the carrier network. The router is physically connected to the carrier network with a device such as a modem or a CSU/DSU. These devices sit at the border or demarc of the CPE. Everything on the other side of this device is part of the carrier network. The modem or CSU/DSU is the Data Circuit Terminating Equipment, or DCE. The router on the Site A network is the Data Terminal Equipment, or DTE. The first part of WAN communications involves the communication between the DTE and the DCE. Communication of this type is on the C-plane. Next, a path to the destination through the carrier network must be determined and a connection must be established. This occurs on the M-plane. Finally, communication between the computers in each site takes place on the U-plane. The transmission methods and media used for a Local Area Network differ significantly from those used in a Wide Area Network. In a LAN environment, the network usually uses Ethernet, Token Ring, or FDDI/CDDI topologies. The connections are made using Category 5 Unshielded Twisted Pair (Cat 5 UTP), Type 1 Shielded Twisted Pair (Type 1 STP) wiring, or Fiber optic cable. Ethernet offers bandwidth of 10, 100, or even 1000 megabits per second (Mbps). Token Ring offers at 4 or 16 Mbps, and FDDI/CDDI provides 100 Mbps. WAN transmission technologies usually (but not always) operate with much lower bandwidth than those used in LANs. WAN bandwidth is often measured in Kilobits per second (Kbps) rather than Mbps. Many WAN links operate at 56 Kbps, the same as most PC user's modems. Speed alone cannot distinguish between WAN and LAN, as the emerging 10 Gigabit Ethernet (10GE) and the Synchronous Optical Network (SONET) OC-192 rate technologies run over exactly the same physical layer. When Dense Wavelength Division Multiplexing (DWDM) is added between 10GE or SONET OC-192, hundreds of 10GE or OC-192 signals can run over a single fiber. However, even at higher bandwidths, the total bandwidth available in WANs is often divided among several links. This bandwidth is purchased from carrier networks at great expense. Due to the high cost of this bandwidth, it is common practice to purchase only the bandwidth that it absolutely necessary to provide the required connectivity. With this in mind, it is essential that WAN bandwidth is optimized, and that only traffic that must cross the WAN link should be allowed to do so. It is fair to say that if you encounter a slow speed, it will be in a WAN. We are encountering very low speed WAN applications today, such as pagers and wireless web devices. Early WAN implementations were analog serial links between sites. Later, they developed into digital connections, but many of the techniques used to carry traffic over today's digital networks were simply adapted from the earlier serial technologies. A first step in understanding WAN technologies is examining how data is carried over the WAN link. Let's start at the physical layer. There are all sorts of WAN devices, and you will hear names you are familiar with and names you are not. Some of the devices you are probably used to are
modems, routers, and access servers. Other devices, which you may not have seen before, are Channel Service Units (CSUs), Digital Service Units (DSUs), Terminal Adapters, and WAN switches. WAN devices are most often connected using twisted pair wires or serial cables. When discussing WAN technologies, you will hear two terms frequently: DTE and DCE. DTE stands for Data Terminal Equipment, and in terms of WAN communications, this could be an actual terminal, a phone device, or a router. DCE stands for Data Circuit-terminating Equipment. An example of a DCE device would be a WAN switch. WAN technologies often focus on the communication between DTE and DCE. While this model is also used in LAN technologies, there are differences when considering WANs. While the layer 1 and layer 2 connectivity between DTE and DCE on LANs is usually connectionless, it is usually connection-oriented in WANs. Many WAN protocols function to establish, monitor, and maintain the connection between DTE and DCE. PPP, the Point-to-Point Protocol, establishes connectivity between two layer 2 endpoints. Under PPP are several subprotocols that do such things as authenticate users, assign addresses, etc. These subprotocols are control mechanisms for layer 2, and do not belong to layer 3. There can be more than one protocol per layer; think of the difference at layer 3, for example, between routing and routed protocols. Examples of the User Plane and Control Plane in LANs include the following: LAN Examples
OSI model layer User Plane Control Plane
Network IP ARP, ICMP, IGMP, DHCP, routing protocols
Data Link LLC
MAC 802.1Q VLAN802.1D bridging BPDUs802.5 monitor frames
Physical 802.3 medium independent signaling 802.3 physical layer signaling
When you make a telephone call, you pick up the phone and wait for a dial tone. The dial tone indicates to you that you have a connection to the telephone company's network. You dial the phone number and wait for a connection to be established with the phone of the person you are calling. While you wait for your call to go through, you remain connected to the phone company's network, via telephone wires at layer 1, and certain protocols at layer 2. These protocols are control protocols, and function on the C-Plane. Framing and Frame Types If you examine network communications from the point of view of the OSI reference model, you understand that functions performed at each layer pass information to the layers above and below it. When a computer wants to communicate with another computer on a network, information is taken from higher layers, and passed to lower layers, with each layer adding its own information (header) to the data from the layer above, until finally the data is sent across the communications medium. At each layer, the unit of information has a different name. At the network layer, for example, it is called a packet. At the Data Link layer it is called a frame, and at the physical layer it might be referred to as bits or bytes. It is the Data Link frame that we will be most concerned with during this discussion. SDLC
During the 1970s, there was this company called IBM. You may have heard of them. At the time, people at IBM were working on a method for efficient serial communications in the Systems Network Architecture (SNA) arena, which facilitates communications for IBM mainframe computers, terminals, and other related devices. The result of their work was the Synchronous Data Link Control protocol, or SDLC. SDLC defined a method for carrying information at the Data Link layer (hence the words "Data Link" in its name). Remember that SDLC predates the ISO Open Systems Interconnection Reference Model. The SDLC frame format included fields for addressing, control information, user data, and error checking. The SDLC frame is shown in Figure 2.
Figure 2. The SDLC frame comprises six fields, defined below:
• Flag -- The Flag field indicates the start and end of the SDLC frame. It also serves to initiate and terminate error checking. The field is 1 byte long, and always contains the value 0x7E.
• Address -- The Address field contains the SDLC address of the secondary station. This is the destination address for the information contained in the frame. This could be a single station, a group of stations indicated by a group address, or if the information is intended for all stations, a broadcast address. This field can be either 1 or 2 bytes in length.
• Control -- The Control field contains information used to provide flow control. This field can be in one of three formats, depending on the function of the SDLC frame. SDLC frames are either Information frames, Supervisory frames, or Unnumbered frames. The Control field is either 1 or 2 bytes in length.
• Data -- The actual data carried by the frame goes in the Data field. This field is variable in length.
• FCS -- The Frame Check Sequence field is used to store the result of an error checking algorithm to catch errors in the frame. The algorithm is executed by the sending station, and then re-executed by the receiving station. If the result is different, then the frame contains an error.
SDLC is the grandfather of all WAN protocols, and, as you will see, forms the basis for all the other protocols covered by Cisco's first WAN protocols exam objective. HDLC The International Organization for Standardization (ISO) worked toward objectives similar to those of IBM for SDLC. The ISO developed its own HDLC protocol standard. They developed things a bit differently than IBM did, though this is not really evident when examining the HDLC frame format. The differences are quite fine, as in the bit order of certain fields. The basic form of the protocol is closely aligned with SDLC. The HDLC frame format is shown in Figure 3.
Figure 3. Look familiar? Good! The frame consists of six fields with the same functions as the SDLC frame fields, except that HDLC has an "Information" field where the SDLC Data field is. You might also have noticed that the HDLC frame does not have a field to indicate which protocol is being carried in the frame. The lack of a protocol field means that HDLC does not inherently support multi-
protocol traffic. Cisco's implementation of HDLC is a proprietary one that is modified slightly to allow for protocol information. Because of its modification, Cisco's HDLC will not inter-operate with any other vendor's HDLC. We can examine HDLC in terms of both the OSI model and the 3-dimensional model. Here are some HDLC examples: HDLC Examples
OSI Model Layer User Plane Control Plane
Network IP ICMP, IGMP, DHCP, routing protocols
Data Link HDLC stacker/predictor compression SLARP
Physical most serial
LAP, LAPB, LAPD Continuing in the tradition of solving new problems by borrowing from existing technologies and adapting them to the new situation, the International Telecommunication Union Telecommunications Standardization Sector (ITU-T) -- formerly known as the CCITT -- borrowed the HDLC standard from the ISO and modified it slightly to create the Link Access Procedure (LAP). LAP is the Data Link layer protocol for the ITU-T X.25 specification. LAP was modified further still to create the Link Access Procedure-Balanced (LAPB). Figure 4 provides a look at the LAPB frame format:
Figure 4. No, this isn't a misprint. At the byte level, the LAPB frame format looks exactly like the HDLC frame format. There are some bit encoding differences that do not show up in most displays, and really are of little concern unless you are designing integrated circuits. The variations come mostly within the Information field, where the various types of LAPB frames (Information, Supervisory, or Unnumbered) are specified. One significant difference that is not apparent from examining the frame format is the use of the Address field. Since LAPB is used in Point-to-Point links, where addressing is carried at layer 3, the Address field is utilized for another purpose. The LAPB Address field is always one of two values: 0x01 or 0x03. Frames initiated by DTE devices to DCE devices (and their responses) have the value 0x01 in the Address field. Frames initiated by DCE devices to DTE devices (and their responses) have the value 0x03 in the Address Field. When developing specifications for ISDN, the CCITT (Committee Consultative de Internationale Telegraphique et Telephony) implemented a slightly modified LAP protocol for Data Link functions on the ISDN D channel (ISDN is described in more detail later). The adapted protocol is called Link Access Procedure-D channel. Catchy, isn't it? Take a look at Figure 5, the frame format for LAPD.
Figure 5. There are certainly no surprises here. The frame format is just like the LAP and LAPB frame format, which is just like HDLC, which is almost like SDLC. It makes you wonder, doesn't it? Are all the latest and greatest technologies really just revamped versions of the old technologies?
Maybe, but it is not such a bad thing. When you have a really solid foundation to work with, it makes sense to build upon it rather than create something totally new. New technologies evolve out of older ones as new sets of problems arise that couldn't be solved by the original specifications. It's really just a natural progression. PPP As you may have noted while studying the frame types above, none of the protocols we have covered so far have had any support built in for different protocol types. This made them of limited use in multi-protocol environments without proprietary modifications. As demand for multi-protocol connectivity in both synchronous and asynchronous environments increased, a solution was developed to accommodate this demand. Point-to-Point Protocol (PPP) was developed in the late 80s in order to provide multi-protocol support to Wide Area networking, as well as to provide for end user connectivity to corporate networks and the Internet. For connectivity to the Internet or corporate IP networks, PPP became the successor to an earlier protocol, Serial Line Internet Protocol (SLIP). PPP has a number of optional features that are especially useful in dialup applications (including ISDN). These features include user authentication, either acceptance of user-proposed IP addresses or dynamically assigning IP addresses for the duration of a call, etc. PPP Frames The PPP frame format evolved from the ISO HDLC frame format with minor modification. The PPP frame format is shown in Figure 6.
Figure 6. The PPP frame consists of the following fields:
• Flag -- This field always has the value of 0x7E. This field indicates the start or end of a PPP frame. It is one byte in length.
• Address -- PPP does not assign individual addresses at the Data Link layer. This field contains the broadcast address of 0xFF. This field is one byte long.
• Control -- This one-byte field is always set to 0x03. This indicates an HDLC Unnumbered Information frame. PPP frames with any other value in this field are dropped.
• Protocol -- This two-byte field indicates the upper layer protocol that is encapsulated in the PPP frame.
• Data -- This field is variable in length and contains the actual application data portion of the frame.
• FCS -- The Frame Check Sequence field is a checksum used for error checking. Most PPP implementations use a 2-byte (16-bit) FCS field, but some implementations can use a 4-byte (32 bit) FCS.
PPP Link Establishment and Encapsulation Steps In order to carry multi-protocol traffic across a synchronous or asynchronous link, PPP uses a layered approach to initialize connections and to encapsulate and transfer data. At the Physical layer, PPP supports both synchronous connections, ISDN, for example, or asynchronous connections, such as a modem connection. At the Data Link layer, PPP functions are provided by two core sets of protocols, the Link Control Protocol (LCP) and the Network Control Protocol (NCP). LCP is responsible for tasks such as establishing, configuring, and testing the data-link connection. This includes tasks like authentication or callback. The Network Control Protocol is actually a family of protocols; one for each of the supported higher level protocols that is carried over the link by PPP. Each supported higher level protocol is assigned a number, and that number is specified in the Protocol field of the PPP frame. Some of the supported protocols and their assigned numbers are:
• 0x0021 IP • 0x0027 DECnet Phase IV • 0x0029 AppleTalk • 0x002b Novell IPX
Keep in mind that the protocols that make up the NCP are control protocols that support the operations of the various higher layer protocols. When examining the function of these control protocols, it is important to remember that they operate at layer 2 of the OSI model, though the protocols they are designed to support operate at layer 3. Again, we can examine PPP in relation to the OSI model and the 3-dimensional model. Here are some examples: PPP Examples
OSI Model Layer User Plane Control Plane
Network IP ARP, ICMP, IGMP, DHCP by proxy, routing protocols
Data Link PPP NCP, LCP, CHAP/PAP
Physical most serial
In order to establish a PPP connection, a number of steps must be performed. First, the LCP frames are sent to establish certain connection parameters; including compression, authentication protocol, maximum receive unit (MRU), FCS format, and callback options. Once the link is established, LCP is used to test the link and terminate the link when required. If authentication has been configured, this is performed after the link is established. PPP authentication can use either the Password Authentication Protocol (PAP), or the Challenge Handshake Authentication Protocol (CHAP). The protocol used will be specified along with other configuration options during the initial link establishment. The devices on either side of the link must both support the authentication protocol that is selected for it to be used. Using PAP, the remote device is authenticated by the local device through the use of a name and password. The remote device sends the name and password information in clear text across the link until the local device accepts or rejects it, or until the link is terminated. This process is called a two-way handshake. The thing to remember is that when using PAP, the information is sent across the link in clear text. This means that it is readable by anyone. A network analyzer could easily capture the information. Furthermore, since the remote device initiates authentication, captured information could be resent from another device at a later time, allowing that device to be authenticated. This is known as a playback attack. PAP is not a strong authentication protocol, and it is not recommended for general use. Resort to PAP authentication when a remote device does not support CHAP. The CHAP protocol differs from PAP in a number of ways. First, CHAP uses a three-way handshake. Once the initial connection is established, the host device sends a challenge to the remote device. The remote device sends a response that includes a value calculated using a "one-way hash" function. This function is performed against a secret password that is known by the devices at both sides of the connection. The host device performs its own "one-way hash" and compares the value it generates to the one received from the remote device. If the two values match, then the remote device is authenticated, if they do not, then authentication is rejected and the connection is terminated. This 3-way handshake is repeated at random intervals throughout the duration of the connection. Repeating this challenge process at random intervals helps to minimize the vulnerability of the host device to a playback attack, since the actual value required for authentication will continually be changing. Another significant difference between CHAP and PAP is that while using CHAP, the local device is in control of how often the authentication challenges are issued. Note that with CHAP, the actual secret password is never transmitted across the link, only the hash value is sent. The hash
function that is performed is sufficiently complex that it is impossible to compute the actual secret password from the hash value. This makes CHAP much more secure than PAP. PPP Features/Functions on Cisco Routers The Cisco IOS offers many commands that pertain to PPP. Some of the commands are configuration commands, others are for troubleshooting or verifying configuration information. To configure PPP encapsulation on a Cisco router interface, first enter Interface Configuration Mode for the desired interface. For example, if you were configuring interface Serial 0, then you would use the following commands from Privileged Exec Mode: ! enter Configuration Mode: Router#config term ! enter Interface Configuration Mode: Router(config)#int s0 ! configure PPP encapsulation: Router(config-if)#encapsulation ppp ! exit Configuration Mode: Router(config-if)#^Z Note that PPP encapsulation must be configured on both sides of the link. Here are some of the many additional IOS commands for configuring various PPP options.
• ppp compression -- Configures the compression options for the PPP link. • ppp timeout -- Configures the timeout value for PPP link establishment. • ppp max-bad-auth -- Configures authentication for multiple failed authentication attempts. • ppp authentication -- Configures the PPP authentication type. • ppp pap -- Configures PAP authentication options. • ppp chap -- Configures CHAP authentication options.
For a complete list of IOS commands for PPP configuration, use IOS help from Interface Configuration Mode as follows: Router(config-if)#ppp ? (Remember the space before the "?") It is likely that one of the first things that you will configure for your PPP connection will be authentication. If you choose to use authentication, there are four configuration options:
• PAP only -- Configures the interface for PAP authentication only. • CHAP only -- Configures the interface to use CHAP authentication only. • PAP first, then CHAP -- Configures the interface to attempt to use PAP first, but if that is
refused, the interface will attempt to use CHAP. • CHAP first, then PAP -- Will configure the interface to attempt to use CHAP first, but if
that is not supported, the interface will attempt to use PAP. The last option above is perhaps the most typical configuration. To configure an interface to use this option, use the following command from Interface Configuration Mode: Router(config-if)#ppp authentication chap pap On each router, you need to configure the name and password used for authentication. The IOS command to accomplish this is Router(config)#username name password secret The name parameter is the hostname of the router to be authenticated. The secret parameter is the password that will be used for authentication. This must be the same on both routers for CHAP authentication to work properly, since both routers need to use this value to perform the "one-way hash" function. Remember that when using CHAP the actual password is not transmitted across the PPP link. You can use the show interfaces IOS command to examine the PPP configuration on a Cisco router. Use this command to verify that PPP encapsulation is being used, to verify that the connection is up, and to examine which NCP upper-layer protocol functions are in use.
Frame Relay One of the most popular WAN technologies today is Frame Relay. Frame Relay WAN connections are widely deployed because of the flexibility and relatively low cost of Frame Relay technology. Frame Relay Connections Frame Relay technology is often depicted in books with network diagrams showing a local router with a WAN connection to a "cloud." Out of the other side of the cloud is another WAN connection to a remote router. These drawings often leave those new to Frame Relay with a sense of doubt about what is really going on with Frame Relay technology. The reason that Frame Relay connections are shown coming into and out of a cloud is that Frame Relay is a Data-Link Layer specification that defines the connection from the CPE to the DCE. Now that I have explained that, don't you feel much better? No? Don't worry, I didn't expect you to. Here's some more detail. Frame Relay specifications define the connection, at the Data-Link layer, between your router and the service provider's Frame Relay switch. This connection is assigned a number to identify it. This number is called the Data Link Connection Identifier (DLCI, pronounced dell-see). Once data comes from your router to the switch over this connection, it enters the service provider's cloud. The cloud really represents the switch fabric of the service provider's network. Frame Relay specifications do not pertain to this network, so Frame Relay network drawings represent it with a cloud, indicating that it is not specifically defined. When your data reaches the border of the service provider's switched network, it leaves that network and enters your remote router through another connection defined by the Frame Relay specification. This connection also has a DLCI number assigned to it. How is the path from one router to another determined if the service provider's cloud is undefined? Each connection to the cloud is assigned its own identification number, and a table is maintained, mapping each connection to the appropriate port on the service provider's Frame Relay switch. What happens to your data inside the cloud is really not important provided that it reaches the appropriate outbound switch port and reaches the correct remote destination. Under Frame Relay, a single physical connection to the service provider's network can carry multiple virtual connections. These connections are referred to as virtual circuits. Each virtual circuit is assigned its own identifier and the Frame Relay device statistically multiplexes each virtual circuit over the physical connection. Frame Relay Network Topology Frame Relay networks can be connected in a number of ways, depending on the requirements of the network in question. There are a few popular topologies that are common practice. These include Star, Full Mesh, and Partial Mesh. Each of these topologies has its pros and cons, and you need to consider your network design requirements carefully before selecting which to use. The following is a brief description of each of the three topologies mentioned above:
• Star -- In a star configuration, each remote location is connected to a single central location. This is a relatively inexpensive configuration because it requires a minimal number of virtual circuits. Each location communicates with each other location through the central site. Star is often called "hub and spoke."
• Full Mesh -- In this topology, every site in the WAN is connected directly (via a Frame Relay connection) to every other site in the WAN. Sites communicate directly with each other. With a full-mesh topology, the number of virtual circuits is maximized, and the cost can be very high. The benefit of this topology is the redundancy and fault tolerance that is provides. If a direct link to a site goes down, that site can still be reached indirectly through another site in the mesh. This topology can be cost effective in small networks where redundancy and fault tolerance are required. In larger networks, this topology can be prohibitively expensive.
• Partial Mesh -- In this topology, some sites have connections to multiple other sites, but not every site is directly connected to every other site. This configuration can offer the fault tolerance that is required while helping to reduce the total number of virtual circuits required and keeping costs down. Care should be taken when designing this type of topology to ensure that the redundancy is available where it is required and that the available connections are optimized with respect to the type of data traffic patterns that you expect the WAN to support.
Regardless of the topology selected, Frame Relay technology can present problems with routing protocol update messages. Frame Relay offers what is called non-broadcast multi-access (NBMA) connectivity. This means that, though a single physical connection can support multiple virtual circuits, broadcast traffic is not supported. In order to send a broadcast message to each virtual circuit on a single physical connection, the Frame Relay router must replicate a broadcast message for each active Frame Relay virtual circuit on the connection. This takes significant resources on the router. The split-horizon feature of many routing protocols (IP RIP both Version 1 and 2, IGRP, and most desktop routing protocols such as Apple RTMP and IPX RIP) prevents a router from sending routing updates out the same interface on which the update was received. In the case of a Frame Relay network, incoming routing updates on one virtual circuit could not be sent out to other routers connected by different virtual circuits on the same physical connection because they all share the same physical interface. The IP protocol allows you to disable the split-horizon feature but other protocols do not. In order to solve this problem, configure the physical interface on your router to support subinterfaces. A subinterface is a logical interface. A single physical interface can be divided into multiple subinterfaces, with each subinterface supporting a single virtual circuit. In this case, each subinterface is treated as an independent physical interface with a point-to-point link. The split-horizon feature is no longer an issue because routing information that comes in on one subinterface can be sent out all other subinterfaces. You can configure a subinterface to support multiple virtual circuits, but in this case it will be subject to the split-horizon rule just as the physical interface was before being divided into logical subinterfaces. Frame Relay Terms and Features Frame Relay terminology may be as confusing as that of ISDN. There are many terms to understand relating to Frame Relay components, configuration, and provisioning. In order to pass the CCNA exam, you will need to be familiar with many of these terms. I will define the most important of these terms in this section.
• Local Management Interface -- The Local Management Interface (LMI) is responsible for managing the connection between the CPE and the Frame Relay switch. The LMI provides a keepalive mechanism for maintaining the status of the connection. The LMI also provides a mechanism for reporting the status of the connection, as well as mechanisms for supporting multicast traffic and multicast addressing.
• Local Access Rate -- The Local Access Rate is the rate at which data enters or leaves the Frame Relay cloud. This is also known as the clock speed of the connection to the Frame Relay switch.
• Committed Information Rate -- The Committed Information Rate (CIR) is the rate at which data is transmitted by the Frame Relay switch. The CIR is measured in bits per second, and is usually averaged over a particular time interval. This interval is known as the Committed Rate Measurement Interval.
• Committed Burst -- The Committed Burst is the maximum number of bits that can be guaranteed to be transmitted over the Frame Relay network during any one Committed Rate Measurement Interval.
• Excess Burst -- Excess Burst is the maximum number of bits in excess of the CIR that the Frame Relay switch will attempt to transmit. This number varies depending on the options provided by your Frame Relay service provider.
• Oversubscription -- If the sum of the CIRs on all of the virtual circuits on a single Frame Relay connection, or the sum of all CIRs plus burst capability, exceeds the access line speed, then the connection is considered to be oversubscribed. Oversubscription results in transmission overhead since frames that cannot be transmitted are dropped.
• Data-Link Connection Identifier -- Each connection from a Frame Relay device to a Frame Relay switch is assigned a number to identify it. This number is known as the Data-Link Connection Identifier (DLCI). A connection between two Frame Relay devices through the Frame Relay cloud is maintained by mapping each DLCI to the switch port it connects to. The connection between a pair of DLCIs is referred to as a Permanent Virtual Circuit (PVC).
• Discard Eligibility Indicator -- In the Frame Relay frame, there is a field called the Discard Eligibility Indicator, which is set on each frame of oversubscribed traffic. If network congestion occurs on the Frame Relay link, frames with this bit set will be discarded first.
• Forward Explicit Congestion Notification -- When congestion occurs on a Frame Relay network, the Frame Relay switch will set the Forward Explicit Congestion Notification (FECN) bit on outgoing frames to indicate to the destination router that congestion occurred while this frame was being transmitted.
• Backward Explicit Congestion Notification -- When congestion occurs on a Frame Relay network, the Frame Relay switch will set the Backward Explicit Congestion Notification (BECN) bit on frames to a source router to indicate to the source router that it should reduce its transmission rate to help eliminate the congestion.
Frame Relay on Cisco Routers Configuring an interface on a Cisco router for Frame Relay operation is a fairly simple task. Start by entering Interface Configuration Mode for the interface that you want to set up. Configure an address for the network layer protocol you are using. More than likely, you will be using IP, so you will assign the interface an IP address using the following IOS command: Router(config-if)#ip address address mask The address parameter above would be the IP address you wish to assign to the interface, and the mask parameter is the subnet mask for the particular IP subnet that this interface is connected to. Once you have assigned an address, you will need to select an encapsulation type for your Frame Relay traffic. The devices at each end of the Frame Relay connection must support the encapsulation type that you select. Use the following command to select an encapsulation type: Router(config-if)#encapsulation frame-relay [cisco | ietf] If you are using Cisco routers on both ends of the Frame Relay connection, you can select the proprietary cisco encapsulation type. If one of the devices is not a Cisco router, then you must select the ietf encapsulation type. On Cisco routers running IOS version 11.2 or newer, the LMI type used by the Frame Relay switch can be automatically detected. If you are using an earlier version, or if you wish to specify the LMI type manually, you should use the following IOS command: Router(config-if)#frame-relay lmi-type [ansi | cisco | q9331] Once you have established the LMI type, you will need to specify the bandwidth for the link. Some routing protocols use bandwidth as a metric for making routing decisions, so this information could be very important, depending on the routing protocol(s) that you use on your network. To specify the bandwidth for the Frame Relay connection, use the following command: Router(config-if)#bandwidth kilobits The kilobits parameter is the bandwidth for the Frame Relay connection in kilobits per second. Once the information above has been configured, and you have saved your configuration, you have configured basic Frame Relay operations on the router interface. The router will now use the Inverse ARP protocol to construct a table that maps addresses to DLCIs for outgoing traffic. In some cases, such as when you want to control broadcast traffic on the Frame Relay interface,
you will need to manually specify the address to DLCI mappings. To do this, use the following IOS command: Router(config-if)#frame-relay map protocol protocol-address dlci [broadcast] [ietf | cisco | payload-compress packet-by-packet] The protocol parameter specifies the network protocol in use over the Frame Relay link. The protocol-address parameter specifies the network layer address, for example, the IP address, of the remote router, which maps to the specified DCLI. The dlci parameter specifies the DLCI number, which maps to the protocol address previously specified. The parameters listed in brackets are optional. The broadcast parameter specifies that broadcast traffic should be forwarded to the protocol address specified earlier in the command. The ietf and cisco parameters simply specify the encapsulation to use for the Frame Relay connection, which we already configured in a previous step. The final parameter, payload-compress packet-by-packet, specifies a Cisco proprietary compression method for the Frame Relay connection. Depending on your network design, this basic Frame Relay configuration may be all you need. However, if you are using a distance vector protocol, and you are using a single interface for multiple Frame Relay virtual circuits, then you will have problems sending routing updates due to the limitations of the split-horizon rule. To work around this problem, you will need to configure subinterfaces on your Cisco router. To configure subinterfaces, first enter Interface Configuration Mode for the physical interface that you wish to divide into subinterfaces. If you have previously configured that interface with an IP address, you must remove that address in order to setup subinterfaces. Use the following command: Router(config-if)#no ip address In order to specify a subinterface for configuration, you separate the interface number from the subinterface number with a period, using the following syntax: interface_number.subinterface_number For example, to configure the first subinterface on the first physical serial interface on your router, use the following command from within Interface Configuration Mode: Router(config-if)#interface serial 0.1 ... {multipoint | point-to-point} Note that the first serial interface is serial 0, but the first subinterface on that physical interface is subinterface 1. You need to specify whether the subinterface will support a single virtual circuit (point-to-point) or multiple virtual circuits (multipoint). In order to configure the subinterface with a DLCI that will distinguish it from the physical interface, you use the following IOS command: Router(config-if)#frame-relay interface-dlci dlci The dlci parameter specifies the DLCI number that you wish to assign to the subinterface. You must use this command to link a virtual circuit derived from LMI to the subinterface, since the LMI does not have knowledge of subinterfaces. Any DLCIs advertised by the Frame Relay switch that you do not assign to a subinterface using the "frame-relay interface-dlci" command will be assigned to the routers physical interface. A Cisco router can be configured to act as a Frame Relay switch. Though this will probably never be done in a real production network, it can be very useful in a lab environment. There are a few steps that you need to perform to configure a Cisco router to act as a Frame Relay switch. First, enable Frame Relay switching in global configuration mode: Router(config)#frame-relay switching Second, you need to configure each interface for Frame Relay encapsulation (using the encapsulation frame-relay command) and for the correct Frame Relay LMI type. You cannot rely on LMI autosense, because this router is your Frame Relay switch. You need to explicitly set the LMI type for each interface using the frame-relay lmi-type command. Next, you need to configure your interfaces as DCE and provide clocking using the following interface configuration commands: Router#conf t
Router(config)int s0 Router(config-if)frame-relay intf-type dce Router(config-if)clockrate 56000 The commands above configure the interface s0 to be DCE and set the clockrate to 56 kbps. Finally, you need to configure the connections between the local DLCIs that you will use for each PVC that runs through the switch. This is performed at each interface. The command that accomplishes this is the frame-relay route command. Here is the syntax: Router(config)#frame-relay route in-dlci out-interface out-dlci The in-dlci parameter refers to the DLCI on which the packet is received on the interface you are configuring. The out-interface parameter refers to the interface that the router uses to transmit the packet, and the out-dlci parameter refers to the DLCI that the router uses to transmit the packet over the specified out-interface.
Figure 7. In Figure 7, R2 is configured to act as a Frame Relay Switch. It maintains a PVC connection between R1 and R3. When R1 sends frames to R3, they enter the Frame Relay switch on interface s0 using DLCI 102. In order to reach R3, the switch needs to send the frame out interface s1 using DLCI 201. To configure this, the following interface configuration commands are used: R2#conf t R2(config)int s0 R2(config-if)frame-relay route 102 s1 201 In order to configure traffic flow in the opposite direction through the switch, the following configuration commands are used: R2#conf t R2(config)int s1 R2(config-if)frame-relay route 201 s0 102 Each PVC configured on the switch needs to have a pair of associated "frame relay route" statements in order to configure communication in both directions and complete the circuit. Once you have configured Frame Relay operation on your network, you'll want to be able to monitor things to see how the network is performing or to troubleshoot problems that may occur. The following are some IOS show commands that you will find useful for these purposes:
• show frame-relay pvc -- This command displays the status of each Frame Relay connection to your router. The output will include traffic statistics as well as the number of FECN or BECN frames received by the router. This command is useful to verify that each Frame Relay connection is up and running, as well as for checking for congestion of the Frame Relay links.
• show frame-relay lmi -- This command displays the LMI type in use on your router as well as the LMI traffic statistics for the router, such as the number of status messages received or sent by the router from/to the Frame Relay switch.
• show frame-relay map -- This command displays the contents of the DLCI map table. This table lists the protocol address and the DLCI number associated with it for each Frame Relay virtual circuit connected to the router.
• show interfaces serial -- This command results in more general output, but will include Frame Relay specific information as well, including which serial interfaces are configured for Frame Relay operations. For each serial interface so configured, you will see the DLCIs in use, as well as the DLCI associated with the LMI.
ISDN Another popular WAN technology is ISDN. ISDN is offered by the phone company and stands for Integrated Services Digital Network. If you talk to some of the more seasoned employees that work for the phone company, they might tell you that ISDN stands for "Innovation Subscribers Don't Need." This phrase came up early in the history of ISDN, when the standards were still being developed and no real application for the technology could be seen, but since then ISDN has matured into a stable and quite useful group of protocols. It is interesting that the ISDN objectives appear on the CCNA exam. ISDN information is included in the Cisco Advanced Cisco Router Configuration (ACRC) class material, which is considered part of the CCNP preparation. Most of the CCNA exam material is derived primarily from the material presented in the Interconnecting Cisco Network Devices (ICND) course. The ISDN material is relevant to the CCNA certification, but it sticks out like a sore thumb because Cisco tends to consider it a more advanced topic. ISDN Applications ISDN technology is in widespread use today for a number of applications. Businesses use ISDN for such applications as high-speed fax, videoconferencing, Internet access, and inexpensive connectivity between remote offices. The Cisco ACRC course material presents ISDN in the context of Cisco's Dial-on-Demand Routing (DDR) technology. With DDR, you define certain network traffic that must cross a WAN link as "interesting" to your router. The WAN links in a DDR scenario are not always connected. When the router receives traffic that has been declared to be interesting, it will initiate a connection to the remote router and transmit the traffic. Once the transmission is completed, the connection is terminated. In this way, expenses associated with WAN connections can be minimized, since the WAN link is only active when it is actually needed. ISDN technology fits well into a DDR scenario. ISDN Terminology One of the most interesting things you'll encounter when studying ISDN is the vast array of acronyms. You will find more letters and numbers here than you'll ever want to memorize, yet for the CCNA exam, that is exactly what you'll have to do. There is a list of terms that you will need to know and recognize from memory. I will list them here, along with the definitions. Once you get a feel for where each of these items will appear in an ISDN configuration, it will be easier to memorize them. ISDN technology is offered in one of two ways -- either the Basic Rate Interface (BRI) or the Primary Rate Interface (PRI). Each of these consists of a number of channels that perform certain functions. With BRI, you get two Bearer channels (B channels) and one Delta channel (D channel). The two B channels are 64 Kbps each, and the D channel is 16 Kbps. The B channels are used to carry application data information, and the D channel is used for control information. ISDN BRI is sometimes referred to as 2B+D. ISDN PRI varies depending on whether you are in the United States or elsewhere in the world. In the US, ISDN PRI consists of 23 B channels of 64 Kbps each, and one D channel, which is also 64 Kbps. This can be referred to as 23B+D. In Europe, however, ISDN PRI offers 30 B channels and one D channel, all at 64 Kbps. This service can be referred to as 30B+D. 23B+D offers 1.544
Mbps of bandwidth, while 30B+D offers 2.048 Mbps of bandwidth. For the CCNA exam, if you see a question referring to PRI, it is safe to assume that you are in the US, and that the question assumes 23B+D. Now that you understand BRI and PRI, you will need to know all the acronyms associated with the various ISDN devices. Here is a list:
• CPE -- Customer Premises Equipment -- Just as you might think, this is equipment that is located at the customer premises. In the US, this includes all ISDN equipment connected at the customer site, including the NT1 (defined below). Outside the US, the NT1 is not considered part of the CPE, but rather is part of the ISDN network.
• TA -- Terminal Adapter -- A Terminal Adapter is a device that is required in order to connect a non-ISDN compatible device to an ISDN network. The TA is used to convert V.35 or EIA/TIA 232 signals into ISDN BRI signals.
• TE1 -- Terminal Endpoint 1 -- A TE device is any ISDN user device, including a router, a telephone, or an ISDN fax machine. TE1 equipment is ISDN compatible; it already has the necessary interface to connect to the ISDN network.
• TE2 -- Terminal Endpoint 2 -- TE2 equipment is any user device that is not ISDN compatible. TE2 equipment requires the use of a TA to connect to an ISDN network.
• NT1 -- Network Termination 1 -- An NT1 device is used to transmit ISDN BRI signals over the ISDN digital line. The NT1 is responsible for multiplexing of the ISDN channels, as well as power transfer and performance monitoring.
• NT2 -- Network Termination 2 -- An NT2 device is the point at which all ISDN lines at a customer site are aggregated. An NT2 device provides switching, multiplexing, and concentration for all the ISDN lines at the customer premises. An example of an NT2 device is a corporate PBX. NOTE: there is no NT2 device in a residential ISDN installation.
• LE -- Local Exchange -- This is the ISDN central office. • LT -- Local Termination -- This is the portion of the LE responsible for termination of the
local loop. • ET -- Exchange Termination -- This is the portion of the LE that is responsible for
switching functions and communication with other devices within the service provider's ISDN network.
Once you have mastered the ISDN device terminology, you are ready to move on to the ISDN Reference Points. The ISDN Reference Points define the main connection points between different ISDN devices and are used to establish the protocols that can be used on either side of the connection. There are four main Reference Points that you will need to understand for the CCNA exam. They are:
• R -- The R reference point refers to the connection point between a device that is not ISDN compatible and a Terminal Adapter (TA). Since the R point is specifically the point at which non-ISDN devices connect to ISDN, there is no ISDN specification for the actual characteristics of the R point. It is conceptual and architectural. It could be RS-232, Ethernet, or analog telephone.
• S, T, and S/T -- The S reference point refers to the connection point between ISDN devices such as a TE1 or a TA and the NT2. The T reference point refers to the connection point between an NT2 and the ISDN network. In practical data applications, NT2 devices are rare, so you will most often see the two reference points referred to as S/T. Physically, S/T reference points are realized on four physical wires (two pairs), implemented on an 8-pin RJ45 connector. The additional pins of the RJ45 connector optionally may be used to supply power to the NT or TE.
• U -- The U reference point refers to the connection point between the NT1 and the ISDN provider network (the LE). It is not used in all countries, only those in which the customer can own the NT1. The physical realization of the U reference point is a two-wire (one pair) interface. Even though only two wires are use, you will commonly see it implemented with an 8-pin RJ45 connector.
The ISDN reference points are sometimes easier to understand if you see them:
Figure 8. Is that enough acronyms and initials for you? But wait, there's more. Take a look at the ISDN protocol groups. ISDN Protocol Groups The many standards that make up the technology called ISDN have been developed over a number of years. Early work on ISDN began in the 1960s. The ISDN protocol standards are maintained by the ITU-T, and are divided into three groups based on the function of the protocol defined by the standard. The three ISDN protocol groups are:
• E series -- The E series ISDN protocols are those that make recommendations for telephone network standards for ISDN.
• I series -- The I series ISDN protocols are those that define general ISDN methods, concepts and terminology.
• Q series -- The Q series ISDN protocols are those that cover ISDN switching and call signaling.
If we look at ISDN in terms of the OSI reference model and the 3-D model, we can see the following examples: ISDN B Channel Examples
Layer User Plane Control Plane
Network IP ARP, ICMP, IGMP, DHCP, routing protocols
Data Link any serial (HDLC, SDLC, LAP-B)
Physical most serial
ISDN D channel examples
Layer User Plane Control Plane
Network X.25 for shared packet data Q.931 call setup
Data Link Q.921 LAP-B
Physical BRI, PRI
Cisco and the ISDN BRI Many Cisco routers support ISDN BRI natively; that is, they have ISDN BRI interfaces built in and already provide the TA function. Many Cisco routers do not have such an interface, however. These routers can still be used on an ISDN network, but they will require the use of a TA to connect the router's serial interface to the ISDN network. If you are installing the router in the US, then you will need to provide the NT1. If you are installing the router outside the US, then the ISDN service provider typically supplies the NT1. If you must provide the NT1, then you should select a Cisco router that has a U interface and thus provides the NT1 function. If you are connecting to a service provider's NT1, then you will want a Cisco router with an S/T interface. Unless you are in the habit of toasting router interfaces for fun,
you should take care that you are connecting the right interface type to the ISDN network. Cisco warns that connecting a router with a U interface to a service provider's NT1 can damage the interface, therefore it is not recommended. When you are ready to configure your router to use ISDN BRI, you will first need to specify the ISDN switch type in use at your service provider's central office. Cisco routers support many different switch types for ISDN BRI, including the following:
• 5ess -- This is the AT&T basic rate switch in use in the US. • DMS-100 -- This is the NT DMS-100 switch in use in North America. • NI1 -- This is the National ISDN-1 switch in use in North America. • 1TR6 -- This is the German 1TR6 ISDN switch. • TS013 -- This is the Australian TS013 switch. • Net3 -- This is the switch type in use for Net3 in Europe and the UK. • NTT -- This is the NTT switch in use in Japan.
To specify the ISDN BRI switch type on your Cisco router, enter Global Configuration Mode and use the following command: Router(config)#isdn switch-type Once you have configured the switch type, you will need to configure the SPIDs (Service Profile Identifiers). A SPID is a series of numbers that identifies your connection to the switch at the service provider's central office. The SPID is similar to a phone number in that it uniquely identifies your connection to the switch. Some switch types require that you configure the SPIDs on your router (the DMS-100, for example), and some switches, such as the AT&T 5ess, do not. If your service provider's switch does require you to configure SPIDs on your router, you will be given one or two SPID numbers. To configure the SPIDs on your Cisco router, use the following Interface Configuration Mode command(s): Router(if-config)#isdn spid1 Router(if-config)#isdn spid2 Finally, once you have configured the switch type and the SPIDs, you will need to decide on an encapsulation type for the data on your ISDN B channels. Your ISDN D channel will use LAPD for encapsulation, and your B channels will most likely use either PPP or HDLC encapsulation. Cisco IOS offers several additional commands to configure other specific ISDN parameters, but these are beyond the scope of the CCNA exam. There are also some Cisco IOS commands for examining ISDN operations in the router. Some of the more useful commands are listed below:
• show isdn active --This command will display any active ISDN calls along with the number that was called.
• show isdn status -- This command will display the status of all ISDN interfaces, or you can specify a particular interface.
• show isdn history -- This command will display information about the current call as well as historic information for recent ISDN calls.
• debug q921 -- This command will display debug information pertaining to Q.921 activity on your ISDN interface. Use this information to verify that you have a connection to the ISDN switch.
Conclusion At this point, after learning what you have read in this paper, you should be armed with the knowledge that you need in order to pass the WAN protocols section of the CCNA exam. You are by no means a WAN expert, since the information here is merely a cursory discussion of the protocols as covered by the CCNA exam objectives. You should certainly do a lot more reading on these protocols as you move forward in your career. For now, I suggest you take a short break and allow the material you have taken in so far to be absorbed. And by the way, good luck on the exam! 11.2 Lab Abstract 1. In this scenario you are asked to use the appropriate Cisco IOS commands to perform the following:
1. Login to a router, enter Privileged Exec Mode, and view the current configuration. Determine the encapsulation type for two connections. 2. Determine which control protocols are in use over a connection. 3. Determine which routing protocol(s) are in use. 4. Display the IP routing table. 5. Determine which routed protocols are in use.
2. In this lab scenario you are asked demonstrate an understanding of Frame Relay concepts and show how to configure Cisco routers for Frame Relay connections. 11.3 Lab Scenario. Introduction You are the systems administrator for your company, Happy Acres Growers, Inc. Throughout your tenure with the company, you have expressed your interest in the data communications side of the IT house. You often queried the manager of network services for any openings in the department, and tried to show the knowledge that you have gained through self-study. After many months of effort, you hear opportunity knocking. The company is planning to implement a Frame Relay hub-and-spoke network connecting all of its growers' sites to the corporate headquarters. The network manager feels that his department has too many projects to spare any time for this one. He will need to hire an additional engineer. You have been offered an opportunity to move from your systems position into a slot on the network team, if you can demonstrate to the network manager that you have an understanding of Frame Relay concepts and the ability to configure Cisco routers for Frame Relay connections. You decide to set up a home lab and get some practice before your meeting with the network manager. The first thing you need to do is create a basic Frame Relay network using your 3 Cisco 2501 access routers. The routers have host names of R1, R2, and R3. Here is what you decide to do:
Set-up Items
1. Connect each of the routers with back-to-back cables. 2. Configure router R2 to act as a Frame Relay switch. 3. Configure the Frame Relay switch to advertise DLCI 102 on interface s0 and 201 on
interface s1, and to route frames between the two interfaces. 4. Configure the remaining two routers for Frame Relay connections. Allow them to use
Inverse ARP to detect the DLCIs. 5. Configure an IP address of 10.10.10.1/24 on R1 and 10.10.10.2/24 on R3. 6. Verify connectivity across the Frame Relay link using the ping command. 7. Examine Frame Relay LMI activity on router R1. 8. Examine the state of the PVCs on each R1 and on R2.
Solution Configuring the Physical Connectivity
a. Connect the DTE end of a Cisco back-to-back cable to the s0 interface of R1. b. Connect the other end of this cable to the s0 interface of R2. c. Connect the DTE end of another back-to-back cable to the s1 interface of R2.
d. Connect the other end of the cable to the s0 interface of R3. You can tell if a DTE or a DCE plug is inserted into a given serial interface with the show controller serial x where x is the interface number. Another way to tell if a DCE plug is connected is that only DCE interfaces will accept a clockrate command. clockrate and bandwidth are independent commands, can have different values, and appear both on DTE and DCE interfaces Configuring the Frame Relay Switching Function (Set-up item 2) Configure R2 to act as a Frame Relay switch. Follow these steps: a. login to the router, and enter Privileged Exec mode. R2>enable password:******* R2# b. Enter Global Configuration mode. R2#conf t c. Enable Frame Relay switching. R2(config)#frame-relay switching d. Configure each interface for Frame Relay encapsulation. R2(config)#int s0 R2(config-if)#encapsulation frame-relay R2(config-if)#int s1 R2(config-if)#encapsulation frame-relay e. Configure the router to provide a clockrate of 56 Kbps. R2(config-if)#clockrate 56000 f. Configure the LMI type on each serial interface. R2(config-if)#frame-relay lmi-type ansi R2(config-if)#int s0 R2(config-if)#frame-relay lmi-type ansi g. Configure each serial interface to act as DCE. R2(config-if)#frame-relay intf-type dce R2(config-if)#int s1 R2(config-if)#frame-relay intf-type dce (Set-up item 3) h. Configure each serial interface to route incoming frames to the other serial interface. Note: Extra Credit Challenge How can you repeat the command with the least amount of typing? Answer: Use the up arrow to repeat commands. R2(config-if)#frame-relay route 201 interface Serial0 102 R2(config-if)#int s0 R2(config-if)#frame-relay route 102 interface Serial1 201 Note: Tip You've done quite a bit of configuration. An intermediate "save" here would be conservative practice. Configuring the Frame Relay Access Routers (Set-up items 4 and 5) Configure R1 for Frame Relay operation. Follow the steps below:
a. Enter Interface Configuration mode for R1's interface s0. Configure Frame Relay encapsulation. R1(config-if)#encapsulation frame-relay b. Configure the LMI type. R1(config-if)#frame-relay lmi-type ansi c. Assign IP addresses to the s0 interfaces on routers R1. R1(config-if)#ip address 10.10.10.1 255.255.255.0 d. Enter Interface Configuration mode for R3's interface s0. Configure Frame Relay encapsulation. R3(config-if)#encapsulation frame-relay e. Configure the LMI type. R3(config-if)#frame-relay lmi-type ansi f. Assign IP addresses to the s0 interfaces on router R3. R3(config-if)#ip address 10.10.10.2 255.255.255.0 Testing Connectivity (Set-up item 6) Save your configs on each router, then test for connectivity across the Frame Relay link using the ping command. a. Save configs using the copy running-configuration startup-configuration command on each router: R1#copy run start R2#copy run start R3#copy run start b. Test for connectivity across the Frame Relay link using the ping command on routers R1 and R3. R1#ping 10.10.10.2 Note: write memory is an earlier name for the same command as copy run start, but Cisco has said it will eventually drop support for write mem. You might find a very old IOS version that only accepts write mem. Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/68 ms R3#ping 10.10.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/67/68 ms (Set-up item 7) Examine the LMI activity on R1 a. Examine the output of the following command: R1#debug frame-relay lmi Frame Relay LMI debugging is on
Displaying all Frame Relay LMI data R1# 00:19:57: Serial0(out): StEnq, myseq 88, yourseen 87, DTE up 00:19:57: datagramstart = 0xE30BD8, datagramsize = 14 00:19:57: FR encap = 0x00010308 00:19:57: 00 75 95 01 01 01 03 02 58 57 00:19:57: 00:19:57: Serial0(in): Status, myseq 88 00:19:57: RT IE 1, length 1, type 1 00:19:57: KA IE 3, length 2, yourseq 88, myseq 88 00:20:07: Serial0(out): StEnq, myseq 89, yourseen 88, DTE up 00:20:07: datagramstart = 0xE30BD8, datagramsize = 14 00:20:07: FR encap = 0x00010308 00:20:07: 00 75 95 01 01 01 03 02 59 58 00:20:07: b. Turn off debugging with the undebug all command: R1#u al All possible debugging has been turned off c. Use the show frame-relay lmi command on R1. R1#show frame-relay lmi LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = ANSI Invalid Unnumbered info 0 Invalid Prot Disc 0 Invalid dummy Call Ref 0 Invalid Msg Type 0 Invalid Status Message 0 Invalid Lock Shift 0 Invalid Information ID 0 Invalid Report IE Len 0 Invalid Report Request 0 Invalid Keep IE Len 0 Num Status Enq. Sent 106 Num Status msgs Rcvd 106 Num Update Status Rcvd 0 Num Status Timeouts 1 (Set-up item 8) Examine the state of the Frame Relay PVCs on router R1 and R2. R1#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DTE) Active Inactive Deleted Static Local 1 0 0 0 Switched 0 0 0 0 Unused 0 0 0 0 DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 11 output pkts 12 in bytes 1074 out bytes 1108 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 2 out bcast bytes 68 pvc create time 00:15:09, last time pvc status changed 00:08:09
R2#show frame-relay pvc PVC Statistics for interface Serial0 (Frame Relay DCE) Active Inactive Deleted Static Local 0 0 0 0 Switched 1 0 0 0 Unused 0 0 0 0 DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0 input pkts 13 output pkts 12 in bytes 1142 out bytes 1108 dropped pkts 1 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 Num Pkts Switched 13 pvc create time 01:23:06, last time pvc status changed 00:13:08 PVC Statistics for interface Serial1 (Frame Relay DCE) Active Inactive Deleted Static Local 0 0 0 0 Switched 1 0 0 0 Unused 0 0 0 0 DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1 input pkts 13 output pkts 13 in bytes 1138 out bytes 1142 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 Num Pkts Switched 12 pvc create time 01:23:39, last time pvc status changed 00:13:28
![[XLS]conference.ifas.ufl.edu · Web view10500 University Center Dr Suite 215 bmcphers@usgs.gov ... UT 84056 801-777-4618 ... 602-640-5282 kim.m.gavigan@usace.army.mil Eliza](https://static.documents.pub/doc/80x56/5add77147f8b9ae1408d027b/xls-view10500-university-center-dr-suite-215-bmcphersusgsgov-ut-84056-801-777-4618.jpg)
