Exam Ccna Lab

Exam: 640-816

Interconnecting Cisco Networking Devices Part 2

Exam Description

The 640-816 Interconnecting Cisco Networking Devices Part 2 (ICND2) is the exam associated with the Cisco Certified Network Associate certification. Candidates can prepare for this exam by taking the Interconnecting Cisco Networking Devices Part 2 (ICND2) v1.0 course. This exam tests a candidate's knowledge and skills required to successfully install, operate, and troubleshoot a small to medium size enterprise branch network. The exam covers topics on VLSM and IPv6 addressing; extending switched networks with VLANs; configuring, verifying and troubleshooting VLANs; the VTP, RSTP, OSPF and EIGRP protocols; determining IP routes; managing IP traffic with access lists; NAT and DHCP; establishing point-to- point connections; and establishing Frame Relay connections.

Exam Topics

The following topics are general guidelines for the content likely to be included on the Interconnecting Cisco Networking Devices Part 2 exam. However, other related topics may also appear on any specific delivery of the exam. In order to better reflect the contents of the exam and for clarity purposes, the guidelines below may change at any time without notice.

Configure, verify and troubleshoot a switch with VLANs and interswitch communications

Describe enhanced switching technologies (including: VTP, RSTP, VLAN, PVSTP, 802.1q) Describe how VLANs create logically separate networks and the need for routing between them

Configure, verify, and troubleshoot VLANs

Configure, verify, and troubleshoot trunking on Cisco switches

Configure, verify, and troubleshoot interVLAN routing

Configure, verify, and troubleshoot VTP

Configure, verify, and troubleshoot RSTP operation

Interpret the output of various show and debug commands to verify the operational status of a Cisco switched network

Implement basic switch security (including: port security, unassigned ports, trunk access, etc.) (Lab 1) (Lab 2)

Implement an IP addressing scheme and IP Services to meet network requirements in a medium-size Enterprise branch office network

Calculate and apply a VLSM IP addressing design to a network Determine the appropriate classless addressing scheme using VLSM and summarization to satisfy addressing

requirements in a LAN/WAN environment

Describe the technological requirements for running IPv6 (including: protocols, dual stack, tunneling, etc)

Describe IPv6 addresses

Identify and correct common problems associated with IP addressing and host configurations

Configure and troubleshoot basic operation and routing on Cisco devices

Compare and contrast methods of routing and routing protocols Configure, verify and troubleshoot OSPF (Lab 1) (Lab 2)

Configure, verify and troubleshoot EIGRP (Lab 1) (Lab 2)

Verify configuration and connectivity using ping, traceroute, and telnet or SSH

Troubleshoot routing implementation issues

Verify router hardware and software operation using SHOW & DEBUG commands

http://www.testking.com/member/index.php/part_private/sect_labv2/product_1650/page_83/











Implement basic router security

Implement, verify, and troubleshoot NAT and ACLs in a medium-size Enterprise branch office network.

Describe the purpose and types of access control lists Configure and apply access control lists based on network filtering requirements

Configure and apply an access control list to limit telnet and SSH access to the router

Verify and monitor ACL's in a network environment

Troubleshoot ACL implementation issues

Explain the basic operation of NAT

Configure Network Address Translation for given network requirements using CLI

Troubleshoot NAT implementation issues

Implement and verify WAN links

Configure and verify Frame Relay on Cisco routers Troubleshoot WAN implementation issues

Describe VPN technology (including: importance, benefits, role, impact, components)

Configure and vary PPP connection between Cisco routers

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot VLANs

Contents Introduction Technology Background

Lab Scenario

Lab Objectives

Lab Solution

Introduction

A VLAN is a logical segmentation of Layer 2 networks which confines broadcasts, unicasts and multicasts to the logical boundary irrespective of the physical location. VLANs also help in extending a LAN across physical locations. VLANs are often associated with IP subnetworks. For example, all the end stations in a particular VLAN belong to the same IP Subnet. Interface VLAN membership on the switch is assigned manually on an interface-by-interface basis.

Technology Background

A broadcast domain includes all connected devices such that when any of the devices sends a broadcast frame, all the other devices get a copy of the frame. When VLANs did not exist, the Switch considered all devices, connected to it, as being in a single broadcast domain. When LANs grew in size the amount of broadcast brought down the network performance to an unbearable level.

VLANs provide a way to logically divide the layer 2 network into different broadcast domains. This way broadcasts are confined to a relatively small area while providing a basic security mechanism. VLANs also allow seamless extension of networks across physical locations.

http://www.testking.com/member/index.php/part_private/sect_labv2/product_1650/page_83/#labso

http://www.testking.com/member/index.php/part_private/sect_labv2/product_1650/page_83/#labob

http://www.testking.com/member/index.php/part_private/sect_labv2/product_1650/page_83/#labsc

http://www.testking.com/member/index.php/part_private/sect_labv2/product_1650/page_83/#techn

http://www.testking.com/member/index.php/part_private/sect_labv2/product_1650/page_83/#intro







Figure 1

Figure 1 shows how VLAN help in segmenting VLANs and extending it across physical locations. Hosts in VLAN 3 in Building A can easily communicate with hosts in VLAN 3 in Building B even though they are physically in different locations. Some benefits of VLANs can be summed as:

Allows creating flexible design that can ground users by function, department etc. Reduces overhead and optimizes resource utilization by dividing LAN in smaller segments

Allows enforcing security by separating hosts which do not need to share information

Configuring and Using VLANs can be divided into 3 easy steps:

Steps Required Relevant Command

Create VLAN Switch(config)#vlan <id>

Give a Name to the VLAN (optional) Switch(config-vlan)#name <name>

Assign a Switchport to a VLAN Switch(config-if)#switchport access vlan <vlan#>

Lab Scenario

We have recently acquired 2 Cisco 2950 switches. We have two buildings. One switch has been installed in each building. 2 VLANs need to be configured on the switches - VLAN 5 and VLAN 10. Building A will have hosts in both VLANs but Building B will have hosts in VLAN 10 only. Hosts of VLAN 10 in both buildings should be able to communicate with each other. For testing purpose we have a host connected to each Switch. The network diagram is shown in Figure 2:

Figure 2 - Network

Lab Objectives

1. Add VLAN 5 and VLAN 10 on both switches

2. Configure fa0/1 and fa0/15 on both Switches to be in VLAN 10

3. Verify VLAN information

Lab Solution

VLANs need to be created before switchports can become a part of them. Let's create VLANs on SwitchA:

SwitchA#config t

SwitchA(config)#vlan 5

SwitchA(config-vlan)#exit

SwitchA(config)#vlan 10

SwitchA(config-vlan)#exit

A single command could also be used to create multiple VLANs as shown on SwitchB here:

SwitchB#config t

SwitchB(config)#vlan 5,10

SwitchB(config-vlan)#exit

Now the relevant switchports can be added to the VLANs. Special attention should be paid to the fact that fa0/15 on both switches (connecting each other), are made a part of VLAN 10. This is done to ensure that traffic from VLAN 10 can across the switches. This can also be done using Trunking but that is covered in further labs.

SwitchA(config)#interface fa0/1

SwitchA(config-if)#switchport access vlan 10


SwitchA(config-if)#switchport access vlan 10

Note that each port had to be manually configured into VLAN 10. It can be tiresome if lot of ports need to be configured. One simple way to do this is to use the interfacerange command as shown on SwitchB:

SwitchB(config)#interface range fa0/5, fa0/10

SwitchB(config-if-range)#switchport access vlan 10

VLAN information can be verified using the "show vlan" command:

SwitchA#show vlan

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/6, Fa0/7, Fa0/8, Fa0/9

Fa0/11, Fa0/12, Fa0/13, Fa0/14

Fa0/16, Fa0/17, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23, Fa0/24

Fa0/25, Fa0/26, Fa0/27, Fa0/28

Fa0/29, Fa0/30, Fa0/31, Fa0/32

Fa0/33, Fa0/34, Fa0/35, Fa0/36

Fa0/37, Fa0/38, Fa0/39, Fa0/40

Fa0/41, Fa0/42, Fa0/43, Fa0/44

Fa0/45, Fa0/46, Fa0/47, Fa0/48

5 VLAN0005 active

10 VLAN0010 active Fa0/1, Fa0/15

SwitchB#show vlan

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/6, Fa0/7, Fa0/8, Fa0/9

Fa0/11, Fa0/12, Fa0/13, Fa0/14

Fa0/16, Fa0/17, Fa0/19, Fa0/20

Fa0/21, Fa0/22, Fa0/23, Fa0/24

Fa0/25, Fa0/26, Fa0/27, Fa0/28

Fa0/29, Fa0/30, Fa0/31, Fa0/32

Fa0/33, Fa0/34, Fa0/35, Fa0/36

Fa0/37, Fa0/38, Fa0/39, Fa0/40

Fa0/41, Fa0/42, Fa0/43, Fa0/44

Fa0/45, Fa0/46, Fa0/47, Fa0/48

5 VLAN0005 active

10 VLAN0010 active Fa0/1, Fa0/15

Important facts to note in the output:

1. All switchports belong to VLAN 1 by default

2. When VLAN names are not configured their default names are VLAN00xx, where xx is the VLAN id

3. As per our configuration port fa0/1 and fa0/15 now belong to VLAN 10.

References:

Catalyst 2950 and Catalyst 2955 Switch Software Configuration Guide - Configuring VLANs

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea5/configuration/guide/swvlan.html

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot trunking on Cisco switches


Lab Scenario

Lab Objectives

Lab Solution






Introduction

Switchports can be in access or trunk modes. Access ports can carry traffic of one VLAN only. Trunk ports can carry traffic of multiple VLANs. Trunks ports are 100 or 1000Mbps interfaces which connect any of the following:

Switch to Switch Switch to Router

Switch to a Server


In the network shown in Figure 1, if Host1 and Host3 need to communicate with Host 2 and Host 4 respectively, then fa0/10 cannot be an access port because access ports can carry traffic of one VLAN only.

Figure 1 - VLANs across Switches

Interface fa0/10 on both the switches would need to be configured as Trunk Ports. As a frame leaves a switchport, it is marked with the source VLAN Id. This is called frame tagging. The destination switch can identify the VLAN of the frame by looking at the VLAN ID in the frame tag. Cisco Switches support two Frame Tagging methods - Inter-Switch Link (ISL) and IEEE 802.1Q

ISL - ISL is a Cisco propritary method of tagging the frame. It adds a new header containing the VLAN ID onto the original data frame. If untagged traffic is received on a ISL trunk port, the frame will be dropped.

802.1Q - 802.1Q is an IEEE standard frame tagging protocol and can be used to trunk between a Cisco and a non-Cisco switch. Unlike ISL, it adds field into the original data frame header. When untagged traffic is received on an 802.1Q trunk,it is assumed to be belonging to a default VLAN ID known as Native VLAN.

Configuring Trunk can be divided into 2 steps:

Configure the Switchport mode (optional) Configure the Trunking Protocol (optional)

Configuring Switchport mode: A Switchport can be any of the following modes :

switchport mode access - Manually configure a port as access and does not allow trunk neogtiation

switchport mode dynamic auto - This mode will allow automatic neogtiation of trunk mode and trunking protocol using Dynamic Trunking Protocol (DTP). A port in this mode will not active seek to become a trunk but will become a trunk if the remote port is set to desirable or static trunking mode.

switchport mode dynamic desirable - This mode will allow automatic neogtiation of trunk mode and trunking protocol using Dynamic Trunking Protocol (DTP). A port in this mode will actively seek to become a trunk port. If the remote port is set to trunk,auto or desirable mode then this port will become a trunk port

switchport mode trunk - Manually configures a port as trunk.This port will become a trunk as soon as it comes up even if the remote port is not configured as a trunk.

switchport nonegotiate - This port will not generate DTP frames. Mode and protocol configuration needs to be manually configured.

Switchport mode can be configured using the "switchport mode <access|trunk|dynamic>" command.

Trunking protocol can be configured using the "switchport trunk encapsulation" command.

Verificatio of a trunk link can be done using the "show interface trunk" command.

Lab Scenario

For this lab you will need 4 switches, connected as shown in the diagram. The connectivity between the switches is shown in Figure 2. You need to ensure that if a host is plugged into any VLAN in any switch, it will be able to communicate with all other hosts in the same VLAN across the switches. There is a chance that we purchase non-Cisco switches in the future. All protocols used should be open standard. It also should be ensured that in no circumstances the ports currently used for connecting to other switches can become access links.

Figure 2 - Lab Scenario

Lab Objectives Configure fa0/1 and fa0/2 interfaces on all switches to be in static trunk mode Configure fa0/1 and fa0/2 interfaces on all switches to use 802.1q encapsulation

Verify trunk links

Lab Solution

We need to carry traffic of multiple VLANs across the switches. This calls for making fa0/1 and fa0/2 interfaces on all the switches as trunks (as per Figure 2). The conditions call for an open standard protocol - 802.1q - and to ensure that the inter-switch links never become access links - static trunk mode.

All this can be configured using the following commands:


SwitchA(config-if)#switchport trunk encapsulation dot1q

SwitchA(config-if)#switchport mode trunk


SwitchA(config-if)#switchport trunk encapsulation dot1q

SwitchA(config-if)#switchport mode trunk

Note that encapsulation was configured before the mode. A Switchport cannot be set to manual trunking mode unless the encapsulation is configured.

The commands required can be reduced using the range option:

SwitchB(config)#interface range fa0/1 - 2

SwitchB(config-if-range)#switchport encapsulation dot1q

SwitchB(config-if-range)#switchport mode trunk

SwitchC(config)#interface range fa0/1 - 2

SwitchC(config-if-range)#switchport encapsulation dot1q

SwitchC(config-if-range)#switchport mode trunk

SwitchD(config)#interface range fa0/1 - 2

SwitchD(config-if-range)#switchport encapsulation dot1q

SwitchD(config-if-range)#switchport mode trunk

For verifying the trunking, "show interface trunk" command is used on all switches:

SwitchA#show interface trunk

Port Mode Encapsulation Status Native vlan

Fa0/1 on 802.1q trunking 1


SwitchB#show interface trunk




