CCIE Enterprise Infrastructure
Uploaded by
Da vCCIE Enterprise Infrastructure
Uploaded by
Da vNETWORK LESSONS:
CCIE Enterprise Infrastructure
INDEX:
1|Page
CCIE Enterprise Infrastructure
Unit 1: Network Infrastructure
1.1: Switched Campus
1.1.a: Switch Administration
How does a switch learn MAC Addresses?
A switch has some intelligence and operates on layer 2 of the OSI model. In this
lesson, I’ll demonstrate how a switch learns MAC addresses. Let me show you an
example of three computers connected to a switch:
There’s a switch in the middle and we have 3 computers. All computers have a MAC
address, but I’ve simplified them. Our switch has a MAC address table and it will learn
where all the MAC addresses are in the network. Let’s send something from H1 to H2:
H1 is going to send some data meant for H2, thus it will create an Ethernet frame which
has a source MAC address (AAA) and a destination MAC address (BBB). Our switch
has a MAC address table and here’s what will happen:
2|Page
Our switch will build a MAC address table and only learns from source MAC
addresses. At this moment it just learned that the MAC address of H1 is on interface 1.
It will now add this information in its MAC address table. As you can see our switch
currently has no information where H2 is located. There’s only one option left….
flood this frame out of all its interfaces except the one where it came from. H2 and H3
will receive this Ethernet frame.
Since H2 sees its MAC address as the destination of this Ethernet frame it knows it’s
meant for him, H3 will discard it. H2 is going to respond to H1, build an Ethernet frame
and send it towards our switch. At this moment the switch will learn the MAC address of
H2.
That’s the end of our story, the switch now knows both MAC addresses and the next
time it can “switch” instead of flooding Ethernet frames. H3 will never see any frames
between H1 and H2 except for the first one which was flooded.
1. Verification
Let me show you what this looks like on a real Cisco switch. I will use a topology with
one switch and three host devices:
3|Page
Let’s verify if all interfaces are up and running:
SW1#show interfaces status
Port Name Status Vlan Duplex Speed Type
Gi0/1 connected 1 auto auto unknown
Gi0/2 connected 1 auto auto unknown
Gi0/3 connected 1 auto auto unknown
All interfaces are connected, let’s check the MAC address table:
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 fa16.3e15.d86d DYNAMIC Gi0/1
1 fa16.3e5c.bc0f DYNAMIC Gi0/2
1 fa16.3ed2.c7c2 DYNAMIC Gi0/3
Total Mac Addresses for this criterion: 3
The show mac address-table dynamic command gives us all MAC addresses that the
switch has learned dynamically. We can see it has learned three MAC addresses.
There are a couple of parameters we can use with this command. For example:
SW1#show mac address-table dynamic address fa16.3e15.d86d
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
4|Page
1 fa16.3e15.d86d DYNAMIC Gi0/1
This only gives us the output for the MAC address of H1. We can also get an overview of
all MAC addresses that were learned on a single interface:
SW1#show mac address-table dynamic interface Gi0/2
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 fa16.3e5c.bc0f DYNAMIC Gi0/2
Total Mac Addresses for this criterion: 1
This shows interface GigabitEthernet0/2 with the MAC address of H2. Here’s how you
can see the default aging time:
SW1#show mac address-table aging-time
Global Aging Time: 300
Vlan Aging Time
---- ----------
If the switch doesn’t see a particular MAC address for 300 seconds, it will be removed
from the MAC address table.
What if we want to manually remove something from the MAC address table? This is
possible with the clear mac address-table command:
SW1#clear mac address-table dynamic ?
address address keyword
interface interface keyword
vlan vlan keyword
<cr>
You can choose if you want to remove a single MAC address, all MAC address on a
particular interface or that belong to one VLAN. If you don’t add any parameters then it
will remove all MAC addresses. Let’s try that:
SW1#clear mac address-table dynamic
The MAC address table is now empty:
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
5|Page
Vlan Mac Address Type Ports
---- ----------- -------- -----
Let’s send a ping from H1 to H2 to check if our switch is able to learn their MAC
addresses:
H1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/9/10 ms
The ping is successful, let’s check the table:
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 fa16.3e15.d86d DYNAMIC Gi0/1
1 fa16.3e5c.bc0f DYNAMIC Gi0/2
Total Mac Addresses for this criterion: 2
It’s now showing the MAC addresses of H1 and H2.
Alright, so far so good. What if we have two switches with a couple of hosts? Take a look
at the following topology:
Take a look at the output of these two switches, especially their GigabitEthernet0/3
interfaces:
6|Page
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 fa16.3e02.9079 DYNAMIC Gi0/3
1 fa16.3e31.cdd8 DYNAMIC Gi0/2
1 fa16.3e40.f97d DYNAMIC Gi0/1
1 fa16.3eb9.eacd DYNAMIC Gi0/3
Total Mac Addresses for this criterion: 4
As you can see above, SW1 has learned the MAC addresses of H3 and H4 on its
GigabitEthernet0/3 interface. SW2 has learned the addresses of H1 and H2:
SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 fa16.3e02.9079 DYNAMIC Gi0/2
1 fa16.3e31.cdd8 DYNAMIC Gi0/3
1 fa16.3e40.f97d DYNAMIC Gi0/3
1 fa16.3eb9.eacd DYNAMIC Gi0/1
Total Mac Addresses for this criterion: 4
This is just a quick example to explain that a switch is able to learn multiple MAC
addresses on a single interface.
I hope this lesson has been useful to understand the MAC address table of your Cisco
Catalyst switch.
Static MAC Address Table Entry
Normally your switch will automatically learn MAC addresses and fill its MAC address
table (CAM table) by looking at the source MAC address of incoming frames and
flooding frames if it doesn’t know where to forward the frame.
This process is vulnerable to layer 2 MAC address spoofing attacks where an attacker
spoofs a certain MAC address to change entries in the MAC address table. A really
simple method to deal with this issue is to manually configure entries in the MAC
address table, a static entry will always overrule dynamic entries. You can either specify
the interface where the MAC address is located or tell the switch to drop the traffic.
Let’s look at an example!
7|Page
To demonstrate this, we only require two devices. A router to generate some traffic and
a switch to look at (and configure) the MAC address table. Here’s the configuration:
R1(config)#interface fastEthernet 0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.12.1 255.255.255.0
SW1(config)#interface vlan 1
SW1(config-if)#no shutdown
SW1(config-if)#ip address 192.168.12.2 255.255.255.0
We’ll do a quick ping to generate some traffic so SW1 can learn about the mac address
of R1’s FastEthernet 0/0 interface:
R1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
Let’s take a look at the MAC address table:
SW1#show mac address-table dynamic vlan 1
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 001d.a18b.36d0 DYNAMIC Fa0/1
Total Mac Addresses for this criterion: 1
Here’s the MAC address of R1, learned dynamically. Let’s turn this into a static entry:
SW1(config)#mac address-table static 001d.a18b.36d0 vlan 1 interface fastEthernet
0/1
Use the mac address-table static command to create a static entry. Here’s what the
MAC address table looks like now:
SW1#show mac address-table static | include Fa0/1
1 001d.a18b.36d0 STATIC Fa0/1
8|Page
There it is, a static entry. No way to overrule this unless you have access to our switch.
This prevents us from moving R1 to another interface on SW1 unless we change the
static entry. Like I mentioned before we can also change a static entry so it will drop all
traffic. Here’s how to do it:
SW1(config)#mac address-table static 001d.a18b.36d0 vlan 1 drop
All frames destined for the MAC address of R1 will now be dropped:
R1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Because of our static drop entry, our pings are failing.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
end
hostname SW1
!
interface Vlan1
ip address 192.168.12.2 255.255.255.0
!
mac address-table static 001d.a18b.36d0 vlan 1 drop
end
MTU Troubleshooting on Cisco IOS
Maximum Transmission Unit (MTU) is the largest size in bytes that a certain layer can
forward. The MTU is different for each protocol and medium that we use. Ethernet for
example has a MTU of 1500 bytes by default.
This means that a single Ethernet frame can carry up to 1500 bytes of data. On top of
this data we add the Ethernet header. Typical header sizes are 14 bytes for Ethernet
(add another 4 bytes if you use 802.1Q tagging).
Below is a picture with the different MTU fields that you might encounter:
9|Page
You can see that a typical Ethernet header is 14 bytes, IP is 20 bytes and TCP is also 20
bytes. The maximum amount of payload that TCP can use is called the TCP MSS
(Maximum Segment Size). This MSS value is the largest amount of data that a host
can receive in a single TCP segment. This value is used to set a limit on the payload in
order to prevent fragmentation and is sent in the SYN packet during the 3-way
handshake. The MSS value isn’t synchronized between hosts, it can be different for
each direction.
So why is all of this important to know? Let’s imagine we have an IP packet that is sent
on our LAN. The size of the Ethernet frame will be like this:
1460 bytes of payload for TCP.
20 bytes for the TCP header.
20 bytes for the IP header.
14 bytes for the Ethernet header.
1460 (PAYLOAD) + 20 (TCP) + 20 (IP) = 1500 bytes + 14 (ETHERNET) = 1514 bytes in
total.
Sending 1514 bytes is no problem for Ethernet but some other mediums might have
issues with large MTU values. Often problems arise when you add additional
headers because of PPPoE, GRE Tunneling or IPSEC since this reduces the available
bytes for our MTU. To demonstrate this problem (and how to solve it!) I will use a simple
network with a reduced MTU. Here’s what it looks like:
The network above has two routers, a webserver (S1) behind R1 and a client (H1)
behind R2. Here’s what the configuration looks like:
10 | P a g e
1. Configuration
First, we’ll configure some IP addresses:
R1(config)#interface fastEthernet 0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config)#interface fastEthernet 0/1
R1(config-if)#ip address 192.168.1.254 255.255.255.0
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config)#interface fastEthernet 0/1
R2(config-if)#ip address 192.168.2.254 255.255.255.0
I’ll add some static routes for connectivity:
R1(config)#ip route 192.168.2.0 255.255.255.0 192.168.12.2
R2(config)#ip route 192.168.1.0 255.255.255.0 192.168.12.1
Here’s what the default MTU values look like:
R2#show interfaces fastEthernet 0/0 | include MTU
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
R2#show ip interface fastEthernet 0/0 | include MTU
MTU is 1500 bytes
The first MTU value is the interface MTU, it’s 1500 bytes by default for Ethernet. The
second one is the IP MTU which is also 1500 bytes. Once you get above 1500 bytes
your router will start fragmenting the IP packets.
Is this limit of 1500 bytes really working? There’s an easy way to find out. Let’s do a ping
with the DF-bit (Don’t Fragment) between the routers:
R2#ping
Protocol [ip]:
Target IP address: 192.168.12.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
11 | P a g e
Loose, Strict, Record, Timestamp, Verbose[none]: v
Loose, Strict, Record, Timestamp, Verbose[V]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1495
Sweep max size [18024]: 1505
Sweep interval [1]:
Type escape sequence to abort.
Sending 11, [1495..1505]-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
Packet sent with the DF bit set
Reply to request 0 (1 ms) (size 1495)
Reply to request 1 (4 ms) (size 1496)
Reply to request 2 (1 ms) (size 1497)
Reply to request 3 (4 ms) (size 1498)
Reply to request 4 (1 ms) (size 1499)
Reply to request 5 (4 ms) (size 1500)
Request 6 timed out (size 1501)
Request 7 timed out (size 1502)
Request 8 timed out (size 1503)
Request 9 timed out (size 1504)
Request 10 timed out (size 1505)
Success rate is 54 percent (6/11), round-trip min/avg/max = 1/2/4 ms
In the ping above you can see that the largest packet that I can send is 1500 bytes. The
second packet with 1501 bytes can’t be sent because it is too large, and we set the DF-
bit.
Let’s look at an actual packet between the client and the webserver, see what these
values look like in an actual frame:
Above you can see the TCP MSS which is 1460 bytes. What else can we see in
Wireshark?
12 | P a g e
Above you see that the total length of the IP packet is 1500 bytes (1460 bytes for TCP
MSS + 40 bytes for the TCP/IP header). Ethernet adds another 14 bytes which is how
we get to 1514 bytes in total.
To simulate a network with a lower MTU I will reduce the MTU of the FastEthernet 0/0
interface of R2:
R2(config)#interface fastEthernet 0/0
R2(config-if)#mtu 1400
By reducing the MTU to 1400 bytes, the largest TCP segment size will be only 1360
bytes (1400 – 40 = 1360). This is a scenario where users often complain that sending a
ping is no problem but accessing a website or something else doesn’t work. Why? Let’s
look at the example below:
Above you see a ping between the client and webserver. As you can see the total length
is only 74 bytes…no problem to send this because our MTU allows 1400 bytes. Now we
will try to connect to the webserver from the client using HTTP:
This is where things go wrong…as you can see above the total length of the IP Packet is
1500 bytes which is 100 bytes above our MTU of 1400 bytes. It’s impossible to
communicate between the client and webserver now.
13 | P a g e
How do we fix this? There are two solutions for this:
Set the correct IP MTU value so the router knows when to fragment IP packets.
Reduce the TCP MSS value for outgoing connections so there is less payload.
Here’s how to configure the correct IP MTU value:
R2(config)#interface fastEthernet 0/0
R2(config-if)#ip mtu 1400
This tells the router to fragment all outgoing IP packets when they exceed 1400 bytes.
The second step is to tell the router to intercept all TCP SYN packets from hosts and
change the MSS value. We do this on the interface that is facing our hosts:
R2(config)#interface fastEthernet 0/1
R2(config-if)#ip tcp adjust-mss 1360
Setting the TCP MSS value to 1360 ensures that our total MTU will be 1400 bytes (1360
+ 40). Does this work? Let’s look at a Wireshark example between our host and
webserver again:
Above you can see that the maximum segment size is now 1360 bytes. What about the
total packet length? Look below…
14 | P a g e
With a TCP MSS of 1360 our IP packet is only 1400 bytes which is exactly our MTU of
1400 bytes. You will notice that all communication problems between the host and
webserver are now solved.
The IP tcp adjust-mss command is to intercept TCP SYN packets from hosts and set the
correct MSS value, if you want to change the MSS for TCP connections that are
originated by the router you need to use another command:
R2(config)#ip tcp mss 1360
The ip tcp mss command changes the MSS for the router itself. We can do a debug to
check if it’s working or not:
R2#debug ip tcp transactions
TCP special event debugging is on
Let’s use telnet to connect to TCP port 80 to the webserver:
R2#telnet 192.168.1.1 80
Trying 192.168.1.1, 80 ... Open
TCB495B8B94 created
TCB495B8B94 setting property TCP_VRFTABLEID (20) 496CF85C
TCB495B8B94 setting property TCP_TOS (11) 496CF7F8
TCB495B8B94 setting property TCP_RTRANSTMO (31) 496CF728
TCB495B8B94 setting property TCP_GIVEUP (34) 496CF72C
TCP: Random local port generated 36352, network 1
TCB495B8B94 bound to UNKNOWN.36352
TCB495B8B94 setting property unknown (24) 496CF758
Reserved port 36352 in Transport Port Agent for TCP IP type 1
TCP: sending SYN, seq 3882550463, ack 0
TCP0: Connection to 192.168.1.1:80, advertising MSS 1360
TCP0: state was CLOSED -> SYNSENT [36352 -> 192.168.1.1(80)]
TCP0: state was SYNSENT -> ESTAB [36352 -> 192.168.1.1(80)]
TCP: tcb 495B8B94 connection to 192.168.1.1:80, peer MSS 1460, MSS is 1360
You can see that R2 is using a MSS value of 1360 now…problem solved.
15 | P a g e
1.1.b: Layer 2 Protocols
Introduction to CDP (Cisco Discovery Protocol)
Let’s talk a bit about network management. Perhaps not the most exciting topic but I’m
going to show you how you can use CDP (Cisco Discovery Protocol) to help you build
network maps and what other information it can reveal.
Most networks have multiple switches and/or routers and to make our life easier it’s
good to have a network map that shows us how everything is connected to each other,
what kind of devices we have, to what VLAN they belong and the IP addresses that we
are using. CDP is a Cisco protocol that runs on all Cisco devices that helps us discover
Cisco devices on the network. CDP is Cisco proprietary, runs on the data-link layer and
is enabled by default.
Let’s take a look at a network map:
Above we have 3 routers. Now if I had no idea what the network looked like we could
use CDP to build the network map that you see above. Let me show you how:
R1#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
16 | P a g e
R2 Ser 0/0 167 R S I 3640 Ser 0/0
Use the show cdp neighbors command to see all directly connected neighbors.
Above you see that R1 is connected to R2 and you can also see the platform (3640
router) and the interfaces on both sides. Let me show you the other routers as well:
R2#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R1 Ser 0/0 144 R S I 3640 Ser 0/0
R3 Fas 1/0 164 R S I 3640 Fas 1/0
R3#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Fas 1/0 135 R S I 3640 Fas 1/0
Now we have all the information we need to build a network map with the router names
and interfaces. CDP can tell us even more however…
R1#show cdp neighbors detail
-------------------------
Device ID: R2
Entry address(es):
IP address: 192.168.12.2
Platform: Cisco 3640, Capabilities: Router Switch IGMP
Interface: Serial0/0, Port ID (outgoing port): Serial0/0
Holdtime : 136 sec
Version :
Cisco IOS Software, 3600 Software (C3640-JK9O3S-M), Version 12.4(16), RELEASE
SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Wed 20-Jun-07 11:43 by prod_rel_team
advertisement version: 2
VTP Management Domain: ''
Use show cdp neighbors detail to reveal even more information. For example, you can
see the IP address and the IOS version. This can be very useful to us but it’s also a
security risk. By default, CDP is enabled and runs on all interfaces so it might be a good
idea to disable it on certain interfaces:
R1(config)#interface serial 0/0
R1(config-if)#no cdp enable
17 | P a g e
This is how you can disable it for a single interface, just type no cdp enable. This is how
you can do it globally for all interfaces:
R1(config)#no cdp run
That’s all there is to CDP. Besides revealing networking information CDP is also used for
Cisco IP phones but that’s another story. Keep in mind CDP only runs on Cisco
hardware, there’s also a “standards” based version called LLDP that runs on Cisco
hardware and some other networking vendor equipment.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
interface Serial0/0
ip address 192.168.12.1 255.255.255.0
no cdp enable
!
no cdp run
!
end
hostname R2
!
interface Serial0/0
ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet1/0
ip address 192.168.23.2 255.255.255.0
!
end
hostname R3
!
interface FastEthernet1/0
ip address 192.168.23.3 255.255.255.0
!
end
Link Layer Discovery Protocol (LLDP)
LLDP is a layer two discovery protocol, similar to Cisco’s CDP. The big difference
between the two is that LLDP is a standard while CDP is a Cisco proprietary protocol.
Cisco devices support the IEEE 802.1ab version of LLDP. This allows non-Cisco devices
to advertise information about themselves to our network devices.
LLDP uses attributes that contain a type, length and value descriptions. These are called
TLVs (Type, Length, Value). Devices that support LLDP use TLVs to send and receive
18 | P a g e
information to their directly connected neighbors. Here’s an example of some basic
TLVs:
Port description TLV
System name TLV
System description TLV
System capabilities TLV
Management Address TLV
Some network end devices (like IP Phones) can use LLDP for VLAN assignment or PoE
(Power over Ethernet) requirements. To accomplish this, an enhancement was made
which is called MED (Media Endpoint Discovery). This is typically known as LLDP-MED.
Configuration of LLDP is really simple, depending on your switch and IOS version it
might be enabled or disabled by default. Let’s take a look at an example
I have two Cisco Catalyst 3560 switches, directly connected to each other. LLDP is
disabled by default on these switches so let’s enable it:
SW1, SW2
(config)#lldp run
This enables LLDP globally on all interfaces. After a couple of seconds we can see
something:
SW1#show lldp neighbors
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
SW2 Fa0/24 120 B Fa0/24
Total entries displayed: 1
This output looks very similar to CDP. We can also take a detailed look at our neighbor:
SW1#show lldp neighbors detail
Chassis id: 0011.bb0b.361a
Port id: Fa0/24
19 | P a g e
Port Description: FastEthernet0/24
System Name: SW2.cisco.com
System Description:
Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(46)SE,
RELEASE SOFTWARE (fc2)
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 21-Aug-08 15:26 by nachen
Time remaining: 106 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
100base-TX(FD)
100base-TX(HD)
10base-T(FD)
10base-T(HD)
Media Attachment Unit type: 16
---------------------------------------------
Total entries displayed: 1
Above you can see some details about SW2, it’s hostname, platform, IOS version,
capabilities etc. One little extra that LLDP offers is that it also sends interface
descriptions. Here’s an example:
SW1(config)#interface FastEthernet 0/24
SW1(config-if)#description LINK_SW1_SW2
This description will show up if we look on SW2:
SW2#show lldp neighbors detail
Chassis id: 0019.569d.571a
Port id: Fa0/24
Port Description: LINK_SW1_SW2
System Name: SW1.cisco.com
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname SW1
!
interface FastEthernet 0/24
description LINK_SW1_SW2
!
lldp run
!
20 | P a g e
end
hostname SW2
!
lldp run
!
end
1.1.c: VLAN Technologies
Introduction to VLANs
In this lesson we will take a look at VLANs (Virtual LANs) and I will explain what they are
and why we need them.
First of all, let me show you a picture of a network:
21 | P a g e
Look at this picture for a minute, we have many departments and every department has
its own switch. Users are grouped physically together and are connected to their switch.
what do you think of it? Does this look like a good network design? If you are unsure let
me ask you some questions to think about:
What happens when a computer connected to the Research switch sends a
broadcast like an ARP request?
What happens when the Helpdesk switch fails?
Will our users at the Human Resource switch have fast network connectivity?
How can we implement security in this network?
Now let me explain to you why this is a bad network design. If any of our computers
sends a broadcast what will our switches do? They flood it! This means that a single
broadcast frame will be flooded on this entire network. This also happens when a switch
hasn’t learned about a certain MAC address, the frame will be flooded.
If our helpdesk switch would fail this means that users from Human Resource are
“isolated” from the rest and unable to access other departments or the internet, this
applies to other switches as well. Everyone has to go through the Helpdesk switch in
order to reach the Internet which means we are sharing bandwidth, probably not a very
good idea performance-wise.
Last but not least, what about security? We could implement port-security and filter on
MAC addresses but that’s not a very secure method since MAC addresses are very
easy to spoof. VLANs are one way to solve our problems.
One more question I’d like to ask you to refresh your knowledge:
How many broadcast domains do we have here?
What about broadcast domains? We didn’t talk about this before, but I think you can
answer it. If a computer from the sales switch would send a broadcast frame, we know
22 | P a g e
that all other switches will forward it. Did you spot the router on top of the picture? What
about it…do you think a router will forward a broadcast frame?
The answer is that routers don’t forward broadcast frames so they effectively “limit” our
broadcast domain. Of course, on the right side of our router where we have an Internet
connection this would be another broadcast domain…so we have 2 broadcast domains
here. Let’s see how we can improve things…
When you work with switches you have to keep in mind there’s a big difference between
physical and logical topology. Physical is just the way our cables are connected while
logical is how we have setup things ‘virtually’. In the example above we have 4 switches
and I have created 3 VLANs called Research, Engineering and Sales. A VLAN is a
Virtual LAN so it’s like having a “switch inside a switch”.
What are the advantages of using VLANs?
A VLAN is a single broadcast domain which means that if a user in the research
VLAN would send a broadcast frame only users in the same VLAN will receive it.
Users are only able to communicate within the same VLAN unless you use a
router.
Users don’t have to be grouped physically together, as you can see, we have
users in the Engineering VLAN sitting on the 1 st, 2nd and 3rd floor.
That’s all for now. I hope this has given you an idea of what VLANs are and why we use
them! If you enjoyed this lesson, please leave a comment.
VLAN Configuration on Cisco IOS Switch
In this lesson I will show you how to configure VLANs on Cisco Catalyst Switches
and how to assign interfaces to certain VLANs. Let’s start with a simple network
topology:
23 | P a g e
Let’s start with a simple example. H1 and H2 are connected to SW1.
First, we will look at the default VLAN configuration on SW1:
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/12
Fa0/13, Fa0/14, Fa0/22
Fa0/23, Fa0/24, Gi0/1, Gi0/2
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
Interesting…VLAN 1 is the default LAN and you can see that all active interfaces are
assigned to VLAN 1.
VLAN information is not saved in the running-config or startup-config but in a separate
file called vlan.dat on your flash memory. If you want to delete the VLAN information you
should delete this file by typing delete flash:vlan.dat. I configured an IP address on
H1 and H2 so they are in the same subnet.
Let’s see if H1 and H2 can reach each other:
C:\Documents and Settings\H1>ping 192.168.1.2
Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
24 | P a g e
Even with the default switch configuration H1 is able to reach H2. Let’s see if I can
create a new VLAN for H1 and H2:
SW1(config)#vlan 50
SW1(config-vlan)#name Computers
SW1(config-vlan)#exit
This is how you create a new VLAN. If you want, you can give it a name, but this is
optional. I’m calling my VLAN “Computers”.
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15,
Fa0/23, Fa0/24, Gi0/1, Gi0/2
50 Computers active
VLAN 50 was created on SW1 and you can see that it’s active. However, no ports are
currently in VLAN 50. Let’s see if we can change this…
SW1(config)interface fa0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 50
SW1(config)interface fa0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 50
First, I will configure the switchport in access mode with the switchport mode access
command. By using the switchport access vlan command we can move our interfaces
to another VLAN.
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10,, Fa0/12
Fa0/13, Fa0/14, Fa0/15,
Fa0/23, Fa0/24, Gi0/2
25 | P a g e
50 Computers active Fa0/1, Fa0/2
Excellent! Both computers are now in VLAN 50. Let’s verify our configuration by
checking if they can ping each other:
C:\Documents and Settings\H1>ping 192.168.1.2
Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Our computers are able to reach each other within VLAN 50. Besides pinging each other
we can also use another show command to verify our configuration:
SW1#show interfaces fa0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 50 (Computers)
Trunking Native Mode VLAN: 1 (default)
SW1#show interfaces fa0/2 switchport
Name: Fa0/2
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 50 (Computers)
Trunking Native Mode VLAN: 1 (default)
By using the “show interfaces switchport” command we can see that the operational
mode is “static access” which means it’s in access mode. We can also verify that the
interface is assigned to VLAN 50.
26 | P a g e
Want to take a look for yourself? Here you will find the final configuration of the switch.
hostname SW1
!
vlan 50
name Computers
!
interface FastEthernet0/1
switchport mode access
switchport access vlan 50
!
interface FastEthernet0/2
switchport mode access
switchport access vlan 50
!
End
802.1Q Encapsulation Explained
When you want VLAN traffic between two switches then there is one problem we run
into…take a look at the image below:
This is a normal Ethernet frame…do you see any field where we can specify to which
VLAN our Ethernet frame belongs? Well there isn’t! So how does a switch know to what
VLAN something belongs when it receives a frame? It has no clue so that’s why we
need another protocol to help us.
If you want to VLAN traffic between switches we have to use a trunk. A trunk connection
is simply said nothing more but a normal link, but it is able to pass traffic from different
VLANs and has a method to separate traffic between VLANs. Here’s an example:
27 | P a g e
As you can see, we have computers on both sides and they are in different VLANs, by
using trunks we can make sure all VLAN traffic can be sent between the switches.
Because our regular Ethernet frames don’t have anything to show to which VLAN they
belong we will need another protocol.
There are two trunking protocols:
802.1Q: This is the most common trunking protocol. It’s a standard and
supported by many vendors.
ISL: This is the Cisco trunking protocol. Not all switches support it.
Let’s take a look at 802.1Q:
Here’s an example of an 802.1Q Ethernet frame. As you can see it’s the same as a
normal Ethernet frame, but we have added a tag in the middle (that’s the blue field). In
our tag you will find a “VLAN identifier” which is the VLAN to which this Ethernet frame
belongs. This is how switches know to which VLAN our traffic belongs.
There’s also a field called “Priority” which is how we can give a different priority to the
different types of traffic. This is useful when you have one VLAN for voice over IP traffic
and another VLAN for data traffic, you probably want to give the VoIP traffic priority, or
your call quality might suffer.
802.1Q Native VLAN on Cisco IOS Switch
The IEEE 802.1Q trunking protocol describes something called the native VLAN.
All native VLAN traffic is untagged; it doesn’t have an 802.1Q tag on the Ethernet
frame. When you look at it in Wireshark, it will look the same, just like any standard
Ethernet frame.
When your Cisco switches receive an Ethernet frame without a tag on an 802.1Q
enabled interface, it will assume that it belongs to the native VLAN. For this reason, you
need to make sure that the native VLAN is the same on both sides.
By default, VLAN 1 is the native VLAN. We can change this if we want. Let’s look at an
example. I will use two switches for this:
28 | P a g e
I will configure an 802.1Q trunk between those two switches so we can look at the native
VLAN:
SW1(config)#interface Fastethernet 0/24
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW2(config)#interface Fastethernet 0/24
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
We can verify our trunk configuration and see the native VLAN like this:
SW1#show interface fastEthernet 0/24 trunk
Port Mode Encapsulation Status Native vlan
Fa0/24 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/24 1-4094
Port Vlans allowed and active in management domain
Fa0/24 1,10,12-13,20,23,34,100,123
Port Vlans in spanning tree forwarding state and not pruned
Fa0/24 1,10,12-13,20,23,34,100,123
SW2#show interfaces fastEthernet 0/24 trunk
Port Mode Encapsulation Status Native vlan
Fa0/24 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/24 1-4094
Port Vlans allowed and active in management domain
Fa0/24 1,10,12-13,20,23-24,30
Port Vlans in spanning tree forwarding state and not pruned
Fa0/24 1,10,12-13,20,23-24,30
Above, you can see that the trunk is operational, we are using 802.1Q encapsulation,
and the native VLAN is 1. So, what kind of traffic is running on the native VLAN? Let’s
take a look at a Wireshark capture of our trunk!
29 | P a g e
As you can see, some of the management protocols like CDP (Cisco Discovery
Protocol) are sent on the native VLAN. For security reasons, it might be a good idea to
change the native VLAN from VLAN 1 to something else. You can do it like this:
SW1(config)#interface fastEthernet 0/24
SW1(config-if)#switchport trunk native vlan 10
SW2(config)#interface fastEthernet 0/24
SW2(config-if)#switchport trunk native vlan 10
Instead of VLAN 1, we will now use VLAN 10 as the native VLAN. Let’s verify our work:
SW1#show interfaces fastEthernet 0/24 trunk
Port Mode Encapsulation Status Native vlan
Fa0/24 on 802.1q trunking 10
SW2#show interfaces fastEthernet 0/24 trunk
Port Mode Encapsulation Status Native vlan
Fa0/24 on 802.1q trunking 10
There we go, VLAN 10 is now the native VLAN. Last but not least, we can also configure
our switches to tag the native VLAN just like any other VLAN. Here’s how to do it:
SW1(config)#vlan dot1q tag native
SW2(config)#vlan dot1q tag native
30 | P a g e
That’s all there is to it! Hopefully, this lesson has been helpful to you to understand the
native VLAN and how to configure it.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname SW1
!
interface Fastethernet 0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 10
!
vlan dot1q tag native
!
end
hostname SW2
!
interface Fastethernet 0/24
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk native vlan 10
!
vlan dot1q tag native
!
end
802.1Q Tunneling (Q-in-Q) Configuration
802.1Q tunneling (aka Q-in-Q) is a technique often used by Metro Ethernet providers as
a layer 2 VPN for customers. 802.1Q (or dot1q) tunneling is pretty simple…the provider
will put an 802.1Q tag on all the frames that it receives from a customer with a unique
VLAN tag. By using a different VLAN tag for each customer we can separate the traffic
from different customers and also transparently transfer it throughout the service
provider network.
One of the advantages of this solution is that it’s easy to implement, you don’t need
exotic hardware and we don’t have to run any routing protocols between the service
provider and customer (unlike MPLS VPN). From the customer’s perspective, it’s just
like their sites are directly connected on layer 2.
In this lesson, I’m going to show you how to configure 802.1Q tunneling and I’ll explain
how it works. I’ll be using the following topology for this:
31 | P a g e
Above you see two routers called R1 and R2, imagine these routers are the customer
sites that we want to connect through the service provider network which consists of
SW1, SW2 and SW3. Our customer wants to use VLAN 12 between the two sites and
expects our service provider to transport this from one site to another.
In my example our customer will be using VLAN 12 for traffic between their sites. The
service provider has decided to use VLAN 123 to transport everything for this customer.
Basically, this is what will happen when we send frames between R1 and R2:
Whenever R1 sends traffic it will tag its frames for VLAN 12. Once it arrives at the
service provider, SW1 will add an additional VLAN tag (123). Once SW2 forwards the
frame towards R2 it will remove the second VLAN tag and forwards the original tagged
frame from R1.
Here is another way to visualize this:
Enough talk…let’s take a look at the configuration.
32 | P a g e
Here’s what the router configs look like:
R1(config)#interface fastEthernet 0/0
R1(config-if)#no shutdown
R1(config-if)#interface fastEthernet 0/0.12
R1(config-subif)#encapsulation dot1Q 12
R1(config-subif)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fastEthernet 0/0
R2(config-if)#no shutdown
R2(config-if)#interface fastEthernet 0/0.12
R2(config-subif)#encapsulation dot1Q 12
R2(config-subif)#ip address 192.168.12.2 255.255.255.0
R1 and R2 are both configured with sub-interfaces and use subnet 192.168.12.0 /24. All
their frames are tagged as VLAN 12.
On the service provider network we’ll have to configure a number of items. First, I will
configure 802.1Q trunks between SW1 – SW3 and SW2 – SW3:
SW1(config)#interface fastEthernet 0/19
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW2(config)#interface fastEthernet 0/21
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW3(config)#interface fastEthernet 0/19
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config)#interface fastEthernet 0/21
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
The next part is where we configure the actual “Q-in-Q” tunneling. The service provider
will use VLAN 123 to transfer everything from our customer. We’ll configure the
interfaces towards the customer routers to tag everything for VLAN 123:
SW1(config)#interface fastEthernet 0/1
SW1(config-if)#switchport access vlan 123
SW1(config-if)#switchport mode dot1q-tunnel
SW2(config)#interface fastEthernet 0/2
SW2(config-if)#switchport access vlan 123
SW2(config-if)#switchport mode dot1q-tunnel
The switchport mode dot1q-tunnel command tells the switch to tag the traffic
and switchport access vlan command is required to specify the Q-in-Q VLAN of 123.
Make sure that VLAN 123 is available on SW1, SW2 and SW3. By assigning the
33 | P a g e
interfaces above to this VLAN it was automatically created on SW1 and SW2, but I also
have to make sure that SW3 has VLAN 123 in its database:
SW3(config)#vlan 123
Everything is now in place, let’s do a quick test to see if R1 and R2 can reach each
other:
R1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Great! Our ping is working! Let’s take a look at some commands to verify our work:
SW1#show dot1q-tunnel
dot1q-tunnel mode LAN Port(s)
-----------------------------
Fa0/1
SW2#show dot1q-tunnel
dot1q-tunnel mode LAN Port(s)
-----------------------------
Fa0/2
The show dot1q-tunnel command doesn’t give me a lot of information. The only thing
we see are the interfaces that are configured for dot1q tunneling. A good way to prove
that the service provider switches are really tunneling the frames from the customer is by
looking at the trunks between SW1, SW2 and SW3:
SW1#show interfaces fa0/19 trunk
Port Mode Encapsulation Status Native vlan
Fa0/19 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/19 1-4094
Port Vlans allowed and active in management domain
Fa0/19 1,123
Port Vlans in spanning tree forwarding state and not pruned
Fa0/19 1,123
SW2#show interfaces trunk
34 | P a g e
Port Mode Encapsulation Status Native vlan
Fa0/21 on 802.1q trunking 1
Port Vlans allowed on trunk
Fa0/21 1-4094
Port Vlans allowed and active in management domain
Fa0/21 1,123
Port Vlans in spanning tree forwarding state and not pruned
Fa0/21 1,123
SW3#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Fa1/0/19 on 802.1q trunking 1
Fa1/0/21 auto n-802.1q trunking 1
Port Vlans allowed on trunk
Fa1/0/19 1-4094
Fa1/0/21 1-4094
Port Vlans allowed and active in management domain
Fa1/0/19 1,123
Fa1/0/21 1,123
Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/19 1,123
Fa1/0/21 1,123
As you can see above the only VLAN that is active (besides VLAN 1) on these trunk
links is VLAN 123. You won’t see VLAN 12 here because that’s the customer traffic and
it’s encapsulated with VLAN 123. Another good way to prove this is by looking at
spanning-tree:
SW1#show spanning-tree vlan 12
Spanning tree instance(s) for vlan 12 does not exist.
SW2#show spanning-tree vlan 12
Spanning tree instance(s) for vlan 12 does not exist.
SW3#show spanning-tree vlan 12
Spanning tree instance(s) for vlan 12 does not exist.
Our switches don’t have a spanning-tree topology for VLAN 12, they don’t care what
VLAN the customer is using…they only care about VLAN 123.
So far so good! 802.1Q tunneling has some more tricks up its sleeve, one of the things it
can do is tunnel some layer 2 protocols. Take a look below:
SW1(config)interface fastEthernet 0/1
35 | P a g e
SW1(config-if)#l2protocol-tunnel ?
cdp Cisco Discovery Protocol
drop-threshold Set drop threshold for protocol packets
point-to-point point-to-point L2 Protocol
shutdown-threshold Set shutdown threshold for protocol packets
stp Spanning Tree Protocol
vtp Vlan Trunking Protocol
<cr>
If you want it can tunnel CDP, VTP, STP and even point-to-point protocols like PAgP or
LACP (Etherchannel). Let me show you what happens when you tunnel CDP traffic:
SW1(config)#interface fastEthernet 0/1
SW1(config-if)#l2protocol-tunnel cdp
SW2(config)#interface fastEthernet 0/2
SW2(config-if)#l2protocol-tunnel cdp
I’ll tell SW1 and Sw2 to tunnel all CDP traffic between the interfaces that are connected
to R1 and R2. Take a look below for the result:
R1#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Fas 0/0 171 R S I 2811 Fas 0/1
By tunneling CDP packets between R1 and R2 they see each other as directly
connected. That’s a great example of a “transparent” network. Here’s what it looks like in
wireshark:
The last thing we have to discuss are MTU (Maximum Transmission Unit) problems.
36 | P a g e
The ethernet frame of the customer with the 802.1Q tag will have a MTU of 1500 bytes
but since we are adding another 802.1Q tag the total MTU will be 1504 bytes in the
service provider network. By default, most switches will only allow a maximum MTU of
1500 bytes so you will run into problems with large packets. Below you can see the
actual problem:
R1#ping 192.168.12.2 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
Because of second tag this ping will be dropped because the MTU is too small. To solve
this, you should increase the maximum MTU size of your switches:
SW1(config)#system mtu 1504
SW2(config)#system mtu 1504
SW3(config)#system mtu 1504
After configuring the MTU you have to reboot your switches. You can see the MTU size
like this:
SW1#show system mtu
System MTU size is 1504 bytes
System Jumbo MTU size is 1504 bytes
Routing MTU size is 1504 bytes
Our ping should now work:
R1#ping 192.168.12.2 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
There we go, problem solved! Here’s what this ping looks like in wireshark:
37 | P a g e
This is all I have for now on 802.1Q tunneling, I hope this has been helpful to you. If you
have any questions, feel free to leave a comment!
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
interface FastEthernet0/0.12
encapsulation dot1Q 12
ip address 192.168.12.1 255.255.255.0
!
end
hostname R2
!
interface FastEthernet0/1.12
encapsulation dot1Q 12
ip address 192.168.12.2 255.255.255.0
!
end
hostname SW1
!
vlan 123
!
interface FastEthernet0/1
switchport access vlan 123
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable
!
interface FastEthernet0/19
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
hostname SW2
!
vlan 123
!
interface FastEthernet0/2
switchport access vlan 123
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable
!
interface FastEthernet0/21
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
38 | P a g e
hostname SW3
!
vlan 123
!
interface FastEthernet1/0/19
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet1/0/21
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
Introduction to VTP (VLAN Trunking Protocol)
Let’s say you have a network with 20 switches and 50 VLANs. Normally you would have
to configure each switch separately and create those VLANs on each and every switch.
That’s a time-consuming task so there is something to help us called VTP (VLAN
Trunking Protocol). VTP will let you create VLANs on one switch and all the other
switches will synchronize themselves.
We have one VTP server which is the switch where you create / modify or delete
VLANs. The other switches are VTP clients. The VTP configuration has a revision
number which will increase when you make a change. Every time you make a change
on the VTP server this will be synchronized to the VTP clients. Oh, and by the way you
can have multiple VTP servers since it also functions as a VTP client so you can make
changes on multiple switches in your network. In order to make VTP work you need to
setup a VTP domain name which is something you can just make up, as long as you
configure it to be the same on all your switches.
This is the short version of what I just described:
1. VTP adds / modifies / deletes VLANs.
2. For every change the revision number will increase.
3. The latest advertisement will be sent to all VTP clients.
4. VTP clients will synchronize themselves with the latest information.
Besides the VTP server and VTP client there’s also a VTP transparent which is a bit
different, let me show you an example:
39 | P a g e
Our VTP Transparent will forward advertisements but will not synchronize itself. You
can create VLANs locally though which is impossible on the VTP client. Let’s say you
create VLAN 20 on our VTP server, this is what will happen:
1. You create VLAN 20 on the VTP server.
2. The revision number will increase.
3. The VTP server will forward the latest advertisement which will reach the VTP
transparent switch.
4. The VTP transparent will not synchronize itself but will forward the advertisement
to the VTP client.
5. The VTP client will synchronize itself with the latest information.
Here’s an overview of the 3 VTP modes:
VTP Server VTP VTP
Client Transparent
Create/Modify/Delete Yes No Only local
VLANs
Synchronizes itself Yes Yes No
Forwards advertisements Yes Yes Yes
Should you use VTP? It might sound useful but VTP has a big security risk…the problem
with VTP is that a VTP server is also a VTP Client and any VTP client will synchronize
itself with the highest revision number. The following situation can happen with VTP:
You have a network with a single VTP server and a couple of VTP client switches,
everything is working fine but one day you want to test some stuff and decide to take
one of the VTP clients out of the network and put it in a lab environment.
40 | P a g e
You take the VTP client switch out of the network.
1. You configure it so it’s no longer a VTP Client but a VTP server.
2. You play around with VTP, create some VLANs, modify some.
3. Every time you make a change the revision number increases.
4. You are done playing…you delete all VLANs.
5. You configure the switch from VTP Server to VTP Client.
6. You connect your switch to your production network.
What do you think the result will be? The revision number of VTP on the switch we
played with is higher than the revision number on the switches of our production
network. The VTP client will advertise its information to the other switches, they
synchronize to the latest information and POOF all your VLANs are gone! A VTP client
can overwrite a VTP server if the revision number is higher because a VTP server is
also a VTP client.
Yes, I know this sounds silly but this is the way it works…very dangerous since you’ll
lose all your VLAN information. Your interfaces won’t go back to VLAN 1 by default but
will float around in no man’s land…
One more thing about VTP, let me give you another picture:
You see we have computers in VLAN 10, 20 and 30. The links between the switches are
trunks using the 802.1Q protocol and carrying all VLAN traffic. One of our computers in
VLAN 10 sends a broadcast frame, where do you think this broadcast frame will go?
Broadcast frames have to be flooded by our switches and since our trunks are carrying
all VLANs, this broadcast will go everywhere. However, if you look at the switch in the
middle do you see any computer in VLAN 10? Nope there’s only VLAN 20 there which
means this broadcast is wasted bandwidth. By enabling VTP pruning we’ll make sure
there is no unnecessary VLAN traffic on trunks when there’s nobody in a particular
VLAN. Depending on your switch model VTP pruning is either turned on or off by default.
Let’s take a look at the configuration of VTP. I will be using three switches for this task. I
erased the VLAN database and the startup-configuration on all switches.
41 | P a g e
SW1#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name :
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
SW2#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name :
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
42 | P a g e
SW3#show vtp status
VTP Version : 2
Configuration Revision : 0
Maximum VLANs supported locally : 1005
Number of existing VLANs : 5
VTP Operating Mode : Server
VTP Domain Name :
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0x57 0xCD 0x40 0x65 0x63 0x59 0x47 0xBD
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 0.0.0.0 (no valid interface found)
Depending on the switch model you will see a similar output if you use the show vtp
status command. There’s a couple of interesting things to see here:
Configuration revision 0: Each time we add or remove VLANs this number will
change. It’s 0 at the moment since I haven’t created or removed any VLANs.
VTP Operating mode: the default is VTP server.
VTP Pruning: this will help to prevent unnecessary traffic on your trunk links,
more in this later.
VTP V2 Mode: The switch is capable of running VTP version 2 but it’s currently
running VTP version 1.
SW1(config)#vlan 10
SW1(config-vlan)#name Printers
Let’s create a VLAN on SW1 and we’ll see if anything changes…
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15, Fa0/22
Fa0/23, Fa0/24, Gi0/1, Gi0/2
10 Printers active
My new VLAN shows up in the VLAN database, so far so good…
43 | P a g e
SW1#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 1
You can see that the configuration revision has increased by one.
SW2#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 0
SW3#show vtp status
VTP Version : 2
Configuration Revision : 0
Unfortunately, nothing has changed on SW2 and SW3. This is because we need to
configure a VTP domain-name before it starts working.
SW2#debug sw-vlan vtp events
vtp events debugging is on
SW3#debug sw-vlan vtp events
vtp events debugging is on
Before I change the domain-name I’m going to enable a debug using the debug sw-
vlan vtp events command. This way we can see in real-time what is going on.
SW1(config)#vtp domain NETWORKLESSONS
Changing VTP domain name from NULL to NETWORKLESSONS
SW2#
VTP LOG RUNTIME: Summary packet received in NULL domain state
VTP LOG RUNTIME: Summary packet received, domain = NETWORKLESSONS, rev =
1, followers = 1, length 77, trunk Fa0/16
VTP LOG RUNTIME: Transitioning from NULL to NETWORKLESSONS domain
VTP LOG RUNTIME: Summary packet rev 1 greater than domain NETWORKLESSONS
rev 0
You will see the following debug information on SW2 and SW3; there are two interesting
things we can see here:
The switch receives a VTP packet from domain “NETWORKLESSONS” and
decides to change its own domain-name from “NULL” (nothing) to
“NETWORKLESSONS”. It will only change the domain-name if it doesn’t have a
domain-name.
The switch sees that the VTP packet has a higher revision number (1) than what
it currently has (0) and as a result it will synchronize itself.
SW2#no debug all
44 | P a g e
All possible debugging has been turned off
SW3#no debug all
All possible debugging has been turned off
Make sure to disable the debug output before you get flooded with information.
SW2#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 1
SW3#show vtp status
VTP Version : 2
Configuration Revision : 1
The revision number on SW2 and SW3 is now “1”.
SW2#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/13, Fa0/14, Fa0/15,
Fa0/23, Fa0/24, Gi0/1, Gi0/2
10 Printers active
SW3#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/10, Fa0/11, Fa0/12
Fa0/20, Fa0/22, Fa0/23,
Gi0/1, Gi0/2
10 Printers active
The show vlan command tells us that SW2 and SW3 have learned VLAN 10 through
VTP.
Since all switches are in VTP Server mode I can create VLANs on any switch and they
should all synchronize:
SW2(config)#vlan 20
SW2(config-vlan)#name Servers
SW3(config)#vlan 30
45 | P a g e
SW3(config-vlan)#name Management
Let’s create VLAN 20 on SW2 and VLAN 30 on SW3.
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
SW2#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
SW3#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
As you can see all switches know about the VLANs. What about the revision number?
Did it change?
SW1#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 3
SW2#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 3
SW3#show vtp status
VTP Version : 2
Configuration Revision : 3
Each time I create another VLAN the revision number increases by one. Let’s change
the VTP mode on SW2 to see what it does.
46 | P a g e
SW2(config)#vtp mode client
Setting device to VTP CLIENT mode.
SW2#show vtp status
VTP Version : running VTP1 (VTP2 capable)
Configuration Revision : 3
Maximum VLANs supported locally : 1005
Number of existing VLANs : 7
VTP Operating Mode : Client
It’s now running in VTP Client mode.
Right now, SW1 and SW3 are in VTP Server mode. SW2 is running VTP Client mode. I
have disconnected the link between SW1 and SW3 so there is no direct connection
between them.
I’ll create another VLAN on SW1 so we can see if SW2 and SW3 will learn it.
SW1(config)#vlan 40
SW1(config-vlan)#name Engineering
I’ll call the new VLAN “Engineering”.
SW2#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
SW2 learns about VLAN 40 through SW1.
SW3#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
SW3 learns about VLAN 40 through SW2. SW2 as a VTP client will synchronize itself
but it will also forward VTP advertisements.
SW2(config)#vlan 50
%VTP VLAN configuration not allowed when device is in CLIENT mode.
47 | P a g e
A switch running in VTP Client mode is unable to create VLANs so that’s why I get this
error if I try to create one.
What about the VTP Transparent mode? That’s the last one we have to try…
I’ll change SW2 to VTP Transparent mode and the link between SW1 and SW3 is still
disconnected.
SW2(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.
This is how we change SW2 to VTP Transparent mode.
SW1(config)#vlan 50
SW1(config-vlan)#name Research
Let’s create VLAN 50 for this experiment on SW1.
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
50 Research active
It shows up on SW1 as expected.
SW2#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
It doesn’t show up on SW2 because it’s in VTP transparent mode and doesn’t
synchronize itself.
SW3#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
48 | P a g e
50 Research active
It does show up on SW3! A switch in VTP Transparent mode will not synchronize
itself but it will forward VTP advertisements to other switches so they can synchronize
themselves.
What will happen if I create a VLAN on SW2? Let’s find out!
SW2(config)#vlan 60
SW2(config-vlan)#name Cameras
SW2#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
50 Research active
60 Cameras active
We can create this new VLAN on SW2 without any trouble. It’s in VTP Transparent
mode so we can do this.
SW1#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
50 Research active
SW3#show vlan
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
10 Printers active
20 Servers active
30 Management active
40 Engineering active
50 Research active
VLAN 60 doesn’t show up on SW1 and SW3 because SW2 is in VTP Transparent mode.
SW2 will not advertise its VLANs because they are only known locally.
Is there anything else you need to know about VTP Transparent mode?
SW2#show running-config
Building configuration...
vlan 10
49 | P a g e
name Printers
!
vlan 20
name Servers
!
vlan 30
name Management
!
vlan 40
name Engineering
!
vlan 60
name Cameras
There’s a difference between VTP Transparent mode VS Server/Client mode. If you look
at the running-config you will see that VTP Transparent stores all VLAN information in
the running-config. VTP Server and Client mode store their information in the VLAN
database (vlan.dat on your flash memory).
VTP Version 3
In an earlier lesson I explained the basics of VTP (version 1 and 2). The main goal of
VTP version 3 remains to synchronize VLANs but it has a number for extras. It’s been
around for a while but until recent IOS versions it wasn’t supported on Cisco Catalyst
Switches.
Here are some of the new additions to VTP version 3:
VTP primary server: only the primary server is able to create / modify / delete
VLANs. This is a great change as you can no longer “accidently” wipe all VLANs
like you could with VTP version 1 or 2.
Extended VLANs: you can now synchronize VLANs in the extended VLAN range
(1006 – 4094).
Private VLANs: if you have VLANs that are configured as private VLANs then
you can synchronize them with VTPv3.
RSPAN VLANs: remote SPAN VLANs can now be synchronized.
MST Support: one of the problems of MST is that you had to configure each
switch manually. With VTPv3, MST configurations are synchronized.
Authentication improvements: VTPv3 has more secure methods for
authentication.
VTP mode off: If you didn’t want to use VTP for version 1 or 2 then you had to
use the transparent mode. VTPv3 can be disabled globally or per interface.
Compatibility: VTP version 3 is compatible with version 2, not version 1.
I’ll walk you through each of those and show you how to configure VTP version 3. I’ll use
the following topology:
50 | P a g e
All interfaces between the switches are configured as trunks.
1. Configuration
1.1. Basic Configuration
First, we will try to enable VTP version 3 on one of our switches:
SW1(config)#vtp version 3
Cannot set the version to 3 because domain name is not configured
The domain name is now a requirement, it can’t be null. Let’s set one and try again:
SW1(config)#vtp domain NWL
Changing VTP domain name from NULL to NWL
%SW_VLAN-6-VTP_DOMAIN_NAME_CHG: VTP domain name changed to NWL.
SW1(config)#vtp version 3
Let’s do the same on SW2 and SW3:
SW2 & SW3#
(config)#vtp domain NWL
(config)#vtp version 3
All switches will be running in VTP server mode by default:
SW1#show vtp status | include Operating Mode
VTP Operating Mode : Server
SW2#show vtp status | include Operating Mode
VTP Operating Mode : Server
SW3#show vtp status | include Operating Mode
VTP Operating Mode : Server
Being VTP server however is not enough to make changes to the VLAN database, take
a look below:
SW1(config)#vlan 100
VTP VLAN configuration not allowed when device is not the primary server for vlan
database.
51 | P a g e
This is new, one of the switches has to be the primary server in order to create /
modify or delete VLANs. Let’s make SW1 our primary server:
SW1#vtp primary
This system is becoming primary server for feature vlan
No conflicting VTP3 devices found.
Do you want to continue? [confirm]
%SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0019.569d.5700 has become the primary server
for the VLAN VTP feature
As soon as I make SW1 the primary server then you’ll also see this message on the
other switches:
SW2 & SW3#
%SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0019.569d.5700 has become the primary server
for the VLAN VTP feature
SW1 is now the primary server. We can verify this from SW1 or any other switch in our
VTP domain:
SW1#show vtp status | include Primary
VTP Operating Mode : Primary Server
Primary ID : 0019.569d.5700
SW2#show vtp status | include Primary
Primary ID : 0019.569d.5700
Primary Description : SW1
SW3#show vtp status | include Primary
Primary ID : 0019.569d.5700
Primary Description : SW1
SW2 and SW3 are able to confirm that SW1 is the primary server. VTP version 3 also
has a new command that allows us to see all switches in the same VTP domain:
SW1#show vtp devices
Retrieving information from the VTP domain. Waiting for 5 seconds.
VTP Feature Conf Revision Primary Server Device ID Device Description
------------ ---- -------- -------------- -------------- ----------------------
VLAN No 6 0019.569d.5700 0011.214e.d180 SW3
VLAN No 6 0019.569d.5700 0011.bb0b.3600 SW2
You can run this command on any of your switches, it will show all VTP members (not
just the directly connected ones like CDP does).
52 | P a g e
Let’s see if we are able to synchronize some VLANs. We’ll start with something simple:
SW1(config)#vlan 100
SW1(config-vlan)#exit
Let’s create VLAN 100, it should show up on SW2 and SW3:
SW2 & SW3#show vlan | include VLAN0100
100 VLAN0100 active
There it is! We can also synchronize VLANs in the extended range (1006 – 4094). Let’s
give it a try:
SW1(config)#vlan 1234
SW1(config-vlan)#exit
Let’s verify if it has been synchronized:
SW1, SW2 & SW3#show vlan | include VLAN1234
1234 VLAN1234 active
No problem at all! Let’s look at some more advanced stuff.
1.2. Private VLANs
VTP version 3 is able to synchronize private VLAN information. It only synchronizes the
information from the VLAN database, not port information. Let’s create a private VLAN:
SW1(config)#vlan 501
SW1(config-vlan)#private-vlan community
SW1(config)#vlan 502
SW1(config-vlan)#private-vlan isolated
SW1(config)#vlan 500
SW1(config-vlan)#private-vlan primary
SW1(config-vlan)#private-vlan association add 501
SW1(config-vlan)#private-vlan association add 502
We’ll create VLAN 500 with two VLANs. VLAN 501 is a community VLAN and VLAN 502
is an isolated VLAN. Let’s see if it shows up on SW1:
SW1#show vlan private-vlan
53 | P a g e
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
500 502 isolated
501 community
SW2 & SW3#show vlan private-vlan
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
500 502 isolated
501 community
We see the exact same thing on SW2 and SW3. This is a nice addition to VTPv3.
1.3. Remote SPAN (RSPAN)
RSPAN VLANs are also a special “type” of VLANs. They can be synchronized with VTP
now. Here’s an example:
SW1(config)#vlan 600
SW1(config-vlan)#remote-span
SW1(config-vlan)#exit
Let’s check if it’s available on our switches:
SW1#show vlan remote-span
Remote SPAN VLANs
------------------------------------------------------------------------------
600
SW2#show vlan remote-span
Remote SPAN VLANs
------------------------------------------------------------------------------
600
SW3#show vlan remote-span
Remote SPAN VLANs
------------------------------------------------------------------------------
600
No problem, it has been synchronized to all switches.
1.4. MST (Multiple Spanning-Tree)
Synchronizing MST is pretty useful. In the past you had to configure each switch
separately. VTP version 3 uses a separate “feature” for MST. Take a look below:
54 | P a g e
SW1#show vtp status
VTP Version capable : 1 to 3
VTP version running : 3
VTP Domain Name : NWL
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : 0019.569d.5700
Feature VLAN:
--------------
VTP Operating Mode : Primary Server
Number of existing VLANs : 12
Number of existing extended VLANs : 1
Configuration Revision : 7
Primary ID : 0019.569d.5700
Primary Description : SW1
MD5 digest : 0xC9 0x25 0xB3 0x86 0xE7 0xA1 0xE3 0xAE
0xF8 0x2F 0xB9 0x7F 0x64 0xB3 0x43 0x5F
Feature MST:
--------------
VTP Operating Mode : Transparent
Feature UNKNOWN:
--------------
VTP Operating Mode : Transparent
The default “VLAN” feature is used for the things we did before…VLANs, extended
range VLANs, private VLANs and RSPAN. To synchronize MST information, we have to
use the “MST” feature. As you can see the VTP mode for this feature is currently
transparent.
Just like the VLAN feature, we require a primary server that will create the MST
configuration. You can use the same switch for this role, or you can pick another one. To
demonstrate this, I’ll make SW2 my primary server:
SW2(config)#vtp mode server mst
Setting device to VTP Server mode for MST.
First, I change SW2 from transparent to server mode. Now we can set it to primary:
SW2#vtp primary mst
This system is becoming primary server for feature mst
No conflicting VTP3 devices found.
Do you want to continue? [confirm]
%SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0011.bb0b.3600 has become the primary server
for the MST VTP feature
55 | P a g e
This message will also show up on SW1 and SW3:
SW1 & SW3#
%SW_VLAN-4-VTP_PRIMARY_SERVER_CHG: 0011.bb0b.3600 has become the primary server
for the MST VTP feature
OK great, take a look now at the VTP status output:
SW2#show vtp status | begin Feature MST
Feature MST:
--------------
VTP Operating Mode : Primary Server
Configuration Revision : 1
Primary ID : 0011.bb0b.3600
Primary Description : SW2
MD5 digest : 0xE1 0xFE 0x40 0x19 0x4C 0x47 0x4D 0xA5
0x9C 0x45 0x67 0xE3 0x9C 0xA3 0x92 0xEB
You can see that this switch is now the primary server for the MST feature. Let’s make
SW1 and SW3 our clients:
SW1 & SW3
(config)#vtp mode client mst
Setting device to VTP Client mode for MST.
Everything is now in place so let’s create a configuration for MST. I’ll keep it simple:
SW2(config)#spanning-tree mst configuration
SW2(config-mst)#name MST
SW2(config-mst)#revision 1
SW2(config-mst)#instance 1 vlan 10,20,30
SW2(config-mst)#instance 2 vlan 40,50,60
SW2(config-mst)#exit
Normally you’d have to copy and paste the above on all your switches. We are going to
synchronize it, first let’s enable MST on all switches:
SW1, SW2 & SW3
(config)#spanning-tree mode mst
Let’s verify the MST configuration:
SW2#show spanning-tree mst configuration
Name [MST]
56 | P a g e
Revision 1 Instances configured 3
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
1 10,20,30
2 40,50,60
-------------------------------------------------------------------------------
It’s showing up on SW2, that makes sense since that’s where we created it. What about
SW1 and SW3?
SW1#show spanning-tree mst configuration
Name [MST]
Revision 1 Instances configured 3
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
1 10,20,30
2 40,50,60
-------------------------------------------------------------------------------
SW3#show spanning-tree mst configuration
Name [MST]
Revision 1 Instances configured 3
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
1 10,20,30
2 40,50,60
-------------------------------------------------------------------------------
They received the MST configuration from SW2. It’s even stored in the running
configuration:
SW1#show running-config | begin mst
spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name MST
revision 1
instance 1 vlan 10, 20, 30
instance 2 vlan 40, 50, 60
Great, MST is working. Let’s look at some other things that VTP version 3 can do…
57 | P a g e
1.5. Feature Unknown
If you looked carefully at the output of show vtp status, then you might have noticed that
there were 3 features:
VLAN
MST
UNKNOWN
This “unknown” feature is a placeholder for upcoming features that VTPv3 might use
someday. Here’s the output of VTP status:
SW1#show vtp status | begin UNKNOWN
Feature UNKNOWN:
--------------
VTP Operating Mode : Transparent
Right now, you can only use the transparent mode for this, server and client are not
supported. If you try to enable it then you’ll get an error:
SW1(config)#vtp mode server unknown
Device cannot be VTP Server for unknown instances.
SW1(config)#vtp mode client unknown
Device cannot be VTP Client for unknown instances.
Transparent mode does work:
SW1(config)#vtp mode transparent unknown
Device mode already VTP Transparent for unknown instances.
We’ll just have to wait to see if VTPv3 will ever use a new feature…
1.6. Authentication
Authentication has slightly changed. Take a look below:
SW1(config)#vtp password NWL ?
hidden Set the VTP password hidden option
secret Specify the vtp password in encrypted form
<cr>
We have an option to use a hidden password. Let’s try that:
SW1, SW2 & SW3
(config)#vtp password NWL hidden
58 | P a g e
Setting device VTP password
The password is now set to “NWL”. You can’t extract this password in clear text from the
switch. Here’s how it shows up:
SW1#show vtp password
VTP Password: 2AA31883CB1D0E65FE199ADF177F433A
If you need to add another switch, then you could copy and paste the above secret like
this:
SW2(config)#vtp password 2AA31883CB1D0E65FE199ADF177F433A secret
Setting device VTP password
1.7. VTP Mode Off
VTP version 3 supports the “off” mode. The difference compared to the transparent
mode is that it will be disabled 100%. Transparent mode will not synchronize itself, but it
will keep forwarding VTP advertisements. Here’s how to disable VTP:
SW3(config)#vtp mode off ?
mst Set the mode for MST VTP instance.
unknown Set the mode for unknown VTP instances.
vlan Set the mode for VLAN VTP instance.
You can disable it for the different “features”. Here’s how to disable VTP for the VLAN
feature:
SW3(config)#vtp mode off vlan
It is now disabled globally. You can also disable VTP on the interface level:
SW3(config)#interface FastEthernet 1/0/21
SW3(config-if)#no vtp
This interface will no longer participate in VTP.
1.8. Backward Compatibility
VTP version 3 is compatible with version 2, not with version 1. Typically, when your
VTPv3 switch receives a VTPv2 advertisement it should forward an advertisement that is
compatible with version 2.
I tried to demonstrate this on my Cisco Catalyst 3750 switch but whatever I tried, it kept
ignoring my VTP advertisements. Here’s what I tried:
59 | P a g e
SW4(config)#vtp version 2
If you try this, make sure you disable the passwords on your VTPv3 switches. VTP
version 2 doesn’t support the new password mechanism:
SW1, SW2 & SW3(config)#no vtp password
Clearing device VTP password.
To see what is going on between the switches you can enable the following debug:
SW4#debug sw-vlan vtp packets
vtp packets debugging is on
In my case I kept receiving this message:
SW4#
VTP LOG RUNTIME: Incoming packet version rcvd 3 unknown
My 3750 switch running IOS image “c3750-ipservicesk9-mz.122-55.SE9.bin” was unable
to receive anything through VTP. I think this has something to do with this IOS version. If
you are getting another result, please let me know.
Voice VLAN
In this lesson, we’ll take a look at the Voice VLAN and how it works.
Usually, IP phones sit next to a computer on the same desk. They require the same UTP
cables as computers and also use Ethernet. If we want to connect them to a switch, we
have two options.
You could connect the computer and IP phone using two different cables:
This will work but it has some disadvantages:
You need to install a new cable from the switchport to the IP phone.
You will lose a switchport for the IP phone.
To solve this, most IP phones (including Cisco) have a three-port switch inside of the IP
phone:
60 | P a g e
One port connects to the switch.
One port connects to the computer.
One (internal) port connects to the phone.
This allows us to connect the IP phone and computer like this:
You probably want to separate the data from the computer and IP phone. This is
something we can do with voice VLANs.
The Voice VLAN is also known as the Auxiliary VLAN (AUX VLAN)
The computer will be in a data VLAN, the IP phone will be in the voice VLAN. It will look
like this:
Behind the scenes, we have a trunk between our switch and IP phone. The port on the
IP phone that connects to the computer is an access port. The IP phone will forward all
traffic from the computer to the switch untagged, traffic from the IP phone itself will
be tagged. The only two VLANs that are allowed though, are the access and voice
VLAN.
1. Configuration
If you are familiar with the configuration of VLANs then configuring a voice VLAN is very
simple. Let’s configure a switchport where we use VLAN 100 for the computer and VLAN
101 for our IP phone.
First, we have to create the two VLANs:
SW1(config)#vlan 100
SW1(config-vlan)#name COMPUTER
SW1(config-vlan)#exit
SW1(config)#vlan 101
SW1(config-vlan)#name VOIP
SW1(config-vlan)#exit
61 | P a g e
Now we can configure the interface:
SW1(config)#interface GigabitEthernet 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 100
SW1(config-if)#switchport voice vlan 101
SW1(config-if)#exit
We configure the interface in access mode and use VLAN 100 for the computer.
The switchport voice vlan command tells the switch to use VLAN 101 as the voice
VLAN.
We configured the switch but how does the IP phone know which VLANs to use? Cisco
IP phones use CDP (Cisco Discovery Protocol) for this. The IP Phone will learn through
CDP which VLANs it should use. Other IP phones sometimes use LLDP (Link Layer
Discovery Protocol) for this.
2. Verification
Let’s verify our work. You have to use the show interfaces command for this:
SW1#show interfaces GigabitEthernet 0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 100 (COMPUTER)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: 101 (VOIP)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: 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
62 | P a g e
Above you can see that we are using VLAN 100 for the Computers and VLAN 101 for
the IP phones.
We can also take a look at the trunk status. Although this will show us that the interface
is not-trunking, it does tell us the two VLANs that are used:
SW1#show interfaces GigabitEthernet 0/1 trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 off negotiate not-trunking 1
Port Vlans allowed on trunk
Gi0/1 100-101
Port Vlans allowed and active in management domain
Gi0/1 100-101
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 100-101
Above we see that VLAN 100 and 101 are allowed on this interface. Although it shows
up as non-trunking, keep in mind that in reality, this is a trunk.
3. Conclusion
In this lesson you have learned how to configure the Voice VLAN and how to verify your
work. If you have any questions, feel free to leave a comment in our forum.
63 | P a g e
1.1.d: EtherChannel
In this lesson, we’ll take a look at EtherChannel which is also known as link
aggregation. EtherChannel is a technology that lets you bundle multiple physical links
into a single logical link. We’ll take a look at how it works and what the advantages of
EtherChannel are. Let’s start with an example of a small network:
Take a look at the picture above. I have two switches and two computers connected to
each switch. We use Gigabit Ethernet interfaces everywhere.
Now imagine that H1 sends 800 Mbit of traffic destined to H3 and H2 sends 600 Mbit of
traffic destined to H4. The link between the switches will be a bottleneck. We require 800
+ 600 = 1400 Mbit but we only have a 1000 Mbit link.
There are two solutions to this problem:
Replace the link in between the switches with something that has a higher
bandwidth, perhaps a 10-Gigabit link.
Add multiple links and bundle them into an EtherChannel.
Since this lesson is about EtherChannel, we’ll take a look at adding multiple links. Here’s
an example:
64 | P a g e
In the picture above I have added a couple of extra links. The problem with this setup is
that we have a loop between the switches so spanning-tree would block one out of two
links. EtherChannel solves this problem because it creates a single virtual link out of
these physical links:
Spanning tree sees this link as one logical link so there are no loops! EtherChannel will
do load balancing among the different links that we have and it takes care of
redundancy. Once one of the links fails it will keep working and use the links that we
have left.
Keep in mind that the physical links remain the limiting factor. A single traffic flow won’t
be able to exceed > 1000 Mbit (single Gigabit link). An Etherchannel is the equivalent of
adding more lanes to a highway. The bandwidth increases, but the speed limit doesn’t
change.
You can assign up to 16 physical interfaces to an EtherChannel but only 8
interfaces will be active at a time.
If you want to configure an EtherChannel then we have three options:
PAgP (Cisco proprietary)
65 | P a g e
LACP (IEEE standard)
Manual
PAgP and LACP are negotiation protocols that dynamically configure an Etherchannel.
PAgP is a Cisco proprietary protocol so you can only use it between Cisco devices.
LACP is an IEEE standard which many vendors support.
It’s also possible to configure a static EtherChannel without these protocols doing the
negotiation of the link for you.
If you are going to create an EtherChannel you need to make sure that all interfaces
have the same configuration:
Duplex.
Speed.
Native and allowed VLANs.
Switchport mode (access or trunk).
Desirable Auto
Desirable Yes Yes
Auto Yes No
PAgP and LACP will check if the configuration of the interfaces that you use is the same.
1. Configuration
Let’s see if we can configure an Etherchannel. We’ll try all three options but start with
PAgP.
1.1. PAgP
If you want to configure PAgP there are two options, you can choose from. The interface
can be configured as:
Desirable: The interface will actively ask the other side to become an
EtherChannel.
Auto: The interface will wait passively for the other side to ask to become an
EtherChannel.
Here’s a quick overview with the two PAgP configuration options and whether an
EtherChannel will form or not:
Let me show you an example of how to configure PAgP between two switches. I’ll use
SW1 and SW2 for this demonstration:
66 | P a g e
SW1 and SW2 each have two Gigabit interfaces which we’ll bundle these into a single
logical link.
Here are our options:
SW1(config)#interface GigabitEthernet 0/1
SW1(config-if)#channel-group 1 mode ?
active Enable LACP unconditionally
auto Enable PAgP only if a PAgP device is detected
desirable Enable PAgP unconditionally
on Enable EtherChannel only
passive Enable LACP only if a LACP device is detected
We use the channel-group command on the interface-level. You can pick any number
you like; I’ll go for 1. We need to decide whether we use auto or desirable mode. I’ll
configure SW1 to use desirable mode:
SW1(config)#interface range GigabitEthernet 0/1 - 2
SW1(config-if)#channel-group 1 mode desirable
I configure SW1 for PAgP desirable mode. It will actively ask SW2 to become an
EtherChannel this way. We can configure SW2 in either auto or desirable mode. I’ll use
auto mode:
SW2(config)#interface range GigabitEthernet 0/1 - 2
SW2(config-if)#channel-group 1 mode auto
With auto mode, SW2 will only respond to incoming PAgP requests. After a few
seconds, you’ll see the following message on both switches:
SW1 %LINK-3-UPDOWN: Interface Port-channel1, changed state to up
The switch automatically creates a new port-channel interface:
SW1#show interfaces port-channel 1
Port-channel1 is up, line protocol is up (connected)
Hardware is EtherChannel, address is fa16.3e15.5fb2 (bia fa16.3e15.5fb2)
MTU 1500 bytes, BW 2000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:03:04, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
67 | P a g e
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
12 packets input, 973 bytes, 0 no buffer
Received 0 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
240 packets output, 17496 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
At the moment, there’s nothing configured under the port-channel interface:
SW1#show run interface Port-channel 1
interface Port-channel1
end
Our two physical interfaces that belong to this EtherChannel only have the channel-
group command:
SW1#show run interface GigabitEthernet 0/1
interface GigabitEthernet0/1
channel-group 1 mode desirable
end
SW1#show run interface GigabitEthernet 0/2
interface GigabitEthernet0/2
channel-group 1 mode desirable
end
If you want to make any changes like configuring the EtherChannel as a trunk, you need
to do this under the port-channel interface. For example:
SW1(config)#interface Port-channel 1
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
When you do this, the switch automatically adds the commands to the physical
interfaces as well:
68 | P a g e
SW1#show run interface GigabitEthernet 0/1
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable
end
SW1#show run interface GigabitEthernet 0/2
interface GigabitEthernet0/2
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable
end
You shouldn’t make any changes to the physical interfaces that belong to the
EtherChannel. Always use the port-channel interface.
Let’s continue and take a closer look at the status of the EtherChannel with some show
commands. Here’s the first one:
SW1#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) PAgP Gi0/1(P) Gi0/2(P)
The show EtherChannel summary command gives a nice clean overview with all your
EtherChannels. It tells us whether the EtherChannel is up and which protocol we use.
Here’s another show command:
SW1#show etherchannel 1 port-channel
Port-channels in the group:
---------------------------
Port-channel: Po1
------------
69 | P a g e
Age of the Port-channel = 0d:00h:10m:16s
Logical slot/port = 2/1 Number of ports = 2
GC = 0x00010001 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = PAgP
Port security = Disabled
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 gi0/1 Desirable-Sl 0
0 00 gi0/2 Desirable-Sl 0
Time since last port bundled: 0d:00h:00m:07s Gi0/1
Time since last port Un-bundled: 0d:00h:04m:08s Gi0/2
The show etherchannel command gives you an overview of our EtherChannel. You can
see the protocol and interfaces we use, and it tells us whether the logical interface is up.
Here’s the last show command you can use:
SW1#show interfaces GigabitEthernet 0/1 etherchannel
Port state = Up Mstr In-Bndl
Channel group = 1 Mode = Desirable-Sl Gcchange = 0
Port-channel = Po1 GC = 0x00010001 Pseudo port-channel = Po1
Port index = 0 Load = 0x00 Protocol = PAgP
Flags: S - Device is sending Slow hello. C - Device is in Consistent state.
A - Device is in Auto mode. P - Device learns on physical port.
d - PAgP is down.
Timers: H - Hello timer is running. Q - Quit timer is running.
S - Switching timer is running. I - Interface timer is running.
Local information:
Hello Partner PAgP Learning Group
Port Flags State Timers Interval Count Priority Method Ifindex
Gi0/1 SC U6/S7 H 30s 1 128 Any 5001
Partner's information:
Partner Partner Partner Partner Group
Port Name Device ID Port Age Flags Cap.
Gi0/1 SW2 0019.569d.5700 Gi0/1 19s SAC 10001
Age of the port in the current state: 0d:00h:02m:37s
The third method to verify your EtherChannel is to use the show interfaces command. In
my example, I am looking at the information of the GigabitEthernet 0/1 interface. Besides
information on our local switch, you can also see the interface of our neighbor switch.
Want to take a look for yourself? Here you will find the final PAgP configuration of each
device.
70 | P a g e
hostname SW1
!
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable
!
interface GigabitEthernet0/2
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 1 mode desirable
!
interface port-channel 1
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
hostname SW2
!
interface GigabitEthernet0/1
channel-group 1 mode auto
!
interface GigabitEthernet0/2
channel-group 1 mode auto
!
interface port-channel 1
!
end
1.2. LACP
LACP is similar to PAgP but uses different terminology:
Active: The interface will actively ask the other side to become an EtherChannel.
Passive: The interface waits passively for the other side to ask to become an
EtherChannel.
At least one switch should use active mode. When both switches use passive mode,
nothing will happen.
Active Passive
Active Yes Yes
Passive Yes No
I’ll use the same topology we used for PAgP:
71 | P a g e
We’ll configure SW1 to use active mode:
SW1(config-if)#interface range GigabitEthernet 0/1 - 2
SW1(config-if)#channel-group 1 mode active
And SW2 will use passive mode:
SW2(config)#interface range GigabitEthernet 0/1 - 2
SW2(config-if)#channel-group 1 mode passive
Let’s verify our work. We can use the same show commands we use for PAgP:
SW1#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use N - not in use, no aggregation
f - failed to allocate aggregator
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) LACP Gi0/1(P) Gi0/2(P)
Let’s try the show etherchannel command:
SW1#show etherchannel 1 port-channel
Port-channels in the group:
---------------------------
72 | P a g e
Port-channel: Po1 (Primary Aggregator)
------------
Age of the Port-channel = 0d:00h:01m:43s
Logical slot/port = 16/0 Number of ports = 2
HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = LACP
Port security = Disabled
Load share deferral = Disabled
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Gi0/1 Active 0
0 00 Gi0/2 Active 0
Time since last port bundled: 0d:00h:01m:04s Gi0/2
And last but not least, let’s try show interfaces:
SW1#show interfaces GigabitEthernet 0/1 etherchannel
Port state = Up Mstr Assoc In-Bndl
Channel group = 1 Mode = Active Gcchange = -
Port-channel = Po1 GC = - Pseudo port-channel = Po1
Port index = 0 Load = 0x00 Protocol = LACP
Flags: S - Device is sending Slow LACPDUs F - Device is sending fast LACPDUs.
A - Device is in active mode. P - Device is in passive mode.
Local information:
LACP port Admin Oper Port Port
Port Flags State Priority Key Key Number State
Gi0/1 SA bndl 32768 0x1 0x1 0x2 0x3D
Partner's information:
LACP port Admin Oper Port Port
Port Flags Priority Dev ID Age key Key Number State
Gi0/1 SP 32768 5e00.0001.8000 18s 0x0 0x1 0x2 0x3C
Age of the port in the current state: 0d:00h:01m:37s
As you can see the protocol is now LACP, we have a Port-channel 1 interface with two-
member physical interfaces.
Want to take a look for yourself? Here you will find the final LACP configuration of each
device.
73 | P a g e
hostname SW1
!
interface GigabitEthernet0/1
channel-group 1 mode active
!
interface GigabitEthernet0/2
channel-group 1 mode active
!
interface port-channel 1
!
end
hostname SW2
!
interface GigabitEthernet0/1
channel-group 1 mode passive
!
interface GigabitEthernet0/2
channel-group 1 mode passive
!
interface port-channel 1
!
End
1.3. Manual
Instead of PAgP or LACP, we can also manually enable the Etherchannel. I’ll use the
same topology to demonstrate this:
Here’s the configuration:
SW1(config)#interface range GigabitEthernet 0/1 - 2
SW1(config-if-range)#channel-group 1 mode on
SW2(config)#interface range GigabitEthernet 0/1 - 2
SW2(config-if-range)#channel-group 1 mode on
That’s all there is to it. Let’s try our show commands. We’ll start with an overview:
SW1#show etherchannel summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use N - not in use, no aggregation
f - failed to allocate aggregator
74 | P a g e
M - not in use, minimum links not met
m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated
d - default port
A - formed by Auto LAG
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
1 Po1(SU) - Gi0/1(P) Gi0/2(P)
In the output above, you can see we don’t use any protocol. Let’s take a closer look at
the Port-channel interface:
SW1#show etherchannel 1 port-channel
Port-channels in the group:
---------------------------
Port-channel: Po1
------------
Age of the Port-channel = 0d:00h:06m:54s
Logical slot/port = 16/0 Number of ports = 2
GC = 0x00000000 HotStandBy port = null
Port state = Port-channel Ag-Inuse
Protocol = -
Port security = Disabled
Load share deferral = Disabled
Ports in the Port-channel:
Index Load Port EC state No of bits
------+------+------+------------------+-----------
0 00 Gi0/1 On 0
0 00 Gi0/2 On 0
Time since last port bundled: 0d:00h:01m:21s Gi0/2
Time since last port Un-bundled: 0d:00h:04m:05s Gi0/2
And we can check one of the two physical interfaces and see the Etherchannel
information:
SW1#show interfaces GigabitEthernet 0/1 etherchannel
Port state = Up Mstr In-Bndl
Channel group = 1 Mode = On Gcchange = -
Port-channel = Po1 GC = - Pseudo port-channel = Po1
75 | P a g e
Port index = 0 Load = 0x00 Protocol = -
Age of the port in the current state: 0d:00h:01m:41s
That’s all we have.
Want to take a look for yourself? Here you will find the final manual configuration of each
device.
hostname SW1
!
interface GigabitEthernet0/1
channel-group 1 mode on
!
interface GigabitEthernet0/2
channel-group 1 mode on
!
interface port-channel 1
!
end
hostname SW2
!
interface GigabitEthernet0/1
channel-group 1 mode on
!
interface GigabitEthernet0/2
channel-group 1 mode on
!
interface port-channel 1
!
end
1.4. Load Balancing
The last thing I want to show you about EtherChannel is load-balancing. Take a look at
the following output:
SW1#show EtherChannel load-balance
EtherChannel Load-Balancing Configuration:
src-mac
EtherChannel Load-Balancing Addresses Used Per-Protocol:
Non-IP: Source MAC address
IPv4: Source MAC address
IPv6: Source MAC address
76 | P a g e
Use the show etherchannel load-balance command to see what the default configuration
is. As you can see, this switch load balances based on the source MAC address. If you
want, you can change this behavior with the port-channel load-balance command:
SW1(config)#port-channel load-balance ?
dst-ip Dst IP Addr
dst-mac Dst Mac Addr
src-dst-ip Src XOR Dst IP Addr
src-dst-mac Src XOR Dst Mac Addr
src-ip Src IP Addr
src-mac Src Mac Addr
There are plenty of options to choose from, including combinations of source and/or
destination MAC or IP addresses.
Why should you care about load balancing? Take a look at the picture below:
We have SW1 and four computers. On the right side, we have SW2 and a router. The
default load-balancing mechanism is source MAC address. This means that ALL traffic
from one MAC address will be sent down one and the same physical interface, for
example:
MAC address AAA will be sent using SW1’s gi0/1 interface.
MAC address BBB will be sent using SW1’s gi0/2 interface.
MAC address CCC will be sent using SW1’s gi0/1 interface.
MAC address DDD will be sent using SW1’s gi0/2 interface.
Since we have multiple computers this is fine, both physical links on SW1 will be used
for our EtherChannel so depending on how much traffic the computers send it will be
close to a 1:1 ratio.
It’s a different story for SW2 since we only have one router with MAC address EEE. It
will pick one of the physical interfaces so ALL traffic from the router will be sent down
interface GigabitEthernet 0/1 or 0/2. One of the physical links won’t be used at all.
If this is the case, it might be better to change your load balancing algorithm. For
example, on SW2 we could do this:
77 | P a g e
SW2(config)#port-channel load-balance dst-mac
If we switch the load balancing to destination MAC address on SW2 then traffic from our
router to the computers will be load-balanced amongst the different physical interfaces
because we have multiple computers with different destination MAC addresses.
Want to take a look for yourself? Here you will find the final load-balancing configuration
of each device.
hostname SW1
!
interface GigabitEthernet0/1
channel-group 1 mode active
!
interface GigabitEthernet0/2
channel-group 1 mode active
!
interface port-channel 1
switchport trunk encapsulation dot1q
switchport mode trunk
!
end
hostname SW2
!
interface GigabitEthernet0/1
channel-group 1 mode passive
!
interface GigabitEthernet0/2
channel-group 1 mode passive
!
interface port-channel 1
switchport trunk encapsulation dot1q
switchport mode trunk
!
port-channel load-balance dst-mac
!
end
2. Conclusion
You have now learned what an EtherChannels are and how to configure them:
An EtherChannel is a logical interface that bundles multiple physical interfaces.
Spanning-tree sees an Etherchannel as a single interface so it won’t block
redundant physical links.
There are three options to configure an EtherChannel:
o PAgP: A Cisco proprietary protocol.
o LACP: An IEEE standard.
o Manual: Bundle multiple physical interfaces without any protocol.
78 | P a g e
EtherChannels support multiple load-balancing options. Make sure you select a
load-balancing algorithm that matches your traffic patterns.
Layer 3 Etherchannel on Cisco IOS Switch
In a previous lesson I explained how EtherChannel work and how to configure them, but
I didn’t write about layer 3 EtherChannels before. In this lesson, I’ll show you how to
configure them.
A layer 3 etherchannel is similar to an interface on a router. The switch won’t “switch”
traffic on this interface but route it. Because it’s a layer 3 interface, we configure an IP
address on it.
I’ll be using two switches for this:
Before we configure the port channel settings you need to make sure that all interfaces
have the exact same configuration. Once you use the channel-group command, the
port-channel interface will automatically inherit all settings from your physical interface. If
you forget to run the no switchport command on an interface, your etherchannel will be
layer 2 instead of layer 3!
Having said that, let’s configure our switches:
SW1(config)#interface range fastEthernet 0/1 - 2
SW1(config-if-range)#no switchport
SW1(config-if-range)#channel-group 12 mode on
Creating a port-channel interface Port-channel 12
SW2(config)#interface range fa0/1 - 2
SW2(config-if-range)#no switchport
SW2(config-if-range)#channel-group 12 mode on
Creating a port-channel interface Port-channel 12
This creates our Etherchannel, we can verify our work like this:
SW1#show etherchannel 12 summary
Flags: D - down P - bundled in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
U - in use f - failed to allocate aggregator
M - not in use, minimum links not met
u - unsuitable for bundling
79 | P a g e
w - waiting to be aggregated
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
12 Po12(RU) - Fa0/1(P) Fa0/2(P)
Above you can see that our port-channel 12 interface is layer 3 and it’s operational. Just
like any other layer 3 interface we can configure an IP address on this port-channel
interface:
SW1(config)#interface port-channel 12
SW1(config-if)#ip address 192.168.12.1 255.255.255.0
SW2(config)#interface port-channel 12
SW2(config-if)#ip address 192.168.12.2 255.255.255.0
Let’s see if that works:
SW1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
No problem at all! If you enabled ip routing on your switch you will see that the switch
uses the port-channel interface in its routing table:
SW1#show ip route connected
C 192.168.12.0/24 is directly connected, Port-channel12
That’s all there is to it, I hope this lesson has been useful to you!
80 | P a g e
1.1.e: Spanning-Tree
Spanning-tree is a protocol that runs on our switches that helps us to solve loops.
Spanning-tree is one of the protocols that you must understand as a network engineer
and you will encounter it for sure if you decide to face the Cisco CCNA R&S exam. This
lesson is an introduction to spanning-tree, you will learn why we need it, how it works
and how you can check the spanning-tree topology on your Cisco switches.
1. Why do we need spanning-tree?
What is a loop and how do we get one? Let me show you an example:
In the picture above we have two switches. These switches are connected to each other
with a single cable so there is a single point of failure. To get rid of this single point of
failure we will add another cable:
81 | P a g e
With the extra cable we now have redundancy. Unfortunately for us redundancy also
brings loops. Why do we have a loop in the scenario above? Let me describe it to you:
1. H1 sends an ARP request because it’s looking for the MAC address of H2. An
ARP request is a broadcast frame.
2. SW1 will forward this broadcast frame on all it interfaces, except the interface
where it received the frame on.
3. SW2 will receive both broadcast frames.
Now what does SW2 do with those broadcast frames?
1. It will forward it out of every interface except the interface where it received the
frame on.
2. This means that the frame that was received on interface Fa0/0 will be forwarded
on Interface Fa1/0.
3. The frame that was received on Interface Fa1/0 will be forwarded on Interface
Fa0/0.
Do you see where this is going? We have a loop! Both switches will keep forwarding
over and over again until the following happens:
You fix the loop by disconnecting one of the cables.
One of your switches will crash because they are overburdened with traffic.
Ethernet frames don’t have a TTL (Time to Live) value so they will loop around forever.
Besides ARP requests there are many frames that are broadcasted. For example,
whenever the switch doesn’t know about a destination MAC address it will be flooded.
2. How spanning-tree solves loops
Spanning-tree will help us to create a loop-free topology by blocking certain interfaces.
Let’s take a look how spanning-tree works! Here’s an example:
82 | P a g e
We have three switches and as you can see, we have added redundancy by connecting
the switches in a triangle, this also means we have a loop here. I have added the MAC
addresses but simplified them for this example:
SW1: MAC AAA
SW2: MAC BBB
SW3: MAC CCC
Since spanning tree is enabled, all our switches will send a special frame to each other
called a BPDU (Bridge Protocol Data Unit). In this BPDU there are two pieces of
information that spanning-tree requires:
MAC address
Priority
The MAC address and the priority together make up the bridge ID. The BPDU is sent
between switches as shown in the following picture:
83 | P a g e
Spanning-tree requires the bridge ID for its calculation. Let me explain how it works:
First of all, spanning tree will elect a root bridge; this root-bridge will be the one
that has the best “bridge ID”.
The switch with the lowest bridge ID is the best one.
By default, the priority is 32768 but we can change this value if we want.
So, who will become the root bridge? In our example SW1 will become the root bridge!
Priority and MAC address make up the bridge ID. Since the priority is the same on all
switches it will be the MAC address that is the tiebreaker. SW1 has the lowest MAC
address thus the best bridge ID and will become the root bridge.
The ports on our root bridge are always designated which means they are in
a forwarding state. Take a look at the following picture:
Above you see that SW1 has been elected as the root bridge and the “D” on the
interfaces stands for designated.
Now we have agreed on the root bridge our next step for all our “non-root” bridges (so
that’s every switch that is not the root) will have to find the shortest path to our root
bridge! The shortest path to the root bridge is called the “root port”. Take a look at my
example:
84 | P a g e
I’ve put an “R” for “root port” on SW2 and SW3, their Fa0/0 interface is the shortest
path to get to the root bridge. In my example I’ve kept things simple but “shortest path” in
spanning tree means it will actually look at the speed of the interface. Each interface
has a certain cost and the path with the lowest cost will be used. Here’s an overview of
the interfaces and their cost:
10 Mbit = Cost 100
100 Mbit = Cost 19
1000 Mbit = Cost 4
Excellent…we have designated ports on our root bridge and root ports on our non-root
bridges, we still have a loop however, so we need to shut down a port between SW2 and
SW3 to break that loop. So which port are we going to shut down? The one on SW2 or
the one on SW3? We’ll look again at the best bridge ID:
Bridge ID = Priority + MAC address.
Lower is better, both switches have the same priority but the MAC address of SW2 is
lower, this means that SW2 will “win this battle”. SW3 is our loser here which means it
will have to block its port, effectively breaking our loop! Take a look at my example:
85 | P a g e
If you look at the link between SW2 and SW3 you can see that the Fa1/0 interface of
SW3 says “A” which stands for alternate. An alternate port is blocked! Sometimes the
alternate port is called the ND (Non-Designated) port. By shutting down this interface
we have solved our loop problem.
Because the default priority is 32768 the tie-breaker for selecting the root bridge is the
MAC address. In a production network what switch do you think will be elected as the
root bridge?
Your brand spanking new switch or that dirty old switch that has been used as a dust
collector for the last 8 years?
The old switch probably has a lower MAC address and thus will be elected as the root
bridge. Doesn’t sound like a good idea right? That’s why we can change the priority to
determine what switch will become the root bridge.
Are you following me so far? Good! You just learned the basics of spanning-tree. Let’s
add some more detail to this story…
Let’s continue our spanning tree story and further enhance your knowledge. If you have
played with some Cisco switches before you might have noticed that every time you
plugged in a cable the led above the interface was orange and after a while became
green. What is happening at this moment is that spanning tree is determining the state of
the interface; this is what happens as soon as you plug in a cable:
The port is in listening mode for 15 seconds. In this phase it will receive and
send BPDUs, still neither learning MAC addresses nor data transmission.
The port is in learning mode for 15 seconds. We are still sending and receiving
BPDUs but now the switch will also learn MAC addresses, still no data
transmission though.
Now we go in forwarding mode and finally we can start transmitting data!
Here’s a picture to visualize it:
86 | P a g e
`
3. Spanning-tree configuration on Cisco switches
Now you have an idea what spanning-tree is about. Let’s take a look at some Cisco
switches to see how we can configure it. I will use the same topology that I showed you
earlier, but we have different interfaces.
This is the topology we will use. Spanning-tree is enabled by default; let’s start by
checking some show commands.
SW1#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000f.34ca.1000
Cost 19
Port 19 (FastEthernet0/17)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
87 | P a g e
Address 0011.bb0b.3600
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Fa0/14 Desg FWD 19 128.16 P2p
Fa0/17 Root FWD 19 128.19 P2p
The show spanning-tree command is the most important show command to remember.
There’s quite some stuff here so I’m going to break it down for you!
VLAN0001
Spanning tree enabled protocol ieee
We are looking at the spanning-tree information for VLAN 1. Spanning-tree has multiple
versions and the default version on Cisco switches is PVST (Per VLAN spanning-tree).
This is the spanning-tree for VLAN 1
Root ID Priority 32769
Address 000f.34ca.1000
Cost 19
Port 19 (FastEthernet0/17)
Here you see the information of the root bridge. You can see that it has a priority of
32769 and its MAC address is 000f.34ca.1000. From the perspective of SW1 it has a
cost of 19 to reach the root bridge. The port that leads to the root bridge is called the root
port and for SW1 this is fa0/17.
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0011.bb0b.3600
This part shows us the information about the local switch, SW1 in our case. There’s
something funny about the priority here….you can see it show two things:
Priority 32769
Priority 32768 sys-id-ext 1
The sys-id-ext value that you see is the VLAN number. The priority is 32768 but
spanning-tree will add the VLAN number so we end up with priority value 32769. Last
but not least we can see the MAC address of SW1 which is 0011.bb0b.3600.
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
88 | P a g e
Here’s some information on the different times that spanning-tree uses:
Hello time: every 2 seconds a BPDU is sent.
Max Age: If we don’t receive BPDUs for 20 seconds we know something has
changed in the network and we need to re-check the topology.
Forward Delay: This timer is used for the listening and learning states. We remain
in each state for the duration of the forward delay which is 15 seconds by default.
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Fa0/14 Desg FWD 19 128.16 P2p
Fa0/17 Root FWD 19 128.19 P2p
The last part of the show spanning-tree commands shows us the interfaces and their
status. SW1 has two interfaces:
Fa0/14 is a designated port and in (FWD) forwarding mode.
Fa0/17 is a root port and in (FWD) forwarding mode.
The prio.nbr you see here is the port priority that I explained earlier. We’ll play with this
in a bit.
Because only non-root switches have a root-port I can conclude that SW1 is a non-root
switch. I know that fa0/17 on SW1 leads to the root bridge.
Let’s take a look at SW2 to see what we find:
SW2#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000f.34ca.1000
Cost 19
Port 18 (FastEthernet0/16)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0019.569d.5700
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Fa0/14 Altn BLK 19 128.16 P2p
Fa0/16 Root FWD 19 128.18 P2p
What do we see here?
89 | P a g e
Root ID Priority 32769
Address 000f.34ca.1000
Cost 19
Port 18 (FastEthernet0/16)
Here we see information about the root bridge. This information is similar to what we
saw on SW1. The root port for SW2 seems to be fa0/16.
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0019.569d.5700
This is the information about SW2. The priority is the same as on SW1, only the MAC
address (0019.569d.5700) is different.
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- --------
--------------------------------
Fa0/14 Altn BLK 19 128.16 P2p
Fa0/16 Root FWD 19 128.18 P2p
This part looks interesting; there are two things we see here:
Interface fa0/14 is an alternate port and in (BLK) blocking mode.
Interface fa0/16 is a root port and in (FWD) forwarding mode.
Last but not least let’s check SW3:
SW3#show spanning-tree
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 000f.34ca.1000
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000f.34ca.1000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
90 | P a g e
---------------- ---- --- --------- --------
--------------------------------
Fa0/14 Desg FWD 19 128.14 P2p
Fa0/16 Desg FWD 19 128.16 P2p
Let’s break down what we have here:
Root ID Priority 32769
Address 000f.34ca.1000
This bridge is the root
Bingo… SW3 is the root bridge in this network. We already knew that because SW1 and
SW2 are both non-root, but this is how we verify it by looking at SW3.
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000f.34ca.1000
We can also see the MAC address of SW3.
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Fa0/14 Desg FWD 19 128.14 P2p
Fa0/16 Desg FWD 19 128.16 P2p
Both interfaces on SW3 are designated ports and in (FWD) forwarding mode.
You have now seen what the spanning-tree topology looks like. Why was SW3 chosen
as the root bridge? We’ll have to verify the bridge ID for the answer:
SW1#show spanning-tree | begin Bridge ID
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0011.bb0b.3600
SW2#show spanning-tree | begin Bridge ID
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0019.569d.5700
SW3#show spanning-tree | begin Bridge ID
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000f.34ca.1000
The priority is the same on all switches (32768) so we have to look at the MAC
addresses:
SW1: 0011.bb0b.3600
SW2: 0019.569d.5700
91 | P a g e
SW3: 000f.34ca.1000
SW3 has the lowest MAC address so that’s why it became root bridge. Why was the
fa0/14 interface on SW2 blocked and not the fa0/14 interface on SW1? Once again we
have to look at the bridge identifier. The priority is 32768 on both switches so we have to
compare the MAC address:
SW1: 0011.bb0b.3600
SW2: 0019.569d.5700
SW1 has a lower MAC address and thus a better bridge identifier. That’s why SW2 lost
this battle and has to shut down its fa0/14 interface.
That’s it! You have now learned how spanning-tree works and how you can check the
spanning-tree topology on your Cisco switches.
Spanning-Tree Cost Calculation
Non-root bridges need to find the shortest path to the root bridge. What will happen if
we have a mix of different interface types like Ethernet, FastEthernet and Gigabit? Let’s
find out!
Here’s the topology I will use to explain the spanning-tree cost calculation:
In the picture above we have a larger network with multiple switches. You can also see
that there are different interface types, we have Ethernet (10 Mbit), FastEthernet
(100Mbit) and Gigabit (1000Mbit). SW1 on top is the root bridge so all other switches are
non-root and need to find the shortest path to the root bridge.
Bandwidth Cost
10 Mbit 100
100 Mbit 19
92 | P a g e
1000 Mbit 4
Spanning-tree uses cost to determine the shortest path to the root bridge. The slower
the interface, the higher the cost is. The path with the lowest cost will be used to reach
the root bridge.
Here’s where you can find the cost value:
In the BPDU you can see a field called root path cost. This is where each switch will
insert the cost of its shortest path to the root bridge. Once the switches found out
which switch is declared as root bridge, they will look for the shortest path to get
there. BPDUs will flow from the root bridge downwards to all switches.
If you studied CCNA or CCNP ROUTE, then this story about spanning-tree cost might
sound familiar. OSPF (Open Shortest Path First) also uses cost to calculate the shortest
path to its destination. Both spanning-tree and OSPF use cost to find the shortest path
but there is one big difference. OSPF builds a topology database (LSDB) so all routers
know exactly what the network looks like. Spanning-tree is “dumb”…switches have no
idea what the topology looks like. BPDUs flow from the root bridge downwards to all
switches, switches will make a decision based on the BPDUs that they receive!
Here’s an example of the different spanning-tree costs for our topology:
SW2 will use the direct link to SW1 as its root port since this is a 100 Mbit interface and
has a cost of 19. It will forward BPDUs towards SW4; in the root path cost field of the
BPDU you will find a cost of 19. SW3 is also receiving BPDUs from SW1 so it’s possible
that at this moment it selects its 10 Mbit interface as the root port. Let’s continue…
93 | P a g e
This picture needs some more explanation so let me break it down:
SW3 receives BPDUs on its 10 Mbit interface (cost 100) and on its 1000 Mbit
interface (cost 4). It will use its 1000 Mbit interface as its root port (shortest path
to the root bridge is 19+19+4=42).
SW3 will forward BPDUs to SW4. The root path cost field will be 100.
SW4 receives a BPDU from SW2 with a root path cost of 19.
SW4 receives a BPDU from SW3 with a root path cost of 100.
The path through SW2 is shorter so this will become the root port for SW4.
SW4 will forward BPDUs towards SW3 and SW5. In the root path cost field of the
BPDU we will find a cost of 38 (its root path cost of 19 + its own interface cost of
19).
SW3 will forward BPDUs towards SW5 and inserts a cost of 42 in the root path
cost field (19 + 19 + 4).
The complete picture will look like this:
94 | P a g e
SW5 receives BPDUs from SW3 and SW4. In the BPDU we will look at the root path
cost field and we’ll see the following information:
BPDU from SW3: cost 42
BPDU from SW4: cost 38
SW5 will add the cost of its own interface towards SW4 so the total cost to reach the root
bridge through SW4 is 38 + 19 (cost of 100 Mbit interface) = 57. The total cost to reach
the root bridge through SW3 is 42 + 100 (10 Mbit interface) = 142. As a result, it will
select the interface towards SW4 as its root port.
Are you following me so far? Keep in mind that switches only make decisions on the
BPDUs that they receive! They have no idea what the topology looks like. The only thing
they do know is on which interface they received the best BPDU. The best BPDU is the
one with the shortest path to the root bridge!
What if the cost is equal?
Take a look at the picture above. SW1 is the root bridge and SW2 is non-root. We have
two links between these switches so that we have redundancy. Redundancy means
loops so spanning-tree is going to block one the interfaces on SW2.
SW2 will receive BPDUs on both interfaces but the root path cost field will be the same!
Which one are we going to block? Fa0/1 or fa0/2? When the cost is equal spanning-tree
will look at the port priority. By default, the port priority is the same for all
interfaces which means that the interface number will be the tie-breaker.
95 | P a g e
The lowest interface number will be chosen so fa0/2 will be blocked here. Of course, port
priority is a value that we can change so we can choose which interface will be blocked,
I’ll show you later how to do this!
Whenever spanning-tree has to make a decision, it uses the following list:
Lowest bridge ID: the switch with the lowest bridge ID becomes the root bridge.
Lowest path cost to root bridge: when the switch receives multiple BPDUs it
will select the interface that has the lowest cost to reach the root bridge as the
root port.
Lowest sender bridge ID: when a switch is connected to two switches that it can
use to reach the root bridge and the cost to reach the root bridge is the same, it
will select the interface connecting to the switch with the lowest bridge ID as the
root port.
Lowest sender port ID: when the switch has two interfaces connecting to the
same switch, and the cost to reach the root bridge is the same it will use the
interface with the lowest number as the root port.
Spanning Tree Port States
If you have played with some Cisco switches before you might have noticed that every
time you plug in a cable the led above the interface was orange and after a while
became green. What is happening at this moment is that spanning tree is determining
the state of the interface.
This is what happens as soon as you plug in a cable:
Listening state: Only a root or designated port will move to the listening state.
The non-designated port will stay in the blocking state. No data transmission
occurs at this state for 15 seconds just to make sure the topology doesn’t change
in the meantime. After the listening state we move to the learning state.
Learning state: At this moment the interface will process Ethernet frames by
looking at the source MAC address to fill the mac-address-table. Ethernet frames
however are not forwarded to the destination. It takes 15 seconds to move to the
next state called the forwarding state.
Forwarding state: This is the final state of the interface and finally the interface
will forward Ethernet frames so that we have data transmission!
When a port is not a designated or root port it will be in blocking mode.
This means it takes 30 seconds in total to move from listening to forwarding…that’s not
really fast right? This will happen on all interfaces on the switch.
When an interface is in blocking mode and the topology changes, it’s possible that an
interface that is currently in blocking mode has to move to the forwarding state. When
96 | P a g e
this is the case, the blocking mode will last for 20 seconds before it moves to the
listening state. This means that it takes 20 (blocking) + 15 (listening) + 15 (learning) = 50
seconds before the interface is in the forwarding state.
30 seconds is a long time, right? Any modern PC with a SSD drive boots faster than
that. Here’s an overview of the different port states:
State Forward Frames Learn MAC Addresses Duration
Blocking No No 20 seconds
Listening No No 15 seconds
Learning No Yes 15 seconds
Forwarding Yes Yes –
So, what does this look like on an actual Cisco switch? Let me show you an example of
an interface that is connected to a router. I just unplugged and plugged the cable (or do
a” shut” and “no shut”) and the first time we run the show command it looks like this:
SW1#show spanning-tree vlan
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0019.569d.5700
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0019.569d.5700
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg LIS 19 128.4 P2p
You can see that the role of the port is designated, and the status is listening. Keep
refreshing this show command and after ~ 15 seconds it looks like this:
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0019.569d.5700
97 | P a g e
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0019.569d.5700
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg LRN 19 128.4 P2p
It has moved to the learning state and after another ~ 15 seconds it looks like this:
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0019.569d.5700
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0019.569d.5700
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.4 P2p
Very nice, you just witnessed an interface moving through the different spanning tree
port states. A better method to see the changes is by enabling a debug:
SW1#debug spanning-tree events
Spanning Tree event debugging is on
When we disable and enable the interface again you can see it moving through the
spanning tree port states in real-time:
SW1#
00:14:57: STP: VLAN0001 Fa0/1 -> listening
00:15:12: STP: VLAN0001 Fa0/1 -> learning
00:15:27: STP: VLAN0001 Fa0/1 -> forwarding
STP Topology Change Notification (TCN)
98 | P a g e
How does spanning-tree deal with topology changes? This is a topic that isn’t (heavily)
tested on the CCNP SWITCH exam but it’s very important to understand if you deal with
a network with a lot of switches.
Let me show you an example so I can explain a couple of things:
Let’s take a look at the picture above. We have two computers because I need
something to fill the MAC address tables of these switches. All switches have the default
configuration.
SW3(config)#spanning-tree vlan 1 priority 4096
SW2(config)#interface fa0/19
SW2(config-if)#spanning-tree cost 50
I want SW3 to be the root bridge and the fa0/19 interface of SW2 should be blocked. I’ll
show you why in a minute. Let’s see what the state is of all these interfaces:
SW1#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 19 128.16 P2p
Fa0/16 Root FWD 19 128.18 P2p
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/2 Desg FWD 19 128.4 P2p
Fa0/14 Root FWD 19 128.16 P2p
Fa0/19 Altn BLK 50 128.21 P2p
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/13 Desg FWD 19 128.13 P2p
Fa0/19 Desg FWD 19 128.19 P2p
99 | P a g e
SW4#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/4 Desg FWD 19 128.4 P2p
Fa0/16 Desg FWD 19 128.16 P2p
Fa0/19 Root FWD 19 128.19 P2p
So here we have all the different interfaces, time to draw a nice picture!
Traffic between H1 and H2 will flow from SW2 to SW1, SW3 and then towards SW4.
Interface fa0/19 on SW2 has been blocked.
Let’s generate some traffic so the switches learn the MAC addresses of the computers:
C:Documents and SettingsH1>ping 192.168.1.2
Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
A simple ping will generate some frames and the switches will learn the MAC addresses.
In my case these are the MAC addresses for the computers:
H1: 000c.2928.5c6c
H2: 000c.29e2.03ba
SW1#show mac address-table dynamic
Mac Address Table
100 | P a g e
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/14
1 000c.29e2.03ba DYNAMIC Fa0/16
SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/2
1 000c.29e2.03ba DYNAMIC Fa0/14
SW3#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/13
1 000c.29e2.03ba DYNAMIC Fa0/19
SW4#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/19
1 000c.29e2.03ba DYNAMIC Fa0/4
We can confirm the traffic path by looking at the MAC address table. I like to use
the show mac address-table dynamic command, so we don’t have to browse through
a list of static MAC addresses.
Do you have any idea how long a switch will store a MAC address?
SW1#show mac address-table aging-time
Global Aging Time: 300
If we look at one of the switches, we can check the default aging time of the MAC
address table. As you can see this is 300 seconds (5 minutes by default). If a host has
been silent for 5 minutes its MAC address will be removed from the table.
Why do we care about aging time? I’ll show you why!
C:Documents and SettingsH1>ping 192.168.1.2 -t
First, I’m going to get some traffic going from H1 to H2. By using ping –t it will run
forever.
The next step will be to unplug one of the cables:
101 | P a g e
Assume the link between SW1 and SW3 fails. H1 and H2 will be unable to communicate
with each other until the fa0/19 interface of SW2 goes into forwarding.
It will take a maximum of 50 seconds for SW2 to move the fa0/19 interface from blocking
to listening, learning and finally the forwarding state.
Meanwhile SW2 still has the MAC address of H2 in its MAC address table and will keep
forwarding it to SW1 where it will be dropped. It will be impossible for our computers to
communicate with each other for 300 seconds until the MAC address tables age out.
“Sending Ethernet frames to a place where no frame has gone before doesn’t sound like
a good idea if you want to keep your users happy…”
The idea of MAC address tables that age out after 300 seconds works perfectly fine in a
stable network but not when the topology changes. Of course, there’s a solution to every
problem and that’s why spanning-tree has a topology change mechanism.
When a switch detects a change in the network (interface going down or into forwarding
state) it will advertise this event to the whole switched network.
102 | P a g e
When the switches receive this message, they will reduce the aging time of the MAC
address table from 300 seconds to 15 seconds (this is the forward delay timer). This
message is called the TCN (Topology Change Notification).
To take a closer look at the TCN we’ll have to do some debugging…
SW1#debug spanning-tree events
Spanning Tree event debugging is on
SW2#debug spanning-tree events
Spanning Tree event debugging is on
SW3#debug spanning-tree events
Spanning Tree event debugging is on
SW4#debug spanning-tree events
Spanning Tree event debugging is on
I’m going to enable debug spanning-tree events on all switches so you can see this
process in action.
Now we will shut the Interface fa0/16 on SW1 to simulate a link failure:
SW1(config)#interface fa0/16
SW1(config-if)#shutdown
Here’s what you’ll see:
SW1#STP: VLAN0001 sent Topology Change Notice on Fa0/14
You will see quite some debug information but somewhere along the lines you’ll see that
SW1 is generating a topology change notification and sends it on its fa0/14 interface to
SW2. Here’s what you see on SW2:
SW2#STP: VLAN0001 Topology Change rcvd on Fa0/14
SW2 will throw quite some debug stuff in your face but this is what I was looking for. You
can see that it received the topology change notification from SW1. Upon arrival of this
topology change notification SW2 will age out its MAC address table in 15 seconds.
What will SW2 do with this information? Look below:
SW2#STP: VLAN0001 new root port Fa0/19, cost 69
SW2#STP: VLAN0001 Fa0/19 -> listening
SW2#STP: VLAN0001 Topology Change rcvd on Fa0/14
SW2#STP: VLAN0001 sent Topology Change Notice on Fa0/19
SW2#STP: VLAN0001 Fa0/19 -> learning
103 | P a g e
SW2#STP: VLAN0001 sent Topology Change Notice on Fa0/19
SW2#STP: VLAN0001 Fa0/19 -> forwarding
SW2 decides that fa0/19 is now the new root port and you can see the transition from
listening to learning and forwarding mode. It’s also sending a topology change
notification towards SW4.
SW3#STP: VLAN0001 Topology Change rcvd on Fa0/19
SW3 receives a topology change notification on its fa0/19 interface and will reduce its
age out timer of the MAC address table to 15 seconds.
SW4#STP: VLAN0001 Topology Change rcvd on Fa0/16
SW4#STP: VLAN0001 sent Topology Change Notice on Fa0/19
Here we see that SW4 receives the topology change notification from SW2 and as a
result it will reduce its age out timer of the MAC address table to 15 seconds. It’s also
sending a topology change notification to SW3.
All switches received the topology change notification and set their age out timer to 15
seconds. SW2 doesn’t receive any Ethernet Frames with the MAC address of H2 as the
source on its fa0/14 interface and will remove this entry from the MAC address table.
Meanwhile the fa0/19 interface on SW2 changed from blocking to listening, learning and
forwarding state (50 seconds total). SW2 will now learn the MAC address of H2 on its
fa0/19 interface and life is good!
Of course, the same thing will happen for the MAC address of H1 on SW4.
104 | P a g e
Are you following me so far? To keep a long story short…we need the topology change
notification to reduce the MAC address table aging timer from 300 seconds to 15
seconds to prevent blackholing traffic in a situation like I just explained to you.
So which switches will send and forward the topology change notifications? In our
previous debug you saw a couple of messages but where do we send them and why? Is
it flooded to all switches? Let’s check it out!
In a normal situation a non-root switch will receive BPDUs on its root port but will never
send any BPDUs to the root bridge. When a non-root switch detects a topology change it
will generate a topology change notification and send it on its root port towards the root
bridge.
When a switch receives the topology change notification it will send a (TCA) topology
change acknowledgement on its designated port towards the downstream switch. It will
create a topology change notification itself and send it on its root port as well…we will
work our way up the tree until we reach the root bridge.
What kind of message is used for the TCN? Take a look at this BPDU:
105 | P a g e
You can see it has a field called BPDU type. This value will change to indicate it’s a
topology change notification.
Once the topology change notification reaches the root bridge it will set the TC (topology
change) bit in the BPDUs it will send.
These BPDUs will be forwarded to all the other switches in our network so they can
reduce their aging time of the MAC address table. Switches will receive these messages
on both forwarding and blocked ports.
The root bridge will send BPDUs and it will set the flag field to represent the topology
change.
That’s all there is to it. This is how spanning-tree deals with topology changes in our
network. There is one more thing I want to you show you about this mechanism. Take a
look at the picture below:
106 | P a g e
As you can see H1 is connected to SW2 on its fa0/2 interface. Let’s see what happens
when this interface goes down.
SW2#show spanning-tree interface fa0/2
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg FWD 19 128.4 P2p
We can see that the fa0/2 interface on SW2 is designated and forwarding. Let’s enable a
debug and shut this interface:
SW2#debug spanning-tree events
Spanning Tree event debugging is on
SW2(config)#interface f0/2
SW2(config-if)#shutdown
This is what happens on SW2:
SW2 STP: VLAN0001 sent Topology Change Notice on Fa0/14
Right after shutting down the fa0/2 SW2 generates a topology change notification and
sends it away on its root port.
Let’s bring it up again:
SW2(config)#interface f0/2
SW2(config-if)#no shutdown
This is what you’ll see:
107 | P a g e
SW2# STP: VLAN0001 Fa0/2 -> listening
SW2# %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to up
SW2# %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, SW2# changed
state to up
SW2# STP: VLAN0001 Fa0/2 -> learning
SW2# STP: VLAN0001 sent Topology Change Notice on Fa0/14
SW2# STP: VLAN0001 Fa0/2 -> forwarding
Once we bring the interface up you can see it goes through the listening and learning
state and ends in the forwarding state. The switch generates another topology change
notification and sends it on the root port.
What kind of issues could this cause? Imagine we have a network with a LOT of hosts.
Each time an interface goes up or down a topology change notification will be generated
and ALL switches will set their aging time to 15 seconds. A host will trigger a topology
change and if you have a lot of hosts it’s possible that you end up with a network that is
in a constant state of “topology changes”.
Here’s a situation that could occur:
In the picture above I have a server sending a backup to a LAN backup device. This
means we’ll probably have a lot of unicast traffic from the server to the LAN backup
device.
Whenever an interface goes down it will generate a topology change notification and as
a result all switches will reduce their aging time of the MAC address table to 15 seconds.
All the MAC addresses of the devices will be flushed from the MAC address table.
The switches will quickly re-learn the MAC address of the server since its actively
sending traffic to the LAN Backup device. If this LAN Backup device is just silently
receiving traffic and not sending any traffic itself then there’s no way for the switches to
re-learn its MAC address.
108 | P a g e
What happens to unknown MAC unicast traffic? That’s right…it’s flooded on all
interfaces except the one where it originated from. As a result, this network will be
burdened with traffic until our LAN Backup device sends an Ethernet Frame and the
switches re-learn its MAC address.
How can we deal with this drama scenario?
Portfast to the rescue! Portfast is a Cisco proprietary solution to deal with topology
changes. It does two things for us:
Interfaces with portfast enabled that come up will go to forwarding mode
immediately. It will skip the listening and learning state.
A switch will never generate a topology change notification for an interface that
has portfast enabled.
It’s a good idea to enable portfast on interfaces that are connected to hosts because
these interfaces are likely to go up and down all the time. Don’t enable portfast on an
interface to another hub or switch.
Spanning-Tree Reconvergence
Most students are familiar with the basics of (classic) spanning-tree: how a root bridge is
elected, how the switches decide what interfaces become designated, non-designated,
root ports, etc.
Once the topology has converged, it doesn’t stop. Every time a switch receives a BPDU,
it has to make decisions. When the topology remains the same then the switch will keep
making the same decisions over and over again.
Things become interesting when we do have a change in the topology. How does
spanning-tree adapt to changes in the network?
In this lesson, we’ll take a look at what happens behind the scenes when the topology
changes. I’ll show you the different BPDUs and the decisions that each switch will make.
1. Converged Topology
To demonstrate this, I will use the following topology:
109 | P a g e
Above we have five switches. SW1 is the root bridge. Let’s check the current status of all
interfaces:
SW1#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
SW4#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
SW5#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Altn BLK 4 128.3 P2p
110 | P a g e
Let’s create a simple diagram that has all the port statuses:
Before we start messing around with topology changes. Let’s take a look at the different
BPDUs that we see on the network.
To make sense out of the different BPDUs, let me give you an overview of all MAC
addresses that we will encounter:
111 | P a g e
The MAC addresses in red are the MAC addresses that are used as the bridge
identifiers. Spanning-tree will select a MAC address of one of your (lowest) interface
numbers. In my case, those were the GigabitEthernet 0/0 interfaces that I am not using
in this topology. The MAC addresses in black are those of the interfaces.
Let’s start with the BPDU that our root bridge (SW1) creates:
Above we see the BPDU that SW1 sends towards SW2. You can see the bridge
identifier with the MAC address of SW1. I set the bridge priority to 0. Also, we can see
the message age is 0. This value determines how far you are away from the root bridge.
Each non-root bridge will increase this value by 1.
The message age is used to determine when a BPDU expires. You take the max age
value (20) – message age (0) = 20 seconds. Switches further away from the root bridge
will expire their BPDUs sooner.
Here’s the same BPDU but it’s sent towards SW3:
112 | P a g e
The contents of this BPDU are the same except for the source address.
Above you can see the BPDU from SW1, the message age has been increased by 1.
This means that this BPDU will expire in 20 (max age) – 1 (message age) = 19 seconds.
Here’s the BPDU that SW3 relays to SW5:
113 | P a g e
The information in the BPDU is similar.
Between SW4 and SW5, only SW4 is forwarding BPDUs since the GigabitEthernet0/2
interface of SW5 is currently blocked. Here’s what the BPDU looks like:
114 | P a g e
Our switches will keep flooding the BPDUs that you have seen above, as long as the
topology remains the same. Time to stir up the hornet’s nest…
2. Reconvergence
We are going to shut one of the interfaces of SW1 so that the spanning-tree topology
changes. Some of our switches will lose their root ports. If we want to see everything in
action, we’ll have to enable a debug:
SW1, SW2, SW3, SW4 & SW5
#debug spanning-tree events
Spanning Tree event debugging is on
2.1. Shutting GigabitEthernet0/1 on SW1
We will start by shutting the GigabitEthernet0/1 interface on SW1:
SW1(config)#interface GigabitEthernet 0/1
SW1(config-if)#shutdown
All of our switches will produce some debug info, let’s look at them one-by-one. We start
with SW1:
SW1#
02:50:32: STP: VLAN0001 we are the spanning tree root
02:50:32: STP[1]: Generating TC trap for port GigabitEthernet0/1
02:50:52: STP: VLAN0001 Topology Change rcvd on Gi0/2
02:50:52: STP: VLAN0001 Topology Change rcvd on Gi0/2/code>
SW1 is the root bridge and generates a topology change trap, nothing else happens
here. You can see this event occurs at 2:50:32.
Let’s check SW2:
SW2#
02:51:09: STP: VLAN0001 heard root 32769-fa16.3e5d.b4a0 on Gi0/2
02:51:09: STP: VLAN0001 Topology Change rcvd on Gi0/2
02:51:09: STP: VLAN0001 sent Topology Change Notice on Gi0/1
02:51:10: STP: VLAN0001 heard root 32769-fa16.3e5d.b4a0 on Gi0/2
02:51:10: supersedes 32769-fa16.3e95.a9c9
02:51:10: STP: VLAN0001 new root is 32769, fa16.3e5d.b4a0 on port Gi0/2, cost 4
02:51:10: STP: VLAN0001 sent Topology Change Notice on Gi0/2
02:51:11: STP: VLAN0001 heard root 1-fa16.3eca.4096 on Gi0/2
02:51:11: supersedes 32769-fa16.3e5d.b4a0
02:51:11: STP: VLAN0001 new root is 1, fa16.3eca.4096 on port Gi0/2, cost 16
115 | P a g e
SW2 is no longer receiving BPDUs from SW1 so it has to select another root port. You
can see it is receiving a BPDU from SW4 (fa16.3e5d.b4a0) who claims that it is the new
root bridge, superseding SW2 as the root bridge (fa16.3e95.a9c9).
For a short while, SW2 and SW4 are both isolated from receiving BPDUs from SW1
since SW5 is not forwarding any BPDUs on its blocked interface. About a second later,
SW2 does receive the superior BPDU that is originated from SW1 and uses this as the
root port.
The new root port was discovered at 02:51:11 so it took about 39 seconds.
Below you can see the BPDU that SW2 generated when it thought it was the new root
bridge:
And here’s the BPDU from SW4 who claimed to be the new root bridge:
116 | P a g e
Let’s check SW3:
SW3#
02:50:38: STP: VLAN0001 Topology Change rcvd on Gi0/2
02:50:38: STP: VLAN0001 sent Topology Change Notice on Gi0/1
02:51:05: STP: VLAN0001 Topology Change rcvd on Gi0/2
02:51:05: STP: VLAN0001 sent Topology Change Notice on Gi0/1
Nothing much happens on SW3. This makes sense it’s root and designated ports didn’t
change when GigabitEthernet0/1 on SW1 went down.
Let’s check SW4:
SW4#
02:51:16: STP: VLAN0001 heard root 1-fa16.3eca.4096 on Gi0/1
02:51:16: supersedes 32769-fa16.3e5d.b4a0
02:51:16: STP: VLAN0001 new root is 1, fa16.3eca.4096 on port Gi0/1, cost 8
02:51:16: STP: VLAN0001 sent Topology Change Notice on Gi0/1
02:51:17: STP: VLAN0001 Topology Change rcvd on Gi0/1
02:51:17: STP: VLAN0001 heard root 1-fa16.3eca.4096 on Gi0/2
02:51:17: supersedes 32769-fa16.3e5d.b4a0
02:51:17: STP: VLAN0001 new root is 1, fa16.3eca.4096 on port Gi0/2, cost 12
02:51:17: STP: VLAN0001 sent Topology Change Notice on Gi0/2
117 | P a g e
SW4 was temporarily thinking that it was the new root bridge since it doesn’t receive
BPDUs from SW5. Within the same second, SW2 has sent the superior BPDU from
SW1 so for a short while, SW4 reconsiders Gi0/1 as its root port. Once SW5 starts
forwarding BPDUs, SW4 will use this interface as its root port.
Last but not least, here’s SW5:
SW5#
02:50:43: STP: VLAN0001 Gi0/2 -> listening
02:50:45: STP: VLAN0001 Topology Change rcvd on Gi0/2
02:50:45: STP: VLAN0001 sent Topology Change Notice on Gi0/1
02:50:58: STP: VLAN0001 Gi0/2 -> learning
02:51:13: STP[1]: Generating TC trap for port GigabitEthernet0/2
02:51:13: STP: VLAN0001 sent Topology Change Notice on Gi0/1
02:51:13: STP: VLAN0001 Gi0/2 -> forwarding
SW5 is not receiving any superior BPDUs anymore from SW1 on its GigabitEthernet0/2
interface. This causes it to leave blocking mode, entering the listening and learning
state, ending in forwarding mode.
Here’s the BPDU that SW5 forwards to SW4:
For the sake of completeness, here’s an overview with the new interface states:
SW1#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
118 | P a g e
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Desg FWD 4 128.3 P2p
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Root FWD 4 128.3 P2p
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
SW4#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Root FWD 4 128.3 P2p
SW5#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
Our topology now looks like this:
119 | P a g e
2.2. Shutting GigabitEthernet0/2 on SW1
Let’s try something else. We will start again with the topology where both interfaces on
SW1 are in forwarding mode. I’m going to shut the GigabitEthernet 0/2 interface this
time:
SW1(config)#interface GigabitEthernet 0/2
SW1(config-if)#shutdown
Here’s what happens on SW1:
SW1#
03:00:01: STP: VLAN0001 we are the spanning tree root
03:00:01: STP[1]: Generating TC trap for port GigabitEthernet0/2
03:00:20: STP: VLAN0001 Topology Change rcvd on Gi0/1
03:00:50: STP: VLAN0001 Topology Change rcvd on Gi0/1
SW1 is the root bridge, generating a TCP trap.
Let’s check SW2:
SW2#
03:00:40: STP: VLAN0001 Topology Change rcvd on Gi0/2
03:00:40: STP: VLAN0001 sent Topology Change Notice on Gi0/1
03:01:09: STP: VLAN0001 Topology Change rcvd on Gi0/2
03:01:09: STP: VLAN0001 sent Topology Change Notice on Gi0/1
120 | P a g e
Nothing interesting happens on SW2 since its root port remains the same.
Here’s SW3:
SW3#
03:00:05: STP: VLAN0001 heard root 1-fa16.3eca.4096 on Gi0/2
03:00:05: supersedes 32769-fa16.3e65.f2bc
03:00:05: STP: VLAN0001 new root is 1, fa16.3eca.4096 on port Gi0/2, cost 16
03:00:05: STP: VLAN0001 sent Topology Change Notice on Gi0/2
SW3 loses its root port and for a short moment, it sees itself as the root bridge before it
receives the superior BPDU from SW1 on its Gigabit0/2 interface. This becomes its new
root port. Here’s the BPDU when SW3 saw itself as the root bridge:
Let’s check SW4:
SW4#
03:00:47: STP: VLAN0001 Topology Change rcvd on Gi0/2
03:00:47: STP: VLAN0001 sent Topology Change Notice on Gi0/1
03:01:16: STP: VLAN0001 Topology Change rcvd on Gi0/2
03:01:16: STP: VLAN0001 sent Topology Change Notice on Gi0/1
Nothing much happens on SW4. It’s root and designated ports remain the same.
Last but not least, here’s SW5:
121 | P a g e
SW5#
03:00:12: STP: VLAN0001 new root port Gi0/2, cost 12
03:00:12: STP: VLAN0001 Gi0/2 -> listening
03:00:13: STP: VLAN0001 heard root 32769-fa16.3e65.f2bc on Gi0/1
03:00:13: STP: VLAN0001 Topology Change rcvd on Gi0/1
03:00:13: STP: VLAN0001 sent Topology Change Notice on Gi0/2
03:00:27: STP: VLAN0001 Gi0/2 -> learning
03:00:42: STP[1]: Generating TC trap for port GigabitEthernet0/2
03:00:42: STP: VLAN0001 sent Topology Change Notice on Gi0/2
03:00:42: STP: VLAN0001 Gi0/2 -> forwarding
SW5 is no longer receiving BPDUs from SW1 on its GigabitEthernet 0/1 interface so it
loses its root port (GigabitEthernet0/1) and it has to figure out which interface will
become the new root port. Since SW3 temporarily claimed itself as the root bridge, SW5
is receiving this BPDU.
It is also receiving the superior BPDU from SW1 on its GigabitEthernet 0/2 interface so
this interface will move from the blocking state to the listening, learning and forwarding
state. This becomes the new root port.
Here’s an overview with the new port states:
SW1#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.3 P2p
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Desg FWD 4 128.2 P2p
Gi0/1 Root FWD 4 128.3 P2p
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Root FWD 4 128.2 P2p
SW4#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Desg FWD 4 128.2 P2p
Gi0/1 Root FWD 4 128.3 P2p
SW5#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/2 Root FWD 4 128.2 P2p
Gi0/1 Desg FWD 4 128.3 P2p
122 | P a g e
And the topology now looks like this:
And that’s all there is to it.
3. Conclusion
In this lesson, we have seen what happens behind the scenes when spanning-tree has
to reconverge. You have seen the decisions that each switch makes based on the
BPDUs they receive (or don’t receive).
Per VLAN Spanning Tree (PVST)
Since you are reading this, I assume you understand how “classic” spanning-tree works.
If you don’t, it’s best to read my Introduction to spanning-tree first before you continue.
Having said that, let’s start with a nice picture:
123 | P a g e
VLAN 10 is configured on SW1 and SW2.
VLAN 20 is configured on SW1, SW2 and SW3.
Question for you: do we have a loop in VLAN 10? What about VLAN 20?
There’s a big difference between our physical and logical topology. We don’t have a
loop in VLAN 10 because it only runs on the link between SW1 and SW2. We DO have a
loop within VLAN 20 however.
How does spanning-tree deal with this? Simple…we’ll just calculate a different spanning-
tree for each VLAN! The oldest version of spanning-tree is called CST (Common
Spanning-Tree) and is defined in the 802.1D standard. It only calculates a single
spanning-tree for all VLANs.
Another version of spanning-tree is able to calculate a topology for each VLAN. This
version is called PVST (Per VLAN Spanning-Tree) and it’s the default on Cisco
switches.
Beginning from Cisco IOS 15.2(4)E release, the STP default mode is Rapid PVST+
Let’s look at an example where we have three switches and two VLANs. Both VLANs
are available on all switches:
124 | P a g e
Above you can see that we have two root bridges. If we use PVST we can create a
different root bridge for each VLAN if we want. SW1 could be the root bridge for VLAN
10 and SW2 could be the root bridge for VLAN 20. Why would you want to do this?
Here’s an example:
If I would make one switch root bridge for both VLANs then one interface will be blocked
for both VLANs. In my example above SW1 is the root bridge for VLAN 10 and 20 and
as a result the fa0/16 interface on SW3 is blocked for both VLANs. No traffic will be
forwarded on the fa0/16 interface at all. Imagine these were 10 Gigabit interfaces. It
would be a shame if one of those expensive interfaces wasn’t doing anything right?
If I choose another switch as the root bridge for VLAN 20 we will see different results:
125 | P a g e
In my example, I made SW2 the root bridge for VLAN 20. As you can see the fa0/16
interface on SW2 is blocked for VLAN 10 while the fa0/17 interface on SW1 is blocked
for VLAN 20. The advantage of having multiple root bridges is that I can do some load
sharing/balancing.
Cisco Portfast Configuration
Portfast is a Cisco proprietary solution to deal with spanning-tree topology changes. If
you don’t know how spanning-tree reacts to topology changes then I highly recommend
you to read this lesson before you continue reading. It helps to truly understand why we
need portfast.
Portfast does two things for us:
Interfaces with portfast enabled that come up will go to forwarding mode
immediately, the interface will skip the listening and learning state.
A switch will never generate a topology change notification for an interface that
has portfast enabled.
It’s a good idea to enable portfast on interfaces that are connected to hosts because
these interfaces are likely to go up and down all the time. Don’t enable portfast on an
interface to another hub or switch.
Let’s take a look at the difference of an interface with and without portfast. I’ll be using
the following topology for this:
126 | P a g e
I have two switches and one host connected to SW1. The only reason I have two
switches is so SW1 has another switch that it can send topology notification changes to.
Let’s look at the without portfast scenario first…
1. Portfast disabled
To see the interesting stuff, I will enable a debug on SW1:
SW1#debug spanning-tree events
Spanning Tree event debugging is on
Once I plug in the cable to connect the host to SW1 this is what happens:
SW1#
STP: VLAN0001 Fa0/1 -> listening
STP: VLAN0001 Fa0/1 -> learning
STP: VLAN0001 Fa0/1 -> forwarding
This is just normal spanning-tree behavior, it walks through the listening and learning
states and ends up in forwarding.
Each time I unplug the cable, spanning-tree will generate a topology change notification.
There’s a nice command that you can use to check how many have been sent so far:
SW1#show spanning-tree detail
VLAN0001 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 1, address 0019.569d.5700
Configured hello time 2, max age 20, forward delay 15
Current root has priority 32769, address 0011.bb0b.3600
Root port is 26 (FastEthernet0/24), cost of root path is 19
Topology change flag not set, detected flag not set
Number of topology changes 5 last change occurred 00:02:09 ago
from FastEthernet0/1
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
As you can see there have been 5 topology changes so far on VLAN 1. Let’s unplug the
cable to the host to see what happens:
SW1#
STP: VLAN0001 sent Topology Change Notice on Fa0/24
127 | P a g e
Spanning-tree will send a topology change notification on the interface towards SW2 and
the counter will increase:
SW1#show spanning-tree detail | include changes
Number of topology changes 6 last change occurred 00:01:12 ago
In short, everytime we unplug the cable the switch will generate a TCN. Let’s see the
difference when we enable portfast…
2. Portfast enabled
All we have to do is enable portfast on the FastEthernet 0/1 interface that connects our
host:
SW1(config)#interface FastEthernet 0/1
SW1(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet0/1 but will only
have effect when the interface is in a non-trunking mode.
We get a big warning that portfast shouldn’t be used on interfaces that connect to other
switches etc.
There is also a global command “spanning-tree portfast default” that will enable
portfast on all interfaces that are in access mode. The result will be the same, but it
saves you from enabling it on each interface separately.
Let’s connect our host again:
SW1#
STP: VLAN0001 Fa0/1 ->jump to forwarding from blocking
Great, the interface skips the listening and learning state and goes to forwarding
immediately. Also, the switch will no longer generate topology change notifications when
you unplug this cable anymore.
Want to take a look for yourself? Here you will find the final configuration of SW1.
hostname SW1
!
interface FastEthernet0/1
spanning-tree portfast
128 | P a g e
!
end
Spanning-Tree UplinkFast
Uplinkfast is a spanning-tree feature that was created to improve the convergence time.
In this lesson we’ll take a look at how uplinkfast works. Here’s the topology that I will use
to demonstrate it:
Three switches and SW1 is our root bridge. The fa0/16 interface on SW3 has been
blocked. I’m only using VLAN 1 so nothing fancy here…
If we look at SW3 we see that the fa0/16 interface has been blocked and fa0/14 is the
root port. Let’s see what happens with this topology when one of the links fails:
129 | P a g e
When the fa0/14 interface on SW3 fails we’ll have to use fa0/16 to reach the root bridge.
How long does it take for SW3 to make the transition? Let’s find out:
SW3#debug spanning-tree events
Spanning Tree event debugging is on
SW3(config)#interface fa0/14
SW3(config-if)#shutdown
Now we’ll just wait for the magic to happen…
SW3#STP: VLAN0001 new root port Fa0/16, cost 38
SW3#STP: VLAN0001 Fa0/16 -> listening
SW3#STP: VLAN0001 Fa0/16 -> learning
SW3#STP: VLAN0001 Fa0/16 -> forwarding
BPDUs are originated from the root bridge so if we receive BPDUs on an interface the
switch knows it can reach the root bridge on this interface. We have to go through the
listening (15 seconds) and learning state (15 seconds) so it takes 30 seconds to end up
in the forwarding state.
The good thing is that spanning-tree solves the link failure automatically but it also
means that we have a downtime of 30 seconds. If you want you can tune the forward
delay timer to speed up this process down to roughly 14 seconds.
SW3(config)#interface fa0/14
SW3(config-if)#no shutdown
Let’s restore connectivity first.
SW3(config)#spanning-tree uplinkfast
Now I’m going to enable spanning-tree uplinkfast. This is a global command, you can’t
configure it on the interface level.
SW3(config)#interface fa0/14
SW3(config-if)#shutdown
SW3# STP: VLAN0001 new root port Fa0/16, cost 3038
SW3# %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 FastEthernet0/16 moved to
Forwarding (UplinkFast).
Here’s the big difference. When uplinkfast is enabled a non-designated port will go to
forwarding state immediately if the root port fails. Instead of 30 seconds downtime
connectivity is restored immediately.
130 | P a g e
UplinkFast is useful but it will cause a problem with our MAC address tables. In the
picture above I added two computers to our topology. Interface fa0/16 on SW3 is the
non-designated port and fa0/14 is the root port. Take a look at the following topology:
Let me show you the MAC address tables for all switches:
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/14
1 000c.29e2.03ba DYNAMIC Fa0/17
SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/2
1 000c.29e2.03ba DYNAMIC Fa0/14
SW3#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/14
1 000c.29e2.03ba DYNAMIC Fa0/3
Here are the MAC addresses of the computers:
131 | P a g e
H1: 000c.2928.5c6c
H2: 000c.29e2.03ba
When the link between SW1 and SW3 fails, SW3 will use the fa0/16 interface
immediately. However, it will take 15 seconds for the topology change mechanism to
age out the MAC address table!
SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/2
1 000c.29e2.03ba DYNAMIC Fa0/14
Take a look again at the MAC address table for SW2. The MAC address
(000c.29e2.03ba) that I highlighted belongs to H2. When SW2 receives an Ethernet
Frame for H2 it will be forwarded to SW1 and it will be dropped! (Well at least for 15
seconds until the topology change mechanism kicks in…).
Of course, we have a solution to speed this up, here’s what we will do:
132 | P a g e
Once SW3 switches over to use its non-designated port it will create a dummy
multicast frame. The source MAC address of this Ethernet Frame will be all the MAC
addresses that it has in its MAC address table. In my example above this is only the
MAC address of H2. The destination multicast address is a proprietary Cisco MAC
address.
This multicast frame will be flooded to all other switches so they can update their MAC
address tables right away.
Spanning-tree has saved the day again…anything else you need to know? What do you
think will happen if I re-enable the fa0/14 interface on SW3 again (the original root port)?
SW3(config)#interface fa0/14
SW3(config-if)#no shutdown
Let’s bring the interface back up. In my lab it’s not as exciting as in the picture…
133 | P a g e
SW3# STP: VLAN0001 Fa0/14 -> listening
SW3# STP: VLAN0001 Fa0/14: root port delay timer active
SW3# STP: VLAN0001 Fa0/14 -> blocking
SW3# STP: VLAN0001 new root port Fa0/14, cost 3019
SW3# STP: VLAN0001 Fa0/16 -> blocking (uplinkfast)
You can see we don’t immediately switch back to interface fa0/14. There’s no reason to
switch back to this interface ASAP because we have a working root port. Even if we
would switch back to interface fa0/14 right away we’d still have to wait because the
fa0/17 interface on SW1 will have to go through the listening and learning state (which
takes 30 seconds).
Spanning-Tree Backbone Fast
Backbone Fast is used to recover from an indirect link failure. What does that mean?
Let me show you an example of an indirect link failure and how spanning-tree deals with
it:
Take a look at the picture above. SW1 is the root bridge and the fa0/16 interface on
SW3 has been blocked. Suddenly the link between SW1 and SW2 fails. From SW3’s
perspective this is an indirect link failure.
This is what will happen:
1. SW2 will detect this link failure immediately since it’s a directly connected link.
Since it doesn’t receive any BPDUs from the root anymore it assumes it is now
the new root bridge and will send BPDUs towards SW3 claiming to be the new
root.
134 | P a g e
2. SW3 will receive these BPDUs from SW2 but it will realize that this new BPDU
is inferior compared to the old one it has currently stored on its fa0/16 interface
and will ignore this new BPDU. When a switch receives an inferior BPDU it
means that the neighbor switch has lost its connection to the root bridge.
3. After 20 seconds (default timer) the max age timer will expire for the old BPDU on
the fa0/16 interface of SW3. The interface will go from blocking to the listening
state and will send BPDUs towards SW2.
4. SW2 will receive this BPDU from SW3 and discovers that he isn’t the root bridge.
It won’t send BPDUs anymore towards SW3.
5. The fa0/16 interface on SW3 will continue from the listening state (15 seconds) to
the learning state (15 seconds) and ends up in the forwarding state.
Connectivity is now restored but it took 20 seconds for the max age timer to expire, 15
seconds for the listening state and another 15 seconds for the learning state before we
go to the forwarding state. That’s a total of 50 seconds downtime. Let’s take a look at
this situation on our switches:
SW2#debug spanning-tree events
Spanning Tree event debugging is on
SW3#debug spanning-tree events
Spanning Tree event debugging is on
Let’s enable our debugging.
SW1(config)#interface fa0/14
SW1(config-if)#shutdown
I will shut this interface to simulate an indirect link failure.
SW2# STP: VLAN0001 we are the spanning tree root
SW2 believes it is the root bridge.
SW3# STP: VLAN0001 heard root 8193-0019.569d.5700 on Fa0/16
SW3 receives the BPDUs from SW2 who claims to be the root bridge.
SW3# STP: VLAN0001 Fa0/16 -> listening
SW3# STP: VLAN0001 Fa0/16 -> learning
SW3# STP: VLAN0001 Fa0/16 -> forwarding
135 | P a g e
After the max age timer expires (20 seconds) for the old BPDU from SW2 the fa0/16
interface on SW3 will go to the listening and learning state and ends up in forwarding
state.
SW2# STP: VLAN0001 heard root 4097-0011.bb0b.3600 on Fa0/16
SW2# STP: VLAN0001 new root is 4097, 0011.bb0b.3600 on port Fa0/16, cost 38
The identity crisis of SW2 comes to an end. It now hears the BPDUs from the root bridge
through SW3 and understands that it’s not the root bridge.
Without backbone fast, spanning-tree will discard the inferior BPDUs that SW3 receives
on its fa0/16 interface and it will have to wait till the max age timer expires (20 seconds).
If we enable backbone fast it will skip the max age timer so we can save 20 seconds of
time.
SW1(config)#interface fa0/14
SW1(config-if)#no shutdown
Let’s enable the fa0/14 interface on SW1 first.
SW1(config)#spanning-tree backbonefast
SW2(config)#spanning-tree backbonefast
SW3(config)#spanning-tree backbonefast
Let’s enable backbone fast on all switches. This is a global command (spanning-tree
backbonefast).
SW1#debug spanning-tree backbonefast detail
Spanning Tree backbonefast detail debugging is on
SW2#debug spanning-tree events
Spanning Tree event debugging is on
SW3#debug spanning-tree backbonefast detail
Spanning Tree backbonefast detail debugging is on
Use the debug spanning-tree backbonefast detail command to see real-time information
on backbone fast.
SW1(config)#interface fa0/14
SW1(config-if)#shutdown
Let’s simulate the indirect link failure again…
136 | P a g e
SW2# STP: VLAN0001 we are the spanning tree root
SW2 loses its connection to the root bridge and assumes he is now the new root bridge.
Nothing new so far…
SW1# STP FAST: VLAN0001 FastEthernet0/17: sending requested RLQ response PDU
SW1 receives a new packet called a (RLQ) Root Link Query from SW3. As soon as
SW3 receives an inferior BPDU it will send a root link query on its root port and non-
designated ports to check if the root bridge is still available.
SW3# STP FAST: received RLQ response PDU was expected on VLAN0001 FastEthernet0/14
- resp root id 4097-0011.bb0b.3600
SW3 receives a reply to its root link query on the fa0/14 interface to SW1.
SW3# STP FAST: received_rlq_bpdu on VLAN0001 FastEthernet0/16 - making
FastEthernet0/16 a designated port
Because SW3 received a response from the root bridge on its fa0/14 interface it can now
skip the max age timer on its f0/16 interface and the interface goes to the listening and
learning state right away. We effectively save 20 seconds (max age timer).
Take a good look at the last debug output from SW3. It doesn’t say that it received
something on the fa0/16 interface, it means that it received an answer to the root link
query that it did because it received an inferior BPDU on the fa0/16 interface. That’s all
there is to backbone fast, I hope you enjoyed this lesson.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname SW1
!
spanning-tree backbonefast
!
end
hostname SW2
!
spanning-tree backbonefast
!
end
137 | P a g e
hostname SW3
!
spanning-tree backbonefast
!
end
Rapid Spanning-Tree (RSTP)
Nowadays we see more and more routing in our networks. Routing protocols like OSPF
and EIGRP are much faster than spanning-tree when they have to deal with changes in
the network. To keep up with the speed of these routing protocols another flavor of
spanning-tree was created…rapid spanning-tree.
Rapid spanning-tree is not a revolution of the original spanning-tree but an evolution.
Behind the scenes some things have been changed to speed up the process,
configuration-wise it’s the same as what you have seen so far. I will refer to the original
spanning-tree as “classic spanning-tree”.
Let’s dive into rapid spanning-tree and we’ll see what the differences are with the classic
spanning-tree.
Take a look at the picture below:
Remember the port states of spanning-tree? We have a blocking, listening, learning and
forwarding port state. This is the first difference between spanning-tree and rapid
spanning-tree. Rapid spanning-tree only has three port states:
Discarding
Learning
Forwarding
You already know about learning and forwarding but discarding is a new port state.
Basically, it combines the blocking and listening port state. Here’s a nice overview:
Classic Rapid Port active in Learns MAC
Spanning-Tree Spanning-Tree topology? addresses?
138 | P a g e
Blocking Discarding No No
Listening Discarding Yes No
Learning Learning Yes Yes
Forwarding Forwarding Yes Yes
Do you remember all the other port roles that spanning-tree has? Let’s do a little review
and I’ll show you what is different for rapid spanning-tree:
The switch with the best bridge ID (priority + MAC address) becomes the root bridge.
The other switches (non-root) have to find the shortest cost path to the root bridge. This
is the root port. There’s nothing new here, this works exactly the same for rapid
spanning-tree. The next step is to select the designated ports:
139 | P a g e
On each segment there can be only one designated port, or we’ll end up with a loop.
The port will become the designated port if it can send the best BPDU. SW1 as a root
bridge will always have the best ports so all of interfaces will be designated. The fa0/16
interface on SW2 will be the designated port in my example because it has a better
bridge ID than SW3. There’s still nothing new here compared to the classic spanning-
tree. The interfaces that are left will be blocked:
SW3 receives better BPDUs on its fa0/16 interface from SW2 and thus it will be blocked.
This is the alternate port and it’s still the same thing for rapid spanning-tree. Let me
show you a new example with a port state that is new for rapid spanning-tree:
Here is a new port for you, take a look at the fa0/17 interface of SW2. It’s called
a backup port and it’s new for rapid spanning-tree. You are very unlikely to see this port
on a production network though. Between SW2 and SW3 I’ve added a hub. Normally
(without the hub in between) both fa0/16 and fa0/17 would be designated ports.
140 | P a g e
Because of the hub the fa0/16 and fa0/17 interface on SW2 are now in the same
collision domain. Fa0/16 will be elected as the designated port and fa0/17 will become
the backup port for the fa0/16 interface. The reason that SW2 sees the fa0/17 interface
as a backup port is because it receives its own BPDUs on the fa0/16 and fa0/17
interfaces and understands that it has two connections to the same segment. If you
remove the hub the fa0/16 and fa0/17 will both be designated ports just like the classic
spanning-tree.
Something else that is different is the BPDU, take a look:
The BPDU is different for rapid spanning-tree. In the classic spanning-tree the flags field
only had two bits in use:
Topology change.
Topology change acknowledgment.
All bits of the flag field are now used. The role of the port that originates the BPDU will
be added by using the port role field, it has the following options:
Unknown
Alternate / Backup port.
Root port.
Designated port.
This new BPDU is called a version 2 BPDU. Switches running the old version of
spanning-tree will drop this new BPDU version. In case you are wondering…rapid
spanning-tree and the old spanning are compatible! Rapid spanning-tree has a way of
dealing with switches running the older spanning-tree version.
Let’s walk through the other stuff that has been changed:
BPDUs are now sent every hello time. Only the root bridge generated BPDUs in the
classic spanning-tree and those were relayed by the non-root switches if they received it
on their root port. Rapid spanning-tree works differently…all switches generate
BPDUs every two seconds (hello time). This is the default hello time, but you can
change it.
The classic spanning-tree uses a max age timer (20 seconds) for BPDUs before they
are discarded. Rapid spanning-tree works differently! BPDUs are now used as
a keepalive mechanism similar to what routing protocols like OSPF or EIGRP use. If a
switch misses three BPDUs from a neighbor switch it will assume connectivity to this
switch has been lost and it will remove all MAC addresses immediately.
Rapid spanning tree will accept inferior BPDUs. The classic spanning tree ignores
them. Does this ring a bell? This is pretty much the backbone fast feature of classic
spanning-tree.
141 | P a g e
Transition speed (convergence time) is the most important feature of rapid spanning
tree. The classic spanning tree had to walk through the listening and learning state
before it would move an interface to the forwarding state, this took 30 seconds with the
default timers. The classic spanning tree was based on timers.
Rapid spanning doesn’t use timers to decide whether an interface can move to the
forwarding state or not. It will use a negotiation mechanism for this. I’ll show you how
this works in a bit.
Do you remember portfast? If we enable portfast while running the classic spanning tree
it will skip the listening and learning state and put the interface in forwarding state right
away. Besides moving the interface to the forwarding state it will also not generate
topology changes when the interface goes up or down. We still use portfast for rapid
spanning-tree, but it’s now referred to as an edge port.
Rapid spanning tree can only put interfaces in the forwarding state really fast on edge
ports (portfast) or point-to-point interfaces. It will take a look at the link type and
there are only two link types:
Point-to-point (full duplex)
Shared (half duplex)
Normally we are using switches and all our interfaces are configured as full duplex, rapid
spanning tree sees these interfaces as point-to-point. If we introduce a hub to our
network we’ll have half duplex which is seen as a shared interface to rapid spanning-
tree.
Let’s take a close look at the negotiation mechanism that I described earlier:
Let me describe the rapid spanning tree synchronization mechanism by using the picture
above. SW1 on top is the root bridge. SW2, SW3 and SW4 are non-root bridges.
As soon as the link between SW1 and SW2 comes up their interfaces will be in blocking
mode. SW2 will receive a BPDU from SW1 and now a negotiation will take place
called sync:
142 | P a g e
After SW2 received the BPDU from the root bridge it immediately blocks all its non-
edge designated ports. Non-edge ports are the interfaces that connect to other
switches while edge ports are the interfaces that have portfast configured. As soon as
SW2 blocks its non-edge ports the link between SW1 and SW2 will go into forwarding
state. SW2 will now do the following:
SW2 will also perform a sync operation with both SW3 and SW4 so they can quickly
move to the forwarding state.
Are you following me so far? The lesson to learn here is that rapid spanning tree uses
this sync mechanism instead of the “timer-based” mechanism that the classic
spanning tree uses (listening > learning > forwarding). I’m going to show you what this
143 | P a g e
looks like on real switches in a bit. Let’s take a closer look at the sync mechanism, let’s
look at what happens exactly between SW1 and SW2:
At first the interfaces will be blocked until they receive a BPDU from each other. At this
moment SW2 will figure out that SW1 is the root bridge because it has the best BPDU
information. The sync mechanism will start because SW1 will set the proposal bit in the
flag field of the BPDU. When SW2 receives the proposal it has to do something with it:
SW2 will block all its non-edge interfaces and will start the synchronization towards SW3
and SW4, once this is done SW2 will let SW1 know about this:
Once SW2 has its interfaces in sync mode it will let SW1 know about this by sending
an agreement. This agreement is a copy of the proposal BPDU where the proposal bit
has been switched off and the agreement bit is switched on. The fa0/14 interface on
SW2 will now go into forwarding mode. When SW1 receives the agreement here’s what
happens:
144 | P a g e
Once SW1 receives the agreement from SW2 it will put its fa0/14 interface in forwarding
mode immediately.
What about the fa0/16 and fa0/19 interface on SW2?
The exact same sync mechanism will take place now on these interfaces. SW2 will send
a proposal on its fa0/16 and fa0/19 interfaces towards SW3 and SW4. SW3 and SW4
will send an agreement:
145 | P a g e
SW3 and SW4 don’t have any other interfaces so they will send an agreement back to
SW2:
SW2 will place its fa0/16 and fa0/19 interface in forwarding and we are done. This sync
mechanism is just a couple of messages flying back and forth and very fast, it’s much
faster than the timer-based mechanism of the classic spanning tree!
What else is new with rapid spanning tree? There are three more things I want to show
you:
UplinkFast
Topology change mechanism.
Compatibility with classic spanning tree.
146 | P a g e
When you configure the classic spanning tree you have to enable UplinkFast yourself.
Rapid spanning tree uses UpLinkFast by default, you don’t have to configure it yourself.
When a switch loses its root port it will put its alternate port in forwarding immediately.
The difference is that the classic spanning tree needed multicast frames to update the
MAC address tables of all switches.
We don’t need this anymore because the topology change mechanism for rapid
spanning tree is different. So what’s different about the topology change mechanism?
With the classic spanning tree a link failure would trigger a topology change. Using rapid
spanning tree a link failure is not considered as a topology change. Only non-edge
interfaces (leading to other switches) that move to the forwarding state are considered
as a topology change. Once a switch detects a topology change this will happen:
It will start a topology change while timer with a value that is twice the hello
time. This will be done for all non-edge designated and root ports.
It will flush the MAC addresses that are learned on these ports.
As long as the topology change while timer is active it will set the topology
change bit on BPDUs that are sent out these ports. BPDUs will also be sent out
of its root port.
When a neighbor switch receives this BPDU with the topology change bit set this will
happen:
It will clear all its MAC addresses on all interfaces except the one where it
received the BPDU with the topology change on.
It will start a topology change while timer itself and send BPDUs on all designated
ports and the root port, setting the topology change bit.
Instead of sending a topology change all the way up to the root bridge like the classic
spanning tree does, the topology change is now quickly flooded throughout the network.
If you want to know exactly how this topology change mechanism works then take a look
at this lesson.
147 | P a g e
Last but not least, let’s talk about compatibility. The short answer is that rapid spanning
tree and classic spanning tree are compatible. However when a switch running rapid
spanning tree communicates with a switch running classic spanning tree all the Speedy
Gonzales features won’t work!
In the example above I have my three switches. Between SW1 and SW2 we will run
rapid spanning tree. Between SW2 and SW3 we will fall back to the classic spanning
tree.
Seen enough theory? In the next lesson I will show you the configuration and the
debugs of everything that you have learned so far.
Rapid Spanning-Tree Configuration
In a previous lesson I explained the differences between classic and rapid spanning-tree
and how rapid spanning-tree works. If you haven’t seen it before, I would recommend
to look at it first before diving in the configuration.
Having said that, let’s look at the configuration. This is the topology that I will use:
148 | P a g e
This is the topology I’m going to use. SW1 will be the root bridge in my example. First we
have to enable rapid spanning-tree:
SW1(config)#spanning-tree mode rapid-pvst
SW2(config)#spanning-tree mode rapid-pvst
SW3(config)#spanning-tree mode rapid-pvst
That’s it…just one command will enable rapid spanning tree on our switches. The
implementation of rapid spanning tree is rapid-pvst. We are calculating a rapid
spanning tree for each VLAN.
First I want to show you the sync mechanism:
SW1(config)#interface fa0/14
SW1(config-if)#shutdown
SW1(config)#interface f0/17
SW1(config-if)#shutdown
I’m going to shut both interfaces on SW1 to start with.
SW1#debug spanning-tree events
Spanning Tree event debugging is on
SW2#debug spanning-tree events
Spanning Tree event debugging is on
SW3#debug spanning-tree events
149 | P a g e
Spanning Tree event debugging is on
Second step is to enable debug on all the switches.
SW1(config)#interface fa0/14
SW1(config-if)#no shutdown
I’m going to bring the fa0/14 interface back to the land of the living on SW1. Here’s what
we see:
SW1#
setting bridge id (which=3) prio 4097 prio cfg 4096 sysid 1 (on) id
1001.0011.bb0b.3600
RSTP(1): initializing port Fa0/14
RSTP(1): Fa0/14 is now designated
RSTP(1): transmitting a proposal on Fa0/14
The fa0/14 interface on SW1 will be blocked and it’ll send a proposal to SW2.
SW2#
RSTP(1): initializing port Fa0/14
RSTP(1): Fa0/14 is now designated
RSTP(1): transmitting a proposal on Fa0/14
RSTP(1): updt roles, received superior bpdu on Fa0/14
RSTP(1): Fa0/14 is now root port
Apparently SW2 thought it was the root bridge because it says it received a superior
BPDU on its fa0/14 interface. It changes its fa0/14 interface to root port.
SW2# RSTP(1): syncing port Fa0/16
The fa0/16 interface on SW2 will go into sync mode. This is the interface that connects
to SW3.
SW2# RSTP(1): synced Fa0/14
RSTP(1): transmitting an agreement on Fa0/14 as a response to a proposal
SW2 will respond to SW1 its proposal by sending an agreement.
SW1# RSTP(1): received an agreement on Fa0/14
150 | P a g e
%LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to
up
SW1 receives the agreement from SW2 and interface fa0/14 will go into forwarding.
SW2# RSTP(1): transmitting a proposal on Fa0/16
SW2 will send a proposal to SW3.
SW3# RSTP(1): transmitting an agreement on Fa0/16 as a response to a proposal
SW3 will respond to the proposal of SW2 and send an agreement.
SW2# RSTP(1): received an agreement on Fa0/16
%LINK-3-UPDOWN: Interface FastEthernet0/14, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to
up
SW2 receives the agreement from SW3 and the interface will go into forwarding. That’s
all there to is it…a quick number of handshakes and the interfaces will move to
forwarding without the use of any timers. Let’s continue!
SW1(config)#interface fa0/17
SW1(config-if)#no shutdown
I’m going to enable this interface so that connectivity is fully restored. Let’s look at an
overview:
SW1#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Address 0011.bb0b.3600
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address 0011.bb0b.3600
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
151 | P a g e
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 19 128.16 P2p
Fa0/17 Desg FWD 19 128.19 P2p
We can verify that SW1 is the root bridge. This show command also reveals that we are
running rapid spanning tree. Note that the link type is p2p. This is because my
FastEthernet interfaces are in full duplex by default. Let’s run the same command on the
other two switches:
SW2#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Address 0011.bb0b.3600
Cost 19
Port 16 (FastEthernet0/14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 8193 (priority 8192 sys-id-ext 1)
Address 0019.569d.5700
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 19 128.16 P2p
Fa0/16 Desg FWD 19 128.18 P2p
SW3#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Address 0011.bb0b.3600
Cost 19
Port 14 (FastEthernet0/14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 000f.34ca.1000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
152 | P a g e
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 19 128.14 P2p
Fa0/16 Altn BLK 19 128.16 P2p
Here are SW2 and SW3. Nothing new here, it’s the same information as classic
spanning tree. Here’s what the topology looks like now:
Let’s add another link between SW2 and SW3 to see if this influences our topology:
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 19 128.16 P2p
Fa0/16 Desg FWD 19 128.18 P2p
153 | P a g e
Fa0/17 Desg FWD 19 128.19 P2p
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 19 128.14 P2p
Fa0/16 Altn BLK 19 128.16 P2p
Fa0/17 Altn BLK 19 128.17 P2p
Nothing spectacular, we just have another designated port on SW2 and another
alternate port on SW3. Let me add that alternate port to the topology:
So far the topology with rapid spanning-tree looks the same as with classic spanning-
tree. Now let me show you something you haven’t seen before. I will add a hub between
SW2 and SW3:
154 | P a g e
Now take a look again at the interfaces:
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 19 128.5 P2p
Fa0/16 Desg FWD 100 128.3 Shr
Fa0/17 Back BLK 100 128.4 Shr
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
--------- -------- --------------------------------
Fa0/14 Root FWD 19 128.5 P2p
Fa0/16 Altn BLK 100 128.3 Shr
Fa0/17 Altn BLK 100 128.4 Shr
Here’s something new. SW2 has a backup port. Because of the hub in the middle SW2
and SW3 will hear their own BPDUs.
You can also see that the link type is shr (shared). That’s because the hub causes
these switches to switch their interfaces to half duplex. Here’s the topology picture again:
You probably won’t ever see the backup port on a production network since hubs are
scarce now but if you see it, you’ll know why…
BPDUs are sent every two seconds (hello time) and if you want to prove this you can
take a look at a debug:
155 | P a g e
SW2#debug spanning-tree bpdu
You can use the debug spanning-tree bpdu command to view BPDUs are sent or
received.
SW2#
STP: VLAN0001 rx BPDU: config protocol = rstp, packet from FastEthernet0/14 ,
linktype IEEE_SPANNING , enctype 2, encsize 17
STP: enc 01 80 C2 00 00 00 00 11 BB 0B 36 10 00 27 42 42 03
STP: Data
000002023C10010011BB0B36000000000010010011BB0B360080100000140002000F00
STP: VLAN0001 Fa0/14:0000 02 02 3C 10010011BB0B3600 00000000 10010011BB0B3600 8010
0000 1400 0200 0F00
RSTP(1): Fa0/14 repeated msg
RSTP(1): Fa0/14 rcvd info remaining 6
RSTP(1): sending BPDU out Fa0/16
RSTP(1): sending BPDU out Fa0/17
STP: VLAN0001 rx BPDU: config protocol = rstp, packet f
You will see the contents of the BPDU like above. It’s not very useful if you want to see
the content of the BPDU but it does show us that SW2 is receiving BPDUs and sending
them on its interfaces.
If you do want to look at the contents of a BPDU I recommend you to use wireshark. It
shows everything in a nice structured way.
You don’t have to capture a BPDU yourself if you don’t feel like. The wireshark website
has many pre-recorded packet captures.
Let’s get rid of the hub and do something else…I’m going to simulate a link failure
between SW1 and SW3 to see how rapid spanning tree deals with this.
156 | P a g e
SW1(config)#interface fa0/17
SW1(config-if)#shutdown
First I’m going to shut the fa0/17 interface on SW1.
SW3#
RSTP(1): updt rolesroot port Fa0/14 is going down
RSTP(1): Fa0/16 is now root port
SW3 realized something is wrong with the root port almost immediately and will change
the fa0/16 interface from alternate port to root port. This is the equivalent of UplinkFast
for classic spanning-tree, but it’s enabled by default for rapid spanning tree.
SW1(config)#interface fa0/17
SW1(config-if)#no shutdown
Let’s restore connectivity before we continue.
157 | P a g e
Let’s simulate an indirect link failure. The classic spanning-tree has backbone fast and a
similar mechanism is enabled by default for rapid spanning tree.
SW1(config)#interface fa0/14
SW1(config-if)#shutdown
Shutting down this interface will simulate an indirect link failure for SW3.
SW2#
RSTP(1): updt roles, root port Fa0/14 going down
RSTP(1): we become the root bridge
RSTP(1): updt roles, received superior bpdu on Fa0/16
RSTP(1): Fa0/16 is now root port
SW3#
03:41:29: RSTP(1): updt rolessuperior bpdu on Fa0/16 (synced=0)
03:41:29: RSTP(1): Fa0/16 is now designated
SW2 believes it’s the root bridge until it receives a superior BPDU from SW3. This
happens within the blink of an eye.
SW1(config)#interface fa0/14
SW1(config-if)#no shutdown
Let’s get rid of the shutdown command and continue…let’s look at the edge ports:
158 | P a g e
I added H1 and it’s connected to the fa0/2 interface of SW2. Let’s see how rapid
spanning tree deals with interfaces connected to other devices:
SW2(config)#interface fa0/2
SW2(config-if)#no shutdown
RSTP(1): initializing port Fa0/2
RSTP(1): Fa0/2 is now designated
RSTP(1): transmitting a proposal on Fa0/2
%LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to up
RSTP(1): transmitting a proposal on Fa0/2
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2, changed state to
up
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): transmitting a proposal on Fa0/2
RSTP(1): Fa0/2 fdwhile Expired
You see that it sends a bunch of proposals from the sync mechanism towards the
computer. After a while they will expire. The port will end up in forwarding state anyway,
but it takes a while.
SW2(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
159 | P a g e
Use with CAUTION
%Portfast has been configured on FastEthernet0/2 but will only
have effect when the interface is in a non-trunking mode.
You have to tell rapid spanning tree that the interface connecting the computer is an
edge port. The word “edge” makes sense; it’s the border of our spanning tree topology.
Enable portfast and you are ready to go.
SW2(config)#interface fa0/2
SW2(config-if)#shutdown
SW2(config-if)#no shutdown
I’ll bring the interface up and down.
SW2#
RSTP(1): initializing port Fa0/2
RSTP(1): Fa0/2 is now designated
*Mar 1 04:08:32.931: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to
up
The interface will go to forwarding immediately. Our switch knows that this is the edge of
the spanning tree and we don’t have to send proposals to it. The last thing we have to
look at is compatibility…
I’m going to change SW2 to PVST mode. SW1 and SW3 will remain at rapid-PVST:
SW2(config)#spanning-tree mode pvst
Here’s what we see:
SW2(config)#
RSTP(1): updt roles, non-tracked event
setting bridge id (which=3) prio 8193 prio cfg 8192 sysid 1 (on) id
2001.0019.569d.5700
set portid: VLAN0001 Fa0/2: new port id 8004
STP: VLAN0001 Fa0/2 ->jump to forwarding from blocking
set portid: VLAN0001 Fa0/14: new port id 8010
STP: VLAN0001 Fa0/14 -> listening
set portid: VLAN0001 Fa0/16: new port id 8012
STP: VLAN0001 Fa0/16 -> listening^Z
STP: VLAN0001 heard root 4097-0011.bb0b.3600 on Fa0/16 supersedes 8193-
0019.569d.5700
STP: VLAN0001 new root is 4097, 0011.bb0b.3600 on port Fa0/16, cost 38
160 | P a g e
STP: VLAN0001 new root port Fa0/14, cost 19
STP: VLAN0001 Fa0/14 -> learning
STP: VLAN0001 Fa0/16 -> learning
STP: VLAN0001 sent Topology Change Notice on Fa0/14
STP: VLAN0001 Fa0/14 -> forwarding
STP: VLAN0001 Fa0/16 -> forwarding
SW2 will throw some information at you. You can see that it receives BPDUs from the
root bridge and that the interfaces will have to go through the listening and learning
state. When the switches that are talking rapid spanning-tree receive a BPDU from the
classic spanning tree they will generate classic spanning tree BPDUs themselves, so
everything keeps working.
SW1#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 19 128.16 P2p Peer(STP)
Fa0/17 Desg FWD 19 128.19 P2p
SW2#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/2 Desg FWD 19 128.4 P2p Edge
Fa0/14 Root FWD 19 128.16 P2p
Fa0/16 Desg FWD 19 128.18 P2p
SW3#show spanning-tree | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 19 128.14 P2p
Fa0/16 Altn BLK 19 128.16 P2p Peer(STP)
We can verify this by looking at the interfaces again. All switches still agree on the port
states and everything will function as it should be!
That’s all there is about rapid spanning-tree. The configuration is pretty simple, but I
hope the debugs and show commands helped to understand exactly how everything
works.
Multiple Spanning Tree (MST)
By default, Cisco Catalyst Switches run PVST+ or Rapid PVST+ (Per VLAN Spanning
Tree). This means that each VLAN is mapped to a single spanning tree instance. When
you have 20 VLANs, it means there are 20 instances of spanning tree.
Is this a problem? Like always…it depends, let’s take a look at an example:
161 | P a g e
Take a look at the topology above. We have three switches and a lot of VLANs. There’s
199 VLANs in total. If we are running PVST or Rapid PVST this means that we have 199
different calculations for each VLAN. This requires a lot of CPU power and memory.
When SW2 is the root bridge for VLAN 100 – 200 and SW3 for VLAN 201 – 300 our
spanning-tree topologies will look like this:
SW2 is the root bridge for VLAN 100 up to VLAN 200. This means that the fa0/17
interface of SW1 or the fa0/14 interface on SW3 will be blocked. I’ll have 100 spanning
tree calculations, but they all look the same for these VLANs…
The same thing applies for VLAN 201 – 300. SW3 is the root bridge for VLAN 201 up to
300. The fa0/14 interface on SW1 or SW2 will be blocked for all these VLANs.
Two different outcomes but I still have 200 different instances of spanning tree running.
That’s a waste of CPU cycles and memory right?
MST (Multiple Spanning Tree) will solve this issue. Instead of calculating a spanning tree
for each VLAN we can use instances and map VLANS to each instance. For the
network above I could do something like this:
Instance 1: VLAN 100 – 200
Instance 2: VLAN 201 – 300
Sounds logical right? Only two spanning tree calculations (instances) are required for all
these VLANs.
162 | P a g e
MST works with the concept of regions. Switches that are configured to use MST need
to find out if their neighbors are running MST.
When switches have the same attributes they will be in the same region. It’s possible to
have one or more regions and here are the attributes that need to match:
MST configuration name.
MST configuration revision number.
MST instance to VLAN mapping table.
When switches have the same attributes configured they will be in the same region. If
the attributes are not the same the switch is seen as being at the boundary of the region.
It can be connected to another MST region but also talk to a switch running another
version of spanning tree.
The MST configuration name is just something you can make up, it’s used to identify
the MST region. The MST configuration revision number is also something you can
make up and the idea behind this number is that you can change the number whenever
you change your configuration. It doesn’t matter what you pick as long as it’s the same
on all switches within the MST region. VLANs will be mapped to an instance by using
the MST instance to VLAN mapping table. This is something we have to do ourselves.
Within the MST region, we will have one instance of spanning tree that will create a loop-
free topology within the region. When you configure MST there is always one default
instance used to calculate the topology within the region. We call this the IST (Internal
Spanning Tree). By default, Cisco will use instance 0 to run the IST. In case you were
wondering…its rapid spanning tree that we run within the MST.
163 | P a g e
I could create instance 1 for VLAN 100 – 200 and instance 2 for VLAN 201 – 300.
Depending on which switch will become root bridge for each instance a different port
will be blocked. It could look like this:
The switch outside the MST region doesn’t see what the MST region looks like. For
this switch it’s like it’s talking to one big switch or a ‘black box’:
164 | P a g e
If you want to know the details of how MST and PVST+ work together, check out
our MST and PVST+ interoperability lesson. Let’s have some fun with the
configuration.
1. MST Configuration
I will use the following topology:
We’ll start with a single MST region with the following attributes:
MST configuration name: “Networklessons”
MST configuration revision number: 1 (this is just a number that I made up)
MST instance to VLAN mapping table:
o Instance 2: VLAN 10, 20 and 30.
o Instance 3: VLAN 40, 50 and 60.
This is what we will do:
SW1(config)#spanning-tree mode mst
SW2(config)#spanning-tree mode mst
SW3(config)#spanning-tree mode mst
This is how we enable MST on our switches. Let’s look at the default MST instance:
SW1#show spanning-tree mst configuration
Name []
Revision 0 Instances configured 1
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-4094
-------------------------------------------------------------------------------
SW2#show spanning-tree mst configuration
165 | P a g e
Name []
Revision 0 Instances configured 1
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-4094
-------------------------------------------------------------------------------
SW3#show spanning-tree mst configuration
Name []
Revision 0 Instances configured 1
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-4094
-------------------------------------------------------------------------------
We can use the show spanning-tree mst configuration command to see the MST
instances. I haven’t created any additional instances so only instance 0 is available. You
can see that all VLANs are currently mapped to instance 0. Let’s see what else we can
find:
SW1#show spanning-tree mst
##### MST0 vlans mapped: 1-4094
Bridge address 0011.bb0b.3600 priority 32768 (32768 sysid 0)
Root address 000f.34ca.1000 priority 32768 (32768 sysid 0)
port Fa0/17 path cost 0
Regional Root address 000f.34ca.1000 priority 32768 (32768 sysid 0)
internal cost 200000 rem hops 19
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 200000 128.16 P2p
Fa0/17 Root FWD 200000 128.19 P2p
You can also use the show spanning-tree mst command. We can see the VLAN
mapping but also information about the root bridge. Before we can add more instances
we have to do our chores…time to add some VLANs and configure the links between
the switches as trunks:
SW1(config)#interface fa0/14
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
166 | P a g e
SW1(config)#interface fa0/17
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW2(config)#interface fa0/14
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW2(config)#interface fa0/16
SW2(config-if)#switchport trunk encapsulation dot1q
SW2(config-if)#switchport mode trunk
SW3(config)#interface fa0/14
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
SW3(config)#interface fa0/16
SW3(config-if)#switchport trunk encapsulation dot1q
SW3(config-if)#switchport mode trunk
That takes cares of the trunks, and here are the VLANs:
SW1, SW2 & SW3:
(config)#vlan 10
(config-vlan)#vlan 20
(config-vlan)#vlan 30
(config-vlan)#vlan 40
(config-vlan)#vlan 50
(config-vlan)#vlan 60
(config-vlan)#exit
Now we can configure MST and the instances:
SW1(config)#spanning-tree mst configuration
SW1(config-mst)#name Networklessons
SW1(config-mst)#revision 1
SW1(config-mst)#instance 2 vlan 10,20,30
SW1(config-mst)#instance 3 vlan 40,50,60
SW1(config-mst)#exit
SW2(config)#spanning-tree mst configuration
SW2(config-mst)#name Networklessons
SW2(config-mst)#revision 1
SW2(config-mst)#instance 2 vlan 10,20,30
SW2(config-mst)#instance 3 vlan 40,50,60
SW2(config-mst)#exit
SW3(config)#spanning-tree mst configuration
SW3(config-mst)#name Networklessons
167 | P a g e
SW3(config-mst)#revision 1
SW3(config-mst)#instance 2 vlan 10,20,30
SW3(config-mst)#instance 3 vlan 40,50,60
SW3(config-mst)#exit
This is how we configure MST. First you need the spanning-tree mst
configuration command to enter the configuration of MST. We set the name by using
the name command. Don’t forget to set a revision number and map the instances with
the instance command. Let’s verify our work:
SW1#show spanning-tree mst configuration
Name [Networklessons]
Revision 1 Instances configured 3
Instance Vlans mapped
-------- ---------------------------------------------------------------------
0 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
2 10,20,30
3 40,50,60
-------------------------------------------------------------------------------
We can use the show spanning-tree mst configuration command to verify our
configuration. You can see that we now have two instances. The VLANS are mapped to
instance 2 and 3. All the other VLANs are still mapped to instance 0.
So far so good, let’s play some more with MST and change the root bridge:
Within our region I want to make sure that SW1 is the root bridge. We’ll have to change
the priority for the IST (Internal Spanning Tree):
168 | P a g e
SW1(config)#spanning-tree mst 0 priority 4096
This is how I change the priority for MST instance 0.
SW1#show spanning-tree mst
##### MST0 vlans mapped: 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
Bridge address 0011.bb0b.3600 priority 4096 (4096 sysid 0)
Root this switch for the CIST
Here you can see that SW1 is the root bridge for the IST. It says CIST which stands for
Common and Internal Spanning Tree.
Let’s take a look at the interfaces:
SW1#show spanning-tree mst 0 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 200000 128.16 P2p
Fa0/17 Desg FWD 200000 128.19 P2p
SW2#show spanning-tree mst 0 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 200000 128.16 P2p
Fa0/16 Altn BLK 200000 128.18 P2p
SW3#show spanning-tree mst 0 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 200000 128.14 P2p
Fa0/16 Desg FWD 200000 128.16 P2p
Now we know the state of all interfaces. Let’s draw a picture so we know what the IST
looks like:
169 | P a g e
Now I want to make some changes to instance 2 so SW2 will be root bridge:
SW2(config)#spanning-tree mst 2 priority 4096
We’ll change the priority on SW2 for instance 2.
SW2#show spanning-tree mst 2
##### MST2 vlans mapped: 10,20,30
Bridge address 0019.569d.5700 priority 4098 (4096 sysid 2)
Root this switch for MST2
This command proves that SW2 is the root bridge for instance 2. Let’s check the
interfaces:
SW1#show spanning-tree mst 2 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Root FWD 200000 128.16 P2p
Fa0/17 Altn BLK 200000 128.19 P2p
SW2#show spanning-tree mst 2 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 200000 128.16 P2p
Fa0/16 Desg FWD 200000 128.18 P2p
SW3#show spanning-tree mst 2 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
170 | P a g e
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 200000 128.14 P2p
Fa0/16 Root FWD 200000 128.16 P2p
This is what instance 2 looks like. Let’s turn that into a nice picture:
Here’s a fancy picture of instance 2 to show you the port roles. Note that this topology
looks different than the one for instance 0.
Last but not least I’m now going to make some changes for instance 3:
SW3(config)#spanning-tree mst 3 priority 4096
SW3 will become the root bridge for instance 3.
SW3#show spanning-tree mst 3
##### MST3 vlans mapped: 40,50,60
Bridge address 000f.34ca.1000 priority 4099 (4096 sysid 3)
Root this switch for MST3
SW3 is now the root bridge for instance 3. Let’s look at the interfaces:
SW1#show spanning-tree mst 3 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 200000 128.16 P2p
171 | P a g e
Fa0/17 Root FWD 200000 128.19 P2p
SW2#show spanning-tree mst 3 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Altn BLK 200000 128.16 P2p
Fa0/16 Root FWD 200000 128.18 P2p
SW3#show spanning-tree mst 3 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/14 Desg FWD 200000 128.14 P2p
Fa0/16 Desg FWD 200000 128.16 P2p
And we can draw another topology picture:
Let’s compare instance 2 and 3 next to each other:
172 | P a g e
On the left side you see instance 2 and on the right side is instance 3.
By changing the root bridge per instance we end up with different topologies:
Instance 2: fa0/17 on SW1 is blocked for VLAN 10, 20 and 30.
Instance 3: fa0/14 on SW2 is blocked for VLAN 40, 50 and 60.
Is this making sense so far? I sure hope so!
What happens when I add another switch that is running PVST to our topology? Let’s
find out!
SW4(config)#spanning-tree mode pvst
PVST is the default on most Cisco switches but I’m showing it here, so you really know
I’m running PVST.
SW4(config)#interface fa0/16
SW4(config-if)#switchport trunk encapsulation dot1q
SW4(config-if)#switchport mode trunk
SW4(config)#interface fa0/19
SW4(config-if)#switchport trunk encapsulation dot1q
SW4(config-if)#switchport mode trunk
SW4(config)#vlan 10
SW4(config-vlan)#vlan 20
SW4(config-vlan)#vlan 30
SW4(config-vlan)#vlan 40
SW4(config-vlan)#vlan 50
SW4(config-vlan)#vlan 60
SW4(config-vlan)#exit
173 | P a g e
I want to make sure that we have trunk to SW2 and SW3 and that SW4 knows about all
the VLANs. Let’s see what SW4 thinks of all this:
SW4#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 4096
Address 0011.bb0b.3600
Cost 19
Port 19 (FastEthernet0/19)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0009.7c36.2880
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/16 Altn BLK 19 128.16 P2p
Fa0/19 Root FWD 19 128.19 P2p
This is what SW4 sees about VLAN 1. Keep in mind this VLAN was mapped to instance
0. It sees SW1 as the root bridge and you can see which port is in forwarding and
blocking mode.
SW4#show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 4096
Address 0011.bb0b.3600
Cost 19
Port 19 (FastEthernet0/19)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 0009.7c36.2880
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/16 Altn BLK 19 128.16 P2p
Fa0/19 Root FWD 19 128.19 P2p
174 | P a g e
Here’s VLAN 10 which is mapped to instance 2. SW4 sees SW1 as the root bridge for
this VLAN even though we configured SW2 as the root bridge for instance 2. This is
perfectly normal because MST will only advertise BPDUs from the IST to the outside
world. We won’t see any information from instance 2 or instance 3 on SW4.
SW4#show spanning-tree vlan 40
VLAN0040
Spanning tree enabled protocol ieee
Root ID Priority 4096
Address 0011.bb0b.3600
Cost 19
Port 19 (FastEthernet0/19)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32808 (priority 32768 sys-id-ext 40)
Address 0009.7c36.2880
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/16 Altn BLK 19 128.16 P2p
Fa0/19 Root FWD 19 128.19 P2p
VLAN 40 is mapped to instance 3 but you can see that SW4 sees SW1 as the root
bridge. SW4 receives the same BPDU for all VLANS.
MST and PVST+ Interoperability
MST (Multiple Spanning Tree) and PVST+ (Per VLAN Spanning Tree) both offer loop-
free layer two topologies but they each use a different approach:
MST maps multiple VLANs to an instance, reducing the number of spanning-tree
instances.
PVST+ calculates an instance for each spanning-tree instance.
The two versions are compatible but how should the two behave on the link that
connects the two spanning-tree protocols?
PVST+ sends BPDUs for each instance/VLAN so you could let MST process each
BPDU separately with the instance that is configured for the VLAN. MST, however,
doesn’t have an instance for each VLAN so what kind of BPDUs should it send?
This is an issue…it is possible that two VLANs share the same MST instance but use
different root bridges, root ports, and other attributes in the PVST+ domain. Which
information should MST send in its BPDUs? There is no way to create a 1:1 mapping
between the MST and PVST+ information.
Instead, when an MST region is connected to a PVST+ topology, MST is going
to simulate PVST+ with a feature called the PVST simulation mechanism. What it
does, is that the MST region will send PVST+ BPDUs (one for each VLAN) on the
175 | P a g e
interfaces that are connected to PVST+ switches. These BPDUs all carry the same
information and advertise the same root bridge. The interfaces that connect to the
PVST+ topology are called boundary interfaces/ports.
I’m talking about PVST+, but PVRST+ is also supported. However, MST only uses
PVST+ features, so there is no performance difference.
Since PVST+ switches now receive BPDUs for each VLAN from MST carrying the same
information, they will all make the same decisions when selecting a root bridge, root port,
etc.
Where does the information that MST advertises in the simulated PVST+ BPDUs come
from? All MST switches have to agree on the same information, so we use
the information from the IST for this. The root bridge in the MST region that is
elected as the root bridge for the IST, will also be used in the PVST+ BPDUs that
PVST simulation uses.
What about the other way around? From PVST+ to MST?
MST decides the port role (root, designated, non-designated) for the boundary
interface for all VLANs only by looking at the information in the VLAN 1 BPDU.
Deciding the port role on the boundary interface for all VLANs is risky…after all, it means
that we assume that all VLANs use the same root bridge, root ports, etc. We don’t know
if the PVST+ domain agrees on the port role for all VLANs that we select on our MST
boundary interface. There are, however, some simple checks that MST can use to figure
out if PVST+ agrees on the port roles. Let’s take a look at each possible port role.
Designated Port
If MST wants to use the boundary as a designated port. It uses the following check:
MST BPDU from IST must be superior compared to each PVST+ BPDU from every VLAN
that you receive on the boundary interface.
So, MST compares its own IST BPDU to all PVST+ BPDUs (one for each VLAN). If its
own BPDU is superior, it knows that PVST+ agrees on the port role and we can safely
turn the boundary interface into a designated port. If not, we know that PVST+ doesn’t
agree on our port role and we block our boundary interface. The status of the interface
shows up as broken.
Root Port
The boundary interface can become a root port if the VLAN 1 BPDU that it receives is
the best BPDU that it receives on any of its boundary interfaces. This means, that the
root bridge for VLAN 1 is located in the PVST+ domain. When this happens, the
interface will go into the forwarding state for all VLANs. This is a tricky situation. MST
acts as if all VLANs have their root bridge in the PVST+ domain and turns its boundary
interface as the root port for all VLANs, but that might not be the case. To counter this,
MST uses the following check:
PVST+ BPDUs for all VLANs except VLAN 1 must be identical or superior compared to
the PVST+ VLAN 1 BPDU.
176 | P a g e
What this means is that MST listens to all PVST+ BPDUs that it receives on its boundary
interface and checks if those BPDUs are superior compared to the VLAN 1 BPDU from
PVST+. If so, MST can safely turn its boundary interface into a root port. If not, the
switch reports an inconsistency error; the interface will be blocked and shows the broken
state.
One caveat here is that PVST+ uses the system ID extension, which uses the VLAN
number as part of the bridge ID. This makes it impossible to have PVST+ BPDUs from
different VLANs with an identical value. Because of this, PVST+ BPDUs require a
priority that is at least 4096 lower than the PVST+ VLAN 1 BPDU.
Non-designated Port
Last but not least, the boundary interface could be a non-designated port. It becomes a
non-designated port if the boundary interface receives a VLAN 1 PVST+ BPDU that is
superior to its own MST IST BPDU but not good enough to become a root port. In this
case, the boundary interface becomes a non-designated port for all VLANs. MST has to
check if the PVST+ domain also thinks this should be a non-designated port and it can
quickly check this by listening to all PVST+ BPDUs. When the PVST+ BPDUs are
superior to its own BPDU, it can become a non-designated port. Cisco switches don’t do
any additional checks. Even if a superior BPDU was received, it would report a PVST
inconsistency error and the port would go into broken mode, but since it’s blocked
anyway, it doesn’t matter.
It is easiest to configure your network so that the MST region is the root bridge in your
network. If your PVST+ domain has the root bridge, then MST will use the same root
port for all VLANs. If the root bridge is in your MST region, then you change the cost per
VLAN on your PVST+ switches to use different root ports and use a bit of load
balancing.
1. Configuration
Let’s take a look at all of this in action. There are three switches I use:
SW1, SW2, & SW3
(config)#interface range GigabitEthernet 0/1 - 2
177 | P a g e
(config-if-range)#switchport trunk encapsulation dot1q
(config-if-range)#switchport mode trunk
SW1, SW2 & SW3
(config)#vlan 10
(config-vlan)#vlan 20
(config-vlan)#vlan 30
(config-vlan)#vlan 40
(config-vlan)#vlan 50
(config-vlan)#vlan 60
(config-vlan)#exit
We now have a basic configuration that we can use.
1.1. MST Root Bridge
In the first scenario, I’m going to use the MST region as the root bridge. VLAN 10, 20,
and 30 will be mapped to instance 1, VLAN 40, 50, and 60 to instance 2. SW2 is going
to be the root bridge for instance 0 and 1:
SW2(config)#spanning-tree mode mst
SW2(config)#spanning-tree mst configuration
SW2(config-mst)#name REGION1
SW2(config-mst)#instance 1 vlan 10, 20, 30
SW2(config-mst)#instance 2 vlan 40, 50, 60
SW2(config)#spanning-tree mst 0-1 priority 8192
SW3 will become the root bridge for instance 2:
SW3(config)#spanning-tree mode mst
SW3(config)#spanning-tree mst configuration
SW3(config-mst)#name REGION1
SW3(config-mst)#instance 1 vlan 10, 20, 30
SW3(config-mst)#instance 2 vlan 40, 50, 60
SW3(config-mst)#spanning-tree mst 2 priority 8192
SW1 is running rapid spanning-tree with its default priority. Let’s see what happens now
when I try to make SW1 the new root bridge for one VLAN:
SW1(config)#spanning-tree vlan 60 priority 4096
As soon as you do this, this message will show up on SW2 and SW3:
178 | P a g e
SW2#
%SPANTREE-2-PVSTSIM_FAIL: Blocking designated port Gi0/1: Inconsistent inferior
PVST BPDU received on VLAN 60, claiming root 4106:fa16.3ec0.f43a
SW3#
%SPANTREE-2-PVSTSIM_FAIL: Blocking designated port Gi0/1: Inconsistent inferior
PVST BPDU received on VLAN 60, claiming root 4106:fa16.3ec0.f43a
In order for the boundary interface to be a designated port, the MST IST BPDU must be
superior compared to all PVST+ BPDUs which is not the case now. As a result, the
boundary interface is now in the broken state:
SW2#show spanning-tree mst 0
##### MST0 vlans mapped: 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
Bridge address fa16.3e9f.1dac priority 8192 (8192 sysid 0)
Root this switch for the CIST
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg BKN*20000 128.2 Shr Bound(PVST) *PVST_Inc
Gi0/2 Desg FWD 20000 128.3 Shr
SW2#show spanning-tree mst 1
##### MST1 vlans mapped: 10,20,30
Bridge address fa16.3e9f.1dac priority 8193 (8192 sysid 1)
Root this switch for MST1
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg BKN*20000 128.2 Shr Bound(PVST) *PVST_Inc
Gi0/2 Desg FWD 20000 128.3 Shr
SW2#show spanning-tree mst 2
##### MST2 vlans mapped: 40,50,60
Bridge address fa16.3e9f.1dac priority 32770 (32768 sysid 2)
Root address fa16.3eb2.1388 priority 8194 (8192 sysid 2)
port Gi0/2 cost 20000 rem hops 19
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg BKN*20000 128.2 Shr Bound(PVST) *PVST_Inc
Gi0/2 Root FWD 20000 128.3 Shr
179 | P a g e
The GigabitEthernet 0/1 interface goes into the BKN (broken) status for all
instances/VLANs. In the last output, you can see that even though GigabitEthernet 0/1 is
in the broken state, SW2 does recognize SW1 as the root bridge. Let’s increase the
priority of SW1 so that SW2 and SW3 do become the root bridges in this topology.
SW1(config)#spanning-tree vlan 60 priority 32768
This solves our issues with the broken interfaces:
SW2#
%SPANTREE-2-PVSTSIM_OK: PVST Simulation inconsistency cleared on port
GigabitEthernet0/1.
SW3#
%SPANTREE-2-PVSTSIM_OK: PVST Simulation inconsistency cleared on port
GigabitEthernet0/1.
SW1 now sees the MST region as the root bridge. Since all PVST+ BPDUs that SW2
and SW3 receive are inferior compared to the MST IST BPDU, the inconsistency is
cleared.
Everything is working correctly now. Let’s take a look at some of the spanning-tree
outputs. Here’s VLAN 1 that is mapped to instance 0 where SW2 is the root bridge:
SW1#show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address fa16.3e9f.1dac
Cost 4
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address fa16.3ec0.f43a
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 Shr Peer(STP)
Gi0/2 Altn BLK 4 128.3 Shr Peer(STP)
Above we see that GigabitEthernet 0/1 is the root port. Here’s the output of VLAN 10
which is mapped to instance 1 with SW2 as the root bridge:
180 | P a g e
SW1#show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address fa16.3e9f.1dac
Cost 4
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address fa16.3ec0.f43a
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 Shr Peer(STP)
Gi0/2 Altn BLK 4 128.3 Shr Peer(STP)
The output is the same as VLAN 1. Let’s also take a look at VLAN 60 which is mapped
to instance 2 where SW3 is the root bridge:
SW1#show spanning-tree vlan 60
VLAN0040
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address fa16.3e9f.1dac
Cost 4
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32828 (priority 32768 sys-id-ext 60)
Address fa16.3ec0.f43a
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 Shr Peer(STP)
Gi0/2 Altn BLK 4 128.3 Shr Peer(STP)
The output above is interesting to see. As explained earlier, MST maps all VLANs to the
IST, so even VLAN 60 (and 40+50) share the same information, even though SW3 is the
root bridge for these VLANs. SW1 sees SW2 as the root bridge for these VLANs.
181 | P a g e
Having the MST region as the root bridge is a best practice. It’s simple to maintain, and it
allows load balancing. For example, let’s say we want the PVST+ domain to use another
root port for VLAN 60. We can achieve this by playing with the cost:
SW1(config)#interface GigabitEthernet 0/2
SW1(config-if)#spanning-tree vlan 60 cost 1
SW1 now uses GigabitEthernet 0/2 as its root port to reach VLAN 60:
SW1#show spanning-tree vlan 60
VLAN0040
Spanning tree enabled protocol rstp
Root ID Priority 8192
Address fa16.3e9f.1dac
Cost 1
Port 3 (GigabitEthernet0/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32828 (priority 32768 sys-id-ext 60)
Address fa16.3ec0.f43a
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Altn BLK 4 128.2 Shr Peer(STP)
Gi0/2 Root FWD 1 128.3 Shr Peer(STP)
GigabitEthernet 0/2 is now the root port for VLAN 60. All other VLANs still use
GigabitEthernet 0/1 as their root port.
1.2. PVST+ Root Bridge
It is possible to have the root bridge in the PVST+ domain. Let’s give this a try:
SW1(config)#spanning-tree vlan 1 priority 4096
Once I change the priority for VLAN 1 on SW1, SW2 starts complaining:
SW2#
%SPANTREE-2-PVSTSIM_FAIL: Blocking root port Gi0/1: Inconsistent
inferior PVST BPDU received on VLAN 10, claiming root
32778:fa16.3ec0.f43a
182 | P a g e
This is because of the root port check that MST does. To become a root port, all PVST+
BPDUs except for VLAN 1 need to be identical or superior compared to the PVST+
VLAN 1 BPDU. That’s not the case here, since VLAN 10-60 still have a default priority of
32768. Right now, SW2 puts its boundary interface in the broken state:
SW2#show spanning-tree mst 0
##### MST0 vlans mapped: 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
Bridge address fa16.3e9f.1dac priority 8192 (8192 sysid 0)
Root address fa16.3ec0.f43a priority 4097 (4096 sysid 1)
port Gi0/1 path cost 20000
Regional Root this switch
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root BKN*20000 128.2 Shr Bound(PVST) *PVST_Inc
Gi0/2 Desg FWD 20000 128.3 Shr
SW2#show spanning-tree mst 1
##### MST1 vlans mapped: 10,20,30
Bridge address fa16.3e9f.1dac priority 8193 (8192 sysid 1)
Root this switch for MST1
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Mstr BKN*20000 128.2 Shr Bound(PVST) *PVST_Inc
Gi0/2 Desg FWD 20000 128.3 Shr
SW2#show spanning-tree mst 2
##### MST2 vlans mapped: 40,50,60
Bridge address fa16.3e9f.1dac priority 32770 (32768 sysid 2)
Root address fa16.3eb2.1388 priority 8194 (8192 sysid 2)
port Gi0/2 cost 20000 rem hops 19
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Mstr BKN*20000 128.2 Shr Bound(PVST) *PVST_Inc
Gi0/2 Root FWD 20000 128.3 Shr
To fix this, we have to lower the priority on all VLANs of SW1, except for VLAN 1:
SW1(config)#spanning-tree vlan 10,20,30,40,50,60 priority 0
This satisfies the root port check on SW2:
183 | P a g e
SW2#
%SPANTREE-2-PVSTSIM_OK: PVST Simulation inconsistency cleared on port
GigabitEthernet0/1
Things are looking good now:
SW2#show spanning-tree mst 0
##### MST0 vlans mapped: 1-9,11-19,21-29,31-39,41-49,51-59,61-4094
Bridge address fa16.3e9f.1dac priority 8192 (8192 sysid 0)
Root address fa16.3ec0.f43a priority 4097 (4096 sysid 1)
port Gi0/1 path cost 20000
Regional Root this switch
Operational hello time 2 , forward delay 15, max age 20, txholdcount 6
Configured hello time 2 , forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 20000 128.2 Shr Bound(PVST)
Gi0/2 Desg FWD 20000 128.3 Shr
SW2#show spanning-tree mst 1
##### MST1 vlans mapped: 10,20,30
Bridge address fa16.3e9f.1dac priority 8193 (8192 sysid 1)
Root this switch for MST1
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Mstr FWD 20000 128.2 Shr Bound(PVST)
Gi0/2 Desg FWD 20000 128.3 Shr
SW2#show spanning-tree mst 2
##### MST2 vlans mapped: 40,50,60
Bridge address fa16.3e9f.1dac priority 32770 (32768 sysid 2)
Root address fa16.3eb2.1388 priority 8194 (8192 sysid 2)
port Gi0/2 cost 20000 rem hops 19
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi0/1 Mstr FWD 20000 128.2 Shr Bound(PVST)
Gi0/2 Root FWD 20000 128.3 Shr
Above you can see that the boundary interface is now in the forwarding state for all
VLANs.
2. Conclusion
In this lesson, you have learned how MST and PVST+ (or PVRST+) are compatible.
184 | P a g e
MST and PV(R)ST+ are compatible, but it’s not very straightforward since you can’t
convert their information 1:1. To work around this, MST uses PVST+ compatibility mode
and sends a BPDU for each VLAN on its link (boundary interface) to the PVST+ domain.
The information in each BPDU is based on the IST.
MST uses the information from the PVST+ VLAN 1 BPDU to decide the role of the
boundary interface (root, designated or non-designated) for all VLANs. This introduces a
problem since the PVST+ domain might not agree on the port role. To work around this,
MST has a couple of checks:
Designated port:
o MST BPDU from IST must be superior compared to each
PVST+ BPDU from every VLAN
that you receive on the boundary interface.
Root port:
o PVST+ BPDUs for all VLANs except VLAN 1 must be identical or super
ior compared to the PVST+ VLAN 1 BPDU.
o Because of the extended system ID, it’s impossible to have a BPDU with
the same value. This means the priority of all non-VLAN 1 BPDUs has to
be at least 4096 lower than the PVST+ VLAN 1 BPDU.
Spanning-Tree BPDUGuard
Spanning-tree BPDUguard is one of the features that helps you protect your spanning-
tree topology. Let me give you an example:
In my topology above we have a perfectly working spanning tree topology. By default,
spanning-tree will send and receive BPDUs on all interfaces. In our example we have a
computer on the fa0/2 interface of SW2. Someone with curious hostile intentions could
start a tool that generates BPDUs with a superior bridge ID. What’ll happen is that our
185 | P a g e
switches will believe that the root bridge can now be reached through SW2 and we’ll
have a spanning tree re-calculation. Doesn’t sound like a good idea right? Here’s what
could go wrong:
You could even do a man in the middle attack without anyone knowing. Imagine I
connect my computer to two switches. If I become the root bridge all traffic from SW1 or
SW3 towards SW2 will flow through me. I’ll run Wireshark and wait till the magic
happens.
We can use BPDUGuard to prevent this from happening as it will block BPDUs:
BPDUguard will ensure that when we receive a BPDU on an interface that the interface
will go into err-disable mode.
Let’s take a look how to configure this…
1. Configuration
I will use the following topology:
186 | P a g e
To demonstrate BPDUguard I’m going to use two switches. I’ll configure the fa0/16
interface of SW2 so it will go into err-disable mode if it receives a BPDU from SW3.
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree bpduguard enable
This is how you enable it on the interface. Keep in mind normally you will never do this
between switches; you should configure this on the interfaces in access mode that
connect to computers.
SW2#
%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa0/16 with BPDU Guard enabled.
Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Fa0/16, putting Fa0/16 in err-
disable state
: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/16, changed state
to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 1 00:19:32.089: %LINK-3-UPDOWN: Interface FastEthernet0/16, changed state to
down
Uh oh…there goes our interface.
SW2(config-if)#no spanning-tree bpduguard
SW2(config-if)#shutdown
SW2(config-if)#no shutdown
Get rid of BPDUguard and do a shut/no shut to get the interface back up and running.
SW2(config)#spanning-tree portfast bpduguard default
You can also use the spanning-tree portfast bpduguard default command. This will
globally activate BPDUguard on all interfaces that have portfast enabled.
SW2(config)#spanning-tree portfast default
187 | P a g e
Portfast can also be enabled globally for all interfaces running in access mode.
SW2#show spanning-tree summary
Switch is in pvst mode
Root bridge for: none
Extended system ID is enabled
Portfast Default is enabled
PortFast BPDU Guard Default is enabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Here’s a useful command so you can verify your configuration. You can see that portfast
and BPDUGuard have been enabled globally.
Spanning-Tree BPDUFilter
The spanning-tree BPDUfilter works similar to BPDUGuard as it allows you to block
malicious BPDUs. The difference is that BPDUguard will put the interface that it receives
the BPDU on in err-disable mode while BPDUfilter just “filters” it. In this lesson we’ll take
a good look at how BPDUfilter works.
BPDUfilter can be configured globally or on the interface level and there’s a difference:
Global: if you enable BPDUfilter globally then any interface with portfast enabled
will not send or receive any BPDUs. When you receive a BPDU on a portfast
enabled interface then it will lose its portfast status, disables BPDU filtering and
acts as a normal interface.
Interface: if you enable BPDUfilter on the interface it will ignore incoming BPDUs
and it will not send any BPDUs. This is the equivalent of disabling spanning-tree.
You have to be careful when you enable BPDUfilter on interfaces. You can use it on
interfaces in access mode that connect to computers but make sure you never configure
it on interfaces connected to other switches; if you do you might end up with a loop.
Let’s use the following topology to demonstrate the BPDUfilter:
I’m going to use SW2 and SW3 to demonstrate BPDUfilter:
188 | P a g e
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree portfast trunk
SW2(config-if)#spanning-tree bpdufilter enable
It will stop sending BPDUs and it will ignore whatever is received. Let’s enable a debug
to see what it does:
SW2#debug spanning-tree bpdu
You won’t see any exciting messages but if you enable BPDU debugging you’ll notice
that it doesn’t send any BPDUs anymore. If you want, you can also enable BPDU
debugging on SW3 and you’ll see that you won’t receive any from SW2.
SW2(config)#interface fa0/16
SW2(config-if)#no spanning-tree bpdufilter enable
Let’s get rid of the BPDUfilter command on the interface level and enable it globally:
SW2(config)#spanning-tree portfast bpdufilter default
You can also use the global command for BPDUfilter. This will enable BPDUfilter on all
interfaces that have portfast.
That’s all there is to it. Personally, I wouldn’t use this and use BPDUguard instead. If you
don’t expect BPDUs on an interface, then it’s better to get a notification (through err-
disable) then not seeing what is going on…
Spanning-Tree LoopGuard and UDLD
If you ever used fiber cables you might have noticed that there is a different connector to
transmit and receive traffic.
If one of the cables (transmit or receive) fails we’ll have a unidirectional link
failure, and this can cause spanning tree loops. There are two protocols that can take
care of this problem:
LoopGuard
189 | P a g e
UDLD ( Unidirectional Link Detection )
Let’s start by taking a close look at what will happen if we have a unidirectional link
failure:
Imagine the links between the switches are fiber links. In reality there’s a different
connector for transmit and receive. SW3 is receiving BPDUs from SW2 and as a result
the interface has become an alternate port and is in blocking mode.
Now something goes wrong…the transmit connector on SW2 towards SW3 was eaten
by mice failed due to unknown reasons. As a result SW3 is not receiving any BPDUs
from SW2 but it can still send traffic to SW2.
Because SW3 is not receiving anymore BPDUs on its alternate port it will go into
forwarding mode. We now have a one way loop as indicated by the green arrow.
One of the methods we can use to solve our unidirectional link failure is to
configure LoopGuard. When a switch is sending but not receiving BPDUs on the
190 | P a g e
interface, LoopGuard will place the interface in the loop-inconsistent state and block
all traffic:
Let’s take a look what this looks like on actual switches. I will use the same topology:
Let’s enable loopguard:
SW1(config)#spanning-tree loopguard default
SW2(config)#spanning-tree loopguard default
SW3(config)#spanning-tree loopguard default
191 | P a g e
Use the spanning-tree loopguard default command to enable LoopGuard globally. I don’t
have any fiber connectors so I’m unable to create a unidirectional link failure. I can
simulate it however by using BPDUfilter on SW2’s fa0/16 interface. SW3 won’t receive
any BPDUs anymore on its alternate port which will cause it to go into forwarding mode:
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree portfast trunk
SW2(config-if)#spanning-tree bpdufilter enable
Here’s what will happen:
SW3#
*Mar 1 00:17:14.431: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port
FastEthernet0/16 on VLAN0001.
Normally this would cause a loop but luckily, we have LoopGuard configured. You can
see this error message appearing in your console, problem solved!
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname SW1
!
spanning-tree loopguard default
!
end
hostname SW2
!
spanning-tree loopguard default
!
interface FastEthernet0/16
spanning-tree portfast trunk
spanning-tree bpdufilter enable
!
end
hostname SW3
!
spanning-tree loopguard default
!
end
If you want you don’t have to configure LoopGuard globally, you can also do it on the
interface level like this:
192 | P a g e
SW3(config-if)#spanning-tree guard loop
The other protocol we can use to deal with unidirectional link failures is called UDLD
(UniDirectional Link Detection). This protocol is not part of the spanning tree toolkit,
but it does help us to prevent loops.
Simply said UDLD is a layer 2 protocol that works like a keepalive mechanism. You send
hello messages; you receive them, and life is good. As soon as you still send hello
messages but don’t receive them anymore you know something is wrong and we’ll block
the interface.
Let’s use the same topology but configure UDLD this time. Don’t forget to get rid of
loopguard first…
SW1(config)#udld ?
aggressive Enable UDLD protocol in aggressive mode on fiber ports except
where locally configured
enable Enable UDLD protocol on fiber ports except where locally
configured
message Set UDLD message parameters
There are a number of methods how you can configure UDLD. You can do it globally
with the udld command, but this will only activate UDLD for fiber links!
There are two options for UDLD:
Normal (default)
Aggressive
193 | P a g e
When you set UDLD to normal it will mark the port as undetermined, but it won’t shut
the interface when something is wrong. This is only used to “inform” you, but it won’t
stop loops.
Aggressive is a better solution. When it loses connectivity to a neighbor it will send a
UDLD frame out once a second for 8 seconds. If the neighbor does not respond the
interface will be put in err-disable mode.
Let’s use two switches to demonstrate UDLD:
Let’s enable UDLD:
SW2(config)#interface fa0/16
SW2(config-if)#udld port aggressive
SW3(config)#interface fa0/16
SW3(config-if)#udld port aggressive
We’ll use SW2 and SW3 to demonstrate UDLD. I’ll use aggressive mode so we can see
that the interface goes down when something is wrong. To see what is going on in real
time we’ll use a debug:
SW2#debug udld events
UDLD events debugging is on
SW3#
New_entry = 34422DC (Fa0/16)
Found an entry from same device (Fa0/16)
Cached entries = 2 (Fa0/16)
Entry (0x242BB9C) deleted: 1 entries cached
Cached entries = 1 (Fa0/16)
Checking if multiple neighbors (Fa0/16)
Single neighbor detected (Fa0/16)
Checking if link is bidirectional (Fa0/16)
Found my own ID pair in 2way conn list (Fa0/16)
Now the tricky part will be to simulate a unidirectional link failure. LoopGuard was easier
because it was based on BPDUs. UDLD runs its own layer 2 protocol by using the
proprietary MAC address 0100.0ccc.cccc. We can create a filter to block the UDLD
traffic:
SW3(config)#mac access-list extended UDLD-FILTER
194 | P a g e
SW3(config-ext-macl)#deny any host 0100.0ccc.cccc
SW3(config-ext-macl)#permit any any
SW3(config-ext-macl)#exit
SW3(config)#interface fa0/16
SW3(config-if)#mac access-group UDLD-FILTER in
This is a creative way to cause trouble. By filtering the MAC address of UDLD on one
side it will think that there is an unidirectional link failure! Here’s what you will see:
SW2#
UDLD FSM updated port, bi-flag udld_empty_echo, phase udld_detection (Fa0/16)
timeout timer = 0 (Fa0/16)
Phase set to EXT. (Fa0/16)
New_entry = 370CED0 (Fa0/16)
Found an entry from same device (Fa0/16)
Cached entries = 2 (Fa0/16)
Entry (0x3792BE0) deleted: 1 entries cached
Cached entries = 1 (Fa0/16)
Zero IDs in 2way conn list (Fa0/16)
Zero IDs in 2way conn list (Fa0/16)
UDLD disabled port, packet received in extended detection (Fa0/16)
%UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Fa0/16, unidirectional link
detected
%PM-4-ERR_DISABLE: udld error detected on Fa0/16, putting Fa0/16 in err-disable
state
You’ll see a lot of debug information flying by, but the end result will be that the port is
now in err-disable state. Here’s a show command you can use to check it:
SW2#show udld fastEthernet 0/16
Interface Fa0/16
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Unidirectional
Current operational state: Disabled port
You can verify it by using the show udld command.
LoopGuard and UDLD both solve the same problem: Unidirectional Link failures. They
have some overlap but there are a number of differences, here’s an overview:
LoopGuard UDLD
Configuration Global / per port Global (for
195 | P a g e
fiber) / per port
Per VLAN? Yes No, per port
Yes – requires
Autorecovery Yes err-disable
timeout.
Protection against STP Yes – need to enable Yes – need to
failures because of it on all root and enable it on all
unidirectional link failures alternate ports interfaces
Protection against STP
failures because no BPDUs Yes No
are sent
Protection against
No Yes
miswiring
Spanning-Tree RootGuard
RootGuard will make sure you don’t accept a certain switch as a root bridge. BPDUs are
sent and processed normally but if a switch suddenly sends a BPDU with a superior
bridge ID you won’t accept it as the root bridge. Normally SW2 would become the root
bridge because it has the best bridge ID, fortunately we have RootGuard on SW3 so it’s
not going to happen!
Let me demonstrate this with the following topology:
Let me show you the configuration by using SW2 and SW3, first I will make sure that
SW3 is NOT the root bridge:
SW2(config)#spanning-tree vlan 1 priority 4096
Now we’ll enable rootguard on SW2:
196 | P a g e
SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree guard root
%SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/16.
We get a nice notification message that it has been enabled. Let’s enable a debug so we
can see what is going on:
SW2#debug spanning-tree events
Spanning Tree event debugging is on
Now we’ll upset SW2 by changing the priority to the lowest value possible (0) on SW3.
Normally it should now become the root bridge:
SW3(config)#spanning-tree vlan 1 priority 0
Let’s see what SW2 thinks about this:
SW2#
STP: VLAN0001 heard root 1-000f.34ca.1000 on Fa0/16
supersedes 4097-0019.569d.5700
%SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/16 on
VLAN0001.
Here goes…SW2 will not accept SW3 as a root bridge. It will block the interface for this
VLAN. Here’s another useful command to verify this:
SW2#show spanning-tree inconsistentports
Name Interface Inconsistency
-------------------- ------------------------ ------------------
VLAN0001 FastEthernet0/16 Root Inconsistent
Number of inconsistent ports (segments) in the system : 1
It’s telling us that Fastethernet0/16 is inconsistent. Rootguard is a useful command to
enable on your Core or Distribution layer switches so that the underlying switches will
never be elected as a root bridge.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname SW2
!
197 | P a g e
spanning-tree vlan 1 priority 4096
!
interface FastEthernet0/16
spanning-tree guard root
!
end
hostname SW3
!
spanning-tree vlan 1 priority 0
!
end
STP Dispute
STP dispute is a mechanism that checks if the BPDUs that it receives on an
interface match with the port role/state of the interface. This helps to detect
unidirectional link failures and prevent bridging loops. When a designated port
detects a problem, it will keep the port role but changes its state so that all traffic is
dropped until the issue is fixed. Dropping all traffic isn’t nice, but it’s better than the
alternative, a bridging loop.
1. Configuration
Let’s look at an example. I will use the following two switches:
SW1 and SW2 are connected to each other with two links. Here’s the spanning-tree
topology:
SW1#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Address fa16.3e4e.be24
Cost 4
Port 2 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
198 | P a g e
Address fa16.3ef4.43e6
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 4 128.2 P2p
Gi0/2 Altn BLK 4 128.3 P2p
SW2#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Address fa16.3e4e.be24
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address fa16.3e4e.be24
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
As you can see, SW2 is the root bridge, and all interfaces have the correct port state.
Time to stir things up. I’m using Ethernet interfaces so I can’t pull the cable and cause a
unidirectional link failure. What I can do, is create a mac access-list that denies all
spanning-tree traffic. Before I create and activate it, let’s enable debugging on SW1:
SW1#debug spanning-tree events
Spanning Tree event debugging is on
Now let’s create that access-list that filters spanning-tree traffic:
SW2(config)#mac access-list extended NO_STP
SW2(config-ext-macl)#deny any host 0180.c200.0000
SW2(config-ext-macl)#permit any any
And activate it on the inbound interfaces of SW2:
SW2(config)#interface range GigabitEthernet 0/1 - 2
SW2(config-if-range)#mac access-group NO_STP in
199 | P a g e
This prevents SW2 from receiving any BPDUs from SW1. We can verify this by looking
at the access-list:
SW2#show access-lists NO_STP
Extended MAC access list NO_STP
deny any host 0180.c200.0000 (58 matches)
permit any any (21 matches)
What I will do now, is make SW1 the new root bridge. This causes SW1 to change its
interfaces to designated ports. SW2 should select a root and non-designated (alternate)
port:
SW1(config)#spanning-tree vlan 1 priority 0
As soon as I do this, I get the following debug messages:
SW1#
setting bridge id (which=1) prio 1 prio cfg 0 sysid 1 (on) id 0001.fa16.3ef4.43e6
RSTP(1): updt roles, non-tracked event
RSTP(1): we become the root bridge
RSTP(1): Gi0/1 is now designated
RSTP(1): Gi0/2 is now designated
RSTP(1): transmitting a proposal on Gi0/2
RSTP(1): Gi0/1 Dispute!
RSTP(1): Gi0/2 Dispute!
SW1 is changing its interfaces to the STP dispute status. We can see it here too:
SW1#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address fa16.3ef4.43e6
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address fa16.3ef4.43e6
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
200 | P a g e
Gi0/1 Desg BLK 4 128.2 P2p Dispute
Gi0/2 Desg BLK 4 128.3 P2p Dispute
Both interfaces are still designated ports, but they are blocked and show up “dispute”.
So, why exactly did this happen? The answer lies in the BPDUs that SW2 transmits to
SW1:
As you can see above, the port role (designated) is included in the BPDU. SW2 also
transmits its own MAC address and priority as the root bridge. This doesn’t make sense
since SW1 is the root bridge, the interfaces on SW2 should be a root port and non-
designated (alternate) port, not a designated port. Because it doesn’t match, SW1
changes the state to dispute.
SW2 remains clueless; we can’t blame it since it doesn’t receive the BPDUs from SW1:
SW2#show spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 4097
Address fa16.3e4e.be24
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address fa16.3e4e.be24
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Desg FWD 4 128.2 P2p
201 | P a g e
Gi0/2 Desg FWD 4 128.3 P2p
Thanks to our STP dispute, at least we don’t have a bridging loop…
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname SW1
!
ip cef
!
spanning-tree mode rapid-pvst
spanning-tree vlan 1 priority 0
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
end
hostname SW2
!
ip cef
!
mac access-list extended NO_STP
deny any host 0180.c200.0000
permit any any
!
spanning-tree mode rapid-pvst
spanning-tree vlan 1 priority 4096
!
interface GigabitEthernet0/1
mac access-group NO_STP in
spanning-tree link-type point-to-point
!
interface GigabitEthernet0/2
mac access-group NO_STP in
spanning-tree link-type point-to-point
!
end
Spanning-Tree Bridge Assurance
Spanning-tree Bridge Assurance is one of those STP features that help to prevent
bridging loops in your network. When bridge assurance is enabled, BPDUs are sent on
all interfaces of your switch, including blocked interfaces like the alternate or backup
202 | P a g e
port. When an interface doesn’t receive a BPDU for a certain time, the interface goes
into the blocking state.
Once the interface receives BPDUs again, the interface is unblocked and goes through
the normal spanning-tree port states again. This helps to prevent issues (ie,
unidirectional link failures or switch failures where the switch does forward ethernet
frames, but STP is malfunctioning) where for whatever reason, an interface doesn’t
receive BPDUs again, and a blocked interface goes into the forwarding state, causing a
bridging loop.
Bridge assurance is only supported by PVRST+ and MST.
In this lesson, I’ll show you a “before” and “after” scenario, and we will look at bridge
assurance in action.
1. Without Bridge Assurance
Let’s see how spanning-tree works when we don’t use bridge assurance. We have the
following topology:
SW1 is our root bridge, and it sends BPDUs on both interfaces. SW2 has the designated
port on the interface that connects to SW3, so the GigabitEthernet 0/2 interface on SW3
is the alternate port and blocking. Suddenly, SW2 stops sending BPDUs on its
GigabitEthernet 0/2 interface:
Because SW3 doesn’t receive superior BPDUs anymore on its GigabitEthernet 0/2
interface, it decides that the interface becomes a designated port and it forwards data.
We now have a bridging loop:
203 | P a g e
That’s not good…let’s see what happens with bridge assurance.
2. With Bridge Assurance
We use the same topology as before:
The difference, however, is that when bridge assurance is enabled, every interface
sends BPDUs. Once again, SW2 has a failure, so it’s no longer sending BPDUs:
204 | P a g e
SW1 and SW3 notice the lack of BPDUs and immediately put their interfaces in the
blocking state. This saves the day as there won’t be a bridging loop.
3. Configuration
Bridge assurance is supported on Cisco IOS since version 12.2(33)SXI, but it seems to
be only available on the Cisco catalyst 6500 series. I’m using three Nexus switches to
demonstrate bridge assurance. If you never worked with NX-OS before, don’t worry.
The output is pretty much the same as on Cisco IOS. This is the topology:
Bridge assurance is enabled globally by default on NX-OS:
NX1# show running-config all | include assurance
spanning-tree bridge assurance
However, we do have to change the spanning-tree port type to network on all interfaces
to activate it:
NX1(config)# int e1/28, e1/32
NX1(config-if-range)# spanning-tree port type network
NX2(config)# int e1/30, e1/32
NX2(config-if-range)# spanning-tree port type network
NX3(config)# int e1/28, e1/30
NX3(config-if-range)# spanning-tree port type network
That’s all we have to configure.
4. Verification
Let’s take a look at our spanning-tree port states:
NX1# show spanning-tree vlan 1
VLAN0001
205 | P a g e
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 547f.ee51.3abc
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 547f.ee51.3abc
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/28 Desg FWD 4 128.156 P2p
Eth1/32 Desg FWD 4 128.160 P2p
NX2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 547f.ee51.3abc
Cost 4
Port 160 (Ethernet1/32)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 547f.ee1f.1201
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/30 Altn BLK 4 128.158 P2p
Eth1/32 Root FWD 4 128.160 P2p
NX3# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 547f.ee51.3abc
Cost 4
Port 156 (Ethernet1/28)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 547f.ee1e.0381
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
206 | P a g e
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/28 Root FWD 4 128.156 P2p
Eth1/30 Desg FWD 4 128.158 P2p
Everything is working as it should. We have a root bridge (SW1), and the Ethernet 1/30
interface on NX2 is our alternate port. To test bridge assurance, I’ll enable BPDU filter
on one of my interfaces. This causes the interface to no longer send BPDUs, which will
trigger bridge assurance to block an interface.
I’ll enable BPDU filter on the E1/30 interface of NX2:
NX2(config)# interface e1/30
NX2(config-if)# spanning-tree bpdufilter enable
Once I do this, we see this message on the console of NX2 and NX3:
NX2#
NX2 %$ VDC-1 %$ %STP-2-BRIDGE_ASSURANCE_BLOCK: Bridge Assurance blocking port
Eth1/30 VLAN: 1
NX3#
NX3 %$ VDC-1 %$ %STP-2-BRIDGE_ASSURANCE_BLOCK: Bridge Assurance blocking port
Eth1/30 VLAN: 1.
NX2 is blocking its interface since BPDU filter stops the processing of BPDUs. NX3
blocks its interface since it is no longer receiving BPDUs. Let’s take another look at out
spanning-tree topology:
NX2# show spanning-tree vlan 1 | begin Interface
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/30 Desg BKN*4 128.158 P2p *BA_Inc
Eth1/32 Root FWD 4 128.160 P2p
The E1/30 interface of NX2 was already blocked when it was an alternate port, but now
it has become a designated post and shows “BA_Inc” which means it was blocked
because of bridge assurance. That’s a good thing as it prevents a bridging loop. We see
the same output on NX3:
NX3# show spanning-tree vlan 1 | begin Interface
207 | P a g e
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Eth1/28 Root FWD 4 128.156 P2p
Eth1/30 Desg BKN*4 128.158 P2p *BA_Inc
The E1/30 interface on NX3 is a designated port, but it has been blocked by bridge
assurance. If you remove the BPDU filter, the interfaces will automatically recover from
this bridge assurance error.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname NX1
vlan 1
spanning-tree vlan 1 priority 0
interface Ethernet1/28
spanning-tree port type network
interface Ethernet1/32
spanning-tree port type network
hostname NX2
feature interface-vlan
vlan 1
spanning-tree vlan 1 priority 4096
interface Ethernet1/30
spanning-tree port type network
interface Ethernet1/32
spanning-tree port type network
hostname NX3
vlan 1
interface Ethernet1/28
spanning-tree port type network
interface Ethernet1/30
spanning-tree port type network
5. Conclusion
You have now learned how bridge assurance sends BPDUs on all interfaces, in both
directions. Once a switch detects a lack of BPDUs, it puts the interface in blocking mode,
preventing a possible bridging loop.
208 | P a g e
1.2 Routing Concepts
IP Routing Explained
The actual forwarding of IP packets by routers is called IP routing. This has nothing to do
with the “learning” of network routes through static or dynamic routing protocols. but has
everything to do with the steps that routers have to take when they forward an IP packet
from one interface to another.
In this lesson, I will walk you through an example and show you all steps that occur.
To do this, I will use the following topology:
Above we have two host computers and two routers. H1 is going to send an IP packet to
H2 which has to be routed by R1 and R2.
1. IP Routing Processs
Let’s look at this step-by-step, device-by-device.
1.1. H1
Let’s start with H1. This host creates an IP packet with its own IP address (192.168.1.1)
as the source and H2 (192.168.2.2) as the destination. The first question that H1 will ask
itself is:
Is the destination local or remote?
It answers this question by looking at its own IP address, its subnet mask and the
destination IP address:
C:\Users\H1>ipconfig
209 | P a g e
Windows IP Configuration
Ethernet adapter Ethernet 1:
Connection-specific DNS Suffix . : nwl.local
Link-local IPv6 Address . . . . . : fe80::88fd:962a:44d6:3a1f%4
IPv4 Address. . . . . . . . . . . : 192.168.1.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.254
H1 is in network 192.168.1.0/24 so all IP addresses in the 192.168.1.1 – 254 range are
local. Our destination (192.168.2.2) is outside of the local subnet so that means we
have to use the default gateway.
H1 will now build an Ethernet frame, enters its own source MAC address and asks itself
the second question, do I know the destination MAC address of the default gateway?
It checks its ARP table to find the answer:
C:\Users\H1>arp -a
Interface: 192.168.1.1 --- 0x4
Internet Address Physical Address Type
192.168.1.254 fa-16-3e-3f-fd-3c dynamic
192.168.1.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.251 01-00-5e-00-00-fb static
224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static
H1 has an ARP entry for 192.168.1.254. If not, it would have sent an ARP request. We
now have an Ethernet frame that carries an IP packet with the following addresses:
The frame will be on its way to R1.
1.2. R1
This Ethernet frame makes it to R1 which has more work to do than our host. The first
thing it does, is check if the FCS (Frame Check Sequence) of the Ethernet frame is
correct or not:
210 | P a g e
If the FCS is incorrect, the frame is dropped right away. There is no error recovery for
Ethernet, this is something that is done by protocols on upper layers, like TCP on the
transport layer.
If the FCS is correct, we will process the frame if:
The destination MAC address is the address of the interface of the router.
The destination MAC address is a broadcast address of the subnet that the router
interface is connected to.
The destination MAC address is a multicast address that the router listens to.
In this case, the destination MAC address matches the MAC address of R1’s
GigabitEthernet 0/1 interface so we will process it. We de-encapsulate (extract) the IP
packet out of the Ethernet frame which is then discarded:
The router will now look at the IP packet, and the first thing it does is check if the header
checksum is OK:
If the header checksum is not correct, the IP packet is dropped right away. There is also
no error recovery on the network layer, we rely on upper layers for this. If the header
checksum is correct, we continue by looking at the destination IP address:
211 | P a g e
R1 now checks its routing table to see if there is a match:
R1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, GigabitEthernet0/1
L 192.168.1.254/32 is directly connected, GigabitEthernet0/1
S 192.168.2.0/24 [1/0] via 192.168.12.2
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/2
L 192.168.12.1/32 is directly connected, GigabitEthernet0/2
Above you can see that R1 knows how to reach the 192.168.2.0/24 network, the next
hop IP address is 192.168.12.2. It will now do a second routing table lookup to see if it
knows how to reach 192.168.12.2, we call this recursive routing. As you can see, there
is an entry for 192.168.12.0/24 with GigabitEthernet 0/2 as the interface to use.
There is one thing left to do with the IP packet before we can forward it. Since we are
routing it, we have to decrease the TTL (Time to Live) field by one. R1 will do this and
since this changes the IP header, we have to calculate a new header checksum.
212 | P a g e
Once this is done, R1 checks its ARP table to see if there is an entry for 192.168.12.2:
R1#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 58 fa16.3e87.9c2a ARPA GigabitEthernet0/1
Internet 192.168.1.254 - fa16.3e3f.fd3c ARPA GigabitEthernet0/1
Internet 192.168.12.1 - fa16.3e02.83a1 ARPA GigabitEthernet0/2
Internet 192.168.12.2 95 fa16.3e01.0c98 ARPA GigabitEthernet0/2
No problem there, we have an entry in the ARP table. If not, R1 will send an ARP
request to find the MAC address of 192.168.12.2. R1 builds a new Ethernet frame with
its own MAC address of the GigabitEthernet 0/2 interface and R2 as the destination. The
IP packet is then encapsulated in this new Ethernet frame.
And the frame will be on its way towards R2.
1.3. R2
This Ethernet frame makes it to R2. Like R1 it will first do this:
Check the FCS of the Ethernet frame.
De-encapsulates the IP packet, discard the frame.
Check the IP header checksum.
Check the destination IP address.
In the routing table, we find this:
R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
213 | P a g e
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
S 192.168.1.0/24 [1/0] via 192.168.12.1
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, GigabitEthernet0/1
L 192.168.2.254/32 is directly connected, GigabitEthernet0/1
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/2
L 192.168.12.2/32 is directly connected, GigabitEthernet0/2
Network 192.168.2.0/24 is directly connected to R2 on its GigabitEthernet 0/1 interface.
R2 will now reduce the TTL of the IP packet from 254 to 253, recalculate the IP header
checksum and checks its ARP table to see if it knows how to reach 192.168.2.2:
R2#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.2.2 121 fa16.3e4a.f598 ARPA GigabitEthernet0/1
Internet 192.168.2.254 - fa16.3e3c.7da4 ARPA GigabitEthernet0/1
Internet 192.168.12.1 111 fa16.3e02.83a1 ARPA GigabitEthernet0/2
Internet 192.168.12.2 - fa16.3e01.0c98 ARPA GigabitEthernet0/2
There is an ARP entry there. The new Ethernet frame is created, the IP packet
encapsulated, and it has the following addresses:
The frame is then forwarded to H2.
1.4. H2
H2 receives the Ethernet frame and will:
Check the FCS
Find its own MAC address as the destination MAC address.
De-encapsulates the IP packet from the frame.
Finds its own IP address as the destination in the IP packet.
H2 then looks for the protocol field to figure out what transport layer protocol we are
dealing with, what happens next depends on the transport layer protocol that is used.
That’s a story for another time.
214 | P a g e
2. Conclusion
You have now learned how an IP packet is forwarded from one router to another, also
known as IP routing.
Let’s summarize this process.
The host has a simple decision to make:
Is the destination on the local subnet?
o Check ARP table for destination IP address, if empty, send an ARP
request.
Is the destination on a remote subnet?
o Check ARP table for default gateway IP address, if empty, send an ARP
request.
The router has to perform a number of tasks:
When it receives an Ethernet frame, check if the FCS (Frame Check Sequence)
is correct. If not, drop the frame.
Check if the destination address of the frame is:
o destined to our MAC address
o destined to a broadcast address of the subnet our interface is in.
o destined to a multicast address that we listen to.
De-encapsulate the IP packet from the frame, discard the Ethernet frame.
Look for a match in the routing table for the destination IP address, figure out
what the outgoing interface and optionally, the next hop IP address is.
Decrease the TTL (Time to Live) field in the IP header, recalculate the header
checksum.
Encapsulate the IP packet in a new Ethernet frame.
Check the ARP table for the destination IP address or next hop IP address.
Transmit the frame.
215 | P a g e
1.2.a: Introduction to Administrative Distance
Administrative distance is one of those routing concepts that most CCNA students have
difficulty with to understand. In this short lesson I’ll explain to you what administrative
distance is and how it works.
Let me show you an example:
Imagine we have a network that is running two routing protocols at the same time,
OSPF and EIGRP. Both routing protocols are giving information to R1.
EIGRP tells us the router should send IP packets using the path on the top.
OSPF tells us the router should send IP packets using the path on the bottom.
What routing information are we going to use? Both? Use OSPF or EIGRP?
The answer is that when two routing protocols are giving us information about the
same destination network we have to make a choice…you can’t go left and right at the
same time. We need to look at the administrative distance or AD.
Let me show you the administrative distance list:
216 | P a g e
Administrative Distance
Directly connected 0
Static route 1
EIGRP 90
OSPF 110
RIP 120
The lower the administrative distance the better. As you can see a directly connected
route has an AD of 0. This makes sense since there’s nothing better than having it
directly connected to your router. A static route has a very low administrative distance of
1 which also makes sense since this is something you configure manually. Sometimes
you use a static route to “overrule” a routing protocol’s decisions.
EIGRP has an administrative distance of 90 which makes sense since well, it’s a Cisco
routing protocol. OSPF has 110 and RIP has 120. In our example above we will use the
information EIGRP tells us in the routing table since its AD of 90 is better (lower) than
OSPF which has 110.
Let’s look at an example of an actual router. This is the topology:
Above we see that R1 is connected to both R2 and R3. Here’s the routing table:
R1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
217 | P a g e
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
2.0.0.0/24 is subnetted, 1 subnets
R 2.2.2.0 [120/1] via 192.168.12.2, 00:00:21, GigabitEthernet0/1
3.0.0.0/24 is subnetted, 1 subnets
S 3.3.3.0 [1/0] via 192.168.13.3
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/1
L 192.168.12.1/32 is directly connected, GigabitEthernet0/1
192.168.13.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.13.0/24 is directly connected, GigabitEthernet0/2
L 192.168.13.1/32 is directly connected, GigabitEthernet0/2
Above you can see that R1 has learned 2.2.2.0 /24 through RIP. Between the brackets,
we find:
[120/1]
120 is the administrative distance, 1 is the metric. In case of RIP, that’s the hop count.
R1 also has a static route for 3.3.3.0 /24 to R3. Between the brackets we find:
[1/0]
1 is the administrative distance, since this is a static route, there is no metric so it’s 0. I
hope this has been helpful to understand the administrative distance.
218 | P a g e
1.2.b: VRF Lite
VRF Lite Configuration on Cisco IOS
In this lesson you will learn about VRFs (Virtual Routing and Forwarding). By default a
router uses a single global routing table that contains all the directly connected
networks and prefixes that it learned through static or dynamic routing protocols.
VRFs are like VLANs for routers, instead of using a single global routing table we can
use multiple virtual routing tables. Each interface of the router is assigned to a different
VRF.
VRFs are commonly used for MPLS deployments, when we use VRFs without MPLS
then we call it VRF lite. That’s what we will focus on in this lesson. Let’s take a look at
an example topology
219 | P a g e
In the topology above we have one ISP router and two customers called “Red” and
“Blue”. Each customer has two sites and those are connected to the ISP router. The ISP
router has only one global routing table so if we connect everything like the topology
above, this is what the routing table will look like:
ISP#show ip route connected
C 192.168.4.0/24 is directly connected, FastEthernet3/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.2.0/24 is directly connected, FastEthernet1/0
C 192.168.3.0/24 is directly connected, FastEthernet2/0
The ISP router has a single global routing table that has all 4 directly connected
networks. Let’s use VRFs to change this, I want to create a separate routing table for
customer “Blue” and “Red”. First we have to create these VRFs:
ISP(config)#ip vrf Red
ISP(config-vrf)#exit
ISP(config)#ip vrf Blue
ISP(config-vrf)#exit
Globally we create the VRFs, one for each customer. Our next step is to add the
interfaces of the ISP router to the correct VRF. Here’s how:
ISP(config)#interface FastEthernet 0/0
ISP(config-if)#ip vrf forwarding Blue
% Interface FastEthernet0/0 IP address 192.168.1.254 removed due to enabling VRF
Blue
ISP(config-if)#ip address 192.168.1.254 255.255.255.0
220 | P a g e
On the interface level we use the ip vrf forwarding command to assign the interface to
the correct VRF. Once you do this , you’ll have to add the IP address again. Let’s
configure the remaining interfaces:
ISP(config)#interface FastEthernet 1/0
ISP(config-if)#ip vrf forwarding Red
ISP(config-if)#ip address 192.168.2.254 255.255.255.0
ISP(config)#interface FastEthernet 2/0
ISP(config-if)#ip vrf forwarding Blue
ISP(config-if)#ip address 192.168.3.254 255.255.255.0
ISP(config)#interface FastEthernet 3/0
ISP(config-if)#ip vrf forwarding Red
ISP(config-if)#ip address 192.168.4.254 255.255.255.0
All interfaces are now configured. There’s a useful command you can use to see all the
VRFs and their interfaces:
ISP#show ip vrf
Name Default RD Interfaces
Blue Fa0/0
Fa2/0
Red Fa1/0
Fa3/0
Our VRFs are configured, let’s take a look at the global routing table of the ISP router:
ISP#show ip route connected
The global routing table has no entries, this is because all interfaces were added to a
VRF. Let’s check the VRF routing tables:
ISP#show ip route vrf Blue connected
C 192.168.1.0/24 is directly connected, FastEthernet0/0
C 192.168.3.0/24 is directly connected, FastEthernet2/0
ISP#show ip route vrf Red connected
C 192.168.4.0/24 is directly connected, FastEthernet3/0
C 192.168.2.0/24 is directly connected, FastEthernet1/0
We use the show ip route command, but you’ll need to specify which VRF you want to
look at. As you can see, each VRF has its own routing table with the interfaces that we
configured earlier.
If you want to do something on the router like sending a ping then you’ll have to specify
which VRF you want to use. By default it will use the global routing table. Here’s an
example how to send a ping:
221 | P a g e
ISP#ping vrf Blue 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
That’s easy enough, just don’t forget to specify the correct VRF. The same thing applies
to routing (protocols). For example if you want to configure a static route you’ll have to
specify the correct VRF. Take a look at the example below:
Router Blue1 has a loopback interface with IP address 1.1.1.1 /32. Let’s create a static
route on the ISP router so that we can reach it:
ISP(config)#ip route vrf Blue 1.1.1.1 255.255.255.255 192.168.1.1
We use the same ip route command, but I specified to what VRF the static route
belongs. Let’s see if this works:
ISP#ping vrf Blue 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/24/52 ms
Easy enough, the ping works. What about routing protocols? We can use OSPF, EIGRP,
BGP…no problem at all. Let’s look at an example for OSPF:
222 | P a g e
Customer “Blue” and “Red” both want to use OSPF to advertise their networks. Since we
use VRFs, everything is separated. Let’s start with the OSPF configuration for customer
Blue:
Blue1(config)#router ospf 1
Blue1(config-router)#network 192.168.1.0 0.0.0.255 area 0
Blue1(config-router)#network 1.1.1.1 0.0.0.0 area 0
Blue2(config)#router ospf 1
Blue2(config-router)#network 192.168.3.0 0.0.0.255 area 0
Blue2(config-router)#network 3.3.3.3 0.0.0.0 area 0
The OSPF configuration for the customer routers is pretty straight-forward. On the ISP
router, we’ll have to specify what VRF we want to use:
ISP(config)#router ospf 1 vrf Blue
ISP(config-router)#network 192.168.1.0 0.0.0.255 area 0
ISP(config-router)#network 192.168.3.0 0.0.0.255 area 0
We configure OSPF process 1 and specify the VRF that we want to use, that’s all there
is to it. Let’s do the same for customer Red:
Red1(config)#router ospf 1
Red1(config-router)#network 192.168.2.0 0.0.0.255 area 0
Red1(config-router)#network 2.2.2.2 0.0.0.0 area 0
Red2(config)#router ospf 1
Red2(config-router)#network 192.168.4.0 0.0.0.255 area 0
Red2(config-router)#network 4.4.4.4 0.0.0.0 area 0
ISP(config)#router ospf 2 vrf Red
ISP(config-router)#network 192.168.2.0 0.0.0.255 area 0
223 | P a g e
ISP(config-router)#network 192.168.4.0 0.0.0.255 area 0
The configuration is similar, I had to use another process ID on the ISP router since the
first one is used for customer Blue. Here’s what the VRF routing tables on the ISP router
look like now:
ISP#show ip route vrf Blue ospf
Routing Table: Blue
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 192.168.1.1, 00:00:24, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/2] via 192.168.3.3, 00:00:24, FastEthernet2/0
ISP#show ip route vrf Red ospf
Routing Table: Red
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 192.168.2.2, 00:00:19, FastEthernet1/0
4.0.0.0/32 is subnetted, 1 subnets
O 4.4.4.4 [110/2] via 192.168.4.4, 00:00:19, FastEthernet3/0
Two separate routing tables with the prefixes from each VRF, this is looking good.
This is what VRF lite is about, it has one downside though…it’s not a scalable solution.
In our example we only used a single ISP router but what if we want to use VRFs and
multiple ISP routers? That’s something we’ll discuss in the EVN (Easy Virtual Network)
lesson.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
!
end
hostname Blue2
224 | P a g e
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.3.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 192.168.3.0 0.0.0.255 area 0
!
end
hostname ISP
!
ip cef
!
ip vrf Blue
!
ip vrf Red
!
interface FastEthernet0/0
ip vrf forwarding Blue
ip address 192.168.1.254 255.255.255.0
!
interface FastEthernet1/0
ip vrf forwarding Red
ip address 192.168.2.254 255.255.255.0
!
interface FastEtherne2/0
ip vrf forwarding Blue
ip address 192.168.3.254 255.255.255.0
!
interface FastEthernet3/0
ip vrf forwarding Red
ip address 192.168.4.254 255.255.255.0
!
router ospf 1 vrf Blue
network 192.168.1.0 0.0.0.255 area 0
network 192.168.3.0 0.0.0.255 area 0
!
router ospf 2 vrf Red
network 192.168.2.0 0.0.0.255 area 0
network 192.168.4.0 0.0.0.255 area 0
!
end
hostname Red1
!
ip cef
!
interface Loopback0
225 | P a g e
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.2.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 192.168.2.0 0.0.0.255 area 0
!
end
hostname Red2
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.4.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.4.0 0.0.0.255 area 0
!
end
VRF Lite Route Leaking
VRF Lite allows us to use multiple routing tables on a router, creating a separation
similar to VLANs on switches. Each interface on the router can be assigned to a different
VRF. However, what if you have some shared services or routes that should be shared
between multiple VRFs?
It is possible to “leak” routes from one VRF into another. There are two options to
achieve this:
Static Routes
MP-BGP
In this lesson, I’ll show you how to configure both options.
1. Configuration
This is the topology I will use:
226 | P a g e
We have an ISP router that is connected to two customers. For each customer, we use a
different VRF:
VRF “RED” for Red1
VRF “BLUE” for Blue1
Want to take a look for yourself? Here you will find the startup configuration of each
device.
hostname ISP
!
ip vrf BLUE
!
ip vrf RED
!
ip cef
!
interface GigabitEthernet0/1
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip vrf forwarding BLUE
ip address 192.168.23.2 255.255.255.0
!
end
hostname Red1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
!
end
hostname Blue1
!
227 | P a g e
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
end
With the configuration above, we only have connectivity within a VRF. What if we want
connectivity between VRF RED and BLUE?
1.1. Static Routes
Let’s start with the static routes option. According to this Cisco document, static routes
directly between VRFs are not supported. What does work, is routing traffic from a VRF
to the global routing table and then to the destination VRF. One advantage of using
static routes is that you can configure exactly which routes should be reachable without
the hassle of configuring MP-BGP.
I’ll show you how to get connectivity between 1.1.1.1/32 in VRF RED and 3.3.3.3/32 in
VRF BLUE.
1.1.1. Configuration
First, let’s create a default route on the Red1 and Blue1 routers so that they send all
unknown traffic towards the ISP router:
Red1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2
Blue1(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2
In each VRF, we add a static route for the destination in the other VRF that we want to
reach. This static route is pointed to the global routing table:
ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3 global
ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1 global
Let me explain what you see above:
In VRF RED, we have a static route to destination 3.3.3.3/32 that uses next hop
IP address 192.168.23.3 in the global routing table.
In VRF BLUE, we have a static route for destination 1.1.1.1/32 that uses next hop
IP address 192.168.12.1 in the global routing table.
These two static routes will route traffic from the VRFs to the global routing table. These
next hop addresses, however, are not in the global routing table but in the VRFs.
228 | P a g e
We need to add two static routes in the global routing table of the ISP router so that it
knows how to reach the next hop addresses:
ISP(config)#ip route 192.168.12.1 255.255.255.255 GigabitEthernet 0/1
ISP(config)#ip route 192.168.23.3 255.255.255.255 GigabitEthernet 0/2
That completes our configuration.
1.1.2. Verification
Let’s look at the routing tables of our ISP router. Here’s the routing table of VRF RED:
ISP#show ip route vrf RED static
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 192.168.23.3
Above we see the static route for 3.3.3.3/32 that points to 192.168.23.3. It doesn’t show
it, but this static route points to the global routing table. Here is the route for 1.1.1.1/32 in
routing table VRF BLUE:
ISP#show ip route vrf BLUE static
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [1/0] via 192.168.12.1
Here is the global routing table:
ISP#show ip route static
192.168.12.0/32 is subnetted, 1 subnets
S 192.168.12.1 is directly connected, GigabitEthernet0/1
192.168.23.0/32 is subnetted, 1 subnets
S 192.168.23.3 is directly connected, GigabitEthernet0/2
Above, we see the entries for the next hop addresses in the global routing table.
The ISP router is now able to route from one VRF into the global routing table and into
another VRF. Let’s try a quick ping:
Red1#ping 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/7/10 ms
Mission accomplished.
229 | P a g e
Want to take a look for yourself? Here you will find the startup configuration of each
device.
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.23.2
!
end
hostname ISP
!
ip vrf BLUE
!
ip vrf RED
!
ip cef
!
interface GigabitEthernet0/1
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip vrf forwarding BLUE
ip address 192.168.23.2 255.255.255.0
!
ip route 192.168.12.1 255.255.255.255 GigabitEthernet0/1
ip route 192.168.23.3 255.255.255.255 GigabitEthernet0/2
ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1 global
ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3 global
!
end
hostname Red1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
230 | P a g e
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.12.2
!
end
1.2. MP-BGP
Let’s see how we can get connectivity between the VRFs by using MP-BGP. This is
pretty much the same as MPLS VPN PE CE but without MPLS. We will use MP-BGP to
redistribute routes from one VRF into another.
To demonstrate this, I will redistribute static routes that I create on the ISP router into
MP-BGP. Of course, you can also use a routing protocol like OSPF or EIGRP between
the ISP and customer routers.
1.2.1. Configuration
Let’s create a default route on the customer routers that point to the ISP:
Red1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2
Blue1(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2
On the ISP router, I have to do two things under the VRF configuration:
We need an RD (Route Distinguisher) for each VRF.
We need an RT (Route Target) and export/import our routes.
This is what we’ll do:
VRF RED will use RD 1:1 and VRF BLUE uses RD 3:3
Routes from VRF RED will be exported using RT 1:1
Routes from VRF BLUE will be exported using RT 3:3
Let’s start with the configuration for VRF RED:
ISP(config)#ip vrf RED
ISP(config-vrf)#rd 1:1
ISP(config-vrf)#route-target export 1:1
ISP(config-vrf)#route-target import 3:3
VRF RED exports its routes with RT 1:1 and imports routes with RT 3:3. Here’s VRF
BLUE:
231 | P a g e
ISP(config)#ip vrf BLUE
ISP(config-vrf)#rd 3:3
ISP(config-vrf)#route-target export 3:3
ISP(config-vrf)#route-target import 1:1
Now we can worry about getting the routes into each other’s VRF. For each VRF, I will
create a static route that points to the loopback 0 interface of the other VRF:
ISP(config)#ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3
Now we can redistribute these into MP-BGP. Let’s start a new BGP process. It doesn’t
matter what AS number you use since we won’t have any neighbors. Since I don’t have
any IP addresses in my global routing table, BGP will complain about being unable to
pick a router ID so I’ll configure one manually:
ISP(config)#router bgp 2
ISP(config-router)#bgp router-id 2.2.2.2
Under the address-family of each VRF, we have to redistribute two things:
Static route: this is the static route we just configured for each VRF, it points to
the loopback 0 interface of the other customer router.
Directly connected route: required because the next hop IP address for the static
route is on this network.
ISP(config-router)#address-family ipv4 vrf RED
ISP(config-router-af)#redistribute static
ISP(config-router-af)#redistribute connected
ISP(config-router)#address-family ipv4 vrf BLUE
ISP(config-router-af)#redistribute static
ISP(config-router-af)#redistribute connected
Our static and directly connected routes are now in MP-BGP and will be
exported/imported according to the route-targets we configured.
1.2.2. Verification
Let’s take a look at the VPN routes of each VRF:
ISP#show bgp vpnv4 unicast vrf RED
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf RED)
*> 1.1.1.1/32 192.168.12.1 0 32768 ?
*> 3.3.3.3/32 192.168.23.3 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.23.0 0.0.0.0 0 32768 ?
232 | P a g e
VRF RED has learned the 3.3.3.3/32 and 192.168.23.0/24 prefixes. Here’s VRF BLUE:
ISP#show bgp vpnv4 unicast vrf BLUE
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 3:3 (default for vrf BLUE)
*> 1.1.1.1/32 192.168.12.1 0 32768 ?
*> 3.3.3.3/32 192.168.23.3 0 32768 ?
*> 192.168.12.0 0.0.0.0 0 32768 ?
*> 192.168.23.0 0.0.0.0 0 32768 ?
VRF BLUE has the 1.1.1.1/32 and 192.168.12.0/24 prefixes. We can also see these in
the routing table of each VRF:
ISP#show ip route vrf RED bgp
3.0.0.0/32 is subnetted, 1 subnets
B 3.3.3.3 [20/0] via 192.168.23.3 (BLUE), 00:06:41
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.23.0/24 is directly connected, 00:08:20, GigabitEthernet0/2
ISP#show ip route vrf BLUE bgp
1.0.0.0/32 is subnetted, 1 subnets
B 1.1.1.1 [20/0] via 192.168.12.1 (RED), 00:07:23
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
B 192.168.12.0/24 is directly connected, 00:09:00, GigabitEthernet0/1
Let’s see if we have connectivity between VRF RED and BLUE:
Red1#ping 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/9 ms
Excellent, this is working.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname Blue1
!
ip cef
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Loopback1
ip address 33.33.33.33 255.255.255.255
!
233 | P a g e
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.23.2
!
end
hostname ISP
!
ip vrf BLUE
rd 3:3
route-target export 3:3
route-target import 1:1
!
ip vrf RED
rd 1:1
route-target export 1:1
route-target import 3:3
!
ip cef
!
interface GigabitEthernet0/1
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip vrf forwarding BLUE
ip address 192.168.23.2 255.255.255.0
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
!
address-family ipv4 vrf BLUE
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
redistribute static
exit-address-family
!
ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3
ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1
!
end
hostname Red1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
234 | P a g e
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.12.2
!
end
2. Conclusion
You have now learned how to leak routes from one VRF into another:
How to use static routes to route from a VRF into the global routing table and into
another VRF.
How to use MP-BGP to exchange routes from one VRF into another.
235 | P a g e
1.2.c: Static Routing
Static route on Cisco IOS Router
In this lesson we’ll take a look at static routes, and in particular how to configure them.
Let me show you the following topology:
Look at the network in the picture above. We have a network with two sites,
headquarters and a branch office.
The headquarters is connected to the Branch office. Behind the branch office is a
network with the 2.2.2.0 /24 network. We want to make sure that the headquarters can
reach the 2.2.2.0 /24 network.
Let me show you how we configure this network using a static route:
HQ>enable
HQ#configure terminal
First I’ll go to enable mode and enter configuration mode.
HQ(config)#interface FastEthernet 0/0
HQ(config-if)#no shutdown
HQ(config-if)#ip address 192.168.12.1 255.255.255.0
Branch>enable
Branch#configure terminal
Branch(config)#interface fastEthernet0/0
Branch(config-if)#no shutdown
Branch(config-if)#ip address 192.168.12.2 255.255.255.0
Branch(config-if)#exit
236 | P a g e
Branch(config)#interface fastEthernet 1/0
Branch(config-if)#no shutdown
Branch(config-if)#ip address 2.2.2.2 255.255.255.0
Then I’ll configure the IP addresses on the interfaces; don’t forget to do a “no shutdown”
on the interfaces.
Let’s take a look at the routing tables of both routers:
HQ#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1,
ia - IS-IS inter area, * - candidate default,
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
Branch#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1,
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, FastEthernet1/0
Use the show ip route command to view the routing table. This is what a router uses to
make decisions where to forward IP packets to. By default a router only knows its
directly connected networks. We configured an IP address with a subnet mask on the
interface, so the router also knows the network address.
Router HQ knows about network 192.168.12.0/24.
Router Branch knows about network 192.168.12.0/24 and 2.2.2.0/24.
At this moment our HQ router has no idea how to reach network 2.2.2.0/24 because
there is no entry in the routing table. What will happen when we try to reach it? Let’s
check:
HQ#ping 2.2.2.2
Type escape sequence to abort.
237 | P a g e
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
The ping will fail. This router checks its routing table, discovers that it doesn’t know how
to reach network 2.2.2.0 /24 and will drop the traffic. Let’s use a static route to tell router
HQ how to reach this network!
HQ(config)#ip route 2.2.2.0 255.255.255.0 192.168.12.2
We use the ip route command to create a static route. Let me break it down for you:
2.2.2.0 is the network we want to reach.
255.255.255.0 is the subnet mask of the network.
192.168.12.2 is called the next hop IP address. It’s the IP address where we want
to send traffic to. In this example that’s the branch router.
I’m telling router HQ that it can reach network 2.2.2.0 /24 by sending traffic to IP address
192.168.12.2 (the Branch router).
Let’s take another look at the routing table to see if anything has changed:
HQ#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 -IS-IS inter area, *
- candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
1.0.0.0/24 is subnetted, 1 subnets
C 1.2.3.0 is directly connected, FastEthernet0/0
2.0.0.0/24 is subnetted, 1 subnets
S 2.2.2.0 [1/0] via 192.168.12.2
We can now see an entry for network 2.2.2.0/24 in our routing table. Whenever router
HQ has traffic for network 2.2.2.0 /24 it will send it to IP address 192.168.12.2 (router
Branch). Let’s see if our ping is now working:
HQ#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
238 | P a g e
Bingo now it’s working. Router HQ knows how to reach network 2.2.2.0 /24 because of
our static route.
Are you following me so far? Whenever an IP packet arrives at a router it will check its
routing table to see if it knows about the destination network. If it does it will forward the
IP packet and if it has no idea where to send traffic it will drop the IP packet.
Want to take a look for yourself? Here you will find the startup configuration of each
device.
hostname HQ
!
interface FastEthernet 0/0
ip address 192.168.12.1 255.255.255.0
!
ip route 2.2.2.0 255.255.255.0 192.168.12.2
!
end
hostname Branch
!
interface fastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface fastEthernet 1/0
ip address 2.2.2.2 255.255.255.0
!
end
There is another situation where a static route might be useful, let me demonstrate
another network:
In the picture above our HQ router is connected to an ISP (Internet Service Provider).
There are many networks on the Internet so do we require all of those networks on the
Internet in our routing table? The answer is no because we can use a default route, let
me show you what it is:
HQ(config)#interface fastEthernet 1/0
HQ(config-if)#ip address 1.2.3.2 255.255.255.0
HQ(config-if)#no shutdown
HQ(config-if)#exit
First we’ll configure an IP address on the Fastethernet 1/0 of the HQ router.
239 | P a g e
HQ#ping 1.2.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.2.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms
It’s always a good idea to check connectivity. A quick ping to the ISP router proves that
we can reach the ISP.
HQ#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 -IS-IS inter area, *
- candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 1.2.3.0 is directly connected, FastEthernet1/0
Right now the HQ router only knows how to reach network 1.2.3.0/24 because it’s
directly connected. Let’s configure a default route so that we can reach the Internet:
HQ(config)#ip route 0.0.0.0 0.0.0.0 1.2.3.1
Let me explain this one:
The first 0.0.0.0 is the network address; in this case it means all networks.
The second 0.0.0.0 is the subnet mask; all 0s means all subnet masks.
1.2.3.1 is the next hop IP address. In this case the IP address of the ISP router.
In other words, this static route will match all networks and that’s why we call it a default
route. When our router doesn’t know where to deliver IP packets to, we’ll throw it over
the fence towards the ISP and it will be their job to deliver it…sounds good right?
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname HQ
!
interface FastEthernet 1/0
ip address 1.2.3.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 1.2.3.1
!
end
240 | P a g e
hostname ISP
!
interface FastEthernet 0/0
ip address 1.2.3.1 255.255.255.0
!
end
Something important to know about routers is that they always will use the most specific
match in their routing table. Let me give you an example:
Router#show ip route static
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
S 192.168.1.0/24 [1/0] via 10.2.2.2
S 192.168.1.128/25 [1/0] via 10.3.3.2
S 192.168.0.0/16 [1/0] via 10.1.1.2
Imagine the router above receives an IP packet with destination IP address
192.168.1.140. Will it send the IP packet towards 10.2.2.2, 10.3.3.2 or 10.1.1.2?
All 3 entries in the routing table match this destination IP address but in this case
192.168.1.128 /25 is the most specific entry. The IP packets will be forwarded to
10.3.3.2.
Now you know how a router uses its routing table and how to configure a static route.
Are there any disadvantages to static routes? Let me show you an example:
In the picture above I have many routers and a lot of networks. If I want to configure full
reachability between the routers then I have to configure a LOT of static routes to make
this work and you don’t have any backups. If a link fails you’ll need to edit your static
route and send traffic another direction. The picture above would be more suitable
for dynamic routing.
How to configure IPv6 Static Route
If you know how to configure a static route for IPv4 then you shouldn’t have any issues
with IPv6 static routes. The configuration and syntax are similar, there are only some
minor differences. In this lesson, I will show you how to configure all IPv6 static route
types.
241 | P a g e
1. Configuration
To demonstrate this topology, I will use the following topology:
R1 and R2 are connected with a serial link. R2 has a loopback interface with IPv6
addresses 2001:DB8:2:2::2/64. Let’s see if we can reach this address.
1.1. Static route for a prefix
Let’s start with a simple example where we create a static route for the prefix we want to
reach: 2001:DB8:2:2::/64.
1.1.1. Static route for a prefix – outgoing interface
Just like with IPv4, it is possible to use an interface as the next hop. This will only work
with point-to-point interfaces:
R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0
Here’s what the routing table looks like:
R1#show ipv6 route static
S 2001:DB8:2:2::/64 [1/0]
via Serial0/0/0, directly connected
Let’s see if it works:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Our ping is working.
If you try this with a FastEthernet interface, you’ll see that the router will accept the
command, but the ping won’t work. You can’t use this for multi-access interfaces.
1.1.2. Static route for a prefix – global unicast next hop
Instead of an outgoing interface, we can also specify the global unicast address as the
next hop:
242 | P a g e
R1(config)#ipv6 route 2001:DB8:2:2::/64 2001:DB8:12:12::2
Here’s what the routing table looks like:
R1#show ipv6 route static
S 2001:DB8:2:2::/64 [1/0]
via 2001:DB8:12:12::2
Let’s see if it works:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
No problem at all…
Instead of global unicast addresses, you can also use unique local addresses. These
are the IPv6 equivalent of IPv4 private addresses.
1.1.3. Static route for a prefix – link-local next hop
One of the differences between IPv4 and IPv6 is that IPv6 generates a link-local address
for each interface. In fact, these link-local addresses are also used by routing protocols
like RIPng, EIGRP, OSPFv3, etc. as the next hop addresses. Let’s see what the link-
local address is of R2:
R2#show ipv6 interface Serial 0/0/0 | include link-local
IPv6 is enabled, link-local address is FE80::21C:F6FF:FE11:41F0
Let’s use this as the next hop address. When you use a global unicast address as the
next hop, your router will be able to look at the routing table and figure out what outgoing
interface to use to reach this global unicast address. With link local addresses, the router
has no clue which outgoing interface to use so you will have to specify both the outgoing
interface and the link local address:
R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0
Here’s what the routing table looks like:
R1#show ipv6 route static
243 | P a g e
S 2001:DB8:2:2::/64 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
Just to be sure, let’s try a ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
No problems there.
1.2. Static default route
Just like IPv4, we can also create static default routes. A default route has only zeroes
(::) and a /0 prefix-length. This is the equivalent of 0.0.0.0/0 in IPv4. We can do this with
an interface, global unicast or link-local address. Let’s try all options!
1.2.1. Static default route – outgoing interface
Let’s start with the outgoing interface first:
R1(config)#ipv6 route ::/0 Serial 0/0/0
Here’s the routing table:
R1#show ipv6 route static
S ::/0 [1/0]
via Serial0/0/0, directly connected
Let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
1.2.2. Static default route – global unicast next hop
Instead of an outgoing interface, let’s try a global unicast next hop address:
R1(config)#ipv6 route ::/0 2001:DB8:12:12::2
244 | P a g e
Here’s the routing table:
R1#show ipv6 route static
S ::/0 [1/0]
via 2001:DB8:12:12::2
Let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Time for the next option.
1.2.3. Static default route – link-local next hop
Let’s replace the global unicast next hop address with a link-local address:
R1(config)#ipv6 route ::/0 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0
Here’s the routing table:
R1#show ipv6 route static
S ::/0 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
Let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
Our ping is working.
1.3. Static host route
We can also create static routes for a single IPv6 address, this is called a static host
route. These examples are the same as the ones you have seen before but this time,
we will create an entry for 2001:DB8:2:2::2/128 which is similar to using a /32 subnet
mask in IPv4.
245 | P a g e
1.3.1. Static host route – outgoing interface
First we will try the outgoing interface:
R1(config)#ipv6 route 2001:DB8:2:2::2/128 Serial 0/0/0
Here is the routing table:
R1#show ipv6 route static
S 2001:DB8:2:2::2/128 [1/0]
via Serial0/0/0, directly connected
Let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
1.3.2. Static host route – global unicast next hop
Let’s try a global unicast address as the next hop:
R1(config)#ipv6 route 2001:DB8:2:2::2/128 2001:DB8:12:12::2
Here is the routing table:
R1#show ipv6 route static
S 2001:DB8:2:2::2/128 [1/0]
via 2001:DB8:12:12::2
And let’s try a quick ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
1.3.3. Static host route – link-local next hop
Last but not least, a link-local address as the next hop address:
R1(config)#ipv6 route 2001:DB8:2:2::2/128 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0
246 | P a g e
Here’s R1’s routing table:
R1#show ipv6 route static
S 2001:DB8:2:2::2/128 [1/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
Let’s try another ping:
R1#ping 2001:DB8:2:2::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
1.4. Static floating route
We can also configure floating static routes. To test this, I have to add another router:
R3 is added to our topology and I configured the same loopback address
(2001:DB8:23:23::23/128) on both routers. R3 will be used as our main path to reach
this address. When the link is down we want to use R2.
Here’s the static route that is used to use R3 as the primary path:
R1(config)#ipv6 route 2001:DB8:23:23::/64 2001:DB8:13:13::3
1.4.1. Static floating route – outgoing interface
Let’s try the outgoing interface first. The static route looks like this:
247 | P a g e
R1(config)#ipv6 route 2001:DB8:23:23::/64 Serial 0/0/0 2
Note that at the end of the line above, I specified the administrative distance with a value
of 2. With both interfaces up, R1 will send all traffic to R3:
R1#show ipv6 route static
S 2001:DB8:23:23::/64 [1/0]
via 2001:DB8:13:13::3
Above you can see that the default administrative distance is 1. Let’s shut the
FastEthernet 0/0 interface to test our static floating route:
R1(config)#interface FastEthernet 0/0
R1(config-if)#shutdown
Let’s look at the routing table again:
R1#show ipv6 route static
S 2001:DB8:2:2::/64 [2/0]
via Serial0/0/0, directly connected
The entry to R2 is now installed. You can also see the administrative distance value of
two in the routing table.
1.4.2. Static floating route – global unicast next hop
Instead of the outgoing interface, we can also use a global unicast address as the next
hop:
R1(config)#ipv6 route 2001:DB8:2:2::/64 2001:DB8:12:12::2 2
The routing table will then look like this:
R1#show ipv6 route static
S 2001:DB8:2:2::/64 [2/0]
via 2001:DB8:12:12::2
1.4.3. Static floating route – link-local next hop
Or use a link-local address as the next hop:
R1(config)#ipv6 route 2001:DB8:2:2::/64 Serial 0/0/0 FE80::21C:F6FF:FE11:41F0 2
248 | P a g e
Here is the routing table:
R1#show ipv6 route static
S 2001:DB8:2:2::/64 [2/0]
via FE80::21C:F6FF:FE11:41F0, Serial0/0/0
2. Conclusion
You have now learned how to configure the following IPv6 static routes:
Static route for a prefix
Static default route
Static host route
Static floating route
And how to do this with different next hop types:
Outgoing interface (only for point-to-point interfaces)
Global unicast address
Link-local address
249 | P a g e
1.2.d: Policy Based Routing
How to configure Policy Based Routing
Policy-based routing can be used to change the next hop IP address for traffic matching
certain criteria. This can be useful to overrule your routing table for certain traffic types. I
will show you how to configure policy based routing.
1. Configuration
Here’s the topology that we will use:
Take a look at the topology picture above. OSPF is configured on all routers. Since we
are using Gigabit interfaces everywhere, traffic from R1 destined to 4.4.4.4 would
normally be load balanced between R2 and R3. However, I changed the cost on the
Gigabit Ethernet 0/3 interface of R1 so that all traffic will go from R1 > R2 > R4.
Want to try this for yourself? Here you will find the startup configuration of each device.
hostname H1
250 | P a g e
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.100 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end
hostname R1
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.12.1 255.255.255.0
!
interface GigabitEthernet0/3
ip address 192.168.13.1 255.255.255.0
ip ospf cost 1000
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0
!
end
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0
!
end
hostname R3
!
ip cef
251 | P a g e
!
interface GigabitEthernet0/0
no ip address
!
interface GigabitEthernet0/1
ip address 192.168.13.3 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 192.168.13.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.24.4 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
Let’s verify this:
R1#show ip ospf interface GigabitEthernet 0/2 | include Cost:
Process ID 1, Router ID 192.168.13.1, Network Type BROADCAST, Cost: 1
R1#show ip ospf interface GigabitEthernet 0/3 | include Cost:
Process ID 1, Router ID 192.168.13.1, Network Type BROADCAST, Cost: 1000
Above you can see the increased cost. Let’s try a quick traceroute from H1:
H1#traceroute 4.4.4.4 probe 1
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.1.254 7 msec
2 192.168.12.2 6 msec
3 192.168.24.4 8 msec
252 | P a g e
Now let’s say that I want to use the link in between R1 and R3 to reach 4.4.4.4. I could
influence the metric for OSPF, but this applies to all traffic. What if I wanted to use this
link for certain traffic only?
We could use the link in between R1/R2 for the majority of our traffic and use the link
between R1/R3 only for certain traffic. This can be very useful. For example, imagine
that the link between R1/R3 is a dedicated link that offers QoS for VoIP traffic.
This is something we can achieve with PBR (Policy Based Routing) Let me show you
how!
Right now, all traffic is sent towards R2:
R1#show ip route | include 4.4.4.4
O 4.4.4.4 [110/3] via 192.168.12.2, 00:16:48, GigabitEthernet0/2
Now let’s say that we want all ICMP traffic from H1 destined for 4.4.4.4 to cross the link
between R1/R3. Here’s how to do this:
R1(config)#ip access-list extended ICMP_H1
R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4
First, I create an access-list that matches my traffic. Now we have to create a route-map:
R1(config)#route-map PBR_H1 permit 10
R1(config-route-map)#match ip address ICMP_H1
R1(config-route-map)#set ip next-hop 192.168.13.3
Whenever the traffic matches the access-list, we will change the next hop to
192.168.13.3 (R3).
Last but not least, let’s activate it:
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip policy route-map PBR_H1
Let’s see if it works, to see it in action I will enable a debug on R1:
R1#debug ip policy
Policy routing debugging is on
Now let’s send a ping from H1:
H1#ping 4.4.4.4 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
253 | P a g e
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 13/13/13 ms
The ping is working, let’s see what R1 thinks of it:
R1#
IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 100, FIB policy match
IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 100, PBR_H1 Counted
IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, g=192.168.13.3, len 100, FIB
policy routed
Above you can see that it has been policy routed towards 192.168.13.3. We can also
verify this by looking at the route-map:
R1#show route-map PBR_H1
route-map PBR_H1, permit, sequence 10
Match clauses:
ip address (access-lists): ICMP_H1
Set clauses:
ip next-hop 192.168.13.3
Nexthop tracking current: 0.0.0.0
192.168.13.3, fib_nh:0,oce:0,status:0
Policy routing matches: 1 packets, 114 bytes
Let’s try some traffic that doesn’t match our access-list. Telnet for example:
H1#telnet 4.4.4.4
Trying 4.4.4.4 ... Open
H1 is able to connect but it’s not policy routed:
R1#
IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy
rejected(no match) - normal forwarding
As you can see above, this telnet traffic is routed using the normal path.
There is one more thing I’d like to show you. With policy-based routing, there is a
difference between traffic that is going through the router and traffic that
is originated from the router.
The example above is for traffic that went through our router. What if we want to policy
route traffic that is originated from R1? We will have to use another command to activate
it. Let’s create another route-map:
254 | P a g e
R1(config)#ip access-list extended ICMP_R1
R1(config-ext-nacl)#permit icmp host 192.168.12.1 host 4.4.4.4
R1(config-ext-nacl)#permit icmp host 192.168.13.1 host 4.4.4.4
R1(config)#route-map PBR_R1 permit 10
R1(config-route-map)#match ip address ICMP_R1
R1(config-route-map)#set ip next-hop 192.168.13.3
The route-map above will redirect all traffic from R1 to 4.4.4.4 towards R3. To activate
this, we need to use another command:
R1(config)#ip local policy route-map PBR_R1
This time, we need to use the ip local policy command. Let’s test this:
R1#ping 4.4.4.4 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 19/19/19 ms
R1#
IP: s=192.168.12.1 (local), d=4.4.4.4, len 100, policy match
IP: route map PBR_R1, item 10, permit
IP: s=192.168.12.1 (local), d=4.4.4.4 (GigabitEthernet0/3), len 100, policy routed
IP: local to GigabitEthernet0/3 192.168.13.3
Great, our traffic from R1 is policy routed.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname H1
!
no ip routing
!
no ip cef
!
interface GigabitEthernet0/1
ip address 192.168.1.100 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end
hostname R1
!
ip cef
!
interface GigabitEthernet0/1
255 | P a g e
ip address 192.168.1.254 255.255.255.0
ip policy route-map PBR_H1
!
interface GigabitEthernet0/2
ip address 192.168.12.1 255.255.255.0
!
interface GigabitEthernet0/3
ip address 192.168.13.1 255.255.255.0
ip ospf cost 1000
!
router ospf 1
network 192.168.1.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0
!
ip local policy route-map PBR_R1
!
ip access-list extended ICMP_H1
permit icmp host 192.168.1.100 host 4.4.4.4
ip access-list extended ICMP_R1
permit icmp host 192.168.12.1 host 4.4.4.4
permit icmp host 192.168.13.1 host 4.4.4.4
!
route-map PBR_H1 permit 10
match ip address ICMP_H1
set ip next-hop 192.168.13.3
!
route-map PBR_R1 permit 10
match ip address ICMP_R1
set ip next-hop 192.168.13.3
!
end
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
network 192.168.24.0 0.0.0.255 area 0
!
end
hostname R3
!
ip cef
!
interface GigabitEthernet0/1
256 | P a g e
ip address 192.168.13.3 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 192.168.13.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
end
hostname R4
!
ip cef
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.24.4 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
network 4.4.4.4 0.0.0.0 area 0
network 192.168.24.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
!
line vty 0 4
login
transport input telnet
!
end
2. Conclusion
Policy-based routing allows us to overrule the global routing table for traffic that matches
our access-list. This can be a great way to redirect traffic for certain applications. To
activate PBR, there is a difference for traffic that is going through the router or that is
originated by the router:
Use the ip policy command under the interface for traffic that is going through
the router.
Use the ip policy local command globally for traffic that is originated by the
router.
257 | P a g e
1.2.f: Route filtering with any routing protocol
Distribute-list
How to Filter Prefixes with Distribute-list
Prefixes that are advertised by routing protocols like OSPF, EIGRP or RIP can be
filtered. One way of doing this is by using a distribute-list. In this lesson I’ll give you an
example of how to filter certain prefixes with a distribute-list. Filtering can
occur inbound or outbound. If you have an inbound route filter we will first check if the
network is permitted or not before we will accept it. Let’s take a look at a network
topology so I can give you a demonstration:
R1 and R2 are connected to each other and running EIGRP. On R2 I have added a
couple of loopback interfaces with prefixes that we will advertise in EIGRP. Here is the
configuration:
R1(config)#router eigrp 12
R1(config-router)#no auto-summary
R1(config-router)#network 192.168.12.0
R2(config)#router eigrp 12
258 | P a g e
R2(config-router)#no auto-summary
R2(config-router)#network 192.168.12.0
R2(config-router)#network 172.16.0.0 0.0.3.255
Above you can see that we advertise all prefixes in EIGRP.
R1#show ip route eigrp
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.0.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
D 172.16.1.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
D 172.16.2.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
D 172.16.3.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
If we look at the routing table of router R1 we can see all those networks on the
loopback interfaces as it should be. Now we’ll see if we can do some filtering.
R1(config)#router eigrp 12
R1(config-router)#distribute-list ?
<1-199> IP access list number
<1300-2699> IP expanded access list number
WORD Access-list name
gateway Filtering incoming updates based on gateway
prefix Filter prefixes in routing updates
route-map Filter prefixes based on the route-map
Go to the configuration of the EIGRP process and use the distribute-list command to
see your options. As you can see we can choose between an access-list, a prefix-list
or a route-map. Let’s start with the access-list. You are probably familiar with the
concept of access-lists if you studied CCNA.
R1(config-router)#distribute-list 1 ?
in Filter incoming routing updates
out Filter outgoing routing updates
If you specify an access-list number you can choose if this route filter has to
be inbound or outbound.
R1(config-router)#distribute-list 1 in ?
Async Async interface
BVI Bridge-Group Virtual Interface
CDMA-Ix CDMA Ix interface
CTunnel CTunnel interface
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
MFR Multilink Frame Relay bundle interface
Multilink Multilink-group interface
259 | P a g e
Null Null interface
Port-channel Ethernet Channel of interfaces
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-PPP Virtual PPP interface
Virtual-Template Virtual Template interface
Virtual-TokenRing Virtual TokenRing
<cr>
If you want you can choose the interface where to apply the inbound route filter to. If you
don’t specify an interface it will apply to all interfaces.
R1(config-router)#distribute-list 1 in FastEthernet 0/0
I’m going to apply it to the FastEthernet 0/0 interface since that’s the one where we
receive information from router R2 on.
R1(config)#access-list 1 deny 172.16.1.0 0.0.0.255
R1(config)#access-list 1 permit any
Let’s create an access-list that will filter 172.16.1.0 /24 and permit all the other networks.
R1#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is
resync: route configuration changed
You’ll see a message showing you that the route filter has changed.
R1#show ip route eigrp
172.16.0.0/24 is subnetted, 3 subnets
D 172.16.0.0 [90/156160] via 192.168.12.2, 00:06:26, FastEthernet0/0
D 172.16.2.0 [90/156160] via 192.168.12.2, 00:06:26, FastEthernet0/0
D 172.16.3.0 [90/156160] via 192.168.12.2, 00:06:26, FastEthernet0/0
R1#show access-lists
Standard IP access list 1
10 deny 172.16.1.0, wildcard bits 0.0.0.255 (2 matches)
20 permit any (3 matches)
You can see 172.16.1.0 /24 has been filtered from the routing table. The matches in the
access-list also tell us we have filtered this network. Using an access-list is the most
simple method of route filtering. There are two other options, let me show you:
R1(config-router)#distribute-list ?
<1-199> IP access list number
<1300-2699> IP expanded access list number
260 | P a g e
WORD Access-list name
gateway Filtering incoming updates based on gateway
prefix Filter prefixes in routing updates
route-map Filter prefixes based on the route-map
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router eigrp 12
distribute-list 1 in FastEthernet0/0
network 192.168.12.0
!
access-list 1 deny 172.16.1.0 0.0.0.255
access-list 1 permit any
!
end
hostname R2
!
interface Loopback0
ip address 172.16.0.1 255.255.255.0
!
interface Loopback1
ip address 172.16.1.1 255.255.255.0
!
interface Loopback2
ip address 172.16.2.1 255.255.255.0
!
interface Loopback3
ip address 172.16.3.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
router eigrp 12
network 172.16.0.0 0.0.3.255
network 192.168.12.0
!
end
Using an access-list is the simplest method of filtering. The two other options are prefix-
lists and route-maps. I’ll cover those two in another lesson.
Prefix-List
How to configure Prefix-List on Cisco Router
261 | P a g e
Prefix-lists can be used to filter prefixes and are far more powerful than simple access-
lists. Let’s say I want to filter all prefixes that fall within the 10.0.0.0 range and that have
a subnet mask between /24 and /28. Do you think you could do this with an access-list?
It will be difficult right…with a prefix-list this is very easy to do!
Most CCNP students find prefix-lists difficult to understand so in this lesson I’ll show you
how prefix-lists work by using them as route filters.
I will show you different scenarios and different filters. Here is the topology that we will
use:
Above you see two routers called “R1” and “R2”. On R2 we have a couple of loopback
interfaces with prefixes that we will advertise in EIGRP. I’m doing this so we have a
number of prefixes to play with. Here is the configuration:
R1(config)#router eigrp 12
R1(config-router)#no auto-summary
R1(config-router)#network 192.168.12.0
R2(config)#router eigrp 12
R2(config-router)#no auto-summary
R2(config-router)#network 192.168.12.0
R2(config-router)#network 172.16.0.0 0.0.3.255
EIGRP is configured so all networks are advertised.
R1#show ip route eigrp
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.0.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
D 172.16.1.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
D 172.16.2.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
D 172.16.3.0 [90/156160] via 192.168.12.2, 00:01:07, FastEthernet0/0
If we look at the routing table of R1 we can see all those networks on the loopback
interfaces as it should be. Now we’ll see if we can do some filtering. Let’s start with a
simple prefix-list that filters 172.16.1.0 /24 but permits everything else:
R1(config)#ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24
R1(config)#ip prefix-list FILTERTHIS seq 10 permit 0.0.0.0/0 le 32
262 | P a g e
By using the ip prefix-list command you can create prefix lists. As you can see it looks
a bit similar as my access-list but instead of typing wildcards we just specify the number
of bits. The first line denies 172.16.1.0/24 and the second line permits 0.0.0.0/0 (all
networks) if they have a subnet mask of /32 or smaller…in other words “everything”. This
line is the equivalent of “permit ip any any”.
Let’s enable it on R1 to see what the result is:
R1(config)#router eigrp 12
R1(config-router)#distribute-list prefix FILTERTHIS in
And we’ll enable the new prefix-list.
R1#show ip route eigrp
172.16.0.0/24 is subnetted, 3 subnets
D 172.16.0.0 [90/156160] via 192.168.12.2, 00:01:54, FastEthernet0/0
D 172.16.2.0 [90/156160] via 192.168.12.2, 00:01:54, FastEthernet0/0
D 172.16.3.0 [90/156160] via 192.168.12.2, 00:01:54, FastEthernet0/0
As you can see 172.16.1.0/24 has been filtered and all the other networks are
permitted.
The true power of the prefix list is in the ge (Greater than or Equal to) and le (less
than or equal to) operators. Let’s look at some examples:
R1(config)#ip prefix-list RENETEST permit 10.0.0.0/8 le 19
In this example I’m using the le operator. This prefix-list statement says that all networks
that fall within the 10.0.0.0/8 range AND that have a subnet mask of /19 or less are
permitted.
If I have a network with 10.0.0.0 /21 it will be denied by this prefix list. It falls within the
10.0.0.0 /8 range, but it has a subnet mask of /21. I’m using the le operator which says
that the subnet mask should be /19 or smaller.
Let’s say I have another network with 10.0.0.0 /17 then it will be permitted by this prefix-
list. It falls within the 10.0.0.0/8 range and has a subnet mask that is smaller than /19.
Are you following me here? Let me give you an example on our routers:
R2(config)#interface loopback 10
R2(config-if)#ip address 10.1.1.1 255.255.0.0
R2(config-if)#interface loopback 11
R2(config-if)#ip address 10.2.2.2 255.255.128.0
R2(config-if)#interface loopback 12
R2(config-if)#ip address 10.3.3.3 255.255.192.0
R2(config-if)#interface loopback 13
R2(config-if)#ip address 10.4.4.4 255.255.224.0
R2(config-if)#interface loopback 14
R2(config-if)#ip address 10.5.5.5 255.255.240.0
R2(config-if)#interface loopback 15
R2(config-if)#ip address 10.6.6.6 255.255.248.0
263 | P a g e
First we’ll add a couple of loopback interfaces on R2. If you look closely you can see I’m
using different subnet masks.
R2(config)#router eigrp 12
R2(config-router)#network 10.0.0.0
And I’ll advertise them in EIGRP.
R1(config)#router eigrp 12
R1(config-router)#no distribute-list prefix FILTERTHIS in
Let’s get rid of the prefix-list on R1…
R1#show ip route eigrp
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.0.0 [90/156160] via 192.168.12.2, 00:06:11, FastEthernet0/0
D 172.16.1.0 [90/156160] via 192.168.12.2, 00:00:35, FastEthernet0/0
D 172.16.2.0 [90/156160] via 192.168.12.2, 00:06:11, FastEthernet0/0
D 172.16.3.0 [90/156160] via 192.168.12.2, 00:06:11, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 6 subnets, 6 masks
D 10.2.0.0/17 [90/156160] via 192.168.12.2, 00:02:22, FastEthernet0/0
D 10.3.0.0/18 [90/156160] via 192.168.12.2, 01:14:57, FastEthernet0/0
D 10.1.0.0/16 [90/156160] via 192.168.12.2, 00:06:11, FastEthernet0/0
D 10.6.0.0/21 [90/156160] via 192.168.12.2, 01:02:35, FastEthernet0/0
D 10.4.0.0/19 [90/156160] via 192.168.12.2, 01:14:46, FastEthernet0/0
D 10.5.0.0/20 [90/156160] via 192.168.12.2, 01:02:35, FastEthernet0/0
Now we see all the networks that fall within the 172.16.0.0/16 and 10.0.0.0/8 range.
Time to enable that prefix-list I just created.
R1(config)#router eigrp 12
R1(config-router)#distribute-list prefix RENETEST in
This is how we activate it, and this is what we end up with:
R1#show ip route eigrp
10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
D 10.2.0.0/17 [90/156160] via 192.168.12.2, 00:03:27, FastEthernet0/0
D 10.3.0.0/18 [90/156160] via 192.168.12.2, 01:16:03, FastEthernet0/0
D 10.1.0.0/16 [90/156160] via 192.168.12.2, 00:07:16, FastEthernet0/0
D 10.4.0.0/19 [90/156160] via 192.168.12.2, 01:15:51, FastEthernet0/0
Only four entries remain…why?
R1#show ip prefix-list RENETEST
264 | P a g e
ip prefix-list RENETEST: 1 entries
seq 5 permit 10.0.0.0/8 le 19
Here’s the prefix-list again, let me explain what happened:
Everything in the 172.16.0.0/16 range is filtered because it’s not permitted in our
prefix-list.
10.2.0.0/17 is permitted because it’s in the 10.0.0.0/8 range and has a /17 subnet
mask.
10.3.0.0/18 is permitted because it’s in the 10.0.0.0/8 range and has a /18 subnet
mask.
10.1.0.0/16 is permitted because it’s in the 10.0.0.0/8 range and has a /16 subnet
mask.
10.4.0.0/16 is permitted because it’s in the 10.0.0.0/8 range and has a /19 subnet
mask.
10.5.0.0/20 is filtered, it’s in the 10.0.0.0/8 range but has a /20 subnet mask.
10.6.0.0/21 is filtered, it’s in the 10.0.0.0/8 range but has a /21 subnet mask.
Does this make sense? Let’s walk through a couple more examples together!
R1(config)#ip prefix-list RENETEST2 permit 10.0.0.0/8 ge 20
This time I’m using the ge operator. Ge 20 means that the network needs to have a
subnet mask of /20 or larger in order to be permitted. 10.0.0.0 /8 is the range we are
going to check.
A network with 10.55.55.0 /25 will be permitted because it falls within the 10.0.0.0 /8
range and has a subnet mask of /25 which is larger than /20.
What about 10.60.0.0 /19? It falls within the 10.0.0.0 /8 range, but it is not permitted
because it has a subnet mask of /19…our ge operator says it should be /20 or larger.
Hmm interesting…what about 192.168.12.0 /25? The subnet mask of /25 matches our
ge operator but it doesn’t fall within the 10.0.0.0 /8 range, so it’s not permitted. Let’s see
what happens if I activate this prefix-list on R1:
R1(config)#router eigrp 12
R1(config-router)#no distribute-list prefix RENETEST in
R1(config-router)#distribute-list prefix RENETEST2 in
First disable the old prefix-list and secondly enable the new one.
R1#show ip route eigrp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.6.0.0/21 [90/156160] via 192.168.12.2, 00:01:03, FastEthernet0/0
D 10.5.0.0/20 [90/156160] via 192.168.12.2, 00:01:03, FastEthernet0/0
Only two entries remain…why?
265 | P a g e
Everything in the 172.16.0.0/16 range is filtered because it’s not permitted in our
prefix-list.
All networks in the 10.0.0.0/8 range with a subnet mask that is smaller than 20
are filtered.
All networks in the 10.0.0.0/8 range with a subnet mask that is 20 or larger are
permitted, that means only 10.6.0.0/21 and 10.5.0.0/20
R1(config)#ip prefix-list RENETEST3 permit 10.0.0.0/8 ge 16 le 18 We can also
combine the ge and le operators. Look at my prefix-list above. It’s permitting all networks
that fall within the 10.0.0.0 /8 range and that have a subnet mask of /16, /18 and
everything in between.
10.22.0.0 /18 will be permitted because it falls within the 10.0.0.0 /8 range and has a
subnet mask of /18.
10.55.0.0 / 26 will be denied. It falls within the 10.0.0.0 /8 range but the subnet mask
is /26 which doesn’t match my ge or le operators.
10.4.4.0 /14 will be denied. It falls within the 10.0.0.0 /8 range but the subnet mask is /14
which doesn’t match my ge or le operators.
192.168.12.0 /18 will be denied. It matches my ge and le operators, but it doesn’t fall
within the 10.0.0.0 /8 range.
Let’s activate it on R1 and see what the result is:
R1(config)#router eigrp 12
R1(config-router)#no distribute-list prefix RENETEST2 in
R1(config-router)#distribute-list prefix RENETEST3 in
First we’ll remove the old prefix-list and activate the new one…
R1#show ip route eigrp
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
D 10.2.0.0/17 [90/156160] via 192.168.12.2, 00:00:36, FastEthernet0/0
D 10.3.0.0/18 [90/156160] via 192.168.12.2, 00:00:36, FastEthernet0/0
D 10.1.0.0/16 [90/156160] via 192.168.12.2, 00:00:36, FastEthernet0/0
And here’s the result. What happened?
Everything in the 172.16.0.0/16 range is filtered because it’s not permitted in our
prefix-list.
Only networks in the 10.0.0.0/8 range with a subnet mask of /16, /17 or /18 are
permitted, everything else is filtered.
Do you see how powerful these prefix-lists are? With a single line I can create very
flexible permit or deny statements! Let me show you a couple more examples of prefix-
lists:
R1(config)#ip prefix-list CLASSB permit 128.0.0.0/2 ge 17
266 | P a g e
This one is interesting…let’s break it down in pieces. It’s permitting 128.0.0.0 /2 and the
ge operator says the subnet mask should be /17 or larger. 128.0.0.0 is the start of the
class B range and the /2 says that we have to check the first two bits. 128.0.0.0 /2
covers the entire class B network range. This prefix-list will permit any subnet in the
class B network range that has a subnet mask of /17 or larger.
R1(config)#ip prefix-list ALL permit 0.0.0.0/0 le 32
I showed you this one before…this one says permit 0.0.0.0 /0 which covers the entire
network range. We have a le 32 operator which says that the subnet mask should be /32
or smaller. What does this mean? It means its matching ALL networks!
R1(config)#ip prefix-list DEFAULTROUTE permit 0.0.0.0/0
We don’t have any ge or le operators and this prefix-list shows 0.0.0.0 /0. It’s only
permitting the default route…
R1(config)#ip prefix-list CLASSA permit 0.0.0.0/1 le 27
Last one…promise! The network range to check is 0.0.0.0 and we have /1 which means
we are only checking the first bit. This effectively matches the whole class A range.
We have a le operator with 27 which tells us the subnet mask should be /27 or smaller.
This prefix-list matches all subnets within the class A range that has a subnet mask of
/27 or smaller.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R2
!
interface Loopback0
ip address 172.16.0.1 255.255.255.0
!
interface Loopback1
ip address 172.16.1.1 255.255.255.0
!
interface Loopback2
ip address 172.16.2.1 255.255.255.0
!
interface Loopback3
ip address 172.16.3.1 255.255.255.0
!
interface Loopback10
ip address 10.1.1.1 255.255.0.0
!
interface Loopback11
ip address 10.2.2.2 255.255.128.0
267 | P a g e
!
interface Loopback12
ip address 10.3.3.3 255.255.192.0
!
interface Loopback13
ip address 10.4.4.4 255.255.224.0
!
interface Loopback14
ip address 10.5.5.5 255.255.240.0
!
interface Loopback15
ip address 10.6.6.6 255.255.248.0
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router eigrp 12
network 10.0.0.0
network 172.16.0.0 0.0.3.255
network 192.168.12.0
!
end
hostname R1
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router eigrp 12
distribute-list prefix RENETEST3 in
network 192.168.12.0
!
ip prefix-list ALL seq 5 permit 0.0.0.0/0 le 32
!
ip prefix-list CLASSA seq 5 permit 0.0.0.0/1 le 27
!
ip prefix-list CLASSB seq 5 permit 128.0.0.0/2 ge 17
!
ip prefix-list DEFAULTROUTE seq 5 permit 0.0.0.0/0
!
ip prefix-list FILTERTHIS seq 5 deny 172.16.1.0/24
ip prefix-list FILTERTHIS seq 10 permit 0.0.0.0/0 le 32
!
ip prefix-list RENETEST seq 5 permit 10.0.0.0/8 le 19
!
ip prefix-list RENETEST2 seq 5 permit 10.0.0.0/8 ge 20
!
ip prefix-list RENETEST3 seq 5 permit 10.0.0.0/8 ge 16 le 18
!
end
268 | P a g e
I hope you now have a better understanding of prefix-lists. Don’t just read this lesson
and forget about it, it’s best to boot up your own routers and configure some prefix-lists.
If you have any more questions please leave a comment!
Route-Map Filtering
EIGRP Route-Map Filtering
EIGRP supports filtering with access-lists and prefix-lists, but you can also use route-
maps. In this lesson I’ll show you how to use a route-map to filter in- and outbound route
advertisements. We will use the following topology for this:
We only need two routers for this demonstration. R1 has some networks that it will
advertise to R2 through EIGRP. Here’s what the routing table of R2 looks like:
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/409600] via 192.168.12.1, 00:00:45, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 4 subnets, 4 masks
D 172.16.0.0/24 [90/409600] via 192.168.12.1, 00:00:14, FastEthernet0/0
D 172.16.1.0/25 [90/409600] via 192.168.12.1, 00:00:08, FastEthernet0/0
D 172.16.2.0/26 [90/409600] via 192.168.12.1, 00:00:14, FastEthernet0/0
D 172.16.3.0/27 [90/409600] via 192.168.12.1, 00:00:13, FastEthernet0/0
D 192.168.1.0/24 [90/409600] via 192.168.12.1, 00:00:13, FastEthernet0/0
Above you see that R2 has learned all networks behind R1. Let’s start with something
simple…let’s say we want to configure R1 so that 192.168.1.0 /24 won’t be advertised to
R2. Here’s how we do this:
R1(config)#router eigrp 1
R1(config-router)#distribute-list ?
<1-199> IP access list number
<1300-2699> IP expanded access list number
WORD Access-list name
gateway Filtering incoming updates based on gateway
prefix Filter prefixes in routing updates
route-map Filter prefixes based on the route-map
We have to use the distribute-list command under the EIGRP process but as you can
see it supports a route-map. Let’s use that and give it a name:
R1(config-router)#distribute-list route-map FILTER_OUT ?
269 | P a g e
in Filter incoming routing updates
out Filter outgoing routing updates
I’ll call my route-map “FILTER_OUT” and we will choose outgoing updates:
R1(config-router)#distribute-list route-map FILTER_OUT out
Now we can create the route-map:
R1(config)#route-map FILTER_OUT ?
<0-65535> Sequence to insert to/delete from existing route-map entry
deny Route map denies set operations
permit Route map permits set operations
<cr>
We will start with a deny statement:
R1(config)#route-map FILTER_OUT deny 10
The route-map will require a match statement. There are a lot of things you can select
for the match statement:
R1(config-route-map)#match ?
as-path Match BGP AS path list
clns CLNS information
community Match BGP community list
extcommunity Match BGP/VPN extended community list
interface Match first hop interface of route
ip IP specific information
ipv6 IPv6 specific information
length Packet length
local-preference Local preference for route
metric Match metric of route
mpls-label Match routes which have MPLS labels
nlri BGP NLRI type
policy-list Match IP policy list
route-type Match route-type of route
source-protocol Match source-protocol of route
tag Match tag of route
Not all of these options are possible when you use the route-map for filtering. Let’s start
with a simple example, let’s look at the IP options:
R1(config-route-map)#match ip address ?
<1-199> IP access-list number
<1300-2699> IP access-list number (expanded range)
WORD IP access-list name
270 | P a g e
prefix-list Match entries of prefix-lists
<cr>
Here we can use an access-list or prefix-list. Let’s try the access-list:
R1(config-route-map)#match ip address NET_192
Don’t forget to create the actual access-list:
R1(config)#ip access-list standard NET_192
R1(config-std-nacl)#permit 192.168.1.0 0.0.0.255
The route-map is almost complete. We have a deny statement that matches everything
in our access-list. There’s one problem though, our route-map doesn’t have any permit
statements. If we don’t add one then everything will be blocked. Let’s add it:
R1(config)#route-map FILTER_OUT permit 20
R1(config-route-map)#exit
This permit statement doesn’t require any matches. Let me show you an overview of our
configuration so far:
R1#show running-config | section eigrp
router eigrp 1
network 0.0.0.0
distribute-list route-map FILTER_OUT out FastEthernet0/0
no auto-summary
R1#show route-map
route-map FILTER_OUT, deny, sequence 10
Match clauses:
ip address (access-lists): NET_192
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map FILTER_OUT, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Above you can see that the route-map is attached to the distribute-list command in
EIGRP. Our route-map will deny everything that matches our access-list while
everything else is permitted. Let’s take a look at R2 to see if this works:
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/409600] via 192.168.12.1, 00:01:01, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 4 subnets, 4 masks
271 | P a g e
D 172.16.0.0/24 [90/409600] via 192.168.12.1, 00:01:01, FastEthernet0/0
D 172.16.1.0/25 [90/409600] via 192.168.12.1, 00:01:01, FastEthernet0/0
D 172.16.2.0/26 [90/409600] via 192.168.12.1, 00:01:01, FastEthernet0/0
D 172.16.3.0/27 [90/409600] via 192.168.12.1, 00:01:01, FastEthernet0/0
That’s looking good, everything is in the routing table except 192.168.1.0 /24. Now you
might be thinking that this was a lot of work just to filter one network…
You are right, this was a lot of work. The power of using a route-map for filtering is that
we can use multiple statements and use a mix of filtering techniques.
For example let’s say that we also want to deny all prefixes in the 172.16.0.0 /16 range
that use a /26 subnet or smaller subnet. We can do this by creating a prefix-list and
attaching it to our route-map:
R1(config)#route-map FILTER_OUT deny 20
R1(config-route-map)#match ip address prefix-list SMALL_PREFIXES
R1(config)#ip prefix-list SMALL_PREFIXES permit 172.16.0.0/16 ge 26
R1(config)#route-map FILTER_OUT permit 30
Above I changed route-map entry 20 to a deny statement that checks for our prefix-list
called “SMALL_PREFIXES”. The last permit statement (sequence number 30) doesn’t
have any match statements and is required to permit all other route advertisements.
Here’s what the complete route-map looks like:
R1#show route-map
route-map FILTER_OUT, deny, sequence 10
Match clauses:
ip address (access-lists): NET_192
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map FILTER_OUT, deny, sequence 20
Match clauses:
ip address prefix-lists: SMALL_PREFIXES
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map FILTER_OUT, permit, sequence 30
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Our first sequence number (10) is used to filter with an access-list, the second one (20)
uses our prefix-list and the last one (30) permits everything else. Let’s check the result of
R2:
R2#show ip route eigrp
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/409600] via 192.168.12.1, 00:38:18, FastEthernet0/0
272 | P a g e
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/24 [90/409600] via 192.168.12.1, 00:38:18, FastEthernet0/0
D 172.16.1.0/25 [90/409600] via 192.168.12.1, 00:38:18, FastEthernet0/0
Great, as you can see network 172.16.2.0 /26 and 172.16.3.0 /27 are gone fishing, they
have been filtered because of the prefix-list. I think this example should give you a good
idea about the flexibility of a route-map, you can use a variety of filtering techniques.
Let’s try one more thing…we can also use a route-map for inbound filtering. Let’s filter
network 1.1.1.0 /24 on R2, to keep things interesting I’ll use the route-map in a different
way:
R2(config)#ip access-list standard NET_1
R2(config-std-nacl)#deny 1.1.1.0 0.0.0.255
R2(config-std-nacl)#permit any
First we create an access-list. This access-list denies 1.1.1.0 /24 and permits everything
else. Now we create the route-map:
R2(config)#route-map FILTER_IN permit 10
R2(config-route-map)#match ip address NET_1
This route-map has only one permit statement. Everything that matches our access-list
will be permitted. Let’s attach it to EIGRP:
R2(config)#router eigrp 1
R2(config-router)#distribute-list route-map FILTER_IN in
Now we can check the routing table of R2:
R2#show ip route eigrp
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/24 [90/409600] via 192.168.12.1, 00:56:08, FastEthernet0/0
D 172.16.1.0/25 [90/409600] via 192.168.12.1, 00:56:08, FastEthernet0/0
As you can see 1.1.1.0 /24 is not in the routing table anymore.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface Loopback1
ip address 172.16.0.1 255.255.255.0
!
273 | P a g e
interface Loopback2
ip address 172.16.1.1 255.255.255.128
!
interface Loopback3
ip address 172.16.2.1 255.255.255.192
!
interface Loopback4
ip address 172.16.3.1 255.255.255.224
!
interface Loopback5
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router eigrp 1
distribute-list route-map FILTER_OUT out
network 1.0.0.0
network 172.16.0.0 0.0.3.255
network 192.168.1.0
network 192.168.12.0
!
ip access-list standard NET_192
permit 192.168.1.0 0.0.0.255
!
ip prefix-list SMALL_PREFIXES seq 5 permit 172.16.0.0/16 ge 26
!
route-map FILTER_OUT deny 10
match ip address NET_192
!
route-map FILTER_OUT deny 20
match ip address prefix-list SMALL_PREFIXES
!
route-map FILTER_OUT permit 30
!
end
hostname R2
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
router eigrp 1
distribute-list route-map FILTER_IN in
network 192.168.12.0
!
ip access-list standard NET_1
deny 1.1.1.0 0.0.0.255
permit any
!
route-map FILTER_IN permit 10
match ip address NET_1
!
end
274 | P a g e
That’s all there is to it. I hope these examples have been useful to understand EIGRP
filtering with a route-map. If you have any questions, feel free to leave a comment.
OSPF Distribute-List Filtering
OSPF supports a number of methods to filter routes but it is more restrictive compared
to distance vector routing protocols like RIP or EIGRP.
As a link-state routing protocol OSPF uses LSAs to build its LSDB (Link State
Database). Routers will run the SPF algorithm to find the shortest path to each
destination, the topology in the LSDB has to be the same on all routers or SPF will fail.
However OSPF routers only know what the topology looks like within the area. They
don’t know what the topology looks like for other areas. For inter-area routes OSPF only
knows the prefix and the ABR (Area Border Router) to reach it.
You could say that OSPF acts like a distance vector routing protocol for inter-area
routes. It only knows the metric (distance) and the ABR to get there (vector).
Unlike RIP or EIGRP, OSPF doesn’t advertise routes but LSAs so if we want to filter
something we’ll have to filter the advertisement of LSAs.
Since the LSDB within the area has to be the same we can’t filter LSAs within the
area, we can however filter routes from entering the routing table. Filtering LSAs
between areas on an ABR or ASBR is no problem.
In this lesson I’ll show you how we can filter routes from entering the routing table within
the area. In other lessons I will explain how to filter type 3 LSAs and type 5 LSAs.
Here’s the topology I will use:
Nothing fancy, we have three routers running OSPF in the same area. R1 has a
loopback interface that is advertised in OSPF, we’ll see if we can filter this network.
1. Configuration
Here’s the OSPF configuration:
R1#show running-config | section ospf
router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0
R2#show running-config | section ospf
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
275 | P a g e
network 192.168.23.0 0.0.0.255 area 0
R3#show running-config | section ospf
router ospf 1
network 192.168.23.0 0.0.0.255 area 0
Let’s verify if R2 and R3 have learned 1.1.1.1 /32:
R2#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 192.168.12.1, 00:00:27, FastEthernet0/0
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/3] via 192.168.23.2, 00:00:28, FastEthernet0/0
O 192.168.12.0/24 [110/2] via 192.168.23.2, 00:00:28, FastEthernet0/0
Let’s see if we can get rid of this network on R3:
R3(config)#router ospf 1
R3(config-router)#distribute-list ?
<1-199> IP access list number
<1300-2699> IP expanded access list number
WORD Access-list name
gateway Filtering incoming updates based on gateway
prefix Filter prefixes in routing updates
route-map Filter prefixes based on the route-map
We can use a distribute-list for this, to keep it simple I’ll combine it with an access-list;
R3(config-router)#distribute-list R1_L0 in
When we want to remove something from the routing table we have to apply it inbound.
The outbound distribute-list is used for LSA type 5 filtering.
Let’s create that access-list:
R3(config)#ip access-list standard R1_L0
R3(config-std-nacl)#deny host 1.1.1.1
R3(config-std-nacl)#permit any
It will now be gone from the routing table:
R3#show ip route 1.1.1.1
% Network not in table
As you can see it’s gone…it’s still in the LSDB though:
276 | P a g e
R3#show ip ospf database router 192.168.12.1
OSPF Router with ID (192.168.23.3) (Process ID 1)
Router Link States (Area 0)
LS age: 664
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 192.168.12.1
Advertising Router: 192.168.12.1
LS Seq Number: 80000003
Checksum: 0xF14F
Length: 48
Number of Links: 2
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.1.1
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Transit Network
(Link ID) Designated Router address: 192.168.12.2
(Link Data) Router Interface address: 192.168.12.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
You have to be very careful if you use this command. If you are not careful you can end
up in a scenario where you blackhole some traffic. For example, let’s see what happens
when I filter this network on R2 instead of R3. Let’s remove the distribute-list on R3:
R3(config)#router ospf 1
R3(config-router)#no distribute-list R1_L0 in
Now I will add it to R2:
R2(config)#ip access-list standard R1_L0
R2(config-std-nacl)#deny host 1.1.1.1
R2(config-std-nacl)#permit any
R2(config)#router ospf 1
R2(config-router)#distribute-list R1_L0 in
R2 now no longer has it in its routing table:
R2#show ip route 1.1.1.1
% Network not in table
277 | P a g e
However the LSA is still flooded to R3:
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/3] via 192.168.23.2, 00:02:45, FastEthernet0/0
O 192.168.12.0/24 [110/2] via 192.168.23.2, 00:02:45, FastEthernet0/0
Once R3 tries to reach this network we will have a problem:
R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
R3 will forward these packets to R2 which drops it.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 192.168.12.0 0.0.0.255 area 0
!
end
hostname R2
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet1/0
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 0
278 | P a g e
distribute-list R1_L0 in
!
ip access-list standard R1_L0
deny 1.1.1.1
permit any
!
end
hostname R3
!
ip cef
!
interface FastEthernet0/0
ip address 192.168.23.3 255.255.255.0
!
router ospf 1
network 192.168.23.0 0.0.0.255 area 0
!
ip access-list standard R1_L0
deny 1.1.1.1
permit any
!
end
That’s all there is to it, you have now seen how you can filter routes within your OSPF
area. Make sure you also check my other two lessons on OSPF filtering:
OSPF LSA type 3 filtering
OSPF LSA type 5 filtering
OSPF ABR Type 3 LSA Filtering on Cisco IOS
OSPF uses LSA type 3 for inter-area prefixes and if you want, you can filter these
between OSPF areas. Since you can only filter between areas you’ll have to configure
this on the ABR. Filtering is possible inbound or outbound an area by using the
area filter-list command.
In this lesson I will demonstrate how you can use this command to filter LSA type 3
between different areas. This is the topology that I will be using:
279 | P a g e
R1,R2 and R3 are located in their corresponding area number and have a loopback 0
interface each. The prefix on this loopback will be advertised in OSPF. In the middle you
can see which is the ABR for area 1,2 and 3. We’ll create some filter on R4 to
demonstrate the area filter-list command. Let me show you the OSPF configuration first:
1. OSPF Area Configuration
I will show you all the network commands that I used so you can replicate this if you
want. R1,R2 and R3 will be in their own area and R4 is the ABR:
R1(config)#router ospf 1
R1(config-router)#network 1.1.1.1 0.0.0.0 area 1
R1(config-router)#network 192.168.14.0 0.0.0.255 area 1
R2(config)#router ospf 1
R2(config-router)#network 2.2.2.2 0.0.0.0 area 2
R2(config-router)#network 192.168.24.0 0.0.0.255 area 2
R3(config)#router ospf 1
R3(config-router)#network 3.3.3.3 0.0.0.0 area 3
R3(config-router)#network 192.168.34.0 0.0.0.255 area 3
R4(config)#router ospf 1
R4(config-router)#network 4.4.4.4 0.0.0.0 area 0
R4(config-router)#network 192.168.14.0 0.0.0.255 area 1
R4(config-router)#network 192.168.24.0 0.0.0.255 area 2
R4(config-router)#network 192.168.34.0 0.0.0.255 area 3
Before we continue it’s best to verify that we have working OSPF neighbor adjacencies:
R4#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/BDR 00:00:33 192.168.14.1 FastEthernet0/0
2.2.2.2 1 FULL/BDR 00:00:39 192.168.24.2 FastEthernet0/1
3.3.3.3 1 FULL/BDR 00:00:39 192.168.34.3 FastEthernet1/0
The ABR has 3 working OSPF neighbor adjacencies. Now it’s time to create some
filters. We’ll start with inbound filtering.
280 | P a g e
2. Inbound Area LSA Type 3 filtering
I will start by filtering some prefixes that are headed towards area 3. The inbound filter
will filter prefixes from all areas that are sent to 1 area. First we’ll take a look at the
routing table of R3 in area 3:
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/3] via 192.168.34.4, 00:03:50, FastEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
O IA 2.2.2.2 [110/3] via 192.168.34.4, 00:03:50, FastEthernet0/0
O IA 192.168.14.0/24 [110/2] via 192.168.34.4, 00:03:50, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/2] via 192.168.34.4, 00:03:50, FastEthernet0/0
O IA 192.168.24.0/24 [110/2] via 192.168.34.4, 00:03:50, FastEthernet0/0
All prefixes that R3 has learned are inter-area prefixes (LSA Type 3). Let’s filter
2.2.2.2 /32 from entering area 3. First we’ll create a prefix-list:
R4(config)#ip prefix-list INTO-AREA3 deny 2.2.2.2/32
R4(config)#ip prefix-list INTO-AREA3 permit 0.0.0.0/0 le 32
This prefix-list will deny 2.2.2.2 /32 and allow all other prefixes. Now we have to apply it
to the area:
R4(config)#router ospf 1
R4(config-router)#area 3 filter-list prefix INTO-AREA3 in
If you want you can verify that the area filter is active with the show ip ospf command:
R4#show ip ospf 1 | begin Area 3
Area 3
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm last executed 00:01:50.060 ago
SPF algorithm executed 3 times
Area ranges are
Area-filter INTO-AREA3 in
Number of LSA 5. Checksum Sum 0x03C737
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
Now take a look at the routing table of R3 again:
281 | P a g e
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/3] via 192.168.34.4, 00:07:19, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/3] via 192.168.34.4, 00:07:19, FastEthernet0/0
O IA 192.168.14.0/24 [110/2] via 192.168.34.4, 00:07:19, FastEthernet0/0
O IA 192.168.24.0/24 [110/2] via 192.168.34.4, 00:07:19, FastEthernet0/0
Prefix 2.2.2.2 /32 is gone from the routing table as it has been filtered by the ABR (R4).
The nice thing about inbound filtering is that it doesn’t matter from which area the prefix
came, everything that goes into area 3 will hit the prefix-list and will be filtered. I can
demonstrate this to you by filtering something else, for example the two prefixes
192.168.14.0 /24 (area 1) and 192.168.24.0 /24 (area 2). Let’s change our prefix-list:
R4(config)#ip prefix-list INTO-AREA3 seq 6 deny 192.168.14.0/24
R4(config)#ip prefix-list INTO-AREA3 seq 7 deny 192.168.24.0/24
Now take a look again at the routing table of R3:
R3#show ip route ospf
1.0.0.0/32 is subnetted, 1 subnets
O IA 1.1.1.1 [110/3] via 192.168.34.4, 00:01:22, FastEthernet0/0
4.0.0.0/32 is subnetted, 1 subnets
O IA 4.4.4.4 [110/3] via 192.168.34.4, 00:01:22, FastEthernet0/0
The 192.168.14.0 /24 and 192.168.24.0 /24 prefixes are now gone from the routing
table. It doesn’t matter from which area they come from…
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.14.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 192.168.14.0 0.0.0.255 area 1
!
end
hostname R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
282 | P a g e
interface FastEthernet0/0
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 2
network 192.168.24.0 0.0.0.255 area 2
!
end
hostname R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 3
network 192.168.34.0 0.0.0.255 area 3
!
end
hostname R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.14.4 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.24.4 255.255.255.0
!
interface FastEthernet1/0
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
area 3 filter-list prefix INTO-AREA3 in
network 4.4.4.4 0.0.0.0 area 0
network 192.168.14.0 0.0.0.255 area 1
network 192.168.24.0 0.0.0.255 area 2
network 192.168.34.0 0.0.0.255 area 3
!
end
Now you know how inbound filtering works, let’s take a look at outbound filtering.
3. Outbound Area LSA Type 3 filtering
The outbound filter lets us filter a prefix from 1 area to all other areas. Let’s see if we can
filter 3.3.3.3 /32 so that R1 and R2 won’t have it in their routing table anymore. First we’ll
verify if they have learned about this prefix:
283 | P a g e
R1#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 3, type inter area
Last update from 192.168.14.4 on FastEthernet0/0, 00:03:07 ago
Routing Descriptor Blocks:
* 192.168.14.4, from 4.4.4.4, 00:03:07 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
R2#show ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 3, type inter area
Last update from 192.168.24.4 on FastEthernet0/0, 00:03:23 ago
Routing Descriptor Blocks:
* 192.168.24.4, from 4.4.4.4, 00:03:23 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
R1 and R2 both know about the loopback interface of R3. Let’s create a prefix-list that
matches 3.3.3.3 /32:
R4(config)#ip prefix-list OUT-AREA3 deny 3.3.3.3/32
R4(config)#ip prefix-list OUT-AREA3 permit 0.0.0.0/0 le 32
We’ll deny 3.3.3.3 /32 and permit all other prefixes. Now activate it for area 3:
R4(config)#router ospf 1
R4(config-router)#area 3 filter-list prefix OUT-AREA3 out
This will ensure that all other areas won’t learn about 3.3.3.3 /32 once it leaves area 3.
R1 and R2 won’t know about this network anymore…
R1#show ip route 3.3.3.3
% Network not in table
R2#show ip route 3.3.3.3
% Network not in table
So basically, this is how the area filter-list works:
The inbound area filter-list will filter prefixes from all areas that are sent to 1
area.
The outbound area filter-list will filter prefixes from 1 area sent to all other
areas.
Want to take a look for yourself? Here you will find the startup configuration of each
device.
284 | P a g e
hostname R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.14.1 255.255.255.0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 192.168.14.0 0.0.0.255 area 1
!
end
hostname R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.24.2 255.255.255.0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 2
network 192.168.24.0 0.0.0.255 area 2
!
end
hostname R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.34.3 255.255.255.0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 3
network 192.168.34.0 0.0.0.255 area 3
!
end
hostname R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.14.4 255.255.255.0
!
interface FastEthernet0/1
ip address 192.168.24.4 255.255.255.0
285 | P a g e
!
interface FastEthernet1/0
ip address 192.168.34.4 255.255.255.0
!
router ospf 1
area 3 filter-list prefix INTO-AREA3 in
area 3 filter-list prefix OUT-AREA3 out
network 4.4.4.4 0.0.0.0 area 0
network 192.168.14.0 0.0.0.255 area 1
network 192.168.24.0 0.0.0.255 area 2
network 192.168.34.0 0.0.0.255 area 3
!
end
I hope this has been useful for you to understand OSPF’s capability to filter LSA type 3
prefixes. If you have any questions feel free to leave a comment.
OSPF LSA Type 5 Filtering on Cisco IOS
In previous lessons I explained how you can filter routes within the OSPF area and how
you can filter type 3 LSAs. This time we’ll take a look how you can filter type 5 LSAs
using three different methods.
Here’s the topology we will use for this:`
Above we have three routers in two different areas. R1 has some loopback interfaces
that we will redistribute into OSPF. We’ll use these to play with some of the filtering
techniques.
1. Configuration
Here’s the OSPF configuration of all routers:
R1#show running-config | section ospf
router ospf 1
redistribute connected subnets
network 192.168.12.0 0.0.0.255 area 0
R2#show running-config | section ospf
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
286 | P a g e
network 192.168.23.0 0.0.0.255 area 1
R3#show running-config | section ospf
router ospf 1
network 192.168.23.0 0.0.0.255 area 1
R1 is using the redistribute connected subnets command to get the networks on the
loopback interfaces in OSPF. Let’s see if R2 and R3 have these networks in their routing
table:
R2#show ip route ospf
172.16.0.0/32 is subnetted, 4 subnets
O E2 172.16.0.1 [110/20] via 192.168.12.1, 00:00:03, FastEthernet0/0
O E2 172.16.1.1 [110/20] via 192.168.12.1, 00:00:03, FastEthernet0/0
O E2 172.16.2.1 [110/20] via 192.168.12.1, 00:00:03, FastEthernet0/0
O E2 172.16.3.1 [110/20] via 192.168.12.1, 00:00:03, FastEthernet0/0
R3#show ip route ospf
172.16.0.0/32 is subnetted, 4 subnets
O E2 172.16.0.1 [110/20] via 192.168.23.2, 00:00:07, FastEthernet0/0
O E2 172.16.1.1 [110/20] via 192.168.23.2, 00:00:07, FastEthernet0/0
O E2 172.16.2.1 [110/20] via 192.168.23.2, 00:00:07, FastEthernet0/0
O E2 172.16.3.1 [110/20] via 192.168.23.2, 00:00:07, FastEthernet0/0
O IA 192.168.12.0/24 [110/2] via 192.168.23.2, 00:04:25, FastEthernet0/0
Everything is there. Now let’s see if we can filter these…
1.1. Distribute-list Filtering
The first method is the distribute-list. We can use this on the ASBR to filter certain
networks from entering the area. Let’s configure one to get rid of 172.16.0.1 /32:
R1(config)#ip access-list standard R1_L0
R1(config-std-nacl)#deny host 172.16.0.1
R1(config-std-nacl)#permit any
!
R1(config)#router ospf 1
R1(config-router)#distribute-list R1_L0 out
We will use an outbound distribute-list with an access-list that matches the network (host
route). Let’s see if it works:
R2#show ip route ospf
172.16.0.0/32 is subnetted, 3 subnets
O E2 172.16.1.1 [110/20] via 192.168.12.1, 00:10:12, FastEthernet0/0
287 | P a g e
O E2 172.16.2.1 [110/20] via 192.168.12.1, 00:10:12, FastEthernet0/0
O E2 172.16.3.1 [110/20] via 192.168.12.1, 00:10:12, FastEthernet0/0
R3#show ip route ospf
172.16.0.0/32 is subnetted, 3 subnets
O E2 172.16.1.1 [110/20] via 192.168.23.2, 00:10:12, FastEthernet0/0
O E2 172.16.2.1 [110/20] via 192.168.23.2, 00:10:12, FastEthernet0/0
O E2 172.16.3.1 [110/20] via 192.168.23.2, 00:10:12, FastEthernet0/0
O IA 192.168.12.0/24 [110/2] via 192.168.23.2, 00:14:30, FastEthernet0/0
The entry has disappeared from the routing tables of R2 and R3.
1.2. Redistribution with Route-Map
The previous example works but there’s a better solution. Why not prevent certain routes
from being redistributed in the first place? Technically this isn’t “filtering” but it works very
well.
Let’s see what the current redistribute command looks like now:
R1#show running-config | include redistribute
redistribute connected subnets
We’ll create a route-map that denies 172.16.1.1 /32 from being redistributed while we
allow everything else. When it’s finished we’ll attach it to the redistribute command
above:
R1(config)#ip access-list standard R1_L1
R1(config-std-nacl)#permit host 172.16.1.1
!
R1(config)#route-map CONNECTED_TO_OSPF deny 10
R1(config-route-map)#match ip address R1_L1
!
R1(config)#route-map CONNECTED_TO_OSPF permit 20
R1(config)#router ospf 1
R1(config-router)#redistribute connected subnets route-map CONNECTED_TO_OSPF
The route-map above will deny 172.16.1.1 /32 and permits everything else. After
attaching it to the redistribute command you’ll see this on R2 and R3:
R2#show ip route ospf
172.16.0.0/32 is subnetted, 2 subnets
O E2 172.16.2.1 [110/20] via 192.168.12.1, 00:00:03, FastEthernet0/0
O E2 172.16.3.1 [110/20] via 192.168.12.1, 00:00:03, FastEthernet0/0
R3#show ip route ospf
288 | P a g e
172.16.0.0/32 is subnetted, 2 subnets
O E2 172.16.2.1 [110/20] via 192.168.23.2, 00:00:07, FastEthernet0/0
O E2 172.16.3.1 [110/20] via 192.168.23.2, 00:00:07, FastEthernet0/0
O IA 192.168.12.0/24 [110/2] via 192.168.23.2, 00:20:34, FastEthernet0/0
It’s gone from the routing table…mission accomplished! Let’s take a look at the final
method…
1.3. Summary No-Advertise
The last method to filter a type 5 LSA is a nice trick that you can do with the summary-
address command. Let me show you how to use this to filter 172.16.2.1 /32:
R1(config)#router ospf 1
R1(config-router)#summary-address 172.16.2.1 255.255.255.255 not-advertise
The trick is to add the not-advertise parameter to the summary-address command.
Whatever matches the summary route will no longer be advertised:
R2#show ip route ospf
172.16.0.0/32 is subnetted, 1 subnets
O E2 172.16.3.1 [110/20] via 192.168.12.1, 00:01:40, FastEthernet0/0
R3#show ip route ospf
172.16.0.0/32 is subnetted, 1 subnets
O E2 172.16.3.1 [110/20] via 192.168.23.2, 00:01:44, FastEthernet0/0
O IA 192.168.12.0/24 [110/2] via 192.168.23.2, 00:22:11, FastEthernet0/0
There we go, it’s gone from the routing tables!
2. Conclusion
You have now seen three different methods how you can get rid of type 5 LSAs. Another
method that prevents LSA type 5 from entering the area is using a stub area.
Be careful what filtering technique you use if you learn this for a CCIE R&S lab. The
devil is in the details…the distribute-list is actually filtering the network while the route-
map and summary-address prevent the router from advertising something.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
ip cef
!
interface Loopback0
ip address 172.16.0.1 255.255.255.255
!
289 | P a g e
interface Loopback1
ip address 172.16.1.1 255.255.255.255
!
interface Loopback2
ip address 172.16.2.1 255.255.255.255
!
interface Loopback3
ip address 172.16.3.1 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
summary-address 172.16.2.1 255.255.255.255 not-advertise
redistribute connected subnets route-map CONNECTED_TO_OSPF
network 192.168.12.0 0.0.0.255 area 0
distribute-list R1_L0 out
!
ip access-list standard R1_L0
deny 172.16.0.1
permit any
ip access-list standard R1_L1
permit 172.16.1.1
!
route-map CONNECTED_TO_OSPF deny 10
match ip address R1_L1
!
route-map CONNECTED_TO_OSPF permit 20
!
end
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.23.2 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 0
network 192.168.23.0 0.0.0.255 area 1
!
end
hostname R3
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
!
290 | P a g e
router ospf 1
network 192.168.23.0 0.0.0.255 area 1
!
end
BGP Extended Access-List Filtering
Nowadays we use prefix-lists to filter BGP prefixes. Prefix-lists are very convenient since
they allow you to specify a network address with a specific prefix length or a range of
prefix lengths. Back in the days, before prefix-lists existed on Cisco IOS you had to use
extended access-lists for this.
You really don’t want to use these anymore since the prefix-list does the same thing and
the configuration is much easier. However, when you face a CCIE lab it might be
possible that a task requires you to filter certain prefixes, but you are not allowed to use
the prefix-list. The extended access-list will be your only option then…
Having said that, let’s take a look how extended access-list filtering works. The
“behavior” of the extended access-list is different compared to when you use it for
filtering IP packets.
When you use IP as the protocol, here’s what the extended access-list normally looks
like:
Above you see the source address with the source wildcard bits and the destination
address with destination wildcard bits. Now forget what you have seen above, this is
how the extended access-list works for BGP filtering:
Let me explain these fields:
The first field is for the network address, for example 10.0.0.0.
The second field is used to define what part of the network address to check. For
example, when we specify 10.0.0.0 then we use wildcard bits to tell the router if
we want to look for 10.0.0.0, 10.0.0.x, 10.0.x.x or 10.x.x.x.
The subnet mask and its wildcard bits are used to define the prefix length, we can
use this to tell the router to look for /24, /25, /26 or a range like /24 to /32.
Using the extended access-list for BGP filtering is something that is best explained with
some examples. I’ll use two routers and some prefixes, and we’ll walk through some
different filtering examples.
291 | P a g e
1. Configuration
I will use the following two routers for this:
R2 has a bunch of loopback interfaces with different networks, we’ll use these to play
with filtering.
Here’s what R2 advertises to R1:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 35, local router ID is 192.168.7.25
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 0.0.0.0 0 32768 i
*> 30.0.0.0 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
292 | P a g e
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
Total number of prefixes 34
Let’s start with some simple examples…
1.1. Filter specific prefixes
Let’s say that we to filter some specific prefixes, let’s pick:
20.0.0.0 /8
172.16.0.0 /24
192.168.1.0 /24
Here’s what the access-list will look like:
R1(config)#access-list 100 permit ip 20.0.0.0 0.0.0.0 255.0.0.0 0.0.0.0
R1(config)#access-list 100 permit ip 172.16.0.0 0.0.0.0 255.255.255.0 0.0.0.0
R1(config)#access-list 100 permit ip 192.168.1.0 0.0.0.0 255.255.255.0 0.0.0.0
R1(config)#router bgp 1
R1(config-router)#distribute-list 100 in
R1#clear ip bgp *
Before we check the result, let me explain the access-list:
In the first entry we want an exact match for “20.0.0.0” so we use network
20.0.0.0 with wildcard 0.0.0.0. The prefix-length has to be exactly /8 so we use
subnet mask 255.0.0.0 with wildcard 0.0.0.0.
In the second entry we want an exact match for “172.16.0.0” so we use network
172.16.0.0 with wildcard 0.0.0.0. The prefix-length has to be exactly /24 so we
use subnet mask 255.255.255.0 with wildcard 0.0.0.0.
In the last entry we want an exact match for “192.168.1.0” so we use network
192.168.1.0 with wildcard 0.0.0.0. The prefix-length has to be exactly /24 so we
use subnet mask 255.255.255.0 with wildcard 0.0.0.0.
Let’s see what we get:
R1#show ip bgp
BGP table version is 4, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 20.0.0.0 192.168.12.2 0 0 2 i
r> 172.16.0.0/24 192.168.12.2 0 0 2 i
r> 192.168.1.0 192.168.12.2 0 0 2 i
Great, we only see our three specific prefixes.
293 | P a g e
In my BGP table, you can see R1 is unable to install these prefixes because of a RIB-
failure. This seems to occur because the router refuses to use the next hop IP address
unless you permit it. I couldn’t find anything about this in the Cisco documentation, but
you can solve it by adding this statement to access-list 100: permit ip host
192.168.12.2 any
One little “extra” that the access-list offers us that the prefix-list doesn’t is that it shows
matches:
R1#show access-lists 100
Extended IP access list 100
10 permit ip host 20.0.0.0 host 255.0.0.0 (2 matches)
20 permit ip host 172.16.0.0 host 255.255.255.0 (1 match)
30 permit ip host 192.168.1.0 host 255.255.255.0 (2 matches)
Let’s try something else now!
1.2. Filter all 192.168.x.0 networks with a /24 prefix length
Let’s say that we want to filter all networks in the 192.168.x.0 range that have a /24
prefix length. R2 is currently advertising these networks:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 192.168.
BGP table version is 36, local router ID is 192.168.7.17
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
We only want to see 192.168.0.0 /24, 192.168.1.0 /24 and 192.168.12.0 /24 on R1.
Here’s the access-list we will create:
R1(config)#access-list 101 permit ip 192.168.0.0 0.0.255.0 255.255.255.0 0.0.0.0
R1(config)#router bgp 1
R1(config-router)#distribute-list 101 in
R1#clear ip bgp *
Let me explain the access-list:
The network address we want to check is 192.168.0.0.
294 | P a g e
The wildcard is 0.0.255.0 which means the 1st, 2nd and 4th octet have to match.
We don’t care about the 3rd octet.
The subnet mask is 255.255.255.0 and this has to match exactly which is why we
use a 0.0.0.0 wildcard.
Here’s the result:
R1#show ip bgp
BGP table version is 4, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 192.168.0.0 192.168.12.2 0 0 2 i
r> 192.168.1.0 192.168.12.2 0 0 2 i
r> 192.168.12.0 192.168.12.2 0 0 2 i
Great, these are the only 192.168.x.0 /24 networks that we have. Time for the next
example…
1.3. Filter all 10.x.x.0 networks with a /24 prefix length
This one is similar to the previous example but this time we check the 10.x.x.0 range.
Here are the networks that R2 is advertising:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 10.
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
Let’s build an access-list:
R1(config)#access-list 102 permit ip 10.0.0.0 0.255.255.0 255.255.255.0 0.0.0.0
!
R1(config)#router bgp 1
R1(config-router)#distribute-list 102 in
!
R1#clear ip bgp *
Let me explain the access-list:
295 | P a g e
The network we want to check is 10.0.0.0 but we only care about the 1st and 4th
octet, the 2nd and 3rd octet can be everything, so we use wildcard 0.255.255.0.
We want all networks with a /24 prefix length, so we use 255.255.255.0 as the
subnet mask. This has to be an exact match, so we use 0.0.0.0 as the wildcard.
Here’s what we get:
R1#show ip bgp
BGP table version is 6, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 10.0.0.0/24 192.168.12.2 0 0 2 i
r> 10.1.0.0/24 192.168.12.2 0 0 2 i
r> 10.2.0.0/24 192.168.12.2 0 0 2 i
r> 10.8.1.0/24 192.168.12.2 0 0 2 i
r> 10.8.2.0/24 192.168.12.2 0 0 2 i
Great, these are all networks in the 10.x.x.0 range with a /24 prefix length. Let’s try
something else…
1.4. Filter all 10.x.x.x networks with a /25 prefix length
This time I want to see all networks in the 10.x.x.x range with a /25 prefix length. Here
are all 10.x.x.x networks that R2 is advertising again:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 10.
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
Here’s the access-list:
R1(config)#access-list 103 permit ip 10.0.0.0 0.255.255.255 255.255.255.128
0.0.0.0
R1(config)#router bgp 1
R1(config-router)#distribute-list 103 in
R1#clear ip bgp *
296 | P a g e
Let me explain the access-list:
We want to check the 10.0.0.0 network, but we don’t care about the 2nd, 3th or
4th octet. That’s why we use a 0.255.255.255 wildcard.
The subnet mask is 255.255.255.128 which equals /25. It has to be an exact
match, so we use wildcard 0.0.0.0.
Here’s what you will find:
R1#show ip bgp
BGP table version is 5, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 10.3.0.0/25 192.168.12.2 0 0 2 i
r> 10.3.0.128/25 192.168.12.2 0 0 2 i
r> 10.4.0.0/25 192.168.12.2 0 0 2 i
r> 10.4.0.128/25 192.168.12.2 0 0 2 i
Excellent, these are all 10.x.x.x networks with a /25 prefix length.
1.5. Filter all 192.168.7.x networks with any prefix length
This example will be a bit different. This time I want to filter all networks that start with
192.168.7.x but I don’t care about the prefix length. We are talking about the following
prefixes:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | incl 192.168.7
BGP table version is 36, local router ID is 192.168.7.17
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
Here’s the access-list:
R1(config)#access-list 104 permit ip 192.168.7.0 0.0.0.255 255.255.255.0 0.0.0.255
R1(config)#router bgp 1
R1(config-router)#distribute-list 104 in
R1#clear ip bgp *
Let me walk you through the access-list:
We are looking for network 192.168.7.0 but we only want to check the first three
octets, that’s why we use wildcard 0.0.0.255.
297 | P a g e
We don’t care about the prefix length, it should be at least a /24 since we are
looking at the 192.168.7.x range, but it doesn’t matter if it’s a /25, /26, etc. This is
why we use subnet mask 255.255.255.0 with wildcard 0.0.0.255. It means that
we don’t care about the prefix length in the 4th octet.
Here’s the result:
R1#show ip bgp
BGP table version is 5, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 192.168.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.7.8/29 192.168.12.2 0 0 2 i
r> 192.168.7.16/29 192.168.12.2 0 0 2 i
r> 192.168.7.24/30 192.168.12.2 0 0 2 i
R1 will only have these networks in its BGP table now, everything else will be filtered.
1.6. Filter anything with a /24 to /32 prefix length
Time for something different, we don’t care about the network address, but we only want
to see networks with a prefix length between /24 and /32. Let’s take a look again what
R2 is advertising to us:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 35, local router ID is 192.168.7.25
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 0.0.0.0 0 32768 i
*> 30.0.0.0 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
Network Next Hop Metric LocPrf Weight Path
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
298 | P a g e
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
Total number of prefixes 34
We have a big list with prefixes, most of them have a prefix length that is larger than /24.
We do have 20.0.0.0 /8 and 30.0.0.0 /8 that will be gone when we create this filter. Time
to find out:
R1(config)#access-list 105 permit ip 0.0.0.0 255.255.255.255 255.255.255.0
0.0.0.255
R1(config)#router bgp 1
R1(config-router)#distribute-list 105 in
R1#clear ip bgp *
Here’s how the access-list works:
We don’t care about the network, so the network address is 0.0.0.0 with wildcard
255.255.255.255.
We want all prefixes with a prefix length of at least /24, that’s why we pick a
subnet mask of 255.255.255.0 and a wildcard of 0.0.0.255. This means we don’t
care about the 4th octet so it will match everything from /24 to /32.
Let’s find out if it works:
R1#show ip bgp
BGP table version is 33, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 10.0.0.0/24 192.168.12.2 0 0 2 i
r> 10.1.0.0/24 192.168.12.2 0 0 2 i
r> 10.2.0.0/24 192.168.12.2 0 0 2 i
r> 10.3.0.0/25 192.168.12.2 0 0 2 i
299 | P a g e
r> 10.3.0.128/25 192.168.12.2 0 0 2 i
r> 10.4.0.0/25 192.168.12.2 0 0 2 i
r> 10.4.0.128/25 192.168.12.2 0 0 2 i
r> 10.5.0.0/26 192.168.12.2 0 0 2 i
r> 10.6.0.0/27 192.168.12.2 0 0 2 i
r> 10.7.0.0/28 192.168.12.2 0 0 2 i
r> 10.8.1.0/24 192.168.12.2 0 0 2 i
r> 10.8.2.0/24 192.168.12.2 0 0 2 i
r> 172.16.0.0/24 192.168.12.2 0 0 2 i
r> 172.16.1.0/24 192.168.12.2 0 0 2 i
r> 172.16.2.0/25 192.168.12.2 0 0 2 i
r> 172.16.3.0/25 192.168.12.2 0 0 2 i
r> 172.16.4.0/26 192.168.12.2 0 0 2 i
r> 172.16.5.0/27 192.168.12.2 0 0 2 i
r> 172.16.6.0/28 192.168.12.2 0 0 2 i
r> 172.16.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.0.0 192.168.12.2 0 0 2 i
r> 192.168.1.0 192.168.12.2 0 0 2 i
r> 192.168.2.0/25 192.168.12.2 0 0 2 i
r> 192.168.3.0/25 192.168.12.2 0 0 2 i
r> 192.168.4.0/26 192.168.12.2 0 0 2 i
r> 192.168.5.0/27 192.168.12.2 0 0 2 i
r> 192.168.6.0/28 192.168.12.2 0 0 2 i
r> 192.168.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.7.8/29 192.168.12.2 0 0 2 i
r> 192.168.7.16/29 192.168.12.2 0 0 2 i
r> 192.168.7.24/30 192.168.12.2 0 0 2 i
r> 192.168.12.0 192.168.12.2 0 0 2 i
Our 20.0.0.0 /8 and 30.0.0.0 /8 prefixes are now gone from the BGP table, everything
you see above has at least a /24 prefix length.
1.7. Filter anything with a /26 to /32 prefix length
This example is exactly the same as the previous example but this time the prefix length
has to be at least a /26. Here’s the list with advertised prefixes from R2 again:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 35, local router ID is 192.168.7.25
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.2.0.0/24 0.0.0.0 0 32768 i
*> 10.3.0.0/25 0.0.0.0 0 32768 i
*> 10.3.0.128/25 0.0.0.0 0 32768 i
*> 10.4.0.0/25 0.0.0.0 0 32768 i
*> 10.4.0.128/25 0.0.0.0 0 32768 i
*> 10.5.0.0/26 0.0.0.0 0 32768 i
*> 10.6.0.0/27 0.0.0.0 0 32768 i
*> 10.7.0.0/28 0.0.0.0 0 32768 i
300 | P a g e
*> 10.8.1.0/24 0.0.0.0 0 32768 i
*> 10.8.2.0/24 0.0.0.0 0 32768 i
*> 20.0.0.0 0.0.0.0 0 32768 i
*> 30.0.0.0 0.0.0.0 0 32768 i
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
*> 192.168.0.0 0.0.0.0 0 32768 i
*> 192.168.1.0 0.0.0.0 0 32768 i
*> 192.168.2.0/25 0.0.0.0 0 32768 i
*> 192.168.3.0/25 0.0.0.0 0 32768 i
*> 192.168.4.0/26 0.0.0.0 0 32768 i
*> 192.168.5.0/27 0.0.0.0 0 32768 i
*> 192.168.6.0/28 0.0.0.0 0 32768 i
*> 192.168.7.0/29 0.0.0.0 0 32768 i
*> 192.168.7.8/29 0.0.0.0 0 32768 i
*> 192.168.7.16/29 0.0.0.0 0 32768 i
*> 192.168.7.24/30 0.0.0.0 0 32768 i
*> 192.168.12.0 0.0.0.0 0 32768 i
Total number of prefixes 34
Time to clean up that BGP table. Here’s the access-list we need:
R1(config)#access-list 106 permit ip 0.0.0.0 255.255.255.255 255.255.255.192
0.0.0.63
R1(config)#router bgp 1
R1(config-router)#distribute-list 106 in
R1#clear ip bgp *
Here’s how the access-list works:
We don’t care about the network address, so we use 0.0.0.0 as the network
address with wildcard 255.255.255.255.
The prefix length has to be at least /26, that’s a 255.255.255.192 subnet mask.
We want to match all prefixes from /26 to /32, by using this wildcard we tell the
router that the last six bits have to match, we don’t care about the first two bits.
This will match subnet mask 255.255.255.192, 255.255.255.224,
255.255.255.240, 255.255.255.248, 255.255.255.252, 255.255.255.254 and
255.255.255.255 (everything from /26 to /32).
Here’s the end result:
R1#show ip bgp
BGP table version is 15, local router ID is 192.168.12.1
301 | P a g e
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 10.5.0.0/26 192.168.12.2 0 0 2 i
r> 10.6.0.0/27 192.168.12.2 0 0 2 i
r> 10.7.0.0/28 192.168.12.2 0 0 2 i
r> 172.16.4.0/26 192.168.12.2 0 0 2 i
r> 172.16.5.0/27 192.168.12.2 0 0 2 i
r> 172.16.6.0/28 192.168.12.2 0 0 2 i
r> 172.16.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.4.0/26 192.168.12.2 0 0 2 i
r> 192.168.5.0/27 192.168.12.2 0 0 2 i
r> 192.168.6.0/28 192.168.12.2 0 0 2 i
r> 192.168.7.0/29 192.168.12.2 0 0 2 i
r> 192.168.7.8/29 192.168.12.2 0 0 2 i
r> 192.168.7.16/29 192.168.12.2 0 0 2 i
r> 192.168.7.24/30 192.168.12.2 0 0 2 i
Above you can see that all prefixes below /26 have disappeared.
1.8. Filter 172.16.x.x networks with a /27 to /32 prefix length
This example will be similar to the previous one with the exception that we will check a
specific network range. Here are all networks in the 172.16.x.x range that R2 offers us:
R2#show ip bgp neighbors 192.168.12.1 advertised-routes | include 172.16.
*> 172.16.0.0/24 0.0.0.0 0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/25 0.0.0.0 0 32768 i
*> 172.16.3.0/25 0.0.0.0 0 32768 i
*> 172.16.4.0/26 0.0.0.0 0 32768 i
*> 172.16.5.0/27 0.0.0.0 0 32768 i
*> 172.16.6.0/28 0.0.0.0 0 32768 i
*> 172.16.7.0/29 0.0.0.0 0 32768 i
Let’s see if we can filter these…
R1(config)#$access-list 107 permit ip 172.16.0.0 0.0.255.255 255.255.255.224
0.0.0.31
R1(config)#router bgp 1
R1(config-router)#distribute-list 107 in
R1#clear ip bgp *
Here’s how the access-list works:
We want to check network 172.16.0.0 but we don’t care about the 3rd or 4th octet
so we use wildcard 0.0.255.255.
302 | P a g e
The prefix length should be at least /27 so we use a subnet mask of
255.255.255.224.
We want to match all subnet masks from /27 to /32 so we use a wildcard of
0.0.0.31. This means the first three octets have to match and the last four bits of
the 4th octet. This will allow subnet mask 255.255.255.192, 255.255.255.224,
255.255.255.240, 255.255.255.248, 255.255.255.252, 255.255.255.254 and
255.255.255.255.
Here’s the end result:
R1#show ip bgp
BGP table version is 4, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
r> 172.16.5.0/27 192.168.12.2 0 0 2 i
r> 172.16.6.0/28 192.168.12.2 0 0 2 i
r> 172.16.7.0/29 192.168.12.2 0 0 2 i
Great, we only have a few 172.16.x.x networks with a /27 prefix length or larger.
2. Conclusion
You have now seen quite some examples of how you can use BGP filtering with
extended access-lists. This can be pretty annoying and it’s much easier to use prefix-
lists instead. However if you are not allowed to use them, you now know how to filter
with extended access-lists.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
duplex auto
speed auto
!
router bgp 1
bgp log-neighbor-changes
neighbor 192.168.12.2 remote-as 2
distribute-list 107 in
!
access-list 100 permit ip host 20.0.0.0 host 255.0.0.0
access-list 100 permit ip host 172.16.0.0 host 255.255.255.0
access-list 100 permit ip host 192.168.1.0 host 255.255.255.0
access-list 101 permit ip 192.168.0.0 0.0.255.0 host 255.255.255.0
access-list 102 permit ip 10.0.0.0 0.255.255.0 host 255.255.255.0
access-list 103 permit ip 10.0.0.0 0.255.255.255 host 255.255.255.128
access-list 104 permit ip 192.168.7.0 0.0.0.255 255.255.255.0 0.0.0.255
access-list 105 permit ip any 255.255.255.0 0.0.0.255
303 | P a g e
access-list 106 permit ip any 255.255.255.192 0.0.0.63
access-list 107 permit ip 172.16.0.0 0.0.255.255 255.255.255.224 0.0.0.31
!
end
hostname R2
!
interface Loopback0
ip address 10.0.0.1 255.255.255.0
!
interface Loopback1
ip address 10.1.0.1 255.255.255.0
!
interface Loopback2
ip address 10.2.0.1 255.255.255.0
!
interface Loopback3
ip address 10.3.0.1 255.255.255.128
!
interface Loopback4
ip address 10.3.0.129 255.255.255.128
!
interface Loopback5
ip address 10.4.0.1 255.255.255.128
!
interface Loopback6
ip address 10.4.0.129 255.255.255.128
!
interface Loopback7
ip address 10.5.0.1 255.255.255.192
!
interface Loopback8
ip address 10.6.0.1 255.255.255.224
!
interface Loopback9
ip address 10.7.0.1 255.255.255.240
!
interface Loopback10
ip address 10.8.1.1 255.255.255.0
!
interface Loopback11
ip address 10.8.2.1 255.255.255.0
!
interface Loopback12
ip address 20.0.0.1 255.0.0.0
!
interface Loopback13
ip address 30.0.0.1 255.0.0.0
!
interface Loopback14
ip address 172.16.0.1 255.255.255.0
!
interface Loopback15
ip address 172.16.1.1 255.255.255.0
!
interface Loopback16
304 | P a g e
ip address 172.16.2.1 255.255.255.128
!
interface Loopback17
ip address 172.16.3.1 255.255.255.128
!
interface Loopback18
ip address 172.16.4.1 255.255.255.192
!
interface Loopback19
ip address 172.16.5.1 255.255.255.224
!
interface Loopback20
ip address 172.16.6.1 255.255.255.240
!
interface Loopback21
ip address 172.16.7.1 255.255.255.248
!
interface Loopback22
ip address 192.168.0.1 255.255.255.0
!
interface Loopback23
ip address 192.168.1.1 255.255.255.0
!
interface Loopback24
ip address 192.168.2.1 255.255.255.128
!
interface Loopback25
ip address 192.168.3.1 255.255.255.128
!
interface Loopback26
ip address 192.168.4.1 255.255.255.192
!
interface Loopback27
ip address 192.168.5.1 255.255.255.224
!
interface Loopback28
ip address 192.168.6.1 255.255.255.240
!
interface Loopback29
ip address 192.168.7.1 255.255.255.248
!
interface Loopback30
ip address 192.168.7.9 255.255.255.248
!
interface Loopback31
ip address 192.168.7.17 255.255.255.248
!
interface Loopback32
ip address 192.168.7.25 255.255.255.252
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
duplex auto
speed auto
!
router bgp 2
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.255.0
305 | P a g e
network 10.1.0.0 mask 255.255.255.0
network 10.2.0.0 mask 255.255.255.0
network 10.3.0.0 mask 255.255.255.128
network 10.3.0.128 mask 255.255.255.128
network 10.4.0.0 mask 255.255.255.128
network 10.4.0.128 mask 255.255.255.128
network 10.5.0.0 mask 255.255.255.192
network 10.6.0.0 mask 255.255.255.224
network 10.7.0.0 mask 255.255.255.240
network 10.8.0.0 mask 255.255.255.224
network 10.8.1.0 mask 255.255.255.0
network 10.8.2.0 mask 255.255.255.0
network 20.0.0.0
network 30.0.0.0
network 172.16.0.0 mask 255.255.255.0
network 172.16.1.0 mask 255.255.255.0
network 172.16.2.0 mask 255.255.255.128
network 172.16.3.0 mask 255.255.255.128
network 172.16.4.0 mask 255.255.255.192
network 172.16.5.0 mask 255.255.255.224
network 172.16.6.0 mask 255.255.255.240
network 172.16.7.0 mask 255.255.255.248
network 192.168.0.0
network 192.168.1.0
network 192.168.2.0 mask 255.255.255.128
network 192.168.3.0 mask 255.255.255.128
network 192.168.4.0 mask 255.255.255.192
network 192.168.5.0 mask 255.255.255.224
network 192.168.6.0 mask 255.255.255.240
network 192.168.7.0 mask 255.255.255.248
network 192.168.7.8 mask 255.255.255.248
network 192.168.7.16 mask 255.255.255.248
network 192.168.7.24 mask 255.255.255.252
network 192.168.12.0
neighbor 192.168.12.1 remote-as 1
!
end
BGP IPv6 Route Filtering on Cisco IOS
Filtering IPv6 routes in BGP is similar to IPv4 filtering. There are 3 methods we can use:
Prefix-list
Filter-list
Route-map
Each of these can be applied in- or outbound. I’ll explain how you can use these for
filtering, this is the topology I will use:
306 | P a g e
R1 and R2 are using IPv6 addresses and will use MP-BGP so that R1 can advertise
some prefixes on its loopback interfaces. All prefixes on the loopback interfaces are /64
subnets while loopback3 has a /96 subnet.
1. Configuration
Let’s start with a basic MP-BGP configuration so that R1 and R2 become eBGP
neighbors:
R1 & R2#
(config)ipv6 unicast-routing
R1(config)#router bgp 1
R1(config-router)#bgp router-id 1.1.1.1
R1(config-router)#neighbor 2001:db8:0:12::2 remote-as 2
R1(config-router)#address-family ipv6
R1(config-router-af)#neighbor 2001:db8:0:12::2 activate
R1(config-router-af)#network 2001:db8:0:1::/64
R1(config-router-af)#network 2001:db8:0:11::/64
R1(config-router-af)#network 2001:db8:0:111::/64
R1(config-router-af)#network 2001:db8:0:1111::/96
R2(config)#router bgp 2
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#neighbor 2001:db8:0:12::1 remote-as 1
R2(config-router)#address-family ipv6
R2(config-router-af)#neighbor 2001:db8:0:12::1 activate
Let’s check if R2 has learned all prefixes:
R2#show ipv6 route bgp | begin 2001
B 2001:DB8:0:1::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:11::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:111::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:1111::/96 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
There we go, everything is in the routing table. Now we can play with some of the
filtering options…
1.1. Prefix-List Filtering
Let’s start with the prefix-list. R1 is advertising one /96 subnet. Let’s see if we can
configure R2 to filter this network:
R2(config)#ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64
This prefix-list checks the entire 2001::/16 range and permits subnets with a /64 or
larger. Anything smaller will be denied. Let’s activate it:
307 | P a g e
R2(config)#router bgp 2
R2(config-router)#address-family ipv6
R2(config-router-af)#neighbor 2001:db8:0:12::1 prefix-list SMALL_NETWORKS in
We activate the prefix-list inbound on R2 for everything that we receive from R1. Let’s
reset BGP to speed things up:
R2#clear ip bgp *
Let’s check R2 to see if our prefix is gone:
R2#show ipv6 route bgp | begin 2001
B 2001:DB8:0:1::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:11::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:111::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
Great, it has been filtered successfully!
1.2. Filter-List Filtering
Let’s try the filter-list. We can use this to filter prefixes from certain autonomous systems.
Everything that R1 is advertising only has AS 1 in the AS path, I’ll configure AS
prepending, so we have something to play with:
R1(config)#ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64
R1(config)#route-map PREPEND permit 10
R1(config-route-map)#match ipv6 address prefix-list FIRST_LOOPBACK
R1(config-route-map)#set as-path prepend 11
R1(config)#route-map PREPEND permit 20
R1(config)#router bgp 1
R1(config-router)#address-family ipv6
R1(config-router-af)#neighbor 2001:db8:0:12::2 route-map PREPEND out
The above configuration will make sure that whenever R1 advertises 2001:db8:0:1::/64 it
will add AS 11 to the AS path. Let’s verify this:
R2#show ip bgp all
For address family: IPv4 Unicast
For address family: IPv6 Unicast
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
308 | P a g e
r RIB-failure, S Stale, m multipath, b backup-path, x best-external,
f RT-Filter
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8:0:1::/64
2001:DB8:0:12::1
0 0 1 11 i
*> 2001:DB8:0:11::/64
2001:DB8:0:12::1
0 0 1 i
*> 2001:DB8:0:111::/64
2001:DB8:0:12::1
0 0 1 i
For address family: IPv4 Multicast
Above you can see that 2001:DB8:0:1::/64 now has AS 11 in its AS path. Let’s configure
a filter-list on R2 to get rid of this network:
R2(config)#ip as-path access-list 11 permit ^1$
R2(config)#router bgp 2
R2(config-router)#address-family ipv6
R2(config-router-af)#neighbor 2001:db8:0:12::1 filter-list 11 in
R2#clear ip bgp *
The as-path access-list above only permits prefixes from AS1, nothing else. We attach it
inbound to everything we receive from R1. This is the result:
R2#show ipv6 route bgp | begin 2001
B 2001:DB8:0:11::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
B 2001:DB8:0:111::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
It’s gone from the routing table, mission accomplished.
1.3. Route-Map Filtering
Route-maps are really useful and can be used to match on many different things. I’ll use
an IPv6 access-list in a route-map to filter 2001:DB8:0:11::/64:
R2(config)#ipv6 access-list THIRD_LOOPBACK
R2(config-ipv6-acl)#permit 2001:db8:0:11::/64 any
R2(config)#route-map MY_FILTER deny 10
R2(config-route-map)#match ipv6 address THIRD_LOOPBACK
R2(config-route-map)#exit
R2(config)#route-map MY_FILTER permit 20
309 | P a g e
R2(config)#router bgp 2
R2(config-router-af)#neighbor 2001:db8:0:12::1 route-map MY_FILTER in
R2#clear ip bgp *
The configuration above has an access-list called “THIRD_LOOPBACK” that matches
2001:DB8:0:11::/64 and is denied in the route-map called “MY_FILTER”. Last but not
least, we apply it inbound on R2. Here’s the result:
R2#show ipv6 access-list
IPv6 access list THIRD_LOOPBACK
permit ipv6 2001:DB8:0:11::/64 any (1 match) sequence 10
R2#show ipv6 route bgp | begin 2001
B 2001:DB8:0:111::/64 [20/0]
via FE80::21D:A1FF:FE8B:36D0, FastEthernet0/0
The access-list tells us that it has a match and you can see it’s gone from the routing
table.
2. Order of Operation
You have now seen how you can use a prefix-list, filter-list and route-map to filter IPv6
prefixes. You can apply all of these at the same time if you want, I didn’t remove any of
my previous configurations when I was writing this lesson. Take a look at R2:
R2#show run | sec address-family ipv6
address-family ipv6
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in
neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
neighbor 2001:DB8:0:12::1 filter-list 11 in
On a production network you probably won’t use all of these at the same time. The
route-map is a popular choice since you can use it for pretty much anything, filtering and
doing things like prepending the AS path.
If you do activate all of these at the same time then you might want to know in what
order the router will process these filtering techniques. Here they are:
Inbound:
Route-map
Filter-List
Prefix-List
Outbound:
Prefix-List
Filter-List
Route-Map
310 | P a g e
Why do we care about this? Imagine you have an inbound route-map and prefix-list. If
you permitted a prefix in the prefix-list but denied it in the route-map then you will never
see the prefix in your BGP table since the route-map is processed before the prefix-list.
For outbound filtering it’s the other way around. If you permit something in the route-map
but denied it in a filter-list then it will never be advertised…the filter-list is processed
before the route-map for outbound updates.
Don’t make it too hard for yourself…it’s best to stick to using the route-map only since
you can attach prefix-lists and as-path access-lists to it.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
ipv6 unicast-routing
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::1/64
!
interface Loopback0
ipv6 address 2001:DB8:0:1::1/64
!
interface Loopback1
ipv6 address 2001:DB8:0:11::1/64
!
interface Loopback2
ipv6 address 2001:DB8:0:111::1/64
!
interface Loopback3
ipv6 address 2001:DB8:0:1111::1/96
!
router bgp 1
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::2 remote-as 2
!
address-family ipv4
neighbor 2001:DB8:0:12::2 activate
neighbor 2001:DB8:0:12::2 route-map PREPEND out
exit-address-family
!
address-family ipv6
network 2001:DB8:0:1::/64
network 2001:DB8:0:11::/64
network 2001:DB8:0:111::/64
network 2001:DB8:0:1111::/96
neighbor 2001:DB8:0:12::2 activate
neighbor 2001:DB8:0:12::2 route-map PREPEND out
exit-address-family
!
ipv6 prefix-list FIRST_LOOPBACK permit 2001:db8:0:1::/64
route-map PREPEND permit 10
match ipv6 address prefix-list FIRST_LOOPBACK
set as-path prepend 11
route-map PREPEND permit 20
311 | P a g e
!
end
hostname R2
!
ipv6 unicast-routing
!
interface FastEthernet0/0
ipv6 address 2001:DB8:0:12::2/64
!
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
neighbor 2001:DB8:0:12::1 remote-as 1
!
address-family ipv4
no neighbor 2001:DB8:0:12::1 activate
exit-address-family
!
address-family ipv6
neighbor 2001:DB8:0:12::1 activate
neighbor 2001:DB8:0:12::1 prefix-list SMALL_NETWORKS in
neighbor 2001:DB8:0:12::1 route-map MY_FILTER in
neighbor 2001:DB8:0:12::1 filter-list 11 in
exit-address-family
!
ipv6 prefix-list SMALL_NETWORKS permit 2001::/16 le 64
!
ip as-path access-list 11 permit ^1$
!
ipv6 access-list THIRD_LOOPBACK
permit 2001:db8:0:11::/64 any
!
route-map MY_FILTER deny 10
match ipv6 address THIRD_LOOPBACK
route-map MY_FILTER permit 20
!
end
312 | P a g e
1.2.g: Manual summarization with any routing protocol
Route summarization is a method where we create one summary route that represent
multiple networks/subnets. It’s also called route aggregation or supernetting.
Summarization has a number of advantages:
Saves memory: routing tables will be smaller which reduces memory
requirements.
Saves bandwidth: there are less routes to advertise so we save some
bandwidth.
Saves CPU cycles: less packets to process and smaller routing tables to work
on.
Stability: Prevents routing table instability due to flapping networks.
There are also some disadvantages to summarization:
Forwarding traffic for unused networks: a router will drop traffic when it
doesn’t have a matching destination in its routing table. When we use
summarization, it’s possible that the summary route covers networks that are not
in use. The router that has a summary route will forward them to the router that
has advertised the summary route.
313 | P a g e
Sub-optimal routing: routers prefer the path with the longest prefix match. When
you use summaries, it’s possible that your router prefers another path where it
has learned a more specific network from. The summary route also has a single
metric.
This lesson doesn’t cover how to calculate summary routes. If that’s what you want to
learn, take a look here.
It’s best to see everything I described above in action. Let’s take a look at some routers.
1. Configuration
This is the topology we will use:
For now, we only need two routers. R1 has four loopback interfaces that we will
advertise in RIP. I’ll show you a “before” and “after” of route summarization.
1.1. Without Route Summarization
Let’s configure RIP so that all loopback interfaces are advertised:
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
R1(config-router)#network 172.16.0.0
R1(config-router)#network 192.168.12.0
R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#no auto-summary
R2(config-router)#network 192.168.12.0
Let’s enable a debug so that we can see what is going on behind the scenes:
R1 & R2
#debug ip rip
RIP protocol debugging is on
Here’s what we will see:
R1#
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0
172.16.1.0/24 via 0.0.0.0, metric 1, tag 0
314 | P a g e
172.16.2.0/24 via 0.0.0.0, metric 1, tag 0
172.16.3.0/24 via 0.0.0.0, metric 1, tag 0
R1 is advertising four different networks. R2 receives them:
R2#
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/24 via 0.0.0.0 in 1 hops
172.16.1.0/24 via 0.0.0.0 in 1 hops
172.16.2.0/24 via 0.0.0.0 in 1 hops
172.16.3.0/24 via 0.0.0.0 in 1 hops
The more information we advertise, the more bandwidth we require, and more CPU
cycles are required to process them. Of course, four networks on a Gigabit interface are
no problem but in larger networks, there might be thousands or hundreds of thousands
of networks that are advertised.
Let’s check R2:
R2#show ip route rip
R 172.16.0.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R 172.16.1.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R 172.16.2.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R 172.16.3.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R2 stores all networks in its routing table which requires memory.
Let’s talk about stability. Let me show you what happens when we shut one of the
loopback interfaces on R1:
R1(config)#interface loopback 0
R1(config-if)#shutdown
As soon as this happens, R1 will send a triggered update to R2:
RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build flash update entries
172.16.0.0/24 via 0.0.0.0, metric 16, tag 0
R2 receives this update:
R2#
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/24 via 0.0.0.0 in 16 hops (inaccessible)
315 | P a g e
After a while, R2 will remove this network from its routing table. Every time an interface
goes up and down, packets are generated, and the routing table will change. All of this
requires bandwidth, CPU cycles, and memory. No problem for our small network but
when you have thousands of networks and dozens of routers then it’s a different story.
1.2. With Route Summarization
Let’s see how route summarization works. I’ll configure R1 to advertise a summary
towards R2:
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip summary-address rip 172.16.0.0 255.255.0.0
Here’s what R1 advertises now:
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build update entries
172.16.0.0/16 via 0.0.0.0, metric 1, tag 0
And here’s what R2 receives:
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/16 via 0.0.0.0 in 1 hops
Only one network is advertised, our summary route. Less information, less bandwidth,
less CPU cycles required and less memory. Here’s the routing table of R2:
R2#show ip route rip
R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:10, GigabitEthernet0/1
Only one entry remains. R2 is still able to reach every network that our summary route
covers. Let’s try this:
R2#ping 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
This is looking good. Let me also show you one of the disadvantages of summarization.
Here’s what happens when we ping an IP address that is covered by the summary route,
but which is not available:
R2#ping 172.16.4.4
316 | P a g e
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
The U means it’s unreachable. R2 has a matching route towards R1 so it sends these
packets to R1. When R1 receives them, it drops them since it doesn’t have a matching
entry and informs R2 about this.
Remember what happened when we shut one of the loopback interface? RIP would
send a triggered update. Let’s try that again:
R1(config)#interface loopback 0
R1(config-if)#shutdown
Nothing will happen now! As long as there is one interface up with an IP address that
falls within the summary route then the summary will be advertised. This makes our
network far more stable.
Let me show you what happens when I shut the remaining loopbacks:
R1(config)#interface loopback 1
R1(config-if)#shutdown
R1(config)#interface loopback 2
R1(config-if)#shutdown
R1(config)#interface loopback 3
R1(config-if)#shutdown
Once I shut the last loopback, something happens:
R1#
RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build flash update entries
172.16.0.0/16 via 0.0.0.0, metric 16, tag 0
Once the final loopback interface is gone, R1 sends the triggered update to inform R2
that the summary route is gone. Here’s R2:
R2#
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/16 via 0.0.0.0 in 16 hops (inaccessible)
There is one more disadvantage to summarization but to demonstrate this, I will have to
add another router. Let’s add R3:
317 | P a g e
We use the same topology but R1 and R2 are now also connected to R3. Let’s make
sure our loopback interfaces are up again:
R1(config)#interface range loopback 0 - 3
R1(config-if-range)#no shutdown
Let’s configure R1 so that it sends RIP packets to R3:
R1(config)#router rip
R1(config-router)#network 192.168.13.0
R1(config)#access-list 1 deny any
R1(config)#router rip
R1(config-router)distribute-list 1 in GigabitEthernet 0/2
The access-list on R1 is required to prevent R1 from installing any RIP routes from R3.
Otherwise the summary route is advertised from R1 > R2 > R3 > R1, causing a routing
loop.
Let’s configure R2:
R2(config-if)#router rip
R2(config-router)#network 192.168.23.0
And R3:
R3(config-if)#router rip
R3(config-R3)#version 2
R3(config-R3)#no auto-summary
R3(config-R3)#network 192.168.13.0
R3(config-R3)#network 192.168.23.0
Now let’s take a look at the routing tables:
318 | P a g e
R3#show ip route rip
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:22, GigabitEthernet0/2
R 172.16.0.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 172.16.1.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 172.16.2.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 172.16.3.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:22, GigabitEthernet0/2
[120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
Above you can see that R3 learns the summary route from R2, all other networks are
learned from R1. Let’s check R2:
R2#show ip route rip
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:08, GigabitEthernet0/1
R 172.16.0.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 172.16.1.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 172.16.2.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 172.16.3.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 192.168.13.0/24 [120/1] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
[120/1] via 192.168.12.1, 00:00:08, GigabitEthernet0/1
Above you can see that we now have sub-optimal routing on R2. Since the router
prefers the most specific path, it will use R3 to reach the four 172.16.x.0/24 networks
and it’s not using the summary route from R1. We can verify this with a traceroute:
R2#traceroute 172.16.0.1 probe 1
Type escape sequence to abort.
Tracing the route to 172.16.0.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.23.3 5 msec
2 192.168.13.1 10 msec
There are a couple of different methods how you can solve this, depending on what
routing protocol you select. This is something we will discuss in other lessons.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
ip cef
!
interface Loopback0
ip address 172.16.0.1 255.255.255.0
!
interface Loopback1
ip address 172.16.1.1 255.255.255.0
319 | P a g e
!
interface Loopback2
ip address 172.16.2.1 255.255.255.0
!
interface Loopback3
ip address 172.16.3.1 255.255.255.0
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
ip summary-address rip 172.16.0.0 255.255.0.0
!
interface GigabitEthernet0/2
ip address 192.168.13.1 255.255.255.0
!
router rip
network 172.16.0.0
network 192.168.12.0
network 192.168.13.0
distribute-list 1 in GigabitEthernet0/2
no auto-summary
!
access-list 1 deny any
!
end
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.23.2 255.255.255.0
!
router rip
network 192.168.12.0
network 192.168.23.0
no auto-summary
!
end
hostname R3
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.13.3 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.23.3 255.255.255.0
!
router rip
network 192.168.13.0
320 | P a g e
network 192.168.23.0
no auto-summary
!
end
2. Conclusion
You have now learned what route summarization is about and it’s advantages and
disadvantages:
Summarization means we advertise one summary route that represents multiple
networks.
Also known as route aggregation or supernetting.
Saves CPU cycles, bandwidth and memory.
Reduces the size of the routing table.
Prevents routing table instability
Has two possible disadvantages:
o Forwarding traffic to non-existing networks.
o Sub-optimal routing.
Route Summarization
In this lesson we’ll take a look how you can configure summaries. First I’ll show you
some examples how to do so in binary and then we’ll take a look at some tricks how you
can do it in decimal (which is much faster).
Let’s say we want to create the most optimal summary for the following 4 networks:
192.168.0.0 / 24 subnet mask 255.255.255.0
192.168.1.0 / 24 subnet mask 255.255.255.0
192.168.2.0 / 24 subnet mask 255.255.255.0
192.168.3.0 / 24 subnet mask 255.255.255.0
Let’s convert these network addresses to binary:
192.168.0 110000 101010 000000 000000
.0 00 00 00 00
192.168.1 110000 101010 000000 000000
.0 00 00 01 00
192.168.2 110000 101010 000000 000000
.0 00 00 10 00
192.168.3 110000 101010 000000 000000
.0 00 00 11 00
321 | P a g e
Now we have to look how many bits these network addresses have in common. The first
and second octets are the same, so that’s 16 bits.
Let’s zoom in on the third octet:
00000000
00000001
00000010
00000011
The first 6 bits of the third octet are the same. Now we have enough information to
create our summary address.
8 + 8 + 6 = 22 bits
Our summary address will be 192.168.0.0 /22 (subnet mask 255.255.252.0).
Now you have seen how to do this in binary, let’s do it in decimal. There’s a simple trick
you can use to calculate this summary.
As you can see we have 4 networks, or when we speak in ‘blocks’ it’s a block of 4.
Here’s a formula you can use:
256 – number of networks = subnet mask for summary address.
For example: 256 – 4 networks = 252
The subnet mask will be 255.255.252.0
Another way to look at it is by using the CIDR notation. You know a /24 is a block of 256
addresses. Using a /23 means you have 2 x 256, and a /22 means you have 4 x 256.
Let’s look at another example. Let’s say we want to summarize the following networks:
172.16.0.0 / 16 subnet mask 255.255.0.0
172.17.0.0 / 16 subnet mask 255.255.0.0
172.18.0.0 / 16 subnet mask 255.255.0.0
172.19.0.0 / 16 subnet mask 255.255.0.0
172.20.0.0 / 16 subnet mask 255.255.0.0
172.21.0.0 / 16 subnet mask 255.255.0.0
172.22.0.0 / 16 subnet mask 255.255.0.0
172.23.0.0 / 16 subnet mask 255.255.0.0
Let’s look at it in binary first. I’ll write down the second octet since the first one is the
same for all network addresses:
322 | P a g e
16 00010000
17 00010001
18 00010010
19 00010011
20 00010100
21 00010101
22 00010110
23 00010111
The first 5 bits for all these addresses are the same. The first octet had 8 similar bits so
that’s 8 + 5 = 13 bits.
The summary address will be 172.16.0.0 /13 (subnet mask will be 255.248.0.0).
Calculating in binary like this works but it’s slow. Let’s use our trick for this:
256 – number of networks = subnet mask for summary address.
So that’s 256 – 8 = 248. The subnet mask will be 255.248.0.0
We can also find it by just looking at the CIDR notations:
172.16.0.0 /16 is one network.
172.16.0.0 /15 are two networks.
172.16.0.0 /14 are four networks.
172.16.0.0 /13 are eight networks.
That’s a lot faster than looking at it in binary.
How to configure EIGRP Summarization
In this lesson we’ll take a look at EIGRP summarization. The cool thing about EIGRP
and summarization is that it’s easy to do and can be done on the interface-level. Here’s
the topology that we’ll use:
323 | P a g e
Let’s create a basic EIGRP configuration:
R1(config)#router eigrp 1
R1(config-router)#no auto-summary
R1(config-router)#network 192.168.12.0
R1(config-router)#network 172.16.0.0
R2(config)#router eigrp 1
R2(config-router)#no auto-summary
R2(config-router)#network 192.168.12.0
Just a basic EIGRP configuration. This is what the routing table of R2 looks like:
R2#show ip route eigrp
172.16.0.0/24 is subnetted, 2 subnets
D 172.16.0.0 [90/30720] via 192.168.12.1, 00:02:28, FastEthernet0/0
D 172.16.1.0 [90/30720] via 192.168.12.1, 00:02:28, FastEthernet0/0
Two entries as expected. Now let’s create that summary:
R1(config)#interface fastEthernet 2/0
R1(config-if)#ip summary-address eigrp 1 172.16.0.0 255.255.254.0
Use the ip summary-address eigrp command to specify the summary. Now the routing
table will look like this:
R2#show ip route eigrp
172.16.0.0/23 is subnetted, 1 subnets
D 172.16.0.0 [90/30720] via 192.168.12.1, 00:00:53, FastEthernet0/0
The two networks disappear, and a single entry will appear on R2. The metric is 30720,
how did it get this value? When you advertise a summary, the router advertising the
summary will use the lowest metric of all networks that fall within the range of the
summary. That’s the one it will use for the summary. It is possible to manually set the
metric for each summary. Here’s how:
R1(config)#router eigrp 1
324 | P a g e
R1(config-router)#summary-metric ?
The summary-metric requires you to set the bandwidth, delay, reliability, load, and MTU.
Let’s try something:
R1(config-router)#summary-metric 172.16.0.0 255.255.254.0 100000 10 255 0 1500
R2 will now see the new metric:
R2#show ip route eigrp
172.16.0.0/23 is subnetted, 1 subnets
D 172.16.0.0 [90/2562816] via 192.168.12.1, 00:00:53, FastEthernet0/0
Advertising a summary also changes something in the routing table of R1:
R1#show ip route eigrp
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D 172.16.0.0/23 is a summary, 00:01:38, Null0
EIGRP will create an entry in the routing table for the summary and it’s pointing to the
null0 interface. It does this to protect itself against routing loops. When you use
summaries it’s possible that other routers will send traffic to you for networks that you
have no clue about where they are. When this happens the traffic will be forwarded to
the null0 interface and dropped.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R2
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
router eigrp 1
network 192.168.12.0
!
end
hostname R1
!
interface FastEthernet2/0
ip address 192.168.12.1 255.255.255.0
ip summary-address eigrp 1 172.16.0.0 255.255.254.0
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.0
325 | P a g e
!
interface FastEthernet1/0
ip address 172.16.1.1 255.255.255.0
!
router eigrp 1
network 172.16.0.0
network 192.168.12.0
!
end
How to configure OSPF Summarization
If you are studying OSPF you will learn that OSPF uses LSA type 3 for inter-area routers
and LSA type 5 for external prefixes that are redistributed into OSPF.
OSPF can do summarization but it’s impossible to summarize within an area. This
means we have to configure summarization on an ABR or ASBR. OSPF can only
summarize our LSA type 3 and 5.
If you want summarization for OSPF you will have to configure it yourself. I will show you
how to do this for inter-area prefixes and external prefixes. Let’s start with an example:
Look at the topology above. If we don’t use summarization (which is the default) there
will be a LSA for every specific prefix. If we have a link failure in area 1 then R1 (our
ABR) will flood a new type 3 summary LSA and this change has to be propagated
throughout all our OSPF areas. Since the LSDB will change our OSPF routers they will
have to re-run the SPF algorithm which takes time and CPU power.
If we use summarization things will be different. I can create a summary on R1 to
summarize the different type 3 summary LSAs. Instead of sending a LSA for 4.4.4.0 /24
and 4.5.5.0 /24 I could send 4.0.0.0 /8 or something alike.
If a link failure occurs in area 1 nothing will change for area 0 and area 2 since they don’t
have the specific 4.4.4.0 /24 prefix in their LSDB but the 4.0.0.0 /8 summary. Nothing will
change in their LSDB so we don’t have to re-run the SPF algorithm.
326 | P a g e
Summarization of type 3 summary LSAs means we are creating a summary of all the
interarea routes. This is why we call it interarea route summarization. There are a
couple of things to be aware of:
A summary route will only be advertised if you have at least one subnet that
falls within the summary range.
A summary route will have the cost of the subnet with the lowest cost that falls
within the summary range.
Your ABR that creates the summary route will create a null0 interface to prevent
loops.
OSPF is a classless routing protocol so you can pick any subnet mask you like
for prefixes.
If you look at my picture you can see that 4.4.4.0 /24 and 4.5.5.0 /24 both fall within the
4.0.0.0 /8 summary. If we have a link failure for the 4.4.4.0 /24 prefix we will still
advertise the summary. If 4.5.5.0 /24 would fail as well then the summary will be
withdrawn since there is no subnet left that falls within the 4.0.0.0 /8 range.
Enough theory let’s take a look at the configuration of inter-area summarization. This is
the topology we’ll use:
I’m going to show you an example of interarea route summarization. I’m going to use
routers R1 and R2. R1 will have 4 loopback interfaces which are in area 0. The link
between R1 and R2 is in area 1 which turns R1 into an ABR that can do summarization.
R1(config)#router ospf 1
R1(config-router)#network 172.16.0.0 0.0.3.255 area 0
R1(config-router)#network 192.168.12.0 0.0.0.255 area 1
R2(config)#router ospf 1
R2(config-router)#network 192.168.12.0 0.0.0.255 area 1
Here are the network commands I used to advertise all subnets.
R2#show ip route ospf
172.16.0.0/32 is subnetted, 4 subnets
O IA 172.16.1.1 [110/2] via 192.168.12.1, 00:08:04, FastEthernet0/0
O IA 172.16.0.1 [110/2] via 192.168.12.1, 00:08:04, FastEthernet0/0
O IA 172.16.3.1 [110/2] via 192.168.12.1, 00:08:04, FastEthernet0/0
O IA 172.16.2.1 [110/2] via 192.168.12.1, 00:08:04, FastEthernet0/0
R2#show ip ospf database | begin Summary
327 | P a g e
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
172.16.0.1 172.16.3.1 542 0x80000003 0x005269
172.16.1.1 172.16.3.1 542 0x80000003 0x004773
172.16.2.1 172.16.3.1 542 0x80000003 0x003C7D
172.16.3.1 172.16.3.1 542 0x80000003 0x003187
Above you see the LSDB and routing table of R2. You can see there are 4 LSAs for
each of the prefixes.
R1(config)#router ospf 1
R1(config-router)#area 0 range 172.16.0.0 255.255.0.0
By using the area range command we can summarize the type 3 summary LSAs. In my
example I’m creating the summary 172.16.0.0 /16. To keep things interesting you need
to type in a subnet mask for the summary instead of a wildcard for the network
command.
R2#show ip route ospf
O IA 172.16.0.0/16 [110/2] via 192.168.12.1, 00:03:26, FastEthernet0/0
R2#show ip ospf database | begin Summary
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
172.16.0.0 172.16.3.1 219 0x80000001 0x00605E
Once again the LSDB and routing table of R2. Instead of 4x type 3 summary LSA we
now have just a single LSA. You can see there is only the 172.16.0.0 /16 entry in the
routing table.
So far so good? Excellent! One more thing we can do with OSPF and summarization
which is external route summarization. This is where we summarize the type 5
external LSAs. Two things to keep in mind:
You can create the summary only on the ASBR.
A null0 entry will be created in the routing table for the summary route.
This is the topology I will use to demonstrate this:
328 | P a g e
Instead of using the network command to advertise the prefixes on the loopback
interfaces I’m going to redistribute them into OSPF.
R1(config)#router ospf 1
R1(config-router)#no network 172.16.0.0 0.0.3.255 area 0
R1(config-router)#redistribute connected subnets
We’ll remove the network command for the interfaces and redistribute the loopback
interfaces into OSPF.
R2#show ip route ospf
172.16.0.0/24 is subnetted, 4 subnets
O E2 172.16.0.0 [110/20] via 192.168.12.1, 00:01:07, FastEthernet0/0
O E2 172.16.1.0 [110/20] via 192.168.12.1, 00:01:07, FastEthernet0/0
O E2 172.16.2.0 [110/20] via 192.168.12.1, 00:01:07, FastEthernet0/0
O E2 172.16.3.0 [110/20] via 192.168.12.1, 00:01:07, FastEthernet0/0
R2#show ip ospf database | begin Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
172.16.0.0 172.16.3.1 91 0x80000001 0x00B46E 0
172.16.1.0 172.16.3.1 91 0x80000001 0x00A978 0
172.16.2.0 172.16.3.1 91 0x80000001 0x009E82 0
172.16.3.0 172.16.3.1 91 0x80000001 0x00938C 0
Here is the LSDB and routing table of R2. As you can see we have type 5 external LSAs
and they show up as O E2 entries in the routing table.
R1(config)#router ospf 1
R1(config-router)#summary-address 172.16.0.0 255.255.0.0
This is how you summarize the type 5 external LSAs by using the summary-address
command. This is a different command compared to summarizing the type 3 summary
LSAs.
R2#show ip route ospf
O E2 172.16.0.0/16 [110/20] via 192.168.12.1, 00:00:17, FastEthernet0/0
R2#show ip ospf database | begin Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
172.16.0.0 172.16.3.1 38 0x80000002 0x00B26F 0
This is what the LSDB and routing table of R2 looks like after the summarization. That’s
all I wanted to show you about OSPF summarization.
Want to take a look for yourself? Here you will find the final configuration of each device.
329 | P a g e
hostname R1
!
ip cef
!
interface Loopback0
ip address 172.16.0.1 255.255.255.0
!
interface Loopback1
ip address 172.16.1.1 255.255.255.0
!
interface Loopback2
ip address 172.16.2.1 255.255.255.0
!
interface Loopback3
ip address 172.16.3.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 1
!
end
hostname R2
!
ip cef
!
interface Loopback0
ip address 3.3.3.1 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
!
router ospf 1
network 192.168.12.0 0.0.0.255 area 1
!
end
IS-IS Summarization
IS-IS supports summarization but since it is a link-state routing protocol, you can’t do this
within an area as the link-state database have to be the same on all routers within the
area. You can only configure summarization on a “border”. That would be an area border
router or a router that is doing redistribution.
In this lesson, I’ll walk you through both options.
1. Configuration
This is the topology we will use:
330 | P a g e
Above we have R1 and R3 in area 12. R3 is in area 3. On R1 we have two loopback
interfaces. Loopback 0 will be advertised in IS-IS, loopback 1 will be redistributed. I will
show you how to summarize both routes.
Want to take a look for yourself? Here you will find the startup configuration of each
device.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
ip router isis
!
router isis
net 49.0012.0000.0000.0001.00
is-type level-1
log-adjacency-changes
!
end
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
ip router isis
!
interface GigabitEthernet0/2
ip address 192.168.23.2 255.255.255.0
ip router isis
331 | P a g e
!
router isis
net 49.0012.0000.0000.0002.00
log-adjacency-changes
!
end
hostname R3
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
ip router isis
!
router isis
net 49.0003.0000.0000.0003.00
log-adjacency-changes
!
end
1.1. Summarization
Let’s get started. First, we enable IS-IS on the loopback 0 interface:
R1(config)#interface Loopback 0
R1(config-if)#ip router isis
This loopback has the 1.1.1.1/32 prefix which will show up on R2’s level 1 database:
R2#show isis database level-1 verbose R1.00-00
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 0x00000007 0x1252 1164 0/0/0
Area Address: 49.0012
NLPID: 0xCC
Hostname: R1
Metric: 10 IS R2.01
IP Address: 1.1.1.1
Metric: 10 IP 192.168.12.0 255.255.255.0
Metric: 10 IP 1.1.1.1 255.255.255.255
And it will be copied to R2’s level 2 database:
R2#show isis database level-2 verbose R2.00-00
IS-IS Level-2 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R2.00-00 * 0x00000007 0x5965 1146 0/0/0
332 | P a g e
Area Address: 49.0012
NLPID: 0xCC
Hostname: R2
Metric: 10 IS R2.02
IP Address: 192.168.23.2
Metric: 10 IP 192.168.12.0 255.255.255.0
Metric: 10 IP 192.168.23.0 255.255.255.0
Metric: 20 IP 1.1.1.1 255.255.255.255
This route will show up in the routing table of R2:
R2#show ip route isis
1.0.0.0/32 is subnetted, 1 subnets
i L1 1.1.1.1 [115/20] via 192.168.12.1, 00:01:10, GigabitEthernet0/1
Let’s see if we can summarize this route so that R3 receives a summary:
R2(config)#router isis
R2(config-router)#summary-address 1.0.0.0 255.0.0.0 ?
level-1 Summarize into level-1 area
level-1-2 Summarize into both area and sub-domain
level-2 Summarize into level-2 sub-domain
metric Set metric for summay route
tag Set tag
<cr>
Let’s create a basic summary without specifying anything:
R2(config-router)#summary-address 1.0.0.0 255.0.0.0
Now let’s take a look how this influences R2’s database. Nothing will change in its level
1 database but the LSP in the level 2 database will change:
R2#show isis database level-2 verbose R2.00-00
IS-IS Level-2 LSP R2.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R2.00-00 * 0x00000008 0x8D33 1135 0/0/0
Area Address: 49.0012
NLPID: 0xCC
Hostname: R2
Metric: 10 IS R2.02
IP Address: 192.168.23.2
Metric: 10 IP 192.168.12.0 255.255.255.0
Metric: 10 IP 192.168.23.0 255.255.255.0
Metric: 20 IP 1.0.0.0 255.0.0.0
333 | P a g e
Above we see that R2 now shows 1.0.0.0 255.0.0.0 in its database. Let’s check its
routing table:
R2#show ip route isis
Gateway of last resort is not set
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
i su 1.0.0.0/8 [115/20], 00:02:22, Null0
i L1 1.1.1.1/32 [115/20] via 192.168.12.1, 00:05:11, GigabitEthernet0/1
R2 has created a discard route to null 0 for the 1.0.0.0/8 summary. Let’s take a look at
R3 now:
R3#show isis database level-2 verbose R2.00-00
IS-IS Level-2 LSP R2.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R2.00-00 0x00000008 0x8D33 1002 0/0/0
Area Address: 49.0012
NLPID: 0xCC
Hostname: R2
Metric: 10 IS R2.02
IP Address: 192.168.23.2
Metric: 10 IP 192.168.12.0 255.255.255.0
Metric: 10 IP 192.168.23.0 255.255.255.0
Metric: 20 IP 1.0.0.0 255.0.0.0
R3 receives R2’s LSP with the summary route so that’s what it will install in its routing
table:
R3#show ip route isis
i L2 1.0.0.0/8 [115/30] via 192.168.23.2, 00:03:29, GigabitEthernet0/1
i L2 192.168.12.0/24 [115/20] via 192.168.23.2, 00:36:20, GigabitEthernet0/1
That’s all there is to it.
1. Redistribution Summarization
Now let’s see how we can summarize redistributed routes. I will redistribute the second
loopback interface of R1 into IS-IS with a simple route-map:
R1(config)#route-map L1_ONLY
R1(config-route-map)#match interface Loopback 1
R1(config)#router isis
R1(config-router)#redistribute connected route-map L1_ONLY level-1
334 | P a g e
Without summarization, here’s what the level 1 database looks like:
R2#show isis database level-1 verbose R1.00-00
IS-IS Level-1 LSP R1.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 0x00000008 0xC75F 1180 0/0/0
Area Address: 49.0012
NLPID: 0xCC
Hostname: R1
Metric: 10 IS R2.01
IP Address: 1.1.1.1
Metric: 10 IP 192.168.12.0 255.255.255.0
Metric: 10 IP 1.1.1.1 255.255.255.255
Metric: 0 IP-External 11.11.11.11 255.255.255.255
R2 has installed this entry in its routing table:
R2#show ip route isis
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
i su 1.0.0.0/8 [115/20], 00:08:37, Null0
i L1 1.1.1.1/32 [115/20] via 192.168.12.1, 00:11:26, GigabitEthernet0/1
11.0.0.0/32 is subnetted, 1 subnets
i L1 11.11.11.11 [115/10] via 192.168.12.1, 00:00:31, GigabitEthernet0/1
Let’s summarize this redistribute route on R1. You can do this with the same summary-
address command:
R1(config)#router isis
R1(config-router)#summary-address 11.0.0.0 255.0.0.0 level-1
If you summarize into level 1, make sure you add the level-1 parameter or nothing will
happen. Let’s check the routing table of R1:
R1#show ip route isis
i*L1 0.0.0.0/0 [115/10] via 192.168.12.2, 00:43:46, GigabitEthernet0/1
11.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
i su 11.0.0.0/8 [115/0], 00:00:39, Null0
i L1 192.168.23.0/24 [115/20] via 192.168.12.2, 00:44:13, GigabitEthernet0/1
We can see that R1 has installed a discard route for this summary. Let’s check the level
1 database:
R2#show isis database level-1 verbose R1.00-00
335 | P a g e
IS-IS Level-1 LSP R1.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 0x00000009 0xD76F 1139 0/0/0
Area Address: 49.0012
NLPID: 0xCC
Hostname: R1
Metric: 10 IS R2.01
IP Address: 1.1.1.1
Metric: 10 IP 192.168.12.0 255.255.255.0
Metric: 10 IP 1.1.1.1 255.255.255.255
Metric: 0 IP-External 11.0.0.0 255.0.0.0
Above we can see that the route was summarized directly in the level 1 database. We
can find the summarized route in the routing table of R2:
R2#show ip route isis
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
i su 1.0.0.0/8 [115/20], 00:11:37, Null0
i L1 1.1.1.1/32 [115/20] via 192.168.12.1, 00:14:26, GigabitEthernet0/1
i L1 11.0.0.0/8 [115/10] via 192.168.12.1, 00:01:10, GigabitEthernet0/1
That’s it.
Want to take a look for yourself? Here you will find the final configuration of each device.
hostname R1
!
ip cef
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip router isis
!
interface Loopback1
ip address 11.11.11.11 255.255.255.255
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
ip router isis
!
router isis
net 49.0012.0000.0000.0001.00
is-type level-1
log-adjacency-changes
summary-address 11.0.0.0 255.0.0.0 level-1
redistribute connected route-map L1_ONLY level-1
!
route-map L1_ONLY permit 10
match interface Loopback1
!
336 | P a g e
end
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
ip router isis
!
interface GigabitEthernet0/2
ip address 192.168.23.2 255.255.255.0
ip router isis
!
router isis
net 49.0012.0000.0000.0002.00
log-adjacency-changes
summary-address 1.0.0.0 255.0.0.0
!
end
hostname R3
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.23.3 255.255.255.0
ip router isis
!
router isis
net 49.0003.0000.0000.0003.00
log-adjacency-changes
!
end
2. Conclusion
IS-IS supports summarization but as a link-state routing protocol, there are some
limitations. You can only configure summarization between areas or on a router that is
doing redistribution.
If you configure summarization on an area border router for routes in the level 1
database then it will add the summary route in the level 2 LSP which is advertised to
other areas. If you use redistribution, then the summary route will be added directly in
the level 1 or level 2 LSP
337 | P a g e
You might also like
- Zsiga Z Cisco Certified Design Expert CCDE 400 007 Official Cert Guide 2023100% (2)Zsiga Z Cisco Certified Design Expert CCDE 400 007 Official Cert Guide 20231,115 pages
- CCIE EI v1.1 - Deploy Lab 1 - Section 1 - 24-Nov-2023100% (1)CCIE EI v1.1 - Deploy Lab 1 - Section 1 - 24-Nov-202357 pages
- CCIE Enterprise Infrastructure FoundationNo ratings yetCCIE Enterprise Infrastructure Foundation70 pages
- CCDE In-Depth The New CCDE Book of Orhan Ergun PDF100% (1)CCDE In-Depth The New CCDE Book of Orhan Ergun PDF562 pages
- Cisco Certified DevNet Associate DEVASC 200 901 Official Cert GuideNo ratings yetCisco Certified DevNet Associate DEVASC 200 901 Official Cert Guide678 pages
- System Design Stock Trading Platforms - ScalerNo ratings yetSystem Design Stock Trading Platforms - Scaler1 page
- CCIE Enterprise Infrastructure - A Complete Guide: Authored by100% (1)CCIE Enterprise Infrastructure - A Complete Guide: Authored by655 pages
- OSPF Demystified With RFC: Request For Comments Translated Into PracticeFrom EverandOSPF Demystified With RFC: Request For Comments Translated Into Practice5/5 (1)
- Lacoste R. CCNP Enterprise Advanced Routing ENARSI 300-410... Cert Guide 2ed 2023No ratings yetLacoste R. CCNP Enterprise Advanced Routing ENARSI 300-410... Cert Guide 2ed 20232,990 pages
- IP Routing Protocols All-in-one: OSPF EIGRP IS-IS BGP Hands-on LabsFrom EverandIP Routing Protocols All-in-one: OSPF EIGRP IS-IS BGP Hands-on LabsNo ratings yet
- Implementing+Cisco+SD WAN+Solutions+ (SDWAN300) +v1100% (1)Implementing+Cisco+SD WAN+Solutions+ (SDWAN300) +v1500 pages
- CCIE EI v1.0 - Deploy - Seventh Release - 04-Jun-21100% (8)CCIE EI v1.0 - Deploy - Seventh Release - 04-Jun-21226 pages
- CCIE Enterprise Infrastructure Lab 1 Demo 2No ratings yetCCIE Enterprise Infrastructure Lab 1 Demo 252 pages
- Network Security All-in-one: ASA Firepower WSA Umbrella VPN ISE Layer 2 SecurityFrom EverandNetwork Security All-in-one: ASA Firepower WSA Umbrella VPN ISE Layer 2 SecurityNo ratings yet
- Ccie Enterprise Infrastructure Practice LabNo ratings yetCcie Enterprise Infrastructure Practice Lab7 pages
- CCIE EI v1.0 - Deploy - Final Release v1.9 - 10-August-23No ratings yetCCIE EI v1.0 - Deploy - Final Release v1.9 - 10-August-23376 pages
- OSPF Part of The CCIE EI Workbook Orhan Ergun100% (1)OSPF Part of The CCIE EI Workbook Orhan Ergun123 pages
- CCIE Enterprise Infrastructure v1.0 Real Labs Deploy Module: Lab 1:12-Mar-2021100% (1)CCIE Enterprise Infrastructure v1.0 Real Labs Deploy Module: Lab 1:12-Mar-2021104 pages
- CCIE Enterprise Infrastructure Real Lab 1 Demo 3100% (1)CCIE Enterprise Infrastructure Real Lab 1 Demo 395 pages
- (@SHZ - 0) - MPLS Lab2 Part of The CCIE EI Workbook Orhan ErgunNo ratings yet(@SHZ - 0) - MPLS Lab2 Part of The CCIE EI Workbook Orhan Ergun57 pages
- Deploying+Cisco+SD Access+ (ENSDA) + 3+No ratings yetDeploying+Cisco+SD Access+ (ENSDA) + 3+49 pages
- SD-Access Part of The CCIE EI Workbook Orhan ErgunNo ratings yetSD-Access Part of The CCIE EI Workbook Orhan Ergun42 pages
- CCIE and CCDE Evolving Technologies Study Guide PDF100% (2)CCIE and CCDE Evolving Technologies Study Guide PDF196 pages
- Download Complete CCIE Enterprise Infrastructure Foundation 2nd Edition Rough Cut Narbik Kocharians PDF for All Chapters100% (2)Download Complete CCIE Enterprise Infrastructure Foundation 2nd Edition Rough Cut Narbik Kocharians PDF for All Chapters50 pages
- Multicast Part of The CCIE EI Workbook Orhan ErgunNo ratings yetMulticast Part of The CCIE EI Workbook Orhan Ergun32 pages
- Segment Routing Work Book by Orhan Ergun LLC. Orhan Ergun LLCNo ratings yetSegment Routing Work Book by Orhan Ergun LLC. Orhan Ergun LLC25 pages
- Your Ccie Lab Success Strategy The NonTechnical GuidebookNo ratings yetYour Ccie Lab Success Strategy The NonTechnical Guidebook87 pages
- VXLAN Design With Cisco Nexus 9300 Platform Switches100% (1)VXLAN Design With Cisco Nexus 9300 Platform Switches39 pages
- Cisco Certified Architect - How To Complete The Journey From CCIE To CCDE To CCAr PDFNo ratings yetCisco Certified Architect - How To Complete The Journey From CCIE To CCDE To CCAr PDF38 pages
- Aci Troubleshooting Lab Readthedocs Io en LatestNo ratings yetAci Troubleshooting Lab Readthedocs Io en Latest45 pages
- Networkjourney CCNP Enterprise 2021 Lab Workbook 1631597584No ratings yetNetworkjourney CCNP Enterprise 2021 Lab Workbook 163159758477 pages
- Cisco Unified Communications Manager 8: Expert Administration CookbookFrom EverandCisco Unified Communications Manager 8: Expert Administration CookbookNo ratings yet
- Mastering Netscaler VPX: Learn how to deploy and configure all the available Citrix NetScaler features with the best practices and techniques you need to knowFrom EverandMastering Netscaler VPX: Learn how to deploy and configure all the available Citrix NetScaler features with the best practices and techniques you need to knowNo ratings yet
- Vmware Player 2.5: Getting Started GuideNo ratings yetVmware Player 2.5: Getting Started Guide18 pages
- TASK 4 Challenges Facing in Online EducationNo ratings yetTASK 4 Challenges Facing in Online Education20 pages
- A Simplified Dwell Time Computation Method For SVPNo ratings yetA Simplified Dwell Time Computation Method For SVP13 pages
- 3-Evolutionary Models - Prototype, Spiral and Concurrent Models-09!01!2024No ratings yet3-Evolutionary Models - Prototype, Spiral and Concurrent Models-09!01!202421 pages
- American International University-Bangladesh (AIUB) : Please Upload Your HAND WRITTEN Answers To The Following LinkNo ratings yetAmerican International University-Bangladesh (AIUB) : Please Upload Your HAND WRITTEN Answers To The Following Link2 pages
- Aim: 1. Create:: Implement Data Definition Language Commands - Create, Alter, Drop, Truncate, and RenameNo ratings yetAim: 1. Create:: Implement Data Definition Language Commands - Create, Alter, Drop, Truncate, and Rename4 pages
- Nagalakshmi - 9 Yrs - C Developer - AMD - BangaloreNo ratings yetNagalakshmi - 9 Yrs - C Developer - AMD - Bangalore3 pages
- OpenDesign Specification For .DWG Files PDFNo ratings yetOpenDesign Specification For .DWG Files PDF262 pages
