Documentos de Académico
Documentos de Profesional
Documentos de Cultura
NETWORK FUNDAMENTALS
Name
PDU
Description
Protocols
Device
s
Applicatio
n
L7PDU
Hosts,
Firewalls.
Presentati
on
L6PDU
Session
L5PDU
Hosts,
Firewalls.
Transport
Segment
Hosts,
Firewalls.
Network
Packet
Data Link
Frame
Routers.
Physical
Bits
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.
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
DNS
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
FCS
Source SAP
Control
OUI ID
Type
Data
(Packet)
Source SAP
Control
Data (Packet)
Destination
MAC
Source MAC
Length
Data (Packet)
FCS
Address
Control
Data
(Packets)
FCS
Flag
Address
Control
Protocol
Type
(Proprietar
y)
Data
(Packets)
FCS
Flag
PPP Frame
Flag
Address
Control
Protocol
Type
(Standardiz
ed)
Data
(Packets)
FCS
Flag
Address (DLCI)
Data
(Packets)
FCS
Flags
LMI Frame
Flag
LMI
DLCI
Unnumbered
Information
Indicator
Protocol
Discriminator
Call
Reference
Message
Type
Information
Elements
FCS
Flag
Routers operate at Network Layer 3 of OSI and Revised TCP/IP and at Internet layer of DoD TCP/IP
model.
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.
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.
Bridges
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
CSU/DSU
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.
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
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
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.
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.
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.
Switches build MAC address table based on SOURCE MAC address of incoming frame.
MAC address table is stored in RAM.
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.
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).
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:
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 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.
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.
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.
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.
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.
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.
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.
VTP Modes:
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.
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
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.
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 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.
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.
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.
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.
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:
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
2 seconds
20 seconds
(10 times
hello)
Forward
Delay
15 seconds
(15 sec for
Listening and
15 sec for
Learning)
50 seconds
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.
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.
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
9600 bits/second
No hardware flow control
8-bit ASCII
No parity bits
1 stop bit
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.
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
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.
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
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.
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
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
!
Mode
on
Encapsulation
802.1q
Status
trunking
Port
Fa0/1
Port
Fa0/1
Port
Fa0/1
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
-----------
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
IP-Address
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
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
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)
: 0
: 0
: 0
:
:
:
:
:
:
5
3
0
0
0
0
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
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
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
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
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
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
Sts
--FWD
FWD
FWD
FWD
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
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
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
Sts
--FWD
FWD
BLK
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
Sts
--FWD
FWD
BLK
Prio.Nbr
-------128.12
128.3
128.1
Type
-------------------------------P2p
P2p
P2p
#show spanning-tree detail lists STP related details on per VLAN and per Port basis.
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
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
Type
-------------------------------P2p
P2p
P2p
Priority
Address
Hello Time
Aging Time
Interface
---------------Fa0/12
Fa0/3
Fa0/1
Role
---Desg
Desg
Altn
Sts
--FWD
FWD
BLK
Prio.Nbr
-------128.12
128.3
128.1
Type
-------------------------------P2p
P2p
P2p
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
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
Po1(SU)
Po2(SU)
Fa0/2(P) Fa0/4(P)
Fa0/3(P) Fa0/6(P)
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
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)
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
pause input
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
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.
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.
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.
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
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.
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
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.
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.
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.
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).
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.
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
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.
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
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
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
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
Packet Length
Router ID
Area ID
Checksum
Instance ID
# LSAs
LSAs
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.
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
5. Virtual links
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.
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.
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)
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.
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.
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.
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.
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.
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:
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.
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.
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.
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
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.
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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
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
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
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
Default Route of Gateway of Last Resort as it is called in show ip route command output can be
configured using following three ways:
S
C
C
S
S*
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
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.
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.
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
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.
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 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
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
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
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
C
C
O
O IA
O IA
O IA
O IA
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
In multi-area configuration one interface is always in backbone area and others go in different areas,
no other major difference.
Specify
Specify
Specify
Specify
OSPF
OSPF
OSPF
OSPF
Verification of OSPF
R2#show running-config
interface FastEthernet0/0
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)
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
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.
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
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
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
ADV Router
1.1.1.1
1.1.1.1
2.2.2.2
Age
969
969
1352
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
ADV Router
3.3.3.3
5.5.5.5
Age
761
247
Seq#
Checksum Link count
0x80000008 0x00FDAB 2
0x80000005 0x002C43 3
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.
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
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.
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
ip ospf interface
ip ospf
ip ospf | begin area 1
running-config
4- Unique RIDs
#show
#show
#show
#show
ip ospf interface
ip ospf
ip database
running-config
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
3 Unique Commands that may help troubleshoot all basic neighbor adjacency issues:
EIGRP Configurations
R1(config)#router eigrp 1
R2(config)#router eigrp 1
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
exit
key
no
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
R1(config-keychain-key)#key-string ?
0
7
LINE
1 01:50:24.915: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.1.2 (FastEthernet0/0) is down: authentication mode changed
name of key-chain
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:
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
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
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.
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.
(successor route)
(not being utilized)
show ip eigrp topology command only lists the successor and feasible successor routes:
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:
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:
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:
We rerun the EIGRP process so the new delay value could take effect:
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
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.
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)
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
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 route
D
C
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
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
!
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
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
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.
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
Pending
Routes
0
DHCP Configurations
10.10.1.250
?
10.10.1.251 ?
10.10.1.251 10.10.1.254
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
D- Define length of lease, in days, hours, and minutes: lease days hours minutes
R1(dhcp-config)#lease 1 12 59
IP destination address
Helper-address is global
VRF name for helper-address (if different from interface VRF)
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
Type
Automatic
Automatic
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
NAT Configurations
Outside
100.100.100.1
100.1001.100.2
Step 2: Statically map the inside local addresses to outside global addresses
NAT(config)#ip nat inside source ?
list
route-map
static
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.
Inside local
10.10.10.1
10.10.10.2
Outside local
-----
Outside global
-----
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
Step 3:
Pool name
Start IP address
Specify the network mask
Specify the prefix length
End IP address
Step 4:
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
---
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
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:
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
Step 2:
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:
Distribution1(config-if)#standby 1 timers 1 ?
<2-255>
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
A#ping 10.10.200.2
B#ping 10.10.100.2
!!!!!
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)
Virtual IP
10.10.10.10
After the Distribution 1 router goes down Distribution 2 takes over as active router.
A#ping 10.10.10.10
A#ping 10.10.100.2
A#ping 10.10.200.2
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)
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:
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
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:
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:
Distribution1(config-if)#glbp 1 ip 10.10.10.10
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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
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.
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.
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.
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.
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
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
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 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
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
:
:
:
:
:
:
:
:
:
:
:
:
Enabled
Secure-up
Restrict
0 mins
Absolute
Disabled
3
0
0
0
0000.0000.0000:0
0
:
:
:
:
:
:
:
:
:
:
:
:
Enabled
Secure-shutdown
Shutdown
0 mins
Absolute
Disabled
1
1
1
0
0002.1635.2030:1
1
ACL Configurations
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
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
Finance_PC#ping 10.10.7.2
Management_PC#ping 10.10.7.2
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
Task 2:
IT(config)#access-list 100 ?
deny
dynamic
permit
remark
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
Source address
Any source host
A single source host
Destination address
Any destination host
Match only packets on a given port number
gt
host
lt
neq
range
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)
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:
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.
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
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
Everyone else can reach the Public Printer but not the Secure Server in any way
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
Management_PC#telnet 10.10.4.3
Trying 10.10.4.3 ...
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:
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#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)
IP access list
IP expanded access list
Access-list name
IT(config-line)#access-class 50 ?
in
out
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
Assuming that the interfaces are configures correctly and Host A can ping Host B:
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
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
CONCEPTS