SwitchC#show interface trunk




SwitchD#show interface trunk




References:

Cisco Catalyst 2950 and 2955 Switch Software Configuration Guide - Configuring VLAN Trunks:

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea5/configuration/guide/swvlan.html#wp1200245

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot interVLAN routing


Lab Scenario

Lab Objectives

Lab Solution








Introduction

VLANs provide a way to logically divide the layer 2 network into different broadcast domains. This way broadcasts are confined to a relatively small area while providing a basic security mechanism. Hosts in different VLAN cannot communicate with each other. To facilitate this, Inter-VLAN routing needs to be configured using a Layer 3 device such as a router.


Hosts in different VLAN, as shown in Figure 1, cannot communicate with each other. It is often desirable to use VLANs to reduce the size of a broadcast domain but it usually becomes important to ensure that hosts in different VLANs can communicate with each other.

Figure 1 - Hosts in different VLANs

To ensure that Host1 and Host2 in Figure 1 can communicate with each other, a Layer 3 device such as a router would be needed. The network would look like Figure 2 when a router is added for inter-VLAN communication:

Figure 2 - Inter-VLAN communication

The link between the Router and the Switch will be a trunk link. Cisco Routers can accept and send tagged frames. When a tagged frame is received, the Router interface will check if the frame belongs to its VLAN and then strip the tagging and route it normally. Similarly when a Router needs to send out traffic it can tag the frame before sending it out on the link.

Normal Physical interfaces of a Router cannot be configured with VLAN information. For this purpose a physical interface is divided into logical interfaces called sub-interfaces which can be placed into respective VLANs.

In Figure 2, RouterA's fa0/0 interface can be configured into two sub-interfaces using the interface fa0/0.x global configuration command. x can be any number but usually configured as the VLAN ID for ease of administration.

A sub-interface can be made a part of a VLAN using the "encapsulation <dot1q|isl> <vlan #>" command on the sub-interface.

Sub-Interfaces will also need an IP Address from the VLAN subnet. This Address will be the Gateway Address for all the hosts in that VLAN.

In Figure 2, If Host1 needs to get to Host2; traffic from Host1 will go to RouterA's sub-interface belonging to VLAN 3. From there it will be router out the sub-interface belonging to VLAN 4 and finally reach Host2.

Lab Scenario

For this lab you will need 2 Cisco Switches and a Cisco Router. We have a host on VLAN 5 on Switch1 which needs to communicate with a host on VLAN 10 on Switch2. Your task is to configure the Switchports connecting the Switches, the switchports connecting the Router, and the Router itself, such that these hosts can ping each other. The gateway of hosts in VLAN 5 will be configured as 192.168.5.10 and the Gateway of host in VLAN 10 will be configured as 192.168.10.10. The subnet masks used in both the VLANs is /24.Please ensure that open standard protocols are used in this task.

Figure 3 - Lab Scenario

Lab Objectives

1. Configure fa0/2 on Switch1 as a dot1q trunk

2. Configure fa0/2 and fa0/3 on Switch 2 as dot1q trunk

3. Create 2 sub-interfaces on Router A and put them in VLAN 5 and 10

4. Configure IP addresses on the sub-interfaces on RouterA.

Lab Solution

Since port fa0/2 on both the switches will need to carry traffic of multiple VLANs, they will need to be configured as trunks:

Switch1(config)#interface fa0/2

Switch1(config-if)#switchport trunk encapsulation dot1q

Switch1(config-if)#switchport mode trunk




Port fa0/3 on Switch2 will also need to be trunk since it will carry the traffic from both VLANs to the router for inter-VLAN routing:




RouterA's fa0/0 will need to be divided into logical interfaces and assigned the correct VLAN and IP Address. The IP Address of the sub-interface will be the Gateway address for the hosts in the respective VLANs. IP address for the sub-interface is provided in the question

RouterA(config)#interface fa0/0.5

RouterA(config-subif)#encapsulation dot1q 5

RouterA(config-subif)#ip address 192.168.5.10 255.255.255.0

RouterA(config)#interface fa0/0.10

RouterA(config-subif)#encapsulation dot1q 10


RouterA(config-subif)#exit

Trunking can be verified on Switch2 using the "show interface trunk" command:

Switch2#show interface trunk




Trunking on RouterA can be verified using the "show interfaces fa0/0.5" command:

RouterA#show interfaces fa0/0.5

FastEthernet0/0.5 is up, line protocol is up

Hardware is Gt96k FE, address is c200.4d5c.0000 (bia c200.4d5c.0000)

Internet address is 192.168.5.10/24

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation 802.1Q Virtual LAN, Vlan ID 5.

ARP type: ARPA, ARP Timeout 04:00:00

Last clearing of "show interface" counters never

References:

Configuring InterVLAN Routing and ISL/802.1Q Trunking on a Catalyst 2900XL/3500XL/2950 Switch Using an External Router:

http://www.cisco.com/en/US/tech/tk389/tk815/technologies_configuration_example09186a00800949fd.shtml

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot VTP


Lab Scenario

Lab Objectives

Lab Solution






Introduction

VLAN Trunking Protocol (VTP) provides a mechanism to share VLAN information across multiple switches. This helps in maintaining a consistent VLAN data across the network easily. To understand the importance of VTP imagine creating VLANs on 50-100 switches manually and then making any change across all of them.


VTP is used to manage VLAN information across a Layer 2 network. It allows you to add, delete and rename VLANs. Such changes are then propogated across the network and implemented on all the switches.

A switch can be in any of the three following modes:

Server: A VTP Server propogates its VLAN information throughout the network. The clinets will have the same VLAN database as the server. This is the default mode on Cisco Switches.

Client: A VTP client receives the VTP information from the server and changes its VLAN database accordingly. You cannot add, delete and edit VLAN information on a VTP Client. Once a client receives the VLAN information from the server, it implements the changes and also sends out the received information out all its trunks.

Transparent: A VTP transparent switch does not use the VLAN information received from the VTP server. VLANs can be created, deleted and modified on a transparent switch. It keeps its VLAN database isolated from the rest of the network but floods out the information received from the VTP server.

When VLAN information is changed on a VTP server, it will flood out VTP packets on its trunk ports. The VTP packet will contain a revision number which increases with every change. When a VTP client receives a VTP packet from anywhere, it compares the revision number contained in the packet. If the received revision number is higher than the current revision number then the new information is implemented.

For VTP information to be accepted and transmitted ahead, the VTP domain name must be the same across the network. The links between switches have to be trunks for VTP to work.

VTP communication can be protected using a password. If the password does not match then the VTP information is discarded by clients. This way a rouge VTP server cannot effect the network.

VTP Pruning: VTP gives you a way to preserve bandwidth by configuring it to reduce the amount of traffic which flows through the trunks. This is called pruning. VTP pruning enables switches to send broadcasts only to trunk links that actually need the information. For example in Figure 1, Switch B does not need broadcasts originated in VLAN 3 because it does not have any hosts in that VLAN. If VTP Pruning is enabled, the trunk between SwitchA and SwitchB will not allow broadcasts originated in VLAN 3 to go across.

Figure 1

VTP configuration can be broken into the following steps:

Configure mode using the vtp mode <server|client|transparent> command Configure domain using the vtp domain <name> command

Configure password using the vtp password <password> command (optional)

Configure pruning using the vtp pruning command(optional)

VTP configuration can be verified using the show vtp status command

Lab Scenario

We have recently acquired 3 Cisco Switches. We need to ensure a consistent VLAN database across the switches with the least possible administrative burden. You task is to configure SwitchA such that VLAN information can be changed on this switch only. You need to ensure that the VTP updates are secure. Additionally, we will not have hosts in all configured VLANs on each switch. You need to configure VTP so that bandwidth can be preserved in this situation by stopping unnecessary broadcasts. The links between the switches have been already configured as trunks. The network setup is shown in Figure 2.

Figure 2

Lab Objectives Configure VTP domain and Server mode and password on SwitchA Configure VTP domain and client mode and password on rest of the switches

Enable VTP pruning

Lab Solution

Since the VLANs can be added or modified on SwitchA only, it will have to be the VTP Server. The rest of the switches will be VTP clients. Since the domain name is not mentioned, we can use anything we like as long as it is consistent across the network:

SwitchA(config)#vtp domain test

SwitchA(config)#vtp mode server

SwitchB(config)#vtp domain test

SwitchB(config)#vtp mode client

SwitchC(config)#vtp domain test

SwitchC(config)#vtp mode client

We need to secure VTP communication. This will require configuring a VTP password:

SwitchA(config)#vtp password vtplab

SwitchB(config)#vtp password vtplab

SwitchC(config)#vtp password vtplab

We also need to enable pruning so that bandwidth can be preserved across trunk links. Pruning needs to be enabled on the server only:

SwitchA(config)#vtp pruning

Let's verify the VTP configuration on all the switches using the show vtp status command:

SwitchA#sh vtp status

VTP Version : running VTP2

Configuration Revision : 2

Maximum VLANs supported locally : 1005

Number of existing VLANs : 8

VTP Operating Mode : Server

VTP Domain Name : vtplab

VTP Pruning Mode : Enabled

VTP V2 Mode : Enabled

VTP Traps Generation : Disabled

MD5 digest : 0xD3 0x9E 0xA3 0x43 0xA7 0x86 0xDE 0x3A

SwitchB#sh vtp status





VTP Operating Mode : Client






SwitchC#sh vtp status





VTP Operating Mode : Client






References:

Catalyst 2950 and Catalyst 2955 Switch Software Configuration Guide - Configuring VTP

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea5/configuration/guide/swvtp.html

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot RSTP operation


Lab Scenario




Lab Objectives

Lab Solution

Introduction

Loops on a layer 2 network can be very dangerous. Spanning Tree Protocol (STP) is used to make the layer 2 network loop free. There are two STP standards defined by IEEE - 802.1d (STP) and 802.1w (Rapid STP). As per IEEE standards, a switch can run one STP instance only. Cisco implements a changed to this by allowing one STP instance per VLAN. 802.1w on Cisco Switches is also known as Per VLAN Rapid Spanning Tree Protocol (PVRST).


STP works by identifying all the links in the network and then blocking all redundant links. To do this STP first elects a Root Bridge. Root bridge is the bridge with the best Bridge ID. Bridge ID is a combination of priority and the base MAC address of the switch. Priority is a configurable value between 0 to 61440 in increments of 4096. The default priority on Cisco switches is 32768. The lower the priority and MAC address the better.

The root bridge is the center of the network. All decisions are taken from the prespective of the root bridge. Switches send Bridge Protocol Data Unit (BPDU) out every port. The BPDUs contain amongst other information the BridgeID. By comparing the BridgeIDs the root bridge is selected.

Once the root bridge is elected the rest of the switches in the network (called Non-root Bridge) will select one port which is their lowest cost way to the Root bridge - This port is called the root port.. The cost is determined by the bandwidth. Then port cost is used to find the lowest cost port connecting a network segement to the switch - This port is called the designated port. Root ports, designated ports and all port on the root bridge are in Forwarding mode. Rest of the ports go into a blocked or alternate mode.

Ports in Forwarding mode will send and receive data and BPDUs. Blocked ports will not send or receive data but will receive BPDUs. Alternate ports are redundant root ports which can be used as soon as the root port goes down.

In Figure 1, if bridge priorities are left at default then, Switch1 will become the root bridge because of the lowest base MAC address. Switch2's root port will be fa0/2 due to lower path cost. Switch3's root port will be fa0/1. Switch2's fa0/1 and Switch3's fa0/2 ports will be the alternate ports.

Figure 1

If we need to get Switch2 elected as the root bridge then we will need to lower its priority.

If a host is connected to a host then STP can be disabled on that port by enabling Portfast mode on it. This will ensure that the port goes into forwarding as soon as it comes up.

By default IEEE 802.1d is enabled on most Cisco switches. It can be changed to RSTP with the following global configuration mode command:

spanning-tree mode rapid-pvst

The priority of a Switch can be changed for a VLAN to make it the root bridge of the VLAN using the following command:

spanning-tree vlan <vlan#> priority <priority>

The cost of port can also be modified by using the following interface command:

spanning-tree cost <cost>



To enable portfast on a port use the spanning-tree portfast command on the interface mode.

Spanning tree operation can be verified using the show spanning-tree vlan <vlan#> command

Lab Scenario

We have a network running 802.1D. We need to make the following changes in the network:

Use 802.1w instead of 802.1d Make SwitchC the root bridge for VLAN 2

There will be a host connect to SwitchB on port fa0/10. Disable STP on this port.

The network is shown in Figure 2.

Figure 2

Lab Objectives Enable Rapid PVSTP on all switches Change the priority of SwitchC for VLAN 2

Enable Portfast on fa0/10 on SwitchB

Lab Solution

First STP mode needs to be changed on all switches:

SwitchA(config)#spanning-tree mode rapid-pvst

SwitchB(config)#spanning-tree mode rapid-pvst

SwitchC(config)#spanning-tree mode rapid-pvst

SwitchD(config)#spanning-tree mode rapid-pvst

To make SwitchC the root bridge let's change its priority to 4096

SwitchC(config)#spanning-tree vlan 2 priority 4096

Since the rest of the switches are at default priority (32768) SwitchC will become the root bridge for VLAN 2.

To disable STP on fa0/10 on SwitchB, we will need to enable Portfast on it:

SwitchB(config)#interface fa0/10

SwitchB(config-if)#spanning-tree portfast

Let's verify the spanning-tree operations on SwitchC and SwitchA:

SwitchC#show spanning-tree vlan 2

VLAN0002

Spanning tree enabled protocol rstp

Root ID Priority 4098

Address 0014.a93f.8380

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 4098 (priority 4096 sys-id-ext 2)



Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Fa0/1 Desg FWD 19 128.17 P2p

Fa0/2 Desg FWD 19 128.20 P2p

SwitchA#show spanning-tree vlan 2

VLAN0002

Spanning tree enabled protocol rstp

Root ID Priority 4098


Cost 23

Port 1 (FastEthernet0/1)


Bridge ID Priority 32770 (priority 32768 sys-id-ext 2)

Address 0013.c3e8.2500


