PART 1

NETWORK FUNDAMENTALS

OSI Reference Model

Name

PDU

Description

Protocols

Device
s

Applicatio
n

L7PDU

Telnet, HTTP, FTP,

DNS, DHCP, SNMP,
IMAP, SSH, SMTP,
POP3, VoIP, BGP.

Hosts,
Firewalls.

Presentati
on

L6PDU

Session

L5PDU

JPEG, MPEG, GIF,

MIDI, ASCII, MP3,
QuickTime, PICT,
EBCDIC, TIFF.
NFS (Network File
System).

Hosts,
Firewalls.

Transport

Segment

TCP, UDP, GRE.

Hosts,
Firewalls.

Network

Packet

Data Link

Frame

IP, IPsec, ICMP,

IGMP, ARP, IPX,
EIGRP, OSPF, RIP.
Ethernet (802.3), WiFi (802.11), CDP,
STP, VTP, PAgP,
LACP, L2TP, PPP,
HDLC, Frame Relay,
ATM, Token Ring,
FDDI.

Routers.

-Provides an interface between

application software and the network.
-Checks resource availability
-Defines processes and services for
user authentication.
-Formatting: Define and negotiate data
formats.
-Encryption.
-Compression.
-Defines how to Start, Control and End
a conversation (Session).
-Establishment and Maintenance of
end-to-end bidirectional flows between
endpoints.
-Management of transactional flows.
-Management of multiple application
processes and Scheduling.
-Connection establishment and
termination.
-Reliable or Best effort delivery.
-Flow Control (windowing, buffering and
congestion avoidance).
-Segmentation (of large data into
smaller parts for transmission) and its
Sequencing.
-Error Recovery.
-TCP/UDP port numbering.
-Acknowledgment.
-Logical Addressing.
-Routing.
-Path determination.
-Framing: formats data into frames.
-Defines rules that determine when a
device can send data over a particular
medium (CSMA/CD).
-Uses MAC Addressing for endpoint
communication.
-Provides Error detection using CRC and
FCS but no error recovery or correction.

Physical

Bits

-Defines electrical/ optical cabling,

connectors and pin-outs.
-Voltage and Wire Speed.

EIA/TIA-232, V.92,
ISDN, DSL, 10BASE
etc.
Ethernet (802.3)
Wi-Fi (802.11
a/b/g/n),
Bluetooth.

Hosts,
Firewalls.

Switches,
Bridges,
Wireless
Access
Points,
Cable and
DSL
Modems.
PCs NIC
Hubs,
Repeaters,
Cables,
CSU/DSU
PCs NIC.

Notes on OSI Layers

WANs operate at both layer 2 and layer 1 of OSI.

Encapsulation (adding headers and trailers) happens in a Top Down approach from layer 7 down to
layer 1 e.g. Packets are created when network layer 3 receives a Segment from upper layer 4 and
add layer 3 addresses and control information to that Segment.
Like TCP/IP each OSI layer asks for services from the next lower layer, e.g. if data transfer is slow
between source and destination the Transport layer 4 would request quality of service from Network
layer 3.
Layer 1 and Layer 2 are also called Network Access layer in TCP/IP Model.

Comparison of Networking Models

DoD
TCP/IP
Application
Transport
Internet
Link

Well-known
Port Number
20
21
22
23
25
26
53
67, 68
69
80
110
143
161
443
514

OSI Model
Application
Presentatio
n
Session
Transport
Network
Data Link
Physical

TCP/IP
Revised
Application
Transport
Network
Data Link
Physical

Protocol
TCP
TCP
TCP
TCP
TCP
TCP
UDP, TCP
UDP
UDP
TCP
TCP
TCP
UDP
TCP
UDP

associated Applications

ports and
Application
FTP data
FTP Control
SSH
Telnet
SMTP
Encrypted SMTP
DNS
DHCP
TFTP
HTTP
POP3
IMAP
SNMP
SSL
Syslog

TCP Connection Establishment and Termination

DNS

Headers and Trailer of PDUs

TCP Segment
Source Port
Header
Length

Destination Port

Reserved

Sequence Number
Acknowledgment
Code
Bits

Checksum

Window
Urgent

Options
Data (L5 PDU)

UDP Segment
Source Port
Length

Destination Port
Checksum
Data (L5 PDU)
IPv4 Packet

Version

IHL
Type of Service
Total Length
Identification
Flags
Fragment Offset
Time to Live
Protocol
Header Checksum
Source IP Address
Destination IP Address
Options
Data (Segment)
IPv6 Packet
Version
Traffic Control
Flow Label
Payload Length
Next Header
Hop Limit
Source IP Address
Destination IP Address
Data (Segment)

Ethernet Header
Ethernet operates at Layer 1 and Layer 2 of the OSI Model.
Data Link Layer 2 has two sub layers: the MAC Layer and the Logical Link Control (LLC) Layer. The MAC
layer is responsible for how data is sent over the wire and the LLC Layer is responsible for identifying and
encapsulating different protocol types.

Two types of LLC frames exist SAP (service access points) and SNAP (sub network access protocol). SNAP is
used to support non-802 protocols.
General Ethernet Frame (with Header and Trailer)
Preamble

SFD

Destination
MAC

Source
MAC

Type

Data & Pad

(Packet)

FCS

SNAP 802.2 Frame

Destination SAP

Source SAP

Control

OUI ID

Type

Data
(Packet)

SAP 802.2 Frame

Destination SAP

Source SAP

Control

Data (Packet)

MAC Layer 802.3 Frame

Preamble

Destination
MAC

Source MAC

Length

Data (Packet)

FCS

HDLC Standard Frame

Flag

Address

Control

Data
(Packets)

FCS

Flag

HDLC Cisco Frame

Flag

Address

Control

Protocol
Type
(Proprietar
y)

Data
(Packets)

FCS

Flag

PPP Frame
Flag

Address

Control

Protocol
Type
(Standardiz
ed)

Data
(Packets)

FCS

Flag

Frame Relay Frame

Flags

Address (DLCI)

Data
(Packets)

FCS

Flags

LMI Frame
Flag

LMI
DLCI

Unnumbered
Information
Indicator

Protocol
Discriminator

Call
Reference

Message
Type

Information
Elements

FCS

Flag

Network Devices and Components

Routers

Routers operate at Network Layer 3 of OSI and Revised TCP/IP and at Internet layer of DoD TCP/IP
model.

Router has following basic functions:

1. Internetwork Communication:
Routers are used to connect two or more different networks or subnets, so routing services
are also used for inter-VLAN traffic.
2. Path Determination:
Routers use their Routing table and Routing Protocols such as OSPF to determine the best
path through the networks.
3. Packet Switching and Packet Forwarding:
Once best path is determined router Switches packets from one network to another network
(or from one interface to other interface) and Forwards them to other router or LAN using
Routing Protocols such as IP.
4. Packet Filtering:
Routers can forward or filter packets and services based on IP addresses and TCP/UDP port
numbers.

Routers create a separate Broadcast Domain for each different network and interface i.e. every
interface is a single Broadcast Domain.
Packets are dropped if no destination is found.

Managed Routers usually dont work out of the box they have to be configured for services first.

Switches

Switches operate at Layer 2 Data Link of OSI Model, Link layer of DoD TCP/IP also called Network
Access Layer.

Switches have following basic functions:

1. Connecting Devices:
Switch connects multiple devices on a local area network (LAN).
2. Learning MAC Addresses:
Switch learns MAC addresses of connected devices using hardware ASIC and stores them in
its MAC Address Table (CAM Table).
3. Forwarding/Switching Ethernet Frames:
Switch uses the MAC Address Table to forward L2 Frames to its Unicast, Multicast or Broadcast
Destination(s).
4. Avoiding L2 Loops, Storms and MAC instabilities:
Switches use protocols like Spanning Tree Protocol to avoid loops and Broadcast Storms and
MAC addressing table instabilities.

A Switch (switch may literally referred to as a Bridge in old documents and protocols) is high-end
multiport Bridge as that is cheaper and faster.
In an all Switched environment with no Hubs etc. the Collisions are eliminated completely.
(Assuming no VLANs are configured) All interfaces of a Switch are in a single Broadcast Domain but
every interface is a separate Collision Domain in any case.
Switches can operate at Half or Full Duplex and support different Speeds.

Multilayer (Layer 3) Switches

MLS is essentially a switch with routing

capabilities, also called a Brouter (Bridge +
Router).
MLS does Switching by switching frames at Layer 2 using MAC Address and can perform Routing by
routing packets at Layer 3 using IP Address so its both a Layer 2 and Layer 3 Device.
When operating at Layer 3, MLS switches IP data packets between its interfaces or subnets
(networks) using advanced application-specific integrated circuit (ASIC) switching hardware, whereas
simple Routers dont use ASIC.

Bridges

Bridge operates at Layer 2 of OSI Model.

Bridge is used to divide one network into two or more Collision Domains or Segments, reducing
amount of traffic on a LAN by dividing it.
Each segment carries its own traffic due to being in a separate Collision.
Bridges serve similar function as a Switch i.e. they also use MAC Addressing Table, Unicast, Multicast
and Broadcast but with fewer ports and lack many advanced switch capabilities.

Hubs

A LAN device that provides a centralized connection point for LAN cabling, repeating any received
electrical signal out all other ports, thereby creating a logical bus. Hubs do not interpret the
electrical signals as a frame of bits, so hubs are considered to be Layer 1 devices.
Hubs operate at Physical Layer 1 of OSI Model, they essentially are multiport Repeaters.
Hubs are used to join network devices and connect them together.
Hub is an unintelligent device it repeats the signal out all other ports, Broadcasts any traffic it
receives and works only in Half Duplex using CSMA/CD logic.
All the ports are in single collision domain that may cause slow network performance.

Repeaters

Repeaters operate at Physical Layer 1 of OSI Model.

Repeaters are used to repeat or regenerate the weak signals due to distances.
Repeaters boost the signal so it can travel further.

CSU/DSU

Channel service unit/data service unit. A device that

understands the Layer 1 details of serial links installed by a Telco and how to use a serial cable to
communicate with networking equipment such as routers.
A CSU/DSU converts between the Layer 1 standards used on a Telcos WAN circuit and a serial
cables Layer 1 standards.
The CSU is responsible for the connection to the telecom network while the DSU is responsible for
handling the interface with the DTE. A CSU/DSU is the equivalent of the modem for an entire LAN.
Clocking is provided by CSU/DSU, WAN links can run at a wide variety of speeds. To deal with the
wide range of speeds, routers physically slave themselves to the speed as dictated by the CSU/DSU
through a process called clocking.
CSU/DSU can be purchased as an external device or may come integrated into Router and can also
be installed in the Router as a module.

Modems

Modulator-demodulator. A device that converts between digital and analog signals so that a
computer can send data to another computer using analog telephone lines.
At the source, a modem converts digital signals to a form suitable for transmission over analog
communication facilities. At the destination, the analog signals are returned to their digital form.

Types of Ethernet Ports

Commo
n
Name
Etherne
t
Fast
Etherne
t

Gigabit

Speed

Industry
Name

10 Mbps

10BASE-T

100
Mbps

100BASETX
100BASEFX
1000BASELX
1000BASE-

1000

Cable
Type
Cat3/Cat5
UTP
Cat5 UTP

Maxim
um
Length
100 m

IEEE
Stand
ard
802.3

100 m

802.3u

MM Fiber

400 m

SM Fiber

5 km

MM Fiber

550 m

802.3z

Etherne
t

10
Gigabit
Etherne
t

Mbps

10 Gbps

SX
1000BASEZX
1000BASE-T
1000BASETX
1000BASECX
10GBASESR
10GBASELR
10GBASESX4
10GBASELX4
10GBASE-T

SM Fiber

70 km

Cat5e UTP

100 m

Cat6 UTP

100 m

Copper

25 m

MM Fiber

300 m

SM Fiber

25 km

MM Fiber

550 m

SM Fiber

2 km

Cat6a/Cat7
UTP

100 m

802.3a
b

802.3a
e

802.3a
n

Cables
Cat5 UTP Copper Cable
End 1
T568 A
T568 B
T568 A

End 2
T568 A
T568 B
T568 B

Name
Straight-Thru
Straight-Thru
Crossover

T568 A Color Combination

Green Strap, Green, Orange Strap, Blue, Blue Strap, Orange, Brown Strap, Brown
T568 B Color Combination
Orange Strap, Orange, Green Strap, Blue, Blue Strap, Green, Brown Strap, Brown

Tx and Rx logic of Straight and Cross Cables

10BASE-T and 100BASE-TX Transmission

Transmits on Pins 1,2
PC NIC
Router
Wireless Access Point (Ethernet int)
Network Printers (that connect to LAN)

Transmits on Pins 3,6

Hubs
Switches
-

Uses of Different Types of Cables

Like (same) Devices = Cross Cable
Unlike Devices = Straight Cable

Rollover cable (console cable) is used to access Router or Switchs console.

Router and PCs NIC are considered Like devices because PC can be configured with routing
services to act as a router.
Switch is like a multiport Bridge or an intelligent Hub so they are also considered like devices.
Crossover Cable
Router
Switch/Brid
ge
Switch/Brid
ge
Hub
PC/Server
PC/Server

Router
Switch
Hub

Straight-Through
Cable
Router
Switch
Switch
PC/Server
Hub

PC/Server

Hub
PC/Server
Router

End-to-End Communication

LAN
Communication: PC1 Sends Data to PC2

PC1 wants to send data packets to PC2.

Through DNS PC1 has determined PC2s IP 192.168.1.2. And with help of subnet mask of /24 that
included hosts from 192.168.1.1 to 192.168.1.254, it has calculated that PC2 is in the same subnet
as itself.
They are in same LAN but In order to send data to PC2, PC1 also needs PC2s MAC Address.
1. To get PC2s MAC, PC1 looks in its ARP cache to look up 192.168.1.2 for any existing records
against it.
2. If found,
PC1 would build a frame around IP packet using its own MAC a:a:a:a:a:a as source and PC2s
MAC f:f:f:f:f:0 as destination and forward it directly to PC2.
3. If not found,
PC1 would send a Broadcast ARP Request with destination IP 192.168.1.2 and destination
MAC of all Fs which would be received by every device on the LAN, seeing that its a
Broadcast the Switch in the LAN would also flood the frame out all its working interfaces
(F0/2, F0/3) except the one it was received on (F0/1).
4. But seeing the destination IP all other devices would drop the frame and only PC2 would
process it and respond with a Unicast ARP Reply stating its MAC address.
Now after MAC address of PC2 has been found PC1 would save it in its ARP cache for future use and
data packets can be sent across two hosts.

WAN Communication: PC1 sends Data to Server

PC1 wants to send Data packets to Server on the other end.

Assumptions:
In the diagram above, lets assume that all routers are using OSPF and all routers already know routes for
all subnets. In particular, best route to subnet 172.16.1.0 is known on which the Server 172.16.1.1 resides.
All subnets have mask of /24.

To Send Data Packets to Server:

PC1:
1. Builds and IP Packet with destination address of 172.16.1.1 and source IP address of its own
192.168.1.1.
Because Server resides on different subnet that PC1, it need to send this packet to its default
gateway.
2. PC1 gets MAC address of its default gateway using ARP and IP address if 192.168.1.3.
3. Builds an Ethernet Frame with header and trailer and sends it to its default gateway R1 with
following information:
PC1s Ethernet Frame

Ethernet

Destination MAC
B:B:B:B:B:B

Source MAC
A:A:A:A:A:A

IP Packet
(Src
IP:192.168.1.1
Dst IP:
172.16.1.1)

FCS

R1:
1. Because the incoming frame has the destination MAC if R1s Ethernet interface R1 copies the
frame for processing.
2. R1 check frames FCS trailer and if errors are found the router would discard the frame
immediately, in this case no errors are found.
3. R1 discards the Ethernet header and trailer, and de-encapsulates the packet out of the frame.
4. R1 compares packets destination IP to its routing table and looks for subnet 172.16.1.0. (if
there are multiple paths to the same network router chooses the path with longest prefix or
largest subnet mask)
R1 Routing Table
Subnet
172.16.1.0

Interface
Serial 0/0

Next Hop
100.10.10.2

5. R1 finds that subnet 172.16.1.0 is reachable out Serial 0/0 and next hop router is R2 with
interface IP 100.10.10.2.
6. Because next hop R2 is on a Serial interface R1 encapsulates the IP packet in a new HDLC
frame with new destination and source MAC and send out interface Serial 0/0.

R1s HDLC Frame

HDLC

Destination MAC
C:C:C:C:C:C

Source MAC
B:B:B:B:B:B

IP Packet
(Src
IP:192.168.1.1
Dst IP:
172.16.1.1)

FCS

R2:
1. R2 repeats the same process as R1, receives the HDLC frame, processes it and checks for
FCS errors and removes the HDLC header.
2. R2 finds out that the subnet 172.16.1.0 is reachable out Fast Ethernet 0/1 and next hop
router is R3 with interface IP 200.10.10.2.
R1 Routing Table
Subnet
172.16.1.0

Interface
Fast Ethernet 0/1

Next Hop
200.10.10.2

3. Encapsulates the packet into new Ethernet Header and forwards it out interface Fa0/1.
R2s Ethernet Frame
Ethernet

Destination MAC
D:D:D:D:D:D

Source MAC
C:C:C:C:C:C

IP Packet
(Src
IP:192.168.1.1

FCS

Dst IP:
172.16.1.1)
R3:
1. R3 repeats the same process as R2, receives the Ethernet frame, checks for errors and
discards the old data link header and trailer.
2. R3 consults its routing table and finds out that the subnet 172.16.1.0 is reachable at FaE0/1
and is directly connected, therefore there is no next hop indicated.
R3s Routing Table
Subnet
172.16.1.0

Interface
Fast Ethernet 0/1

Next Hop
N/A

3. R3 encapsulated the packet inside a new Ethernet header and trailer and forwards it to
Server using Servers MAC address. If R3 didnt had the MAC of Server, it would have used
ARP to get it.
R3s Ethernet Frame
Ethernet

Destination MAC
E:E:E:E:E:E

Source MAC
D:D:D:D:D:D

IP Packet
(Src
IP:192.168.1.1
Dst IP:
172.16.1.1)

FCS

Notes:

The Destination and Source IP addresses remained same throughout the communication, but the
Source and Destination MACs kept changing at every hop or whenever they had to leave a LAN.
Every type of Data Link protocol used its own MAC header and trailer at every hop.
If MAC of a device was unknown at any point, ARP was used to get it.
LAN communication was based upon MAC Addresses and WAN communication was based upon IP,
although both (MAC, IP) were used in both (LAN, WAN) cases.

PART 2
LAN SWITCHING

LAN SWITCHING
PART A

CONCEPTS

Switching Logic
As described above a switch has following main functions:
1- Creating MAC Address Table.
2- Forwarding and Filtering Frames.

3- Creating loop-free environment.

Switches use Layer 2 logic, examining the Ethernet data link header to choose how to process frames. In
particular, switches make decisions to forward and filter frames, learn MAC addresses, and use STP to avoid
loops, as follows:
1. Switches Forward frames based on the destination address:
A- If the destination address is a broadcast, multicast, or unknown destination unicast (a
unicast not listed in the MAC table), the switch floods the frame.
B- If the destination address is a known unicast address (a unicast address found in the MAC
table):
iIf the outgoing interface listed in the MAC address table is different from the
interface in which the frame was received, the switch forwards the frame out the
outgoing interface.
iiIf the outgoing interface is the same as the interface in which the frame was
received, the switch filters the frame, meaning that the switch simply ignores the
frame and does not forward it.
2. Switches use STP to prevent loops by causing some interfaces to block, meaning they do not
receive or send frames.
3. Learn MAC addresses as follows:

Learning MAC addresses and creating CAM table

Switches build MAC address table based on SOURCE MAC address of incoming frame.
MAC address table is stored in RAM.

In the Diagrams above:

1- Four PCs are connected to the LAN switch SW1, show mac-address table command shows that
the switch has no idea yet what devices are connected and where are they located.
2- An ICMP echo Ping is issued from PC1 to PC4, Switch receives the incoming frame, checks CRC
and Source and Destination addresses.
3- Switch sees that the frame is coming from source MAC of 0000.aaaa.0001 and that this source
MAC is located at f0/1, switch makes the first entry in the CAM table indicating PC1s MAC and its
location.
4- At start, switch has no idea where the destination address of 0000.aaaa.0004 (PC4) is located so
it Floods the frame to all ports except the port it was received on.

5- PC2 and PC3 drop the frames seeing that its not destined to them, PC4 receives the frame and
sends the echo reply.
6- Switch sees that the ICMP echo reply came from source of 0000.aaaa.0004 that is located at f0/4
and makes the second entry in its CAM table.
Inactivity Timer:

For every MAC address entry in the CAM table the switch keep and inactivity timer which
defaults to 300 seconds or 5 minutes and is set to 0 for new learned MAC.
The timer counts upward from 0 to 300 and is reset to 0 each time a switch receives a frame
with same MAC address.
The entries reaching 300 seconds limit are removed from table to make room for the new
ones.

Forwarding and Filtering Decisions

With CAM table fully populated indicating all devices, if PC1 sends a frame to PC3 the switch would
not Flood the frame it would send the frame as a Unicast out interface fa0/3 that indicates the
location of PC3, hence making a forwarding decision.
Switch would not send the frame to fa0/2 and fa0/4, hence making a filtering decision.

Flooding:

In switch forwarding logic, the switches Flood the copies of Broadcast and Unknown Unicast
frames out all interfaces except the interface it was received on.
Switches also Flood the Multicasts by default, although this behavior can be changed.

Benefits of a Switch

Switch ports connected to a single device micro-segment the LAN, providing dedicated bandwidth
to that single device.
Switches allow multiple simultaneous conversations between devices on different ports.
Switch ports connected to a single device support full-duplex, in effect doubling the amount of
bandwidth available to the device.
Switches support rate adaptation, which means that devices that use different Ethernet speeds can
communicate through the switch (hubs cannot).

Switch Forwarding Methods

Store-and-forward:

The switch fully receives all bits in the frame (store) before forwarding the frame, this allows switch
to check the FCS before forwarding the frame.
This may seem to increase latency as compared to other two methods but with faster ASICs, 100
Mbps desktops and 1 Gbps uplinks it is negligible.
Almost all the modern switches now a days use this method.

Cut-through:

The switch forwards frame as soon as it can.

This reduces latency but does not allow the switch to discard frames that fail to pass FCS check

Fragment-free:

The switch forwards frame after receiving the first 64 bytes of the frame.
Ethernet CSMA/CD logic is that the collision should be detected within the first 64 bytes of the frame.
So, fragment-free method avoids forwarding the frames that were erred or corrupted by a collision.

Broadcast and Collision Domains

Broadcast Domain is a set of interfaces for which a Broadcast Frame sent by one interface is
received by all the interfaces in the same Broadcast Domain.
Collision Domain is a set of interfaces for which a frame sent by one interface could collide with a
frame sent by any other interface in the same Collision Domain.
By default, Routers break Broadcast Domains and Switches break Collision Domains.
Every interface of a Router is a separate Broadcast Domain and every interface of Switch is a
separate Collision Domain.
All interfaces of a Switch are in same Broadcast domain if no VLAN has been configured, and all
ports of a Hub are always in same Collision and Broadcast Domain in any case.
In a single Collision Domain, devices share the available bandwidth and also do not make efficient
use of bandwidth because of collisions.

Benefits of Segmenting Devices

Half
Duplex and Full Duplex

Half-Duplex: Logic in which a port sends data only when it is not also receiving data in other words, it
cannot send and receive at the same time.
The half-duplex logic uses CSMA/CD algorithm that works as follows:
1- A device with a frame to send listens until the Ethernet is not busy.
2- When the Ethernet is not busy, the sender begins sending the frame.
3- The sender listens for collision while sending the frame, if collision occurs, all currently
sending nodes do the following:
A- They send a jamming signal that tells all the nodes that a collision has occurred.
B- They independently choose a random time to wait before trying again, to avoid
unfortunate timing.
C- The next attempt starts again at Step 1.
Full-Duplex: The absence of the half-duplex restriction, ability to send and receive data at the same
time.

Auto-negotiation, Duplex and Speed Mismatch

Auto-negotiation:
Auto-negotiation is an IEEE standard mechanism (802.3u) with which two nodes can exchange messages
for the purpose of choosing to use the same Ethernet standards on both ends of the link, ensuring that the
link functions and functions well.
Ethernet devices on the ends of a link must use the same standard or they cannot correctly send
data.
A NIC cannot use 100BASE-T, which uses a two-pair UTP cable with a 100-Mbps speed, while the
switch port on the other end of the link uses 1000BASE-T.
Even if you used a cable that works with Gigabit Ethernet, the link would not work with one end
trying to send at 100 Mbps while the other tried to receive the data at 1000 Mbps.
Auto-negotiation solves this problem, IEEE standard 802.3u defines a protocol that lets the two UTPbased Ethernet nodes on a link negotiate so that they each choose to use the same speed and
duplex settings.
The protocol messages flow outside the normal Ethernet electrical frequencies as out-of-band signals
over the UTP cable.
Each node states what it can do, and then each node picks the best options that both nodes support:
the fastest speed and the best duplex setting, with full-duplex being better than half-duplex.
Auto-negotiation relies on the fact that the IEEE uses the same wiring pin-outs for 10BASE-T and
100BASET, and that 1000BASE-T simply adds to those pin-outs, adding two pair.

IEEE Rules when auto-negotiation fails:

Speed: Use your slowest speed supports (often 10 Mbps).
Duplex: If your speed = 10/100, use half-duplex; otherwise, use full-duplex.

Cisco Rules when auto-negotiation fails:

Speed: Sense the speed (Cisco switches can sense the speed used by the other node, even without IEEE
auto-negotiation) and adjust accordingly, if that fails, use IEEE default (slowest speed supports often 10
Mbps).
Duplex: Use IEEE defaults, if your speed = 10/100, use half-duplex; otherwise, use full-duplex.

Auto-negotiation Enabled on both sides

PC1: Switch port claims maximum 1000 Mbps, PC1s
max. is 10. Both choose best speed both support (10)
and best duplex (full).
PC2: PC2 claims max. 100, so they use 100 full.
PC3: both support all three 10/100/1000, so the result
is; 1000 full.

Auto-negotiation Disabled on one side

PC1: Switch receives no auto-negotiation messages,
senses that PC1 is sending data at 100 and uses IEEE
default. Result: 100 half. Duplex Mismatch.
PC2: Switch senses speed of 1000. Result 1000 full.
PC3: User picks speed of 10 and half duplex. Switch
senses speed and Result: 10 half.

Auto-negotiation and LAN Hubs:

Hubs do no react to auto-negotiation messages and do not forward them.

Devices attached to Hubs must use IEEE rules while choosing default settings, which often result in
10 Mbps Half-duplex.

Virtual LANs
A LAN includes all the user devices, servers, switches, routers, cables, and wireless access points in one
location in other words: A LAN includes all devices in the same broadcast domain.
Without VLANs, a switch considers all its interfaces to be in the same broadcast domain.

A switch can configure some interfaces into one broadcast domain and some into another, creating
multiple broadcast domains. These individual broadcast domains created by the switch are called
virtual LANs (VLAN).
From IP addressing perspective, every VLAN is a separate Subnet, so a Router is needed for
communication between different VLANs.

Reasons of implementing VLANs:

Group users by departmental instead of physical location.

Reduce CPU overhead on each device by reducing the number of devices that receive each
broadcast frame.

Reduce security risks by reducing the number of hosts that receive copies of frames that the
switches flood (broadcasts, multicasts, and unknown unicasts).
Improve security for hosts that send sensitive data by keeping those hosts on a separate VLAN.
Create more flexible designs that group users by department, or by groups that work together,
instead of by physical location.
Solve problems more quickly, because the failure domain for many problems is the same set of
devices as those in the same broadcast domain.
Reduce the workload for the Spanning Tree Protocol (STP) by limiting a VLAN to a single access
switch.
Separate IP voice traffic from data traffic.

Benefits of using VLANs:

Security: Sensitive data can be isolated to one VLAN, separating it from the rest of the network.
Cost Reduction: Cost savings result from less need for expensive network upgrades and more
efficient use of existing bandwidth and uplinks.
Higher Performance: Dividing flat Layer 2 networks into multiple logical broadcast domains reduces
unnecessary traffic on the network and boosts performance.
Broadcast Storm Mitigation: VLAN segmentation prevents a broadcast storm from propagating
throughout the entire network.
Ease of Management and Troubleshooting: A hierarchical addressing scheme groups network
addresses contiguously and makes problem components easier to locate making management and
troubleshooting more efficient.

Trunking:

When using VLANs in networks that have multiple interconnected switches, the switches need to use
VLAN trunking on the links between the switches.
VLAN Trunks allow hosts on different switches to share the same VLAN.
VLAN trunking causes the switches to use a process called VLAN tagging, by which the sending
switch adds another header to the frame before sending it over the trunk.
When trunking, Switches add an extra header to the Ethernet frame that includes a VLAN identifier
(VLAN ID) field so that the sending switch can associate the frame with a particular VLAN ID, and the
receiving switch can then know in what VLAN each frame belongs.
The switches treat the trunk link as a part of all the VLANs that allows switches to pass frames from
multiple VLANs over a single physical connection.
The trunk keeps the VLAN traffic separate because each frame is identified by VLAN number as it
crosses the trunk.

The 802.1Q and ISL VLAN Trunking Protocols

Cisco has supported two different trunking protocols over the years: Inter-Switch Link (ISL) created
by Cisco and IEEE 802.1Q. Today, 802.1Q has become the more popular trunking protocol, with Cisco
not even supporting ISL in some of its newer models of LAN switches.
While both ISL and 802.1Q tag each frame with the VLAN ID, the details differ. 802.1Q inserts an
extra 4-byte 802.1Q VLAN header into the original frames Ethernet header.

As for the fields

in the 802.1Q header,
only the 12-bit
VLAN ID field inside
the 802.1Q
header matters. This
12-bit field
supports a theoretical
maximum of 212
(4096) VLANs, while
in practice, it
supports a maximum
of 4094.
Both 802.1Q and ISL use 12 bits to tag the VLAN ID, with two reserved values [0 and 4095].
Cisco switches break the range of VLAN IDs (14094) into two ranges: the normal range and the
extended range.
All switches can use normal-range VLANs with values from 1 to 1005. Only some switches can use
extended-range VLANs with VLAN IDs from 1005 to 4094.
The rules for which switches can use extended-range VLANs depend on the configuration of the
VLAN Trunking Protocol (VTP)

Types of VLANs

Data VLAN: Configured to carry only user-generated traffic, ensuring that voice and management
traffic is separated from data traffic.
Default VLAN: All the ports on a switch are members of the default VLAN when the switch is reset
to factory defaults. The default VLAN for Cisco switches is VLAN 1. VLAN 1 has all the features of any
VLAN, except that you cannot rename it and you cannot delete it. It is a security best practice to
restrict VLAN 1 to serve as a conduit only for Layer 2 control traffic (for example, CDP or VTP),
supporting no other traffic.
Black hole VLAN: A security best practice is to define a black hole VLAN to be a dummy VLAN
distinct from all other VLANs defined in the switched LAN. All unused switch ports are assigned to
the black hole VLAN so that any unauthorized device connecting to an unused switch port will be
prevented from communicating beyond the switch to which it is connected.
Native VLAN: 802.1Q also defines one special VLAN ID on each trunk as the native VLAN
(defaulting to use VLAN 1).
802.1Q simply does not add an 802.1Q header to frames in the native VLAN, when the switch
on the other side of the trunk receives a frame that does not have an 802.1Q header, the
receiving switch knows that the frame is part of the native VLAN.
Because of this behavior, both switches must agree on which VLAN is the native VLAN.
The 802.1Q native VLAN provides support connections to devices that do not understand
trunking.
A Cisco switch could be cabled to a switch that does not understand 802.1Q trunking. The
Cisco switch could send frames in the native VLANmeaning that the frame has no trunking
headerso that the other switch would understand the frame.
The native VLAN concept gives switches the capability of at least passing traffic in one VLAN
(the native VLAN), which can allow some basic functions, like reachability to telnet into a
switch.
A security best practice is to define a native VLAN to be a dummy VLAN distinct from all other
VLANs defined in the switched LAN.
The native VLAN is not used for any traffic in the switched network unless legacy bridging
devices happen to be present in the network, or a multi-access interconnection exists
between switches joined by a hub.
Management VLAN: A VLAN defined by the network administrator as a means to access the
management capabilities of a switch.
By default, VLAN 1 is the management VLAN.

It is a security best practice to define the management VLAN to be a VLAN distinct from all
other VLANs defined in the switched LAN. You do so by configuring and activating a new
VLAN interface.
Voice VLANs: The voice VLAN feature enables switch ports to carry IP voice traffic from an IP
phone.
The network administrator configures a voice VLAN and assigns it to access ports. Then when
an IP phone is connected to the switch port, the switch sends CDP messages that instruct the
attached IP phone to send voice traffic tagged with the voice VLAN ID.

Inter-VLAN Routing

One goal of VLANs is to separate traffic in one VLAN from another, preventing frames in one VLAN
from leaking over to other VLANs. So, Layer 2 switches will not forward data between two VLANs.
The job of forwarding data into and out of a VLAN falls to routers. Instead of switching Layer 2
Ethernet frames between the two VLANs, the network must route Layer 3 packets between the two
subnets.
Every VLAN is a different broadcast domain or a different Subnet thats why a Router is needed for
inter-VLAN communications.

VLAN Trunking Protocol

VTP is a Cisco-proprietary tool on Cisco switches that advertises each VLAN configured in one switch so that
all the other switches in the campus learn about that VLAN.

VTP Modes:

VTP operates in one of three modes:

Server: The server is where VLANs can be created, deleted, or renamed for the domain. VTP
servers advertise VLAN information to other switches in the same VTP domain and store the
VLAN information in NVRAM.
Client: You cannot create, change, or delete VLANs on a VTP client. A switch reset deletes
the VLAN information. You must configure a switch to change its VTP mode to client.
Transparent: VTP transparent mode switches forward VTP advertisements to VTP clients and
VTP servers, but do not originate or otherwise implement VTP advertisements. VLANs that are
created, renamed, or deleted on a VTP transparent mode switch are local to that switch only.

VTP Operation:
VTP advertisements are sent by the server every 5 minutes over the default VLAN using a multicast frame.
A configuration revision number included in the frame is used by all VTP clients and servers to determine if
there has been a change in the VLAN database. Figure 24-5 illustrates VTP operation.

Figure begins with all switches having the same VLAN configuration revision number, meaning that they
have the same VLAN configuration database; this means that all switches know about the same VLAN
numbers and VLAN names. The process begins with each switch knowing that the current configuration
revision number is 3.
The steps shown in Figure are as follows:
1. Someone configures a new VLAN on the VTP server.
2. The VTP server updates its VLAN database revision number from 3 to 4.
3. The server sends VTP update messages out its trunk interfaces, stating revision number 4.
4. The two VTP client switches notice that the updates list a higher revision number (4) than their
current revision numbers (3).
5. The two client switches update their VLAN databases based on the servers VTP updates.
VTP defines three types of messages:
Summary advertisement: Sent every 5 minutes by the server; it lists the revision number,
domain name, and other information, but no VLAN information.
Subset advertisement: Follows a summary advertisement if something has changed in the
VLAN database, indicated by a new larger revision number.
Advertisement request message: Allows a switch to immediately request VTP messages
from a neighboring switch as soon as a trunk comes up.

VTP Pruning:

By default, a trunk connection carries traffic for all VLANs in the VTP management domain; however,
every switch might not have ports assigned to every VLAN. VTP pruning uses VLAN advertisements
to determine when a trunk connection is flooding VLAN traffic needlessly.
Pruning means that the appropriate switch trunk interfaces do not flood frames in that VLAN.

Each switch can use one of three VTP modes: server, client, or transparent. Switches use either VTP
server or client mode when the switch wants to use VTP for its intended purpose of dynamically
advertising VLAN configuration information.
With many Cisco switches and IOS versions, VTP cannot be completely disabled on a Cisco switch;
instead, the switch disables VTP by using VTP transparent mode.
The server switches can configure VLANs in the standard range only (11005).
The client switches cannot configure VLANs.

Trunk Negotiation and DTP:

Trunking configuration on Cisco switches includes many more options, including several options for
dynamically negotiating various trunking settings.
The configuration can either predefine different settings or tell the switch to negotiate the settings,
as follows:
The type of trunking: IEEE 802.1Q, ISL, or negotiate which one to use
The administrative mode: Whether to always trunk, always not trunk, or negotiate
First, consider the type of trunking. Cisco switches that support ISL and 802.1Q can negotiate which
type to use, using the Dynamic Trunking Protocol (DTP).
If both switches support both protocols, they use ISL; otherwise, they use the protocol that both
support.
DTP can also negotiate whether the two devices on the link agree to trunk at all, as guided by the
local switch ports administrative mode.
The administrative mode refers to the configuration setting for whether trunking should be used.
Each interface also has an operational mode, which refers to what is currently happening on the
interface, and might have been chosen by DTPs negotiation with the other device.

Spanning

Tree
Protocol
No Spanning Tree Scenario
How an infinite Loop occurs

In this scenario Spanning Tree

Protocol is not enabled.

As it is already mentioned that the switches flood the unknown unicast frames to all ports except the port it
was received on.
PC1 is trying to send a frame down to PC2:
1- Frame reaches SW1, and SW1 says that now I know where PC1 is but I dont know where the PC2 is
so Im going to Flood the frame out Fa0/2 and Fa0/3.
2- Frame is received by SW2 and SW3 on their ports Fa0/1 and they conclude that PC1 located on their
port Fa0/1 but still both dont know where PC2 is so they too Flood the frame out their Fa0/2.
3- Now the Frame reaches to SW4 from SW2 and SW3s Fa0/2 and one of these two frames must have
reached before the other in some finite time. Whichever arrives first on Fa0/2 or Fa0/3 of SW4 is
going to be added as the source of PC1.
4- Lets assume that Fa0/2 receives the frame first. Initially, the SW4 is going to add in the CAM table
that PC1 is located at its Fa0/2. But as the frame from SW3 is received at Fa0/3 it is immediately

overwritten that PC1 is located at Fa0/3 not Fa0/2. Now at this point SW4 says that PC1 is located
Fa0/3s direction.
5- But SW4 and all the switches still dont know where the destination PC2 is. So SW4 is going to Flood
the frame all the ports except the port it was received on and its counting Fa0/3 as the port where
the frame was received. As a result SW4 Floods the frame out Fa0/2 and Fa0/1.
6- Here the Loop occurs, SW4 forwards the frame to the destination at Fa0/1 and also to SW2s Fa0/2.
SW2 concludes that it needs to update the CAM table as the PC1 is now located at Fa0/2 and not
Fa0/1 as it previously noted. SW2 continues to Flood the frame as it doesnt know the destination
and all the receiving switches also continue to Flood the frame and it keeps looping around.