Aging Time 300

Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Fa0/1 Root FWD 19 128.15 P2p

Fa0/2 Altn BLK 100 128.19 P2p

Note in the output that SwitchC is the root bridge and SwitchA's fa0/1 is the root port since its cost is lower that fa0/2's cost.

References:

Catalyst 2950 and Catalyst 2955 Switch Software Configuration Guide - Configuring STP

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea5/configuration/guide/swstp.html

LAB1 SWITCH SECURITY

Exam: 640-816

Exam Objective: Implement basic switch security (including: port security, trunk access, management vlan other than vlan1, etc.)


Lab Scenario

Lab Objectives

Lab Solution

Lab 2: Trunk Access

Introduction

Trunk links are 100 or 1000Mpbs links connecting a Switch to either another Switch or a Router or a Server. Unlike access links, Trunks carry traffic of Multiple VLANs. This enables communication between hosts connected to different switches. There are 2 trunking protocols available - IEEE 802.1q and ISL.


By default Trunks allow traffic from all VLANs to go through it. This is not always desirable. Sometimes you want to control what VLANs traffic can go through a trunk link. Some situation which demands this are :

Security - You want to restrict traffic of certain VLANs to certain switches only. For example in Figure 1, VLAN 5 can be restrict to SwitchA and SwitchB by not allowing traffic for VLAN 5 to go out fa0/2 of both the switches

Figure 1

Load Balancing - You have redundant paths between switches and want to maximize utilization. So some VLANs will be allowed on some trunks only to ensure that all trunks are used effectively. In Figure1, if you need get traffic of 4 VLAN from Switch A to SwitchD then you can allow 2 out fa0/1 and the rest out fa0/2. Effectively you will be load balancing across both the links.

Control traffic flow direction - You might want to control traffic flow direction. For example you might want to ensure that certain traffic takes a certain path to ease load on a highly used path. If SwitchC is handling a lot of traffic from its directly connected hosts then traffic from SwitchA to SwitchD can be redirected out SwitchB by denying some VLANs out fa0/2 on SwitchA.

The following interface command can be used to configure allowed VLANs on a trunk:

switchport trunk allowed vlan <option | vlan #>

Let's see the options available with this command and their explanation

SwitchA(config-if)#switchport trunk allowed vlan ?

WORD VLAN IDs of the allowed VLANs when this port is in trunking mode

add add VLANs to the current list






all all VLANs

exceptall VLANs except the following

none no VLANs

removeremove VLANs from the current list

WORD

Allows only vlans specified. Note that this command will overwrite existing list.

Examples:

switchport trunk allowed vlan 1,2,3

switchport trunk allowed vlan 1-10

add

Add vlans to the current list

Example:

switchport trunk allowed vlan add 1-10

all

Allow all vlans to go through the tunnel

Example:

switchport trunk allowed vlan all

except

Allow all vlans except the specified vlan to go through the tunnel. This command will overwrite the existing list

Example:

switchport trunk allowed vlan except 5-7

none

Do not allow any VLAN to go through the trunk.

Example:

switchport trunk allowed vlan none

remove

Remove specified VLAN from the current list

Example:

switchport trunk allowed vlan remove 5

Table 1 - Allowed VLANs Options

Allowed VLAN configuration can be verified using the show interfaces trunk command

Lab Scenario

Figure 2

You task is to configure the network shown in Figure 2 such that :

Traffic for VLAN 2 is restricted between SwitchA and SwitchB Traffic originating from SwitchE - VLAN 3 takes the SwitchE->SwitchC->SwithA->SwitchB->SwitchD path and back

Traffic originating from SwitchE - VLAN 4 takes the SwitchE->SwitchD->SwitchB->SwitchA->Switch C path and back

All links shown in Figure 2 are 802.1q trunks.

Lab Objectives Do not allow VLAN 2 on fa0/2 of SwitchA and SwitchB Do not allow VLAN 3 on fa0/1 of SwitchE and SwitchC

Do not allow VLAN 4 on fa0/2 of SwitchE and fa0/1 of SwitchD

Lab Solution

The first task states that VLAN 2 should be restricted to SwitchA and SwitchB. Both of them connect to different switches via respective fa0/2 interfaces. Hence VLAN 2 would need to be removed from those interface:


SwitchA(config-if)#switchport trunk allowed vlan remove 2

SwitchB(config)#interface fa0/2

SwitchB(config-if)#switchport trunk allowed vlan remove 2

Second task requires us to remove VLAN 3 from fa0/1 of SwitchE and SwitchC. This will ensure that traffic for VLAN 3 has only one path to take.

SwitchE(config)#interface fa0/1

SwitchE(config-if)#switchport trunk allowed vlan except 3

SwitchC(config)#interface fa0/1

SwitchC(config-if)#switchport trunk allowed vlan except 3

Since all VLANs are allowed through a trunk by default, we could have used the remove option instead of except option here.

The final task requires us to remove VLAN 4 from fa0/2 of SwitchE and fa0/1 of SwitchD so that VLAN 4 has only one path to take.

SwitchE(config)#interface fa0/2

SwitchE(config-if)#switchport trunk allowed vlan except 4

SwitchD(config)#interface fa0/1

SwitchD(config-if)#switchport trunk allowed vlan except 4

Let's verify the configuration on the switches:

SwitchA#show interfaces trunk




Port Vlans allowed on trunk

Fa0/1 1-4094

Fa0/2 1,3-4094

SwitchB#show interfaces trunk





Fa0/1 1-4094

Fa0/2 1,3-4094

SwitchC#show interfaces trunk





Fa0/1 1-2,4-4094

Fa0/2 1-4094

SwitchD#show interfaces trunk





Fa0/1 1-3,5-4094

Fa0/2 1-4094

SwitchE#show interfaces trunk





Fa0/1 1-2,4-4094

Fa0/2 1-3,5-4094

References:

Catalyst 2950 and Catalyst 2955 Switch Software Configuration Guide - Defining Allowed VLANs on a Trunk


LAB2 SWITCH SECURITY

Exam: 640-816

Exam Objective: Implement basic switch security (including: port security, trunk access, management vlan other than vlan1, etc.)


Lab Scenario

Lab Objectives

Lab Solution

Lab 1: Port Security

Introduction

What happens when a switch boots up? Its CAM table is empty. As hosts start sending traffic, the switch learns the MAC Addresses and builds it CAM table. This means that any host which plugs into a switch can start communicating with the rest of the network. This causes a security concern. How do you prevent unauthorized access to the network?

Another question which demands consideration is limited bandwidth. Each switch port has 10 or 100 Mpbs bandwidth often. If someone plugs in a switch or hub and then connects multiple hosts behind a single port, it will effectively decrease the bandwidth. How do you prevent that from happening?

The answer to both these questions is Port Security.


Cisco Switches allow us to configure security on individual switch ports. Port Security has the following options :

Configure static MAC addresses which can connect on a port

If you know that only a particular host will connect to a switchport then you can configure the switch to allow only that MAC address to send data on it. This can be done using the following interface command:

switchport port-security mac-address <H.H.H>

In the above command <H.H.H> is the 48 bit MAC address in that format.

One variation to to this command is the sticky option. This saves us from configuring the MAC address statically. Instead it will take the first MAC address seen on the port as a static MAC address. Thereafter only that MAC address will be able to connect on that port. The command to configure this is :






switchport port-security mac-address sticky

Configure maximum number of MAC addresses which can send data at a time

If you do not want someone from connecting a switch or hub to connect multiple hosts or if you want to restrict the number of hosts which can be connected to such a switch or hub then you can use the maximum option with port-security:

switchport port-security maximum <maximum-allowed-hosts>

<maximum-allowed-hosts> is any number between 1 to 5120

By default the maximum allowed hosts on a switchport is set to 1.

Before configuring any of the port-security options, port-security itself needs to enabled and the port should be in access mode. The following commands will do this:

switchport mode access

switchport port-security

Examples:

To configure a switchport to allow only a host with MAC address 0011.1cb4.a43e to connect to interface fa0/10 the following commands will be used:

Switch(config)#interface fa0/10

Switch(config-if)#switchport port-security

Switch(config-if)#switchport port-security mac-address 0011.1cb4.a43e

To configure the switchport to only allow the first 2 hosts to be the only hosts to connect in future the following commands can be used:

Switch(config)#interface fa0/10

Switch(config-if)#switchport port-security

Switch(config-if)#switchport port-security mac-address sticky

Switch(config-if)#switchport port-security maximum 2

What happens when a security restriction is violated? By default the Switch will put a violated port into error disabled mode. When this happens the administrator will have to manually put the switch back in normal mode using errdisable recovery command.

There are three configurable violation actions:

Protect : The violated port will not be put into the error disabled mode. The port will continue to fuction but will drop packets received from the violating MAC address

Restrict : Same as protect but in addition a message will be generated for the administrator using syslog or SNMP

Shutdown : The violated port will be put into error disabled mode. This is the default action.

The command to configure the violation action is :

switchport port-security violation <protect|restrict|shutdown>

Port-security can be verified using the following commands:

show port-security - shows the port-security configuration on ports

show port-security address - shows the mac addresses configured or learned

Lab Scenario

You task is to configure SwitchA such that :

Only our Web Server can connect to port fa0/1. The MAC address of the webserver is 0010.c250.1400. If a violation is detected then the port should not be disabled but the administrator should be notified

We will connect a hub on port fa0/2 but we need only 5 machines from the hub to be able to send data. If more than 5 hosts connect then the additional hosts should not be able to send data. The administrator need not be notified of this violation

We will connect an IP phone on fa0/3. A PC will be connected to the IP Phone. The MAC address of the IP phone is 0011.1d94.023a. We need to ensure that only the IP Phone and the first PC to connect to it are allowed to send data out this switchport. The port should be put in an error disabled state in case of violations.

Lab Objectives Enable port-security on fa0/1 and configure the static mac-address. Violation mode should be set to restrict. Enable port-security on fa0/2 and set maximum to 5. Violation mode should be set to protect.

Enable port-security on fa0/3 and set maximum to 2. Add one static mac-address and also the sticky option. The default violation mode is shutdown so nothing needs to be changed for that.

Lab Solution

Configure static mac-address based port-security on fa0/1:


SwitchA(config-if)#switchport mode access

SwitchA(config-if)#switchport port-security

SwitchA(config-if)#switchport port-security mac-address 0010.c250.1400

SwitchA(config-if)#switchport port-security violation restrict

Configure the maximum allowed hosts on fa0/2 to 5 and set the violation mode to protect:




SwitchA(config-if)#switchport port-security maximum 5

SwitchA(config-if)#switchport port-security violation protect

Configure the static mac-address of fa0/3 and enable sticky option:




SwitchA(config-if)#switchport port-security mac-address 0011.1d94.023a

SwitchA(config-if)#switchport port-security mac-address sticky

Let's verify the configuration:

SwitchA#show port-security

Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action

(Count) (Count) (Count)

---------------------------------------------------------------------------

Fa0/1 1 1 0 Restrict

Fa0/2 5 0 0 Protect

Fa0/3 1 1 0 Shutdown

---------------------------------------------------------------------------

SwitchA#show port-security address

Secure Mac Address Table

------------------------------------------------------------------------

Vlan Mac Address Type Ports Remaining Age

(mins)

---- ----------- ---- ----- -------------

1 0010.c250.1400 SecureConfigured Fa0/1 -

1 0011.1d94.023a SecureConfigured Fa0/3 -

------------------------------------------------------------------------

References:

Catalyst 2950 and Catalyst 2955 Switch Software Configuration Guide - Configuring Port-Based Traffic Control

http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea5/configuration/guide/swtrafc.html

LAB 1 OSPF TROUBLESHOOTING

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot OSPF


Lab Scenario

Lab Objectives

Lab Solution

Introduction

In this lab you will have to perform configuration tasks in relation to OSPF areas, as well as some redistribution of routes between RIPv2 and OSPF. To complete this lab you will need access to either lab consisting of four Cisco routers or a router simulation program. There are a number of free router simulators available for download from the Internet. As with any other program you download from the Internet make sure you scan it for viruses


When OSPF special areas are implemented the result the ability to support more scalability in networks and increased network stability. The memory of the routers within these areas is not used as much because the LSA messages that are sent are decreased. How much LSA traffic is decreased depends on the area that is implemented. The OSPF areas are stand area, backbone area, stub area, totally area, and NSSA.

OSPF standard areas are the default OPSF area type which accept the following LSA message types: route summary, link updates, and route summaries.

OSPF backbone areas are the area type that all other areas connect to. It also accepts the following LSA message types: route summary, link updates, and route summaries.

Stub areas do not accept any external routes into the area (LSA type 5). These areas cannot contain Autonomous System Boundary Routers (ASBRs) unless the ASBR is also an Area Border Router (ABR). To send packets outside the area a default route is used.






Totally stubby areas do not accept external routes or summary routes from external areas. These areas cannot contain Autonomous System Boundary Routers (ASBRs) unless the ASBR is also an Area Border Router (ABR). To send packets outside the area a default route is used.

NSSA has the same benefits of stub and totally stubby areas, plus also accepts type 7 LSAs and ASBRs

In order for an area to be a stub or a totally stub area, there are a number of criteria that must be met:

All routers within the area must be configured as stub router prior to forming a neighbor relationship.

There must be only one exit (ABR) from the area. If it is acceptable for packets to not take the optimal route to a destination, then this rule can be avoided if the ABRs both interject default routes into the area.

The area cannot be a backbone area.

The area cannot have virtual links traveling through it.

Routers configured as just ASBR are not permitted within the area.

The remainder of this tutorial and lab will focus on stub areas, totally stub areas, and NSSA.

Stub Areas:

After OSPF is configured, if an OSPF area is to be made a stub area this must be complete. For an area to be considered a stub area all routers need to be defined as stub routers. Stub areas are typically used in a hub and spoke topology. A common example would be a head office and remote office. The head office network would be the hub and the routers in the remote office would be considered the spoke routers. An example of this can be found in the diagram below:

In the diagram above RouterA is in the branch office stub area and RouterB's S0/0/0 interface is also in this area. RouterB's other interface is within the company's head office backbone (transit) area as is one of the interfaces of RouterC.

Once OSPF is properly enabled on RouterA and RouterB then these routers must be configured as stub routers. After this is done, the cost of the default router can be changed. The following commands are required to configure the router as a stub and to change the default cost:

areaarea-id stub [no summary]

The area-id parameter is used to identify the area and can either be a decimal number or a dotted decimal number.

The optional [no summary] parameter is what is used to ensure the ABR does not send summary LSAs into the area. This optional parameter will be discussed more in the next section of this tutorial.

area area-id default-cost cost

The area-id parameter is used to identify the area and can either be a decimal number or a dotted decimal number.

The cost parameter is used to change the default cost (1) of the summary route. The cost can be in the range of 0 to 16777215.

In the above figure RouterB is the ABR.To properly configure RouterA and RouterB the following commands will be required: (Based on the assumption that the interfaces have been properly configured.)

RouterA

router ospf 23

network 172.17.0.0 0.0.255.255 area 5

area 5 stub

RouterB

router ospf 23

network 172.18.0.0 0.0.255.255 area 0

network 172.17.0.0 0.0.255.255 area 5

area 5 stub

Totally Stubby Areas:

Totally stubby areas are a Cisco proprietary implementation. These areas block external router (LSA type 5), summary router (LSA type 3), and interarea routes (LSA type 4). The end result is even more memory saving.

To configure a totally stubby area, after OSPF has been configured, all routers within the area must be configured as stub routers with the area stub command. Then on the ABR the area stub command the no summary parameter must be issued. In the previous example, RouterB's configuration would be as follows:

router ospf 55

network 172.18.0.0 0.0.255.255 area 0

network 172.17.0.0 0.0.255.255 area 5

area 5 stub no-summary

NSSA:

NSSA (not so stubby area) was first introduced in RFC 3101 (supported by Cisco IOS 11.2) to allow the some external routes into the stubby area. This is achieved with a special LSA type (7). The NSSA ASBR creates this LSA and the ABR takes this LSA and make it into a type 5 LSA (default route) and passes this into the rest of the area. The steps to configuring NSSA is the same as stub area except instead of issuing the stub area command on all routers the following command needs to be issued on all routers:

area area-id nsaa [no-resdistribution] [default-information-originate [metric metric-value] [metric-type type-value]] [no-summary]

The area-id parameter is used to identify the NSSA and can be either a decimal number or a dotted decimal number.

The optional [no-resdistribution] parameter is an NSSA ABR and the redistribution routes are only to go into the standard area and not the NSSA area.

The optional default-information-originate parameter is what is used to generate type 7 LSAs.

The optional metric parameter sets the metric for default area. This value can be in the range of 0 to 16777214.

The optional metric-type parameter sets the metric type of default routes. Type 1 external routes and Type 2 external routes.

The no-summary parameter sets the area as an NSSA but without summary routes can be interjected into it.

Stub Area Verification:

To ascertain LSA details the show ip ospf database command is used.

To ascertain all routes the show ip route command is used.

To ascertain the OSPF area types the show ip ospf command is used.

To ascertain details of all type 7 LSA the show ip ospf database nssa-external command.

Lab Scenario

For this OSPF lab consider the following network:

Connect you lab as shown using the labeled IP addresses.

Lab Objectives

You are tasked to configure OSPF on Routers Beta and Charlie. The criterion that is to be met is the following:

Configure RIPv2 on Alspha using your own IP addressing sceme. Area 49 is to only accept inter-area routes and a default route from RIP. RIP is to use a metric of 10. There are to be no external routes from the backbone. The OSPF process ID for router Beta is 13.

Area 49 is to be configured as a Not so Stubby Area (NSSA). Charlie is to have a process-id of 25.

Lab Solution

Beta:

router ospf 13

redistribution rip metric 10

network 172.20.19.0 0.0.0.255 area 49

area 49 nssa

Charlie:

router ospf 25

network 172.21.0.0 0.0.255.255 area 0

network 172.20.19.0 0.0.0.255 area 49

area 49 nssa no-summary

LAB 2 OSPF TROUBLESHOOTING

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot OSPF

Contents

Introduction Technology Background

Lab Scenario

Lab Objectives

Lab Solution

Introduction

Open Shortest Path First (OSPF) is an open standard link state routing protocol. OSPF works by using the Dijkstra algorithm. First, a shortest path tree is constructed, and then the routing table is populated with the resulting best paths. An OSPF network is divided into areas to minimize routing update traffic and restrict network instability to a region. It is classless protocol and does not have any hop limits. Being a link state protocol, OSPF will send updates only on startup and when a change is seen in the network.


The shortest path is calculated using the Dijkstra algorithm. The algorithm places each router at the root of a tree and calculates the shortest path to each destination based on the cumulative cost required to reach that destination. Each router will have its own view of the topology even though all the routers will build a shortest path tree using the same link-state database.

The cost (also called metric) of an interface in OSPF is an indication of the overhead required to send packets across a certain interface. A higher bandwidth indicates a lower cost. Therefore there is more overhead (higher cost) and time delays involved in crossing a 56k serial line than crossing a 10M ethernet line. The formula used to calculate the cost is:

cost= 100000000/bandwith in bps

Using this formula, we find that the cost of a 10MB interface is 64 (100000000/ 1544000)

The cost of an interface can be manually changed using the "ip ospf cost <value>" interface command. The value can be anything from 1 to 65535.

OSPF uses multicast addresses 224.0.0.5 and 224.0.0.6 to send out updates. All OSPF routers listen to 224.0.0.5 and some special ones (DR/BR - discussed ahead) listen to 224.0.0.6. When there is a change in network OSPF floods out the update into the network. To limit the extent of the flood, OSPF uses areas. Flooded updates do not go from one area to another.

Area 0 is called the backbone area. All other areas should connect to area0. Routers that belong to multiple areas, and connect these areas to the backbone area are called area border routers (ABR).

An area is interface specific. A router that has all of its interfaces within the same area is called an internal router (IR). A router that has interfaces in multiple areas is called an area border router (ABR). Routers that act as gateways (redistribution points) between OSPF and other routing protocols (IGRP, EIGRP, IS-IS, RIP, BGP, Static) or other instances of the OSPF routing process are called autonomous system boundary router (ASBR). Any router can be an ABR or an ASBR. ABR sends routes between areas.

Figure 1 shows the different kind of routers that exist in an OSPF network:

Figure 1

To enable OSPF on a router we need to follow the steps given below:






Enable OSPF using "router ospf <process-id>" global configuration command Assing areas to interfaces using the "network <network> <wildcard mask> <area-id>" command

Example:

Router(config)#router ospf 1

Router(config-router)#network 192.168.1.0 0.0.0.255 area 0

Note that the process-idis only significant locally on the router. It keeps different OSPF processes separate. Routes will not be shared between two OSPF processes by default. We will need to configure redistribution for them to share the routes.

As soon as the network command is added, OSPF will start sending out Hello packets through the interfaces which belong to the specified network. Hello packets are used to find neighbors and later to check if the neighbor is alive. An adjacency needs to be formed before routers will exchange routes and updates.

A router will not form adjacency with every neighbor it discovers. Adjacency depends on various factors which are dictated by the type of network primarily. These are the OSPF network types:

Broadcast (multi-access):

Broadcast (multi-access) networks such as Ethernet allow multiple devices to connect to the same network as well as provide a broadcast (and multicast) ability in which a single packet is delivered to all nodes on the network.

Non-broadcast multi-access:

Non-broadcast multi-access (NBMA) networks are types such as Frame Relay, X.25, and Asynchronous Transfer Mode (ATM). These networks allow for multi-access but have no broadcast (and multicast) ability like Ethernet. So, NBMA networks require special OSPF configuration to function properly and neighbor relationships must be defined

Point-to-point:

Point-to-point refers to a type of network topology consisting of a direct connection between two routers that provides a single communication path. The point-to-point connection can be physical, as in a serial cable directly connecting two routers, or it can be logical, as in two routers in different locations connected by a circuit in a Frame-Relay network.

Point-to-multipoint:

Point-to-multipoint refers to a type of network topology consisting of a multiple connections between a single interface on one router and multiple destination routers. All routers thus connected share the same network.

In Broadcast Multiaccess and NBMA networks, OSPF chooses a Designated Router (DR) and a Backup Designated Router (BDR). All routers belonging same area in that network segment will form adjacency with the DR and BDR and send all route information and updates to them only. DR in turn sends the routes and updates to the other routers.

In Point-to-Point and Point-to-Multipoint DR/BDR are not elected because there are only two routers in a single segment. Both the routers will form adjacency with each other.

To form adjacency the Area ID and the Hello and Dead intervals need to be same on the routers. Hello interval is the period in which hello packets are sent out. Dead interval is the period after which a neighbor is declared dead if no Hello packets are received.

DR/BDR are selected through an election. Priority and Router ID and two factor which are used to elect the DR and BDR. Priority is a configured value which is set to 1 by default. The priority can be increased or decreased to influence the election of DR/BDR. Router ID is:

The highest loopback interface IP address; or If loopback interface does not exist then the highest Physical Interface IP Address

Loopback interfaces are logical interfaces, which are virtual, software-only interfaces; using loopback interfaces with your OSPF configuration ensures that an interface is always active for OSPF processes and the Router ID does not change. Router ID is used in election only if multiple routers have been configured with the highest priority in the segment.

OSPF Priority is configured on per interface basis. The priority can be changed using the "ip ospf priority <priority>" command. <priority> can be a value from 0 to 255. If priority is configure as 0 then the router will not participate in DR/BDR election.

The following commands can be used to verify OSPF configuration and operation:

show ip route - Displays the routing table of a router show ip ospf neighbor - Displays discovered neighbors and the relation with them

show ip ospf - Displays information about all ospf process configured on the router

show ip ospf database - This will display information about routers and networks in the OSPF network.

show ip ospf interface - Displays interface level OSPF information such as DR/BDR in the segment connected to the interface

Lab Scenario

Your task is to configure OSPF in our network as shown in Figure 2. The following should be ensured:

RouterC never becomes the DR or BDR for any segment RouterID of RouterA should be 1.1.1.1

RouterID of RouterB should be 2.2.2.2

RouterID of RouterC should be 3.3.3.3

RouterID of RouterD should be 4.4.4.4

RouterID of RouterE should be 5.5.5.5

RouterA should be the DR for its segment connected to RouterB and RouterC

Router D should be the DR for its segment connected to RouterE and RouterC

All networks shown should be visible on each router's routing table

Figure 2

Lab Objectives Create a loopback interface on all routers and assign the IP address depending on the RouterID required Enable OSPF on all routers and advertise all connected networks as per the area information shown

Set the priority of RouterC's interfaces to 0

Set the priority of RouterA's fa0/0 interface to 255

Set the priority of RouterD's fa0/1 interface to 255

Verify the routing table

Lab Solution

First let's create loopback interfaces on all routers:

RouterA(config)#interface loopback0

RouterA(config-if)#ip address 1.1.1.1 255.255.255.0

RouterB(config)#interface loopback0

RouterB(config-if)#ip address 2.2.2.2 255.255.255.0

RouterC(config)#interface loopback0

RouterC(config-if)#ip address 3.3.3.3 255.255.255.0

RouterD(config)#interface loopback0

RouterD(config-if)#ip address 4.4.4.4 255.255.255.0

RouterE(config)#interface loopback0

RouterE(config-if)#ip address 5.5.5.5 255.255.255.0

If the loopback interface is not configured before enabling OSPF process then the highest physical IP address will be taken as Router ID. The OSPF process would need to be restarted of the IP Router ID to take effect. For the same reason we will configure the priorities before enabling OSPF:

RouterC should not become a DR or BDR. This requires us to change the priority of its interface to 0:

RouterC(config)#interface fa0/0

RouterC(config-if)#ip ospf priority 0

RouterC(config-if)#exit


RouterC(config-if)#ip ospf priority 0

We also need to ensure that RouterA and RouterD are the DRs for their segment. We will need to increase the priority above 1 (default on Cisco Routers) to ensure that they become DRs:

RouterA(config)#interface fa0/0

RouterA(config-if)#ip ospf priority 255

RouterD(config)#interface fa0/1

RouterD(config-if)#ip ospf priority 255

Finally let's enable OSPF process and advertise the connect networks in the correct Area:

RouterA(config)#router ospf 1

RouterA(config-router)#network 192.168.1.0 0.0.0.255 area 0

RouterA(config-router)#network 10.1.1.0 0.0.0.255 area 0

RouterB(config)#router ospf 1

RouterB(config-router)#network 192.168.1.0 0.0.0.255 area 0

RouterB(config-router)#network 10.1.2.0 0.0.0.255 area 0

RouterC(config)#router ospf 1

RouterC(config-router)#network 192.168.1.0 0.0.0.255 area 0

RouterC(config-router)#network 192.168.2.0 0.0.0.255 area 1

RouterD(config)#router ospf 1

RouterD(config-router)#network 192.168.2.0 0.0.0.255 area 1

RouterD(config-router)#network 10.1.3.0 0.0.0.255 area 1

RouterE(config)#router ospf 1

RouterE(config-router)#network 192.168.2.0 0.0.0.255 area 1

RouterE(config-router)#network 10.1.4.0 0.0.0.255 area 1

Now let's verify it all routes are visible on RouterA and RouterD:

RouterA#show ip route

--output truncated--

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Loopback0


O IA 10.1.3.0 [110/30] via 192.168.1.3, 00:01:03, FastEthernet0/0

O 10.1.2.0 [110/20] via 192.168.1.2, 00:01:13, FastEthernet0/0

C 10.1.1.0 is directly connected, FastEthernet0/1


C 192.168.1.0/24 is directly connected, FastEthernet0/0

O IA 192.168.2.0/24 [110/20] via 192.168.1.3, 00:01:03, FastEthernet0/0

IA next to O stands for OSPF Inter-Area routes.

RouterD#show ip route




C 4.4.4.0 is directly connected, Loopback0


C 10.1.3.0 is directly connected, FastEthernet0/0



O 10.1.4.0 [110/20] via 192.168.2.2, 00:01:42, FastEthernet0/1

O IA 192.168.1.0/24 [110/20] via 192.168.2.3, 00:01:42, FastEthernet0/1