Spanning Tree Protocol solves these types of looping problems in redundant links. With STP enabled
some switches block ports so that these ports do not forward the frames.
Switch intelligently chooses which ports to block with two goals in mind:
1. All devices in the VLAN can send traffic to other all devices, STP does not cut traffic to any
device.
2. Frames have a shorter life and does not loop around indefinitely.
Spanning Tree Protocol (STP) prevents looping traffic in a redundant switched network by blocking
traffic on the redundant links. If the main link goes down, Spanning Tree activates the standby path.
STP operation is transparent to end stations. Switches use the IEEE 802.1d STP by default.
STP prevents loops by placing each switch port in either a forwarding state or a blocking state.
Interfaces in the forwarding state act as normal, forwarding and receiving frames.
Interfaces in a blocking state do not process any frames except STP messages and some other
overhead messages.
Interfaces that block do not forward user frames, do not learn MAC addresses of received frames,
and do not process received user frames.

Spanning Tree Operations

The process used by STP, sometimes called the spanning-tree algorithm (STA), chooses the
interfaces that should be placed into a forwarding state. For any interfaces not chosen to be in a
forwarding state, STP places the interfaces in blocking state.
All devices agree on a reference point in the network called the root bridge.
Devices directly downstream of the root bridge perform the following:
Everyone selects single link that is facing upstream towards the root bridge to forward
traffic toward the root bridge, these ports are called the root port.
All other upstream ports are disabled called blocking ports.
All downstream facing ports are called designated ports.
Next downstream device performs the same, selecting one upstream facing root port

STP uses three criteria to choose whether to put an interface in forwarding state:

1. STP elects a root switch. STP puts all working interfaces on the root switch in forwarding state.
2. Each non-root switch considers one of its ports to have the least administrative cost between itself
and the root switch. The cost is called that switchs root cost. STP places its port that is part of the
least root cost path, called that switchs root port (RP), in forwarding state.
3. The switch with the lowest root cost, as compared with the other switches attached to the same link,
is placed in forwarding state. That switch is the designated switch, and that switchs interface,
attached to that segment, is called the designated port (DP).
4. All other interfaces are put into blocking state.

STP works following these steps:

1234-

Exchange Bridge and link attributes.

Elect one Root Bridge.
Elect one Root Port per bridge.
Elect Designated Ports.

Step 1- Exchange Bridge and link attributes:

STP Advertisements are as follows:

STP defines messages called bridge protocol data units (BPDU), which switches use to exchange
information with each other.
BPDUs are used to exchange BID and other attributes its simply a spanning tree packet or
advertisement.
BPDUs are different on a per port basis because they carry different attributes per link.
BPDUs are sent as multicast frames between adjacent switches.
During initial convergence everyone generates its own BPDU everyone claiming to be Root Bridge.
The most common BPDU, called a hello BPDU, lists many details, including the sending switchs BID.
By listing its own unique BID, switches can tell which switch sent which hello BPDU.

Step 2- Root Bridge Election:

Root Bridge election is based on the lowest Bridge ID in the network.

The STP Bridge ID (BID) is an 8-byte value unique to each switch.
BID consists of a 2-byte Bridge Priority that ranges from 0-65535 and defaults to 32768 where 0 is
highest priority (lower is better) and a 6-byte system ID.
The system ID is based on a universal (burned-in) MAC address in each switch it ensures that each
switchs bridge ID will be unique.
The new standard splits Bridge Priority into two fields i.e. Bridge priority and System ID Extension.
System ID Extension is a 12 bit numerical number ranging 1 4094
System ID Extension the VLAN number so when using multiple instances of spanning tree on per
VLAN basis the System ID Extension keeps those instances unique.