Let's verify the DRs on both the segments. This can be done by using the "show ip ospf neighbor" command.

RouterC#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

1.1.1.1 255 FULL/DR 00:00:39 192.168.1.1 FastEthernet0/0

2.2.2.2 1 FULL/BDR 00:00:34 192.168.1.2 FastEthernet0/0

4.4.4.4 255 FULL/DR 00:00:35 192.168.2.1 FastEthernet0/1

5.5.5.5 1 FULL/BDR 00:00:30 192.168.2.2 FastEthernet0/1

The output shows that RouterA and RouterD are DRs for their respective segments and RouterC is neither the DR or BDR for any segment.

You will also notice from the output that the RouterID of the routers are as required.

RouterID can further be verified using the "show ip ospf interface" command.

RouterA#show ip ospf interface fa0/0

FastEthernet0/0 is up, line protocol is up

Internet Address 192.168.1.1/24, Area 0

Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10

Transmit Delay is 1 sec, State DR, Priority 255

Designated Router (ID) 1.1.1.1, Interface address 192.168.1.1

Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

oob-resync timeout 40

Hello due in 00:00:01

Supports Link-local Signaling (LLS)

Index 1/1, flood queue length 0

Next 0x0(0)/0x0(0)

Last flood scan length is 1, maximum is 3

Last flood scan time is 0 msec, maximum is 4 msec

Neighbor Count is 2, Adjacent neighbor count is 2

Adjacent with neighbor 2.2.2.2 (Backup Designated Router)

Adjacent with neighbor 3.3.3.3

Suppress hello for 0 neighbor(s)

RouterB#show ip ospf interface fa0/0




Transmit Delay is 1 sec, State BDR, Priority 1








Next 0x0(0)/0x0(0)




Adjacent with neighbor 1.1.1.1 (Designated Router)



RouterC#show ip ospf interface fa0/0




Transmit Delay is 1 sec, State DROTHER,Priority 0








Next 0x0(0)/0x0(0)







RouterC#show ip ospf interface fa0/1




Transmit Delay is 1 sec, State DROTHER, Priority 0








Next 0x0(0)/0x0(0)







RouterD#show ip ospf interface fa0/1




Transmit Delay is 1 sec, State DR, Priority 255








Next 0x0(0)/0x0(0)







RouterE#show ip ospf interface fa0/1




Transmit Delay is 1 sec, State BDR, Priority 1








Next 0x0(0)/0x0(0)







References:

OSPF Design Guide

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

LAB 1 EIGRP TROUBLESHOOTING

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot EIGRP


Lab Scenario

Lab Objectives

Lab Solution

Introduction

EIGRP is a Cisco proprietary enhanced distance vector (hybrid) routing protocol. It is a classless protocol which sends output updates at startup and when there is a change in the network. The maximum hop count for EIGRP is 255. It supports various Routed protocols such as IPv4, IPv6, Appletalk, etc. It uses proprietary Reliable Transport Protocol (RTP) to send updates and Diffusing Update Algorithm (DUAL) to find the best path.


EIGRP is started on a router using the "router eigrp <as>" command. AS stands for Autonomous system.AS defines an EIGRP network. Routers belonging to different Autonomous Systems do not share routing information.

Once EIGRP has been started, network can be defined using the "network <address> <wildcard mask>". Wildcard mask is optional if you are using default subnet mask for the address class.






As soon as the network statement is added, EIGRP will start on interface which belongs to the Network configured with the network command. EIGRP will start sending out Hello packets to multicast address 224.0.0.10 to discover neighboring routers running EIGRP.

If it receives an ACK or Hello from another router in the same EIGRP AS then it will form an adjacency with it and the routers will exchange their full routing table.

EIGRP maintains a table of all its neighbors. This table can be viewed using the "show ip eigrp neighbor" command.

Routes received from neighbors are stored in a local topology table.

The route received from the neighbor will have a metric attached to it. This is the metric that is applicable on the advertising router. This is called the Reported Distance (RD). The receiving route will need to add the metric of the link between itself and the advertising router. If multiple paths are learned to a remote network then the path with best metric (RD + metric to the advertising router) is selected. This metric is the Feasible Distance (FD).

The path with the best metric is called the Successor. This is the route which will be presented to the router for the routing table. All other route to the same remote network will be kept as Feasible Successors as long as their RD is lower than the FD. Feasible successor is the route which will be used when the Successor is lost. EIGRP will keep upto 6 successors in the topology table.

EIGRP uses a combination of Bandwidth, Delay, Load and Reliability to calculate the metric of a route. Metric is the cost of using that route.

EIGRP topology table can be viewed using "show ip eigrp topology" command.

An important thing to note about EIGRP communication between two routers is that it is done using a Multicast to 224.0.0.10 IP address. If a route does not get Hellos from an adjacent router for a configured period then it will remove it from its neighbor table and also remove all routes learned from it.

Similarly if an EIGRP update is not acknowledged by an adjacent neighbor then update will be resent using a unicast packet up to 16 times. If the adjacent router still fails to acknowledge the update then the adjacency will be torn down and all routes learned from that neighbor will be flushed.

We learned previously that EIGRP will select the route with the best metric. What if there are multiple routes to the same destination with the same metric? EIGRP can load-balance over a maximum of 6 such equal cost paths. By default it is configured to load balance between 4 paths. This can be changed using the following command:

Router(config)#router eigrp 1

Router(config-router)#maximum-paths 6

As mentioned earlier EIGRP has a maximum hop count of 255 but the default maximum hop count is 100. This can be changed using the following command:

Router(config)#router eigrp 1

Router(config-router)#metric maximum-hops 255

The number 255 can be anything from 1 to 255.

EIGRP can be disabled on an interface using the "passive-interface <interface>" command in the EIGRP configuration mode. This will stop EIGRP from sending and receiving Hello packets on an interface. This means that EIGRP will not for adjacency on that interface and hence will not send or receive routes.

Lab Scenario

We want to use EIGRP in the network shown in Figure 2. Your task is to configure EIGRP on all routers such that:

Traffic from 192.168.1.0/24 never goes through RouterC to reach 192.168.7.0/24 RouterB never load-balances between the two paths to 192.168.7.0/24

RouterA should not form adjacency if Hello packets are received on its fa0/1 interface

RouterC and RouterD should not form adjacency if Hello packets are received on their fa0/2 interfaces.

Apart from the restrictions above, all routers should know about all the networks. AS 100 should be used across the network.

Figure 2

Lab Objectives Configure EIGRP is AS 100 on all routers and advertise all connected routes Set maximum hop to 2 on RouterA

Set maximum-paths to 1 on RouterB

Configure fa0/1 as passive on RouterA

Configure fa0/2 as passive on RouterC and RouterD

Lab Solution

First we need to enable EIGRP on all routers and advertise their connected routes:

RouterA(config)#router eigrp 100

RouterA(config-router)#network 192.168.1.0

RouterA(config-router)#network 192.168.2.0

RouterB(config)#router eigrp 100

RouterB(config-router)#network 192.168.2.0



RouterC(config)#router eigrp 100

RouterC(config-router)#network 192.168.3.0



RouterD(config)#router eigrp 100

RouterD(config-router)#network 192.168.5.0



We need to ensure that traffic from 192.168.1.0/24 never cross RouterC on the way to 192.168.7.0/24. RouterB will have the path form RouterC as a feasible successor to 192.168.7.0/24. This path will be advertised to RouterA if RouterB's fa0/2 link goes down.

The difference between the two paths for RouterA is the hop count. If we restrict the hop count to 2 on RouterA then the path to 192.168.7.0/24 from RouterC will never be used because its hop count is higher.


RouterA(config-router)#metric maximum-hops 2

We can stop RouterB from load-balancing by setting maximum-paths to 1 instead of default 4 :

RouterB(config)#router eigrp 100

RouterB(config-router)#maximum-paths 1

Finally we can make the given interfaces passive by using the following commands:


RouterA(config-router)#passive-interface fa0/1

RouterC(config)#router eigrp 100

RouterC(config-router)#passive-interface fa0/2

RouterD(config)#router eigrp 100

RouterD(config-router)#passive-interface fa0/2

Let's verify configuration by looking at the routing table of each router:

RouterA#show ip route



D 192.168.4.0/24 [90/309760] via 192.168.2.2, 00:01:59, FastEthernet0/0







RouterB#show ip route










RouterC#show ip route










RouterD#show ip route










[90/307200] via 192.168.5.1, 00:03:35, FastEthernet0/1

We can further verify the configuration using "show ip protocols" command:

RouterA#sh ip protocols

Routing Protocol is "eigrp 100"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

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 2

EIGRP maximum metric variance 1

Redistributing: eigrp 100

EIGRP NSF-aware route hold timer is 240s

Automatic network summarization is in effect

Automatic address summarization:

192.168.1.0/24 for FastEthernet0/0

Maximum path: 4

Routing for Networks:

192.168.1.0

192.168.2.0

Passive Interface(s):

FastEthernet0/1

Routing Information Sources:

Gateway Distance Last Update

192.168.2.2 90 00:06:31

Distance: internal 90 external 170

RouterB#sh ip protocols













192.168.5.0/24 for FastEthernet0/0, FastEthernet0/1



Maximum path: 1


192.168.2.0

192.168.3.0

192.168.5.0



192.168.3.2 90 00:07:25

192.168.2.1 90 00:07:26

192.168.5.2 90 00:07:26


RouterC#show ip protocols
















Maximum path: 4


192.168.3.0

192.168.4.0

192.168.6.0


FastEthernet0/2



192.168.3.1 90 00:09:16

192.168.6.2 90 00:09:16


RouterD#show ip protocols
















Maximum path: 4


192.168.5.0

192.168.6.0

192.168.7.0


FastEthernet0/2



192.168.5.1 90 00:10:08

192.168.6.1 90 00:10:08


References:

Enhanced Interior Gateway Routing Protocol

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml

Configuring EIGRP

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfeigrp.html

LAB2 EIGRP TROUBLESHOOTING

Exam: 640-816

Exam Objective: Configure, verify, and troubleshoot EIGRP


Lab Scenario

Lab Objectives

Lab Solution






Introduction

To take advantage of the features of EIGRP, it needs to be configured. The steps to configure EIGRP are very basic and can be completed very easily. Great care must be taken to ensure that the configuration of EIGRP is properly planned.


For EIGRP to function properly among a group of routers, the routers need to be assigned within the same Autonomous System (AS). An AS is a set of routers under the same administrative control. If an AS is isolated the configuration is very straight forward. When there is a router which connects to another AS or a router not running EIGRP, great care needs to be taken. Throughout this tutorial the configuration of the routers will be based upon the following diagram.

Router A interfaces are connected as follows:

Serial 0 - 172.30.20.40 to External AS

Serial 1 - 172.25.30.2

Serial 2 - 172.25.5.4

One of the interfaces on Routers B, C, and D are part of AS 150.

Enabling EIGRP

There are three steps which need to be taken to enable EIGRP. The first step is to issue the router eigrp command, issue the network command, and if required issue the bandwidth command. Router eigrp command is what identifies the routing protocol as EIGRP and the network command identifies which networks are participating in EIGRP (as far as that router) is concerned. The bandwidth specifies the bandwidth available over the interface for routing updates. If this command is not used, then available bandwidth is assumed to be T1. If the wrong bandwidth is assumed then routing updates may become lost or the router may not converge. The proper syntax of the command is as follows:

router eigrp autonomous-system-number

autonomous-system-number is the number of the autonomous system the router is a member of.

network network-number [wild-mask]

network-number is the address of the directly connected network/subnet.

[wild-mask] is an optional parameter that can be used to further specify how the network address is to be read. When a 0 is used in the wild card mask this means that the specified octet must match. If 1 is used the number does not need to match.

bandwidth kilobits

kilobits is the kilobits available for updates.

There are a few general rules that must be followed when setting the bandwidth of serial interfaces. If the interface is a generic serial interface, then the bandwidth must be set to the line speed. If the interface is a point to point Frame Relay then the bandwidth must be set to the CIR. If the interface is a multipoint Frame Relay then (if they all share the same CIRs) set the bandwidth to the total of all CIRs. If the PVCs have different CIRs then the lowest CIR is taken and multiply that by the number of PVCs available.

To configure Router B the following commands would be required:

RouterB(config) # router eigrp 150

RouterB(config-router)# network 172.25.30.0



For Router A if the S1 was a generic interface with a 64 kbps line speed then the required command to set the bandwidth would be

RouterA(config-if)# bandwidth 64

There are a number of reasons to use the wildcard mask of the network command. The most common is that you want to ensure that a router does not form an adjacency with an interface or when you want the router not to treat network commands as classful networks (thus summarizing network addresses when possible).

It is now time to look at configuring of Router A illustrated at the beginning of this tutorial. Router A has one interface (S0) which connects to an external AS. This is a text book reason to use the wildcard parameter of the network command. You need to ensure that a neighbor relationship is not established with 172.30.20.40.

To configure Router A the following commands would be required:

RouterA(config) # router eigrp 150

RouterA(config-router) # network 172.25.30.0 0.0.0.255

RouterA(config-router) # network 172.25.5.0 0.0.0.255

Due to the above configuration the external AS will not be advertised within AS 150. If there is a need to configure a last-resort gateway or default gateway to this network, then the ip default-network command is used. The syntax of this command is

ip default-network network-number

To ensure the 172.30.0.0 network command is advertised within the AS, the specific command that must be issued on Router A is:

RouterA(config)# ip default-network 172.30.0.0

Through EIGRP this network is advertised to the other router which will set this as their default network. This means that the other router's gateway of last resort is set to this.

Lab Scenario

In this lab we will configure EIGRP according to the needs of the following network:

Router East interfaces is connected as follows:

Serial 0 - 172.25.30.2 to External AS

Serial 1 - 172.29.6.3

Serial 2 - 172.29.5.5

The interfaces on routers North, South, West are part of AS 169.

To complete this lab you will need access to either a Cisco router or a router simulator. There is a number of free router simulators available for download from the Internet. As with any other program you download from the Internet make sure you scan it for viruses

Lab Objectives

In this lab you are tasked to configure all routers with EIGRP. Assume that all serial interfaces on router East are generic interfaces that have a 128 kbps line speed. Ensure that a neighbor relationship has not formed between Router East and the external AS. In addition, the external connection is to be the default network for AS 169. Finally, care must be taken so that the routers do not turn the route into classful networks.

Lab Solution

1. To enable EIGRP on Router East the following command need to be issued:

Router East(config) # router eigrp 169

Router East(config-router# network 172.29.6.0 0.0.0.255

Router East(config-router# network 172.29.5.0 0.0.0.255

This also ensures that Router East does not form a neighbor relationship with the External AS.

2. In order to interject the external connection as the default network the following command also needs to be issued on Router East:

Router East(config) # ip default-network 172.25.0.0

This will provide this as the gateway of last resort of Routers North, South, and West.

3. On each of the Serial interfaces of the Router East the following command must be issued:

Router East(config-if) #bandwidth 128

4. To enable EIGRP on Router South the following commands may be used:

Router South(config) # router eigrp 169

Router Southt(config-router) # network 172.29.5.0 0.0.0.255

Router South(config-router) # network 172.29.8.0 0.0.0.255

5. To enable EIGRP on Router West the following commands may be used:

Router West(config) # router eigrp 169

Router West(config-router) # network 172.29.7.0 0.0.0.255

Router West(config-router) # network 172.29.8.0 0.0.0.255

Router West((config-router) # network 172.29.14.00.0.0.255

6. To enable EIGRP on Router North the following commands may be used:

Router North(config) # router eigrp 169

Router North(config-router) # network 172.29.6.0 0.0.0.255

Router North(config-router) # network 172.29.7.0 0.0.0.255

Router North(config-router) # network 172.29.12.00.0.0.255

Exam: 640-816

Exam Objective: Implement basic router security


Lab Scenario

Lab Objectives

Lab Solution

Introduction

This CCNA lab 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


This lab will cover the basics of some important security measures to take when configuring any Cisco router. Namely, we will cover how to discuss securing the many ways of accessing a Cisco router, as well as briefly go over some other security measures, including access lists.

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.

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>enableRouter#config termRouter(config)#line con 0Router(config-line)#loginRouter(config-line)#password ciscoRouter(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>enablePassword:*******Router#config term ; puts you in Global Configuration ModeRouter(config)#line aux 0Router(config-line)#login ; Now in Line Configuration Mode






Router(config-line)#password ciscoRouter(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>enablePassword:*******Router#config termRouter(config)#line vty 0 4Router(config-line)#loginRouter(config-line)#password ciscoRouter(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.

To configure the host name on a router, follow these steps:

Router>enableRouter(config)hostname fl3ar1Router(config)^Zfl3ar1>

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>enableRouter#config termRouter(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.

Lab Scenario

You are the network administrator for the TestKing company. 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.

Your boss has hired his son, Joe, as an intern for the summer. Joe 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 Joe 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. You want to enhance the security of these routers.

Lab 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 Joe'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.

Lab 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>enablePassword:*******Battle#conf termBattle(config)#line con 0Battle(config-line)#loginBattle(config-line)#password oatmealBattle(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>enablePassword:*******Battle#conf termBattle(config)#line vty 0 3Battle(config-line)#loginBattle(config-line)#password oatbranBattle(config-line)#^Z

Battle#conf termBattle(config)#line vty 4Battle(config-line)#loginBattle(config-line)#password shellfishBattle(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>enablePassword:*******Battle#conf termBattle(config)#enable secret wheatgermBattle(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>enablePassword:*******Battle#conf termBattle(config)#no access-list 101Battle(config)#access-list 101 permit tcp host 172.18.56.14 ... any eq telnet logBattle(config)#access-list 101 deny tcp any any eq telnet logBattle(config)#access-list 101 deny icmp host 172.18.56.16 ... any eq echo-request logBattle(config)#access-list 101 permit ip any any Battle(config)#int s0Battle(config-int)#ip access-group 101 inBattle(config-int)#int s1Battle(config-int)# ip access-group 101 inBattle(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).

Final 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 logaccess-list 101 deny tcp any any eq telnet logaccess-list 101 deny icmp host 172.18.56.16 any eq echo-request logaccess-list 101 permit ip any any !interface Ethernet 0no shutdowndescription connected to Corporate LANip address 172.18.56.1 255.255.0.0keepalive 10ip access-group 101 in!interface Serial 0no shutdowndescription connected to Lincolnip address 172.19.1.2 255.255.255.252encapsulation ppp!interface Serial 1no shutdowndescription connected to Battleip address 172.20.1.1 255.255.255.252encapsulation ppp!router rip

network 172.18.0.0network 172.19.0.0network 172.20.0.0no auto-summary!!!line console 0exec-timeout 0 0password oatmeallogin!line vty 0 3password oatbranlogin!line vty 4password shellfishlogin!end

Battle Creek Router:

!service timestamps debug uptimeservice timestamps log uptime!hostname Battle!enable password wheatgerm!no ip name-server!ip subnet-zerono ip domain-lookupip routing!access-list 101 permit tcp host 172.18.56.14 any eq telnet logaccess-list 101 deny tcp any any eq telnet logaccess-list 101 deny icmp host 172.18.56.16 any eq echo-request logaccess-list 101 permit ip any any !interface Ethernet 0no shutdowndescription connected to Battle Creek LANip address 172.17.56.1 255.255.0.0keepalive 10!interface Serial 0no shutdowndescription connected to Corporateip address 172.20.1.2 255.255.255.252encapsulation pppip access-group 101 in!interface Serial 1no shutdowndescription connected to Lincolnip address 172.21.1.2 255.255.255.252encapsulation pppip access-group 101 in!router ripnetwork 172.17.0.0network 172.20.0.0

network 172.21.0.0no auto-summary!!!line console 0exec-timeout 0 0password oatmeallogin!line vty 0 3password oatbranlogin!line vty 4password shellfishlogin!end

Lincoln Router:

!service timestamps debug uptimeservice timestamps log uptimeservice password-encryption!hostname Lincoln!enable password wheatgerm!no ip name-server!ip subnet-zerono ip domain-lookupip routing!access-list 101 permit tcp host 172.18.56.14 any eq telnet logaccess-list 101 deny tcp any any eq telnet logaccess-list 101 deny icmp host 172.18.56.16 any eq echo-request logaccess-list 101 permit ip any any !interface Ethernet 0no shutdowndescription connected to Lincoln LANip address 172.16.56.1 255.255.0.0keepalive 10!interface Serial 0no shutdowndescription connected to Corporateip address 172.19.1.1 255.255.255.252encapsulation pppip access-group 101 in!interface Serial 1no shutdowndescription connected to Battleip address 172.21.1.1 255.255.255.252encapsulation pppip access-group 101 in!router ripversion 2network 172.16.0.0network 172.19.0.0

network 172.21.0.0no auto-summary!!!line console 0exec-timeout 0 0password oatmeallogin!line vty 0 3password oatbranlogin!line vty 4password shellfishlogin!end

Exam: 640-816

Exam Objective: Configure and apply access control lists based on network filtering requirements


Lab Scenario

Lab Objectives

Lab Solution

Introduction

Access lists (ACLs) filter network traffic by controlling whether routed packets are forwarded or blocked at the router's interfaces. The router examines each packet to determine whether to forward or drop the packet, based on the criteria you specified within the access lists.

Access list criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol, or other information.

Access lists are used in many other situations which do not deal with blocking packets. An example would be using Access List to determine which route will be advertised by a routing protocol.


Access lists are created using a series of statements called Access Control Entries (ACEs). Each ACE is a condition describing a network, or a host, or a protocol or a port or a combination of any of them.

Before we get into types of Access Lists and their creation, there are some ground rules we need to know well about what happens when a packet arrives at an interface or is about to leave an interface and an ACL is applied to it:

The Packet will be checked against the ACEs sequentially starting from the top. It will be compared with ACEs until a match is found. The action specified with the first ACE which matches will be

taken and no further ACEs will be checked

There is an implicit deny any the end. This means if the packet does not match any of the ACEs then it will be discarded.

There are 2 types are Access Lists supported by IOS:






Standard Access Lists: These use only the source IP address in an IP packet as the condition to match a packet. This means that standard access lists will permit or deny all traffic from any host/network. They do not differentiate between type of traffic.

Extended Access Lists: Extended access lists can evaluate many of the other fields in the layer 3 and layer 4 headers of an IP packet. They can evaluate source and destination IP addresses, the protocol field in the Network layer header, and the port number at the Transport layer header. This gives us more control more what kind of traffic is permitted or denied.

Access Lists do not do anything unless they are applied to the interface. Each interface can have one Access List per direction per layer 3 protocol. So it most of today's IP networks we can have one ACL in each direction each interface. The direction mentioned here refers to the direction of the traffic. When an Access List is applied to an inbound direction it will filter traffic coming from the network into the router. When it is applied in outbound direction it will filter traffic going from the router to the network.

Access Lists are created using the following syntax:

Standard Access List : access-list <1-99|1300-1999> <permit|deny> <address|host|any> <wildcard-mask>

Numbers are used to identify ACLs. Standard access list use the 1-99 and 1300-1999 range.

permit or deny states the action to take if a packet matches the condition

We can permit or deny based on an address/mask (example 1), or a single IP address (host) (example 2) or any traffic (example 3).

We will discuss wildcard masks shortly.

Example 1:

access-list 1 permit 192.168.1.0 0.0.0.255

Example 2:

access-list 2 deny host 192.168.1.1

Example 3:

access-list 3 permit any

Extended Access List: access-list <100-199 | 2000-2699> <permit|deny> <protocol> <source address> <source mask> < source port> <destination address> <destination mask> <destination port>

Extended ACLs use the numbers 100-199 and 2000-2699. In addition to the standard ACL options, we have the option to specify the destination address, Layer 4 protocol or IP and source and destination ports.

Example 1:

To block telnet traffic from any host to any host we will use the following Access List:

access-list 100 deny tcp any any eq 23

Note that eq stands for equal. We can use gt (greater than) and lt (less than) to specify port numbers.

Example 2:

To block traffic all IP traffic from the host 192.168.1.10 to network 10.1.1.0/24, we will use the following ACL:

access-list 101 deny ip host 192.168.1.10 10.1.1.0 0.0.0.255

Note that we have used a deny ACE. If this is the only ACE in the ACL, we will need to add an explicit permit statement in the end or else no traffic will be allowed due to the implicit deny.

Masks are used with IP addresses in IP ACLs to specify what should be permitted and denied. Masks in order to configure IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 209.165.202.129 with a 255.255.255.224 mask. Masks for IP ACLs are the reverse, for example, mask 0.0.0.255. This is sometimes called an inverse mask or a wildcard mask. When the value of the mask is broken down into binary (0s and 1s),

the results determine which address bits are to be considered in processing the traffic. A 0 indicates that the address bits must be considered (exact match); a 1 in the mask is a "don't care".

This table further explains the concept.

Mask Example

network address (traffic that is to be processed) 10.1.1.0

mask 0.0.0.255

network address (binary) 00001010.00000001.00000001.00000000

mask (binary) 00000000.00000000.00000000.11111111

Based on the binary mask, you can see that the first three sets (octets) must match the given binary network address exactly (00001010.00000001.00000001). The last set of numbers are "don't cares" (.11111111). Therefore, all traffic that begins with 10.1.1. matches since the last octet is "don't care". Therefore, with this mask, network addresses 10.1.1.1 through 10.1.1.255 (10.1.1.x) are processed.

Subtract the normal mask from 255.255.255.255 in order to determine the ACL inverse mask. In this example, the inverse mask is determined for network address 172.16.1.0 with a normal mask of 255.255.255.0.

255.255.255.255 - 255.255.255.0 (normal mask) = 0.0.0.255 (inverse mask)

Note these ACL equivalents.

The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any". The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".

As mentioned earlier, Access Lists are useless if not applied to an interface. They access be applied to an interface using the following command:

ip access-group <access-list> <in|out>

Example:

ip access-ground 101 in

We can use the following commands to verify Access Lists:

show access-lists - Will show all access-lists configured on the router and the count of packets which were denied or permitted through each ACE

show interfaces - Will show will ACL is applied in which directions on Interfaces.

Lab Scenario

We need some security added to our network shown in Figure 1. Your task is to configure the network such that:

HTTP and ICMP traffic should not be allowed from 172.16.0.0/24 and 172.17.0.0/24 networks to Server1 and Server 2. This configuration needs to be done at RouterA

Only hosts 172.16.1.1 and 172.16.1.2 can access server Server1 from the 172.16.1.0/24 network. This configuration needs to be done at RouterB

Only hosts 172.17.1.10 and 172.17.1.11 can access server Server2 from the 172.16.1.0/24 network. This configuration needs to be done at RouterC

Figure 1

Lab Objectives Create an Access List denying TCP/80 and ICMP traffic from 172.16.0.0/24 and 172.17.0.0/24 to Server1 and

Server2. Apply on RouterA fa0/1 Create an Access List permitting ip traffic from host 172.16.1.1 and 172.16.1.2 to Server1 and Server2. All other

traffic to Server1 and Server2 should be blocked. Apply this ACL on fa0/0 on RouterB

Create an Access List permitting ip traffic from host 172.17.1.10 and 172.17.1.11 to Server1 and Server2. All other traffic to Server1 and Server2 should be blocked. Apply this ACL on fa0/0 on RouterC

Lab Solution

The first task requires us to stop HTTP and ICMP traffic from coming to Server1 and Server2 by applying an ACL on RouterA. We will need to deny these traffic and then add an explicit permit in the end:

RouterA(config)#access-list 101 deny tcp 172.16.0.0 0.0.255.255 host 192.168.1.1 eq 80

RouterA(config)#access-list 101 deny icmp 172.16.0.0 0.0.255.255 host 192.168.1.1







RouterA(config)#access-list 101 permit ip any any

RouterA(config)#interface fa0/1

RouterA(config-if)#ip access-group 101 in

The Second task requires us to ensure that only the given hosts are able to access Server1 and Server2 by applying an ACL on RouterB. We first permit the given hosts and then deny all ip traffic destined to the Servers. In the end an explicit permit will be needed:

RouterB(config)#access-list 101 permit ip host 172.16.1.1 host 192.168.1.1




RouterB(config)#access-list 101 deny ip any host 192.168.1.1

RouterB(config)#access-list 101 deny ip any host 192.168.1.2

RouterB(config)#access-list 101 permit ip any any

RouterB(config)#interface fa0/0

RouterB(config-if)#ip access-group 101 in

The Last task also requires us to ensure that certain hosts are able to get to the Servers from RouterC:

RouterC(config)#access-list 101 permit ip host 172.17.1.10 host 192.168.1.1




RouterC(config)#access-list 101 deny ip any host 192.168.1.1

RouterC(config)#access-list 101 deny ip any host 192.168.1.2

RouterC(config)#access-list 101 permit ip any any


RouterC(config-if)#ip access-group 101 in

To verify this lab try to ping 192.168.1.1 from RouterB's fa0/0 interface. No ICMP reply should be received. The output will be similar to the one given below:

RouterB#ping 192.168.1.1 source fa0/0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.16.1.1

.....

Success rate is 0 percent (0/5)

References:

Configuring IP Access Lists

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml#standacl

Exam: 640-816

Exam Objective: Configure and apply an ACLs to limit telnet and SSH access to the router


Lab Scenario

Lab Objectives

Lab Solution

Introduction

It is important to have telnet and/or SSH access to a router because it is not always possible to have access to the physical console port. This need gives rise to a security hazard. Someone from or outside your network can try to access the telnet and guess/crack the username/password. So it is very important to protect this access using additional methods.







Cisco provides two ways to restrict access to the telnet/ssh line (line vty) using an access list. The first method is applying the access list to the vty line itself and the second is applying it to the physical interfaces of the router.

To restrict access using line vty, we can use a standard ACL. The command to create a standard ACL is:

access-list <1-99> permit <address> <mask>

or

access-list <1-99> permit host <host address>

This access-list can be applied to line vty using the following command:

access-class <access-list number> in

Example:

Router(config)#access-list 1 permit host 10.1.1.1

Router(config)#line vty 0 4

Router(config-line)#access-class 1 in

The above example will allow telnet from host 10.1.1.1 only because there is an implicit deny at the end of the access-list.

The second method requires us to create an extended access-list denying telnet (TCP port 23) to the router and apply it on the physical interface. The command to create extended access list is:

access-list <100-199> permit <protocol> <source address> <source mask> <source port> <destination address> <destination mask> <destination port>

or

access-list <100-199> permit <protocol> host <source address> <source port> host <destination address> <destination port>

This access list can be applied on an interface using the following command:

ip access-group <access-list number> in

Note that the access-lists applied in both the cases are in the in direction because we are filtering traffic coming into the router. Also note that the extended access-list will only stop telnet traffic coming in from that port. Telnet traffic may also come in from other physical ports so the procedure would have to be repeated for every interface.

Example:

Router(config)#access-list 101 permit tcp host 10.1.1.1 host 192.168.1.1 eq 23

Router(config)#access-list 101 permit tcp host 10.1.1.1 host 192.168.1.1 eq 22

Router(config)#access-list 101 deny tcp any host 192.168.1.1 eq 23

Router(config)#access-list 101 deny tcp any host 192.168.1.1 eq 22

Router(config)#access-list 101 permit ip any any

Router(config)#interface fa0/0

Router(config-if)#ip access-group 1 in

The above access-list permits telnet and ssh from 10.1.1.1 to 192.168.1.1 (router's IP) and then denies telnet and ssh from anyone else to the router. The last access-list entry is to permit all other traffic. If the last entry is not added, the implicit deny at the end will deny all traffic.

It is highly recommended that you do not apply telnet/ssh restricting access-lists while being connected to the router via telnet/ssh. Wrong configuration will lock you out. It is suggested to be connected via console or auxiliary while adding this configuration.

Lab Scenario

We need to secure telnet access to our routers using Access Lists. Our network is shown in Figure 1. Your task is to configure the Routers such that:

Only the administrator can telnet to RouterA from his workstation at 192.168.1.10 No telnet access should be permitted to RotuerB from s0/0. The IP address of s0/0 on RouterB is 200.1.130.1

Figure 1

Lab Objectives Configure a standard access-list and apply it to line vty on RouterA Configure an extended access-list and apply it to s0/0 on RouterB

Lab Solution

Let's configure RouterA first. Since the source address is known we can easily apply a standard access-list on the vty line:

RouterA(config)#access-list 1 permit host 192.168.1.10

RouterA(config)#line vty 0 4

RouterA(config-line)#access-class 1 in

For the next task we do not know the source addresses so we will need to use an extended access list to deny traffic to the interface ip address and apply it on the interface:

RouterB(config)#access-list 101 deny tcp any host 200.1.130.1 eq 23

RouterB(config)#access-list 101 permit ip any any

RouterB(config)#interface s0/0

RouterB(config-if)#ip access-group 1 in

The solution can be verified by initiating a telnet from RouterA to RouterB. You should not receive a username/password prompt.

References:

Controlling Access to a Virtual Terminal Line

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cntrl_acc_vtl.html

Exam: 640-816

Exam Objective: Configure NAT for given network requirements (including: CLI/SDM)


Lab Scenario

Lab Objectives

Lab Solution

Introduction

The Internet has grown larger than anyone ever imagined it could be. Although the exact size is unknown, the current estimate is that there are about 100 million hosts and over 350 million users actively on the Internet. That is more than the






entire population of the United States! In fact, the rate of growth has been such that the Internet is effectively doubling in size each year.

So what does the size of the Internet have to do with NAT? Everything! For a computer to communicate with other computers and Web servers on the Internet, it must have an IP address. An IP address (IP stands for Internet Protocol) is a unique 32-bit number that identifies the location of your computer on a network. Basically it works just like your street address: a way to find out exactly where you are and deliver information to you.

When IP addressing first came out, everyone thought that there were plenty of addresses to cover any need. Theoretically, you could have 4,294,967,296 unique addresses (232). The actual number of available addresses is smaller (somewhere between 3.2 and 3.3 billion) because of the way that the addresses are separated into Classes and the need to set aside some of the addresses for multicasting, testing or other specific uses.

This is where NAT comes to the rescue. Basically, Network Address Translation allows a single device, such as a router, to act as agent between the Internet (or "public network") and a local (or "private") network. This means that only a single unique IP address is required to represent an entire group of computers to anything outside their network.


Developed by Cisco, Network Address Translation is used by a device (firewall, router or computer) that sits between an internal network and the rest of the world. NAT has many forms and can work in several ways:

Static NAT - Mapping an unregistered IP address to a registered IP address on a one-to-one basis. Particularly useful when a device needs to be accessible from outside the network. For example if you have a server at 192.168.1.1 and you create a static NAT for it using a Public IP address of 200.1.1.1 then traffic from 192.168.1.1 will always be translated to 200.1.1.1 and traffic destined to 200.1.1.1 will always reach 192.168.1.1

Dynamic NAT - Maps an unregistered IP address to a registered IP address from a group of registered IP addresses. Dynamic NAT also establishes a one-to-one mapping between unregistered and registered IP address, but the mapping could vary depending on the registered address available in the pool, at the time of communication. For example, if you have 10 Public IP addresses and 15 hosts inside the private network then traffic from each host will take any free IP Address for the pool of 10 public addresses while going to the public network. If there is no free address then the traffic will not be able to go out to the public network.

Nat Overload or Port Address Translation: A form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address by using different ports. Known also as PAT (Port Address Translation), single address NAT or port-level multiplexed NAT. For example if host 192.168.1.1 is sending an HTTP packet to 200.1.20.10 then the source port will be random and destination port will be 80. The NAT device will replace the source address with the configured public address and source port with its own randomly generated port. Meanwhile if another host wants to go out then a different source port will be used for translation. This way upto 63000 sessions from different hosts can be served using a single public address.

The first step in configuring NAT is to define the inside and outside interfaces. You may find it easiest to define your internal network as inside, and the external network as outside. However, the terms internal and external are subject to arbitration as well. The figure below shows an example of this.

Figure 1

In Figure1, fa0/0 and fa0/1 will be defined as the inside interfaces and s0/0 will be the outside interface. The command to define the inside/outside interfaces is:

ip nat <inside|outside>

This is an interface level command.

Now the configuration differs depending on the type of NAT required:

Configure Static NAT: Static NAT requires a single line of configuration and it will allow bi-directional traffic. Which means a new session can be initiated from outside to inside. The command is:

ip nat inside source static <inside source> <public ip>

Example:

ip nat inside source static 192.168.1.1 200.1.20.10

This example configures a static NAT for inside IP 192.168.1.1 and public IP 200.1.20.10.

Dynamic NAT Configuration: For this we need to configure a pool defining public addresses, an access-list defined inside network/hosts and a nat statement to tie both of these:

ip nat pool <pool name> <start address> <end address> netmask <mask>

access-list <number> permit <source address> <mask>

ip nat inside source list <access-list number> pool <pool name>

Example:

ip nat pool test 200.1.1.10 200.1.1.20 netmask 255.255.255.0


ip nat inside source list 1 pool test

This example configures a pool of 11 addresses which will be used to translated traffic going from 192.168.1.0/24 to the outside network. At any time only 10 sessions will be allowed out.

PAT Configuration: PAT configuration is same as Dynamic NAT configuration with the exception that you will need to add the "overload" keyword to the nat statement:

ip nat pool <pool name> <start address> <end address> netmask <mask>

access-list <number> permit <source address> <mask>

ip nat inside source list <access-list number> pool <pool name> overload

Example:

ip nat pool test 200.1.1.10 200.1.1.10 netmask 255.255.255.0


ip nat inside source list 1 pool test overload

This Example configures a single address 200.1.1.10 to be used from traffic originating from 192.168.1.0/24 and destined to the outside network. The overload keyword will force the router to perform a Port Address Translation.

Two commands can be used to verify and troubleshoot NAT operation:

show ip nat translation - This will show the table of current translations debug ip nat - This will show debugs of traffic being natted

Lab Scenario

Our network is shown in Figure 2. We have a pool of 9 addresses given to us by the ISP. We need NAT configured on the Router such that:

Users from 10.1.1.0/24 can go out to the internet using the 199.80.7.65 IP address We have 3 servers in the 10.1.2.0/24 network - 10.1.2.10, 10.1.2.11 and 10.1.2.12. These servers should be

accessible from the internet using the 199.80.7.66, 199.80.7.67 and 199.80.7.67 addresses respectively

We have a group of 5 users in the 10.1.3.0/24 network. Their IP address is 10.1.3.2 to 10.1.3.6. They should be able to go out to the internet using an address from the pool of 199.80.7.68 to 199.80.7.72.

No one apart from the mentioned hosts should be able to out to the Internet using NAT.

Figure 2

Lab Objectives Configure fa0/0, fa0/1 and fa1/0 as inside interfaces and s0/0 as outside interface Configure PAT for the users in 10.1.1.0/24

Configure Static NAT for the servers in 10.1.2.0/24

Configure Dynamic NAT for the hosts in 10.1.3.0/24

Lab Solution

First we will need to define the inside and outside interfaces:

Router(config)#interface fa0/0

Router(config-if)#ip nat inside

Router(config-if)#interface fa0/1


Router(config-if)#interface fa1/0


Router(config-if)#interface s0/0

Router(config-if)#ip nat outside

Now we configure PAT for users in the 10.1.1.0/24 network:

Router(config)#ip nat pool pat 199.80.7.65 199.80.7.65 netmask 255.255.255.0

Router(config)#access-list 1 permit 10.1.1.0 0.0.0.255

Router(config)#ip nat inside source list 1 pool pat overload

Next we configure the static NAT for the servers in 10.1.2.0/24 network:

Router(config)#ip nat inside source static 10.1.2.10199.80.7.66



Finally we configure dynamic NAT for users in 10.1.3.0/24 network:

Router(config)#ip nat pool dnat 199.80.7.68 199.80.7.72 netmask 255.255.255.0






Router(config)#ip nat inside source list 2 pool dnat

Let's verify the PAT configuration first by sending an ICMP ping to the internet sourced from the fa0/0 interface:

Router#ping 200.1.10.20 so fa0/0



Packet sent with a source address of 10.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/20 ms

Router#sh ip nat translations

Pro Inside global Inside local Outside local Outside global

icmp 199.80.7.65:3 10.1.1.1:3 200.1.10.20:3 200.1.10.20:3

On adding a static NAT we will have an output similar to this one:



--- 199.80.7.66 10.1.2.10 --- ---

When there is a session established an additional NAT entry will be formed similar to this:



icmp 199.80.7.66:5 10.1.2.10:5 200.1.10.20:5 200.1.10.20:5

Finally let's see the NAT translation when traffic from 10.1.3.2 gets dynamically translated using the pool:



icmp 199.80.7.68:6 10.1.3.2:6 200.1.10.20:6 200.1.10.20:6

References:

How NAT Works

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml

Configuring Network Address Translation: Getting Started

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094e77.shtml

Exam: 640-816

Exam Objective: Configure and verify Frame Relay on Cisco routers

Contents Introduction



Lab Scenario

Lab Objectives

Lab Solution

Introduction

Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers of the OSI reference model. Frame Relay originally was designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well. This chapter focuses on Frame Relay's specifications and applications in the context of WAN services.

Frame Relay is an example of a packet-switched technology. Packet-switched networks enable end stations to dynamically share the network medium and the available bandwidth. Frame Relay often is described as a streamlined version of X.25, offering fewer of the robust capabilities, such as windowing and retransmission of last data that are offered in X.25. Frame Relay is a layer 2 technology.


The default encapsulation on a Cisco Router's serial interface is HDLC. To use Frame-Relay on them, the encapsulation needs to be changed using the "encapsulation frame-relay" command. With Frame Relay, there are further two encapsulation types - Cisco and IETF. Cisco is the default type and you will need to manually change it to IETF if you are connecting to a non-Cisco device. The command to do this is:

Router(config)#interface s0/0

Router(config-if)#encapsulation frame-relay ietf

Frame Relay operates using virtual circuits. These virtual circuits are what link together the devices connected to the provider's network. Frame Relay provides a virtual circuit between your two DTE devices, making them appear to be connected via a circuit when they are actually sending devices through a shared medium. There are two types of Virtual Circuits - Permanent virtual circuit (PVC) and Switched Virtual Circuit (SVCs). PVCs will always remain in place but SVCs are setup and torn down as and when data needs to be sent.

Frame Relay PVCs use Data Link Connection Identifiers (DLCIs). A Frame Relay service provider assigns DLCI values, which are used on Frame Relay interfaces to distinguish between different virtual circuits.

A DLCI can be assigned to an interface using the following command


Router(config-if)#frame-relay interface-dlci <dlci>

The DLCI value can be anything between 16 and 1007.

Local Management Interface (LMI) is a signaling standard used between your router and the first Frame Relay switch it's connected to. It allows for sharing information about the operation and status of the virtual circuit between the provider's network and your router. The following information is shared using LMI:

Keepalives: These verify that data is flowing.

Global addressing: This provides global significance to DLCIs, allowing the Frame Relay

cloud to work exactly like a LAN.

Status of virtual circuits: This provides DLCI status. The status inquiries and messages are

used as keepalives when there is no regular LMI traffic to send.

There are three different types of LMI message formats: Cisco, ANSI, and Q.933A. The different

kinds in use depend on both the type and configuration of the telco's switching gear, so it's important the router is configured to use the LMI type configured at the telco's end. Cisco is default LMI type.

LMI type can be configured using the following command:





Router(config-if)#frame-relay lmi-type <cisco|ansi|q933a>

LMI is autosensed in routers running IOS version 11.2 and above.

Let's see the configuration of a PVC on a Serial Interface:



Router(config-if)#ip address 192.168.1.1 255.255.255.0

Router(config-if)#frame-relay interface-dlci 101

The above example will configure a serial interface to use frame relay IETF encapsulation and DLCI 101. The router at the other end can use a DLCI provided by the ISP and 192.168.1.1 IP Address to reach us.

We can have multiple virtual circuits on a single Physical interface and each circuit can be treated as a different network/interface. This can be achieved using sub-interfaces. Frame Relay sub-interfaces can be point-to-point or multipoint. Point-to-Point sub-interfaces treat each DLCI as a different network. Multipoint interfaces will treat a group of DLCI as single network. Frame relay can be configured on sub-interfaces using the following commands:



Router(config-if)#exit

Router(config)#interface s0/0.1 point-to-point

Router(config-subif)#ip address 192.168.1.1 255.255.255.0

Router(config-subif)#frame-relay interface-dlci 101

The following commands can be used to verify frame relay configuration:

show frame-relay pvc show frame-relay lmi

show interfaces

Lab Scenario

We have purchased Frame Relay links between our Head Office and Branch Offices. Your task is to configure the Routers as shown in Figure 1. Ensure that IETF frame-relay encapsulation is used.

Figure 1

Lab Objectives Configure Frame Relay using sub-interfaces on RouterA using DLCI 102 and 103 Configure Frame Relay using the physical interface of Router B and DLCI 201

Configure Frame Relay using the physical interface of Router C and DLCI 301

Lab Solution

Before we configure Frame-relay, it should be noted that a Frame Relay switch is required between the devices for the link to work. A Cisco router can be configured as a Frame Relay Switch. See the References section for the URL to the document explaining the Frame Relay switch configuration:

Let's configure RouterA first:

RouterA(config)#interface s0/0

RouterA(config-if)#encapsulation frame-relay ietf

RouterA(config-if)#no shut

RouterA(config-if)#exit

RouterA(config)#interface s0/0.1 point-to-point

RouterA(config-subif)#frame-relay interface-dlci 102

RouterA(config-fr-dlci)#exit


RouterA(config-subif)#exit

RouterA(config)#interface s0/0.2 point-to-point

RouterA(config-subif)#frame-relay interface-dlci 103

RouterA(config-fr-dlci)#exit


Configuration on RouterB:


RouterB(config-if)#encapsulation frame-relay ietf

RouterB(config-if)#frame-relay interface-dlci 201

RouterB(config-fr-dlci)#exit


RouterB(config-if)#no shut

Configuration on RouterC:

RouterC(config)#interface s0/0

RouterC(config-if)#encapsulation frame-relay ietf

RouterC(config-if)#frame-relay interface-dlci 301

RouterC(config-fr-dlci)#exit

RouterC(config-if)#ip address 192.168.2.2 255.255.255.0

RouterC(config-if)#no shut

Let's verify connectivity from RouterA:

RouterA#ping 192.168.1.2



!!!!!





!!!!!


PVC status on RouterA:

RouterA#show frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

Active Inactive Deleted Static

Local 2 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

input pkts 7 output pkts 18 in bytes 610

out bytes 3502 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 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 7 out bcast bytes 2358

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

pvc create time 00:04:33, last time pvc status changed 00:04:13

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.2










PVC status on RouterB:

RouterB#show frame-relay pvc



Local 1 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0










PVC status on RouterC

RouterC#show frame-relay pvc



Local 1 0 0 0

Switched 0 0 0 0

Unused 0 0 0 0

DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0










References:

Configuring Frame Relay Switching

http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml#topic7

Frame Relay

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Frame-Relay.html

Comprehensive Guide to Configuring and Troubleshooting Frame Relay

http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml

Exam: 640-816

Exam Objective: Configure and verify a PPP connection between Cisco routers


Lab Scenario

Lab Objectives

Lab Solution

Introduction

The Point-to-Point Protocol (PPP) originally emerged as an encapsulation protocol for transporting IP traffic over point-to-point links. PPP also established a standard for the assignment and management of IP addresses asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, error detection, and option negotiation for such capabilities as network layer address negotiation and data-compression negotiation.


PPP is Data Link Layer Protocol and supports its functions by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCPs) to negotiate optional configuration parameters and facilities. In addition to IP, PPP supports other protocols, including Novell's Internetwork Packet Exchange (IPX) and DECnet.

The PPP LCP provides a method of establishing, configuring, maintaining, and terminating the point-to-point connection. LCP goes through four distinct phases.

First, link establishment and configuration negotiation occur. Before any network layer datagrams (for example, IP) can be exchanged, LCP first must open the connection and negotiate configuration parameters. This phase is complete when a configuration-acknowledgment frame has been both sent and received.

This is followed by link quality determination. LCP allows an optional link quality determination phase following the link-establishment and configuration-negotiation phase. In this phase, the link is tested to determine whether the link quality is sufficient to bring up network layer protocols. This phase is optional. LCP can delay transmission of network layer protocol information until this phase is complete. An optional authentication phase can be initiated here or along with the link-quality determination phase before NCP takes over.

At this point, network layer protocol 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. If LCP closes the link, it informs the network layer protocols so that they can take appropriate action.

Finally, link termination occurs. LCP can terminate the link at any time. This usually is done at the request of a user but can happen because of a physical event, such as the loss of carrier or the expiration of an idle-period timer.






PPP can be enabled on an interface using the "encapsulation ppp" command. Along with this a layer 3 address is required to ensure communication.

As mentioned before, PPP supports authenticating a link. There are two methods of authentication that can be used with PPP links:

Password Authentication Protocol (PAP): The Password Authentication Protocol (PAP) is the less secure of the two methods. Passwords are sent in clear text, and PAP is only performed upon the initial link establishment. When the PPP link is first established, the remote node sends the username and password back to the originating router until authentication is acknowledged.

Challenge Handshake Authentication Protocol (CHAP): The Challenge Handshake Authentication Protocol (CHAP) is used at the initial startup of a link and at periodic checkups on the link to make sure the router is still communicating with the same host. After PPP finishes its initial link-establishment phase, the local router sends a challenge request to the remote device. The remote device sends a value calculated using a one-way hash algorithm called MD5. The local router checks this hash value to make sure it matches. If the values don't match, the link is immediately terminated.

After PPP has been enabled on the interface, authentication can be configured between the routers. First, we need to set the hostname of the router. Then we set the username and password for the remote router that will be connecting to your router:

Example:

Router#config t

Router(config)#hostname RouterA

RouterA(config)#username RouterB password ppppassword

Note that the username (RouterB) is the hostname of the remote router and it is case sensitive. The password on both routers must be the same. We must have a username and password configured for each remote system we plan to connect to. The remote routers must also be configured with usernames and passwords. Now we need to enable authentication on the interface using the "ppp authentication <protocol> <protocol>" command. Note that the second protocol is optionally and is used only when the remote end does not support the first protocol. If a single protocol is selected and the remote then does not support it, the link will be terminated.

Example:


RouterA(config-if)#ppp authentication pap chap

PPP configuration can be verified using the following commands:

show interfaces debug ppp negotiation

Lab Scenario

We need to have PPP configured between our Head office and Branch Office. You task is to configure PPP on both the devices and ensure that they authenticate using "0urPPP" password. You also need to ensure that the authentication is done periodically after the link is established. Our network is shown in Figure 1:

Figure 1

Lab Objectives

Configure PPP on both routers using CHAP as authentication protocol

Lab Solution

RouterA(config)#username RouterB password 0urPPP


RouterA(config-if)#encapsulation ppp

RouterA(config-if)#ppp authentication chap

RouterA(config-if)#ip address 192.168.1.1 255.255.255.0

RouterA(config-if)#no shut

RouterB(config)#username RouterA password 0urPPP


RouterB(config-if)#encapsulation ppp

RouterB(config-if)#ppp authentication chap


RouterB(config-if)#no shut

Let's verify the connectivity from RouterA:




!!!!!


Let's see the interface output on both routers:

RouterA#show interfaces s0/0

Serial0/0 is up, line protocol is up

Hardware is GT96K Serial




Encapsulation PPP, LCP Open

Open: IPCP, CDPCP, loopback not set

Keepalive set (10 sec)

Last input 00:00:44, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:04:33

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec



65 packets input, 3035 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

74 packets output, 2900 bytes, 0 underruns

0 output errors, 0 collisions, 3 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

RouterB#show interfaces s0/0

Serial0/0 is up, line protocol is up

Hardware is GT96K Serial




Encapsulation PPP, LCP Open

Open: IPCP, CDPCP, loopback not set

Keepalive set (10 sec)

Last input 00:00:30, output 00:00:01, output hang never

Last clearing of "show interface" counters 00:05:20

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 1158 kilobits/sec



79 packets input, 3259 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

81 packets output, 3909 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

This is what debug ppp negotiation looks like on RouterA

*Mar 1 00:08:36.615: Se0/0 LCP: I CONFREQ [Open] id 3 len 15

*Mar 1 00:08:36.619: Se0/0 LCP: AuthProto CHAP (0x0305C22305)

*Mar 1 00:08:36.619: Se0/0 LCP: MagicNumber 0x0136C252 (0x05060136C252)

*Mar 1 00:08:36.627: Se0/0 IPCP: State is Closed

*Mar 1 00:08:36.635: Se0/0 PPP: Phase is TERMINATING

*Mar 1 00:08:36.635: Se0/0 PPP: Phase is ESTABLISHING

*Mar 1 00:08:36.639: Se0/0 LCP: O CONFREQ [Open] id 13 len 15



*Mar 1 00:08:36.647: Se0/0 LCP: O CONFACK [Open] id 3 len 15



*Mar 1 00:08:36.659: Se0/0 IPCP: Remove route to 192.168.1.2

*Mar 1 00:08:36.671: Se0/0 LCP: I CONFACK [ACKsent] id 13 len 15



*Mar 1 00:08:36.675: Se0/0 LCP: State is Open

*Mar 1 00:08:36.679: Se0/0 PPP: Phase is AUTHENTICATING, by both

*Mar 1 00:08:36.679: Se0/0 CHAP: O CHALLENGE id 3 len 28 from "RouterA"

*Mar 1 00:08:36.679: Se0/0 CHAP: I CHALLENGE id 3 len 28 from "RouterB"

*Mar 1 00:08:36.691: Se0/0 CHAP: Using hostname from unknown source

*Mar 1 00:08:36.695: Se0/0 CHAP: Using password from AAA

*Mar 1 00:08:36.695: Se0/0 CHAP: O RESPONSE id 3 len 28 from "RouterA"

*Mar 1 00:08:36.699: Se0/0 CHAP: I RESPONSE id 3 len 28 from "RouterB"

*Mar 1 00:08:36.699: Se0/0 PPP: Phase is FORWARDING, Attempting Forward

*Mar 1 00:08:36.703: Se0/0 PPP: Phase is AUTHENTICATING, Unauthenticated User

*Mar 1 00:08:36.711: Se0/0 PPP: Phase is FORWARDING, Attempting Forward

*Mar 1 00:08:36.715: Se0/0 PPP: Phase is AUTHENTICATING, Authenticated User

*Mar 1 00:08:36.731: Se0/0 CHAP: O SUCCESS id 3 len 4

*Mar 1 00:08:36.739: Se0/0 CHAP: I SUCCESS id 3 len 4

*Mar 1 00:08:36.743: Se0/0 PPP: Phase is UP

*Mar 1 00:08:36.747: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10

*Mar 1 00:08:36.747: Se0/0 IPCP: Address 192.168.1.1 (0x0306C0A80101)

*Mar 1 00:08:36.747: Se0/0 PPP: Process pending ncp packets

*Mar 1 00:08:36.755: Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10


*Mar 1 00:08:36.759: Se0/0 AAA/AUTHOR/IPCP: Start. Her address 192.168.1.2, we want 0.0.0.0

*Mar 1 00:08:36.775: Se0/0 AAA/AUTHOR/IPCP: Reject 192.168.1.2, using 0.0.0.0

*Mar 1 00:08:36.779: Se0/0 AAA/AUTHOR/IPCP: Done. Her address 192.168.1.2, we want 0.0.0.0

*Mar 1 00:08:36.783: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10


*Mar 1 00:08:36.783: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10


*Mar 1 00:08:36.783: Se0/0 IPCP: State is Open

*Mar 1 00:08:36.799: Se0/0 IPCP: Install route to 192.168.1.2

References:

PPP

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/PPP.html

Configuring PPP CHAP authentication

http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4131.shtml

Documents

Exam Ccna Lab