So BID = Priority + System ID Extension (VLAN#) and MAC Address.

In Root election, first of all lowest Bridge Priority is taken if there is a tie in priority the lowest MAC is
taken.
Lowest BID in the network becomes everyones Root ID (RID) in their advertised BPDUs.
Root bridge has no root port all of its ports are designated ports.

Step 3- Root Port Election:

A switchs Root Port is its interface through which it has the least root cost i.e. least STP cost to
reach the root switch.

Each non-root switch chooses its one and only root port.
Root Port is always upstream facing interface towards the Root and non-root ports are downstream
facing interface.

If there is a tie in the cost:

Choose upstream device with lowest BID.
(if BID also tie) Choose upstream device with lowest Port ID.

Step 4- Designated Port Election:

The designated port (DP) on each LAN segment is the switch port that advertises the lowest-cost
hello onto a LAN segment.
When a non-root switch forwards a hello, the non-root switch sets the root cost field in the hello to
that switchs cost to reach the root. In effect, the switch with the lower cost to reach the root, among
all switches connected to a segment, becomes the DP on that segment.
DPs are downstream facing away from Root Bridge.
Like Root Port, its elected based on lowest Root Path Cost or lowest BID or lowest Port ID.

STP Path Selection Example

Root Port Selection:

SW1:

Root Bridge has no Root ports.

SW2:

Every non Root switch has to select a Root port, SW2 has to choose either Fa0/13 or Fa0/19 as its
Root port. This decision is going to be based on the lowest cost value to reach the Root.
SW2 has either cost of 10 from Fa0/13 or it has port cost of 10+10+10=30 from Fa0/19. SW2
chooses the lower cost and Fa0/13 is the Root Port.

SW3:

Follows the same logic as SW2 and chooses Fa0/13 as the Root Port.

SW4:

From SW4 has to choose Fa0/16 or Fa0/19, both have same port cost of 20 to reach the Root. From
SW4s perspective we have a tie.

In this case of tie, SW4 is going to go for the lower upstream BID, so it compares BID of SW2 and BID
of SW3.
SW2 has lower BID so from SW4s perspective Fa0/16 is going to be the Root Port.

Designated and Blocking Port Selection:

SW1:

Both ports Fa0/13 and Fa0/16 on SW1 are going to be designated ports and are in forwarding state
because it is itself the Root and cost to reach itself for all its ports is 0.
Ports Fa0/13 and Fa0/16 are downward facing away from Root, so they are designated.

SW2:

Fa0/19 is going to be the designated port because at the opposite of a RP is always a DP, as Fa0/19
is at the opposite of RP of SW4.
Root port is facing upstream DP is facing downstream.

SW3:

Now there is competition between Fa0/19 of SW3 and Fa0/19 of SW4, SW3 has a cost of 10 and SW4
has a cost of 20 to the Root so SW3s Fa0/19 is the designated port.

SW4:

The remaining port Fa0/19 of SW4 would be the blocking port.

STP Timers

The root switch sends a new hello BPDU every 2 seconds by default.
Each non-root switch forwards the hello on all DPs, but only after changing items listed in the hello,
the switch sets the root cost to that local switchs calculated root cost.
The switch also sets the senders bridge ID field to its own bridge ID. (The roots bridge ID field is
not changed.)
By forwarding the received (and changed) hellos out all DPs, all switches continue to receive hellos
every 2 seconds.
The following steps summarize the steady-state operation when nothing is currently changing in the
STP topology:

Step 1. The root creates and sends a hello BPDU, with a root cost of 0, out all its working
interfaces (those in a forwarding state).

Step 2. The non-root switches receive the hello on their root ports. After changing the hello
to list their own BID as the senders BID, and listing that switchs root cost, the switch
forwards the hello out all designated ports.
Step 3. Steps 1 and 2 repeat until something changes.
Each switch relies on these periodic received hellos from the root as a way to know that its path to
the root is still working.
When a switch ceases to receive the hellos, or receives a hello that lists different details, something
has failed, so the switch reacts and starts the process of changing the spanning-tree topology.

Timers
Timer

Description

Default
Value

Hello
Max Age

Time the Root takes to create Hello.

After ceasing to hear hellos, how long switch
should wait before trying to change STP topology.

2 seconds
20 seconds
(10 times
hello)

Forward
Delay

Delay when an interface changes from blocking to

forwarding. A port stays in an interim listening
state, and then an interim learning state, for the
number of seconds defined by forward delay timer.

15 seconds
(15 sec for
Listening and
15 sec for
Learning)

Total default time the Common STP takes to

converge from Blocking to forwarding.

50 seconds

STP Port States

STP moves an interface from blocking to listening, then to learning, and then to forwarding state.
STP leaves the interface in each interim state for a time equal to the forward delay timer, which
defaults to 15 seconds.
A convergence event that causes an interface to change from blocking to forwarding requires 30
seconds to transition from blocking to forwarding.
A switch might have to wait Max Age seconds before even choosing to move an interface from
blocking to forwarding state.
Listening:
Like the blocking state, the interface does not forward frames. The switch removes old stale
(unused) MAC table entries for which no frames are received from each MAC address during this
period. These stale MAC table entries could be the cause of the temporary loops.
Learning:

Interfaces in this state still do not forward frames, but the switch begins to learn the MAC addresses
of frames received on the interface.

Port Fast:

Port Fast allows a switch to immediately transition from blocking to forwarding, bypassing listening
and learning states.
The only ports on which you can safely enable Port Fast are ports on which you know that no
bridges, switches, or other STP-speaking devices are connected. Otherwise, using Port Fast risks
creating loops.
Port Fast is most appropriate for connections to end-user devices. If you turn on Port Fast on ports
connected to end-user devices, when an end-user PC boots, the switch port can move to an STP
forwarding state and forward traffic as soon as the PC NIC is active.
Without Port Fast, each port must wait while the switch confirms that the port is a DP, and then wait
while the interface sits in the temporary listening and learning states before settling into the
forwarding state.

BPDU Guard:

STP opens up the LAN to several different types of possible security exposures. For example:
An attacker could connect a switch to one of these ports, one with a low STP priority value,
and become the root switch. The new STP topology could have worse performance than the
desired topology.
The attacker could plug into multiple ports, into multiple switches, become root, and actually
forward much of the traffic in the LAN. Without the networking staff realizing it, the attacker
could use a LAN analyzer to copy large numbers of data frames sent through the LAN.
Users could innocently harm the LAN when they buy and connect an inexpensive consumer
LAN switch (one that does not use STP). Such a switch, without any STP function, would not
choose to block any ports and would likely cause a loop.
The Cisco BPDU Guard feature helps defeat these kinds of problems by disabling a port if any BPDUs
are received on the port.
BPDU Guard is particularly useful on ports that should be used only as an access port and never
connected to another switch.
BPDU Guard helps prevent problems with Port Fast. Port Fast should be enabled only on access ports
that connect to user devices, not to other LAN switches.

Rapid STP Concepts and Operations

IEEE improved the convergence performance of STP from 50 seconds to less than 10 seconds with
its definition of Rapid STP (RSTP) in the standard 802.1w.
RSTP is identical to STP in the following ways:
It elects the root switch using the same parameters and tiebreakers.

It elects the root port on non-root switches with the same rules.
It elects designated ports on each LAN segment with the same rules.
It places each port in either Forwarding or Blocking State, although RSTP calls the Blocking
State the Discarding State.
The main changes with RSTP can be seen when changes occur in the network. RSTP acts differently
on some interfaces based on what is connected to the interface.

Edge-Type Behavior and Port Fast: RSTP improves convergence for edge-type connections by
immediately placing the port in Forwarding State when the link is physically active.
Link-Type Shared: RSTP doesnt do anything differently from STP on link-type shared links.
However, because most of the links between switches today are not shared, but are typically fullduplex point-to-point links, it doesnt matter.
Link-Type Point-to-Point: RSTP improves convergence over full-duplex links between switches.
RSTP recognizes the loss of the path to the root bridge, through the root port, in 3 times the Hello
timer, or 6 seconds with a default Hello timer value of 2 seconds. So RSTP recognizes a lost path to
the root much more quickly.

RSTP removes the need for Listening State and reduces the time required for Learning State by
actively discovering the networks new state.
STP passively waits on new BPDUs and reacts to them during the Listening and Learning States. With
RSTP, the switches negotiate with neighboring switches by sending RSTP messages.
The messages enable the switches to quickly determine whether an interface can be immediately
transitioned to a Forwarding State. In many cases, the process takes only a second or two for the
entire RSTP domain.
RSTP also adds three more port roles to the root port and designated port roles defined in STP.

PVST+, PVRST, and MIST

802.1d does not support a spanning-tree instance for each VLAN because VLANs did not exist when
the standard was first introduced.

Cisco switches include a proprietary feature called Per-VLAN Spanning Tree Plus (PVST), which
creates a separate instance of STP for each VLAN.
Again, when IEEE introduced 802.1w, there still was no support for multiple instances of STP. So
Cisco implemented another proprietary solution called either Rapid Per-VLAN Spanning Tree
(RPVST) or Per-VLAN Rapid Spanning Tree (PVRST). Later, IEEE created the 802.1s standard called
Multiple Instances of Spanning Tree (MIST).

EtherChannel:

One of the best ways to lower STPs convergence time is to avoid convergence altogether.
EtherChannel provides a way to prevent STP convergence from being needed when only a single
port or cable failure occurs.
EtherChannel combines multiple parallel segments of equal speed (up to eight) between the same
pair of switches, bundled into an EtherChannel.
The switches treat the EtherChannel as a single interface with regard to STP. As a result, if one of the
links fails, but at least one of the links is up, STP convergence does not have to occur.
With each pair of Ethernet links configured as an EtherChannel, STP treats each EtherChannel as a
single link.
Both links to the same switch must fail for a switch to need to cause STP convergence.
Without EtherChannel, if you have multiple parallel links between two switches, STP blocks all the
links except one.
With EtherChannel, all the parallel links can be up and working at the same time, while reducing the
number of times STP must converge, which in turn makes the network more available.
When a switch makes a forwarding decision to send a frame out an EtherChannel, the switch then
has to take an extra step in logic: Out which physical interface does it send the frame?
The switches have load-balancing logic that let it pick an interface for each frame, with a goal of
spreading the traffic load across all active links in the channel.
LAN design that uses EtherChannels makes much better use of the available bandwidth between
switches, while also reducing the number of times that STP must converge.

Dynamic

EtherChannel:

Cisco switches support two different protocols that allow the switches to negotiate whether a
particular link becomes part of an EtherChannel or not.

The configuration enables the protocol for a particular channel-group number. The switch can use
the protocol to send messages to/from the neighboring switch and discover whether their
configuration settings pass all checks.
If a given physical link passes, the link is added to the EtherChannel and used; if not, it is placed in a
down state, and not used, until the configuration inconsistency can be resolved.
Cisco switches support the Cisco proprietary Port Aggregation Protocol (PAgP) and the IEEE
standard Link Aggregation Control Protocol (LACP), based on IEEE standard 802.3ad.
They both accomplish the same task: negotiate so that only links that pass the configuration checks
are actually used in an EtherChannel.
To configure either protocol, a switch uses the channel-group configuration commands on each
switch, but with a keyword that either means use this protocol and begin negotiations or use this
protocol and wait for the other switch to begin negotiations.
The desirable and auto keywords enable PAgP.
The active and passive keywords enable LACP.
With these options, at least one side has to begin the negotiations i.e. with PAgP, at least one of the
two sides must use desirable, and with LACP, at least one of the two sides must use active.
Do not use the on parameter on one end, and either auto or desirable (or for LACP, active or
passive) on the neighboring switch.
The on option uses neither PAgP nor LACP, so a configuration that uses on, with PAgP or LACP
options on the other end, would prevent the EtherChannel from working.

LAN SWITCHING
PART B

CONFIGURATIONS

Operating and Navigating Cisco IOS

Switch Status from LEDs:
Off: Switch not powered on.
On (green): Switch powered on and operational (IOS loaded).
On (amber): System has power but not is not functioning properly.

Port Status from LEDs:

Off: Link is not working including shutdown.
Solid Green: Link is working, but no current traffic.
Flashing Green: Link is working, traffic is passing.
Flashing Amber: Port blocked by spanning tree.

Terminal Emulator Setting:

9600 bits/second
No hardware flow control
8-bit ASCII
No parity bits
1 stop bit

Connecting to a Cisco Device:

Ways to configure Cisco devices are as follows:

Console terminal: Use an RJ-45 to RJ-45 rollover cable, RJ-45 to USB and a computer with the
terminal communications software (Hyper Terminal etc.) to establish a direct connection.
Remote terminal: Use an external modem connected to the auxiliary portrouters onlyto
remotely configure the device.
Establish a terminal (vty) session using Telnet.
Configure the device through the current connection (console or auxiliary), or download a
previously written startup-config file from a Trivial File Transfer Protocol (TFTP) server on the
network.
Download a configuration file using a network management software application such as
CiscoWorks.

Cisco Device Access Levels:

Cisco IOS separates the EXEC session into two basic access levels:
User EXEC mode: Access to only a limited number of basic monitoring and troubleshooting
commands, such as show and ping.
Privileged EXEC mode: Full access to all device commands, including configuration
mode and management.

IOS Examination Commands:

To verify and troubleshoot network operation, you use show commands. Figure below delineates the
different show commands, as follows:
If they are applicable to IOS (stored in RAM)
If they apply to the backup configuration file stored in NVRAM

If they apply to flash or specific interfaces

Storing, Copying Erasing Configurations:

The following list details the four main types of memory found in Cisco switches, as well as the most
common use of each type:
RAM: Sometimes called DRAM, for dynamic random-access memory, RAM is used by the
switch just as it is used by any other computer: for working storage. The running (active)
configuration file is stored here.
ROM: Read-only memory (ROM) stores a bootstrap (or boot helper) program that is loaded
when the switch first powers on. This bootstrap program then finds the full Cisco IOS image
and manages the process of loading Cisco IOS into RAM, at which point Cisco IOS takes over
operation of the switch.
Flash memory: Either a chip inside the switch or a removable memory card, flash memory
stores fully functional Cisco IOS images and is the default location where the switch gets its
Cisco IOS at boot time. Flash memory also can be used to store any other files, including
backup copies of configuration files.
NVRAM: Nonvolatile RAM (NVRAM) stores the initial or startup configuration file that is used
when the switch is first powered on and when the switch is reloaded.

Switch Base Configuration

1- Configure the Hostname
(config)#hostname

2- Configure the Message of the Day Banner

(config)#banner motd
3- Configure Privilege EXEC Mode (Enable mode) Password/Secret
(config)#enable password/secret
4- Configure Console
(config)#line console 0
(config-line)#password WORD
(config-line)#login
(config-line)#exec-timeout HRS MINS
(config-line)#logging synchronous
5- Configure Telnet
(config)#line vty 0 15
(config-line)#password WORD
(config-line)#login
(config-line)#exec-timeout HRS MINS
(config-line)#logging synchronous
6- Configure IP Address
(config)#interface vlan 1
(config-if)#ip address IP MASK
(config-if)#no shutdown
7- Configure Default Gateway
(config)#ip default-gateway IP
8- Configure SSH
(config)#line vty 0 15
(config-line)#login local
(config-line)#transport input telnet ssh
(config)#username WORD password WORD
(config)#ip domain name DOMAIN.COM
(config)#crypto key generate rsa
(config)#ip ssh version 2
9- Configure Speed and Duplex
(config)#interface fa0/1
(config-if)#duplex full/half/auto
(config-if)#speed 10/100/1000/auto
10- Configure Password Encryption
(config)#service password-encryption
11- Save Configuration
(config)#copy running-config startup-config

Troubleshooting Base Configuration

SW_LAB_1#show running-config
Current configuration : 2268 bytes
version 12.2

no service timestamps log datetime msec

no service timestamps debug datetime msec
service password-encryption
hostname SW_LAB_1
enable secret 5 $1$mERr$n6Uqzw24DKADA36Hi7KY.0
enable password 7 0822455D0A16
ip domain-name cisco.com
username ali privilege 1 password 7 0825455D0A16
spanning-tree mode pvst
interface FastEthernet0/1
duplex full
speed 100
interface FastEthernet0/24
duplex full
speed 100
interface GigabitEthernet1/1
interface GigabitEthernet1/2
interface Vlan1
ip address 192.168.1.10 255.255.255.0
ip default-gateway 192.168.1.1
banner motd ^C#################################################################
UNAUTHORISED ACCESS NOT PERMITTED!
#
############################################################## C
line con 0
password 7 0825455D0A16
logging synchronous
login
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password 7 0825455D0A16
logging synchronous
login local
line vty 5 15
exec-timeout 0 0
password 7 0825455D0A16
logging synchronous
login local
end

SW_LAB_1#show interfaces
FastEthernet0/1 is down, line protocol is down (disabled)
Hardware is Lance, address is 0003.e413.0e01 (bia 0003.e413.0e01)
BW 100000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:08, output 00:00:05, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:0
Queueing strategy: fifo
Output queue:0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
956 packets input, 193351 bytes, 0 no buffer
Received 956 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
2357 packets output, 263570 bytes, 0 underruns
0 output errors, 0 collisions, 10 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

SW_LAB_1#show crypto key mypubkey rsa

% Key pair was generated at: 0:19:15 UTC Mar 1 1993
Key name: SW_LAB_1.cisco.com.server
Usage: Encryption Key
Key is not exportable.
Key Data:
00001567 00000110 000045c7 000013b9 00007c0f 0000193b

0000191d

00004572

SW_LAB_1#show ip ssh
SSH Enabled - version 1.99
Authentication timeout: 120 secs; Authentication retries: 3

SW_LAB_1#show ssh
%No SSHv2 server connections running.
%No SSHv1 server connections running.

To erase contents of NVRAM use any of these three and issue #reload:
SW_LAB_1#erase nvram:
SW_LAB_1#erase startup-config
SW_LAB_1#write erase
IOS allows you to configure neither, one or the other, or even both of these commands. Then the
switch chooses what password to require of a user based on the following rules:
Both commands configured: Use the enable secret password command
Only one command configured: Use the password in that one command
Neither command configured (default): Console users are allowed into enable mode
without a password prompt, while others are rejected.

VLAN Configurations

All devices are in same Subnet, No VLAN is configured, every device is in default VLAN 1 and
everyone can access each other.

Although every device is in the same Subnet, but when we configure VLAN 10 and VLAN 20, layer 2
traffic is divided and segmented.
PCs in VLAN 10 cannot access SERVERs in VLAN 20 even they are in the same IP subnet.

To enable inter-VLAN communication, well have to assign different Subnets to different VLANs.
Now that every VLAN is a separate IP subnet, a layer 3 device is needed for inter-communication
between different networks.
A layer 3 Switch or a Router is used for this purpose, this Router is called Router-on-Stick.
Layer 2 Traffic is still separated in this scenario.

Configurations based of third scenario:

1- Create and Name the VLANs
Switch(config)#vlan 10
Switch(config-vlan)#name PC
Switch(config-vlan)#exit
Switch(config)#vlan 20
Switch(config-vlan)#name SERVER
Switch(config-vlan)#end
2- Assign port(s) to the VLANs
Switch(config)#interface range fastEthernet 0/10 - 11
Switch(config-if-range)#switchport access vlan 10
Switch(config-if-range)#exit
Switch(config)#interface range fastEthernet 0/20 - 21
Switch(config-if-range)#switchport access vlan 20
Switch(config-if-range)#end
3- Configure Trunk between Switch and the Router
Switch(config)#interface fastEthernet 0/1

Switch(config-if)#switchport mode trunk

4- Configure the Router as Router on Stick
Router(config)#interface fastEthernet 0/0.10
Router(config-subif)#encapsulation dot1Q 10
Router(config-subif)#ip address 192.168.10.1 255.255.255.0
Router(config-subif)#exit
Router(config)#interface fastEthernet 0/0.20
Router(config-subif)#encapsulation dot1Q 20
Router(config-subif)#ip address 192.168.20.1 255.255.255.0
Router(config-subif)#exit
Router(config)#interface fastEthernet 0/0
Router(config-if)#no shutdown
Router(config-if)#
%LINK-5-CHANGED: Interface FastEthernet0/0, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
%LINK-5-CHANGED: Interface FastEthernet0/0.10, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0.10, changed state to
up
%LINK-5-CHANGED: Interface FastEthernet0/0.20, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0.20, changed state to
up
5- On End Devices, configure RoS sub-interfaces as Gateway
PCs: IP 192.168.10.10, 192.168.10.11 Gateway 192.168.10.1
Servers: IP 192.168.20.20, 192.168.20.21 Gateway 192.168.20.1

Troubleshooting VLAN configurations

Ping from PC to Server:
PC>ping 192.168.20.20

Pinging 192.168.20.20 with 32 bytes of data:

Reply
Reply
Reply
Reply

from
from
from
from

192.168.20.20:
192.168.20.20:
192.168.20.20:
192.168.20.20:

bytes=32
bytes=32
bytes=32
bytes=32

time=0ms
time=0ms
time=1ms
time=0ms

TTL=127
TTL=127
TTL=127
TTL=127

Ping statistics for 192.168.20.20:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

Switch#show running-config

interface FastEthernet0/1
switchport mode trunk

!
interface FastEthernet0/10
switchport access vlan 10
!
interface FastEthernet0/11
switchport access vlan 10


!
interface FastEthernet0/20
switchport access vlan 20
!
interface FastEthernet0/21
switchport access vlan 20
!

Switch#show vlan brief

VLAN Name
Status
Ports
---- -------------------------------- --------- ------------------------------1
default
active
Fa0/2, Fa0/3, Fa0/4, Fa0/5
Fa0/6, Fa0/7, Fa0/8, Fa0/9
Fa0/12, Fa0/13, Fa0/14, Fa0/15
Fa0/16, Fa0/17, Fa0/18, Fa0/19
Fa0/22, Fa0/23, Fa0/24, Gig1/1
Gig1/2
10
PC
active
Fa0/10, Fa0/11
20
SERVER
active
Fa0/20, Fa0/21
1002 fddi-default
active
1003 token-ring-default
active
1004 fddinet-default
active
1005 trnet-default
active

Switch#show interfaces trunk

Port
Fa0/1

Mode
on

Encapsulation
802.1q

Status
trunking

Port
Fa0/1
Port
Fa0/1
Port
Fa0/1

Vlans allowed on trunk

1-1005
Vlans allowed and active in management domain
1,10,20
Vlans in spanning tree forwarding state and not pruned
1,10,20

Switch#show interfaces switchport

Native vlan
1

Name: Fa0/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: All
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none


Name: Fa0/10
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 10 (PC)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none

Switch#show mac-address-table

Mac Address Table

------------------------------------------Vlan
---1
10
10
10
20
20
20

Mac Address
-----------

Type
--------

Ports
-----

0003.e4d4.7701
0002.16e4.b9dd
0003.e4d4.7701
0090.0cba.14b5
0001.9699.8ce9
0003.e4d4.7701
00d0.bc46.37ab

DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC

Fa0/1
Fa0/11
Fa0/1
Fa0/10
Fa0/20
Fa0/1
Fa0/21

Switch#show flash:
Directory of flash:/
1
2

-rw-rw-

4414921
676

<no date>
<no date>

c2960-lanbase-mz.122-25.FX.bin
vlan.dat

64016384 bytes total (59600787 bytes free)

Router#show ip interface brief

Interface

IP-Address

OK? Method Status

FastEthernet0/0
FastEthernet0/0.10
FastEthernet0/0.20
FastEthernet0/1
Vlan1

unassigned
192.168.10.1
192.168.20.1
unassigned
unassigned

YES
YES
YES
YES
YES

NVRAM
manual
manual
NVRAM
NVRAM

Protocol

up
up
up
up
up
up
administratively down down
administratively down down

Router#show interfaces fastEthernet 0/0.10

FastEthernet0/0.10 is up, line protocol is up (connected)
Hardware is PQUICC_FEC, address is 0003.e4d4.7701 (bia 0003.e4d4.7701)
Internet address is 192.168.10.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 10
ARP type: ARPA, ARP Timeout 04:00:00,
Last clearing of "show interface" counters never

To remove VLAN(s), along with no vlan commands also remove vlan.dat file from flash by issuing
Switch#delete flash:vlan.dat command.
#show vlan command output does not display the trunk ports in it, # show interfaces trunk
command is to be issued to specifically see trunks.

VTP Configurations
1-Configure links between all switches as Trunks
Switch(config-int)#switchport mode trunk

2-Configure VTP domain

Switch(config)#vtp domain DISTRIBUTION
Changing VTP domain name from NULL to DISTRIBUTION

3-Configure VTP mode

Switch(config)#vtp mode server
Device mode already VTP SERVER.

4-Configure VTP password

Switch(config)#vtp password cisco
Setting device VLAN database password to cisco

5-Configure VTP version and Pruning

Switch(config)#vtp version 2
Switch(config)#vtp pruning

Troubleshooting VTP
Switch#show vtp status
VTP Version
: 2
Configuration Revision
: 1
Maximum VLANs supported locally : 255
Number of existing VLANs
: 7
VTP Operating Mode
: Server
VTP Domain Name
: DISTRIBUTION
VTP Pruning Mode
: Disabled
VTP V2 Mode
: Enabled
VTP Traps Generation
: Disabled
MD5 digest
: 0x82 0x29 0xBA 0x71 0xE3 0x4D 0xDA 0xAC
Configuration last modified by 192.168.0.1 at 3-1-93 02:19:23
Local updater ID is 192.168.0.1(no valid interface found)

Switch#show vtp password

VTP Password: cisco

Switch#show vtp counters

VTP statistics:
Summary advertisements received
Subset advertisements received
Request advertisements received

: 0
: 0
: 0

Summary advertisements transmitted

Subset advertisements transmitted
Request advertisements transmitted
Number of config revision errors
Number of config digest errors
Number of V1 summary errors

:
:
:
:
:
:

5
3
0
0
0
0

VTP pruning statistics:

Trunk
Join Transmitted Join Received

Summary advts received from

non-pruning-capable device
---------------- ---------------- ---------------- ---------------------------

Spanning Tree Protocol Configurations

Analyzing Default STP Operations

ACCESS_0#show spanning-tree summary
Switch is in pvst mode
Root bridge for: default PC LAPTOP SERVER
Extended system ID
is enabled
Portfast Default
is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default
is disabled

EtherChannel misconfig guard is

UplinkFast
is
BackboneFast
is
Configured Pathcost method used

disabled
disabled
disabled
is short

Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------VLAN0001
0
0
0
3
3
VLAN0010
0
0
0
4
4
VLAN0020
0
0
0
4
4
VLAN0030
0
0
0
4
4
---------------------- -------- --------- -------- ---------- ---------4 vlans
0
0
0
15
15

ACCESS_2#show spanning-tree summary

Switch is in pvst mode
Root bridge for:
Extended system ID
is
Portfast Default
is
PortFast BPDU Guard Default is
Portfast BPDU Filter Default is
Loopguard Default
is
EtherChannel misconfig guard is
UplinkFast
is
BackboneFast
is
Configured Pathcost method used

enabled
disabled
disabled
disabled
disabled
disabled
disabled
disabled
is short

Name
Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ---------VLAN0001
1
0
0
1
2
VLAN0010
1
0
0
2
3
VLAN0020
1
0
0
2
3
VLAN0030
1
0
0
2
3
---------------------- -------- --------- -------- ---------- ---------4 vlans
4
0
0
7
11

STP mode is Per-VLAN Spanning Tree.

ACCESS_0 is default Root Bridge for VLANs: PC, LAPTOP and SERVER.
STP services like Portfast, BPDU Guard etc. are disabled.
On ACCESS_0 out of 15 STP Active ports no port is in Blocking state all of them are
Forwarding.
On ACCESS_2 out of 11 Active ports 4 port (1 per VLAN for 4 VLANs) are Blocking and 7 are
Forwarding.

ACCESS_0#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID
Priority
32769
Address
0002.1712.8990
This bridge is the root
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Forward Delay 15 sec

32769 (priority 32768 sys-id-ext 1)

0002.1712.8990
2 sec Max Age 20 sec Forward Delay 15 sec
20

Interface
---------------Fa0/3
Fa0/2
Fa0/1

Role
---Desg
Desg
Desg

Sts
--FWD
FWD
FWD

Cost
--------19
19
19

Prio.Nbr
-------128.3
128.2
128.1

Type
-------------------------------P2p
P2p
P2p

VLAN0010
Spanning tree enabled protocol ieee
Root ID
Priority
32778
Address
0002.1712.8990
This bridge is the root
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/3
Fa0/10
Fa0/2
Fa0/1

Role
---Desg
Desg
Desg
Desg

Sts
--FWD
FWD
FWD
FWD

32778 (priority 32768 sys-id-ext 10)

0002.1712.8990
2 sec Max Age 20 sec Forward Delay 15 sec
20
Cost
--------19
19
19
19

Prio.Nbr
-------128.3
128.10
128.2
128.1

Type
-------------------------------P2p
P2p
P2p
P2p

VLAN0020
Spanning tree enabled protocol ieee
Root ID
Priority
32788
Address
0002.1712.8990
This bridge is the root
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/11
Fa0/3
Fa0/2
Fa0/1

Role
---Desg
Desg
Desg
Desg

Sts
--FWD
FWD
FWD
FWD

Cost
--------19
19
19
19

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/3
Fa0/12
Fa0/2
Fa0/1

Role
---Desg
Desg
Desg
Desg

Forward Delay 15 sec

32788 (priority 32768 sys-id-ext 20)

0002.1712.8990
2 sec Max Age 20 sec Forward Delay 15 sec
20
Prio.Nbr
-------128.11
128.3
128.2
128.1

Type
-------------------------------P2p
P2p
P2p
P2p

VLAN0030
Spanning tree enabled protocol ieee
Root ID
Priority
32798
Address
0002.1712.8990
This bridge is the root
Hello Time 2 sec Max Age 20 sec
Bridge ID

Forward Delay 15 sec

Forward Delay 15 sec

Sts
--FWD
FWD
FWD
FWD

32798 (priority 32768 sys-id-ext 30)

0002.1712.8990
2 sec Max Age 20 sec Forward Delay 15 sec
20
Cost
--------19
19
19
19

Prio.Nbr
-------128.3
128.12
128.2
128.1

Type
-------------------------------P2p
P2p
P2p
P2p

Switch ACCESS_0 is the default Root Bridge for all VLANs 1, 10, 20 and 30.
All working ports of ACCESS_0 are designated forwarding for all VLANs.
All STP Timers, Port Costs and Port Priority are at their default values.

ACCESS_2#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID
Priority
32769
Address
0002.1712.8990
Cost
19
Port
3(FastEthernet0/3)
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/3
Fa0/1

Role
---Root
Altn

Sts
--FWD
BLK

32769 (priority 32768 sys-id-ext 1)

0040.0BD5.393C
2 sec Max Age 20 sec Forward Delay 15 sec
20
Cost
--------19
19

Prio.Nbr
-------128.3
128.1

Type
-------------------------------P2p
P2p

VLAN0010
Spanning tree enabled protocol ieee
Root ID
Priority
32778
Address
0002.1712.8990
Cost
19
Port
3(FastEthernet0/3)
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/10
Fa0/3
Fa0/1

Role
---Desg
Root
Altn

Sts
--FWD
FWD
BLK

Cost
--------19
19
19

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/11
Fa0/3
Fa0/1

Role
---Desg
Root
Altn

Forward Delay 15 sec

32778 (priority 32768 sys-id-ext 10)

0040.0BD5.393C
2 sec Max Age 20 sec Forward Delay 15 sec
20
Prio.Nbr
-------128.10
128.3
128.1

Type
-------------------------------P2p
P2p
P2p

VLAN0020
Spanning tree enabled protocol ieee
Root ID
Priority
32788
Address
0002.1712.8990
Cost
19
Port
3(FastEthernet0/3)
Hello Time 2 sec Max Age 20 sec
Bridge ID

Forward Delay 15 sec

Forward Delay 15 sec

Sts
--FWD
FWD
BLK

32788 (priority 32768 sys-id-ext 20)

0040.0BD5.393C
2 sec Max Age 20 sec Forward Delay 15 sec
20
Cost
--------19
19
19

Prio.Nbr
-------128.11
128.3
128.1

Type
-------------------------------P2p
P2p
P2p

VLAN0030
Spanning tree enabled protocol ieee
Root ID
Priority
32798
Address
0002.1712.8990
Cost
19
Port
3(FastEthernet0/3)
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/12
Fa0/3
Fa0/1

Role
---Desg
Root
Altn

Forward Delay 15 sec

Sts
--FWD
FWD
BLK

32798 (priority 32768 sys-id-ext 30)

0040.0BD5.393C
2 sec Max Age 20 sec Forward Delay 15 sec
20
Cost
--------19
19
19

Prio.Nbr
-------128.12
128.3
128.1

Type
-------------------------------P2p
P2p
P2p

Port Fa0/1 of ACCESS_2 is Blocked for all VLANs by STP.

Root Bridge ACCESS_0 is located at Fa0/3 at default FastEthernet cost of 19.

ACCESS_0#show spanning-tree detail

VLAN0001 is executing the ieee compatible Spanning Tree Protocol
Bridge Identifier has priority of 32768, sysid 1, 0002.1712.8990
Configured hello time 2, max age 20, forward delay 15
Current root has priority 32769
Topology change flag not set, detected flag not set
Number of topology changes 0 last change occurred 00:00:00 ago
from FastEthernet0/1
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
Port 1 (FastEthernet0/1) of VLAN0001 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.1
Designated bridge has priority 32769, address 0002.1712.8990
Designated port id is 128.1, designated path cost 19
Timers: message age 16, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default

#show spanning-tree detail lists STP related details on per VLAN and per Port basis.

Custom Configuration of STP

1- Configure Rapid PVST on all three Switches
ACCESS_0(config)#spanning-tree mode rapid-pvst
ACCESS_1(config)#spanning-tree mode rapid-pvst
ACCESS_2(config)#spanning-tree mode rapid-pvst

2- Make ACCESS_1 Root for VLAN 20 and ACCESS_2 for VLAN 30

ACCESS_1(config)#spanning-tree vlan 20 root primary
ACCESS_1#show spanning-tree vlan 20
VLAN0020
Spanning tree enabled protocol rstp

Root ID

Bridge ID

Priority
Address
This bridge
Hello Time

24596
0009.7CED.01C3
is the root
2 sec Max Age 20 sec

Priority
Address
Hello Time
Aging Time

24596 (priority 24576 sys-id-ext 20)

0009.7CED.01C3
2 sec Max Age 20 sec Forward Delay 15 sec
20

Interface
---------------Fa0/1
Fa0/2
Fa0/11

Role
---Desg
Desg
Desg

Sts
--FWD
FWD
FWD

Cost
--------19
19
19

Prio.Nbr
-------128.1
128.2
128.11

Forward Delay 15 sec

Type
-------------------------------P2p
P2p
P2p

ACCESS_2(config)#spanning-tree vlan 30 priority 4096

ACCESS_2#show spanning-tree vlan 30
VLAN0030
Spanning tree enabled protocol rstp
Root ID
Priority
4126
Address
0040.0BD5.393C
This bridge is the root
Hello Time 2 sec Max Age 20 sec
Bridge ID

Priority
Address
Hello Time
Aging Time

Interface
---------------Fa0/12
Fa0/3
Fa0/1

Role
---Desg
Desg
Altn

Forward Delay 15 sec

Sts
--FWD
FWD
BLK

4126 (priority 4096 sys-id-ext 30)

0040.0BD5.393C
2 sec Max Age 20 sec Forward Delay 15 sec
20
Cost
--------19
19
19

Prio.Nbr
-------128.12
128.3
128.1

Type
-------------------------------P2p
P2p
P2p

3- To change Blocking status of ports by changing Port Cost or Port Priority

(config)#interface fa0/1
(config-if)#spanning-tree vlan NUMBER port-priority NUMBER
(config-if)#spanning-tree vlan NUMBER cost NUMBER

4- Enable PortFast and BPDU Guard on Access ports

ACCESS_0(config)#interface range fa 0/10 - 12
ACCESS_0(config-if-range)#spanning-tree portfast

%Warning: portfast should only be enabled on ports connected to a single

host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast will be configured in 3 interfaces due to the range command
but will only have effect when the interfaces are in a non-trunking mode.

ACCESS_0(config-if-range)#spanning-tree bpduguard enable

5- To change STP Timers

(config)#spanning-tree vlan NUMBER hello-time/forward-time/max-age

6- Configure EtherChannel between all three switches

ACCESS_0(config-if)#channel-group 1 mode ?
active
auto
desirable
on
passive

Enable LACP unconditionally

Enable PAgP only if a PAgP device is detected
Enable PAgP unconditionally
Enable Etherchannel only
Enable LACP only if a LACP device is detected

ACCESS_0(config-if)#channel-group 1 mode on
ACCESS_0(config-if)#
Creating a port-channel interface Port-channel 1
%LINK-5-CHANGED: Interface Port-channel 1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel 1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to up

Troubleshooting Spanning Tree Protocol

ACCESS_0#show running-config
!
hostname ACCESS_0
!
spanning-tree mode rapid-pvst
!
interface FastEthernet0/2
channel-group 1 mode on
switchport mode trunk
!
interface FastEthernet0/3
channel-group 2 mode on
switchport mode trunk
!
interface FastEthernet0/4
channel-group 1 mode on
switchport mode trunk
!
interface FastEthernet0/6
channel-group 2 mode on
switchport mode trunk
!
interface FastEthernet0/10
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable
!

ACCESS_0#show etherchannel summary

Flags:

D
I
H
R
U
u
w
d

down
P - in port-channel
stand-alone s - suspended
Hot-standby (LACP only)
Layer3
S - Layer2
in use
f - failed to allocate aggregator
unsuitable for bundling
waiting to be aggregated
default port

Number of channel-groups in use: 2

Number of aggregators:
2
Group Port-channel Protocol
Ports
------+-------------+-----------+---------------------------------------------1
2

Po1(SU)
Po2(SU)

Fa0/2(P) Fa0/4(P)
Fa0/3(P) Fa0/6(P)

ACCESS_0#show etherchannel port-channel

Channel-group listing:
---------------------Group: 1
---------Port-channels in the group:
---------------------------

Port-channel: Po1
-----------Age of the Port-channel
= 00d:00h:21m:21s
Logical slot/port
= 2/1
Number of ports = 2
GC
= 0x00000000
HotStandBy port = null
Port state
= Port-channel
Protocol
=
PAGP
Port Security
= Disabled
Ports in the Port-channel:
Index
Load
Port
EC state
No of bits
------+------+------+------------------+----------0
00
Fa0/2
On
0
0
00
Fa0/4
On
0
Time since last port bundled:
00d:00h:20m:39s
Fa0/4
Group: 2
---------Port-channels in the group:
--------------------------Port-channel: Po2
-----------Age of the Port-channel
= 00d:00h:18m:02s
Logical slot/port
= 2/2
Number of ports = 2
GC
= 0x00000000
HotStandBy port = null
Port state
= Port-channel
Protocol
=
PAGP
Port Security
= Disabled
Ports in the Port-channel:
Index
Load
Port
EC state
No of bits
------+------+------+------------------+----------0
00
Fa0/3
On
0
0
00
Fa0/6
On
0
Time since last port bundled:
00d:00h:17m:49s
Fa0/6

#show running-config
#show spanning-tree
#show spanning-tree active
#show spanning-tree detail
#show spanning-tree vlan NUMBER interface 0/1 detail
#show spanning-tree summary
#debug spanning-tree events

IOS interface Error Counters

For both Routers and Switches interface counters are helpful in monitoring and troubleshooting
various Hardware and Software errors.

#show interfaces
FastEthernet0/1 is up, line protocol is up (connected)

Hardware is Lance, address is 0060.47e9.7501 (bia 0060.47e9.7501)

BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Last input 00:00:08, output 00:00:05, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
956 packets input, 193351 bytes, 0 no buffer
Received 956 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
2357 packets output, 263570 bytes, 0 underruns
0 output errors, 0 collisions, 10 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Counters (in
alphabetical order)

Description and Common Causes of Incrementing Error Counters

Alignment errors are a count of the number of frames received that don't end with an even number of octets
and have a bad Cyclic Redundancy Check (CRC).

Align-Err

babbles

Carri-Sen

Common Causes: These are usually the result of a duplex mismatch or a physical problem (such as cabling,
a bad port, or a bad NIC). When the cable is first connected to the port, some of these errors can occur. Also,
if there is a hub connected to the port, collisions between other devices on the hub can cause these errors.
A jabber is a frame longer than 1518 octets (which exclude framing bits, but include FCS octets), which does
not end with an even number of octets (alignment error) or has a bad FCS error.
Carri-Sen (carrier sense) counter increments every time an Ethernet controller wants to send data on a half
duplex connection. The controller senses the wire and checks if it is not busy before transmitting.
Common Causes: This is normal on an half duplex Ethernet segment.
The number of times a collision occurred before the interface transmitted a frame to the media successfully.

collisions

Common Causes:Collisions are normal for interfaces configured as half duplex but must not be seen on full
duplex interfaces. If collisions increase dramatically, this points to a highly utilized link or possibly a duplex
mismatch with the attached device.
This increments when the CRC generated by the originating LAN station or far-end device does not match the
checksum calculated from the data received.

CRC

Common Causes: This usually indicates noise or transmission problems on the LAN interface or the LAN
itself. A high number of CRCs is usually the result of collisions but can also indicate a physical issue (such as
cabling, bad interface or NIC) or a duplex mismatch.

deferred

The number of frames that have been transmitted successfully after they wait because the media was busy.
Common Causes: This is usually seen in half duplex environments where the carrier is already in use when

it tries to transmit a frame.

pause input

input packets with

dribble condition

An increment in pause input counter means that the connected device requests for a traffic pause when its
receive buffer is almost full.
Common Causes: This counter is incremented for informational purposes, since the switch accepts the
frame. The pause packets stop when the connected device is able to receive the traffic.
A dribble bit error indicates that a frame is slightly too long.
Common Causes: This frame error counter is incremented for informational purposes, since the switch
accepts the frame.
A count of frames for which transmission on a particular interface fails due to excessive collisions. An
excessive collision happens when a packet has a collision 16 times in a row. The packet is then dropped.

Excess-Col

Common Causes: Excessive collisions are typically an indication that the load on the segment needs to be
split across multiple segments but can also point to a duplex mismatch with the attached device. Collisions
must not be seen on interfaces configured as full duplex.
The number of valid size frames with Frame Check Sequence (FCS) errors but no framing errors.

FCS-Err

frame

Giants

ignored

Common Causes: This is typically a physical issue (such as cabling, a bad port, or a bad Network Interface
Card (NIC)) but can also indicate a duplex mismatch.
number of packets received incorrectly that has a CRC error and a non-integer number of octets (alignment
error).
Common Causes: This is usually the result of collisions or a physical problem (such as cabling, bad port or
NIC) but can also indicate a duplex mismatch.
Frames received that exceed the maximum IEEE 802.3 frame size (1518 bytes for non-jumbo Ethernet) and
have a bad Frame Check Sequence (FCS).
Common Causes: In many cases, this is the result of a bad NIC. Try to find the offending device and remove
it from the network.
The number of received packets ignored by the interface because the interface hardware ran low on internal
buffers.
Common Causes: Broadcast storms and bursts of noise can cause the ignored count to be increased.

Input errors

includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also
cause the input errors count to be increased, and some datagrams can have more than one error. Therefore,
this sum cannot balance with the sum of enumerated input error counts.
The number of times a collision is detected on a particular interface late in the transmission process. For a 10
Mbit/s port this is later than 512 bit-times into the transmission of a packet. Five hundred and twelve bit-times
corresponds to 51.2 microseconds on a 10 Mbit/s system.

Late-Col

Common Causes: This error can indicate a duplex mismatch among other things. For the duplex mismatch
scenario, the late collision is seen on the half duplex side. As the half duplex side is transmitting, the full
duplex side does not wait its turn and transmits simultaneously which causes a late collision. Late collisions
can also indicate an Ethernet cable or segment that is too long. Collisions must not be seen on interfaces
configured as full duplex.

lost carrier

The number of times the carrier was lost in transmission.

Common Causes: Check for a bad cable. Check the physical connection on both sides.
number of times multiple collisions occurred before the interface transmitted a frame to the media
successfully.

Multi-Col

Common Causes: Collisions are normal for interfaces configured as half duplex but must not be seen on full
duplex interfaces. If collisions increase dramatically, this points to a highly utilized link or possibly a duplex
mismatch with the attached device.
The number of received packets discarded because there is no buffer space.

no buffer

no carrier

Out-Discard

Common Causes: Compare with ignored count. Broadcast storms can often be responsible for these
events.
The number of times the carrier was not present in the transmission.
Common Causes: Check for a bad cable. Check the physical connection on both sides.
The number of outbound packets chosen to be discarded even though no errors have been detected.
Common Causes: One possible reason to discard such a packet can be to free up buffer space.
The number of failed buffers and the number of buffers swapped out.

Common Causes: A port buffers the packets to the Tx buffer when the rate of traffic switched to the port is
high and it cannot handle the amount of traffic. The port starts to drop the packets when the Tx buffer is full
output buffer failures
output buffers swapped and thus increases the underruns and the output buffer failure counters. The increase in the output buffer
failure counters can be a sign that the ports are run at an inferior speed and/or duplex, or there is too much
out
traffic that goes through the port. As an example, consider a scenario where a 1gig multicast stream is
forwarded to 24 100 Mbps ports. If an egress interface is over-subscribed, it is normal to see output buffer
failures that increment along with Out-Discards.

output errors

overrun

The sum of all errors that prevented the final transmission of datagrams out of the interface.
Common Cause: This issue is due to the low Output Queue size.
The number of times the receiver hardware was unable to hand received data to a hardware buffer.
Common Cause: The input rate of traffic exceeded the ability of the receiver to handle the data.

packets input/output

The total error free packets received and transmitted on the interface. Monitoring these counters for
increments is useful to determine whether traffic flows properly through the interface. The bytes counter
includes both the data and MAC encapsulation in the error free packets received and transmitted by the
system.

Rcv-Err

rcv-err = receive buffer failures. For example, a runt, giant, or an FCS-Err does not increment the rcv-err
counter. The rcv-err counter on a 5K only increments as a result of excessive traffic..

Runts

The frames received that are smaller than the minimum IEEE 802.3 frame size (64 bytes for Ethernet), and
with a bad CRC.
Common Causes: This can be caused by a duplex mismatch and physical problems, such as a bad cable,
port, or NIC on the attached device.

The number of times one collision occurred before the interface transmitted a frame to the media
successfully.
Single-Col

throttles

Common Causes: Collisions are normal for interfaces configured as half duplex but must not be seen on full
duplex interfaces. If collisions increase dramatically, this points to a highly utilized link or possibly a duplex
mismatch with the attached device.
The number of times the receiver on the port is disabled, possibly because of buffer or processor overload. If
an asterisk (*) appears after the throttles counter value, it means that the interface is throttled at the time the
command is run.
Common Causes:Packets which can increase the processor overload include IP packets with options,
expired TTL, non-ARPA encapsulation, fragmentation, tunelling, ICMP packets, packets with MTU checksum
failure, RPF failure, IP checksum and length errors.
The number of times that the transmitter has been that run faster than the switch can handle.

underruns

Undersize

Common Causes: This can occur in a high throughput situation where an interface is hit with a high volume
of bursty traffic from many other interfaces all at once. Interface resets can occur along with the underruns.
The frames received that are smaller than the minimum IEEE 802.3 frame size of 64 bytes (which excludes
framing bits, but includes FCS octets) that are otherwise well formed.
Common Causes: Check the device that sends out these frames.
This is an indication that the internal send (Tx) buffer is full.

Xmit-Err

Common Causes: A common cause of Xmit-Err can be traffic from a high bandwidth link that is switched to a
lower bandwidth link, or traffic from multiple inbound links that are switched to a single outbound link. For
example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a 100Mbps
interface, this can cause Xmit-Err to increment on the 100Mbps interface. This is because the output buffer of
the interface is overwhelmed by the excess traffic due to the speed mismatch between the inbound and
outbound bandwidths.

Analyzing LAN Topology using CDP

CDP provides basic information about DIRECTLY ATTACHED devices without knowing the passwords
of devices and without accessing them properly.
CDP is Cisco proprietary, IEEE has standardized Link Layer Discovery Protocol (LLDP) which serves
the same role.
CDP is used to document or confirm the network diagram using inter-device advertisement
messages.
Any CDP supporting device can learn about other CDP supporting devices.

ACCESS_0#show cdp neighbors

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID
Local Intrfce
Holdtme
Capability
Platform
Port ID
Router
Fas 0/1
161
R
C1841
Fas 0/0
Router
Fas 0/1
161
R
C1841
Fas 0/0.10
Router
Fas 0/1
161
R
C1841
Fas 0/0.20
Router
Fas 0/1
161
R
C1841
Fas 0/0.30
ACCESS_1
Por 1
161
S
2960
Fas 0/2
ACCESS_1
Por 1
161
S
2960
Fas 0/4
ACCESS_1
Por 1
161
S
2960
Por 1
ACCESS_2
Por 2
161
S
2960
Fas 0/3
ACCESS_2
Por 2
161
S
2960
Fas 0/6
ACCESS_2
Por 2
161
S
2960
Por 2
IP Phone
Fas 0/7
140
H P
7960

Device ID: Lists the Hostname of the device.

Local Interface: The Local interface to which the other foreign device is attached, in this case Switch
ACCESS_0s own interfaces are listed here to which other devices are attached.
Hold Time: Is the amount of time in seconds for which the Show CDP command will hold the output and
would not change output for that particular device until that timer expires. For example IP Phone has hold
timer of 140, even if the device is removed the switch will list the phone in output for 140 seconds after
that it will refresh the output.
Capability: Shows whether the device is a router, a switch or a phone.
Platform: Show the model of a particular device.
Port ID: Is the port of the foreign device that is listed in the output, to which this local device is attached.

Note that the switch is showing EtherChannel ports of both local and foreign devices but only shows
the actual ports in EtherChannel for foreign devices.

ACCESS_0#show cdp neighbors detail

Device ID: Router
Entry address(es):
IP address : 192.168.1.254
Platform: cisco C1841, Capabilities: Router
Interface: FastEthernet0/1, Port ID (outgoing port): FastEthernet0/0.10
Holdtime: 157
Version :
Cisco IOS Software, 1841 Software (C1841-ADVIPSERVICESK9-M), Version 12.4(15)T1, RELEASE SOFTWARE
(fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Wed 18-Jul-07 04:52 by pt_team
advertisement version: 2

Duplex: full
----------------------------------------------------Device ID: ACCESS_1
Entry address(es):
IP address : 192.168.0.2
Platform: cisco 2960, Capabilities: Switch
Interface: Port-channel 1, Port ID (outgoing port): FastEthernet0/2
Holdtime: 157
Version :
Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version 12.2(25)FX, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Wed 12-Oct-05 22:05 by pt_team
advertisement version: 2
Duplex: full
------------------------------------------------------------------------------Device ID: IP Phone
Entry address(es):
Platform: cisco 7960, Capabilities: Host Phone
Interface: FastEthernet0/7, Port ID (outgoing port): Switch
Holdtime: 137
Version :
P00303020214
advertisement version: 2
Duplex: full

Show cdp neighbor detail command lists following additional device by device details :
Layer 3 Address: Along with the layer 2 address of outgoing and incoming ports the detail command also
lists the layer 3 IP address of attached device.
IOS Software and Version: Lists the IOS software name and its version.
Duplex: Whether the device is connecting to other device in full or half duplex.

CDP can be disabled globally and on per-interface basis, to toggle CDP off and on issue no cdp run
and cdp run command globally and to no cdp enable and cdp enable command on per-interface
basis.

PART 3
ROUTING

ROUTING
PART A

CONCEPTS

Routing Logic Summary

1. For each received data link frame, choose whether or not to process the frame. Process it if:
A. The frame has no errors (per the data link trailer Frame Check Sequence, or FCS, field).
Routers do not attempt to recover the error.
B. The frames destination data link address is the routers address (or an appropriate multicast
or broadcast address).
2. If choosing to process the frame at Step 1, deencapsulate the packet from inside the data link frame.
3. Make a routing decision. To do so, compare the packets destination IP address to the routing table and
find the route that matches the destination address. This route identifies the outgoing interface of the
router and possibly the next hop router.
4. Encapsulate the packet into a data link frame appropriate for the outgoing interface. When forwarding
out LAN interfaces, use ARP as needed to find the next devices MAC address.
5. Transmit the frame out the outgoing interface, as listed in the matched IP route.

Cisco Routers Switching Methods

Packet Switching is the internal process that router uses to switch packet between its interfaces or different
networks.
Cisco routers switch packets using following three methods:
Process Switching:
This traditional type of switching was used in early days dating back 1980s and 1990s.
Process switching works like a formal routing process as described before.
Fast Switching:
Fast switching makes some additional optimizations to traditional Process Switching:
It kept another list in addition to the routing table, listing specific IP addresses for recently
forwarded packets.
This fast-switching cache also kept a copy of the new data link headers used when forwarding
packets to each destination.
Rather than build a new data link header for each packet destined for a particular IP address,
the router saved a little effort by copying the old data link header.
Cisco Express Forwarding (CEF) Switching:
Like fast switching, CEF uses additional tables for faster searches, and it saves outgoing data link
headers.
CEF organizes its tables for all routing table destinations, ahead of time, not just for some of the
specific destination IP addresses.
CEF also uses much more sophisticated search algorithms and binary tree structures as compared to
fast switching.
CEF table lookups that replace the routing table matches take even less time than with fast
switching, it caches the data link headers as well.
Today, current models of Cisco routers, and current IOS versions, use CEF by default.

Before a router can route IP packets out one or more interfaces, the router needs some routes.
Routers can add routes to their routing tables through three methods:
1. Connected routes: Added because of the configuration of the ip address interface
subcommand on the local router.
2. Static routes: Added because of the configuration of the ip route global command on the
local router.
3. Routing protocols: Added as a function by configuration on all routers, resulting in a
process by which routers dynamically tell each other about the network so that they all learn
routes.

Connected Routes

A Cisco router automatically adds a route to its routing table for the subnet connected to each
interface, assuming that the following two facts are true:
The interface is in a working statein other words, the interface status in the show
interfaces command lists a line status of up and a protocol status of up.
The interface has an IP address assigned through the ip address interface subcommand.

Static Routes

Networks use static routesroutes added to a routing table through direct configurationmuch less
often than dynamic routing.
IOS allows the definition of individual static routes using the ip route global configuration
command.
Every ip route command defines a destination that can be matched, usually with a subnet ID and
mask.
The command also lists the forwarding instructions, typically listing either the outgoing interface or
the next-hop routers IP address.
IOS then takes that information and adds that route to the IP routing table.

Default Static Route:

When a router tries to route a packet, the router might not match the packets destination IP address
with any route. When that happens, the router normally just discards the packet.

Routers can be configured so that they use either a statically configured or dynamically learned
default route. The default route matches all packets, so that if a packet does not match any other
more specific route in the routing table, the router can at least forward the packet based on the
default route.
IOS allows the configuration of a static default route by using special values for the subnet and mask
fields in the ip route command: 0.0.0.0 and 0.0.0.0. For example, the command ip route 0.0.0.0
0.0.0.0 S0/0/1 creates a static default route on

Dynamic Routing Protocols

Routing protocol:
A set of messages, rules, and algorithms used by routers for the overall purpose of learning
routes.
This process includes the exchange and analysis of routing information.
Each router chooses the best route to each subnet (path selection) and finally places those
best routes in its IP routing table. Examples include RIP, EIGRP, OSPF, and BGP.
Routed protocol and Routable protocol:
Both terms refer to a protocol that defines a packet structure and logical addressing, allowing
routers to forward or route the packets.
Routers forward packets defined by routed and routable protocols. Examples include IP
Version 4 (IPv4) and IP Version 6 (IPv6).
The goals of a routing protocol, regardless of how the routing protocol works:
To dynamically learn and fill the routing table with a route to each subnet in the internetwork.
If more than one route to a subnet is available, to place the best route in the routing table.
To notice when routes in the table are no longer valid, and to remove them from the routing
table.
If a route is removed from the routing table and another route through another neighboring
router is available, to add the route to the routing table. (Many people view this goal and the
preceding one as a single goal.)
To work quickly when adding new routes or replacing lost routes. (The time between losing
the route and finding a working replacement route is called convergence time.)
To prevent routing loops.
Functions of Routing Protocols:
Learn routing information about IP subnets from other neighboring routers.
Advertise routing information about IP subnets to other neighboring routers.
If more than one possible route exists to reach one subnet, pick the best route based on a
metric.
If the network topology changesfor example, a link failsreact by advertising that some
routes have failed and pick a new currently best route. (This process is called convergence.)
The term path selection sometimes refers to part of the job of a routing protocol, in which the
routing protocol chooses the best route.

Interior Gateway Protocols and Exterior Gateway Protocols

IGP: A routing protocol that was designed and intended for use inside a single autonomous system
(AS).
EGP: A routing protocol that was designed and intended for use between different autonomous
systems.
AS is a network under the administrative control of a single organization. Each ISP is also typically a
single different AS.

Some routing protocols work best inside a single AS by design, so these routing protocols are called
IGPs.
Routing protocols designed to exchange routes between routers in different autonomous systems
are called EGPs. Today, Border Gateway Protocol (BGP) is the only EGP used.
Each AS can be assigned a number called (unsurprisingly) an AS number (ASN). Like public IP
addresses, the Internet Assigned Numbers Authority (IANA, www.iana.org) controls the worldwide
rights to assigning ASNs. It delegates that authority to other organizations around the world,
typically to the same organizations that assign public IP addresses. For example, in North America,
the American Registry for Internet Numbers (ARIN, www.arin.net) assigns public IP address ranges
and ASNs.

IGP Algorithms:

The term routing protocol algorithm simply refers to the logic and processes used by different
routing protocols to solve the problem of learning all routes, choosing the best route to each subnet,
and converging in reaction to changes in the internetwork.
Three main branches of routing protocol algorithms exist for IGP routing protocols:
Distance vector (sometimes called Bellman-Ford after its creators).
Advanced distance vector (sometimes called balanced hybrid).
Link-state.

Basic Distance Vector Routing Protocol Features

EIGRP does not fit cleanly into the category of DV routing protocols or LS routing protocols. However, it
most closely matches DV protocols.
The term distance vector describes what a router knows about each route. At the end of the process, when
a router learns about a route to a subnet, all the router knows is some measurement of distance (the
metric) and the next-hop router and outgoing interface to use for that route (a vector, or direction).
Figure shows a view of both the vector and the distance as learned with RIP. The figure shows the flow of
RIP messages that cause R1 to learn some IPv4 routes, specifically three routes to reach subnet X:
The four-hop route through R2
The three-hop route through R5
The two-hop route through R7

DV protocols learn two pieces of information about a possible route to reach a subnet: the distance (metric),
and the vector (the next hop router).
Figure gives a better view into R1s distance vector logic. R1 knows three routes, each with:
Distance: The metric for a possible route
Vector: The direction, based on the next-hop router for a possible route
R1 knows no other topology information about the internetwork. Unlike LS protocols, RIPs DV logic has no
idea about the overall topology, instead just knowing about next-hop routers and metrics.

Full Update Messages and Split Horizon

DV routing protocols have a couple of functions that require messages between neighboring routers.
First, routers need to send routing information inside some message, so that the sending router can
advertise routing information to neighboring routers
RIP and EIGRP both happen to call their messages an update message.
Routers need to monitor whether each neighboring router is still working or not; routers do so by sending
and receiving regular messages with each neighbor.
By quickly realizing when a neighboring router fails, routers can more quickly converge to use any stillavailable routes.
All routing protocols use some mechanism to monitor the state of neighboring routers. OSPF uses Hello
messages, on a relatively short timer (default 10 seconds on many interfaces). EIGRP happens to use a
Hello message and process, as well.
However, old basic DV protocols like RIP do not use a separate Hello type of message, instead using the
same update message both to advertise routing information and be aware of whether the neighboring
router is still alive.
The function of advertising routing information, and the function of monitoring neighbor state, is done with
the same update message.
These older basic DV routing protocols like RIP send periodic full routing updates based on a relatively short
timer.
Full update means that a router advertises all its routes, using one or more RIP update messages, no matter
whether the route has changed or not.
Periodic means that the router sends the message based on a timed period (30 seconds with RIP).

How Information Is Discovered with Distance Vectors

Network discovery is the process of learning about nondirectly connected destinations.
As the network discovery proceeds, routers accumulate metrics and learn the best paths to various
destinations.
In Figure below:
Each directly connected network has a distance of 0.
Router A learns about other networks based on information it receives from Router B.
Router A increments the distance metric for any route learned by Router B.
Router B knows about the networks to Router C, which is directly connected.
Router B increments its distance metrics by 1 and sends them to Router A.

Updating Routing Tables

A router compares the information contained in the update to its current table. If the update contains
information about a better (lower-metric) route to a destination, the router updates its own routing table.
During updates, the router sends its entire routing table to each of its adjacent neighbors.
The table includes the total path cost (defined by its metric) and the logical address of the first router on
the path to each destination network.
In Figure below, Router B is one unit of cost from Router A. Therefore, it adds 1 to all costs reported by
Router A

How Routing Loops Occur in Distance Vector Protocols

During updates, routing loops can occur if the network has inconsistent routing entries. Slow convergence
on a new configuration is one cause of this phenomenon.
The network is converged when all routers have consistent routing tables.
Figure below illustrates how a routing loop occurs:
Before a network failure, all routers have correct tables.
Figure uses hop count as a cost metric, so the cost of each link is 1.
Router C is directly connected to network 10.4.0.0, with a distance of 0.
Router As path to network 10.4.0.0 is through Router B, with a hop count of 2.
Network 10.4.0.0 fails, and Router C detects the failure and stops routing packets to that network.
At this point, Routers A and B still do not know of the failure.
Router As table still shows a valid path to 10.4.0.0 through Router B.
If Router B sends out its normal update to Routers A and C, Router C sees a valid path to 10.4.0.0 through
Router B and updates its routing table to reflect a path to network 10.4.0.0 with a hop count of 2
(remember, B has incremented the hop count for A).
Now Router C sends an update back to Router B, which then updates Router A. Router A detects the
modified distance vector to network 10.4.0.0 as 4.
With each update, the incorrect information continues to bounce between the routers. Without some
mechanism to prevent this, the updates continue. This condition, called counting to infinity, continuously
loops packets around the network.

Split Horizon
Split horizon is one way to eliminate routing loops and speed convergence. The idea behind split horizon is
that it is never useful to send information about a route back in the direction from which the update came.
If the router has no valid alternative path to the network, it is considered inaccessible.
Split horizon also eliminates unnecessary routing updates, thus speeding convergence.
Figure below shows:
Routers A and B do not advertise the failed route 10.1.4.0 out of the interfaces they learned the failed
route.
In this case, this is interface Serial 0 for Router A and interface Serial 1 for Router B.
When Router B sees the metric of 10.4.0.0 jump to infinity, Router B sends a poison reverse back to Router
C.
The poison reverse states that network 10.4.0.0 is inaccessible.
Poison reverse is a specific circumstance that overrides split horizon. Router C is no longer susceptible to
incorrect updates about network 10.4.0.0.

Route Poisoning
Route poisoning (part of split horizon) also eliminates routing loops caused by inconsistent updates. Route
poisoning sets a route to unreachable.
By poisoning a route, the router is not susceptible to incorrect updates about the poisoned network from
other routers that claim to have a valid alternate path.
Figure shows:
When network 10.4.0.0 goes down, Router C poisons its link to network 10.4.0.0 with an infinite metric
(marked as unreachable, seen as a hop count of 16 in RIP).
When Router B sees the metric of 10.4.0.0 jump to infinity, Router B sends a poison reverse back to Router
C.
The poison reverse states that network 10.4.0.0 is inaccessible.
Poison reverse is a specific circumstance that overrides split horizon. Router C is no longer susceptible to
incorrect updates about network 10.4.0.0.

Poison Reverse
In Figure:

When Router B sees the metric to 10.4.0.0 jump to infinity, it sends a return message (overriding split
horizon) called a poison reverse back to Router C, stating that network 10.4.0.0 is inaccessible.
This message ensures that all routers on that segment have received information about the poisoned route.

Triggered Updates
A triggered update is sent immediately in response to a change in the network.
The router detecting the change immediately sends an update message to adjacent routers, which then
generate their own triggered updates.
This continues until the network converges.
The following two problems exist with triggered updates:
The update message can be dropped or corrupted.
The updates do not happen instantly. A router can issue a regular update before receiving the triggered
update. If this happens, the bad route can be reinserted into a router that received the triggered update.
Solution: Hold-down timers dictate that when a route is invalid, no new route with the same or a worse
metric will be accepted for the same destination for a period of time.
This allows the triggered update to propagate throughout the network.

Hold-Down Timers
Hold-down timers prevent regular update messages from inappropriately reinstating a route that might
have gone bad. They force routers to hold any changes for a period of time.
Figure shows the hold-down implementation process:
1 When a router receives an update that a network is down, it marks the route as inaccessible and starts a
hold-down timer.
2 If an update is received from a neighboring router with a better metric, the router removes the timer and
uses the new metric.
3 If an update is received (before the hold-down timer expires) with a poorer metric, the update is ignored.
4 During the hold-down period, routes appear in the routing table as possibly down.

Link-State Routing

The link-state-based routing algorithm (also known as shortest path first [SPF]) maintains a database of
topology information.
Unlike the distance vector algorithm, link-state routing maintains full knowledge of distant routers and how
they interconnect.
Network information is shared in the form of link-state advertisements (LSA).
With link-state routing protocols, each router has a full map of the network topology.
A router can independently make a decision based on its map of the network.
Each link-state router must keep a record of the following:
Immediate neighbor routers
All other routers in the network
The best paths to each destination
Link-state routing provides better scaling than distance vector routing for the following reasons:

 Link-state sends only topology changes (called triggered updates). Distance vector sends complete
routing tables.
Link-state updates are sent less often than distance vector updates.
Link-state uses a hierarchy by dividing large routing domains into smaller routing domains called areas.
Areas limit the scope of route changes.
Link-state supports classless addressing and summarization.
Link-state routing converges fast and is robust against routing loops, but it requires a great deal of
memory and strict network designs.

Metrics:

A unit of measure used by routing protocol algorithms to determine the best route for traffic to use
to reach a particular destination.
Routing protocols choose the best route to reach a subnet by choosing the route with the lowest
metric.

Route redistribution:

Many companies and organizations use a single routing protocol. However, in some cases, a
company needs to use multiple routing protocols.
For example, if two companies connect their networks so that they can exchange information, they
need to exchange some routing information. If one company uses OSPF, and the other uses EIGRP,
on at least one router, both OSPF and EIGRP must be used. Then, that router can take routes learned
by OSPF and advertise them into EIGRP, and vice versa, through a process called route

redistribution.

Administrative Distance:

In Cisco routers, a means for one router to choose between multiple routes to reach the same subnet
when those routes were learned by different routing protocols.
The lower the administrative distance, the better the source of the routing information.
Depending on the network topology, the two routing protocols might learn routes to the same
subnets. When a single routing protocol learns multiple routes to the same subnet, the metric tells it
which route is best.
When two different routing protocols learn routes to the same subnet, because each routing
protocols metric is based on different information, IOS cannot compare the metrics.
OSPF might learn a route to subnet 10.1.1.0 with metric 101, and EIGRP might learn a route to
10.1.1.0 with metric 2,195,416, but the EIGRP might be the better routeor it might not. There is
simply no basis for comparison between the two metrics.
When IOS must choose between routes learned using different routing protocols, IOS uses a concept
called administrative distance.
Administrative distance is a number that denotes how believable an entire routing protocol is on a
single router. The lower the number, the better, or more believable, the routing protocol.
For example, RIP has a default administrative distance of 120, OSPF uses a default of 110, and EIGRP
defaults to 90. When using OSPF and EIGRP, the router will believe the EIGRP route instead of the
OSPF route (at least by default).
The administrative distance values are configured on a single router and are not exchanged with
other routers.

Open Shortest Path First

OSPF is link-state routing protocol was developed to replace RIP.

Major advantages of OSPF are:
Guarantees loop-free network

Every router has the same map of the network

Open standard
Scalability
Fast convergence
OSPF actively looks for neighbors.
OSPF updates are event driven and incremental.
Updating is efficient: uses reliable multicast and unicast updates, non-OSPF routers do not need to
process the updates where as in RIP all the routers had to process the update.
Bandwidth based cost metric: lower is better.
Control Plane Security: clear-text and MD5.
VLSM and summarization support.
Hierarchy through areas.
Every router has the same input topology database and every router gives same output SPF
tree.

OSPF Terminology:

When learning about OSPF, you might encounter different terminology for the OSPF tables. Following
is list of common terminology used in OSPF:
OSPF neighbor table = Adjacency database
OSPF topology table = OSPF topology database (link-state database [LSDB])
Routing table = Forwarding database

OSPF Router ID (RID):

Each router then uses RIDs for many purposes, such as the following:
When routers send a Hello message, they basically state Hello, my RID is....
Neighbors identify each other by their RID, as listed in the output of the show ip ospf
neighbor command.
Many LSAs list the RID of one of the routers.
For OSPF to initialize, it must be able to define a router ID for the entire OSPF process.
A router can receive its router ID from several sources:
First, it can be assigned manually through the router-id command.
Second, it is the numerically highest IP address set on a loopback interface. The loopback
interface is a logical interface that never goes down.
If no loopback address is defined, an OSPF enabled router will select the numerically highest
IP address on any of its OSPF-configured interfaces as its router ID.
The router ID is chosen when OSPF is initialized. Initialization occurs when a router loads its OSPF
configuration, whether at startup or when OSPF is first configured or reloaded.
If other interfaces later come online that have a higher IP address, the OSPF router ID does not
change until the OSPF process is restarted.

OSPF Message Format

The data portion of an OSPF message is encapsulated in a packet. This data field can include one of five
OSPF packet types. Figure shows an encapsulated OSPF message in an Ethernet frame:

The OSPF packet header is included with every OSPF packet, regardless of its type.
The OSPF packet header and packet type-specific data are then encapsulated in an IP packet.
In the IP packet header, the protocol field is set to 89 to indicate OSPF, and the destination address
is typically set to one of two multicast addresses: 224.0.0.5 or 224.0.0.6.
224.0.0.5 is used to send updates to DR and 224.0.0.6 used to send updates from DR to everyone
else.

If the OSPF packet is encapsulated in an Ethernet frame, the destination MAC address is also a
multicast address: 01-00-5E-00-00-05 or 01-00-5E-00-00-06.
Main OSPF Packet Header
Version

Type

Packet Length
Router ID
Area ID

Checksum

Instance ID

OSPF Packet Types

There are five OSPF packet types each serve a specific purpose in the routing process.
As per RFC 5340 (OSPFv3 for IPv6) there are 5 OSPF Packet formats as follows:
1. Hello: Hello packets are used to:
Discover OSPF neighbors.
Establish and maintain adjacency with other OSPF routers.
Advertise parameters on which two routers must agree to become neighbors.
Elect the DR and BDR on multi-access networks such as Ethernet and Frame Relay.

Type 1: The Hello Packet Header

Version

Type

Checksum
Router Priority
Hello Interval

Packet Length
Router ID
Area ID
Instance ID
Interface ID
Options
Router Dead Interval
Designated Router ID
Backup Designated Router ID
Neighbor ID

Important Fields in Hello Packet Header are:

Type: OSPF packet type: Hello (Type 1), DBD (Type 2), LS Request (Type 3), LS Update(Type 4), LS ACK
(Type 5)
Local Router ID: ID of the originating router
Local Area ID: Area from which the packet originated
Local Interface Mask: Subnet mask associated with the sending interface
Hello Interval: Number of seconds between the sending routers Hellos
Router Priority: Used in DR/BDR election (discussed later in the section DR/BDR Election)
Designated Router (DR): Router ID of the DR, if any
Backup Designated Router (BDR): Router ID of the BDR, if any
RIDs of Neighbors: Lists the OSPF Router ID of the neighboring router(s)

Receiving an OSPF Hello packet on an interface confirms for a router that another OSPF router exists
on this link. OSPF then establishes adjacency with the neighbor.
By default, OSPF Hello packets are sent to the multicast address 224.0.0.5 (All SPF Routers) every 10
seconds on multi-access and point-to-point segments and every 30 seconds on non-broadcast multiaccess (NBMA) segments (Frame Relay, X.25, ATM).
The default dead interval is four times the Hello interval.
2. Database Description: DBD packet contains an abbreviated list of the sending routers linkstate database and is used by receiving routers to check against the local link state database.
Type 2: The Database Description Packet Header
Version

Type

Checksum
0
Interface MTU

Packet Length
Router ID
Area ID
Instance ID
Interface ID
Options
0
0
0
0 0 0
DD Sequence number
An LSA Header

MS

3. Link-State Request: Receiving routers can then request more information about any entry
in the DBD by sending a LSR.
Type 3: The OSPF Link State Request Packet Header
Version

Type

Packet Length
Router ID
Area ID

Checksum
0

Instance ID

0
LS Type

Link State ID
Advertising Router

4. Link-State Update: LSU packets are used to reply to LSRs and to announce new
information. LSUs contain 11 types of link-state advertisements (LSAs).LSU and LSA terms are
often used interchangeably.
Type 1 LSAs are router LSAs and are generated by each router for each area to which
it belongs. These LSAs describe the states of the routers links to the area and are
flooded within a single area.
Type 2 LSAs are network LSAs and are generated by the DR and BDR. They describe
the set of routers attached to a particular network. They are flooded within a single
area.

Type 4: The OSPF Link State Update Packet

Version

Type

Packet Length
Router ID
Area ID

Checksum

Instance ID

# LSAs
LSAs

5. Link-State Acknowledgement: When an LSU is received, the router sends an LSAck to

confirm receipt of the LSU.
Type 5: The OSPF Link State Acknowledgement Packet
Version

Type

Packet Length
Router ID
Area ID

Checksum

Instance ID
An LSA Header

OSPF Link-State Database (LSDB) is the data structure in RAM of a router that holds the various
LSAs, with the collective LSAs representing the entire topology of the network.

OSPF network types

1. Point-to-point

Point-to-point networks, such as a T1, connect a single pair of routers that always
become adjacent. No DR/BDR elections take place.

2. Broadcast multi-access

Examples of broadcast networks are Ethernet and Token Ring. OSPF routers on
broadcast networks elect a designated router (DR) and backup designated router
(BDR). All routers on the broadcast segment form adjacencies with the DR and BDR.
Multi-access networks create two challenges for OSPF regarding the flooding of LSAs:
Creation of multiple adjacencies, one adjacency for every pair of routers
Extensive flooding of LSAs

3. Non-broadcast multi-access

NBMA networks include Frame Relay, X.25, and ATM; they are capable of connecting
more than two routers but have no broadcast capability. NBMA networks elect a DR
and BDR, and all OSPF packets are unicast.

4. Point-to-multipoint

Point-to-multipoint networks are a special configuration of NBMA networks in which

networks are treated as a collection of point-to-point links. Routers on these networks
do not elect a DR or BDR, and because all links are seen as point-to-point, all OSPF
packets are multicast.

5. Virtual links

Virtual links are a special configuration that is interpreted by the router as

unnumbered point-to-point networks. Virtual links are created by the administrator.

OSPF Designated Routers on Ethernet

On Ethernet links, OSPF elects one of the routers on the same subnet to act as the designated router
(DR).
The DR plays a key role in how the database exchange process works, with different rules than with
point-to-point links.

The figure shows five OSPFv2 routers on the same Ethernet VLAN. These five OSPF routers elect one
router to act as the DR, and one router to be backup DR (BDR). The figure shows A and B as DR and
BDR, for no other reason than the Ethernet must have one of each.
The database exchange process on an Ethernet link does not happen between every pair of routers
on the same VLAN/subnet. Instead, it happens between the DR and each of the other routers, with
the DR making sure that all the other routers get a copy of each LSA.
The BDR watches the status of the DR and takes over for the DR if it fails. (When the DR fails, the
BDR takes over, and then a new BDR is elected.)
Because the DR and BDR both do full database exchange with all the other OSPF routers in the LAN,
they reach a full state with all neighbors.
Routers that are neither a DR nor a BDRcalled DROthers by OSPFnever reach a full state
because they do not do database exchange with each other.
The show ip ospf neighbor command on these routers list some neighbors, permanently, in a
state of 2-way, and not in a full state.
With OSPF working normally on the Ethernet LAN in Figure 8-5, a show ip ospf neighbor command
on router C (a DROther) would show the following:
Two neighbors (A and B, the DR and BDR, respectively) with a full state (called fully adjacent)
Two neighbors (D and E) with a 2-way state (called adjacent)
This different behavior on OSPF neighbors on a LANwhere some neighbors reach full state and
some do notcalls for the use of two more OSPF terms: adjacent and fully adjacent.
Fully adjacent neighbors reach a full state, after having exchanged their LSDBs directly. Adjacent
neighbors are those DROther routers that (correctly) choose to stay in 2-way state but never reach a
full state.

DR/BDR Election

The solution to managing the number of adjacencies and the flooding of LSAs on a multi-access
network (e.g. Ethernet) is the designated router (DR).
To reduce the amount of OSPF traffic on multi-access networks, OSPF elects a DR and backup DR
(BDR). The DR is responsible for updating all other OSPF routers when a change occurs in the multiaccess network. The BDR monitors the DR and takes over as DR if the current DR fails.
The following criteria is used to elect the DR and BDR:
1. DR: Router with the highest OSPF interface priority.
2. BDR: Router with the second highest OSPF interface priority.
3. If OSPF interface priorities are equal, the highest router ID is used to break the tie.
When the DR is elected, it remains the DR until one of the following conditions occurs:
1. The DR fails.
2. The OSPF process on the DR fails.
3. The multi-access interface on the DR fails.
If the DR fails, the BDR assumes the role of DR, and an election is held to choose a new BDR. If a
new router enters the network after the DR and BDR have been elected, it will not become the DR or
the BDR even if it has a higher OSPF interface priority or router ID than the current DR or BDR.
The new router can be elected the BDR if the current DR or BDR fails. If the current DR fails, the BDR
will become the DR, and the new router can be elected the new BDR.
Without additional configuration, you can control the routers that win the DR and BDR elections by
doing either of the following:
Boot the DR first, followed by the BDR, and then boot all other routers.
Shut down the interface on all routers, followed by a no shutdown on the DR, then the BDR,
and then all other routers.
However, the recommended way to control DR/BDR elections is to change the interface priority.

Link-State Routing Process

General Link-State routing in following steps:

Form adjacency relationship with connected neighbors
Exchange attributes in form of LSAs with connected neighbors
Store copy of all LSAs in Link-State Database (LSDB) to form a graph of network
Run Dijkstra Algorithm to find shortest path to all links
Since all routers have same LSDB, all SPF calculations are loop-free

OSPF Routing Process

Step 1: Discovery of OSPF neighbors and exchange of topology in formation

1. OSPF uses Hello packets to discover neighbors on OSPF enabled attached links. Hellos in turn list
each routers Router ID (RID), which serves as each routers unique name or identifier for OSPF .
2. Hello packets contain attributes that neighbors must agree on to form adjacency, some of those
attributes are as follows:
Interface Area-ID
Hello and Dead Interval
Interface Network Address and Mask
Interface MTU
Network Type
Authentication
Stub Flags
Etc
3. Once adjacency is negotiated, LSDB is exchanged.

Before both routers can establish adjacency, both interfaces must be part of the same network,
including the same subnet mask.
Then full adjacency will happen after both routers have exchanged any necessary LSUs and have
identical link-state databases.

OSPF Adjacency States:

There are 8 different states to determine progress of adjacency establishment:
1. Down:
No hellos received from the neighbor
2. Attempt:
Used only for manually configured NBMA neighbors
Unicast hellos sent but no answer received
3. Init:
I received a hello packet from neighbor, but they havent acknowledge a hello from me
4. 2-way:
At this point, the following two major facts are true:
The router received a Hello from the neighbor, with that routers own RID listed as
being seen by the neighbor.
The router has checked all the parameters in the Hello received from the neighbor,
with no problems. The router is willing to become a neighbor.
As indicated by my RID in neighbors hello, I have received a hello from neighbor and they
have acknowledged a hello from me
5. ExStart:
First step of actual adjacency
Master and Slave relationship is formed, where master has a higher RID
6. Exchange:
Local LSDB is sent through DBD packets
DBD sequence number is used for reliable transmission
7. Loading:
Link-State Request (LSR) packets are sent for more information about some LSAs
After two routers decide to exchange databases, they do not simply send the contents of the
entire database. First, they tell each other a list of LSAs in their respective databasesnot all
the details of the LSAs, just a list. Then, each router can check which LSAs it already has, and
then ask the other router for only the LSAs that are not known yet.
8. Full:
Neighbors are fully adjacency and databases are fully synchronized

Step 2: Choose Best Path via SPF

After database synchronization path selection begins

When a router has received all the LSAs and built its local link-state database, OSPF uses Dijkstras
shortest path first (SPF) algorithm to create an SPF tree.
This algorithm accumulates costs along each path, from source to destination. The SPF tree is then
used to populate the IP routing table with the best paths to each network.
In the Figure below each path is labeled with an arbitrary value for cost. The cost of the shortest
path for R2 to send packets to the LAN attached to R3 is 27 (20 + 5 + 2 = 27).
This cost is not 27 for all routers to reach the LAN attached to R3. Each router determines its own
cost to each destination in the topology.
Each router uses the SPF algorithm to calculate the cost of each path to a network and determines
the best path to that network from its own perspective.

Step 3: Neighbor and Topology Maintenance

Once adjacency established and SPF build, OSPF tacks neighbor and topology changes
Hello packets are used to track neighbor changes and LSA fields to track topology changes.
Routers monitor each neighbor relationship using Hello messages and two related timers: The Hello
Interval and the Dead Interval (by default 4 times as long as the Hello Interval).
Routers must react when the topology changes as well, and neighbors play a key role in that
process. When something changes, one or more routers change one or more LSAs. Then, the routers
must flood the changed LSAs to each neighbor so that the neighbor can change its LSDB.
A third maintenance task done by neighbors is to reflood each LSA occasionally, even when the
network is completely stable. By default, each router that creates an LSA also has the responsibility
to reflood the LSA every 30 minutes (the default), even if no changes occur.
Each LSA has a separate timer, based on when the LSA was created, so there is no single big event
where the network is overloaded with flooding LSAs.
The following list summarizes these three maintenance tasks for easier review:
Maintain neighbor state by sending Hello messages based on the Hello Interval, and listening
for Hellos before the Dead Interval expires
Flood any changed LSAs to each neighbor
Reflood unchanged LSAs as their lifetime expires (default 30 minutes)

OSPF Passive Interface:

OSPF passive interface, tells the router to do the following:

Quit sending OSPF Hellos on the interface
Ignore received Hellos on the interface
Do not form neighbor relationships over the interface

By making an interface passive, OSPF does not form neighbor relationships over the interface, but it
does still advertise about the subnet connected to that interface.
Passive Interface is also used as a security measure.

OSPF Cost Based on Interface Bandwidth

IOS uses the following formula to choose an interfaces OSPF cost. IOS puts the interfaces bandwidth in the
denominator, and a settable OSPF value called the reference bandwidth in the numerator:
Reference_bandwidth / Interface_bandwidth
With this formula, a higher interface bandwidth is better. The higher (faster) the interface bandwidth, the
lower the calculated OSPF cost for the interface.
The lower the interface cost, the lower the metric for routes using that interface, and the more likely the
interface is used in a route chosen by SPF.
If the default reference bandwidth set to 100,000 Kbps, and defaults for interface
bandwidth on serial, Ethernet, and Fast Ethernet interfaces are respectively 1544 Kbps, 10,000 Kbps
(meaning 10 Mbps), and 100,000 Kbps (meaning 100 Mbps).
This is how IOS calculates the OSPF cost for those interfaces:

To change the OSPF cost on these interfaces use the bandwidth speed interface subcommand to set the
bandwidth on an interface.
The interface bandwidth does not change the Layer 1 transmission speed at all; instead, it is used for other
purposes, including routing protocol metric calculations.
For instance, if you add the bandwidth 10000 command to a serial interface, with a default reference
bandwidth, the serial interfaces OSPF cost could be calculated as
100,000 / 10,000 = 10.
You can change the reference bandwidth with the auto-cost reference-bandwidth speed OSPF mode
subcommand. This command sets a value in a unit of megabits per second (Mbps), set the reference
bandwidth value to match fastest link speed in the network. For instance, auto-cost referencebandwidth 10000 accommodates links up to 10 Gbps in speed.
Cisco recommends making the OSPF reference bandwidth setting the same on all OSPF routers in an
enterprise network.

The following list summarizes the rules for how a router sets its OSPF interface costs:
1- Set the cost explicitly, using the ip ospf cost x interface subcommand, to a value between 1 and
65,535, inclusive.
2- Change the interface bandwidth with the bandwidth speed command, with speed being a number
in kilobits per second(Kbps).
3- Change the reference bandwidth, using router OSPF subcommand auto-cost referencebandwidth ref-bw, with a unit of megabits per second (Mbps).

OSPF Areas

Larger OSPFv2 networks suffer in single area design although it can work but problems may arise
due to this.
Problems of using Single Area OSPF in a large Organization:

More CPU time is required to run SPF algorithm on topology data as a result convergence may
be slow
The routers may run low on ram
A larger topology database requires more memory on each router
Processing the larger topology database with the SPF algorithm requires processing power
that grows exponentially with the size of the topology database.
A single interface status change, anywhere in the internetwork (up to down, or down to up),
forces every router to run SPF again!
The solution is to take the one large LSDB and break it into several smaller LSDBs by using OSPF
areas.
With areas, each link is placed into one area. SPF does its complicated math on the topology inside
the area, and that areas topology only.
With multiple areas, an internetwork with 1000 routers and 2000 subnets, broken in 100 areas,
would average 10 routers and 20 subnets per area. The SPF calculation on a router would have to
only process topology about 10 routers and 20 links, rather than 1000 routers and 2000 links.
Generally, networks larger than a few dozen routers benefit from areas, and some documents over
the years have listed 50 routers as the dividing line at which network really should use areas.
OSPF area design should be as follows:
Put all interfaces connected to the same subnet inside the same area.
An area should be contiguous.
Some routers may be internal to an area, with all interfaces assigned to that single area.
Some routers may be ABRs, because some interfaces connect to the backbone area, and
some connect to non-backbone areas.
All non-backbone areas must connect to the backbone area (area 0) by having at least one
ABR connected to both the backbone area and the non-backbone area.

Some OSPF Multi-Area Design benefits are as follows:

The smaller per-area LSDB requires less memory.

Routers require fewer CPU cycles to process the smaller per-area LSDB with the SPF
algorithm, reducing CPU overhead and improving convergence time.
Changes in the network (for example, links failing and recovering) requires SPF calculations
only on routers connected to the area where the link changed state, reducing the number of
routers that must rerun SPF.
Less information must be advertised between areas, reducing the bandwidth required to send
LSAs.

Link-State Advertisements in Multi-Area Design

OSPF defines the first three types of LSAs as follows:

One router LSA for each router in the area
One network LSA for each network that has a DR plus one neighbor of the DR
One summary LSA for each subnet ID that exists in a different area

In some networks, both OSPF and other routing protocols are used. In that case, one or more routers
run both OSPF and the other routing protocol, with those routers acting as an OSPF Autonomous
System Border Router, or ASBR, redistributing routing information between OSPF and the other
protocol. In such a case, the ASBR creates a Type 4 LSA, which describes the ASBR itself, and Type 5
LSAs for each external route learned from the other routing protocol and then advertised into OSPF.

Router LSAs build most of the Intra-Area Topology:

OSPF needs very detailed topology information inside each area. The routers inside area X need to
know all the details about the topology inside area X. And the mechanism to give routers all these
details is for the routers to create and flood router (Type 1) and network (Type 2) LSAs about the
routers and links in the area.
Router LSAs, also known as Type 1 LSAs, describe the router in detail. It lists a routers RID, its
interfaces, its IPv4 addresses and masks, its interface state, and notes about what neighbors the
router knows out its interfaces.
Figure lists internetwork topology, with subnets listed. As a small internetwork, the engineer chose a
single-area design, with all interfaces in backbone area 0.

With the single-area design planned for this small internetwork, the LSDB will contain four router
LSAs.
Each router creates a router LSA for itself, with its own RID as the LSA identifier. The LSA lists that
routers own interfaces, IP address/mask, with pointers to neighbors.
Once all four routers have copies of all four router LSAs, SPF can mathematically analyze the LSAs to
create a model.
The model looks a lot like the concept drawing in Figure. Note that the drawing shows each router
with an obvious RID value. Each router has pointers that represent each of its interfaces, and
because the LSAs identify neighbors, SPF can figure out which interfaces connect to which other
routers.

Network LSAs Complete the Intra-Area Topology

Whereas router LSAs define most of the intra-area topology, network LSAs define the rest. As it turns
out, when OSPF elects a DR on some subnet and that DR has at least one neighbor, OSPF treats that
subnet as another node in its mathematical model of the network. To represent that network, the DR
creates and floods a network (Type 2) LSA for that network (subnet).
In Figure, one Ethernet LAN and one Ethernet WAN exists. The Ethernet LAN between R2 and R3 will
elect a DR, and the two routers will become neighbors; so, whichever router is the DR will create a
network LSA. Similarly, R1 and R4 connect with an Ethernet WAN, so the DR on that link will create a
network LSA.
Figure shows the completed version of the intra-area LSAs in area 0 with this design. Note that the
router LSAs actually point to the network LSAs when they exist, which lets the SPF processes
connect the pieces together.
The drawings in the last two figures work a little like a jigsaw puzzle. The SPF algorithm basically
solves the jigsaw puzzle, but by looking at all the numbers inside the different LSAs, to see which
LSAs fit next to which other LSAs.
Note that in this single-area design example no summary (Type 3) LSAs exist at all. These LSA
represent subnets in other areas, and there are no other areas. The next example shows some
summary LSAs.
LSAs in a Multi-Area Design

Migrating from a single-area design to a multi-area design has a couple of effects on LSAs:

Each area has a smaller number of router and network LSAs.

The ABRs have a copy of the LSDB for each area to which they connect.
The ABRs each have a router LSA in each areas LSDB.
Each area has a need for some summary (Type 3) LSAs to describe subnets in other areas.
Figure above begins this new example using the same internetwork topology as Figure before, but
now with a multi-area design, with router R1 as the only ABR.
Consider what router and network LSAs should be in the area 4 LSDB.
Inside an area, the LSDB should have router LSAs for routers inside the area, and network LSAs for
certain networks inside the area (those with a DR that has at least one neighbor).
The area 4 LSDB will include two router LSAs (for R1 and R4), plus one network LSA, for the network
between R1 and R4, as shown in Figure.
Now focus on the subnets in the entire internetwork for a moment. Breaking it down by area, we
have the following:
Three subnets in area 23
Two subnets in area 4
Two subnets in area 0
The routers inside area 4 need to know about the five subnets outside area 4, and to do that, the
ABR (R1) advertises summary LSAs into area 4.
Summary (Type 3) LSAs describes a subnet that sits in another area. First, it has to list the subnet ID
and mask to identify the specific subnet. The LSA also lists the RID of the ABR that creates and
advertises the summary LSA into the area. By identifying the ABR, from a topology perspective,
these subnets appear to be connected to the ABR. In this new example, ABR R1 creates and floods
the five Summary LSAs shown in the upper left of Figure.
Note that the OSPF summary LSA does not mean that the router is performing route summarization,
which is the process of taking multiple routes, for multiple subnets, and advertising them as one
route for a larger subnet.

OSPFv3 for IPv6

OSPFv3 and OSPFv2 behave very much like each other, OSPFv3 works much like OSPFv2 with regard
to:
Area design and the related terms.
The configuration idea of enabling the routing process, per interface, for an area.
The neighbor discovery process with Hello messages.
Transitioning through neighbor states and the topology exchange process.
The use of full and 2-way as the normal stable state for working neighbor relationships, with
other states being either temporary or pointing to some problem with the neighbor.
The general ideas behinds LSA Types 1, 2, and 3 and the link-state database (LSDB).
SPF and how it uses interface cost to calculate metrics.
Messages are sent to reserved multicast addresses (FF02::5 for all OSPF routers, FF02::6 for
all DR and BDR routers), similar to OSPFv2s use of 224.0.0.5 and 224.0.0.6.
Differences between the two:
The name of the Type 3 LSA.
That OSPFv3 neighbors do not have to have IPv6 addresses in the same IPv6 subnet, whereas
OSPFv2 neighbors must be in the same IPv4 subnet.
New LSA types used by OSPFv3 but not by OSPFv2 (also beyond scope).
The details defined inside LSA types 1, 2, and 3 differ.

OSPFv3 LSDB and LSAs

Once OSPFv3 routers become neighbors, they proceed to exchange their LSDBs over that subnet.
The two routers exchange their LSDBs directly, and when finished, each router lists its neighbor as
having reached a full state.
Once in a full state, the two routers should have the same link-state advertisements (LSA) for that
area.

Verifying OSPFv3 LSAs

OSPFv3 uses similar concepts, with slightly different naming for the equivalent of OSPFv2s Type 1,
2, and 3 LSAs.
OSPFv2 uses the Type 1 router LSA and Type 2 network LSA to define the topology inside an area.
The Type
3 summary LSA then describes for one area a subnet that exists in some other areaan inter-area
subnet, if you will, only these three types of LSAs are needed in the OSPFv2 LSDB.
OSPFv3 keeps those same three LSA concepts, renaming the summary LSA. The following list
summarizes these three key OSPFv3 LSA types and the reasons why OSPFv3 routers create each:
One router LSA (Type 1 LSA) for each router in the area (including ABRs attached to the area)
One network LSA (Type 2 LSA) for each network that has a DR plus one neighbor of the DR
One inter-area prefix (Type 3 LSA) LSA for each IPv6 prefix (subnet) that exists in a different area
In area 4 in the sample network used throughout this chapter, two routers exist: internal router R4
and ABR R1.
The area 4 LSDB will have a router LSA for each router. One network exists in this area for which a
DR will be used (the Ethernet WAN between R1 and R4).
R1 and R4 will become neighbors, as well, so one network LSA will be created for that network.
ABR R1 will know about five different IPv6 prefixes that exist outside area 4, so ABR R1 should create
and flood five inter-area prefix LSAs into area 4.
Figure shows the conceptual model of these LSAs for area 4.
Beyond this basic LSA structure, OSPFv3 does make several changes to LSAs compared to OSPFv2.
The details inside these LSAs change, and OSPFv3 adds several new LSA types not seen in OSPFv2.

Figure lists the beginning of the area 4 LSDB as it exists in router R4. The example highlights the
headings and the IPv6 prefixes of the inter-area prefix LSAs.
The output indeed shows two router LSAs, one line for the single network LSA and five lines with the
inter-area prefixes.

Enhanced Interior Gateway Routing Protocol

EIGRP converges quickly, meaning that when something changes in the internetwork, EIGRP quickly finds
the currently best loop-free routes to use.
RIP uses a basic metric of hop count, meaning the number of routers between the destination subnet and
the local router.
These metrics make RIP to choose a short route (fewest router hops away), even shorter routes with slow
links, so that route might not be the truly best route.
EIGRPs metric calculation uses a math formula that avoids routes with slow links by giving those routes
worse (higher) metrics.

EIGRP Features
Protocol-independent modules: EIGRP supports IP, IPv6, Internetwork Packet

Exchange (IPX), and AppleTalk.

Reliable Transport Protocol: RTP controls sending, tracking, and acknowledging updates
and EIGRP messages.
Neighbor discovery/recovery: EIGRP discovers neighboring devices using periodic
Hello messages.
Diffusing Update Algorithm (DUAL): EIGRP uses DUAL to calculate and maintain loop-free
paths and provide fast convergence.
Partial updates: EIGRP sends partial triggered updates instead of periodic updates.
EIGRP Terminology
Neighbor table: Lists all adjacent routers. Includes the neighbors address and the interface
through which it can be reached. EIGRP routers keep a neighbor table for each routed Layer 3
protocol (IP, IPX, AppleTalk).
Topology table: Contains all learned routes to a destination. The topology table holds all
successor and feasible successor routes in its table.
Routing table: Holds the best routes (the successor routes) to each destination.

EIGRP Path Calculation

DUAL uses distance information (metric) to select the best, loop-free path to a destination. It does
this by selecting a successor with the best feasible distance. A backup route, called the feasible
successor, is selected if the advertised distance is less than the feasible distance.
The following is a list of the terminology DUAL uses to select a route:
Successor: The primary route used to reach a destination. The successor route is kept in the
routing table.
Feasible successor: The backup route. Must have an AD less than the FD of the current
successor route.
Advertised distance (AD): The lowest-cost route between the next-hop router and the
destination.
Feasible distance (FD): The sum of the AD plus the cost between the local router and the
next-hop router.

EIGRP Message Format

Data field is called Type/Length/Value, or TLV. The types of TLVs are EIGRP Parameters, IP
Internal Routes, and IP External Routes.

The EIGRP packet header is included with every EIGRP packet, regardless of its TLV. The EIGRP
packet header and TLV are then encapsulated in an IP packet.
In the IP packet header, the protocol field is set to 88 to indicate EIGRP, and the destination address
is set to the multicast address of 224.0.0.10.
If the EIGRP packet is encapsulated in an Ethernet frame, the destination MAC address is also a
multicast address: 01-00-5E-00-00-0A.
Opcode specifies the EIGRP packet type. The autonomous system number specifies the EIGRP
routing process. Unlike RIP, Cisco routers can run multiple instances of EIGRP. The autonomous
system number is used to track multiple instances of EIGRP.
EIGRP Packet Header
Version

Opcode

Checksum

Flags
Sequence Number
Acknowledgment Number
Autonomous System Number
Type

Length
Value

Reliable Transport Protocol

Reliable Transport Protocol (RTP) is the protocol used by EIGRP for the delivery and reception of EIGRP
packets.
EIGRP was designed as a network layerindependent routing protocol; therefore, it cannot use the services
of UDP or TCP because IPX and AppleTalk do not use protocols from the TCP/IP protocol suite.
Although reliable is part of its name, RTP includes both reliable delivery and unreliable delivery of EIGRP
packets.
Reliable RTP requires an acknowledgment to be returned, whereas an unreliable RTP packet does not
require an acknowledgment.
RTP can send packets either as a unicast or a multicast. Multicast EIGRP packets use the reserved multicast
address of 224.0.0.10.

EIGRP Packet Types

EIGRP uses five packet types:

Hello:

Hello packets are used by EIGRP to discover neighbors and to form adjacencies with those neighbors.
EIGRP hello packets are multicasts and use unreliable delivery, so no response is required from the
recipient.
On most networks, EIGRP hello packets are sent every 5 seconds.
On multipoint non-broadcast multi-access (NBMA) networks such as X.25,
Frame Relay, and ATM interfaces with access links of T1 (1.544 Mbps) or slower, hellos are unicast every 60
seconds.
By default, the hold time is 3 times the hello interval, or 15 seconds on most networks and 180 seconds on
low-speed NBMA networks.
If the hold time expires, EIGRP declares the route as down, and DUAL searches for a new path in the
topology table or by sending out queries.

Update:
EIGRP does not send periodic updates. Update packets are sent only when necessary, contain only the
routing information needed, and are sent only to those routers that require it.
EIGRP update packets use reliable delivery. Update packets are sent as a multicast when required by
multiple routers, or as a unicast when required by only a single router.

Acknowledgement:
Acknowledgment (ACK) packets are sent by EIGRP when reliable delivery is used.
RTP uses reliable delivery for EIGRP update, query, and reply packets.

EIGRP acknowledgment packets are always sent as an unreliable unicast.

Query:
A query packet is used by DUAL when searching for networks.
Queries use reliable delivery and can use multicast or unicast.

Reply:
A reply packet is sent in response to a query packet regardless of whether the replying router has
information about the queried route.
Replies use reliable delivery and unlike queries, replies are always sent as unicast (never as multicast).

Diffusing Update Algorithm

Distance vector routing protocols such as RIP prevent routing loops with hold-down timers.
The primary way that EIGRP prevents routing loops is with the DUAL algorithm.
DUAL is used to obtain loop-freedom at every instant throughout a route computation. This allows all
routers involved in a topology change to synchronize at the same time.
Routers that are not affected by the topology changes are not involved in the recomputation because
queries and replies are bounded to only those routers that need or have the route-specific information. This
method provides EIGRP with faster convergence times than other distance vector routing protocols.
Because recomputation of DUAL can be processor intensive, it is advantageous to avoid recomputation
whenever possible. Therefore, DUAL maintains a list of backup routes it has already determined to be loopfree. If the primary route in the routing table fails, the best backup route is immediately added to the
routing table.

EIGRP Sends Partial Update Messages, As Needed

EIGRP sends information about each route once, when the router learns the information. Then, the router
sends only partial updates.
EIGRP partial updates are EIGRP update messages that list any new or changed information about a route.
The idea works a little like OSPFs convention of flooding an LSA once inside an area. However, the router
that creates an OSPF LSA does reflood that LSA every 30 minutes. EIGRP does not even bother to reflood its
routing information.
If the routing information about a route does not change for a year, EIGRP will literally remain silent about
that route in its update messages for that whole year after it first advertises the route.
EIGRP Maintains Neighbor Status Using Hello
The EIGRP Hello message and protocol defines that each router should send a periodic Hello message on
each interface, so that all EIGRP routers know that the router is still working.
The routers use their own independent Hello Interval, which defines the time period between each EIGRP
Hello. For instance, routers R1 and R2 do not have to send their Hellos at the same time.
Routers also must receive a Hello from a neighbor with a time called the Hold Interval, with a default setting
of four times the Hello Interval.
EIGRP does not require two neighboring routers to use the same Hello and hold timers.
The flexibility to use different settings on neighboring routers makes it possible to prevent the neighbors
from working properly. For instance, if R2 changes its Hello/Hold Intervals to 30/60, respectively, but R1
keeps its Hello/Hold Intervals of 5/15 seconds, R1 will believe R2 has failed on a regular basis.

EIGRP uses a three step model similar to OSPF when a router first joins a network. These steps each lead to
a list or table: the neighbor table, the topology table, and the routing table.
All these processes and tables lead toward building the IPv4 routes in the routing table, as follows:
1. Neighbor discovery:
EIGRP routers send Hello messages to discover potential neighboring EIGRP routers and perform
basic parameter checks to determine which routers should become neighbors.
Neighbors that pass all parameter checks are added to the EIGRP neighbor table.
2. Topology exchange:
Neighbors exchange full topology updates when the neighbor relationship comes up, and then only
partial updates as needed based on changes to the network topology.
The data learned in these updates is added to the routers EIGRP topology table.
3. Choosing routes:
Each router analyzes its respective EIGRP topology tables, choosing the lowest-metric route to reach
each subnet.
EIGRP places the route with the best metric for each destination into the IPv4 routing table.
Although the overall three-step process looks similar to OSPF, the details differ greatly, especially those
related to how OSPF uses LS logic to process topology data, whereas EIGRP does not.

EIGRP Neighbors
An EIGRP neighbor is another EIGRP-speaking router, connected to a common subnet, with which the router
is willing to exchange EIGRP topology information.
EIGRP uses EIGRP Hello messages, sent to multicast IP address 224.0.0.10, to dynamically discover
potential neighbors. A router learns of potential neighbors by receiving a Hello.
Routers perform some basic checking of each potential neighbor before that router becomes an EIGRP
neighbor. A potential neighbor is a router from which an EIGRP Hello has been received.
Then the router checks the following settings to determine whether the router should be allowed to
be a neighbor:
It must pass the authentication process if used.
It must use the same configured autonomous system number (which is a configuration
setting).
The source IP address used by the neighbors Hello must be in the same subnet as the local
routers interface IP address/mask.
The routers EIGRP K values must also match
EIGRP uses relatively straightforward verification checks for neighbors:
First, if authentication is configured, the two routers must be using the same type of
authentication and the same authentication key (password).
Second, EIGRP configuration includes a parameter called an autonomous system number
(ASN), which must be the same on two neighboring routers.

Third, the IP addresses used to send the EIGRP Hello messagesthe routers respective
interface IP addressesmust be in the range of addresses on the other routers respective
connected subnet.

OSPF neighbors have several interim states and a few stable states, EIGRP simply moves to a working state
as soon as the neighbor passes the basic verification checks. At that point, the two routers can begin
exchanging topology information using EIGRP update messages.

Exchanging EIGRP Topology Information

EIGRP uses EIGRP update messages to send topology information to neighbors.
These update messages can be sent to multicast IP address 224.0.0.10 if the sending router needs to
update multiple routers on the same subnet; otherwise, the updates are sent to the unicast IP address of
the particular neighbor.
Hello messages are always sent to the 224.0.0.10 multicast address.
The use of multicast packets on LANs allows EIGRP to exchange routing information with all neighbors on
the LAN efficiently.
EIGRP sends update messages without UDP or TCP, but it does use a protocol called Reliable Transport
Protocol (RTP).
RTP provides a mechanism to resend any EIGRP messages that are not received by a neighbor.
By using RTP, EIGRP can better avoid loops because a router knows for sure that the neighboring router has
received any updated routing information.
Neighbors use both full routing updates and partial updates A full update means that a router sends
information about all known routes, whereas a partial update includes only information about recently
changed routes.
Full updates occur when neighbors first come up. After that, the neighbors send only partial updates in
reaction to changes to a route.

EIGRP refers to the information exchanged in the updates as topology information. The information is not
nearly as detailed as OSPF LS topology data, and it does not attempt to describe every router and link in
the network. However, it does describe more than just a distance (metric) and vector (next-hop router) for
the local routera local router also learns the metric as used by the next-hop router. This added information
is used to help EIGRP converge quickly, without causing loops.

Calculating the Best Routes for the Routing Table

EIGRP calculates the metric for routes much differently than any other routing protocol.
With OSPF, anyone with a network diagram and knowledge of the configured OSPF interface costs can
calculate the exact OSPF metric (cost) for each route. EIGRP uses a math equation and a composite metric,
making the exact metric value hard to predict.

The EIGRP Metric Calculation

The EIGRP composite metric means that EIGRP feeds multiple inputs (called metric components) into the
math equation.

By default, EIGRP feeds two metric components into the calculation: bandwidth and delay.
EIGRP supports also using the interface load and interface reliability in the metric calculation, although
Cisco recommends against using either.
EIGRP also advertises the maximum transmission unit (MTU) associated with the routethat is, the longest
IP packet allowed over the routebut does not use the MTU when calculating the metric.
Past documents and books often stated that EIGRP, and its predecessor, IGRP, also could use MTU as a part
of the metric, but MTU cannot be used and was never considered as part of the calculation.
EIGRPs metric calculation formula actually helps describe some of the key points about the composite
metric.
The formula, assuming that the default settings that tell the router to use just bandwidth and delay, is as

follows:
In this formula, the term least-bandwidth represents the lowest-bandwidth link in the route, using a unit of
kilobits per second, if the slowest link in a route is a 10-Mbps Ethernet link, the first part of the formula is
107 / 104, which equals 1000. You use 104 in the formula because 10 Mbps is equal to 10,000 Kbps (104
Kbps).
The cumulative-delay value used in the formula is the sum of all the delay values for all outgoing interfaces
in the route, with a unit of tens of microseconds.
Delay part of the equation adds the delay for every link, so that routes with a large number of links will be
relatively less desirable than a route with fewer links.
You can set both bandwidth and delay for each link, using the cleverly named bandwidth and delay
interface subcommands.
Most show commands, including show ip eigrp topology and show interfaces, list delay settings as the
number of microseconds of delay, the EIGRP metric formula uses a unit of tens of microseconds.

Caveats with Bandwidth on Serial Links

Serial links default to a bandwidth of 1544 and a delay of 20,000 microseconds.
IOS cannot automatically change the bandwidth and delay settings based on the Layer 1 speed of a serial
link. So, using default bandwidth and delay settings, particularly the bandwidth setting on serial links, can
lead to problems.
Figure shows the problem with using default bandwidth settings and how EIGRP uses the better (faster)
route when the bandwidth is set correctly.
The figure focuses on router Bs route to subnet 10.1.1.0/24 in each case.
In the left side of the figure, all serial interfaces use defaults, even though the top serial link actually runs at
a slow 64 Kbps. The right side of the figure shows the results when the slow serial links bandwidth
command is changed to reflect the correct (slow) speed.

A good metric strategy for networks that use EIGRP is to set the WAN bandwidth to match the actual Layer
1 speed, use defaults for LAN interfaces, and EIGRP will usually choose the best routes.

EIGRP Convergence
Loop avoidance poses one of the most difficult problems with any dynamic routing protocol. DV protocols
overcome this problem with a variety of tools, some of which create a large portion of the minutes-long
convergence time after a link failure.
LS protocols overcome this problem by having each router keep a full topology of the network, so by
running a rather involved mathematical model, a router can avoid any loops.
EIGRP avoids loops by keeping some basic topological information, while keeping much less information as
compared to LS protocols like OSPF.
EIGRP keeps a record of each possible next-hop router for alternate routes, and some metric details related
to those routes, but no information about the topology beyond the next-hop routers.
This topology information does not require the sophisticated shortest path first (SPF) algorithm, but it does
allow quick convergence to loop-free routes.

Feasible Distance and Reported Distance

EIGRP, a local router needs to consider its own calculated metric for each route, but at the same time, the
local router considers the next-hop routers calculated metric for that same destination subnet. And EIGRP
has special terms for those metrics, as follows:
Feasible Distance (FD): The local routers metric of the best route to reach a subnet, as calculated on the
local router
Reported Distance (RD): The next-hop routers best metric for that same subnet
Using the same advertisement as in earlier Figure shows the two calculations done by R1. One calculation
finds R1s own metric (FD) for its one route for subnet 10.1.3.0/24.
The other uses the metric components in the update received from R2, to calculate what R2 would have
calculated for R2s metric to reach this same subnet.
R1s second calculation based on R2s informationa slowest bandwidth of 100,000 Kbps and a cumulative
delay of 100 microsecondsis R1s RD for this route.

Following the steps in the figure:

1. R2 calculates its own metric (its FD) for R2s route for 10.1.3.0/24, based on a bandwidth of 100,000
Kbps and a delay of 100 microseconds.
2. R2 sends the EIGRP update that lists 10.1.3.0/24, with these same metric components.
3. R1 calculates the RD for this route, using the same math R2 used at Step 1, using the information in the
update message from Step 2.
4. R1 calculates its own metric, from R1s perspective, by considering the bandwidth and delay of R1s S0/1
interface.
The decision of whether a router has a feasible successor route depends on the FD and RD values of the
competing routes to reach a given subnet.

EIGRP Successors and Feasible Successors

EIGRP calculates the metric for each route to reach each subnet. For a particular subnet, the route with the
best metric is called the successor, with the router filling the IP routing table with this successor route, this
successor routes metric is called the feasible distance
Of the other routes to reach that same subnetroutes whose metrics were larger than the FD for the
successor routeEIGRP needs to determine which alternate route can be used immediately if the currently
best route fails, without causing a routing loop.
EIGRP runs a simple algorithm to identify which routes could be used, keeping these loop-free backup
routes in its topology table and using them if the currently best route fails. These alternative, immediately
usable routes are called feasible successor routes because they can feasibly be used as the new successor
route when the previous successor route fails.
A router determines whether a route is a feasible successor based on the feasibility condition:
If a nonsuccessor routes RD is less than the FD, the route is a feasible successor route.
Router E chooses its best route to subnet 1. Router E learns three routes to subnet 1, from Routers B, C, and
D. The figure shows the metrics as calculated on router E, as listed in router Es EIGRP topology table.
Router E finds that the route through Router D has the lowest metric, making that route Es successor route
for subnet 1. Router E adds that route to its routing table, as shown. The FD is the metric calculated for this
route, a value of 14,000 in this case.

At the same time, EIGRP on router E decides whether either of the other two routes to subnet 1 can be used
immediately if the route through router D fails for whatever reason.
Only a feasible successor route can be used. To meet the feasibility condition, the alternate routes RD must
be less than the FD of the successor route. Figure below shows an updated version of
Figure above. Router E uses the following logic to determine that the route through router B is not a feasible
successor route, but the route through router C is, as follows:
Router E compares the FD of 14,000 to the RD of the route through B (19,000). The RD is worse than the
FD, so this route is not a feasible successor.
Router E compares the FD of 14,000 to the RD of the route through C (13,000). The RD is better than the
FD, making this route a feasible successor.

If the route to subnet 1 through router D fails, Router E can immediately put the route through router C into
the routing table without fear of creating a loop. Convergence occurs almost instantly in this case.

The Query and Reply Process

When a route fails, and the route has no feasible successor, EIGRP uses a distributed algorithm called
Diffusing Update Algorithm (DUAL) to choose a replacement route.
DUAL sends queries looking for a loop-free route to the subnet in question.
When the new route is found, DUAL adds it to the routing table.
The EIGRP DUAL process simply uses messages to confirm that a route exists, and would not create a loop,
before deciding to replace a failed route with an alternative route.
Imagine that both Routers C and D fail. Router E does not have any remaining feasible successor route for
subnet 1, but there is an obvious physically available path through Router B.
To use the route, Router E sends EIGRP query messages to its working neighbors (in this case, Router B).
Router Bs route to subnet 1 is still working fine, so router B replies to Router E with an EIGRP reply
message, simply stating the details of the working route to subnet 1 and confirming that it is still viable.
Router E can then add a new route to subnet 1 to its routing table, without fear of a loop.
Replacing a failed route with a feasible successor takes a very short amount of time, usually less than a
second or two. When queries and replies are required, convergence can take slightly longer, but in most
networks, convergence can still occur in less than 10 seconds.

Autosummarization and Discontiguous Classful Networks

Older routing protocols, namely RIP-1 and IGRP, were classified as classful routing protocols. This term
comes from the fact that these classful routing protocols had to pay more attention to details about Class A,
B, and C networks.
These older classful routing protocols also had to use a more careful and cautious subnet design plan to
avoid a problem called a discontiguous classful network.
These simpler old routing protocols just got confused when a classful network became discontiguous,
because of a required feature of classful routing protocols called autosummarization.

Automatic Summarization at the Boundary of a Classful Network

A routing protocol that uses auto-summary automatically creates a summary route under certain
conditions. In particular, when a router sits at the boundary between classful networksthat is, with some
interfaces in one Class A, B, or C network and other interfaces in another Class A, B, or C networkthe
router summarizes routes.
Routes from one classful network are summarized as one route to the entire Class A, B, or C network.
Routes related to subnets in network X, when advertised out an interface whose IP address is not in network
X, are summarized and advertised as one route. That route is for the entire Class A, B, or C network X.
Figure shows two networks in use: 10.0.0.0 and 172.16.0.0. R3 has four (connected) routes to subnets of
network 10.0.0.0 on the right, and one interface on the left connected to a different classful network, class
B network 172.16.0.0. As a result, R3, with autosummary enabled, will summarize a route for all of class A
network 10.0.0.0.

Lets follow the steps in the figure:

1. R3 has autosummary enabled, with the EIGRP autosummary router subcommand.

2. R3 advertises a route for all of Class A network 10.0.0.0, instead of advertising routes for each subnet
inside network 10.0.0.0 because the link to R2 is a link in another network (172.16.0.0).
3. R2 learns one route in network 10.0.0.0: A route to 10.0.0.0/8, which represents all of network 10.0.0.0,
with R3 as the next-hop router.

Discontiguous Classful Networks

Autosummarization does not cause any problems as long as the summarized network is contiguous rather
than discontiguous.
U.S. residents can appreciate the concept of a discontiguous network based on the common term
contiguous 48, referring to the 48 U.S. states besides Alaska and Hawaii. To drive to Alaska from the
contiguous 48, for example, you must drive through another country (Canada, for the geographically
impaired), so Alaska is not contiguous with the 48 states. In other words, it is discontiguous.
Contiguous network: A classful network in which packets sent between every pair of subnets can pass
only through subnets of that same classful network, without having to pass through subnets of any other
classful network
Discontiguous network: A classful network in which packets sent between at least one pair of subnets
must pass through subnets of a different classful network
In this design, some subnets of network 10.0.0.0 sit off R1 on the left, whereas others still connect to R3 on
the right. Packets passing between subnets on the left to subnets on the right must pass through subnets of

Class B network 172.16.0.0

Autosummarization causes problems in that routers like R2 that sit totally outside the discontiguous
network become totally confused about how to route packets to the discontiguous network.
As shown in Example, R2 now has two routes to network 10.0.0.0/8: one pointing left toward R1 and one
pointing right toward R3. R2 simply uses its usual load-balancing logic, because as far as R2 can tell, the
two routes are simply equal-cost routes to the same destination: the entire network 10.0.0.0. Sometimes R2
happens to forward a packet toward the correct destination, and sometimes not.
This problem has two solutions. The old-fashioned solution is to create IP addressing plans that do not
create discontiguous classful networks. The other: Just do not use autosummary, by using EIGRP defaults, or
by disabling it with the noautosummary EIGRP subcommand.
the no autosummary command configured on routers R1 and R3.

Dynamic Host Configuration Protocol

The vast majority of hosts in a TCP/IP network are user devices, and the vast majority of user devices learn
their IPv4 settings using DHCP.
Using DHCP has several advantages over using manually or statically configured IPv4 settings:
The configuration of host IP settings sits in a DHCP server, with the client learning these settings using
DHCP messages.
The host IP configuration is controlled by the IT staff, which cuts down on user errors.
DHCP allows both the permanent assignment of host addresses and temporary lease of IP addresses.
DHCP server can reclaim IP addresses when a device is removed from the network, making better use of
the available addresses.
DHCP also enables mobility, every time a user moves to a new location with a tablet computerto a coffee
shop, a client location, or back at the officethe users device can connect to the wireless LAN, use DHCP
to lease a new IP address, and begin working on the new network. Without DHCP, the user would have to

ask for information about the local network, configure settings manually, with more than a few users
making mistakes.
In some enterprise networks, that router configuration can be a single command on many of the routers
LAN interfaces (ip helper-address server-ip), which identifies the DHCP server by its IP address.

DHCP Protocol Messages and Addresses

The host acts as a DHCP client. As DHCP client, the host begins with no IPv4 settings: no IPv4 address, no
mask, no default router, and no DNS server IP addresses. But a DHCP client does have knowledge of the
DHCP protocol.
The client can use that protocol to
(a) Discover a DHCP server and
(b) Request to lease an IPv4 address.
The DHCP process to lease an IP address uses the following four messages between the client and server:
Discover: Sent by the DHCP client to find a willing DHCP server
Offer: Sent by a DHCP server to offer to lease to that client a specific IP address (and inform the client of its
other parameters)
Request: Sent by the DHCP client to ask the server to lease the IPv4 address listed in the Offer message
Acknowledgment: Sent by the DHCP Server to assign the address, and to list the mask, default router,
and DNS server IP addresses
DHCP clients have a unique problem: they do not have an IP address yet, but they need to send IP packets.
To make that work, DHCP messages make use of two special IPv4 addresses that allow a host that has no IP
address still be able to send and receive messages on the local subnet:
0.0.0.0: An address reserved for use as a source IPv4 address for hosts that do not yet have an IP address.
255.255.255.255: The address reserved as a local subnet broadcast address. Packets sent to this
destination address are broadcast on the local data link, but routers do not forward them to other subnets.
Figure shows an example of the IP addresses used between a host A and a DHCP server on the same LAN.
Host A, a client, sends a Discover message, with source IP address of 0.0.0.0 because host A does not have
an IP address to use yet. Host A sends the packet to destination 255.255.255.255, which is sent in a LAN
broadcast frame, reaching all hosts in the subnet. The client hopes that there is a DHCP server on the local
subnet. Why? Packets sent to 255.255.255.255 only go to hosts in the local subnet; Router R1 will not
forward this packet.

Figure shows just one example of the addresses that can be used, specifically when the DHCP client
chooses to use a DHCP option called the broadcast flag.
The server sets the destination IP address to 255.255.255.255 again, because Host A still does not have an
IP address, so the server cannot send a packet directly to host A. So, the server sends the packet to all
hosts on the local subnet (255.255.255.255), a packet that is also encapsulated in an Ethernet broadcast
frame. Host A will be able to receive and process the message. (Other hosts receive and ignore the
message.)
Once the four messages are complete, the DHCP client has an IP address, plus its other IPv4 settings, and it
can send unicast IP packets as normal.

Supporting DHCP for Remote Subnets with DHCP Relay

Many enterprise networks use a couple of DHCP servers at a centralized site, supporting DHCP services to
all remote subnets, the routers need to somehow forward those DHCP messages between clients and the
DHCP server.

To make that work, the routers connected to the remote LAN subnets need an interface subcommand: the
ip helper-address server-ip command.
The ip helper-address server-ip subcommand tells the router to do the following for the messages coming
in an interface, from a DHCP client:
1. Watch for incoming DHCP messages, with destination IP address 255.255.255.255.
2. Change that packets source IP address to the routers incoming interface IP address.
3. Change that packets destination IP address to the address of the DHCP server (as configured in the ip
helper-address command).
4. Route the packet to the DHCP server.
This feature, by which a route relays DHCP messages by changing the IP addresses in the packet header, is
called DHCP relay.
Host A sits on the left, as a DHCP client. The DHCP server (172.16.2.11) sits on the right. R1 has an ip
helper-address 172.16.2.11 command configured, under its G0/0 interface. At Step 1, Router R1 notices
the incoming DHCP packet destined for 255.255.255.255. Step 2 shows the results of changing both the
source and destination IP address, with R1 routing the packet.

The router uses a similar process for the return DHCP messages from the server. First, for the return packet
from the DHCP server, the server simply reverses the source and destination IP address of the packet
received from the router (relay agent).
For example the Discover message lists source IP address 172.16.1.1, so the server sends the Offer
message back to destination IP address 172.16.1.1.
When a router receives a DHCP message, addressed to one of the routers own IP addresses, the router
realized the packet might be part of the DHCP relay feature. When that happens, the DHCP relay agent
(Router R1) needs to change the destination IP address, so that the real DHCP client (host A), which does
not have an IP address yet, can receive and process the packet.
When R1 receives the DHCP Offer message sent to R1s own 172.16.1.1 address. R1 changes the packets
destination to 255.255.255.255, and forwards it out G0/0, knowing that all hosts (including the DHCP client
A) will receive the message.

Information Stored at the DHCP Server

To be ready to answer DHCP clients, and to supply them with an IPv4 address and other information, the
DHCP server (software) needs information. DHCP servers typically organize these IPv4 settings per subnet,
because the information the server tells the client is usually the same for all hosts in the same subnet. For
example, IP addressing rules tell us that all hosts on the same subnet should use the same mask.
The following list shows the types of settings the DHCP server needs to know to support DHCP clients:
Subnet ID and mask: The DHCP server can use this information to know all addresses in the subnet.
Usually, unless reserved or excluded, the server believes that it can lease any and all valid addresses in the
subnet. (The DHCP server knows to not lease the subnet ID or subnet broadcast address.)
Reserved (excluded) addresses: The server needs to know which addresses in the subnet to not lease.
This list allows some addresses to be reserved for assignment as statically assigned IP addresses.
Default router(s): This is the IP address of the router on that subnet.
DNS IP Address(es): This is a list of DNS server IP addresses, Figure shows the concept behind the preconfiguration on a DHCP server for two LAN-based subnets, 172.16.1.0/24 and 172.16.2.0/24. The DHCP
server sits on the right. For each subnet, the server defines all the items in the list. In this case, the
configuration reserves the lowest IP addresses in the subnet to be used as static addresses.

The configuration can list other parameters, it can set the time limit for leasing an IP address. The server
leases an address for a time (usually a number of days), and then the client can ask to renew the lease. If
the client does not renew, the server can reclaim the IP address and put it back in the pool of available IP
addresses. The server configuration sets the maximum time for the lease.

Network Address Translation

NAT, defined in RFC 3022, allows a host that does not have a valid, registered, globally unique IP address to
communicate with other hosts through the Internet. The hosts might be using private addresses or
addresses assigned to another organization.
NAT allows these addresses that are not Internet ready to continue to be used and still allows
communication with hosts across the Internet.
NAT achieves its goal by using a valid registered IP address to represent the private address to the rest of
the Internet. The NAT function changes the private IP addresses to publicly registered IP addresses inside

each IP packet.
Router, performing NAT, changes the packets source IP address when the packet leaves the private
organization. The router also changes the destination address in each packet that is forwarded back into the
private network. (Network 200.1.1.0 is a registered network in Figure) The NAT feature, configured in the
router labeled NAT, performs the translation.

Static NAT

Static NAT works just like the example shown in Figure, but with the IP addresses statically mapped to each
other.

The companys ISP has assigned it registered network 200.1.1.0. Therefore, the NAT router must make the
private IP addresses look like they are in network 200.1.1.0.
To do so, the NAT router changes the source IP addresses in the packets going from left to right in the
figure, the NAT router changes the source address (SA in the figure) of 10.1.1.1 to 200.1.1.1. With static
NAT, the NAT router simply configures a one-to-one mapping between the private address and the
registered address that is used on its behalf.
The NAT router has statically configured a mapping between private address 10.1.1.1 and public, registered
address 200.1.1.1.
Supporting a second IP host with static NAT requires a second static one-to-one mapping using a second IP
address in the public address range.
To support 10.1.1.2, the router statically maps 10.1.1.2 to 200.1.1.2. Because the enterprise has a single
registered Class C network, it can support at most 254 private IP addresses with NAT, with the usual two
reserved numbers (the network number and network broadcast address).
NAT table lists the private IP addresses as private and the public, registered addresses from network
200.1.1.0 as public.
Cisco calls the private IP address used in the inside network the inside local address and the address used
to represent the host to the rest of the Internet the inside global address.

Dynamic NAT
Like static NAT, the NAT router creates a one-to-one mapping between an inside local and inside global
address, and changes the IP addresses in packets as they exit and enter the inside network. However, the
mapping of an inside local address to an inside global address happens dynamically.
Dynamic NAT sets up a pool of possible inside global addresses and defines matching criteria to determine
which inside local IP addresses should be translated with NAT.

1. Host 10.1.1.1 sends its first packet to the server at 170.1.1.1.

2. As the packet enters the NAT router, the router applies some matching logic to decide whether the
packet should have NAT applied. Because the logic has been configured to match source IP addresses that
begin with 10.1.1, the router adds an entry in the NAT table for 10.1.1.1 as an inside local address.
3. The NAT router needs to allocate an IP address from the pool of valid inside global addresses. It picks the
first one available (200.1.1.1, in this case) and adds it to the NAT table to complete the entry.
4. The NAT router translates the source IP address and forwards the packet.
The dynamic entry stays in the table as long as traffic flows occasionally. You can configure a timeout value
that defines how long the router should wait, having not translated any packets with that address, before
removing the dynamic entry. You can also manually clear the dynamic entries from the table using the
clear ip nat translation * command.
NAT can be configured with more IP addresses in the inside local address list than in the inside global
address pool. The router allocates addresses from the pool until all are allocated. If a new packet arrives
from yet another inside host, and it needs a NAT entry, but all the pooled IP addresses are in use, the router
simply discards the packet.
The user must try again until a NAT entry times out, at which point the NAT function works for the next host
that sends a packet.
The inside global pool of addresses needs to be as large as the maximum number of concurrent hosts that
need to use the Internet at the same timeunless you use PAT.
Overloading NAT with Port Address Translation (PAT)
With static NAT, for each private IP host that needs Internet access, you need a publicly registered IP
address, completely defeating the goal of reducing the number of public IPv4 addresses needed for that
organization.
Dynamic NAT lessens the problem to some degree, because every single host in an internetwork should
seldom need to communicate with the Internet at the same time.
However, if a large percentage of the IP hosts in a network will need Internet access throughout that
companys normal business hours, NAT still requires a large number of registered IP addresses, again failing
to reduce IPv4 address consumption.
The NAT Overload feature, also called Port Address Translation (PAT), solves this problem. Overloading
allows NAT to scale to support many clients with only a few public IP addresses.
The key to understanding how overloading works is to recall how hosts use TCP and User Datagram Protocol
(UDP) ports.
First consider the idea of three separate TCP connections to a web server, from three different hosts.

Next, compare those three TCP connections in Figure above to three similar TCP connections, now with all
three TCP connections from one client, as shown in Figure below.

The server does realize a difference, because the server see the IP address and TCP port number used by
the clients in both figures.
The server really does not care whether the TCP connections come from different hosts, or the same host;
the server just sends and receives data over each connection.

NAT
takes advantage of the fact
that, from a transport layer perspective, the server doesnt care whether it has one connection each to
three different hosts or three connections to a single host IP address.
NAT overload (PAT) translates not only the address, but the port number when necessary, making what
looks like many TCP or UDP flows from different hosts look like the same number of flows from one host.

When PAT creates the dynamic mapping, it selects not only an inside global IP address but also a unique
port number to use with that address.
The NAT router keeps a NAT table entry for every unique combination of inside local IP address and port,
with translation to the inside global address and a unique port number associated with the inside global
address.
Because the port number field has 16 bits, NAT overload can use more than 65,000 port numbers, allowing
it to scale well without needing many registered IP addressesin many cases, needing only one inside
global IP address.

First Hop Redundancy Protocols

FHRPs allow network engineers to install multiple routers in a subnet, which collectively act as a single
default router.
The FHRP makes the routers appear like a single default router to the hosts, letting the hosts be completely
unaware of the redundant routers while receiving the benefits of that redundancy.
The routers exchange messages to coordinate which router does the work and how to recognize a router
problem and take over the function of the other router when needed.
First Hop Redundancy Protocol (FHRP) refers to the category of protocols that can be used so that the hosts
take advantage of redundant routers in a subnet.

The Need for Redundancy in Networks

Networks need redundant links to improve the availability of the network. Eventually, something in the
network will fail. A router power supply might fail, or a cable might break, or a switch might lose power.
Depending on the design of the network, the failure of a single component might mean an outage that
affects at least some part of the user population. Network engineers refer to any one component that, if it
fails, brings down that part of the network as a single point of failure. Figure below removes all the single
points of failure.

The Need for a First

Protocol

Hop Redundancy

While having the redundant routers on the same subnet helps, the network needs to use an FHRP when
these redundant routers exist.
To see the need and benefit of using an FHRP, first think about how these redundant routers could be used
as default routers by the hosts in VLAN 10/subnet 10.1.1.0/24. The host logic will remain unchanged, so
each host has a single default router setting.
Some design options for default router settings include the following:
All hosts in the subnet use R1 (10.1.1.9) as their default router, and they statically reconfigure their default
router setting to R2s 10.1.129 if R1 fails.
All hosts in the subnet use R2 (10.1.1.129) as their default router, and they statically reconfigure their
default router setting to R1s 10.1.1.9 if R2 fails.
Half the hosts use R1, and half use R2, as default router, and if either router fails, that half of the users
statically reconfigure their default router setting.
The figure removes all the LAN switches just to unclutter the figure. Hosts A and B use R1 as default router,
and hosts C and D use R2 as default router.
All of these options have a problem: The users have to take action. They have to know an outage occurred.
They have to know how to reconfigure their default router setting. And they have to know when to change it
back to the original setting.
FHRPs make this design work better. The two routers appear to be a single default router. The users never
have to do anything: Their default router setting remains the same, and their ARP table even remains the
same.
To allow the hosts to remain unchanged, the routers have to do some more work, as defined by one of the
FHRP protocols.
Generically, each FHRP makes the following happen:
1. All hosts act like they always have, with one default router setting that never has to change.
2. The default routers share a virtual IP address in the subnet, defined by the FHRP.
3. Hosts use the FHRP virtual IP address as their default router address.
4. The routers exchange FHRP protocol messages, so that both agree as to which router does what work at
any point in time.
5. When a router fails, or has some other problem, the routers use the FHRP to choose which router takes
over responsibilities from the failed router.

The Three Solutions for First-Hop Redundancy

The term First Hop Redundancy Protocol does not name any one protocol. Instead, it names a family of
protocols that fill the same role.
First Hop is a reference to the default router being the first router, or first router hop, through which a
packet must pass.
Table lists the three FHRP protocols in chronological order, based on when these were first used. Cisco first
introduced the proprietary Hot Standby Router Protocol (HSRP), and it worked well for many of their
customers. Later, the IETF developed an RFC for a very similar protocol, Virtual Router Redundancy Protocol
(VRRP). Finally, Cisco developed a more robust option, Gateway Load Balancing Protocol (GLBP).

HSRP Concepts
HSRP operates with
an active/standby model
(also more generally called active/passive).
HSRP allows two (or more) routers to cooperate, all being willing to act as the default router.
At any one time, only one router actively supports the end user traffic.
The packets sent by hosts to their default router flow to that one active router then the other routers with
an HSRP standby state, sit there patiently waiting to take over should the active HSRP router have a
problem.
The HSRP active router implements a virtual IP address and matching virtual MAC address.
This virtual IP address exists as part of the HSRP configuration, which is an additional configuration item
compared to the usual ip address interface subcommand.
This virtual IP address is in the same subnet as the interface IP address, but it is a different IP address. The
router then automatically creates the virtual MAC address.
All the cooperating HSRP routers know these virtual addresses, but only the HSRP active router uses these
addresses at any one point in time.
Hosts refer to the virtual IP address as their default router address, instead of any one routers interface IP
address.
R1 and R2 use HSRP. The HSRP virtual IP address is 10.1.1.1, with the virtual MAC address referenced as
VMAC1 for simplicitys sake.

HSRP Failover
The two routers need HSRP configuration, including the virtual IP address. The two routers send HSRP
messages to each other to negotiate and decide which router should currently be active, and which should
be standby.
Then, the two routers continue to send messages to each other so that the standby router knows when the
active router fails so that it can take over as the new active router.
R1, the HSRP active router fails. R1 quits using the virtual IP and MAC address, while R2, the new active
router, starts using these addresses. The hosts do not need to change their default router settings at all,
with traffic now flowing to R2 instead of R1.

When the failover happens, some changes do happen, but none of those changes happen on the hosts. The
host keeps the same default router setting, set to the virtual IP address (10.1.1.1 in this case). The hosts

ARP table does not have to change either, with the HSRP virtual MAC being listed as the MAC address of the
virtual router.
When the failover occurs, changes happen on both the routers and the LAN switches. Clearly, the new
active router has to be ready to receive packets (encapsulated inside frames) using the virtual IP and MAC
addresses. However, the LAN switches, hidden in the last few figures, formerly sent frames destined for
VMAC1 to router R1. Now the switches must know to send the frames to the new active router, R2.
To make the switches change their MAC address table entries for VMAC1, R2 sends an Ethernet frame with
VMAC1 as the source MAC address. The switches, as normal, learn the source MAC address (VMAC1), but
with new ports that point toward R2.
The frame is also a LAN broadcast, so all the switches learn a MAC table entry for VMAC1 that leads toward
R2.
This Ethernet frame holds an ARP Reply message, called a gratuitous ARP, because the router sends it
without first receiving an ARP Request.

HSRP Load Balancing

The active/standby model of HSRP means that in one subnet all hosts send their off-subnet packets through
only one router.
Routers do not share the workload, with one router handling all the packets.
R1 was the active router, so all hosts in the subnet sent their packets through R1, and none of the hosts in
the subnet sent their packets through R2.
HSRP does support load balancing by preferring different routers to be the active router in different subnets.
HSRP can be configured to prefer one router as active in one VLAN, and another router as active in another
VLAN, balancing the traffic.
Figure below shows a redesigned LAN, now with two hosts in VLAN 1 and two hosts in VLAN 2. Both R1 and
R2 connect to the LAN, and both use a VLAN trunking and router-on-a-stick (ROAS) configuration. Both
routers use HSRP in each of the two subnets, supporting each other. However, on purpose, R1 has been
configured so that it wins the negotiation to become HSRP active in VLAN 1, and R2 has been configured to

win in VLAN 2.
By having each router act as the HSRP active router in some subnets, the design makes use of both routers
and both WAN links.
For designs that use Layer 3 switches, the Layer 3 switches act as the default router of the hosts. In that
case, the HSRP configuration goes on the Layer 3 switch.

GLBP Concepts
HSRP and VRRP, which were introduced before Gateway Load Balancing Protocol (GLBP), balanced the
packet load per subnet.
Because traffic loads vary unpredictably from subnet to subnet, Cisco wanted an FHRP option with better
load-balancing options than just the per-subnet load balancing of HSRP and VRRP. To meet that need, Cisco
introduced GLBP.
GLBP balances the packet load per host by using an active/active model in each subnet. Each GLBP router
in a subnet receives off-subnet packets from some of the hosts in the subnet. Each host still remains

unaware of the FHRP, allowing the hosts to configure the same default gateway/router setting and for the
hosts to make no changes when a router fails.
GLBP creates a world that at first glance looks like HSRP, but with a few twists that let GLBP balance the
traffic. Like HSRP, all the routers configure a virtual IP address, which is the IP address used by hosts as
their default router.
Like with HSRP, hosts use a default router setting that points to the virtual IP address, and that setting does
not need to change. GLBP differs from HSRP with regard to the MAC addresses it uses and the ARP process,
because GLBP actually uses ARP Reply messages to balance traffic from different hosts through different
routers.
With GLBP, one router acts in a special role called the active virtual gateway (AVG).
The AVG replies to all ARP requests for the virtual IP address. Each router has a unique virtual MAC address,
so that the AVG can reply to some ARP Requests with one virtual MAC, and some with the other.
As a result, some hosts in the subnet send frames to the Ethernet MAC address of one of the routers, with
other hosts sending their frames to the MAC address of the second router.

The figure shows three messages, top to bottom, with the following action:
1. Host A has no ARP table entry for its default router, 10.1.1.1, so host A sends an ARP Request to learn
10.1.1.1s MAC address.
2. The GLBP AVG, R1 in this case, sends back an ARP Reply. The AVG chooses to include its own virtual MAC
address in the
ARP Reply, VMAC1.
3. Future IP packets sent by host A are encapsulated in Ethernet frames, destined to VMAC1, so that they
arrive at R1.
From now on, host A sends off-subnet packets to R1 due to host As ARP table entry for its default gateway
(10.1.1.1). Host As ARP table entry for 10.1.1.1 now refers to a MAC address on R1 (VMAC1), so packets
host A sends off-subnet flow through R1.
To balance the load, the AVG answers each new ARP Request with the MAC addresses of alternating routers.
Figure continues the load-balancing effect with the ARP Request for 10.1.1.1 coming from host B. The router
acting as AVG (R1) still sends the ARP Reply, but this time with R2s virtual MAC (VMAC2).
Here are the steps in the figure:
1. Host B sends an ARP Request to learn 10.1.1.1s MAC address.
2. The GLBP AVG (R1) sends back an ARP Reply, listing VMAC2, R2s virtual MAC address.
3. For future packets sent off-subnet, host B encapsulates the packets in Ethernet frames, destined to
VMAC2, so that they arrive at R2.
The process shown in Figures balances the traffic, per host, but the routers must also be ready to take over
for the other router if it fails. GLBP refers to each router as a forwarder. When all is well, each router acts as
forwarder for their own virtual MAC address, but it listens to GLBP messages to make sure the other
forwarders are still working. If another forwarder fails, the still-working forwarder takes over the failed
forwarders virtual MAC address role and continues to forward traffic.

ROUTING

PART B

CONFIGURATIONS

Static Route Configuration

Task: Configure static route from Host A to Host B and verify.

Analyzing Default configurations

Configurations on Host A and Host B:

Host A and Host B are running Linux TinyCore OS with following configurations:

Configurations on Routers:
R1#show ip interface brief
Interface
IP-Address
FastEthernet0/0
192.168.1.1
Serial0/0
192.168.2.1
FastEthernet0/1
unassigned
Serial0/1
unassigned
R1#show ip route

OK?
YES
YES
YES
YES

Method
manual
manual
unset
unset

Status
Protocol
up
up
up
up
administratively down down
administratively down down

C
192.168.1.0/24 is directly connected,
C
192.168.2.0/24 is directly connected,
R2#show ip interface brief
Interface
IP-Address
FastEthernet0/0
unassigned
Serial0/0
192.168.2.2
FastEthernet0/1
unassigned
Serial0/1
192.168.3.1
R2#show ip route

FastEthernet0/0
Serial0/0

C
192.168.2.0/24 is directly connected,
C
192.168.3.0/24 is directly connected,
R3#show ip interface brief
Interface
IP-Address
FastEthernet0/0
192.168.4.1
Serial0/0
unassigned
FastEthernet0/1
unassigned
Serial0/1
192.168.3.2
R3#show ip route

Serial0/0
Serial0/1

C
C

OK?
YES
YES
YES
YES

OK?
YES
YES
YES
YES

Method
unset
manual
unset
manual

Method
manual
unset
unset
manual

Status
Protocol
administratively down down
up
up
administratively down down
up
up

Status
Protocol
up
up
administratively down down
administratively down down
up
up

192.168.4.0/24 is directly connected, FastEthernet0/0

192.168.3.0/24 is directly connected, Serial0/1

All three routers cannot reach beyond their connected network as shown in their Routing Tables, to
make this possible let us use static route configuration.
Static Route configuration is done using:
ip route|network|mask|outgoing interface (next hop ip) command that is to say: ip
route (if you wanna route to) destination network (with) mask (then go to this) outgoing
interface (or this) next hop interface ip

Static Route configuration based on Outgoing interface

Step 1:

R1 would be educated about destination network 192.168.4.0 and all the unknown transit networks
One unknown transit network in this case is network 192.168.3.0

R1(config)#ip route 192.168.4.0 255.255.255.0 serial 0/0

R1(config)#ip route 192.168.3.0 255.255.255.0 serial 0/0

Step 2:

Transit router R2 would also be educated about essential unknown networks 192.168.4.0 and
192.168.1.0
For traffic coming from network 192.168.4.0 to 192.168.1.0 R2 should know the way to 192.168.1.0

R2(config)#ip route 192.168.4.0 255.255.255.0 serial 0/1

R2(config)#ip route 192.168.1.0 255.255.255.0 serial 0/0

Step 3:
As in Step 1 to send traffic (back) to 192.168.1.0, R3 must know destination and all the transit networks
R3(config)#ip route 192.168.1.0 255.255.255.0 serial 0/1
R3(config)#ip route 192.168.2.0 255.255.255.0 serial 0/1

The end result is that every router know about all four networks:
For R1 to reach R4, R1 knows, along with destination, all the transit networks through which it has to
pass to reach R4 and vice versa and transit router R2 knows networks in both ways.

R1#show ip route
S
192.168.4.0/24
C
192.168.1.0/24
C
192.168.2.0/24
S
192.168.3.0/24
R2#show ip route
S
192.168.4.0/24
S
192.168.1.0/24
C
192.168.2.0/24
C
192.168.3.0/24
R3#show ip route
C
192.168.4.0/24
S
192.168.1.0/24
S
192.168.2.0/24
C
192.168.3.0/24

is
is
is
is

directly
directly
directly
directly

connected,
connected,
connected,
connected,

Serial0/0
FastEthernet0/0
Serial0/0
Serial0/0

is
is
is
is

directly
directly
directly
directly

connected,
connected,
connected,
connected,

Serial0/1
Serial0/0
Serial0/0
Serial0/1

is
is
is
is

directly
directly
directly
directly

connected,
connected,
connected,
connected,

FastEthernet0/0
Serial0/1
Serial0/1
Serial0/1

Pings from Host A to Host B are successful:

Static Route configuration based on Next Hop

In this approach we educate routers hop by hop about the destination and all the unknown networks
in the way to the destination.

Step 1:
R1(config)#ip route
R1(config)#ip route
R1#show ip route
S
192.168.4.0/24
C
192.168.1.0/24
C
192.168.2.0/24
S
192.168.3.0/24

192.168.3.0 255.255.255.0 192.168.2.2

192.168.4.0 255.255.255.0 192.168.2.2
[1/0] via 192.168.2.2
is directly connected, FastEthernet0/0
is directly connected, Serial0/0
[1/0] via 192.168.2.2

Show ip route command lists different output in this case showing next hop routers interface ip
address in place of outgoing interface as seen previously.
It might be tempting to take 192.168.4.0 one hop away from local router (R1) but
[1/0] via 192.168.2.2 (one hop via 192.168.2.2) means that network 192.168.4.0 (and
192.168.3.0) is 1 hop away from the next hop routers interface 191.168.2.2.
As we can see in the topology diagram that actually network 192.168.4.0 is 2 hops away from local
router (R1) and network 192.168.3.0 is 1 hop away, we can also verify this using traceroute
command:

R1#traceroute 192.168.4.1

Type escape sequence to abort.

Tracing the route to 192.168.4.1
1 192.168.2.2 28 msec 36 msec 28 msec
2 192.168.3.2 28 msec 44 msec *

Step 2:
R2(config)#ip route 192.168.1.0 255.255.255.0 192.168.2.1
R2(config)#ip route 192.168.4.0 255.255.255.0 192.168.3.2

Step 3:
R3(config)#ip route 192.168.2.0 255.255.255.0 192.168.3.1
R3(config)#ip route 192.168.1.0 255.255.255.0 192.168.3.1

Configuration of Default Route

Default Route of Gateway of Last Resort as it is called in show ip route command output can be
configured using following three ways:

1- Using Exit (outgoing) interface

The command format is ip route|0.0.0.0|0.0.0.0|interface
R1(config)#ip route 0.0.0.0 0.0.0.0 serial 0/0
R1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S
C
C
S
S*

192.168.4.0/24 [1/0] via 192.168.2.2

192.168.1.0/24 is directly connected, FastEthernet0/0
192.168.2.0/24 is directly connected, Serial0/0
192.168.3.0/24 [1/0] via 192.168.2.2
0.0.0.0/0 is directly connected, Serial0/0

This is the most preferred way to set a default route as it has AD of 0

2- Using Next Hop

Command format ip route|0.0.0.0|0.0.0.0|next hop ip
Router(config)#ip route 0.0.0.0 0.0.0.0 192.168.3.2
Router#show ip route
Gateway of last resort is 192.168.3.2 to network 0.0.0.0
S
S
C
C
S*

192.168.4.0/24 [1/0] via 192.168.3.2

192.168.1.0/24 [1/0] via 192.168.2.1
192.168.2.0/24 is directly connected, Serial0/0
192.168.3.0/24 is directly connected, Serial0/1
0.0.0.0/0 [1/0] via 192.168.3.2

3- Using Default Network

The command format is ip default-network|network

R3(config)#ip default-network 192.168.3.0

The ip default-network command would advertise the default network when you configure an IGP on
the router, so other routers in the internetwork receive this route as a default route automatically.

OSPF Configurations
Single Area Configuration

Step 1: Enable OSPF

R1(config)#router ospf 1
R2(config)#router ospf 1
R3(config)#router ospf 1

router ospf 1 puts the user in OSPF configuration mode, and sets the OSPF process-id.
Process-id number needs to be unique on the local router if multiple OSPF instances are needed,
otherwise process-id does not have to match on each router.
PID can be any integer between 1 and 65,535.

Step 2: Configure Router ID

R1(config-router)#router-id 1.1.1.1
R2(config-router)#router-id 2.2.2.2
R3(config-router)#router-id 3.3.3.3

RID must be in IP address format but it does not have to be a valid IP Address.
Can also be configured by creating a loopback interface.

Step 3: Advertise Interfaces

Can be done in following two ways:

Using Network Command

R1(config-router)#network 10.10.1.1 0.0.255.255 area 0
R2(config-router)#network 10.10.1.2 0.0.0.0 area 0
*Mar 1 00:36:52.275: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to
FULL, Loading Done
R2(config-router)#network 10.10.3.1 0.0.0.0 area 0

Although command was given as 10.10.1.1. the IOS will take it as 10.10.0.0 because of wildcard
mask.
Wildcard specifies which interface to include and which to ignore, the 255 or portion with 1s in
wildcard mask tell IOS to ignore that part.
0.0.255.255 says that first 2 octets must match and other two can be ignored and maybe anything.
Wildcard of 0.0.0.0 means that the IP must exactly match and only that interface must be included
in the process.
Network statement 0.0.0.0 255.255.255.255 specifies any and all interfaces with an IP and enables
the protocol on them, now and in the future.
OSPF area ID can be in decimal format or in IP address format, 0 and 0.0.0.0 are both valid and
useable and same.

Using Interfaces
R3(config)#int fa 1/0
R3(config-if)#ip ospf
R3(config-if)#
*Mar 1 00:45:38.139:
FULL, Loading Done
R3(config-if)#exit
R3(config)#int fa 0/1
R3(config-if)#ip ospf
R3(config-if)#
*Mar 1 00:46:17.547:
FULL, Loading Done

1 area 0
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet1/0 from LOADING to

1 area 0
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/1 from LOADING to

Manipulate Cost to influence SPF Path Selection

R1#show ip route
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 3 subnets
10.10.1.0 is directly connected, FastEthernet0/0
10.10.2.0 is directly connected, FastEthernet0/1
10.10.3.0 [110/11] via 10.10.2.2, 00:05:31, FastEthernet0/1
[110/11] via 10.10.1.2, 00:05:31, FastEthernet0/0

C
C
O

As the output shows that R1 has two equal cost paths to reach subnet 10.10.3.0, this is because R1
has the same OSPF cost of 10 via FaE0/1 and FaE0/0 from R3 and R2s side to reach this subnet.

R1#show ip ospf interface

FastEthernet0/1 is up, line protocol is up
Internet Address 10.10.2.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
FastEthernet0/0 is up, line protocol is up
Internet Address 10.10.1.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10

As it can be seen that OSPF is enabled on two interfaces fa0/0 and 0/1 and both have cost of 10
If we change the cost from 10 to 20 on 0/1 of R1, the cost via 10.10.2.2 to subnet 10.10.3.0 would
increase and OSPF would eliminate this entry via interface 0/1 from routing table:

R1(config)#int f0/1
R1(config-if)#ip ospf cost 20

R1#show ip ospf interface fastEthernet 0/1

FastEthernet0/1 is up, line protocol is up
Internet Address 10.10.2.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 20

R1#show ip route
10.0.0.0/24 is subnetted, 3 subnets
C
10.10.1.0 is directly connected, FastEthernet0/0
C
10.10.2.0 is directly connected, FastEthernet0/1
O
10.10.3.0 [110/11] via 10.10.2.2, 00:00:02, FastEthernet0/0

The path via FastEthernet 0/1 is eliminated because of increased cost.

Influencing DR/BDR election

R1(config)#int f0/1
R1(config-if)#ip ospf priority 20

The assigned priority can be between 0 and 255.

A priority of 0 makes the router ineligible to become a designated router (DR) or backup designated
router BDR).
The highest priority wins the election. A priority of 255 guarantees a tie in the election.
If all routers have the same priority, regardless of the priority number, they tie. Ties are broken by
the highest router ID.

OSPF Timers
R1(config)#int f0/1
R1(config-if)#ip ospf hello-interval
R1(config-if)#ip ospf dead-interval

Simple Authentication
R1(config)#router ospf 1
R1(config-router)#area 0 authentication
R1(config-router)#exit
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip ospf authentication-key cisco
R1(config)#interface fastEthernet 0/1
R1(config-if)#ip ospf authentication-key cisco

Enables simple authentication; password will be sent in clear text.

The password can be any continuous string of characters that can be entered from the keyboard, up
to
8 bytes in length.
To be able to exchange OSPF information, all neighboring routers on the same network must have
the same password.

MD5 Authentication
R1(config)#router ospf 1
R1(config-router)#area 0 authentication message-digest
R1(config-router)#exit
R1(config)#int fa 0/0
R1(config-if)#ip ospf message-digest-key 1 md5 cisco
R1(config)#int fa 0/1
R1(config-if)#ip ospf message-digest-key 1 md5 cisco

Enables authentication with MD5 password encryption.

If the service password encryption command is not used when implementing OSPF MD5
authentication, the MD5 secret is stored as plain text in NVRAM.

Multi-Area OSPF Configurations

Step 1:
R2(config)#router ospf 1
R2(config-router)#network 10.10.4.1 0.0.0.0 area 1
R2(config-router)#end
R3(config)#router ospf 1
R3(config-router)#network 10.10.5.1 0.0.0.0 area 2
R3(config-router)#end
R4(config)#router ospf 1
R4(config-router)#network 10.10.4.2 0.0.0.0 area 1
R4(config-router)#network 10.10.6.1 0.0.0.0 area 1
R4(config-router)#end
R5(config)#router ospf 1
R5(config-router)#network 10.10.5.2 0.0.0.0 area 2
R5(config-router)#network 10.10.7.1 0.0.0.0 area 2
R5(config-router)#end

R1#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set

C
C
O
O IA
O IA
O IA

10.0.0.0/24 is subnetted, 7 subnets

10.10.1.0 is directly connected, FastEthernet0/0
10.10.2.0 is directly connected, FastEthernet0/1
10.10.3.0 [110/11] via 10.10.1.2, 00:10:55, FastEthernet0/0
10.10.4.0 [110/20] via 10.10.1.2, 00:10:55, FastEthernet0/0
10.10.5.0 [110/21] via 10.10.1.2, 00:10:55, FastEthernet0/0
10.10.6.0 [110/30] via 10.10.1.2, 00:10:55, FastEthernet0/0

O IA

10.10.7.0 [110/31] via 10.10.1.2, 00:08:46, FastEthernet0/0

IA = Inter-Area routes i.e. routes between multiple areas, and other routes that are represented by
simple O are Intra-Area routes i.e. routes within one area.

R2#show ip route
C
O
C
C
O IA
O
O IA

10.0.0.0/24 is subnetted, 7 subnets

10.10.1.0 is directly connected, FastEthernet0/0
10.10.2.0 [110/11] via 10.10.3.2, 00:12:55, FastEthernet1/0
10.10.3.0 is directly connected, FastEthernet1/0
10.10.4.0 is directly connected, FastEthernet0/1
10.10.5.0 [110/11] via 10.10.3.2, 00:12:55, FastEthernet1/0
10.10.6.0 [110/20] via 10.10.4.2, 00:16:48, FastEthernet0/1
10.10.7.0 [110/21] via 10.10.3.2, 00:10:46, FastEthernet1/0

In multi-area configuration one interface is always in backbone area and others go in different areas,
no other major difference.

Changing OSPF Network Type

R2(config)#int fa 0/1
R2(config-if)#ip ospf network ?
broadcast
non-broadcast
point-to-multipoint
point-to-point

Specify
Specify
Specify
Specify

OSPF
OSPF
OSPF
OSPF

broadcast multi-access network

NBMA network
point-to-multipoint network
point-to-point network

R2(config-if)#ip ospf network point-to-point

R3(config)#int fa0/0
R3(config-if)#ip ospf network point-to-point
R4(config)#interface range fastEthernet 0/0 - 1
R4(config-if-range)#ip ospf network point-to-point
R5(config)#int ra fa 0/0 - 1
R5(config-if-range)#ip ospf network point-to-point

OSPF Passive Interface Configuration

R4(config)#router ospf 1
R4(config-router)#passive-interface fastEthernet 0/0
R5(config)#router ospf 1
R5(config-router)#passive-interface fastEthernet 0/1

Passive-interface default command sets all interfaces as passive.

Verification of OSPF
R2#show running-config
interface FastEthernet0/0

ip address 10.10.1.2 255.255.255.0

ip ospf authentication-key cisco
ip ospf message-digest-key 1 md5 cisco
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.10.4.1 255.255.255.0
ip ospf network point-to-point
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.10.3.1 255.255.255.0
ip ospf message-digest-key 1 md5 cisco
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
area 0 authentication message-digest
network 10.10.1.2 0.0.0.0 area 0
network 10.10.3.1 0.0.0.0 area 0
network 10.10.4.1 0.0.0.0 area 1
!

Lists Router and interface level OSPF configurations:

IP addresses and Masks
Authentication Type
Authentication Key (if password encryption is not configured)
OSPF Network Type
Process ID
Area Number
Router ID
Network Statements
Stub, NSSA Config

R1#show ip protocols
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 1.1.1.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.10.0.0 0.0.255.255 area 0
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway
Distance
Last Update
3.3.3.3
110
00:33:05
2.2.2.2
110
00:33:36
Distance: (default is 110)

Lists following information:

OSPF 1: Protocol that is running is OSPF with Process ID of 1.
Router ID of local Router.
Number and Types of Areas: How many are normal, stub or NSSA areas.

Maximum Path: Show maximum default Equal Cost Load Balancing paths that are
configured. OSPF does not support Unequal Cost Load Balancing, EIGRP does.
Routing for Networks: The Network command that was added to router, its routing for all
the networks that encompass this command.
Routing Information Sources: Other neighbor from whom the local router is getting
updates.
Distance: Administrative Distance of OSPF

R2#show ip ospf
Routing Process "ospf 1" with ID 2.2.2.2
Start time: 00:00:03.416, Time elapsed: 00:02:53.088
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
It is an area border router
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has message digest authentication
SPF algorithm last executed 00:02:00.804 ago
SPF algorithm executed 5 times
Area ranges are
Number of LSA 10. Checksum Sum 0x065BCF
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 1
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:02:30.904 ago
SPF algorithm executed 4 times
Area ranges are
Number of LSA 7. Checksum Sum 0x03DFB2
Number of opaque link LSA 0. Checksum Sum 0x000000
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0

Lists following information:

Area specific details
Process ID

Router ID
Authentication Type (Null, Clear Text, MD5)
Number of interfaces as per area
Stub Flags: if an area was configured as stub if would have been mentioned in area section, show run
command also mentions stub configuration.

R3#show ip ospf neighbor

Neighbor ID
2.2.2.2
1.1.1.1
5.5.5.5

Pri
1
2
0

State
FULL/DR
FULL/DR
FULL/ -

Dead Time
00:00:35
00:00:34
00:00:37

Address
10.10.3.1
10.10.2.1
10.10.5.2

Interface
FastEthernet1/0
FastEthernet0/1
FastEthernet0/0

Lists following information:

Neighbor ID: Router ID of OSPF Neighbors.
Pri: OSPF link Priority of neighbors with respect to DR/BDR election.
State: Adjacency state and DR/BDR state of neighbors.
Address: Neighbors interface Address to which local router is attached.
Interface: Local routers interface to which neighbor is attached.

R3#show ip ospf interface brief

Interface
Fa1/0
Fa0/1
Fa0/0

PID
1
1
1

Area
0
0
2

IP Address/Mask
10.10.3.2/24
10.10.2.2/24
10.10.5.1/24

Cost
1
10
10

State
BDR
BDR
P2P

Nbrs F/C
1/1
1/1
1/1

Local routers OSPF interfaces summary and related information.

What show ip ospf neighbor command tells about neighbors, this command tells that about the
local router.

R3#show ip ospf interface

FastEthernet1/0 is up, line protocol is up
Internet Address 10.10.3.2/24, Area 0
Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 1
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 2.2.2.2, Interface address 10.10.3.1
Backup Designated router (ID) 3.3.3.3, Interface address 10.10.3.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:09
Supports Link-local Signaling (LLS)
Index 2/2, 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 1, Adjacent neighbor count is 1
Adjacent with neighbor 2.2.2.2 (Designated Router)
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
FastEthernet0/1 is up, line protocol is up
Internet Address 10.10.2.2/24, Area 0
Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 10

FastEthernet0/0 is up, line protocol is up

Internet Address 10.10.5.1/24, Area 2
Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 10
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Shows all OSPF interfaces and their details:

Interface Status
Interface IP Address
Interface Area
OSPF Process ID
Router ID
OSPF Network Type
Interface Cost
Delay
DR/BDR/DROTHER State
Interface Priority
DRs RID and its directly connected interface IP
BDRs RID and its directly connected interface IP
OSPF Timers
OSPF Authentication and Key number
Default cost of 1 shows that this is a FastEthernet link and cost of 10 show its an 10mbps Ethernet
interface.

R1#show ip ospf interface fastEthernet 0/0

Lists OSPF details on specified interface as mentioned above.

R3#show ip ospf database

OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
Link ID
1.1.1.1
2.2.2.2
3.3.3.3

ADV Router
1.1.1.1
2.2.2.2
3.3.3.3

Age
969
838
1262

Seq#
0x80000008
0x8000000A
0x80000008

Checksum
0x00E9B3
0x00752D
0x006930

Seq#
0x80000005
0x80000005
0x80000002

Checksum
0x00EF20
0x0017F3
0x0016EE

Link count
2
2
2

Net Link States (Area 0)

Link ID
10.10.1.1
10.10.2.1
10.10.3.1

ADV Router
1.1.1.1
1.1.1.1
2.2.2.2

Age
969
969
1352

Summary Net Link States (Area 0)

Link ID
10.10.4.0
10.10.5.0
10.10.6.0
10.10.7.0

ADV Router
2.2.2.2
3.3.3.3
2.2.2.2
3.3.3.3

Age
838
1008
330
265

Seq#
0x80000005
0x80000002
0x80000002
0x80000002

Checksum
0x00828C
0x005FAD
0x00D62F
0x00AD53

Router Link States (Area 2)

Link ID
3.3.3.3
5.5.5.5

ADV Router
3.3.3.3
5.5.5.5

Age
761
247

Seq#
Checksum Link count
0x80000008 0x00FDAB 2
0x80000005 0x002C43 3

Summary Net Link States (Area 2)

Link ID

ADV Router

Age

Seq#

Checksum

10.10.1.0
10.10.2.0
10.10.3.0
10.10.4.0
10.10.6.0

3.3.3.3
3.3.3.3
3.3.3.3
3.3.3.3
3.3.3.3

1266
1266
1266
1266
270

0x80000005
0x80000005
0x80000005
0x80000005
0x80000002

0x008F7D
0x007A92
0x0015FF
0x006E9B
0x00C23E

Router Link States: Router Link State Advertisements or LSA Type 1s and their related information.
Net Link States: Network LSA Type 2s and their related information.

R3#show ip ospf database router 2.2.2.2

OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
Routing Bit Set on this LSA
LS age: 1055
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 2.2.2.2
Advertising Router: 2.2.2.2
LS Seq Number: 8000000A
Checksum: 0x752D
Length: 48
Area Border Router
Number of Links: 2
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.3.1
(Link Data) Router Interface address: 10.10.3.1
Number of TOS metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.10.1.1
(Link Data) Router Interface address: 10.10.1.2
Number of TOS metrics: 0
TOS 0 Metrics: 10

Lists in depth analysis of Router LSAs with respect to certain specified router.

R1#debug ip ospf ?
adj
database-timer
events
flood
hello
lsa-generation
mpls
nsf
packet
retransmission
spf
tree

OSPF
OSPF
OSPF
OSPF
OSPF
OSPF
OSPF
OSPF
OSPF
OSPF
OSPF
OSPF

adjacency events
database timer
events
flooding
hello events
lsa generation
MPLS
non-stop forwarding events
packets
retransmission events
spf
database tree

R3#debug ip ospf adj

OSPF adjacency events debugging is on

R3#clear ip ospf process

Reset ALL OSPF processes? [no]: yes
R3#
OSPF: Send with youngest Key 1

OSPF: Interface FastEthernet1/0 going Down

OSPF: 2.2.2.2 address 10.10.3.1 on FastEthernet1/0 is dead, state DOWN
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet1/0 from FULL to DOWN, Neighbor Down:
Interface down or detached
OSPF: Neighbor change Event on interface FastEthernet1/0
OSPF: DR/BDR election on FastEthernet1/0
OSPF: Elect BDR 3.3.3.3
OSPF: Elect DR 3.3.3.3
OSPF: Elect BDR 0.0.0.0
OSPF: Flush network LSA immediately
OSPF: Interface FastEthernet0/1 going Down
OSPF: Interface FastEthernet0/0 going Up
OSPF: 2 Way Communication to 1.1.1.1 on FastEthernet0/1, state 2WAY
OSPF: Backup seen Event before WAIT timer on FastEthernet0/1
OSPF: Send DBD to 2.2.2.2 on FastEthernet1/0 seq 0x169D opt 0x52 flag 0x7 len 32
OSPF: Send with youngest Key 1
OSPF: Rcv DBD from 5.5.5.5 on FastEthernet0/0 seq 0xCC2 opt 0x52 flag 0x7 len 32 mtu 1500 state
EXSTART
OSPF: NBR Negotiation Done. We are the SLAVE
OSPF: Send DBD to 5.5.5.5 on FastEthernet0/0 seq 0xCC2 opt 0x52 flag 0x0 len 32
OSPF: Rcv DBD from 2.2.2.2 on FastEthernet1/0 seq 0x169E opt 0x52 flag 0x0 len 32 mtu 1500 state
EXCHANGE
OSPF: Exchange Done with 2.2.2.2 on FastEthernet1/0
OSPF: Send LS REQ to 2.2.2.2 length 72 LSA count 6
OSPF: Rcv LS UPD from 5.5.5.5 on FastEthernet0/0 length 216 LSA count 6

Shows different states of adjacency and LSA flooding procedure and regular exchange of OSPF
authentication keys.
Clear ip ospf process command restarts the OSPF process on the router.

Troubleshooting Basic OSPF

Assuming that the interfaces are correctly configured, are in up/up state and neighboring
candidates are in same subnet:

Step 1: Ping and Trace route to neighboring device to confirm reachability

Step 2: Verify OSPF is enabled on neighbor or not
#ping 224.0.0.5

Step 3: Verify OSPF is enabled on local router and is enabled on right interfaces
#show
#show
#show
#show

running-config
ip ospf interface brief
ip protocols (esp. check the network statement)
run | section router ospf

Step 4: Check compulsory OSPF neighborship parameters for Adjacency

1- Subnet and Subnet Mask (Except P2P or Virtual Link)
#show ip ospf interface brief
#show ip ospf interface
#show running-config

2- Area number and Type

#show
#show
#show
#show

ip ospf interface
ip ospf
ip ospf | begin area 1
running-config

3- Timers (esp. Hello and Dead Timers)

#show ip ospf interface

4- Unique RIDs
#show
#show
#show
#show

ip ospf interface
ip ospf
ip database
running-config

5- Authentication Type (Null, Clear Text, MD5) and Passwords

#show
#show
#show
#show

ip ospf
ip ospf | begin area 0
running-config
ip ospf interface

6- Network Type
#show ip ospf interface
#show running-config

7- Interface MTU

#show interfaces fa0/0

8- Stub Flags ( Stub, NSSA)

#show ip ospf
#show ip ospf | begin area 0
#show running-config

3 Unique Commands that may help troubleshoot all basic neighbor adjacency issues:

#show ip ospf interface

#show ip ospf
#show interfaces

EIGRP Configurations

Step 1: Define ASN

R1(config)#router eigrp 1
R2(config)#router eigrp 1

Step 2: Configure Router ID

R1(config-router)#eigrp router-id 1.1.1.1
R2(config-router)#eigrp router-id 2.2.2.2

Step 3: Advertise Interfaces

R1(config-router)#network 10.10.1.1 0.0.0.0
R1(config-router)#network 10.10.2.1 0.0.0.0
R1(config-router)#network 10.10.5.2 0.0.0.0
R2(config-router)#network 10.10.1.2 0.0.0.0
R2(config-router)#network 10.10.4.2 0.0.0.0
R2(config-router)#network 10.10.7.1 0.0.0.0

Step 4: Configure Authentication

A- Create an Authentication Key Chain, globally:
Commands sequence is:
(i)-key chain HusnainAliBaig
(ii)-key 1
(iii)-key-string HUSNAIN ALI BAIG

R1(config)#key ?
chain
config-key

Key-chain management
Set a private configuration key for general use

R1(config)#key chain ?
WORD

Key-chain name

R1(config)#key chain HusnainAliBaig

R1(config-keychain)#?
Key-chain configuration commands:
default Set a command to its defaults

exit
key
no

Exit from key-chain configuration mode

Configure a key
Negate a command or set its defaults

R1(config-keychain)#key ?
<0-2147483647>

Key identifier

R1(config-keychain)#key 1
R1(config-keychain-key)#?
Key-chain key configuration commands:
accept-lifetime
default
exit
key-string
no
send-lifetime

Set accept lifetime of key

Set a command to its defaults
Exit from key-chain key configuration mode
Set key string
Negate a command or set its defaults
Set send lifetime of key

R1(config-keychain-key)#key-string ?
0
7
LINE

Specifies an UNENCRYPTED password will follow

Specifies a HIDDEN password will follow
The UNENCRYPTED (cleartext) user password

R1(config-keychain-key)#key-string HUSNAIN ALI BAIG

R1(config-keychain-key)#end
R2(config)#key chain HusnainAliBaig
R2(config-keychain)#key 1
R2(config-keychain-key)#key-string HUSNAIN ALI BAIG
R2(config-keychain-key)#end

B- Select and implement MD5 Authentication Mode on interfaces:

Commands sequence is:
(i)-ip authentication mode eigrp 1 md5
(ii)-ip authentication key-chain eigrp 1 HusnainAliBaig

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip authentication mode eigrp 1 md5
*Mar

1 01:50:24.915: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.1.2 (FastEthernet0/0) is down: authentication mode changed

R1(config-if)#ip authentication key-chain eigrp 1 ?

WORD

name of key-chain

R1(config-if)#ip authentication key-chain eigrp 1 HusnainAliBaig

R2(config)#interface fastEthernet 0/0
R2(config-if)#ip authentication mode eigrp 1 md5
R2(config-if)#ip authentication key-chain eigrp 1 HusnainAliBaig
*Mar

1 01:54:11.439: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.1.1 (FastEthernet0/0) is up: new adjacency

R1#show key chain

Key-chain HusnainAliBaig:
key 1 -- text "HUSNAIN ALI BAIG"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]

Manipulating Hello and Hold timers

R1#show ip eigrp interfaces detail
IP-EIGRP interfaces for process 1
Xmit Queue
Mean
Pacing Time
Interface
Peers Un/Reliable SRTT
Un/Reliable
Fa0/0
1
0/0
32
0/2
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/9 Un/reliable ucasts: 13/8
Mcast exceptions: 2 CR packets: 2 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 0
Authentication mode is not set
Use multicast

Multicast
Flow Timer
132

Pending
Routes
0

Default Hold Time is three times Hello, so in this case it is 15 seconds and can be seen ticking in
show ip eigrp neighbors command:

R1#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H
Address
Interface
2
1
0

10.10.5.1
10.10.2.2
10.10.1.2

Fa1/0
Fa0/1
Fa0/0

Hold Uptime
SRTT
(sec)
(ms)
11 00:07:44
38
12 00:07:47
30
14 00:07:50
32

RTO

Q
Cnt
228 0
200 0
200 0

Seq
Num
43
30
29

To Change these two timers:

R1(config)#int fa 0/0
R1(config-if)#ip hello-interval eigrp ?
<1-65535> Autonomous system number
R1(config-if)#ip hello-interval eigrp 1 ?
<1-65535> Seconds between hello transmissions
R1(config-if)#ip hello-interval eigrp 1 5
R1(config-if)#ip hold-time eigrp 1 ?
<1-65535> Seconds before neighbor is considered down
R1(config-if)#ip hold-time eigrp 1 15

Influencing Metric Calculations by manipulating Bandwidth and

Delay
Topology Table Analysis:
R1#show ip eigrp topology all-links
IP-EIGRP Topology Table for AS(1)/ID(10.10.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.10.1.0/24, 1 successors, FD is 281600, serno 8
via Connected, FastEthernet0/0
P 10.10.2.0/24, 1 successors, FD is 281600, serno 10
via Connected, FastEthernet0/1
P 10.10.3.0/24, 1 successors, FD is 284160, serno 17
via 10.10.5.1 (284160/281600), FastEthernet1/0
via 10.10.2.2 (307200/281600), FastEthernet0/1
via 10.10.1.2 (332800/307200), FastEthernet0/0, serno 19
P 10.10.4.0/24, 1 successors, FD is 284160, serno 18
via 10.10.5.1 (284160/281600), FastEthernet1/0
via 10.10.2.2 (332800/307200), FastEthernet0/1, serno 20
via 10.10.1.2 (307200/281600), FastEthernet0/0
P 10.10.5.0/24, 1 successors, FD is 28160, serno 3
via Connected, FastEthernet1/0
P 10.10.6.0/24, 1 successors, FD is 33280, serno 25
via 10.10.2.2 (284160/28160), FastEthernet0/1
via 10.10.5.1 (286720/284160), FastEthernet1/0
P 10.10.7.0/24, 1 successors, FD is 33280, serno 27
via 10.10.1.2 (284160/28160), FastEthernet0/0
via 10.10.5.1 (286720/284160), FastEthernet1/0

This command show all the possible routes to all the possible destination subnets, this is all
EIGRP knows.
For example, as the output shows, To reach subnet 10.10.3.0/24, R1 has three possible routes:

I.
II.
III.

via next hop interface 10.10.5.1 of R4 that is located on R1s outgoing interface FaE 1/0
via next hop interface 10.10.2.2 of R3 that is located on R1s outgoing interface FaE 0/1
via next hop interface 10.10.1.2 of R2 that is located on R1s outgoing interface FaE 0/0

P: is for EIGRP Passive is a calculation state means that EIGRP has done all the calculations, Active
means that EIGRP is actively calculating the different metrics for that route etc

R2#show ip eigrp topology all-links

IP-EIGRP Topology Table for AS(1)/ID(10.10.1.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.10.1.0/24, 1 successors, FD is 281600, serno 9
via Connected, FastEthernet0/0
via 10.10.4.1 (309760/284160), FastEthernet0/1
P 10.10.2.0/24, 1 successors, FD is 284160, serno 22
via 10.10.1.1 (307200/281600), FastEthernet0/0
via 10.10.4.1 (309760/284160), FastEthernet0/1,
P 10.10.3.0/24, 1 successors, FD is 307200, serno 18
via 10.10.4.1 (307200/281600), FastEthernet0/1
via 10.10.1.1 (309760/284160), FastEthernet0/0,
P 10.10.4.0/24, 1 successors, FD is 281600, serno 10
via Connected, FastEthernet0/1
via 10.10.1.1 (309760/284160), FastEthernet0/0,
P 10.10.5.0/24, 2 successors, FD is 30720, serno 23
via 10.10.1.1 (284160/28160), FastEthernet0/0
via 10.10.4.1 (284160/28160), FastEthernet0/1
P 10.10.6.0/24, 2 successors, FD is 309760, serno 25
via 10.10.1.1 (309760/284160), FastEthernet0/0,
via 10.10.4.1 (309760/284160), FastEthernet0/1
P 10.10.7.0/24, 1 successors, FD is 28160, serno 3
via Connected, FastEthernet1/0

serno 13
serno 17
serno 16

serno 20

R2s Metrics:
For network 10.10.2.0, FD = 2,84,160
For route 10.10.1.1, FD = 3,07,200 and RD = 2,81,600 (this RD is R1s FD for 10.10.2.0 as reported
to R2)
For route 10.10.4.1, FD = 3,09,760 and RD = 2,84,160 (this RD is R4 s FD for 10.10.2.0 as reported
to R2)
(as shown below) R2 chooses 10.10.1.1 as successor route because it meets the feasibility condition
i.e. 10.10.1.1s RD (2,81,160) is less than R2s FD (2,84,160).
10.10.4.1 is neither chosen as successor nor as feasible successor (so also not mentioned in output
below) because it does not meet feasibility condition i.e. 10.10.4.1s RD (2,84,160) is not less than
R2s FD (2,84,160), its equal.

R2#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.10.1.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.10.1.0/24, 1 successors, FD is 281600
via Connected, FastEthernet0/0
P 10.10.2.0/24, 1 successors, FD is 284160
via 10.10.1.1 (307200/281600), FastEthernet0/0
P 10.10.3.0/24, 1 successors, FD is 307200
via 10.10.4.1 (307200/281600), FastEthernet0/1
via 10.10.1.1 (309760/284160), FastEthernet0/0, serno 17
P 10.10.4.0/24, 1 successors, FD is 281600
via Connected, FastEthernet0/1

P 10.10.5.0/24, 2 successors, FD is 30720

via 10.10.1.1 (284160/28160), FastEthernet0/0
via 10.10.4.1 (284160/28160), FastEthernet0/1
P 10.10.6.0/24, 2 successors, FD is 309760
via 10.10.1.1 (309760/284160), FastEthernet0/0, serno 20
via 10.10.4.1 (309760/284160), FastEthernet0/1
P 10.10.7.0/24, 1 successors, FD is 28160
via Connected, FastEthernet1/0

This command shows only Successor and Feasible Successor routes and related metrics, but
does not explicitly mention which route is the successor and feasible successor, we have to apply
the feasibility condition to judge the successor and feasible successor.
Feasibility Condition: If a routes RD is less than local routers FD for the destination subnet, the
route meets the feasibility condition and is added in topology table as successor or feasible
successor.
For the destination subnet 10.10.3.0:
10.10.1.1 meets the feasibility condition (2,84,160 < 3,07,200) so it is the feasible successor and
not the successor because 10.10.4.1 meets the feasibility condition even better ( 2,81,600 <
2,84,160 < 3,07,200) and is the successor.
10.10.5.0 and 10.10.6.0 report 2 successors and no feasible successors because:
In both cases the feasibility condition is equally met, both RDs are equal and are less than local
routers FD so both are added as successors. If one successor goes down the second successor will
take on as the feasible successor would have done.

R2#show ip route
10.0.0.0/24 is subnetted, 7 subnets
10.10.1.0 is directly connected, FastEthernet0/0
10.10.2.0 [90/307200] via 10.10.1.1, 00:01:58, FastEthernet0/0
10.10.3.0 [90/307200] via 10.10.4.1, 00:02:01, FastEthernet0/1
10.10.4.0 is directly connected, FastEthernet0/1
10.10.5.0 [90/284160] via 10.10.4.1, 00:01:58, FastEthernet0/1
[90/284160] via 10.10.1.1, 00:01:58, FastEthernet0/0
10.10.6.0 [90/309760] via 10.10.4.1, 00:01:51, FastEthernet0/1
[90/309760] via 10.10.1.1, 00:01:52, FastEthernet0/0
10.10.7.0 is directly connected, FastEthernet1/0

C
D
D
C
D
D
C

EIGRP puts only the successor routes, and local routers metric to reach that route, in the routing
table.
As shown in routing table of R2, for subnet 10.10.3.0, only successor route 10.10.4.1, as we
calculated above, is listed in the routing table.
307200 is local routers metric to reach subnet 10.10.4.1 and 90 is the administrative distance for
EIGRP.
The letter D in the start denotes that this route was learned using EIGRP.
Subnets 10.10.5.0 and 10.10.6.0 had two successor routes, so both routes are listed.

Changing Bandwidth or Delay to influence metric thereby creating a feasible

successor
Previously we saw in R2s topology table that for network 10.10.2.0 it has two possible routes, 10.10.1.1 is
being used as the successor route and 10.10.4.1 is not being used at all because it does not meet the
feasibility condition:

R2#show ip eigrp topology all-links

P 10.10.2.0/24, 1 successors, FD is 284160,

via 10.10.1.1 (307200/281600), FastEthernet0/0

via 10.10.4.1 (309760/284160), FastEthernet0/1,

(successor route)
(not being utilized)

show ip eigrp topology command only lists the successor and feasible successor routes:

R2#show ip eigrp topology

P 10.10.2.0/24, 1 successors, FD is 284160

via 10.10.1.1 (307200/281600), FastEthernet0/0 (successor route)

We can use Bandwidth and/or Delay to meet the feasibility condition and make 10.10.4.1 a feasible
successor by increasing R2s FD for subnet 10.10.2.0 than 10.10.4.1s RD for subnet 10.10.2.0, which are
now equal:

R2#show ip eigrp topology 10.10.2.0/24

IP-EIGRP (AS 1): Topology entry for 10.10.2.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 284160
Routing Descriptor Blocks:
10.10.1.1 (FastEthernet0/0), from 10.10.1.1, Send flag is 0x0
Composite metric is (307200/281600), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.10.4.1 (FastEthernet0/1), from 10.10.4.1, Send flag is 0x0
Composite metric is (309760/284160), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2

This command list subnet 10.10.2.0/24s metric calculation details.

The output shows:
Subnet 10.10.2.0 is reachable via 10.10.4.1 that is located on local routers outgoing
interface FaE 0/1
Composite metric: R2s FD for 10.10.4.1(R4) is 3,09,760 and 10.10.4.1(R4)s RD 2,84,160
that is equal to R2s total FD for subnet 10.10.2.0 that is also 2,84,160. So does not meet the
feasibility condition.
R2s Minimum Bandwidth for 10.10.4.1 is 10000 Kbit
R2s Total Delay for 10.10.4.1 is 2100 microseconds
R2s Reliability for 10.10.4.1 is 255/255 i.e. 100%
R2s traffic Load for 10.10.4.1 is 1/255 minimal
R2s MTU for 10.10.4.1 is 1500
Subnet 10.10.2.0 is 2 hops away using 10.10.1.4 as first hop

To change bandwidth of delay for route 10.10.4.1 we would use local routers interface that is attached to
10.10.4.1 i.e. FastEthernet 0/1 of R2, same thing can be done in other cases like:

R2#show ip eigrp topology all-links

P 10.10.1.0/24, 1 successors, FD is 281600, serno 9
via Connected, FastEthernet0/0
via 10.10.4.1 (309760/284160), FastEthernet0/1
P 10.10.2.0/24, 1 successors, FD is 284160,

via 10.10.1.1 (307200/281600), FastEthernet0/0

via 10.10.4.1 (309760/284160), FastEthernet0/1,
P 10.10.3.0/24, 1 successors, FD is 307200,
via 10.10.4.1 (307200/281600), FastEthernet0/1
via 10.10.1.1 (309760/284160), FastEthernet0/0,

In the above output, if we want to change metrics for the routes in left typically by changing
bandwidth and delay, the changes can go into the local routers interfaces to the right.
So to influence route 10.10.4.1s metrics for subnet 10.10.2.0, we change the bandwidth or delay on FaE
0/1.
If we decide to increase the delay on FaE 0/1 a little bit that would influence all the metrics for 10.10.4.1:

R2#show interfaces fa0/1

FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is c012.157c.0001 (bia c012.157c.0001)
Internet address is 10.10.4.2/24
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set

Current Delay is 1000 microseconds.

Changing the delay a little:
R2(config)#int fastEthernet 0/1
R2(config-if)#delay ?
<1-16777215> Throughput delay (tens of microseconds)
R2(config-if)#delay 110

New Delay value is 1100 microseconds:

R2#show interfaces fa0/1

FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is c012.157c.0001 (bia c012.157c.0001)
Internet address is 10.10.4.2/24
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1100 usec,
reliability 255/255, txload 1/255, rxload 1/255

We rerun the EIGRP process so the new delay value could take effect:

R2#clear ip eigrp neighbors

R2#
*Mar
*Mar
*Mar
*Mar

1
1
1
1

05:54:46.842:
05:54:46.862:
05:54:46.942:
05:54:46.998:

%DUAL-5-NBRCHANGE:
%DUAL-5-NBRCHANGE:
%DUAL-5-NBRCHANGE:
%DUAL-5-NBRCHANGE:

IP-EIGRP(0)
IP-EIGRP(0)
IP-EIGRP(0)
IP-EIGRP(0)

1:
1:
1:
1:

Neighbor
Neighbor
Neighbor
Neighbor

10.10.1.1
10.10.4.1
10.10.4.1
10.10.1.1

(FastEthernet0/0)
(FastEthernet0/1)
(FastEthernet0/1)
(FastEthernet0/0)

is
is
is
is

down: manually cleared

down: manually cleared
up: new adjacency
up: new adjacency

R2#show ip eigrp topology 10.10.2.0/24

IP-EIGRP (AS 1): Topology entry for 10.10.2.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 307200 (was 284160)
Routing Descriptor Blocks:
10.10.1.1 (FastEthernet0/0), from 10.10.1.1, Send flag is 0x0
Composite metric is (307200/281600), Route is Internal
Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.10.4.1 (FastEthernet0/1), from 10.10.4.1, Send flag is 0x0

Composite metric is (312320/284160) (was 309760/284160), Route is Internal

Vector metric:
Minimum bandwidth is 10000 Kbit
Total delay is 2200 microseconds (was 2100)
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2

10.10.4.1 Previously could not meet the feasibility condition for subnet 10.10.2.0 because its RD was
not lower than R2s FD, they were equal.
Now an increase in Delay has increase R2s FD from 284160 to 307200 and 10.10.4.1s RD remained
same and is automatically lower than R2s FD (284160 < 307200) and meets the feasibility
condition.

So it is now added as a feasible successor route in the topology table below:

R2#show ip eigrp top

IP-EIGRP Topology Table for AS(1)/ID(10.10.1.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.10.1.0/24, 1 successors, FD is 281600
via Connected, FastEthernet0/0
P 10.10.2.0/24, 1 successors, FD is 307200
via 10.10.1.1 (307200/281600), FastEthernet0/0
via 10.10.4.1 (312320/284160), FastEthernet0/1
P 10.10.3.0/24, 2 successors, FD is 309760
via 10.10.4.1 (309760/281600), FastEthernet0/1
via 10.10.1.1 (309760/284160), FastEthernet0/0
P 10.10.4.0/24, 1 successors, FD is 284160
via Connected, FastEthernet0/1
P 10.10.5.0/24, 1 successors, FD is 284160
via 10.10.1.1 (284160/28160), FastEthernet0/0
via 10.10.4.1 (286720/28160), FastEthernet0/1
P 10.10.6.0/24, 1 successors, FD is 309760
via 10.10.1.1 (309760/284160), FastEthernet0/0
via 10.10.4.1 (312320/284160), FastEthernet0/1
P 10.10.7.0/24, 1 successors, FD is 28160
via Connected, FastEthernet1/0

As we know already that this command only lists successors and feasible successors and that route
10.10.4.1 was not in this output before but now its there as a feasible successor.
Route 10.10.4.1 is feasible successor and still not the successor because route 10.10.1.2s metric is
unchanged but still better (281600 < 284160 < 307200)

EIGRP Load balancing

Equal-Cost Load balancing:

Like OSPF, EIGRP supports the ability to put multiple equal-metric routes in the IPv4 routing table.
Like OSPF, EIGRP defaults to support four such routes for each subnet, and it can be configured to
other values using the maximum-paths number EIGRP subcommand.
Routes with exactly same metric are added to the routing table, but these routes are either
successors or feasible successors.
The maximum number of equal cost paths depends on the IOS version and router platform.

R3#show ip route
10.0.0.0/24 is subnetted, 7 subnets
10.10.1.0 [90/307200] via 10.10.2.1, 00:00:34, FastEthernet0/1
10.10.2.0 is directly connected, FastEthernet0/1
10.10.3.0 is directly connected, FastEthernet0/0
10.10.4.0 [90/307200] via 10.10.3.2, 00:00:34, FastEthernet0/0
10.10.5.0 [90/284160] via 10.10.3.2, 00:00:34, FastEthernet0/0
[90/284160] via 10.10.2.1, 00:00:34, FastEthernet0/1
10.10.6.0 is directly connected, FastEthernet1/0
10.10.7.0 [90/309760] via 10.10.3.2, 00:00:42, FastEthernet0/0
[90/309760] via 10.10.2.1, 00:00:42, FastEthernet0/1

D
C
C
D
D
C
D

R3s routing table shows its by default load-balancing across multiple equal cost routes for subnet
10.10.5.0 and 10.10.7.0.
Maximum limit of multiple equal cost routes for load balancing can be set:
R3(config)#router eigrp 1
R3(config-router)#maximum-paths ?
<1-16> Number of paths
R3(config-router)#maximum-paths

Unequal-Cost Load Balancing:

IOS also includes the concept unequal-cost load balancing using an EIGRP setting called variance.
Variance allows routes whose metrics are relatively close in value to be considered equal, allowing
multiple unequal-metric routes to the same subnet to be added to the routing table.
The variance is multiplied by the current FD (the metric of the best route to reach the subnet).
Any Feasible Successor routes whose calculated metric is less than or equal to the product of
variance times the FD are added to the IP routing table, assuming that the maximum-paths setting
allows more routes.
Routes that are neither successor nor FS can never be added to the IP routing table, regardless of
the variance setting, because doing so may cause packets to loop.

Analyzing R3:

R3#show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.10.6.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.10.1.0/24, 1 successors, FD is 307200
via 10.10.2.1 (307200/281600), FastEthernet0/1
via 10.10.3.2 (312320/284160), FastEthernet0/0
P 10.10.2.0/24, 1 successors, FD is 281600
via Connected, FastEthernet0/1

For subnet 10.10.1.0 we have 1 successor and 1 feasible successor,

And we can see that only successor is added in the routing table below:

R3#show ip route
D
C

10.0.0.0/24 is subnetted, 7 subnets

10.10.1.0 [90/307200] via 10.10.2.1, 00:05:19, FastEthernet0/1
10.10.2.0 is directly connected, FastEthernet0/1

When we configure the variance with lets say 10, EIGRP is going to multiply the FDs of R3 (in subnet
10.10.1.0s case 307200) with 10 i.e. 307200x10 = 3072000. (This multiplication product is not shown in
routing or topology table its just an internal process.)
Now all the Feasible Successor routes (in this case there is only one i.e. 10.10.3.2 whose metric is less than
or equal to the product (3072000) are going to be added into routing table as load balancing routes as well
as back up routes:

R3#show ip route
D
C

10.0.0.0/24 is subnetted, 7 subnets

10.10.1.0 [90/312320] via 10.10.3.2, 00:00:06, FastEthernet0/0
[90/307200] via 10.10.2.1, 00:00:06, FastEthernet0/1
10.10.2.0 is directly connected, FastEthernet0/1

We can see now 10.10.3.2 is also added to the routing table despite its different metric and is load
balancing.

EIGRP Verifications
R1#show running-config
Building configuration...
Current configuration : 1203 bytes
!
key chain HusnainAliBaig
key 1
key-string HUSNAIN ALI BAIG
!
!
interface FastEthernet0/0
ip address 10.10.1.1 255.255.255.0
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 HusnainAliBaig
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.10.2.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.10.5.2 255.255.255.0
duplex auto
speed auto
!
router eigrp 1
network 10.10.1.1 0.0.0.0
network 10.10.2.1 0.0.0.0
network 10.10.5.2 0.0.0.0

no auto-summary
!

Lists following information:

Key Chain and Key String: The key string is going to be encrypted if password encryption
is enabled.
Authentication Type
Interface level EIGRP configurations
Network Statements

R1#show ip protocols
Routing Protocol is "eigrp 1"
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 100
EIGRP maximum metric variance 1
Redistributing: eigrp 1
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.10.1.1/32
10.10.2.1/32
10.10.5.2/32
Routing Information Sources:
Gateway
Distance
Last Update
10.10.2.2
90
01:28:06
10.10.1.2
90
01:28:06
10.10.5.1
90
01:28:06
Distance: internal 90 external 170

Lists following information:

EIGRP ASN (Autonomous System Number)
K-Values
Variance Multiplier
Auto-summary
Maximum Paths for Equal and Unequal-Cost Load Balancing
Network Statements
EIGRP Neighbors
EIGRP Administrative Distance

R1#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H
Address
Interface
2
1
0

10.10.2.2
10.10.1.2
10.10.5.1

Fa0/1
Fa0/0
Fa1/0

Hold Uptime
SRTT
(sec)
(ms)
13 01:04:34
48
11 01:35:32
42
14 01:35:35
72

RTO

Q
Cnt
288 0
252 0
432 0

Seq
Num
38
40
50

Lists following information:

Address: IP Address of neighboring router
Interface: Local routers interface to which the neighbor is attached
Hold: EIGRP hold timer, if local router does not receive hello within hold time its going to
consider that neighbor dead.
Uptime: Total time for which the EIGRP is running

SRTT: Smooth Round Trip Time, its the measure of delay on the interface. Not the Delay
value related to EIGRP metric in any way.
Q: Queue, waiting queue for the packets.

R1#show ip eigrp interfaces

IP-EIGRP interfaces for process 1
Xmit Queue
Interface
Peers Un/Reliable
Fa0/0
1
0/0
Fa0/1
1
0/0
Fa1/0
1
0/0

Mean
SRTT
42
48
72

Pacing Time
Un/Reliable
0/2
0/2
0/1

Multicast
Flow Timer
172
216
328

Pending
Routes
0
0
0

Lists following information:

Local Routers EIGRP enabled interfaces summary
Lists information like show ip eigrp neighbors command for local router

R1#show ip eigrp interfaces detail

IP-EIGRP interfaces for process 1
Xmit Queue
Mean
Pacing Time
Multicast
Interface
Peers Un/Reliable SRTT
Un/Reliable
Flow Timer
Fa0/0
1
0/0
42
0/2
172
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/13 Un/reliable ucasts: 18/6
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 1
Retransmissions sent: 1 Out-of-sequence rcvd: 0
Authentication mode is md5, key-chain is "HusnainAliBaig"
Use multicast
Fa0/1
1
0/0
48
0/2
216
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/8 Un/reliable ucasts: 12/8
Mcast exceptions: 2 CR packets: 2 ACKs suppressed: 1
Retransmissions sent: 1 Out-of-sequence rcvd: 0
Authentication mode is not set
Use multicast
Fa1/0
1
0/0
72
0/1
328
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/14 Un/reliable ucasts: 18/6
Mcast exceptions: 2 CR packets: 1 ACKs suppressed: 1
Retransmissions sent: 0 Out-of-sequence rcvd: 0
Authentication mode is not set
Use multicast

Lists following information:

EIGRP interface level information in detail
Hello interval
Authentication Type and Key Chain

R1#show key chain

Key-chain HusnainAliBaig:
key 1 -- text "HUSNAIN ALI BAIG"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]

Lists following information:

Key Chain

Pending
Routes
0

Key String (password)

Troubleshooting Basic EIGRP

Solving EIGRP Adjacency Failures:
Assuming that the interfaces are correctly configured, are in up/up state and neighboring
candidates are in same subnet:
Step 1: Test Connectivity using Ping
#ping x.x.x.x
Step 2: Check ASN, it must be same
#show ip protocols
Step 3: Check Network Statements
#show ip protocols
#show running-config
Step 5: Authentication, must be same
#ping show running-config
#debug eigrp packets
#show ip egrp interfaces detail
#show key chain
Step 6: K-Values, they must match
#show ip protocols
Step 7: Access Control Lists, should not block any EIGRP packets
#show ip interfaces fa0/0
#show access-list
Step 8: Check for any Passive Interface
#show ip protocols
#show running-config
Useful Debug Commands

DHCP Configurations

Configuring Router IOS as DHCP Server

Step 1: Exclude addresses from being assigned by DHCP: ip dhcp excluded-address first last
R1(config)#ip dhcp excluded-address
R1(config)#ip dhcp excluded-address
A.B.C.D Low IP address
R1(config)#ip dhcp excluded-address
A.B.C.D High IP address
<cr>
R1(config)#ip dhcp excluded-address

10.10.1.250
?
10.10.1.251 ?
10.10.1.251 10.10.1.254

Either give IP addresses one by one randomly or give in low-high range.

Step 2: Create a DHCP pool and go to pool configuration mode: ip dhcp pool name
R1(config)#ip dhcp pool ALI

A- Define subnet that the DHCP server should support: network subnet-ID mask or network
subnet-ID prefix-length
R1(dhcp-config)#network 10.10.1.0 /24

B- Define default router IP address (es) in that subnet: default-router address

R1(dhcp-config)#default-router 10.10.1.1

C- Define list of DNS server IP addresses: dns-server address

R1(dhcp-config)#dns-server 8.8.8.8

D- Define length of lease, in days, hours, and minutes: lease days hours minutes
R1(dhcp-config)#lease 1 12 59

E- Define the DNS domain name: domain-name name

R1(dhcp-config)#domain-name ali

Configuring Helper Address when DHCP Server is not in local subnet

R1(config)#int fa 0/0
R1(config-if)#ip helper-address ?
A.B.C.D
global
vrf

IP destination address
Helper-address is global
VRF name for helper-address (if different from interface VRF)

R1(config-if)#ip helper-address 10.10.3.1

Interface fa 0/0 is the default gateways interface and the helper address is the address of DHCP
server.

DHCP Verifications
R1#show ip dhcp ?
binding
conflict
database
import
pool
relay
server

DHCP address bindings

DHCP address conflicts
DHCP database agents
Show Imported Parameters
DHCP pools information
Miscellaneous DHCP relay information
Miscellaneous DHCP server information

R1#show ip dhcp binding

Bindings from all pools not associated with VRF:
IP address
Client-ID/
Lease expiration
Hardware address/
User name
10.10.1.4
0108.0027.922d.bf
Mar 01 2002 02:27 AM
10.10.1.5
0108.0027.69f9.3f
Mar 01 2002 02:27 AM

Type
Automatic
Automatic

R1#show ip dhcp pool

Pool ALI :
Utilization mark (high/low)
: 100 / 0
Subnet size (first/next)
: 0 / 0
Total addresses
: 254
Leased addresses
: 2
Pending event
: none
1 subnet is currently in the pool :
Current index
IP address range
10.10.1.6
10.10.1.1
- 10.10.1.254

R1#show ip dhcp server statistics

Memory usage
Address pools
Database agents
Automatic bindings
Manual bindings
Expired bindings
Malformed messages
Secure arp entries

32494
1
0
2
0
2
0
0

Message
BOOTREQUEST
DHCPDISCOVER
DHCPREQUEST

Received
0
9
11

Leased addresses
2

DHCPDECLINE
DHCPRELEASE
DHCPINFORM

0
0
0

Message
BOOTREPLY
DHCPOFFER
DHCPACK
DHCPNAK

Sent
0
9
0
2

R1#show run | section ip helper

ip helper-address 10.10.3.1

NAT Configurations

Static NAT Configurations

Mapping Plan
Inside
10.10.10.1
10.10.10.2

Outside
100.100.100.1
100.1001.100.2

Step 1: Specify Inside and outside interfaces

NAT(config)#int fa 0/0
NAT(config-if)#ip nat inside
NAT(config)#int se 0/0
NAT(config-if)#ip nat outside

Step 2: Statically map the inside local addresses to outside global addresses
NAT(config)#ip nat inside source ?
list
route-map
static

Specify access list describing local addresses

Specify route-map
Specify static local->global mapping

NAT(config)#ip nat inside source static ?

A.B.C.D
esp
network
tcp
udp

Inside local IP address

IPSec-ESP (Tunnel mode) support
Subnet translation
Transmission Control Protocol
User Datagram Protocol

NAT(config)#ip nat inside source static 10.10.10.1 ?

A.B.C.D
interface

Inside global IP address

Specify interface for global address

NAT(config)#ip nat inside source static 10.10.10.1 100.100.100.1 1

NAT(config)#ip nat inside source static 10.10.10.2 100.100.100.2

Verifications
Telnet from host A to the internet router:
A#telnet 100.100.100.253
Trying 100.100.100.253 ... Open
User Access Verification
Password:
Internet>show users
Line
User
0 con 0
* 66 vty 0
Interface

Host(s)
idle
idle

User

Idle
Location
00:03:04
00:00:00 100.100.100.1
Mode

Idle

Peer Address

We know that actual address of host A is 10.10.10.1, but because of NAT, the telnet connection to
the Internet router shows that the connection is coming from 100.100.100.1.

NAT#show ip nat translations

Pro Inside global
--- 100.100.100.1
--- 100.100.100.2

Inside local
10.10.10.1
10.10.10.2

Outside local
-----

Outside global
-----

NAT#show ip nat statistics

Total active translations: 2 (2 static, 0 dynamic; 0 extended)
Outside interfaces:
Serial0/0
Inside interfaces:
FastEthernet0/0
Hits: 0 Misses: 0
CEF Translated packets: 0, CEF Punted packets: 0
Expired translations: 0
Dynamic mappings:
Appl doors: 0
Normal doors: 0
Queued Packets: 0

Dynamic NAT Configurations

Step 1:

Specify Inside and outside interfaces

NAT(config)#int fa 0/0
NAT(config-if)#ip nat inside
NAT(config)#int se 0/0
NAT(config-if)#ip nat outside

Step 2:
performed

Configure an ACL that matches the packets entering inside interfaces for which NAT should be

NAT(config)#access-list 1 permit 10.10.10.1

NAT(config)#access-list 1 permit 10.10.10.2

Step 3:

Configure the pool of public registered IP addresses

NAT(config)#ip nat pool ?

WORD

Pool name

NAT(config)#ip nat pool NAT_POOL ?

A.B.C.D
netmask
prefix-length

Start IP address
Specify the network mask
Specify the prefix length

NAT(config)#ip nat pool NAT_POOL 100.100.100.1 ?

A.B.C.D

End IP address

NAT(config)#ip nat pool NAT_POOL 100.100.100.1 100.100.100.5 ?

netmask
prefix-length

Specify the network mask

Specify the prefix length

NAT(config)#ip nat pool NAT_POOL 100.100.100.1 100.100.100.5 netmask 255.255.255.0

Step 4:

Enable dynamic NAT by referencing the ACL and the Pool

NAT(config)#ip nat inside source list 1 pool NAT_POOL

Verifications

After generating some traffic by sending pings from host A and B to the Internet router:
NAT#show ip nat translations
Pro Inside global
Inside local
icmp 100.100.100.1:5
10.10.10.1:5
icmp 100.100.100.1:6
10.10.10.1:6
--- 100.100.100.1
10.10.10.1
icmp 100.100.100.2:0
10.10.10.2:0
--- 100.100.100.2
10.10.10.2

Outside local
100.100.100.2:5
100.100.100.253:6
--100.100.100.253:0
---

Outside global
100.100.100.2:5
100.100.100.253:6
--100.100.100.253:0
---

NAT#show ip nat statistics

Total active translations: 2 (0 static, 2 dynamic; 0 extended)
Outside interfaces:
Serial0/0
Inside interfaces:
FastEthernet0/0
Hits: 186 Misses: 6
CEF Translated packets: 169, CEF Punted packets: 2
Expired translations: 9
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 1 pool NAT_POOL refcount 2
pool NAT_POOL: netmask 255.255.255.0
start 100.100.100.1 end 100.100.100.5
type generic, total addresses 5, allocated 2 (40%), misses 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

Telnet from host B to the internet router shows source of telnet from 100.100.100.2:
B#telnet 100.100.100.253
Trying 100.100.100.253 ... Open
User Access Verification
Password:
Internet>show users
Line
User
0 con 0
* 66 vty 0

Host(s)
idle
idle

Idle
Location
00:42:55
00:00:00 100.100.100.2

Interface

User

Mode

Idle

Peer Address

#clear ip nat translations

#debug ip nat

PAT (NAT Overload) Configurations

Clear previous dynamic NAT translations if any:
NAT#clear ip nat translation *

Use the same steps for configuring dynamic NAT, as outlined in the previous section, but include the
overload keyword at the end of the ip nat inside source list command:
NAT(config)#ip nat inside source list 1 pool NAT_POOL overload

Troubleshooting NAT

Ensure that the configuration includes the ip nat inside and ip nat outside interface
subcommands. These commands enable NAT on the interfaces, and the inside/outside designation is
important.
For static NAT, ensure that the ip nat inside source static command lists the inside local address
first and the inside global IP address second.
For dynamic NAT, ensure that the ACL configured to match packets sent by the inside hosts match
that hosts packets, before any NAT translation has occurred. For example, if an inside local address
of 10.1.1.1 should be translated to 100.100.100.1, ensure that the ACL matches source address
10.10.10.1, not 100.100.100.1.
For dynamic NAT without PAT, ensure that the pool has enough IP addresses. Symptoms of not
having enough addresses include a growing value in the second misses counter in the show ip nat
statistics command output, as well as seeing all the pool addresses already in the NAT table.
For PAT, it is easy to forget to add the overload option on the ip nat inside source list command.
Without it, NAT works, but PAT does not, often resulting in users packets not being translated and
hosts not being able to get to the Internet.
Perhaps NAT has been configured correctly, but an ACL exists on one of the interfaces, discarding
the packets, IOS processes ACLs before NAT for packets entering an interface, and after translating
the addresses for packets exiting an interface.
Make sure that some user traffic is entering the NAT router on an inside interface, triggering NAT to
do a translation. The NAT configuration can be perfect, but if no inbound traffic occurs that matches
the NAT configuration, NAT does nothing.
NAT function on one router can be impacted by a routing problem that occurs on another router. The
routers in the outside part of the network, oftentimes the Internet, need to be able to route packets
to the inside global IP addresses configured on the NAT router.

FHRP Configurations

HSRP Configurations
Step 1:

Create and Name the Standby Group

Distribution1(config)#int fa 0/0
Distribution1(config-if)#standby ?
<0-255>
authentication
delay
ip
mac-address
name
preempt
priority
redirect
timers
track
use-bia
version

group number
Authentication
HSRP initialisation delay
Enable HSRP and set the virtual IP address
Virtual MAC address
Redundancy name string
Overthrow lower priority Active routers
Priority level
Configure sending of ICMP Redirect messages with an HSRP
virtual IP address as the gateway IP address
Hello and hold timers
Priority tracking
HSRP uses interface's burned in address
HSRP version

Distribution1(config-if)#standby 1 ?
authentication Authentication
ip
Enable HSRP and set the virtual IP address

mac-address
name
preempt
priority
timers
track

Virtual MAC address

Redundancy name string
Overthrow lower priority Active routers
Priority level
Hello and hold timers
Priority tracking

Distribution1(config-if)#standby 1 name FHRP

Distribution2(config)#int fa 0/0
Distribution2(config-if)#standby 1 name FHRP

Step 2:

Set the Virtual IP address to turn HSRP on

Distribution1(config-if)#standby 1 ip 10.10.10.10
Distribution2(config-if)#standby 1 ip 10.10.10.10

With HSRP and GLBP the interface IP address cannot be assigned as the Virtual IP, in VRRP we can.

Distribution1#show standby
FastEthernet0/0 - Group 1

State is Active
2 state changes, last state change 00:03:58
Virtual IP address is 10.10.10.10
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.916 secs
Preemption disabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
IP redundancy name is "FHRP" (cfgd)

Step 3:

Configure the Priority, Preemption, Delay and Timers

Distribution1(config-if)#standby 1 priority 110

Distribution1(config-if)#standby 1 preempt ?
delay
<cr>

Wait before preempting

Distribution1(config-if)#standby 1 preempt delay ?

minimum Delay at least this long
reload
Delay after reload
sync
Wait for IP redundancy clients

Distribution1(config-if)#standby 1 preempt delay min

Distribution1(config-if)#standby 1 preempt delay minimum ?
<0-3600>

Number of seconds for minimum delay

Distribution1(config-if)#standby 1 preempt delay minimum 50 ?

reload
sync
<cr>

Delay after reload

Wait for IP redundancy clients

Distribution1(config-if)#standby 1 preempt delay minimum 50

Distribution1(config-if)#standby 1 timers ?
<1-254> Hello interval in seconds
msec
Specify hello interval in milliseconds

Distribution1(config-if)#standby 1 timers 1 ?
<2-255>

Hold time in seconds

Distribution1(config-if)#standby 1 timers 1 5
Distribution2(config-if)#standby 1 timers 1 5

FHRP Verifications
Ping the Virtual IP address from hosts A and B:

A#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/224/1020 ms

B#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/228/1040 ms

Ping the Core router from hosts A and B:

A#ping 10.10.100.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/44 ms

A#ping 10.10.200.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.200.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/257/1056 ms

B#ping 10.10.100.2

Type escape sequence to abort.

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

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/252/1084 ms
B#ping 10.10.200.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.200.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/268/1112 ms

Verify Distribution 1:

Distribution1#show standby
FastEthernet0/0 - Group 1
State is Active
2 state changes, last state change 00:06:01
Virtual IP address is 10.10.10.10
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 1 sec, hold time 5 sec
Next hello sent in 0.092 secs
Preemption enabled, delay min 50 secs
Active router is local
Standby router is 10.10.10.253, priority 100 (expires in 4.200 sec)
Priority 110 (configured 110)
IP redundancy name is "FHRP" (cfgd)

Distribution1#show standby brief

Interface
Fa0/0

P indicates configured to preempt.

|
Grp Prio P State
Active
Standby
1
110 P Active
local
10.10.10.253

Virtual IP
10.10.10.10

Take down Distribution 1 router and analyze the events on Distribution 2:

Distribution2#
*Mar 1 00:47:09.875: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
Distribution2#
*Mar 1 00:47:17.055: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.10.254 (FastEthernet0/0) is down: holding time expired

After the Distribution 1 router goes down Distribution 2 takes over as active router.

A#ping 10.10.10.10

Type escape sequence to abort.

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

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/28 ms

A#ping 10.10.100.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/40/64 ms

A#ping 10.10.200.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.200.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/64 ms

Pings are still successful from host A and host B

Distribution2#show standby
FastEthernet0/0 - Group 1
State is Active
2 state changes, last state change 00:06:01
Virtual IP address is 10.10.10.10
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 1 sec, hold time 5 sec
Next hello sent in 0.756 secs
Preemption disabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
IP redundancy name is "FHRP" (cfgd)

This MAC address is well known FHRP MAC address.

Bring back Distribution 1 router and analyze the events:

Distribution2#debug standby events

HSRP Events debugging is on
Distribution2#
*Mar 1 01:00:00.555:
Distribution2#
*Mar 1 01:00:42.015:
*Mar 1 01:00:42.019:
*Mar 1 01:00:42.023:
*Mar 1 01:00:42.027:
*Mar 1 01:00:42.027:
Distribution2#
*Mar 1 01:00:42.031:
*Mar 1 01:00:42.039:
Distribution2#
*Mar 1 01:00:47.023:
*Mar 1 01:00:47.023:
*Mar 1 01:00:47.027:
*Mar 1 01:00:47.027:
Distribution2#
*Mar 1 01:00:47.027:

HSRP: Fa0/0 Grp 1 Standby router is 10.10.10.254

HSRP: Fa0/0 Grp 1 Active: j/Coup rcvd from higher pri router (110/10.10.10.254)
HSRP: Fa0/0 Grp 1 Active router is 10.10.10.254, was local
HSRP: Fa0/0 Grp 1 Standby router is unknown, was 10.10.10.254
HSRP: Fa0/0 Grp 1 Active -> Speak
%HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Active -> Speak
HSRP: Fa0/0 Grp 1 Redundancy "FHRP" state Active -> Speak
HSRP: Fa0/0 API MAC address update
HSRP: Fa0/0 Grp 1 Speak: d/Standby timer expired (unknown)
HSRP: Fa0/0 Grp 1 Standby router is local
HSRP: Fa0/0 Grp 1 Speak -> Standby
%HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby
HSRP: Fa0/0 Grp 1 Redundancy "FHRP" state Speak -> Standby

Distribution1#
*Mar 1 00:04:52.247: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Speak -> Standby
Distribution1#
*Mar 1 00:05:33.691: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active

As the Distribution 1 is back again after the delay timer expired, it is back to the Active state
because of Preemption configuration and higher priority.

VRRP Configurations

Step 1:

Create the VRRP Group and set the group Description Set the Virtual IP address to turn

VRRP on
Distribution1(config-if)#vrrp 1 description VRRP

Step 2:

Set the Virtual IP address to turn VRRP on

Distribution1(config-if)#vrrp 1 ?
authentication Authentication
description
Group specific description
ip
Enable Virtual Router Redundancy Protocol (VRRP) for IP
preempt
Enable preemption of lower priority Master
priority
Priority of this VRRP group
shutdown
Disable VRRP Configuration
timers
Set the VRRP timers
track
Event Tracking
Distribution1(config-if)#vrrp 1 ip 10.10.10.254
Distribution1(config-if)#
*Mar 1 00:10:11.499: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Init -> Master
Distribution2(config-if)#vrrp 1 ip 10.10.10.254
Distribution2(config-if)#
*Mar 1 00:10:06.567: %VRRP-6-STATECHANGE: Fa0/0 Grp 1 state Init -> Backup

In VRRP interface IP can be set as the Virtual IP.

State names are Master/Backup as Active/Standby in GLBP.
Tracking is more rigorous in VRRP as compared to HSRP.
Instead of Name, VRRP uses Description.

Verification
Distribution1#show vrrp
FastEthernet0/0 - Group 1
VRRP
State is Master
Virtual IP address is 10.10.10.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 255
Master Router is 10.10.10.254 (local), priority is 255
Master Advertisement interval is 1.000 sec
Master Down interval is 3.003 sec
FastEthernet0/0 - Group 1
VRRP
State is Backup
Virtual IP address is 10.10.10.254
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Master Router is 10.10.10.254, priority is 255
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec (expires in 3.033 sec)

The router on which VRRP is first enabled is by default the Master router and its priority is set to 255.
Preemption is enabled by default on all VRRP routers, we have to manually turn it off.

GLBP Configurations
Step 1:

Create and Name the Standby Group

Distribution1(config)#int fa 0/0
Distribution1(config-if)#glbp 1 ?
authentication Authentication method
forwarder
Forwarder configuration
ip
Enable group and set virtual IP address
load-balancing Load balancing method
name
Redundancy name
preempt
Overthrow lower priority designated routers
priority
Priority level
timers
Adjust GLBP timers
weighting
Gateway weighting and tracking
Distribution1(config-if)#glbp 1 name GLBP

Step 2:

Set the Virtual IP address to turn GLBP on

Distribution1(config-if)#glbp 1 ip 10.10.10.10

Configure GLBP Preemption and Delay

Distribution1(config-if)#glbp 1 forwarder preempt delay minimum 20

GLBP Load-Balancing

Distribution1(config-if)#glbp 1 load-balancing ?
host-dependent Load balance equally, source MAC determines forwarder choice
round-robin
Load balance equally using each forwarder in turn
weighted
Load balance in proportion to forwarder weighting
<cr>

GLBP Verification
Distribution1#show glbp
FastEthernet0/0 - Group 1
State is Active
2 state changes, last state change 00:08:26
Virtual IP address is 10.10.10.10
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.948 secs
Redirect time 600 sec, forwarder time-out 14400 sec
Preemption disabled
Active is local
Standby is 10.10.10.253, priority 100 (expires in 9.936 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
IP redundancy name is "GLBP"
Group members:
c00c.0560.0000 (10.10.10.253)
c00d.0560.0000 (10.10.10.254) local
There are 2 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:08:16
MAC address is 0007.b400.0101 (default)
Owner ID is c00d.0560.0000
Redirection enabled
Preemption enabled, min delay 20 sec
Active is local, weighting 100

Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is c00c.0560.0000
Redirection enabled, 599.264 sec remaining (maximum 600 sec)
Time to live: 14399.260 sec (maximum 14400 sec)
Preemption enabled, min delay 20 sec
Active is 10.10.10.253 (primary), weighting 100 (expires in 9.256 sec)

Distribution1#show glbp br
Interface
Fa0/0
Fa0/0
Fa0/0

Grp
1
1
1

Fwd
1
2

Pri
100
-

State
Active
Active
Listen

Address
10.10.10.10
0007.b400.0101
0007.b400.0102

Active router
local
local
10.10.10.253

Standby router
10.10.10.253
-

Distribution2#show glbp
FastEthernet0/0 - Group 1
State is Standby
1 state change, last state change 00:09:35
Virtual IP address is 10.10.10.10
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.608 secs
Redirect time 600 sec, forwarder time-out 14400 sec
Preemption disabled
Active is 10.10.10.254, priority 100 (expires in 8.668 sec)
Standby is local
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
IP redundancy name is "GLBP"
Group members:
c00c.0560.0000 (10.10.10.253) local
c00d.0560.0000 (10.10.10.254)
There are 2 forwarders (1 active)
Forwarder 1
State is Listen
MAC address is 0007.b400.0101 (learnt)
Owner ID is c00d.0560.0000
Time to live: 14398.668 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 10.10.10.254 (primary), weighting 100 (expires in 9.120 sec)
Forwarder 2
State is Active
1 state change, last state change 00:09:42
MAC address is 0007.b400.0102 (default)
Owner ID is c00c.0560.0000
Preemption enabled, min delay 30 sec
Active is local, weighting 100

PART 4
SEURITY

SECURITY
PART A

CONCEPTS

Layer 2 Security
Port Security

If the network engineer knows what devices should be cabled and connected to particular interfaces
on a switch, the engineer can use port security to restrict that interface so that only the expected
devices can use it.
This reduces exposure to attacks in which the attacker connects a laptop to some unused switch
port.
When that inappropriate device attempts to send frames to the switch interface, the switch can take
different actions, ranging from simply issuing informational messages to effectively shutting down
the interface.
Port security identifies devices based on the source MAC address of Ethernet frames the devices
send.
Port security also has no restrictions on whether the frame came from a local device or it was
forwarded through other switches.
The following list summarizes these ideas common to all variations of port security:
Define a maximum number of source MAC addresses allowed for all frames coming in the
interface.
Watch all incoming frames, and keep a list of all source MAC addresses, plus a counter of the
number of different source MAC addresses.
When adding a new source MAC address to the list, if the number of MAC addresses pushes
past the configured maximum, a port security violation has occurred. The switch takes action
(the default action is to shutdown the interface).

Cisco makes some general recommendations to override the default interface settings to make the
unused ports more secure, as follows:
Administratively disable the interface using the shutdown interface subcommand.
Prevent VLAN trunking by making the port a non-trunking interface using the switchport
mode access interface subcommand.
Assign the port to an unused VLAN using the switchport access vlan number interface
subcommand.
Set the native VLAN to not be VLAN 1, but to instead be an unused VLAN, using the
switchport trunk native vlan vlanid interface subcommand.

Access Control Lists

IPv4 Access Control List Basics
IPv4 ACLs perform many functions in Cisco routers, with the most common use as a packet filter, the ACL
sits in the forwarding path of packets as they pass through the router.
After it is enabled, the router considers whether each IP packet will either be discarded or allowed to
continue as if the ACL did not exist.
ACLs can be used to match packets for applying quality of service (QoS) features. QoS allows a router to
give some packets better service, and other packets worse service.

ACL Location and Direction

Cisco routers can apply ACL logic to packets at the point at which the IP packets enter an interface, or the
point at which they exit an interface, the ACL becomes associated with an interface and for a direction of
packet flow (either in or out).
That is, the ACL can be applied inbound to the router, before the router makes its forwarding (routing)
decision, or outbound, after the router makes its forwarding decision and has determined the exit interface
to use.
.

The four arrowed lines in the figure point out the location and direction for the router interfaces used to
forward the packet from host B to server S1.
In this particular example, those interfaces and direction are inbound on R1s F0/0 interface, outbound on
R1s S0/0/0 interface, inbound on R2s S0/0/1 interface, and outbound on R2s F0/0 interface.
If, for example, you enabled on ACL on R2s F0/1 interface, in either direction, that ACL could not possibly
filter the packet sent from host B to server S1, because R2s F0/1 interface is not part of the route from B to
S1.
In short, to filter a packet, you must enable an ACL on an interface that processes the packet, in the same
direction the packet flows through that interface.

Matching Packets
Generally, an ACL command uses logic like look for these values in the packet header, and if found, discard
the packet. (The action could instead be to allow the packet, rather than discard.) Specifically, the ACL
looks for header fields you should already know well, including the source and destination IP addresses, plus
TCP and UDP port numbers.

Taking Action When a Match Occurs

When using IP ACLs to filter packets, only one of two actions can be chosen. The configuration commands
use keywords deny and permit, and they mean (respectively) to discard the packet or to allow it to keep
going as if the ACL did not exist.

Types of IP ACLs
Cisco has added many ACL features, including:
Standard Numbered ACLs (199)
Extended Numbered ACLs (100199)
Additional ACL Numbers (13001999 standard, 20002699 extended)
Named ACLs
Improved Editing with Sequence Numbers

IP ACLs will be either numbered or named in that the configuration identifies the ACL either using a number
or a name. ACLs will also be either standard or extended, with extended ACLs having much more robust
abilities in matching packets.

List Logic with IP ACLs

A single ACL is both a single entity and, at the same time, a list of one or more configuration commands. As
a single entity, the configuration enables the entire ACL on an interface, in a specific direction.
As a list of commands, each command has different matching logic that the router must apply to each
packet when filtering using that ACL.
When doing ACL processing, the router processes the packet, compared to the ACL, as follows:
ACLs use first-match logic. Once a packet matches one line in the ACL, the router takes the action listed in
that line of the
ACL, and stops looking further in the ACL.
This example applies ACL 1 on R2s S0/0/1 interface, inbound.

If a packet does not match any of the items in the ACL, the packet is discarded. The reason is that every IP
ACL has a deny all statement implied at the end of the ACL. It does not exist in the configuration, but if a
router keeps searching the list, and no match is made by the end of the list, IOS considers the packet to
have matched an entry that has a deny action.

Matching Logic and Command Syntax

Standard numbered IP ACLs use the following global command:
access-list {1-99 | 1300-1999} {permit | deny} matching-parameters
Each standard numbered ACL has one or more access-list commands with the same number, any number
from the ranges shown in the preceding line of syntax. (One number is no better than the other.)
Besides the ACL number, each access-list command also lists the action (permit or deny), plus the
matching logic.

Matching the Exact IP Address

To match a specific source IP address, the entire IP address, all you have to do is type that IP address at the
end of the command.
In earlier IOS versions, the syntax included a host keyword. Instead of simply typing the full IP address, you
first typed the host keyword, and then the IP address.
Later IOS versions, if you use the host keyword, IOS accepts the command, but then removes the keyword.
access-list 1 permit host 10.1.1.1

Matching a Subset of the Address with Wildcards

IOS allows standard ACLs to match a range of addresses using a tool called a wildcard mask.

This is not a subnet mask. The wildcard mask tells IOS to ignore parts of the address when making
comparisons, essentially treating those parts as wildcards, as if they already matched.
You can think about WC masks in decimal and in binary, and both have their uses. To begin, think about WC
masks in decimal, using these rules:
Decimal 0: The router must compare this octet as normal.
Decimal 255: The router ignores this octet, considering it to already match.

The WC mask causes IOS to compare only some of the octets, while ignoring other octets.
All three examples result in a match, because each wildcard mask tells IOS to ignore some octets.
The example on the left shows WC mask 0.0.0.255, which tells the router to treat the last octet as a
wildcard, essentially ignoring that octet for the comparison.
Similarly, the middle example shows WC mask 0.0.255.255, which tells the router to ignore the two octets
on the right.
The rightmost case shows WC mask 0.255.255.255, telling the router to ignore the last three octets when
comparing values.

Binary Wildcard Masks

Wildcard masks, as dotted-decimal number (DDN) values, actually represent a 32-bit binary number. As a
32-bit number, the WC mask actually directs the routers logic bit by bit. In short, a WC mask bit of 0 means
the comparison should be done as normal, but a binary 1 means that the bit is a wildcard, and can be
ignored when comparing the numbers.
For most real-world applications, you can ignore the binary WC mask, we generally want to match a range
of addresses that can be easily identified by a subnet number and mask, whether it be a real subnet, or a
summary route that groups subnets together.
If you really want to know the binary mask logic, take the two DDN numbers the ACL will compare (one from
the access-list command, and the other from the packet header) and convert both to binary. Then, also
convert the WC mask to binary. Compare the first two binary numbers bit by bit, but also ignore any bits for
which the WC mask happens to list a binary 1, because that tells you to ignore the bit. If all the bits you
checked are equal, its a match!

Finding the Right Wildcard Mask to Match a Subnet

In many cases, an ACL needs to match all hosts in a particular subnet. To match a subnet with an ACL, you
can use the following shortcut:
Use the subnet number as the source value in the access-list command.
Use a wildcard mask found by subtracting the subnet mask from 255.255.255.255.
For example, for subnet 172.16.8.0 255.255.252.0, use the subnet number (172.16.8.0) as the address
parameter, and then do the following math to find the wildcard mask:

Matching Any/All Addresses

In some cases, you will want one ACL command to match any and all packets that reach that point in the
ACL. First, you have to know the (simple) way to match all packets using the any keyword. More
importantly, you need to think about when to match any and all packets.

First, to match any and all packets with an ACL command, just use the any keyword for the address. For
example, to permit all packets:
access-list 1 permit any
Cisco IP ACLs end with an implicit deny any concept at the end of each ACL. That is, if a router compares a
packet to the ACL, and the packet matches none of the configured statements, the router discards the
packet, to override that default behavior configure a permit any at the end of the ACL.
ACL show commands list counters for the number of packets matched by each command in the ACL, but
there is no counter for that implicit deny any concept at the end of the ACL, if you want to see counters for
how many packets are matched by the deny any logic at the end of the ACL, configure an explicit deny
any.
Following list summarizes some important tips to consider when choosing matching parameters to any
access-list command:
To match a specific address, just list the address.
To match any and all addresses, use the any keyword.
To match based only on the first one, two, or three octets of an address, use the 0.255.255.255,
0.0.255.255, and
0.0.0.255 WC masks, respectively. Also, make the source (address) parameter have 0s in the wildcard
octets (those octets with 255 in the wildcard mask).
To match a subnet, use the subnet ID as the source, and find the WC mask by subtracting the DDN subnet
mask from
255.255.255.255.

Reverse Engineering from ACL to Address Range

To interpret some existing access-list commands, you need to determine the range of IP addresses
matched by a particular address/wildcard mask combination in each ACL statement.
The low end of the range is the address field, and you find the high end of the range by adding the address
to the WC mask
With the command access-list 1 permit 172.16.200.0 0.0.7.255, the low end of the range is simply
172.16.200.0, taken directly from the command itself. Then, to find the high end of the range, just add this
number to the WC mask, as follows:

IOS lets the CLI user type an access-list command in configuration mode, and IOS will potentially change
the address parameter before placing the command into the running config file.
This process of just finding the range of addresses matched by the access-list command expects that the
access-list command came from the router, so that any such changes were complete.
The change IOS can make with an access-list command is to convert to 0 any octet of an address for
which the wildcard masks octet is 255. For example, with a wildcard mask of 0.0.255.255, IOS ignores the
last two octets. IOS expects the address field to end with two 0s. If not, IOS still accepts the access-list
command, but IOS changes the last two octets of the address to 0s.
The math to find the range of addresses relies on the fact that either the command is fully correct, or that
IOS has already set these address octets to 0.
The most useful WC masks, in binary, do not interleave 0s and 1s. WC masks that interleave 0s and 1s are
allowed, but these WC masks break the simple method of calculating the range of addresses.

Extended Access Control Lists

Extended Numbered IP Access Control Lists

Extended IP access lists have many similarities compared to the standard numbered IP ACLs. Just like
standard IP ACLs, you enable extended access lists on interfaces for packets either entering or exiting the
interface.
IOS searches the list sequentially. Extended ACLs also use first-match logic, because the router stops the
search through the list as soon as the first statement is matched, taking the action defined in the firstmatched statement.
Extended ACLs differ from standard ACLs mostly because of the larger variety of packet header fields that
can be used to match a packet. One extended ACL statement can examine multiple parts of the packet
headers, requiring that all the parameters be matched correctly to match that one ACL statement. That
powerful matching logic makes extended access lists both more useful and more complex than standard IP
ACLs.

Matching the Protocol, Source IP, and Destination IP

The syntax is identical, at least up through the permit or deny keyword.
Extended ACL access-list command requires three matching parameters:
the IP protocol type,
the source IP address,
and the destination IP address.
For the protocol type you simply use a keyword, such as tcp, udp, or icmp, matching IP packets that
happen to have a TCP, UDP, or ICMP header, respectively, following the IP header.
Or you can use the keyword ip, which means all ip packets.
You also must configure some values for the source and destination IP address fields which follow; these
fields use the same syntax and options for matching the IP addresses.

When matching IP addresses in the source and destination fields, there is one difference with standard
ACLs:
When matching a specific IP address, the extended ACL requires the use of the host keyword. You cannot
simply list the IP address alone.

The last entry in Table helps make an important point about how IOS processes extended ACLs:
In an extended ACL access-list command, all the matching parameters must match the packet for the
packet to match the command.
For example, in that last example from Table, the command checks for UDP, a source IP address from
subnet 1.1.1.0/24, and any destination IP address. If a packet with source IP address 1.1.1.1 were
examined, it would match the source IP address check, but if it had a TCP header instead of UDP, it would
not match this access-list command. All parameters must match.

Matching TCP and UDP Port Numbers

Extended ACLs can also examine parts of the TCP and UDP headers, particularly the source and destination
port number fields. The port numbers identify the application that sends or receives the data.
When an extended ACL command includes either the tcp or udp keyword, that command can optionally
reference the source and/or destination port.
To make these comparisons, the syntax uses keywords for equal, not equal, less than, greater than, and for
a range of port numbers.
Additionally, the command can use either the literal decimal port numbers, or more convenient keywords
for some well-known application ports.

The FTP server sits on the right, with the client on the left. The figure shows the syntax of an ACL that
matches the following:
Packets that include a TCP header
Packets sent from the client subnet
Packets sent to the server subnet
Packets with TCP destination port 21 (FTP server control port)

Filtering Packet Based on Destination Port

To fully appreciate the matching of the destination port with the eq 21 parameters, consider packets
moving from left to right, from PC1 to the server. Assuming the server uses well-known port 21 (FTP control
port), the packets TCP header has a destination port value of 21.
The ACL syntax includes the eq 21 parameters after the destination IP address. The position after the
destination address parameters is important: That position identifies the fact that the eq 21 parameters
should be compared to the packets destination port.
As a result, the ACL statement shown in Figure above would match this packet, and the destination port of
21, if used in any of the four locations implied by the four dashed arrowed lines in the figure.
Conversely, Figure below shows the reverse flow, with a packet sent by the server back toward PC1. In this
case, the packets TCP header has a source port of 21, so the ACL must check the source port value of 21,
and the ACL must be located on different interfaces.
In this case, the eq 21 parameters follow the source address field, but comes before the destination

address field.
First consider the location and direction in which the ACL will be applied. That direction determines whether
the packet is being sent to the server, or from the server.
At that point, you can decide whether you need to check the source or destination port in the packet,
assuming you want to check the well-known port used by that service.
The syntax of the access-list commands accepts both the port numbers and a shorthand version of the
application name.
You must choose the location and direction in which to enable the ACL, particularly the direction, so that

you can characterize whether certain addresses and ports will be either the source or destination.
Configure the ACL using access-list commands, and when complete, then enable the ACL using the same
ip access-group command used with standard ACLs.
All these steps mirror what you do with standard ACLs; however, when configuring, keep the following
differences in mind:

Place extended ACLs as close as possible to the source of the packets that will be filtered. Filtering close to
the source of the packets saves some bandwidth.
Remember that all fields in one access-list command must match a packet for the packet to be considered
to match that access-list statement.
Use numbers of 100199 and 20002699 on the access-list commands; no one number is inherently better
than another.

Named IP Access Lists

IOS support for ACLs: named ACLs and ACL editing with sequence numbers, neither adds any function as to
what a router can and cannot filter. Instead, named ACLs and ACL sequence numbers make it easier to
remember ACL names and edit existing ACLs when an ACL needs to change.
Named ACLs originally had three big differences compared to numbered ACLs:
Using names instead of numbers to identify the ACL, making it easier to remember the reason for the ACL
Using ACL subcommands, not global commands, to define the action and matching parameters
ACL editing features that allow the CLI user to delete individual lines from the ACL and insert new lines
You can easily learn named ACL configuration by just converting numbered ACLs to use the equivalent
named ACL configuration.
The only truly new part of the named ACL configuration is the ip access-list global configuration
command. This command defines whether an ACL is a standard or extended ACL, and defines the name. It
also moves the user to ACL configuration mode.
Once in ACL configuration mode, you configure permit, deny, and remark commands that mirror the
syntax of numbered ACL access-list commands. If configuring a standard named ACL, these commands
match the syntax of standard numbered ACLs; if configuring extended named ACLs, they match the syntax
of extended numbered ACLs.

Editing ACLs Using Sequence Numbers

ACL sequence numbers provide the following features for both numbered and named ACLs:
New Configuration Style for Numbered: Numbered ACLs use a configuration style like named ACLs, as
well as the traditional style, for the same ACL; the new style is required to perform advanced ACL editing.
Deleting Single Lines: An individual ACL permit or deny statement can be deleted with a no sequencenumber subcommand.
Inserting New Lines: Newly added permit and deny commands can be configured with a sequence
number, dictating the location of the statement within the ACL.
Automatic Sequence Numbering: IOS adds sequence numbers to commands as you configure them,
even if you do not include the sequence numbers.

Password Protections for the CLI

IOS can require a password to get into the CLI, or move to a different mode: the console, vty, and to move
from user to enable mode.
The following list summarizes some recommendations for how to secure a router or switch CLI:
Use the enable secret command, instead of the combination of the enable password command plus the
service password-encryption command. Both result in what looks like a scrambled password when
displayed with the show running-config command. However, the enable secret command uses stronger
password encryption, while passwords encrypted with the service password-encryption command can
be easily broken.
Avoid using simple password checking for the console or VTYs with the login line-mode command, because
this method does not identify individual users.
Optimally, authenticate CLI logins using an external authentication server, like a RADIUS server. However, if
necessary, use locally configured username secret commands, which hides the passwords with a hash (as
does the enable secret command).

Disable support for inbound Telnet connections, because Telnet sends the passwords as clear text, opening
up the possibility of someone capturing the packets and stealing the password. Instead, configure the
router and switch to allow SSH only, using the transport input ssh command in VTY line mode.
Maintain solid physical security for your networking devices.
The devices should be in a secured area, where only authorized personnel can physically reach the devices.
Once an attacker gains physical access to a router or switch, they can remove cables, power off devices,
and even reset passwords from the console, allowing them to access the devices remotely at a later time.

Disable Services
Cisco IOS supports a graphical user interface (GUI) to do the same work as done at the CLI. To make that
work, IOS acts as a web server. By default, IOS enables an HTTP web service that does not encrypt data
(HTTP), with an option to configure an HTTP service that does encrypt data (HTTPS). The recommendation?
Disable the HTTP service, and only enable the HTTPS service if you intend to allow users to connect to the
router or switch using a web browser.
Cisco Discovery Protocol (CDP) allows devices on the same link to learn basic information from each other,
Cisco suggests disabling CDP on all interfaces connected to untrusted parts of the network. To be even
more secure, CDP could be disabled globally.
Some IOS versions leave these services enabled by default, while some do not. To be thorough, disable both
TCP and UDP small services.
! Disable the HTTP service
R1(config)# no ip http server
! Disable small services, both TCP and UDP
R1(config)# no service tcp-small-servers
R1(config)# no service udp-small-servers
! Disable CDP on one interface only; no cdp run would disable
! CDP globally
R1(config)# interface gigabitEthernet 0/0
R1(config-if)# no cdp enable
R1(config-if)# ^Z

Controlling Telnet and SSH Access with ACLs

When an external user connects to a router or switch using Telnet or SSH, IOS uses a vty line to represent
that user connection. IOS can apply an ACL to those inbound connections by applying an ACL to the vty line,
filtering the addresses from which IPv4 hosts can telnet or SSH into the router or switch.
vty Access Control Using the access-class Command
line vty 0 4
login
password cisco
access-class 3 in
Next command is a global command that matches IPv4 packets with a source address that begins with
10.1.1.
access-list 3 permit 10.1.1.0 0.0.0.255
The access-class command refers to the matching logic in access-list 3. The keyword in refers to Telnet
and SSH connections into this routerin other words, people telnetting into this router. As configured, ACL 3
checks the source IP address of packets for incoming Telnet connections.
IOS also supports using ACLs to filter outbound Telnet and SSH connections. For example, consider a user
who first uses telnet or SSH to connect to the CLI, and now sits in user or enable mode. With an outbound
vty filter, IOS will apply ACL logic if the user tries the telnet or ssh commands to connect out of the local
device to another device.
To configure an outbound VTY ACL, use the access-class acl out command in VTY configuration mode.
Once configured, the router filters attempts by current vty users to use the telnet and ssh commands to
initiate new connections to other devices.

When using the out keyword, the standard IP ACL listed in the ip access-class command actually looks at
the destination
IP address, and not the source. That is, it filters based on the device to which the telnet or ssh command is
trying to connect.

ACL Implementation Considerations

Cisco makes the following general recommendations:
Place extended ACLs as close as possible to the source of the packet to discard the packets quickly.
Place standard ACLs as close as possible to the packets destination, because standard ACLs often discard
packets that you do not want discarded when they are placed close to the source.
Place more specific statements early in the ACL.
Disable an ACL from its interface (using the no ip access-group command) before making changes to the
ACL.
The first point deals with the concept of where to locate your ACLs. If you intend to filter a packet, filtering
closer to the packets source means that the packet takes up less bandwidth in the network, which seems
to be more efficientand it is.
Therefore, Cisco suggests locating extended ACLs as close to the source as possible.
However, the second point seems to contradict the first point, at least for standard ACLs, to locate them
close to the destination, because standard ACLs look only at the source IP address, they tend to filter more
than you want filtered when placed close to the source.
For the third item in the list, by placing more specific matching parameters early in each list, you are less
likely to make mistakes in the ACL
Finally, Cisco recommends that you disable the ACLs on the interfaces before you change the statements in
the list, as soon as you add a command to the ACL, the IOS starts filtering packets.

Network Time Protocol

To solve an operational problem with log messages that occur on routers and switches. Solving this problem
might not appear to be related to security at first, but it actually does play a key role at looking for and
correlating the evidence that some kind of attack has happened.
Routers and switches issue log messages in response to different events. For example, when an interface
fails, the device creates log messages. With default settings, IOS sends these messages to the console port.
IOS can be configured to handle log messages in a variety of ways. One option to handle log messages uses
a service called a Syslog server, where the routers and switches forward copies of all log messages to the
Syslog server. The Syslog server saves copies of the messages, from all devices. With a centralized location,
the network support staff can later look at the messages from all devices, and look at messages that
happen at the same time, to discover if a problem has occurred.
Each device has a time-of-day clock, and most log messages list the date and time as part of the message.
So that when a network engineer looks back at the message, the engineer knows exactly when that
message occurred.
Network Time Protocol (NTP) gives any device type, routers and switches included, a way to synchronize
their time-of-day clocks. If all the network devices synchronize their clocks, then messages that list the
date/time can be viewed so you know which messages happened around the same time, making
troubleshooting easier.

Virtual Private Network

Even when sending data over public networks like the Internet, VPNs can provide the following:
Confidentiality (Privacy): Preventing anyone in the middle of the Internet (man in the middle) from being
able to read the data
Authentication: Verifying that the sender of the VPN packet is a legitimate device and not a device used
by an attacker

Data integrity: Verifying that the packet was not changed as the packet transited the Internet
Anti-replay: Preventing a man in the middle from copying and later replying the packets sent by a
legitimate user, for the purpose of appearing to be a legitimate user
To accomplish these goals, two devices near the edge of the Internet create a VPN, sometimes called a VPN
tunnel.
These devices add headers to the original packet, with these headers including fields that allow the VPN
devices to perform all the functions.
The VPN devices also encrypt the original IP packet, meaning that the original packets contents are
undecipherable to anyone who happens to see a copy of the packet as it traverses the Internet.
Figure shows the general idea of what typically occurs with a VPN tunnel. The figure shows a VPN created
between a branch office router and a Cisco Adaptive Security Appliance (ASA). In this case, the VPN is
called a site-to-site VPN because it connects two sites of a company. This VPN is also called a site-to-site

intranet VPN because it connects sites that belong inside a single company.
The figure shows the following steps, which explain the overall flow in the figure:
1. Host PC1 (10.2.2.2) on the right sends a packet to the web server (10.1.1.1), just as it would without a
VPN.
2. The router encrypts the packet, adds some VPN headers, adds another IP header (with public IP
addresses), and forwards the packet.
3. A man in the middle copies the packet, but cannot change the packet without being noticed, and cannot
read the contents of the original packet.
4. ASA-1 receives the packet, confirms the authenticity of the sender, confirms that the packet has not
been changed, and then decrypts the original packet.
5. Server S1 receives the unencrypted packet.
The term tunnel generically refers to any protocols packet that is sent by encapsulating the packet inside
another packet. The term VPN tunnel implies that the encapsulated packet has been encrypted, whereas
the term tunnel does not imply whether the packet has been encrypted.
Types of VPNs

To build a VPN, one device at each site needs to have hardware/software that understands a chosen set of
VPN security standards and protocols. The devices include the following:
Routers: In addition to packet forwarding, the router can provide VPN functions. The router can have
specialized addon cards that help the router perform the encryption more quickly.
Adaptive Security Appliances (ASA): The Cisco leading security appliance that can be configured for
many security functions, including acting as a VPN concentrator, supporting large numbers of VPN tunnels.
VPN client: For remote-access VPNs, the PC might need to do the VPN functions; the laptop needs
software to do those functions, with that software being called a VPN client.

When comparing VPNs to other WAN technologies, VPNs have several advantages. For instance, consider a
company with 1000 small retail locations. The company could create a private WAN using leased lines, or
Frame Relay, Ethernet WAN,
Multiprotocol Label Switching (MPLS), and so on. However, each branch could instead have an Internet
connection and use
VPN technology, usually saving money over the other WAN options.
Here are some of the benefits:
Cost: Internet VPN solutions can be cheaper than alternative private WAN options.
Security: Internet VPN solutions can be as secure as private WAN connections.
Scalability: Internet VPN solutions scale to many sites at a reasonable cost. Each site connects via any
Internet connection, with most business locations having multiple competitive options to choose from for
Internet access.

IPsec VPNs
IPsec is an architecture or framework for security services for IP networks. The name itself is not an
acronym, but rather a name derived from the title of the RFC that defines it (RFC 4301, Security
Architecture for the Internet Protocol), more generally called IP Security, or IPsec.
IPsec defines how two devices, both connected to the Internet, can achieve the main goals of a VPN as:
confidentiality, authentication, data integrity, and anti-replay.
IPsec does not define just one way to implement a VPN, instead allowing several different protocol options
for each VPN feature. One of IPsecs strengths is that its role as an architecture allows it to be added to and
changed over time as improvements to individual security functions are made.
IPsec encryption uses a pair of encryption algorithms, which are essentially math formulas, to meet a
couple of requirements. First, the two math formulas are a matched set:
One to hide (encrypt) the data
Another to re-create (decrypt) the original data based on the encrypted data Besides those somewhat
obvious functions, the two math formulas were chosen so that if you intercept the encrypted text but do not
have the secret password (called an encryption key), decrypting that one packet would be difficult.
In addition, the formulas are also chosen so that if an attacker did happen to decrypt one packet, that
information would not give the attacker any advantages in decrypting the other packets.
Encryption key is also known as the session key, shared key, or shared session key.

The four steps highlighted in the figure are as follows:

1. The sending VPN device (like the remote office router in Figure 7-1) feeds the original packet and the
session key into the encryption formula, calculating the encrypted data.
2. The sending device encapsulates the encrypted data into a packet, which includes the new IP header
and VPN header.
3. The sending device sends this new packet to the destination VPN device (ASA-1 back in Figure 7-1).
4. The receiving VPN device runs the corresponding decryption formula, using the encrypted data and
session keythe same key value as was used on the sending VPN deviceto decrypt the data.

SSL VPNs
The Secure Socket Layer (SSL) protocol serves as an alternative VPN technology to IPsec.
Web browsers support SSL as a way to dynamically create a secure connection from the web browser to a
web server, supporting safe online access to financial transactions.
Web browsers use HTTP as the protocol with which to connect to web servers. However, when the
communications with the web server need to be secure, the browser switches to use SSL.
SSL uses well-known port 443, encrypting data sent between the browser and the server and authenticating
the user. Then, the HTTP messages flow over the SSL VPN connection.
The built-in SSL functions of a web browser create one secure web browsing session, but this same SSL
technology can be used create a remote access VPN using a Cisco VPN client.
The Cisco AnyConnect VPN client is software that sits on a users PC and uses SSL to create one end of a
VPN remote-access tunnel. As a result, all the packets sent to the other end of the tunnel are encrypted, not
just those sent over a single HTTP connection in a web browser.
Many types of devices can sit on the server side of an SSL connection as well. The web server can be the
endpoint of an SSL connection from a web browser, but often, to improve server performance, the SSL
tunnel on the server side terminates on specialized devices like the Cisco ASA.
Figure combines all the SSL concepts into one example with two SSL tunnels. One SSL VPN tunnel connects
a web browser at host A to the ASA on the right, supporting a single web browsing session. Host B uses the
Cisco VPN client, so all packets from host B to the site on the right will be secured over the SSL connection.

GRE Tunnels
The device on the endpoint of a VPN takes a normal unencrypted packet and performs several functions
before forwarding that packet.
One of those functions is to encrypt the packet, and another is to encapsulate the packet in a new IP
header. The new
IP header uses addresses that allow the routers in the unsecured network between the two VPN tunnel
endpoints to forward the VPN IP packet.
The original IP packet, including the original IP header, is encrypted and unreadable.

GRE Tunnel Concepts

One type of IP tunnel: generic routing encapsulation (GRE). GRE, defined in RFC 2784, defines an additional
header, along with the new IP header, that encapsulates the original packet.
Two routers work together, with matching configuration settings, to create a GRE IP tunnel. Then, IPsec
configuration can be added to encrypt the traffic.

Routing over GRE Tunnels

A GRE tunnel exists between two routers, with the tunnel working very much like a serial link with regard to

packet forwarding.
GRE creates a concept that works just like the serial link in Figure above, at least with regard to IP routing.
Instead of a serial link with serial interfaces, the routers use virtual interfaces called tunnel interfaces. The
two routers have IP addresses on their tunnel interfaces in the same subnet. Figure below shows an
example where the serial link has been replaced with these virtual tunnel interfaces.

The tunnel looks like just another link in the secure part of the network.
The tunnel IP addresses are from the secure enterprise network. The routers encapsulate the original packet
inside a tunnel header, which takes the place of the serial links HDLC header. And the routers will even
have routes that list the tunnel interfaces (Tunnel0 and Tunnel1 in this case) as the outgoing interfaces.
To make use of the GRE tunnel, the routers treat it like any other link with a point-to-point topology. The
routers have IPv4 addresses in the same subnet. The routers using a routing protocol become neighbors
and exchange routes over the tunnel.
And the routes learned over the tunnel list the tunnel interface as the outgoing interface, with the
neighboring routers tunnel interface IP address as the next-hop router. Figure 7-7 shows an example, with
the routes learned by each router listed at the bottom.

R2 will have a connected route to that subnet. R1 and R2 will use some routing protocol (for instance, OSPF)
to exchange routing information. R1 will add a new route for subnet 10.1.2.0/24, and that route will list R1s
own tunnel interface, Tunnel0, as the outgoing interface.
That route lists R2s tunnel interface IP address, 10.1.3.2, as the next hop router, as shown in R1s IP
routing table on the bottom-left part of the figure.

GRE Tunnels over the Unsecured Network

The tunnel can exist over any IP network. The tunnel is created using an IP network to forward the original
packets, so any IP network between routers R1 and R2 would allow the tunnel to exist.
Often, site-to-site VPNs, like the one shown in Figure below, use an unsecured network like the Internet as

the IP network.
The routers on the ends of the GRE tunnel create the tunnel by agreeing to send each other packets over
the unsecure network between the two. The figure shows the interfaces R1 and R2 each use to connect to
the Internet. And it shows the IP addresses each router uses on their Internet connections, in this case
1.1.1.1 and 2.2.2.2.
The router configuration uses virtual interfaces called tunnel interfaces. These interfaces do not exist until
the engineer creates the tunnel with the interface tunnel command.
For instance, the command interface tunnel 0 creates a tunnel interface numbered as 0. To create a
tunnel, both routers create a tunnel interface and use IP addresses as if the tunnel were a point-to-point
link.
Figure below shows a conceptual diagram of a packet coming into router R1 from PC1, one that needs to be
forwarded over the
GRE tunnel to server S1 (10.1.2.2). When the router uses its IP routing logic from the secured part of the
network.
R1 wants to send the packet over the tunnel. Figure shows the encapsulation done by R1.

If the two routers creating this tunnel also configured the IPsec encryption part of the tunnel, before
encapsulating the original packet, the sending router would first encrypt the packet.
GRE specifies the use of two headers to create the tunnel. GRE defines its own header, used to manage the
tunnel itself. GRE also defines the use of a complete 20-byte IP header, called the delivery header. This
header will use IP addresses from the unsecure network. In this case, the delivery IP header will list R1s
1.1.1.1 Internet IP address as the source and R2s 2.2.2.2 Internet IP address as the destination.
While this packet passes through the Internet, the routers in the Internet use this outer GRE delivery IP
header to route the packet. The fact that this packet happens to hold another entire IP packet inside does
not matter to the IP forwarding process in those routers; they just forward the IP packet based on the
2.2.2.2 destination IP address. Figure below shows the concept; note that this packet may be routed by

many routers in the Internet before arriving at R2.

When the GRE packet in Figure above finally arrives on the right side of the Internet, at R2, R2 needs to
extract the original IP packet. With physical links, R2 would normally simply remove the old incoming data

link header. With a GRE-encapsulated packet, the receiving router (R2) also needs to remove the delivery
header and the GRE header, leaving the original packet, as shown in Figure below.

SECURITY
PART B

CONFIGURATIONS

Port Security Configurations

AccessSW#show mac-address-table
Mac Address Table
------------------------------------------Vlan
---1
1
1
1
1
1

Mac Address
-----------

Type
--------

Ports
-----

aaaa.aaaa.0001
aaaa.aaaa.0002
aaaa.aaaa.0003
aaaa.aaaa.0010
aaaa.aaaa.0011
aaaa.aaaa.0012

DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC
DYNAMIC

Fa0/4
Fa0/4
Fa0/4
Fa0/1
Fa0/2
Fa0/3

<PC1
<PC2
<PC3
<Server
<Workstation
<Laptop

Step 1: Configure all end device ports as access ports

AccessSW(config)#int range fastEthernet 0/1 - 4
AccessSW(config-if-range)#switchport mode access

Step 2: Enable port security on fa0/1, statically add mac address and set violation
policy as shutdown
AccessSW(config)#int fastEthernet 0/1
AccessSW(config-if)#switchport port-security
AccessSW(config-if)#switchport port-security mac-address aaaa.aaaa.0010
AccessSW(config-if)#switchport port-security violation shutdown

Step 3: Enable port security on fa0/2, dynamically add mac address and set violation
policy as protect
AccessSW(config)#int fastEthernet 0/2
AccessSW(config-if)#switchport port-security
AccessSW(config-if)#switchport port-security mac-address sticky
AccessSW(config-if)#switchport port-security violation protect

Step 4: Enable port security on fa0/2 and set violation policy as restrict

AccessSW(config)#int fastEthernet 0/3

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

Step 3: Enable port security on fa0/2, set maximum addresses to 3, dynamically add
mac address and set violation policy as restrict
AccessSW(config)#int fastEthernet 0/4
AccessSW(config-if)#switchport port-security
AccessSW(config-if)#switchport port-security maximum 3
AccessSW(config-if)#switchport port-security mac-address sticky
AccessSW(config-if)#switchport port-security violation restrict

Port Security Verifications

AccessSW#show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count)
(Count)
(Count)
-------------------------------------------------------------------Fa0/1
1
1
0
Shutdown
Fa0/2
1
0
0
Protect
Fa0/3
1
0
0
Restrict
Fa0/4
3
0
0
Restrict
----------------------------------------------------------------------

AccessSW#show port-security interface fa0/4

Port Security
Port Status
Violation Mode
Aging Time
Aging Type
SecureStatic Address Aging
Maximum MAC Addresses
Total MAC Addresses
Configured MAC Addresses
Sticky MAC Addresses
Last Source Address:Vlan
Security Violation Count

:
:
:
:
:
:
:
:
:
:
:
:

Enabled
Secure-up
Restrict
0 mins
Absolute
Disabled
3
0
0
0
0000.0000.0000:0
0

After violation on port fa0/1:

AccessSW#show port-security interface fastEthernet 0/1

Port Security
Port Status
Violation Mode
Aging Time
Aging Type
SecureStatic Address Aging
Maximum MAC Addresses
Total MAC Addresses
Configured MAC Addresses
Sticky MAC Addresses
Last Source Address:Vlan
Security Violation Count

:
:
:
:
:
:
:
:
:
:
:
:

Enabled
Secure-shutdown
Shutdown
0 mins
Absolute
Disabled
1
1
1
0
0002.1635.2030:1
1

ACL Configurations

Standard ACL Configurations

Task 1:

Deny internet access only to Finance_PC

IT(config)#access-list ?
<1-99>
IP standard access list
<100-199>
IP extended access list
<1000-1099>
IPX SAP access list
<1100-1199>
Extended 48-bit MAC address access list
<1200-1299>
IPX summary address access list
<1300-1999>
IP standard access list (expanded range)
<200-299>
Protocol type-code access list
<2000-2699>
IP extended access list (expanded range)
<300-399>
DECnet access list
<600-699>
Appletalk access list
<700-799>
48-bit MAC address access list
<800-899>
IPX standard access list
<900-999>
IPX extended access list
dynamic-extended Extend the dynamic ACL absolute timer
rate-limit
Simple rate-limit specific access list
IT(config)#access-list 1 ?
deny
Specify packets to reject

permit Specify packets to forward

remark Access list entry comment
IT(config)#access-list 1 deny 10.10.4.2 ?
A.B.C.D Wildcard bits
log
Log matches against this entry
<cr>
IT(config)#access-list 1 deny 10.10.4.2 0.0.0.0 (IT(config)#access-list 1 deny host 10.10.4.2)
IT(config)#access-list 1 permit any
IT(config)#end
IT(config)#int serial 0/0
IT(config-if)#ip access-group ?
<1-199>
IP access list (standard or extended)
<1300-2699> IP expanded access list (standard or extended)
WORD
Access-list name
IT(config-if)#ip access-group 1 ?
in
inbound packets
out outbound packets
IT(config-if)#ip access-group 1 out

Standard is to be placed Close to the destination, Serial 0/0 is closest to the destination 10.10.7.2
Access-group 1 denotes access-list 1
In case of host, wildcard 0.0.0.0 can be given or simply give keyword host before host ip

Verifications
Finance_PC#ping 10.10.6.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.6.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/93/104 ms

Finance_PC#ping 10.10.7.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.7.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Management_PC#ping 10.10.7.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.7.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/58/72 ms

IT#show access-lists
Standard IP access list 1
10 deny
10.10.4.2 (8 matches)
20 permit any (10 matches)
IT#show ip int se0/0
Serial0/0 is up, line protocol is up
Internet address is 10.10.7.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is 1
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled

Security level is default

Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF Feature Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled

Task 2:

Deny whole Finance subnet 10.10.4.0 access to whole Management

LAN subnet using Standard Named ACL in new syntax:
Management(config)#ip access-list standard DENY_FINANCE
Management(config-std-nacl)#deny 10.10.4.0 0.0.0.255
Management(config-std-nacl)#permit any
Management(config-std-nacl)#exit
Management(config)#int fa1/0
Management(config-if)#ip access-group DENY_FINANCE out
Management(config-if)#end
Management#show ip access-lists
Standard IP access list DENY_FINANCE
10 deny
10.10.4.0, wildcard bits 0.0.0.255
20 permit any
Management#show ip int fastEthernet 1/0
FastEthernet1/0 is up, line protocol is up
Internet address is 10.10.5.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is DENY_FINANCE
Inbound access list is not set
Finance#ping 10.10.5.2 so
Finance#ping 10.10.5.2 source 10.10.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.5.2, timeout is 2 seconds:
Packet sent with a source address of 10.10.4.1
U.U.U
Success rate is 0 percent (0/5)

Extended ACL Configurations

Task 1: Only Management PC should be allowed web access to Secure Server, no
one other from the Management LAN, Finance or Internet should be able to use web
browser to use this server. Since there is also Public Printer and other public resources
in the subnet, all other traffic should be allowed.
Command Format is:
access-list|number|permit/deny|protocol|source address|source wildcard|eq/gt/lt |source port|
destination address|destination wildcard| eq/gt/lt| destination port
IT(config)#access-list ?
<1-99>
<100-199>
<1000-1099>
<1100-1199>
<1200-1299>
<1300-1999>
<200-299>
<2000-2699>
<300-399>
<600-699>
<700-799>
<800-899>
<900-999>
dynamic-extended
rate-limit

IP standard access list

IP extended access list
IPX SAP access list
Extended 48-bit MAC address access list
IPX summary address access list
IP standard access list (expanded range)
Protocol type-code access list
IP extended access list (expanded range)
DECnet access list
Appletalk access list
48-bit MAC address access list
IPX standard access list
IPX extended access list
Extend the dynamic ACL absolute timer
Simple rate-limit specific access list

IT(config)#access-list 100 ?
deny
dynamic
permit
remark

Specify packets to reject

Specify a DYNAMIC list of PERMITs or DENYs
Specify packets to forward
Access list entry comment

IT(config)#access-list 100 permit ?

<0-255>
ahp
eigrp
esp
gre
icmp
igmp
ip
ipinip
nos
ospf
pcp
pim
tcp
udp

An IP protocol number
Authentication Header Protocol
Cisco's EIGRP routing protocol
Encapsulation Security Payload
Cisco's GRE tunneling
Internet Control Message Protocol
Internet Gateway Message Protocol
Any Internet Protocol
IP in IP tunneling
KA9Q NOS compatible IP over IP tunneling
OSPF routing protocol
Payload Compression Protocol
Protocol Independent Multicast
Transmission Control Protocol
User Datagram Protocol

IT(config)#access-list 100 permit tcp ?

A.B.C.D
any
host

Source address
Any source host
A single source host

IT(config)#access-list 100 permit tcp 10.10.5.2 ?

A.B.C.D

Source wildcard bits

IT(config)#access-list 100 permit tcp host 10.10.5.2 ?

A.B.C.D
any
eq

Destination address
Any destination host
Match only packets on a given port number

gt
host
lt
neq
range

Match only packets with a

A single destination host
Match only packets with a
Match only packets not on
Match only packets in the

greater port number

lower port number
a given port number
range of port numbers

IT(config)#access-list 100 permit tcp host 10.10.5.2 10.10.6.3 ?

A.B.C.D

Destination wildcard bits

IT(config)#access-list 100 permit tcp host 10.10.5.2 host 10.10.6.3 ?

ack
dscp
eq
established
fin
fragments
gt
log
log-input
lt
neq
option
precedence
psh
range
rst
syn
time-range
tos
urg
<cr>

Match on the ACK bit

Match packets with given dscp value
Match only packets on a given port number
Match established connections
Match on the FIN bit
Check non-initial fragments
Match only packets with a greater port number
Log matches against this entry
Log matches against this entry, including input interface
Match only packets with a lower port number
Match only packets not on a given port number
Match packets with given IP Options value
Match packets with given precedence value
Match on the PSH bit
Match only packets in the range of port numbers
Match on the RST bit
Match on the SYN bit
Specify a time-range
Match packets with given TOS value
Match on the URG bit

IT(config)#access-list 100 permit tcp host 10.10.5.2 host 10.10.6.3 eq ?

<0-65535>
bgp
chargen
cmd
daytime
discard
domain
drip
echo
exec
finger
ftp
ftp-data
gopher
hostname
ident
irc
klogin
kshell
login
lpd
nntp
pim-auto-rp
pop2
pop3
smtp
sunrpc
tacacs
talk
telnet
time
uucp
whois
www

Port number
Border Gateway Protocol (179)
Character generator (19)
Remote commands (rcmd, 514)
Daytime (13)
Discard (9)
Domain Name Service (53)
Dynamic Routing Information Protocol (3949)
Echo (7)
Exec (rsh, 512)
Finger (79)
File Transfer Protocol (21)
FTP data connections (20)
Gopher (70)
NIC hostname server (101)
Ident Protocol (113)
Internet Relay Chat (194)
Kerberos login (543)
Kerberos shell (544)
Login (rlogin, 513)
Printer service (515)
Network News Transport Protocol (119)
PIM Auto-RP (496)
Post Office Protocol v2 (109)
Post Office Protocol v3 (110)
Simple Mail Transport Protocol (25)
Sun Remote Procedure Call (111)
TAC Access Control System (49)
Talk (517)
Telnet (23)
Time (37)
Unix-to-Unix Copy Program (540)
Nicname (43)
World Wide Web (HTTP, 80)

IT(config)#access-list 100 permit tcp host 10.10.5.2 host 10.10.6.3 eq 80

IT(config)#access-list 100 deny tcp any host 10.10.6.3 eq 80
IT(config)#access-list 100 permit ip any any
IT(config)#exit
IT(config)#int fa 1/0
IT(config-if)#ip access-group 100 ?
IT(config-if)#ip access-group 100 out
IT(config-if)#end

Verifications

Finance_PC#ping 10.10.6.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.6.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/70/84 ms

Finance_PC#telnet 10.10.6.3
Trying 10.10.6.3 ... Open
Secure_Server>exit
[Connection to 10.10.6.3 closed by foreign host]

Finance_PC#telnet 10.10.6.3 80

Trying 10.10.6.3, 80
% Destination unreachable; gateway or host down

Pings and Telnet connections are allowed to the Secure Server but connections on port 80 are denied
(declared unreacheable) by access list

Management_PC#telnet 10.10.5.3 80
Trying 10.10.5.3, 80
% Connection refused by remote host

A port 80 Telnet from management PC does not give a destination unreachable output, connection
to port 80 was successful

IT#show access-lists
Extended IP access list 100
10 permit tcp host 10.10.5.2 host 10.10.6.3 eq www (3 matches)
20 deny tcp any host 10.10.6.3 eq www (4 matches)
30 permit ip any any (125 matches)

Shows 3 successful attempts by Management PC using www and 4 attempts were denied using www
to Secure Server.

Task 2:

Management PC should be allowed web access to Secure Server but no

other types of access should be allowed, no one other should be able to access this
server. Since there is also Public Printer in the subnet, everyone should have access to
the printer.
Configure a Named Extended ACL using modern syntax.
IT(config)#ip access-list extended SECURE
IT(config-ext-nacl)#permit tcp host 10.10.5.2 host 10.10.6.3 eq 80
IT(config-ext-nacl)#permit ip any host 10.10.6.2
IT(config-ext-nacl)#deny ip any any
IT(config-ext-nacl)#exit
IT(config)#int fa 1/0
IT(config-if)#ip access-group SECURE out

Verifications
Management_PC#telnet 10.10.6.3 80
Trying 10.10.6.3, 80 ...
% Connection refused by remote host

Management_PC#telnet 10.10.6.3
Trying 10.10.6.3 ...
% Destination unreachable; gateway or host down

Management_PC#ping 10.10.6.3
Type escape sequence to abort.

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

U.U.U
Success rate is 0 percent (0/5)

Only port 80 web access is granted all other services and accesses are denied from Management PC
to Secure Server.

Finance_PC#ping 10.10.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.6.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/68/84 ms

Finance_PC#ping 10.10.6.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.6.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Management_Server#ping 10.10.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.6.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/77/100 ms

Management_Server#ping 10.10.6.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.6.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Everyone else can reach the Public Printer but not the Secure Server in any way

Extended IP access list 100

10 permit tcp host 10.10.5.2 host 10.10.6.3 eq www (3 matches)
20 deny tcp any host 10.10.6.3 eq www (4 matches)
30 permit ip any any (125 matches)
Extended IP access list SECURE
10 permit tcp host 10.10.5.2 host 10.10.6.3 eq www (1 match)
20 permit ip any host 10.10.6.2 (25 matches)
30 deny ip any any (34 matches)

Task 3:

Allow only FTP to Finance Server and deny all other services from

everyone
Finance(config)#ip access-list extended 111
Finance(config-ext-nacl)#permit tcp any host 10.10.4.3 eq ftp
Finance(config-ext-nacl)#deny ip any host 10.10.4.3
Finance(config-ext-nacl)#permit ip any any
Finance(config-ext-nacl)#exit
Finance(config)#int fa 1/0
Finance(config-if)#ip access-group 111 out
Finance(config-if)#end

Verifications
Management_PC#ping 10.10.4.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.4.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Management_PC#telnet 10.10.4.3
Trying 10.10.4.3 ...

% Destination unreachable; gateway or host down

Management_PC#telnet 10.10.4.3 ftp

Trying 10.10.4.3, 21 ...
% Connection refused by remote host

Management_PC#ping 10.10.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.4.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/65/68 ms

Finance#show ip access-lists
Extended IP access list 111
10 permit tcp any host 10.10.4.3 eq ftp (2 matches)
20 deny ip any host 10.10.4.3 (10 matches)
30 permit ip any any (5 matches)

Task 4:

Deny Management Server from accessing all links between routers,

use only one deny statement
Management(config)#ip access-list extended MGMT_SERVER_RESTRICTION
Management(config-ext-nacl)#deny ip host 10.10.5.3 10.10.0.0 0.0.3.255
Management(config-ext-nacl)#permit ip any any
Management(config-ext-nacl)#exit
Management(config)#int fa 1/0
Management(config-if)#ip access-group MGMT_SERVER_RESTRICTION in
Management(config-if)#end

Verifications
Management_Server#ping 10.10.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Management_Server#ping 10.10.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.2.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Management_Server#ping 10.10.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.3.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

Management Server cannot access the links between the routers

Management_Server#ping 10.10.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.4.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 60/70/76 ms

Management_Server#ping 10.10.6.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.6.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/68/84 ms

But it can go through the router links and subnets to other devices as shown above

Management#show ip access-lists
Extended IP access list MGMT_SERVER_RESTRICTION
10 deny ip host 10.10.5.3 10.10.0.0 0.0.3.255 (44 matches)
20 permit ip any any (35 matches)

Only one deny statement is used with proper wildcard

Securing Telnet Lines using ACL

Task 1:

Only Secure Server should be able to telnet into IT router

IT(config)#access-list 50 permit host 10.10.6.3

IT(config)#line vty 0 935
IT(config-line)#access-class ?
<1-199>
<1300-2699>
WORD

IP access list
IP expanded access list
Access-list name

IT(config-line)#access-class 50 ?
in
out

Filter incoming connections

Filter outgoing connections

IT(config-line)#access-class 50 in

Secure_Server#telnet
Trying 10.10.6.1 ...
IT>
Management_PC#telnet
Trying 10.10.3.1 ...
% Connection refused

10.10.6.1
Open
10.10.3.1
by remote host

Verification

GRE Tunnel Configurations

Assuming that the interfaces are configures correctly and Host A can ping Host B:

Step 1: Create a Tunnel

Lahore(config)#int tunnel 1
Sialkot(config)#int tunnel 2

Tunnel number is locally significant

Step 2: Assign an IP address to the Tunnel

Lahore(config-if)#ip address 10.10.100.1 255.255.255.0

Sialkot(config-if)#ip address 10.10.100.2 255.255.255.0

Step 3: Configure Tunnels source IP address, the IP address of the local

interface.
Lahore(config-if)#tunnel source 10.10.10.1

Sialkot(config-if)#tunnel source 10.10.10.2

Step 4: Configure Tunnels destination IP address, the IP address of foreign

interface.
Lahore(config-if)#tunnel destination 10.10.10.2
Sialkot(config-if)#tunnel destination 10.10.10.1
Sialkot(config-if)#
*Mar 1 00:02:50.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

Step 5: If needed configure a dynamic protocol to learn Tunnels network(s).

Verifications
Lahore#show ip int br
Interface
FastEthernet0/0
Serial0/0
FastEthernet0/1
Tunnel1

IP-Address
10.10.20.254
10.10.10.1
unassigned
10.10.100.1

OK?
YES
YES
YES
YES

Method
NVRAM
NVRAM
NVRAM
manual

Status
Protocol
up
up
up
up
administratively down down
up
up

Sialkot#show ip int br
Interface
FastEthernet0/0
Serial0/0
FastEthernet0/1
Tunnel2

IP-Address
10.10.30.254
10.10.10.2
unassigned
10.10.100.2

OK?
YES
YES
YES
YES

Method
NVRAM
NVRAM
NVRAM
manual

Status
Protocol
up
up
up
up
administratively down down
up
up

Lahore#show interfaces tunnel 1

Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.10.100.1/24
MTU 1514 bytes, BW 9 Kbit/sec, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.10.10.1, destination 10.10.10.2
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:02:09, output 00:02:09, output hang never
Last clearing of "show interface" counters never
A#ping 10.10.30.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.30.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/62/64 ms

B#ping 10.10.20.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.20.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/59/68 ms

PART 5
WIDE AREA NETWORK

WIDE AREA NETWORK

PART A

CONCEPTS