Exploring IP Routing and Ethernet Bridging.pdf

EXPLORING IP
ROUTING AND
ETHERNET BRIDGING
IPC_207
IP CONVERGENCE & IMS CURRICULUM
Award Solutions' eBook is authorized for a single user only. Do not distribute.

© 2016 Award Solutions, Inc. All Rights Reserved.
This course book and the material and information contained in it are owned by Award Solutions, Inc. (“Award Solu-
tions”) and Award Solutions reserves for itself and successors and assigns all right, title and interest in and to the
Award Content, Award Solutions’ logos and other trademarks, including all copyrights, authorship rights, moral
rights, publication and distribution rights, trademarks and other intellectual property rights. Award grants no license
or other rights in the contents of the course book or course, except as may be expressly set forth in a duly executed
written agreement between Award Solutions and the authorized user of this course book or the user’s employee or
principal. This course book shall not be modified, reproduced, disseminated, or transmitted by or in any medium,
form or means, electronic or mechanical, including photocopying, recording or any information retrieval system, in
whole or in part, without Award Solutions, Inc.’s express, prior written consent signed by an authorized officer
whose authority is evidenced by a duly signed corporate resolution.
This course book was designed for use as a student guide with the subject matter course taught by Award Solu-
tions’ authorized employees and contractors. It was not designed to be a standalone textbook. Award Solutions
makes no representations or warranties and disclaims all implied warranties with respect to the information con-
tained herein or products derived from use of such information and Award Solutions undertakes no obligation to
update or otherwise modify the information or to notify the purchaser or any user of any update or obsolescence.
To the extent permitted by applicable law, Award’s total liability in connection with the course and/or course materi-
al is the amount actually received by Award from the purchaser/user for the purchase or license of the course and
course material. This course book is not made for publication or distribution in the public domain and shall not be
published or placed in the public domain, in whole or in part, without Award Solutions, Inc.’s express, prior written
consent signed by an authorized officer whose authority is evidenced by a duly signed corporate resolution.
2100 Lakeside Blvd., Suite 300
Richardson, TX 75082 USA
Phone: +1.972.664.0727
Website: www.awardsolutions.com
If you have any questions, concerns or comments regarding this course please write to us at:
friends@awardsolutions.com
The 3GPP, LTE and LTE-Advanced logos are the property of Third Generation Partnership Project (3GPP). The
3GPP2 logo is property of Third Generation Partnership Project (3GPP2) and its organization partners. The
content of this document is based on 3GPP/LTE and 3GPP2 specifications which are available at
www.3gpp.org, and www.3gpp2.org.

Award Solutions, Inc. www.awardsolutions.com +1.972.664.0727 v16.0
About Award Solutions
AWARD SOLUTIONS, INC. has over 18 years of
training excellence in advanced wireless, IP, and network
virtualization technologies. Our products and services
provide our customers with innovative, flexible, and cost-
effective solutions that help rapidly boost workforce
productivity to more quickly meet market demands.
Our areas of expertise include:
• 4G • OpenStack
• LTE • SDN
• VoLTE • NFV
• LTE-Advanced • IP Convergence
• IMS • IPv6
• TD-LTE • Cloud
• Small Cells • M2M
• DAS • Technology Trends
The level of technical depth in our training programs gives
students unique benefits that they can apply immediately.
We offer a range of courses appropriate for audiences
needing a high-level overview, engineers looking for
technical details as well as sales and marketing teams
needing a different point of view.
Our Subject Matter Experts (SMEs) and consultants
are best-in-class, having achieved substantial industry
experience in areas such as product definition and
development, network deployment, and network and
systems engineering. We strive to help our students and
customers “become an expert”.
Award Solutions constantly keeps a finger on the pulse of
the industry, always researching new technologies, and
updating our curriculums to stay on the cutting edge.
Whether you are a training manager responsible for a large
organization, or a team lead responsible for enhancing your
team’s skills, Award Solutions can meet your technology
training needs.
We offer a multitude of delivery methods and services:
ON-SITE TRAINING: Our Subject Matter Experts
travel to your facility to engage the students in
an interactive learning experience. This is a great
option for teams with 12 or more people.
VIRTUAL TRAINING: Award Solutions embraces
different learning styles and preferences. Our
virtual trainings are conducted by our Subject
Matter Experts in real-time. This is a great option
for teams geographically dispersed.
PUBLIC TRAINING EVENTS: Award Solutions
hosts a subset of our courses in our office
and in conjunction with Industry events. This
expert-led sessions are ideal for individuals and
small groups. Visit our website at for the latest
schedule.
SELF-PACED eLEARNING: An engaging, cost-
effective solution, allowing individuals to take
training online at their own pace when their
schedule permits.
CERTIFICATIONS: Becoming an Award Certified
Expert (A.C.E.) is the best way to for a student to
demonstrate expertise, prove their ability to use
real-world industry tools, and validate that they
have the required knowledge to implement and/
or run a successful network.
If you are interested in or have any questions regarding
Award Solutions training or services, please visit Award’s
website at www.awardsolutions.com or contact us at
+1-972-664-0727 ext. 306.
OUR PROMISE
To continually demonstrate our core values: Integrity,
Expertise, Flexibility, Teamwork and Excellent Return on
Investment.

Instructor Led Training
Wireless Landscape
[FUND204] Fundamentals of RF Engineering..................2 days
4G LTE
[LTE_101] LTE Essentials.................................................... 1 day
[LTE_114] LTE-Advanced Essentials.................................. 1 day
[LTE_115] LTE RAN Performance Essentials.................... 1 day
[LTE_116] VoLTE Essentials............................................... 1 day
[LTE_205] LTE Technology Overview.................................2 days
[LTE_209] LTE Technology Overview with Public Safety Features....2.5 days
[LTE_203] VoLTE and IMS in LTE-EPC Networks.................... 3 days
[LTE_207] Exploring IMS/VoLTE Networks.......................2 days
[LTE_301] Mastering LTE Air Interface.............................2 days
[[LTE_309] Mastering TD-LTE Air Interface......................2 days
[LTE_302] LTE Protocols and Signaling............................3 days
[LTE_305] LTE-EPC Networks and Signaling....................3 days
[LTE_313] LTE-EPC Networks and Signaling (Architecture, Attach)....2 days
[LTE_310] LTE-Advanced Technical Overview..................2 days
[LTE_401] LTE RF Planning and Design Certification Workshop...5 days
[LTE_405] LTE RAN Signaling and Operations Certification....5 days
[LTE_408] LTE RAN Capacity Planning Certification Workshop....3 days
[LTE_427] VoLTE Signaling and Operations.....................3 days
[LTE_425] eMBMS Protocols and Signaling................... 1.5 days
[LTE_428] LTE Broadcast eMBMS in LTE Networks.....................1 day
[LTE_424]SON:SelfOrganizingNetworkFeaturesinLTEandLTE-Advanced...1.5days
[LTE_415] RF Design Workshop: Part 1 - LTE...................2 days
[LTE_416] RF Design Workshop: Part 2 - VoLTE and Small Cells...2 days
[LTE_418] LTE RAN Signaling and Operations: Part 1 - Attach...1.5 days
[LTE_419]LTERANSignalingandOperations:Part2–Mobility,QoS,Traffic.....1.5days
[LTE_420]LTERANSignalingandOperations:Part3-Interworking(GSM/UMTS)....1.5days
[LTE_412] LTE RF Optimization Certification Workshop (UE Based)....5 days
[LTE_421]LTERFOptimization:Part1 – CoverageandAccessibility....1.5 days
[LTE_422]LTERFOptimization:Part2–DownlinkandUplinkThroughput...1.5days
[LTE_423] LTE RF Optimization: Part 3 – Mobility and Inter-RAT...1.5 days
[LTE_413]SmallCellandVoLTERFPlanningandDesignCertificationWorkshop...4days
*
*
IP Convergence & IMS
[IPC_202] Exploring IPv6.................................................... 1 day
[IPC_203] Exploring MPLS................................................2 days
[IPC_405] IP Networking Workshop for LTE.....................4 days
[IPC_406] IP Networking Workshop for 4G Backhaul.....4 days
[IPC_407] IP Routing and Ethernet Bridging Workshop...4 days
[IPC_409] IPv6 Networking Workshop for LTE Networks....3 days
Network Virtualization
NWV_103] Big Data Essentials.......................................... 1 day
[NWV_110] API Essentials.................................................. 1 day
[NWV_120] SDN and NFV Essentials................................ 1 day
[NWV_122] SDN Essentials............................................... 1 day
OpenStack Cloud IaaS Essentials...................................... 1 day
Virtualization and Cloud Computing Essentials................ 1 day
[NWV_203] Exploring Network Functions Virtualization (NFV)....2 days
[NWV_204] Exploring Cloud, SDN, NFV............................2 days
[NWV_205] Exploring Network Virtualization, NFV, SDN, Orchestration, Cloud, and Big Data... 5 days
[NWV_206] Exploring OpenStack.....................................2 days
[NWV_704] Exploring Software-Defined Networking (SDN) for Network Operators....2 days
Exploring Virtualization and Cloud Computing.................2 days
[NWV_304] SDN and NFV Architecture and Operations...3 days
[NWV_402] Software-Defined Networking (SDN) Workshop..3 days
[NWV_403] SDN in Carrier Networks Workshop..............3 days
[NWV_406] OpenStack Workshop for SDN and NFV.......4 days
[NWV_407] NFV Application Planning and Design Workshop...3 days
[NWV_408] Scripting Workshop for SDN and NFV..........2 days
Software-Defined Networking (SDN) Troubleshooting Workshop.....2 days
Linux SysAdmin Workshop for NFV...................................3 days
[NWV_404] OpenStack Networking Troubleshooting Workshop...3 days
NFV Application Troubleshooting Workshop.....................3 days
[NWV_113] Overview of Mobile CSP Network................... 1 day
[NWV_112] Introduction to Mobile CSP Network..........0.5 day
[NWV_705] Mobile CSP Network Architecture and Operations...2 days
* New Course
TECHNOLOGY PRIMERS
[TPR1001] IoT in Wireless Networks..............................0.5 day
[TPR1002] C-RAN.............................................................0.5 day
[TPR1003] 5G Use Cases and Technology Options.......0.5 day
[TPR1004] Wi-Fi Offload, LTE-U, and LAA.......................... 0.5 day
[TPR1005] SON: Self Organzing Networks.....................0.5 day
[TPR1006] Voice over Wi-Fi (VoWiFi)..............................0.5 day
[TPR1007] Proximity Services, LTE Direct, D2D Communications....0.5 day
[TPR1008] LTE Broadcast/eMBMS................................0.5 day
*
*
*
*
*
*
*
*

Self-paced eLearning
(e) eLearning Course
IP Convergence & IMS
[IPC_103] Welcome to IP Networking (e)...........................3 hrs
[IPC_104] IP Convergence Overview (e).............................4 hrs
[IPC_106] Overview of MPLS (e)......................................3.5 hrs
[IPC_107] Overview of IMS (e)..........................................2.5 hrs
[IPC_108] Voice and Video over IP (VoIP) Overview (e).....3 hrs
[IPC_109] IP Quality of Service (QoS) (e)............................3 hrs
[IPC_110] Session Initiation Protocol (SIP) (e)...................2 hrs
[IPC_114] IP Basics (e)..........................................................1 hr
[IPC_113] IP Routing (e)........................................................1 hr
[IPC_115] QoS in IP Networks (e).........................................1 hr
[IPC_117] TCP and Transport Layer Protocols (e)................1 hr
[IPC_119] Ethernet Basics (e)...............................................1 hr
[IPC_118] Ethernet VLANs (e)...............................................1 hr
[IPC_116] Ethernet Bridging (e)............................................1 hr
[IPC_122] Ethernet Backhaul Overview (e)........................3 hrs
[IPC_120] Interconnecting IP Networks (e)..........................1 hr
[IPC_121] Welcome to IPv6 (e).............................................1 hr
4G LTE
[LTE_109] Welcome to LTE (e)..............................................1 hr
[LTE_102] LTE Overview (e).................................................3 hrs
[LTE_103] LTE SAE Evolved Packet Core (EPC) Overview (e).... 3 hrs
[LTE_111] LTE Air Interface Signaling Overview (e)...........3 hrs
[LTE_113] Overview of IPv6 for LTE Networks (e)...............3hrs
[LTE_117] eMBMS Overview (e)............................................1 hr
[LTE_118] Welcome to VoLTE (e)..........................................1 hr
[LTE_112] VoLTE Overview (e)..........................................1.5 hrs
[TRND103] Overview of OFDM (e)......................................2 hrs
[TRND104] Multiple Antenna Techniques (e).....................3 hrs
Network Virtualization
[NWTF101] Welcome to SDN (Software-Defined Networks) (e)...1 hr
[NWTF104]WelcometoMobileCSPNetworkTransformation(e)....1hr
[NWTF105] SDN Overview (e)...............................................1 hr
[NWTF106] NFV Overview (e)................................................1 hr
[NWTF107] OpenStack Cloud Overview (e)..........................1 hr
[NWTF108] API Overview (e).................................................1 hr
[NWTF109] Big Data Overview (e)........................................1 hr
[NWTF111] Cloud RAN Overview (e).....................................1 hr
[NWTF114] CSP Network Performance Overview (e)..........1 hr
[NWTF115] OpenStack IaaS Overview (e)............................1 hr
[NWTF116] Welcome to SDN and NFV I - Introductions (e).... 1 hr
[NWTF117] Welcome to SDN and NFV II - Foundations (e).... 1 hr
[NWTF118] Welcome to SDN and NFV I - Technologies (e).... 1 hr
*
*
*

API
[Application
Program Interface]
A programmatic
interface that makes
resources
software-accessible
BIG
DATA
Finding insights
by analyzing
volumes of
diverse data
ORCHESTRATION
Automating workflow
to coordinate network
functions and services
NFV
[Network Functions
Virtualization]
Running virtualized
network nodes on
commoditized
hardware
SDN
[Software-Defined
Networking]
Making networking
capabilities elastic
through centralized
control
SOFTWARE-DEFINED NETWORKS
Orchestrating elastic network functions and
services through software
AWARD SOLUTIONS’ NETWORK VIRTUALIZATION CURRICULUM
focuses on preparing you for the evolution of virtualization and the cloud-based network world.
CLOUD COMPUTING
Pooled computing resources accessed in a self-serve way

Table of Contents
Chapter 1: Prologue 1
Chapter 2: Spanning Tree Protocol 7
Broadcast Storms and STP 9
Rapid Spanning Tree Protocol (RSTP) 14
Multiple Spanning Tree Protocol (MSTP) 19
Chapter 3: Routing Table 27
Routing Table Concepts 29
The Longest Match 36
Recursive Routing 40
Black Holes 42
Chapter 4: OSPF Key Concepts 47
Areas and Router Types 50
Link State Advertisements (LSA) 53
Link State Advertisements 57
Chapter 5: OSPF in Wireless Networks 67
Neighbor Discovery 70
Metrics 75
Areas 82
Chapter 6: BGPv4 Key Concepts 89
Autonomous Systems 92
BGP Messages 96
BGP Attributes and Routing Policy 100
Route Reflectors 111
Chapter 7: BGPv4 in Wireless Networks 117
Chapter 8: L3VPN in Wireless Networks 129
Interconnecting MTSOs 131
L3VPN Architecture 135
High-Level Operations 138
Chapter 9: L3VPN Routing 147
Provider-Customer Model 149
MPLS Router 151
VPN Routing and Forwarding 154
VPN Route Distribution using MP-iBGP 160
Route Distinguisher 162
VPNv4 and IPv4 Address Families 167
Route Target 169
IPC_207 Version 2.2c

L3VPN Routing 172
Acronyms 185
References 189

1 | Prologue
Chapter 1:
Prologue
Award Solutions Proprietary
1

1 | Prologue
Objectives
After completing this module, you will be able to:
• Explain why IP is the data transport of choice for
today’s carrier networks
• Explain the Customer-Provider Model and its use of
Layer 3 VPNs
• Describe the customers found in a carrier’s
implementation of the Customer-Provider Model
• List the routing protocols used in the typical
implementation of L3VPNs
2

The Customer-Provider model uses Layer 3 Virtual Private
Network (L3VPNs) to provide private network services to a
set of customers. The customer networks include a
Customer Edge (CE) router that connects to the service
provider’s Provider Edge (PE) router. The CE and PE
routers exchange routing information, using Border
Gateway Protocol (BGP). The PE routers use MPLS to
forward packets through the backbone and BGP to
distribute the customer routes to other VPN locations.
The L3VPN solution is widely deployed. It is easy for
customers to send data throughout their respective sites,
while at the same time being scalable and manageable
for the service provider. For these reasons, L3VPNs are
used in carrier networks to isolate traffic between
customers and services.
While the terms customer and provider evoke a
commercial relationship, this is not necessarily the case in
a carrier environment. The customer networks represent
subsystems within the larger network, interconnected
through a transport backbone.
1 | Prologue
Site A
Customer 1
CE
Customer 2
CE
Customer 3
CE
Site C
Site
B
Site
D
Customer-Provider Model
Customer 1
CE
Customer 2
CE
Customer 3
CE
Provider
PE PE
Customer 1
CE
Customer 2
CE
Customer 3
CE
PE
Customer 1
CE
Customer 2
CE
Customer 3
CE
PE
P
P
P
P
3

Wireless service providers adopt the L3VPN solution as a
means to manage their networks. The makeup of the
customer networks varies according to service provider
policies, but some generalities may be discussed. The
service provider may choose to implement different
wireless network technologies (e.g., UMTS, EVDO, LTE) as
customer networks. They may also choose to implement
different network services (e.g., voice, Internet access, IP
Multimedia Subsystem (IMS)) as customer networks. Or
they may also use them to segregate Operations,
Administration and Maintenance (OAM) connections or
inter-connectivity with Internet peering or roaming
partners.
The customer networks are present throughout the
service provider’s facilities, including local Mobile
Telephone Switching Offices (MTSO), regional Network or
Data Centers and national Network or Data Centers.
1 | Prologue
MTSO
MTSO
MTSO
MTSO
3G Voice
CE
3G Data
CE
4G Data
CE
Segregating Services
Core
PE
PE
PE
PE
P
P
P
P
IMS
CE
OAM
CE
Peering
CE
3G Voice
CE
3G Data
CE
4G Data
CE
IMS
CE
OAM
CE
Peering
CE
4

The customer networks run an interior gateway routing
protocol such as the Open Shortest Path First (OSPF). The
Core runs an interior gateway routing protocol as well to
distribute routes between the PE and P routers. The CE
and PE routers run eBGP to exchange customer routing
information. This routing information is subsequently
passed from one PE router to another PE using Multi-
Protocol BGP (MP-BGP) to distribute customer routes
throughout the network.
1 | Prologue
L3VPN Routing Protocols
5

1 | Prologue
Summary
• Wireless equipment at the cell site used T1s as transport before the
use of IP.
• IP interfaces in wireless networks carry user data, OA&M data and
signaling data.
• The Customer-Provider Model implements L3VPNs to segregate the
data traffic of individual customers.
• The customer networks found in a carrier’s network can include
networks belonging to individual customers, networks belonging to
technologies such as LTE and UMTS, and networks belonging to
particular traffic types such as OA&M.
• In a network that implements Layer 3 VPNs (L3VPNs), eBGP is used
between CEs and PEs to exchange customer routes, MP-BGP is used
between PEs to distribute the customer routes, and OSPF is used
between the PEs and P for internal core routing exchanges.
6

2 | Spanning Tree Protocol
Chapter 2:
Spanning Tree Protocol
7

Objectives
• Explain how the Spanning Tree Protocol protects
networks from broadcast storms
• Select the best Spanning Tree Protocol for a
given network
• List the differences between STP, RSTP, and
MSTP
• Describe the significance of the root switch to
the Spanning Tree Protocol
8

Broadcast Storms and
STP
9

Several version of spanning tree protocols have been
developed over the years. The most significant are:
Spanning Tree Protocol (STP)
The first Spanning Tree Protocol published as a standard
by the Institute of Electrical and Electronic Engineering
(IEEE) in 802.1d-1990. It is generally no longer used in
service provider environments as it takes too long to
discover and react to changes in the network topology. It
also predates the existence of virtual LANs (VLANs).
Rapid Spanning Tree Protocol (RSTP)
As its name implies, RSTP revamps the operation of the
spanning tree protocol to reduce the time it takes to
detect and react to changes in the topology. It does not,
however, incorporate support for VLANs. RSTP was first
published in 802.1w-2001, but was later incorporated
into 802.1d-2004.
Rapid Per-VLAN Spanning Tree Protocol Plus (Rapid-
PVST+)
Rapid-PVST+ represents the an evolution in a series of
spanning tree protocols developed by Cisco Systems, Inc.
It incorporates the performance improvements of RSTP
and includes support for VLANs. It is used in networks that
run only Cisco equipment, and is not widely supported by
other equipment vendors.
Multiple Spanning Tree Protocol (MSTP)
The latest version of the spanning tree protocol
standardized by the IEEE, originally published as 802.1s-
2002 and later incorporated into 802.1q-2005. MSTP
builds on the capabilities of RSTP and includes support for
multiple VLANs. One notable difference between MSTP
and Rapid-PVST+ regards the number of spanning tree
instances that run in the switch. Rapid-PVST+ requires
one spanning tree instance per VLAN, while MSTP allows
many VLANs to be mapped onto a single spanning tree.
MSTP therefore operates more efficiently when large
numbers of VLANs are configured. MSTP also supports
hierarchical network design with the concept of a region.
Topology changes affect the switches in the region, but
are invisible to switches outside of the region. This allows
for more efficient operation in large-scale networks.
Spanning Tree Protocols
•Legacy STP, now obsolete
•Recovery time < 1 minute
•Does not support VLANs
STP
•Recovery time < 1 second
•Does not support VLANs
RSTP
•Cisco proprietary
•One spanning tree per VLAN
Rapid-PVST+
•Latest open standard
•Multiple VLANs share one spanning tree
•Supports hierarchical network design
MSTP
10

Broadcast storms may occur whenever a loop exists in the
Ethernet LAN topology. The figure illustrates a simple case
in which a loop exists between two Ethernet switches. The
sequence of events unfolds as follows:
1. The node on the left sends a broadcast frame. SW1
receives it on port gi0/1.
2. Whenever an Ethernet switch receives a broadcast
frame, it forwards the frame out all active ports,
except the one on which the frame was received. In
this case, SW1 forwards the frame out ports gi0/2
(shown in red) and gi0/3 (shown in green).
3. SW2 receives two broadcast frames. Ethernet does
not provide any means to determine that these are, in
fact, two copies of the same original frame, so SW2
must process each one independently. It receives one
frame (red) on port gi0/7 and forwards it out ports
gi0/6 and gi0/8. It receives the other frame (green)
on port gi0/8 and forwards it out gi0/6 and gi0/7.
The node on the right receives two copies of the
frame.
4. SW1 receives two broadcast frames. Ethernet
provides no means to determine that these are
copies of the frames that it recently forwarded on to
SW1, so it must process them again. It receives one
frame (green) on port gi0/2 and forwards it out ports
gi0/1 and gi0/3. It receives the other frame (red) on
port gi0/3 and forwards it out ports gi0/1 and gi0/2.
The node on the left receives two copies of the frame
that it originally sent.
The frames are now stuck in the loop. Ethernet has no
concept of a frame identifier, so the switches do not
recognize that they are processing the same frame again
and again. Ethernet also does not have a timeout
mechanism, so the switches continue processing the
frames in this manner forever. And each iteration through
the loop causes additional copies of the frame to be
made, so the storm consumes an increasing amount of
bandwidth, buffer space and processing time.
Broadcast Storms
Loops cause broadcast storms
bcast bcast
bcast bcast
bcast bcast
bcast bcast
bcast bcast
bcast bcast
gi0/2
gi0/1
gi0/3
gi0/7
gi0/6
gi0/8
bcast
bcast bcast
bcast bcast
bcast
bcast
bcast
bcast
bcast
bcast
bcast
bcast
SW1 SW2
11

Broadcast storms may be prevented (or managed) by
avoiding large, complex Ethernet networks in the first
place. Service providers may choose to strategically
deploy IP and MPLS to minimize the reach of the Ethernet
topology. Where Ethernet is used, designing loop-free
networks (i.e., tree topology) also eliminates the
conditions in which storms may occur. Most Ethernet
switches also implement some form of storm control
mechanisms wherein the broadcast traffic gets throttled.
Storm control features minimize the damage caused by
broadcast storms, but do not prevent them outright.
Finally, spanning tree protocols can also be used to
automatically patrol the network for loops. When a loop is
detected, the spanning tree protocol automatically
disables some links in order to break the loop.
Broadcast Storm Prevention
1. Prefer IP and MPLS over Ethernet
for large networks
2. Avoid loops in Ethernet topology
3. Storm Control
4. Spanning Tree Protocols
Backhaul
Router
CE
CE
CE
CE
PE
PE
12

When Spanning Tree Protocol is used, the switches in the
network exchange messages that enable them to detect
loops that would otherwise cause broadcast storms. They
then select one or more ports to be blocked in order to
simplify the logical topology of the network such that it
resembles a tree. The switches do not forward user traffic
through a blocked port. The net result is that the loop is
broken and the conditions for a broadcast storm are
eliminated.
Spanning Tree Protocol
Before After
13

Rapid Spanning Tree
Protocol (RSTP)
14

The Spanning Tree Protocol selects one switch to serve as
the root of the logical tree topology. The root switch
election process governs which switch gets selected as
the root and ensures that all switches make the same
selection. The procedure is relatively straightforward. Each
switch has a unique identifier. The switch with the lowest
identifier becomes the root. The identifier is a combination
of a priority value and the switch’s MAC address. By
default, all switches use the same priority value, so the
root switch election boils down to which switch has the
numerically lowest MAC address.
Choosing the root switch based solely on the MAC address
is fairly arbitrary, but the loop detection procedures work
regardless of which switch gets elected to be the root. The
administrator may influence the outcome, however, by
overriding the default priority value and setting it to
something lower than the default value. The other
switches then select it as the root switch.
The figure illustrates the process of overriding the default
priority value to select the root switch. If we let all of the
switches use the default priority value of 32768, then the
switch in the center would become the root switch, since it
has the numerically lowest address. By changing the
priority of the switch at the top of the figure, we ensure
that it wins the root switch election.
The Root Switch
Root Switch Election
• ID = Priority + Address
• By default, all switches use same priority value
• Override default priority value to specify root switch
32768
+ AABB:1122:0001
32768
+ AABB:1122:0003
32768
+ AABB:1122:0002
32768
+ AABB:1122:0005
32768
+ AABB:1122:0004
32768
+ AABB:1122:0006
8192 32768
+ AABB:1122:0007
15

The spanning tree algorithm assigns a cost to each switch
port based on the speed of the link. Faster links cost less.
The spanning tree algorithm also calculates the root path
cost for each switch port. This is defined as the sum of the
port costs between it and the root switch. When the
spanning tree detects a loop, it uses the root path cost to
determine which ports should carry traffic and which
should be blocked.
Shortest Path Selection
Shortest Path Selection
• Port Cost = assigned based on link speed (range: 1 to 200M)
• Root Path Cost = sum of port costs of shortest path to root switch
1
Cost: 2000 Cost: 2000
Cost: 2000
Cost: 2000
Root Path Cost: 6000
Root Path Cost:
6000
Root Path Cost:
4000
16

The spanning tree algorithm assigns each switch port a
specific role to play. It selects one port on each switch to
be the root port for that switch. This port provides the
most optimal path to the root switch (i.e., the lowest root-
path cost). The algorithm also selects one port on each
LAN segment to be the designated port for that segment.
Any remaining ports are designated alternate ports. Root
ports and designated ports forward user traffic. Alternate
ports discard user traffic.
The spanning tree algorithm only assigns the alternate
port role when a loop exists in the network’s topology. This
is the heart of the algorithm’s loop-detection function. The
loop is broken because the alternate port discards user
traffic. When a node in the LAN sends a broadcast frame,
it floods the network through root and designated ports,
but gets dropped by alternate ports.
Port Role Assignment
Port Roles
• Root Port = per switch, shortest path to root switch; forwards traffic
• Designated Port = per segment, shortest path to root; forwards traffic
• Alternate Port = alternate, but less optimal path to root switch; discards
traffic
1
Designated Port
Root Port
Alternate Port
32768
+ AABB:1122:0001
32768
+ AABB:1122:0003
32768
+ AABB:1122:0002
32768
+ AABB:1122:0005
32768
+ AABB:1122:0004
32768
+ AABB:1122:0006
8192
+ AABB:1122:0007
17

When a switch detects the loss of a Physical Layer signal,
the spanning tree algorithm re-assesses the port role
assignments in light of the new connectivity. If it
determines that a change is necessary, it sends a
proposal of the new role to its neighboring switch. The
neighboring switch re-assesses its own port roles based
on this new information and may agree or, if it believes it
has better insight into the topology, issue a counter-
proposal. Changing the role of one port on the switch may
cause a ripple effect throughout the network. The
proposal/agreement exchanges propagate in a link-by-link
fashion away from the failure toward the root switch until
it reaches a switch for whom the new proposal does not
require any changes.
In the figure shown, the link that connects the center
switch to the root switch fails. This had been the center
switch’s root port. The precise details of the operation go
beyond the scope of this discussion, but the loss of the
root port forces the center switch to change the remaining
port’s role from designated port to root port. The bottom-
most switch changes its root port to a designated port and
must therefore unblock one of its alternate ports. In this
example, the root path cost is the same for both alternate
ports, so the port priorities are considered. Similar to the
root switch priority, the administrator can influence the
selection of the root switch by modifying the default
priority value. If both ports have the same priority value,
then the numerical port identifier is used to break the tie.
The bottom-most switch sends a proposal to the
neighboring switch (on its left in the figure). The proposal
does not require it to change any of its port roles, so the
configuration changes stop there. The network has re-
converged on the new topology.
One task remains, however. Remember that each of the
switches in the network maintains a MAC table that
associated MAC addresses with port numbers. Some of
that information is now out of date. The root switch sends
a Topology Change Notification, which the other switches
use as a signal to flush stale data from their MAC tables.
Topology Changes
Topology Changes
• Nodes detect link failure through Physical Layer, or message timeout
• Proposal and agreement process updates port roles
• Topology Change Notification tells switches to flush MAC tables
1
Designated Port
Root Port
Alternate Port
Link Fails
DP becomes RP
RP becomes
DP
AP becomes RP
Proposal/
Agreement
Proposal/
Agreement
18

Multiple Spanning Tree
Protocol (MSTP)
19

The figure illustrates a hypothetical Ethernet backhaul
network design. In this design, each cell site is assigned a
unique VLAN ID. The cell site links enter the Mobile
Telephone Switching Office (MTSO) and connect to a set
of access switches. Each access switch carries traffic for
ten cell sites. Two access switches, designated SWA and
SWB are shown in the diagram. The others are omitted
due to lack of space. The access switches connect to a
pair of aggregation switches, SWC and SWD, which in turn
connect to a Multi-Layer Switch (MLS) that acts as
backhaul router. The spanning tree protocol manages the
redundant links between the access and aggregation
switches.
Multiple VLAN Sample Topology
MLS
SWC
SWA
SWB
SWD
Aggregation switches
Access switches
Spanning Tree manages
redundant links
20

Let’s assume that the MLS is the root switch in our sample
topology. When the spanning tree algorithm runs, each
access switch selects a root port and an alternate port.
The root path costs are the same for both ports (assuming
of the same links are the same speed), so the selection of
the root and alternate ports is fairly arbitrary. In the figure
shown, the top-most port on SWA remains active, while the
bottom-most port gets blocked. SWB does just the
opposite of this.
Spanning Tree Results
MLS
SWC
SWA
SWB
SWD
Designated Port
Root Port
Alternate Port
21

When redundant links are deployed in the network,
service providers often prefer a load-balancing solution to
a strict active/standby scheme. When multiple VLANs are
used, this can be accomplished by directing some VLAN
traffic (for example, the even-numbered VLANs) across
one of the redundant links and other VLAN traffic (for
example, the odd-numbered VLANs) across the other
redundant link.
Referring back to our sample topology, let us focus on the
links that connect access switch SWA to the aggregation
switches SWC and SWD. SWA carries traffic for 10 VLANs
(one per cell site). If RSTP is used to manage these links,
then load balancing is not possible. When RSTP computes
the spanning tree, the traffic for all 10 VLANs is carried
over the active link. The blocked link remains idle. This is
because RSTP does not support the notion of computing
multiple spanning trees.
Alternatively, one could use PVSTP+ instead. As its name
implies, Rapid PVSTP+ computes one spanning tree
solution for each VLAN configured on the switch. There
would therefore be 10 spanning trees in our example. By
overriding the default port priorities, we could arrange for
half of the spanning trees to select the top-most port to be
the root port and the bottom-most port to be the alternate
port. We could configure the other half of the spanning
trees to do just the opposite. The net effect is that the
traffic would be evenly divided (assuming the cell sites
were equally loaded) across the two links. If either of the
links failed, then the spanning trees would react by
unblocking the alternate port and all traffic would be
directed over the remaining link.
Load Balancing with VLANs
• MSTP
– Efficient load balancing
– Two spanning trees (one blocks port 1, the other blocks port 2)
– Half of the VLANs get mapped to one spanning tree; half get mapped to the other
• PVSTP+
– Less efficient load balancing ; one spanning tree per VLAN
– Half of the VLANs block port 1; the other half block port 2
• RSTP
– Single spanning tree, active/idle configuration, no load balancing
MLS
MSTP = Two Spanning Trees
SWC
SWA
SWD
MLS
SWC
SWA
SWD
22

While Rapid PVSTP+ achieves the goal of balancing the
traffic load, it does so at a certain cost. SWA needs to
maintain 10 separate spanning tree instances. Each
spanning tree instance introduces some processing,
memory and messaging overhead. Note, however, that in
our sample topology, there are really only two possible
spanning trees. The fact that Rapid PVSTP+ requires one
spanning tree per-VLAN means that it creates five
separate copies of each of the two possible spanning
trees. This is where MSTP offers some advantages over
RSTP and Rapid PVSTP+.
MSTP allows us to define spanning tree instances and
then associate those instances with a set of VLANs. In our
case, we would create the two spanning tree instances,
overriding the port priorities so that they choose different
root ports, and then map five VLANs onto each of the two
instances.
Load Balancing with VLANs (Continued)
• MSTP
– Efficient load balancing
– Two spanning trees (one blocks port 1, the other blocks port 2)
– Half of the VLANs get mapped to one spanning tree; half get mapped to the other
• Rapid PVSTP+
– Less efficient load balancing ; one spanning tree per VLAN
– Half of the VLANs block port 1; the other half block port 2
• RSTP
– Single spanning tree, active/idle configuration, no load balancing
MLS
MSTP = Two Spanning Trees
SWC
SWA
SWD
MLS
SWC
SWA
SWD
23

MSTP supports a form of hierarchical network design by
introducing the concept of a region. A region is a collection
of switches that share a common view of their physical
and logical topology. Collectively, the switches in the
region appear as a single, virtual switch to the switches
outside of the region. When a topology change occurs
within the region, the switches inside the region re-
converge on the new topology. The switches outside the
region remain unaware of, and unaffected by, the topology
change.
MSTP regions allow the Ethernet LAN to grow in scale and
complexity without adversely affecting the performance of
the error detection and recovery procedures.
MSTP Regions
24

Summary
• Spanning Tree Protocol (STP) prevents loops
from triggering broadcast storms in Layer 2
networks.
• Rapid Spanning Tree Protocol (RSTP)
significantly reduces the time to detect and
recover from a failure.
• Multiple Spanning Tree Protocol (MSTP) adds
support for VLANs.
• MSTP provides an efficient means to load
balance VLAN traffic across multiple links.
25

The figure illustrates a hypothetical Ethernet backhaul
network. Based on the priority and addresses shown,
which switch is selected as root switch by the Spanning
Tree Protocol? What could you do to ensure that the MLS
becomes the root switch?
Review Exercise
MLS
SWC
SWD
SWA
32768 + e05f:b903:5280
32768 + e05f:b903:535a
32768 + e05f:b903:4653
SWB
32768 + e05f:b903:1121
32768 + e05f:b903:9863
32768 + e05f:b903:af3c
32768 + e05f:b903:753a
32768 + e05f:b903:5280
32768 + e05f:b9c3:a2d0
32768 + e05f:b93f:d9ea
32768 + e05f:b9c3:7719
26

3 | Routing Table
Chapter 3:
Routing Table
27

3 | Routing Table
Objectives
• Read and understand IP routing tables
• Understand the factors that go into the route
selection algorithm
• Identify the preferred route from a set of
alternates
• Employ recursive routing techniques
• Explain how black holes impact routing and why
a packet might be deliberately discarded
28

3 | Routing Table
Routing Table
Concepts
29

The routing table is essentially a collection of network
addresses that the router knows how to reach. For a given
inbound packet, the routing table indicates to which node
it should forward the packet (the next hop) and/or the
outbound interface it should use to get there. The routing
table entries may contain additional information used to
prioritize routes, indicate their origin and how long they’ve
been around.
Routing table entries come from one of three possible
sources. The most straightforward source of routes are
the router’s own network interfaces. If we configure an
interface with the address 192.168.1.1/24, then it stands
to reason that the router knows how to reach the nodes
on the 192.168.1.0/24 subnet. Similarly, so-called static
routes can be created by explicitly configuring the routes
on the router. Finally, the router can use a dynamic routing
protocol such as OSPF and BGPv4 to exchange routing
information with other routers.
It’s worth noting that the routing table is only one
repository of routing information. Individual routing
protocols maintain databases that contain routing
information they’ve learned from neighboring routers. And
while it’s convenient to talk about the router searching the
routing table when it receives a packet, modern routers
copy the contents of the routing table into a more
optimized data structure, typically called the Forwarding
Information Base (FIB).
3 | Routing Table
Routing Table Concepts
Routing Table
Destination Source Cost Next Hop
0.0.0.0/0 Static 1 192.168.1.1
192.168.1.0/24 Connected 2 Gi 0/0
10.1.1.0/22 OSPF 10 10.5.3.8
172.16.0.0/16 BGP 20 192.168.7.30
Forwarding
Information
Base
Sources
Static
Connected
Dynamic
30

This sample routing table is used to discuss the concepts
and structure that make up the routing table.
3 | Routing Table
Routing Table Example
R1# show ip route
B 216.238.54.0/24 [20/0] via 12.123.1.236, 4w4d
O 216.221.5.0/24 [110/1] via 12.123.1.236, 7w0d
136.141.0.0/24 is subnetted, 2 subnets
S 136.141.6.0 [1/0] via 12.122.125.4, 7w0d
R 136.141.2.0 [120/0] via 12.122.125.4, 7w0d
B 170.162.32.0 [20/0] via 12.123.1.236, 7w0d
O 170.160.32.0 [110/1] via 12.122.125.4, 7w0d
O 170.160.64.0 [110/1] via 12.123.1.236, 3d15h, fa0/1/1
187.179.0.0/16 is variably subnetted, 3 subnets, 2 masks
B 187.179.0.0/19 [20/0] via 12.123.1.236, 13:51:40, gi0/1
B 187.179.32.0/19 [20/0] via 12.123.1.236, 4w3d
S 187.179.64.0/18 [1/0] via 12.123.1.236, 4w3d
S 34.254.244.0/22 [1/0] via 12.122.125.4, 7w0d
S 34.254.112.0/21 [1/0] via 12.122.125.4, 7w0d
S 34.253.0.0/19 [1/0] via 12.123.1.236, 7w0d
31

The routing table is organized into two tiers.
Level 1 routes serve as routes only as shown in the first
line of the example above or they may serve as indexes to
the Level 2 routes listed below them as seen in the third
line of our example. When a router searches for a match
to a particular destination address, it first searches the
Level 1 routes. If it finds a match, then it searches the
Level 2 routes for a more specific match.
A Parent Route is a Level 1 route that has Level 2 routes
beneath it. A Child Route is a Level 2 route. The router
automatically adds Parent Routes to the routing table
when Child Routes are created.
The basis of this two-tier hierarchy is classful routing which
has been replaced by Classless Inter-Domain Routing
(CIDR). This hierarchy is useful for quickly searching the
routing table and does not mean that the network
employs classful addressing or that the router uses
classful routing.
3 | Routing Table
Parent and Child Routes
R1# show ip route
B 216.238.54.0/24 [20/0] via 12.123.1.236, 4w4d
O 216.221.5.0/24 [110/1] via 12.123.1.236, 7w0d
S 136.141.6.0 [1/0] via 12.122.125.4, 7w0d
R 136.141.2.0 [120/0] via 12.122.125.4, 7w0d
B 170.162.32.0 [20/0] via 12.123.1.236, 7w0d
O 170.160.32.0 [110/1] via 12.122.125.4, 7w0d
O 170.160.64.0 [110/1] via 12.123.1.236, 3d15h, fa0/1/1
B 187.179.0.0/19 [20/0] via 12.123.1.236, 13:51:40, gi0/1
B 187.179.32.0/19 [20/0] via 12.123.1.236, 4w3d
S 187.179.64.0/18 [1/0] via 12.123.1.236, 4w3d
S 34.254.244.0/22 [1/0] via 12.122.125.4, 7w0d
S 34.254.112.0/21 [1/0] via 12.122.125.4, 7w0d
S 34.253.0.0/19 [1/0] via 12.123.1.236, 7w0d
Level 1 Route
Level 1/Parent Route
Level 2/Child Route
32

The prefix length sets the range of addresses that a route
applies to. For example, if a network is listed as
10.10.10.0/24, the route applies to destination IP
addresses in the range from 10.10.10.0 to
10.10.10.255. If the network is listed as 10.10.10.0/28,
the route applies to IP addresses in the range of
10.10.10.0 – 10.10.10. 15. All routes in a routing table
must have a prefix length in order to determine the range
of addresses that the route applies to. The range for each
route is not necessarily unique. The ranges for
10.10.10.0/28 is wholly contained in the range for
10.10.10.0/24. If you examine the sample routing table,
some routes do not have route prefixes, for example,
136.141.6.0 [1/0] via 12.122.125.4, 7w0d and
136.141.2.0 [120/0] via 12.122.125.4, 7w0d.
<COLUMN BREAK HERE>
The presence or absence of the prefix length in the
example table is determined by the rules below.
Level 1 with no Children
Level 1 route has its own prefix length.
Level 1 with Children
• Case 1: All Children have same prefix length.
― Level 1 route lists the prefix length, Child Routes
do not list prefix lengths.
• Case 2: Children have different prefixes.
― Prefix lengths are listed for each Child and the
Level 1 route uses the classful prefix for the
network.
3 | Routing Table
Prefix Length
R1# show ip route
B 216.238.54.0/24 [20/0] via 12.123.1.236, 4w4d
O 216.221.5.0/24 [110/1] via 12.123.1.236, 7w0d
S 136.141.6.0 [1/0] via 12.122.125.4, 7w0d
R 136.141.2.0 [120/0] via 12.122.125.4, 7w0d
B 170.162.32.0 [20/0] via 12.123.1.236, 7w0d
O 170.160.32.0 [110/1] via 12.122.125.4, 7w0d
O 170.160.64.0 [110/1] via 12.123.1.236, 3d15h, fa0/1/1
B 187.179.0.0/19 [20/0] via 12.123.1.236, 13:51:40, gi0/1
B 187.179.32.0/19 [20/0] via 12.123.1.236, 4w3d
S 187.179.64.0/18 [1/0] via 12.123.1.236, 4w3d
S 34.254.244.0/22 [1/0] via 12.122.125.4, 7w0d
S 34.254.112.0/21 [1/0] via 12.122.125.4, 7w0d
S 34.253.0.0/19 [1/0] via 12.123.1.236, 7w0d
Prefix in Level 1 Route
Prefix in Level 2 Route
33

Route Code
The route code indicates the source of the routing
information. The meaning of the codes is given at the top
of the routing table when working with the device. In our
example here, B=BGP, O=OSPF, S=Static, and R=RIP.
Connected routes (not shown here) are listed with a C and
Local routes (AKA Host routes) are listed with an L. Host
routes represent the router’s own IP addresses and carry
a 32-bit prefix length.
Administrative Distance
The administrative distance is a precedence value
assigned to the route, based on the source of the routing
information. Some sources of routing information are
considered more trustworthy than others, and have a
lower administrative distance. If the same route is learned
through multiple sources, the one with the lowest
administrative distance gets installed into the routing
table.
Metric
Each route is assigned a metric to show the relative cost
of using the particular route. Metrics act as tie breakers
when the router must select between routes for the same
destination network, which were learned from the same
dynamic routing protocol. Most routing protocols allow
Equal Cost Multi-Path (ECMP) and allow multiple routes to
the same destination network having the same metric to
be installed in the routing table. Traffic matching these
routes is load-balanced across the ECMP routes. ECMP
adds overhead to the forwarding function of a router as
the router must track which data stream is using which of
the routes. Administrators can set the maximum number
of ECMP routes that are allowed per destination network.
The metric may also be manipulated by an administrator
to prefer one ECMP route over another.
Next-Hop Address
The next-hop address identifies the IP address of the
device to which the router sends packets that match the
route. The next-hop address is typically the IP address of
the router that provided the route.
3 | Routing Table
What’s in a Route?
R1# show ip route
B 216.238.54.0/24 [20/0] via 12.123.1.236, 4w4d
O 216.221.5.0/24 [110/1] via 12.123.1.236, 7w0d
S 136.141.6.0 [1/0] via 12.122.125.4, 7w0d
R 136.141.2.0 [120/0] via 12.122.125.4, 7w0d
B 170.162.32.0 [20/0] via 12.123.1.236, 7w0d
O 170.160.32.0 [110/1] via 12.122.125.4, 7w0d
O 170.160.64.0 [110/1] via 12.123.1.236, 3d15h, fa0/1/1
B 187.179.0.0/19 [20/0] via 12.123.1.236, 13:51:40, gi0/1
B 187.179.32.0/19 [20/0] via 12.123.1.236, 4w3d
S 187.179.64.0/18 [1/0] via 12.123.1.236, 4w3d
S 34.254.244.0/22 [1/0] via 12.122.125.4, 7w0d
S 34.254.112.0/21 [1/0] via 12.122.125.4, 7w0d
S 34.253.0.0/19 [1/0] via 12.123.1.236, 7w0d
Route Code
Admin.Distance/Metric
Next-Hop Address
34

In general, when a router knows more than one route to a
particular destination, it prefers the one with the lowest
metric. This can be a problem when the routes were
learned from different sources because the metrics that
one routing protocol uses may not be consistent with the
metrics used by other routing protocols. For example, BGP
uses the number of Autonomous Systems (ASs) in its Path
Vector as a metric, while OSPF metrics are based on
bandwidth. Relying solely on route metrics, the router
would not be able to select the best possible routes.
The router uses the Administrative Distance to select the
best possible route from among a set of alternate routes
that were learned from different routing sources. The
administrative distance is determined by the source of
routing information. Routing information sources with
lower administrative distance values are preferred over
those with higher administrative distance values.
Unlike the route metric, the administrative distance is not
set on a per-route basis. All routes from a particular
routing information source share the same administrative
distance value. For example, all routes learned by OSPF
have 110 as the administrative distance value. The
administrative value is a configuration parameter set
within the router and is not exchanged by the routing
protocols (also unlike the route metrics).
Routing protocols with lower administrative distances are
deemed to be more reliable, accurate or trustworthy than
those with higher administrative distances. The table
shown here lists the default administrative values used by
Cisco routers. The defaults can be overridden, however, if
one wishes to change the relative rankings.
Finally, it’s worth noting that the administrative distance
determines which routes actually get installed in the
routing table. Typically multiple routes to the same
destination network (as specified by network address and
prefix length) from different routing protocols are not
found in routing tables. Whichever one has the lower
administrative distance causes the others to be bumped
from the routing table.
Source: “What is Administrative Distance?”, Document ID:
15986, Cisco.
3 | Routing Table
Administrative Distance
Source Administrative Distance
Connected 0
Static 1
EIGRP summary route 5
eBGP 20
Internal EIGRP 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
ODR 160
External EIGRP 170
iBGP 200
<Unknown> 255
35

3 | Routing Table
The Longest Match
36

A packet has arrived with destination address
66.134.50.11. The router has the following three routes
installed in its routing table.
• 66.0.0.0/8 next-hop 10.10.10.1 gi0/1
• 66.134.0.0/18 next-hop 12.13.14.5 gi0/22
• 66.134.48.0/20 next-hop 62.34.24.33 gi0/3
The prefix length indicates the range of addresses
covered by the route. Here is the range for each of the
routes.
• 66.0.0.0/8 has range 66.0.0.0 – 66.255.255.255
• 66.134.0.0/18 has range 66.134.0.0 –
66.134.63.255
• 66.134.48.0/20 has range 66.134.48.0 –
66.134.63.255
Our destination address, 66.134.50.11 falls into each of
these three ranges. When a router discovers more than
one possible route for the packet it bases the forwarding
decision on the Longest-Match Rule.
3 | Routing Table
Finding the Right Route
Route
Prefix
Length
Range of Addresses
Is
66.134.50.11
in this range?
66.0.0.0 /8 66.0.0.0 – 66.255.255.255
66.134.0.0 /18 66.134.0.0 – 66.134.63.255
66.134.48.0 /20 66.134.48.0 – 66.134.63.255
Source IP: 12.12.134.19
Destination IP: 66.134.50.11
37

The Longest-Match Rule says that when multiple routes
contain the destination address in their ranges, the one
with the longest prefix length is the route to use.
Examining our prefix lengths we have /8, /18/ and /20.
The /20 is the longest prefix length and the route
66.134.48.0/20 is the route used for forwarding the
packet.
A route is said to match the packet’s destination address
if the packet’s destination address has the same network
prefix as the route. In other words, the route matches if
the first n bits of the packet’s destination address match
the first n bits of the route entry, where n is the route’s
prefix length. The bits in the destination address must
match exactly the bits in the network prefix of the route.
3 | Routing Table
Longest-Match Rule
Destination IP
66.134.50.11
01000010 10000110 00110010 00001011
S 66.0.0.0/8 01000010 00000000 00000000 00000000
Destination matches 8 bits
B 66.134.0.0/18 01000010 10000110 00000000 00000000
O 66.134.48.0/20 01000010 10000110 00110000 00000000
Longest-Match Rule: the route matches if the first n bits of the
packet’s destination address match the first n bits of the route
entry, where n is the route’s prefix length.
38

The Longest-Match requires that the destination’s prefix
match the network prefix exactly. Enter the route number
in the space provided for each of the destination IP
addresses.
What happens if there is no matching route for the
destination IP address?
3 | Routing Table
Longest-Match Exercise
1 66.0.0.0/8 0100 0010 0000 0000 0000 0000 0000 0000
2 66.134.0.0/18 0100 0010 1000 0110 0000 0000 0000 0000
3 66.134.48.0/20 0100 0010 1000 0110 0011 0000 0000 0000
Which Route (above) do these Destination IPs use?
66.128.12.31 0100 0010 1000 0000 0000 1100 0001 1111
66.134.64.222 0100 0010 1000 0110 0100 0000 1101 1110
66.134.46.76 0100 0010 1000 0110 0010 1110 0100 1100
39

3 | Routing Table
Recursive Routing
40

The router needs two pieces of information to forward a
packet to the next device in the path toward its
destination: the next-hop address and the exit interface. If,
after searching the routing table, the preferred route
identifies only the next-hop address, but not the exit
interface, the router searches the routing table a second
time to locate a suitable exit interface.
In the example given above, the router receives a packet
with a destination address of 10.1.0.5. Its first pass
through the routing table selects the 10.1.0.4/30 route as
the preferred route. This entry includes the next-hop
address, 172.16.4.2, but not the exit interface. The router
searches the routing table a second time for a route to
172.16.4.2. It finds the 172.16.4.0/30 route and
determines that fa0/1/2 is the exit interface.
This recursive search could have been avoided if the
10.1.0.4/30 route had included both a next-hop address
and an exit interface. This is useful to remember,
especially when configuring static routes. Specifying both
the next-hop address and the exit interface reduces the
amount of processing required to forward the packets.
3 | Routing Table
Recursive Routing
P1#show ip route
10.0.0.0/30 is subnetted, 2 subnets, 2 masks
10.1.0.4 [110/2] via 172.16.4.2, 00:02:56
172.16.4.0 is directly connected, fa0/1/2
P1#show ip route
10.0.0.0/30 is subnetted, 2 subnets, 2 masks
10.1.0.4 [110/2] via 172.16.4.2, 00:02:56, fa0/1/2
172.16.4.0 is directly connected, fa0/1/2
fa 0/1/2
Dst: 10.1.0.5
172.16.4.2 10.1.0.5
1
2
1
Next Hop
address
Exit
Interface
Next Hop
address
Exit
Interface
41

3 | Routing Table
Black Holes
42

The term black hole refers to the case when a router
receives a packet, but cannot forward the packet and the
packet is dropped. This action results in a routing black
hole, analogous to the theoretical astronomical
phenomenon of a region in space with a gravitational pull
such that nothing, not even light, can escape.
There are several reasons why black holes – in the IP
networking sense – might occur.
• Routing Errors – A packet arrives, the router finds no
route and discards the packet. If the router is allowed
to send ICMP messages, it notifies the sender using
an Internet Control Message Protocol (ICMP)
“Destination Network Unreachable” message.
• MTU Problems – If the Maximum Transmission Unit
(MTU) of the outbound link is too small to
accommodate the packet, and if the packet’s “Don’t
Fragment” bit is set, the router drops the packet and
send an ICMP “Fragmentation Required” message
indicating what the MTU must be to send the packet
through the interface.
• Intentional Discard – In some circumstances, the
routing table includes a null route (also known as
black hole route). Any incoming packets that that
match that route are discarded. This is an appropriate
way to deal with malicious traffic, for example. An
Intrusion Prevention System (IPS) may dynamically
create a null route when it detects suspect activity.
ICMP messages are usually suppressed in this case,
so as to conceal the countermeasures from the
attacker.
3 | Routing Table
Black Holes
• Network forwards
packets to a router
• Router drops the
packets
• Possible reasons:
– Routing Error
– MTU Error
– Intentional Discard
• “Black Hole” Route:
R(config)#ip route 10.1.1.1 255.255.255.0 null0
43

3 | Routing Table
Summary
• There are three sources of routes: directly connected
interfaces, static routes, and dynamic routing protocols.
• Routing table organization is as follows: Level 1 and Level 2
routes; Parent and Child Routes.
• Administrative distance, the longest-match rule and route
metrics are used to select from among multiple alternate
routes.
• Routing table entries have a next-hop address, metric and
(optionally) exit interface.
• Recursive routing may be used when the route table entry
does not specify an exit interface.
44

3 | Routing Table
Review Questions
Use the table on the following page to answer the
questions below.
1. How many Level 1 routes are in this table?
2. How many routes were learned through dynamic
routing protocols?
3. The router receives a packet with the destination
address 172.16.0.1. Which interface does the
router send the packet out?
4. The router receives a packet with destination
address 20.15.0.4 Which interface does the
router send the packet out?
45

3 | Routing Table
Review
P1#show ip route
Codes: C - connected, S - static, R - RIP, B – BGP, O - OSPF
C 140.30.19.0 is directly connected, gi0/1
B 20.0.0.0/8 [20/0] via 140.30.19.110, 00:04:17
C 66.134.48.0 is directly connected, gi0/0
C 172.16.60.0 is directly connected, fa0/1/6
O 172.16.0.0 [110/2] via 172.16.4.2, 00:02:56, fa0/1/0
O 10.1.4.1/32 [110/2] via 172.16.4.2, 00:02:56, fa0/1/0
O 10.1.0.4/30 [110/2] via 172.16.4.2, 00:02:56, fa0/1/0
46

4 | OSPF Key Concepts
Chapter 4:
OSPF Key Concepts
47

Objectives
After completing the module, you will be able to:
• Describe how OSPF relates to Autonomous
Systems and other routing protocols.
• Describe the design of scalable networks using
OSPF areas
• Describe the role of Area Border Routers (ABRs)
• List the types of Link-State Advertisements that
OSPF uses to communicate routing information
48

The Open Shortest Path First (OSPF) protocol is a widely
used interior gateway protocol. It is a mature protocol,
defined by the Internet Engineering Task Force (IETF)
standard specification, Request for Comment (RFC) 2328.
OSPF runs within a single Autonomous System (AS). OSPF
routers collect information about the AS topology, known
generically as Link State Advertisements (LSAs). The
routers store this information in a Link State Database
(LSDB) and use it to calculate least-cost routes to each of
the destinations in the AS. These routes loaded into
routing tables.
OSPF quickly detects changes to the AS topology (such as
interface failures), updates the LSDB, recalculates the
cost of the routes and updates the routing tables.
OSPF Areas allows OSPF to perform more efficiently over
large networks. Without OSPF areas, OSPF would not scale
well as the size and complexity of the Autonomous System
grows. The Link State Database (LSDB) would expand,
increasing the amount of memory that OSPF needs to
function. The number of Link State Advertisements (LSA)
sent would increase, worsening the messaging overhead
added by the protocol. The Shortest Path First algorithm
would run more frequently and need to consider greater
numbers of alternate paths, increasing the amount of
processing that OSPF performs.
OSPF areas provide scalability by dividing the autonomous
system into logical subsystems. Each router learns the
detailed topology of its own area, but not that of other
areas. Instead, the Area Border Router (ABR) originates a
Summary-LSA into the area on behalf of all the routers
outside of the area.
All routers in a single area have identical LSDBs. ABRs
have a LSDB for each area that they participate in.
Open Shortest Path First (OSPF)
• Interior Gateway Protocol
• Link State Protocol
• Bandwidth → Link cost
• IETF Standard (RFC 2328)
• Uses Areas to subdivide the
autonomous system
OSPF Area 1
OSPF Area 0
OSPF Area 2
AS 100
BGP
AS 300
BGP
49

Areas and Router
Types
50

OSPF defines a special area called the backbone. The
backbone is always be area 0 (alternately written as
0.0.0.0). All other areas must connect to the backbone.
This acts as a transit network for inter-area traffic. The
non-backbone areas send routing information to the
backbone, which in turn distributes the information to the
other non-backbone areas.
If an area does not contain a physical interface to the
backbone network, a logical backbone connection may be
formed by configuring what’s called a virtual link.
The Backbone Area: Area 0
• Backbone Area = Area 0
• All areas must connect to backbone area
• Distribute inter-area routes
Area 1
Area 0
Area 2
51

OSPF defines four types of routers: Internal Routers,
Backbone Routers, Area Border Routers, and Autonomous
System Boundary Routers. Depending on their function, a
given router may be of one or more of these types.
The simplest type of router is an internal router. If all of a
router’s interfaces are part of the same area, then that
router is said to be an internal router.
A router with at least one interface that is part of the
backbone area is a backbone router. If all of the router’s
interface are part of the backbone area, then that router
could be considered both a backbone and internal router.
The Area Border Router (ABR) contains interfaces on at
least two different areas. The ABR originates Summary-
LSAs into the backbone containing a summary of the non-
zero area’s intra-area routes. It originates Summary-LSAs
into the non-zero area containing a summary of the AS’s
inter-area routes.
The Autonomous System Boundary Router (ASBR)
exchanges routing information with other Autonomous
Systems (ASs). This may be through a different routing
protocol, such as the Border Gateway Protocol (BGP) or
through static configuration. They originate External-AS
Link State Advertisements (LSAs) to communicate these
external routes throughout the AS.
OSPF Router Types
AS 300
Area Border Router
(ABR)
Internal Router
ASBR, ABR and
Backbone Router
Backbone Router
AS 400
AS 100
Backbone Router
Internal and
Autonomous
System Boundary
Router (ASBR)
ASBR and
Backbone Router
Area 1 Area 2
Area 0
AS 200
52

Link State
Advertisements (LSA)
53

The router maintains a Link State Database (LSDB) for
each area to which it belongs. The contents of the LSDB
are flooded to all of the routers in the area. Each of the
routers in the area eventually build an exact replica of the
area’s LSDB. The LSDB is a representation of the topology
of the area. It identifies the routers and networks in the
area, the links that interconnect them and the cost of
those links.
The contents of the LSDB are Link State Advertisements
(LSA). The LSDB holds four types of LSAs:
1. Router-LSAs. Each router originates a Router-LSA that
describes the state of the its interfaces.
2. Networks-LSAs. The network’s designated router
originates a Network-LSA that contains a list of
routers connected to that network.
3. Summary-LSAs. The area border router originates a
Summary-LSA that contains routes to destinations
outside the area, but inside the autonomous system.
4. External-LSAs. The autonomous system boundary
router originates an External-LSA that contains routes
to destinations outside the autonomous system.
Using the information in the chart, draw the network
topology for the local area that contains 11 routers and
three networks. The numbers indicate the metrics on the
given links between the connected nodes or networks. For
example, the 0 in the row and column that link Network 3
with Router 7 indicate that Router 7 connects to Network
3 and from Network 3 to Router 7 the cost is 0. However,
look at the link from Router 7 to Network 3 and the cost is
2. There is no cost associated with coming out of a
network. Costs are incurred when leaving routers.
Link State Database
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 N1 N2 N3
R1 3 0 0
R2 5 5 5 0
R3 5
R4 5
R5 5
R6 3 0 0
R7 4 4 4 0
R8 4
R9 4
R10 4
R11 3 3
N1 3 3
N2 1 1
N3 2 2
Using the information in
this LSDB, draw the
topology of the local
network.
54

Draw the network based on the LSDB on the previous
page.
Draw the Network
55

This network is based on the LSDB given in the exercise. It
is in an OSPF network. Your drawing on the previous page
should look similar.
The Network
N3 2
2 4
4
4
1
R2
R4
R3
R1
R5
R7 R9
R8
R6
R10
N2
N1 3
3
5
5
5
1
R11
3 3
56

Link State
Advertisements
57

All OSPF routing information is exchanged in the form of a
Link State Advertisements (LSA). An LSA is a piece of
routing information that may describe a router, a physical
interface or a range of addresses, along with an
associated cost. The LSA specifies its originating router, its
age in seconds (which allows old routing information to
expire) and a sequence number (used to detect duplicate
LSAs).
There are 11 types of LSAs. The type of LSA depends on
the type of router creating the LSA.
Link State Advertisement
Link State
Advertisement
(LSA)
Router-LSA
(Type 1)
Network-LSA
(Type 2)
Summary-LSA
(Type 3, 4)
External-LSA
(Type 5, 7)
Opaque-LSA
(Type 9,10,11)
58

Each router in the Autonomous System originates a
Router-LSA. The Router-LSA indicates whether the router
is an ASBR or ABR. It includes a list of the router’s links,
the cost of each link, as well as other information such as
the link’s address. The Router-LSA gets distributed to
each of the routers in the area, but the ABR does not
forward the Router-LSA across area boundaries.
Type 1 Router-LSA
Area 1
Router-LSA = Type 1
Link State ID: 192.168.50.1
No of Links=2
Link 1 Cost , Type and other Details
Link 2 Cost , Type and other Details
Neighbor List
Generated by each router in the AS Area-scope
Link State ID is set to Router ID
59

A Network-LSA is originated for each broadcast or Non-
Broadcast Multiple Access (NBMA) network in the
autonomous system (but not for point-to-point links). It
includes a list of routers attached to the network and the
subnet address and mask assigned to the network. When
there are multiple OSPF router connected to the network,
only one of them, the Designated Router, sends the
Network-LSA. The Network-LSA gets distributed to each of
the routers in the area, but the Area Border Router (ABR)
does not forward the Network-LSA across area
boundaries.
Type 2 Network-LSA
Area 1
Network-LSA = Type 2
Subnet Mask = 255.255.255.0
RID of Attached Router-R1
Generated by Designated Router Area-scope
Link State ID is set to DR Interface Address
R1 (DR)
R3 R4
Point-to-Point Link
Network-LSA = Type 2
Subnet Mask = 255.255.255.0
R2
10.2.1.100/24
NW: 10.2.1.0/24
60

The Area Border Router (ABR) does not forward Router-
LSAs or Network-LSAs from one area to the next. Instead,
the ABR originates a Summary-LSA that, as its name
implies, summarizes the routing information for that area.
The ABR may originate separate Summary-LSAs for each
of the networks to be advertised, or it may condense
multiple networks into a single Summary-LSA by
advertising a single network address with a shorter
network prefix. When a router receives a Summary-LSA, it
computes a new cost to the target by adding in the cost of
the path between that router and the ABR. When an ABR
receives a Summary-LSA sent from some other ABR, it
does not forward the Summary-LSA across area
boundaries.
In the example shown, the ABR receives four Network-
LSAs from within Area 1. The ABR has been configured to
condense these into a single Summary-LSA that it
originates into Area 0. It sets the cost of the summary
route to be the largest cost of its individual component.
Type 3 Summary-LSA
Area 0
Summary-LSA = Type 3
Subnet Mask = 255.255.252.0
Metric = 10
Generated by ABR Area-scope
Link State ID is set to Advertised Network Address
Cost = Advertised Cost + Cost to ABR
Area 1
10.1.1.0/24 Cost: 3
10.1.2.0/24 Cost: 5
10.1.3.0/24 Cost: 10
10.1.4.0/24 Cost 8
Network-LSA
Subnet Mask = 255.255.255.0
ABR
61

The Area Border Router (ABR) generates an Autonomous
System Boundary Router (ASBR) Summary-LSA for each
ASBR in its area. This includes the cost of the path from
the ABR to the ASBR. The router may choose to use this
information to calculate the total cost to reach a
destination outside of the Autonomous System. When an
ABR receives an ASBR Summary-LSA from some other
ABR, it does not forward it across area boundaries.
Type 4 ASBR Summary-LSA
Area 1
ASBR Summary-LSA = Type 4
Subnet Mask = 0.0.0.0
Metric = 22
Generated by ABR Area-scope
Link State ID is set to ASBR Router ID
For External Type 1 routes, add cost to ASBR
For External Type 2 routes, store as-is in Routing Table
Area 0
R7
(RID 192.168.50.7)
AS 100
ASBR
62

When the Autonomous System Boundary Router (ASBR)
wants to import a route from other routing processes to an
external destination into the Autonomous System (AS), it
originates an AS-External-LSA. This includes the network
address and mask of the external destination and the next
hop address of the external link. The AS-External-LSA gets
flooded throughout the AS.
The cost of the external route may be one of two types.
Type 1 costs use the same units as other OSPF LSAs. The
Shortest Path First algorithm may make a meaningful
comparison between the Type 1 cost of the AS-External-
LSA and the costs learned through other types of LSAs.
Type 2 costs are expressed using some other type of units
that are not compatible with the metrics used by the AS.
These other units are assumed to be significantly larger
than those used by the AS, such that the Shortest Path
First algorithm always selects a path with a cost expressed
in Type 1 units over a path expressed in Type 2 units.
Type 5 AS-External-LSA
AS External-LSA = Type 5
Link State ID: 10.0.0.0/16
Metric = 20
Metric = 20
Area 0
Metric = 20
Link State ID is set to Advertised Network Address
ASBR generates 1 AS External-LSA per route imported for the whole AS
Distributed transparently without any modification within AS
Includes the Next Hop IP address of the external link in the LSA
Area 1
AS 100
eBGP
10.0.0.0/16
10.1.0.0/16
10.2.0.0/15
ASBR
Metric = 20
Metric = 20
Metric = 20
63

The Opaque-LSA type was introduced as a means to
extend OSPF to carry application-specific data. It provides
the means to carry a generic chunk of data, the exact
form and function of which is known only to the
application that defines it. For example, the Traffic
Engineering application defines a type of Opaque-LSA. In
this application, the LSA carries bandwidth reservation
information associated with the link.
Three types of Opaque-LSAs have been defined. Link-local
opaque-LSAs (type 9) is sent to routers attached to the
specified network and not forwarded beyond that point.
Area-Local opaque-LSAs (Type 10) are forwarded to all
routers in the area, but not forwarded across area
boundaries. AS-local opaque-LSAs (Type 11) are
forwarded to all routers in the Autonomous System.
Types 9 – 11 Opaque-LSA
AS 300
AS 400
AS 100
Area 1
Area 2
Area 0
AS 200
N1
Opaque-LSA
Network-scope
Opaque-LSA
Area-scope
Opaque-LSA
AS-scope
64

Summary
• OSPF is used to exchange routing information
between routers within an Autonomous System.
• OSPF uses Link-State Advertisements to
communicate information about the topology of the
network.
• Routers store Link-State Advertisements in the
Link-State Database.
• Each router in an area maintains its own copy of
the Link-State Database.
• OSPF routers learn details about the topology of
their area, but not that of other areas.
65

The figure illustrates a sample OSPF network. It highlights
four of the routers (R4, R8, R12 and R13). What type of
routers are these? (Hint: a single router may be of more
than one type.)
Your choices are: internal router, backbone router, Area
Border Router (ABR), Autonomous System Boundary
Router (ASBR).
Orlando St. Petersburg
Tampa
Review Exercise
R1
R4
R6
R5
R3
R7
N1 N2 R9 R11
R10
R8
R12
R2
R14
R16
R15
R13
R17
N3 R18
Area 1 Area 2
Area 3
BGP
R8:
R13:
BGP
R19
R12:
R4:
66

5 | OSPF in Wireless Networks
Chapter 5:
OSPF in Wireless
Networks
67

Objectives
• Describe the operations of an OSPF router
• Troubleshoot OSPF adjacency issues
• Analyze the contents of the link-state database
• Calculate OSPF link metrics to influence routing
decisions
• Use OSPF areas to build scalable networks
68

An OSPF-capable router spends its life performing the
following functions.
• OSPF routers automatically discover the existence of
neighboring routers.
• Having discovered a new neighbor, the two routers
synchronize their Link State Databases (LSDBs).
• Once the topology of the network is known (through
the LSDB), the router runs a Shortest Path First (SPF)
algorithm to calculate the optimal path to reach each
of the known destinations in the network.
• The “best” path information is merged with other
routing information (e.g., static routes and other
dynamic routing protocols) to create routing table.
• When changes occur in the network topology (e.g.,
links are enabled or shutdown), the router updates its
neighbors by sending a Link State Advertisement
(LSA). Of course, the router may also re-run the SPF
calculations to determine the impact of the topology
change and update the routing table accordingly.
• OSPF routers keep tabs on their neighbors. If the
router suddenly stops receiving keep-alive messages,
it assumes that the neighbor has gone off-line,
updates the LSDB accordingly, re-runs the SPF
algorithm and adjusts the routing table as necessary.
Life of an OSPF Router
Neighbor
Discovery
Synchronize
LSDB
Compute SPF
Populate
Routing Table
Send LSA
Keep-Alive
69

Neighbor Discovery
70

Whenever possible, OSPF relies on the automatic
discovery of neighboring routers, rather than having them
administratively configured. An OSPF router periodically
sends a “Hello” message to the multi-cast address
224.0.0.5. This is a well-known address to which all OSPF
routers are supposed to be listening.
The router does not necessarily exchange routing
information with each one of its neighbors. It only does so
with so-called adjacent neighbors. The Hello message
includes several configuration data: the router identifier,
area identifier, hello interval, dead interval and subnet
prefix. The two neighboring routers must agree on each of
these parameters if they are to form an adjacency and
exchange routing information. The Hello message also
includes the list of neighboring routers that are already
known to this router. This is used to confirm that the
neighbor heard your Hello message (i.e., to confirm that
two-way communication exists).
Neighbor Discovery
• Hello message
– Send periodically
– Multicast: 224.0.0.5
• Includes
– Router ID
– Area ID
– Hello Interval
– Dead Interval
– Subnet Prefix
– Neighbor List
71

The Hello protocol is used to discover new OSPF
neighbors, verify that two-way communication is in place,
communicate information about the router’s configuration
and confirm that the neighbor remains active over time.
The router sends a Hello message every HelloInterval
seconds (10 seconds is typical). The router sends the
Hello message to the well-known multicast address
224.0.0.5. The router includes the Area ID, the sending
router’s own Router ID and a list of Router IDs from whom
the sending router has received a Hello message. The
message also contains authentication credentials, the
network mask of the interface, the value of the
HelloInterval and RouterDeadInterval timers, the Router ID
of the Designated Router and a priority value used in the
Designated Router election procedure.
In the example shown, Router R1 has been sending Hello
messages every HelloInterval seconds. Router R2 comes
online starts running OSPF. It starts sending its own Hello
messages. Router R1 hears the Hello message that
Router R2 has sent. It adds R2 to its list of neighbors and
includes R2’s Router ID when it sends its next Hello
message. Likewise, Router R2 hears the Hello message
that Router R1 has sent. It notes that its own Router Id
was included in the message. Router R2 now knows that
two-way communication is possible with this neighbor. R2
adds R1 to its list of the neighbors and includes R1’s
Router Id in the next Hello message that it sends. Router
R1 notes that its Router ID has been included in Router
R2’s hello message. Router R1 now knows that two-way
communication is possible with R2.
The two routers analyze the fields in the Hello messages.
If their respective area ID, network mask, HelloInterval,
and RouterDeadInterval fields match, they may attempt to
form an adjacency with each other and begin to
synchronize their Link State Databases.
Hello Protocol
R1 R2
Hello
Area ID, Router ID, Neighbor List
Hello
Area ID, Router ID, Neighbor List (R2)
Hello
R2 powers on and
sends first Hello
R1 hears Hello
and adds R2 to
neighbor list
Hello
Area ID, Router ID, Neighbor List (R1)
R2 hears Hello
and adds R1 to
neighbor list
Hello
72

Having established an adjacency with each other, the two
neighboring routers synchronize their LSDBs. They first
send a series of Database Description messages. These
messages summarize the contents of the LSDB and
include enough information for the neighbor to determine
whether it already knows the Link State Advertisements
(LSAs) contained within. If the router learns about a new
LSA that is not in its LSDB, or sees that a more recent
copy of an LSA is available, it sends a Link State Request
message, indicating that it wants to know the details
about the LSAs. The first router then sends the requested
LSAs in a Link State Update message.
The figure illustrates the process by which router R1
synchronizes its database with router R2. Router R2 also
synchronizes its database with router R1, but this is not
shown in the illustration.
Database Synchronization
Link State Request
Please send me these LSAs…
R1 R2
LSDB LSDB
Database Description
These are the LSAs in my LSDB
Link State Update
Here are the LSAs you asked for…
73

Consider the effects of the neighbor discovery procedure
on a multiple-access network with six routers. Each router
would discover five neighbors and form five adjacencies.
Fifteen adjacencies would be formed overall. The
Designated Router (DR) concept reduces the number of
adjacencies required in this circumstance, and by
extension reduces the size of the Link State Database
(LSDB) and the number of OSPF messages sent over the
network.
The Hello protocol includes a mechanism by which the
routers autonomously determine which router functions as
the DR. The administrator can influence this decision by
assigning certain priorities to each of the routers. Once a
DR has been elected for the network, it generally does not
change unless the DR goes out of service. To facilitate a
fast recovery from that circumstance a Backup
Designated Router (BDR) is elected at the same time as
the DR. If the DR should go out of service, the BDR takes
over as DR and a new BDR is elected.
Instead of forming adjacency with every neighbor on the
network, a router instead forms an adjacency with only the
DR and BDR. In the example configuration shown, the
total number of adjacencies that form is reduced from 15
to 9.
Designated Router (DR)
R1 R2 R3
R4 R5 R6
R1 (DR) R2 (BDR)
R3
R4
R5 R6
Multi-Access
Network with
6 OSPF
Routers
With DR and BDR Election
Adjacencies = 2N-3
Adjacencies = (2*6)-3=9
R1 R2
R3
R4
R5 R6
Designated Router is
Elected to Reduce
Adjacencies
Backup Designated Router
is also elected for fast
takeover from DR’s Failure
No DR and BDR Election
Adjacencies = N*(N-1)/2
Adjacencies = 6*(6-1)/2 = 15
74

Metrics
75

OSPF automatically assigns a cost to each of the links in
the network based on the bandwidth of the link. It
calculates this cost by selecting a fixed value known as
the reference bandwidth, and then dividing the reference
bandwidth by the bandwidth of the link. The minimum cost
that can be assigned to a link is 1. It is important that
each of the routers in the network use the same reference
bandwidth in order to accurately compare routes.
OSPF Metric
Interface
Type
Speed
(Mbps)
Cost
ref = 100 Mbps ref = 1 Gbps ref = 10 Gbps
10GE 10000 1 1 1
OC-192c 9953.28 1 1 1
OC-48c 2488.32 1 1 4
GigE 1000 1 1 10
OC-12c 622.08 1 1 16
OC-3c 155.52 1 6 64
Fast Ethernet 100 1 10 100
Ethernet 10 10 100 1000
Reference Bandwidth
Link Speed
OSPF Cost =
76

Exercise
Calculate the cost for the T3 and T1 links.
Interface Type
Speed
(Mbps)
Cost
ref = 100 Mbps ref = 1 Gbps ref = 10 Gbps
10GE 10000 1 1 1
OC-192c 9953.28 1 1 1
OC-48c 2488.32 1 1 4
GigE 1000 1 1 10
OC-12c 622.08 1 1 16
OC-3c 155.52 1 6 64
Fast Ethernet 100 1 10 100
Ethernet 10 10 100 1000
T3 44.736
T1 1.544
77

Each router in the network uses the information in its link
state database to execute the Shortest Path First (SPF)
algorithm and calculate the most optimal route to each
destination in the network. The SPF algorithm uses the
costs that were assigned to each of the links. The cost of
the route is the sum of the link costs that make up the
route.
The figure illustrates four switching offices: Orlando, St.
Petersburg, Tampa and Boca. Each switching office has
an edge router (R3, R8, R13 and R18) that connects to
the backbone for the region (R1 and R2). Additionally,
each edge router connects directly to two neighboring
offices (for example, R3 in Orlando connects to R8 in St.
Petersburg and R13 in Tampa).
Shortest Path First
Orlando
1
R4
R6
R5
R3
R7
N1 3
3
5
5
5
1
St. Petersburg
N2 2
2 4
4
4
R9 R11
R10
R8
R12
2
Tampa
1
R14
R16
R15
R13
R17
N3 3
3
5
5
5
Boca
2
2 4
4
4
N4 R19 R21
R20
R18
R22
1 1
1 1
2
R1
R2
78

The Shortest Path First algorithm produces a tree of
shortest paths to each router and network in the area,
with the router itself as the root of the tree. The router
only needs to know the next hop for each of the
destinations to forward packets. These next hops are
loaded into the routing table.
The figure illustrates the results of the Shortest Path First
algorithm when run on router R3 (we’ve also abbreviated
the diagram by only showing the paths to each office’s
edge router). The table illustrates the set of next hops that
are loaded into the routing table.
Shortest Path First
R3
1
R18
R13
R8
R2
R1
1
1
2
1
1
2
1
1
R3
1
R18
R13
R8
R2
R1
1
1
1
1
Before After
Destination Next Hop
R8 R8
R1 R1
R13 R13
R2 R13
R18 R13
79

It is possible that the Shortest Path First algorithm
identifies multiple paths to a destination with the same
cost value. When that happens, multiple paths may be
loaded into the routing table (assuming they have
different next hops) and traffic is distributed equally
across each of them.
We can illustrate this by changing the cost of the R1-R2
and R8-R18 links. If these two links each have a cost of
one, then router R3 calculates multiple equal-cost paths
to routers R2 and R18. To send packets to router R2, R3
could forward packets to router R1 or R13. Each path has
a cost of two. To send packets to R18, R3 could forward
packets to R8 or R13. Each path has a cost of two.
Equal-Cost Multipath
After
R3
1
R18
R13
R8
R2
R1
1
1
1
1
1
1
Destination Next Hop
R8 R8
R1 R1
R13 R13
R2 R13
R2 R1
R18 R13
R18 R8
80

The figure illustrates four switching offices: Orlando, St.
Petersburg, Tampa and Boca. Each switching office has
an edge router (R3, R8, R13 and R18) that connects to
the backbone for the region (R1 and R2). Additionally,
each edge router connects directly to two neighboring
offices (for example, R3 in Orlando connects to R8 in St.
Petersburg and R13 in Tampa).
Assign a cost to each of the links indicated such that the
following two conditions are met:
1. Each edge router (R3, R8, R13 and R18) processes
only traffic that originates or terminates inside its
respective office. They do not process so-called
transit traffic that both originates and terminates
outside their respective offices.
2. Each edge router shall direct traffic destined for an
adjacent office over the direct link to that office.
When properly configured, traffic that runs from Orlando
to St. Petersburg goes over the R3-R8 link. Traffic that
runs from Orlando to Tampa traverses the R3-R13 link.
Traffic that runs from Orlando to Boca passes through the
backbone, R3-R1-R2-R18.
Tampa Boca
SPF Exercise
R1
R4
R6
R5
R3
R7
N1 3
3
5
5
5
N2 2
2 4
4
4
R9 R11
R10
R8
R12
R2
R14
R16
R15
R13
R17
N3 3
3
5
5
5
2
2 4
4
4
N4 R19 R21
R20
R18
R22
81

Areas
82

The figure illustrates the amount of routing information
that would be exchanged if the sample network presented
earlier in the chapter were implemented as a single OSPF
area. Since we did not subdivide the Autonomous System
into areas, each router receives all of the Link State
Advertisements (LSAs) that are generated in the network.
So each router keeps a copy of the Link State Database
(LSDB), which holds 26 LSAs (22 Router-LSAs, 4 Network-
LSAs). Whenever a topology change occurs, the LSA must
be propagated to each router, which in turn must re-
execute its Shortest Path First algorithm.
Example Network (No Areas)
R1
Orlando
1
R4
R6
R5
R3
R7
N1 3
3
5
5
5
1
St. Petersburg
N2 2
2 4
4
4
R9 R11
R10
R8
R12
2
R2
Tampa
1
R14
R16
R15
R13
R17
N3 3
3
5
5
5
Boca
2
2 4
4
4
N4 R19 R21
R20
R18
R22
1 1
1 1
2
Total: 22 SPF Processes, 22 LSDBs and 572 LSAs
Each Router:
1 SPF, 1 LSDB, 26 LSAs
83

If we were to subdivide our example network into areas,
as illustrated here, then we could reduce the amount of
work that OSPF must do. The routers within each of the
offices (internal routers) still exchange full topology
information with each other. So they store five Router-Link
State Advertisements (LSAs) and 1 Network-LSA in their
Link State Databases (LSDBs). In addition, their Area
Border Router (ABR) generates a Summary-LSA for each
of the other four areas. Likewise, the routers inside the
backbone area (Area 0) store six Router-LSAs and four
Summary-LSAs in the LSDB. The ABR routers have two
LSDB: a copy of the Area 0 LSDB and a copy of the non-
zero area LSDB.
The net effect of this configuration is fewer OSPF
messages being sent through the network, a reduction in
the size of the LSDB, and faster computations of routing
table updates.
Tampa Boca
Example Network (with Areas)
R1
1
R4
R6
R5
R3
R7
N1 3
3
5
5
5
1
N2 2
2 4
4
4
R9 R11
R10
R8
R12
2
R2
1
R14
R16
R15
R13
R17
N3 3
3
5
5
5
2
2 4
4
4
N4 R19 R21
R20
R18
R22
1 1
1 1
2
Total: 26 SPF Processes, 26 LSDBs and 240 LSAs
Area 1 Area 2
Area 3 Area 4
Internal Routers:
ABR:
2 SPF, 2 LSDBs & 19 LSAs
Backbone Router:
84

The area boundary is also a good place to implement
route summarization. In the figure shown, each of the
areas contains several /24 subnets. When the Area
Border Router (ABR) sends the Summary-LSA, it could list
each /24 subnet individually. But let’s say that the routers
in area 1 experience an outage that causes the
10.1.1.0/24 subnet to become unavailable. The routers
inside area 1 would send link-state updates to notify each
other of the change in the topology. And because the ABR
had previously included the 10.1.1.0/24 subnet in its
Summary-LSA, the ABR would also have to send a link-
state update to reflect the change in status. The updated
Summary-LSA would be forwarded throughout the
autonomous system so that each router updates its link-
state database.
Rather than advertise each of the /24 subnets
individually, the ABR could instead summarize them
together and include a single /16 subnet in its Summary-
LSA. Then, if an outage occurred in the 10.1.1.0/24
subnet, the ABR does not have to update its Summary-
LSA. The impact of the outage is contained within Area 1.
Tampa Boca
Area Summarization
R1
R4
R6
R5
R3
R7
N1
10.1.3.0/24
N2 R9 R11
R10
R8
R12
R2
R14
R16
R15
R13
R17
N3 N4 R19 R21
R20
R18
R22
Area 1 Area 2
Area 3 Area 4
Summary-LSA:
10.1.0.0/16
10.1.0.0/24
10.1.1.0/24
10.1.2.0/24
10.3.3.0/24
10.3.0.0/24
10.3.1.0/24
10.3.2.0/24
10.2.3.0/24
10.2.2.0/24
10.2.1.0/24
10.2.0.0/24
10.4.3.0/24
10.4.2.0/24
10.4.1.0/24
10.4.0.0/24
Summary-LSA:
10.3.0.0/16
Summary-LSA:
10.1.0.0/16
85

Summary
• The OSPF Hello protocol drives the neighbor
discovery process.
• On broadcast networks, OSPF routers form
adjacencies with the designated router.
• Adjacent neighbors exchange link-state databases.
• The Link-State Database (LSDB) stores Link-State
Advertisements (LSAs).
• All routers in an area share the same LSDB.
• Area Border Routers send Summary-LSAs on behalf
of the area.
• OSPF metrics are calculated based on link speed.
86

Review Questions
1. The Area Border Router (ABR) may perform which of the following
functions?
a) Send Summary-LSAs on behalf of the area.
b) Connect the routers in the area to the OSPF backbone.
c) Form an OSPF adjacency with each of the routers in the area.
d) Route summarization by advertizing a single route that
encompasses all of the area’s routes.
2. When an OSPF router forms an adjacency with a neighbor:
a) It always receives a complete copy of the neighbor’s Link-State
Database.
b) It uses a Summary-LSA to send an abbreviated copy of its Link-State
Database to the neighbor.
c) It uses the neighbor’s Hello messages as a keep-alive mechanism.
d) It sends a Link-State Update message to notify the other routers in
the area that an adjacency has been formed.
87

Review Exercise
ASBR
Backbone Area
ABR
Internal Router
Backbone Router
Non-Backbone Area
Connects OSPF backbone area
and a non-backbone area
Connects two different AS
All Links fall in the same area
At least one link in Area 0
Set of links falling other than
Area 0
Set of links falling in Area 0
Match the columns.
88

6 | BGPv4 Key Concepts
Chapter 6:
BGPv4 Key Concepts
89

Objectives
• Define an Autonomous System
• Differentiate between iBGP and eBGP
• Describe how BGP attributes can be used to
implement routing policy
• List some of the most significant BGP attributes
• Describe the BGP messages for session
establishment
• Use Route Reflectors to build scalable BGP
networks
90

The figure illustrates a hypothetical network that consists
of six switching offices in California. Each switching office
contains a 3G data network and a 4G data network. They
would likely contain other networks too, but these two are
sufficient for our discussion. Three of the larger offices
also serve as Internet peering points. The San Francisco
office connects to an Internet Service Provider (ISP) called
Alpha Corp; San Jose connects to an ISP called Beta Net;
and Sacramento connects to an ISP called Charlie Com.
The six switching offices connect to an MPLS core
network.
Sample Network
San Francisco
4G
Data CE1
3G
Data CE2
Peering CE3
GW2
Alpha
Corp GW1
San Jose
4G
Data CE4
3G
Data CE5
Peering CE6
GW4
Beta
Net GW3
Sacramento
4G
Data CE7
3G
Data CE8
Peering CE9
GW6
Charlie
Com GW5
Modesto
4G
Data
CE10
3G
Data
CE11
Fresno
4G
Data
CE12
3G
Data
CE13
Bakersfield
4G
Data
CE14
3G
Data
CE15
MPLS
Backbone
PE1
PE2
PE3
PE4
PE5
PE6
91

Autonomous Systems
92

The term Autonomous System (AS) refers to a connected
group of networks, identified by their network prefixes,
that share a common routing policy. The routing policy
determines what routing information is shared, and how it
is shared, with other ASs. Each AS is identified by a unique
Autonomous System Number (ASN).
Within each of the switching offices in our sample
network, the 4G data network comprises an AS with ASN
110. The 3G data network is ASN 120. The MPLS core
network is ASN 1. The AS that peers with the external
Internet Service Provider (ISP) partners has been assigned
ASN 4000. The ISP partners have been assigned ASNS
7700, 8800 and 9900.
San Francisco
Sacramento
San Jose
Autonomous System
MPLS
Backbone
AS 1
4G Data
AS110 CE1
3G Data
AS120 CE2
ISP
AS4000 CE3
GW2
Alpha
AS9900 GW1
4G Data
AS110 CE7
3G Data
AS120 CE8
ISP
AS4000 CE9
GW6
Charlie
AS7700 GW5
4G Data
AS110 CE4
3G Data
AS120 CE5
ISP
AS4000 CE6
GW4
Beta
AS8800 GW3
PE1
PE3
PE2
93

The Autonomous System Number (ASN) was originally
defined to be a two-byte value, between the range of 0
and 65535. The Internet administrative authorities
allocated ASNs to networks that connected to the public
Internet. The range of ASNs between 64512 and 65534
were reserved for private use, within internal networks
(similar to the private IP address ranges).
As the size of the Internet grew, it became apparent that a
two-byte ASN value would be inadequate to capture the
number of distinct networks. A revised, four-byte ASN
format was introduced to accommodate the growth.
Routers that connect to the public Internet now use the
four-byte variant. Routers that operate solely within private
networks may continue to use the two-byte ASN or adopt
the newer four-byte ASN format.
Autonomous System Number
• 2-byte ASN
– Public ASNs allocated by Internet
– 64512 – 65534 used for private
networks
• 4-byte ASN
– Two notations
• “AS Plain”: 65536 – 4294967296
• “AS Dot”: 1.0 to 65535.65535
– Existing ASN 1776 written as 0.1776
94

The Border Gateway Protocol (BGP) carries routing
information between Autonomous Systems (ASs). Interior
gateway protocols such as the Open Shortest Path First
(OSPF) protocol make routing decisions based on
straightforward link metrics. At this level in the network,
however, administrators generally prefer the flexibility of
policy-based routing. BGP supports this by associating a
set of attributes with each route. The attributes include
standard parameters such as AS Path, Origin and Next-
Hop address. Additionally, BGP may tag routes with more
customized attributes whose meanings are known only to
the AS. The routers may use these attributes to decide
which routes to advertise to peers, which advertisements
they accept from peers and how they prioritize the routes
that they do accept. Routers may manipulate the
attributes when they send or receive routes from peers.
When a router uses BGP to exchange routes with a router
in a different autonomous system, we refer to that
specifically as External BGP (eBGP). A router may also use
BGP to exchange routes with a router inside its own
autonomous system. This is referred to as Internal BGP
(iBGP).
In our sample network, the autonomous systems inside
the switching offices have a Customer Edge (CE) router
that uses eBGP to exchange routes with the Provider Edge
(PE) router in the core network autonomous system. The
PE routers use Internal BGP (iBGP) to connect to other
core network routers. The Internet peering AS (ASN 4000)
contains a gateway router that uses eBGP to connect to
the respective external ISP. The gateway router also uses
iBGP to connect to the ASN 4000 CE router.
San Jose
Border Gateway Protocol
MPLS
Backbone
AS 1
PE1
3G Data
AS 120
4G Data
AS 110 CE4
CE5
Beta Net
AS 8800 GW3
eBGP
AS 4000 CE6
GW4
iBGP
eBGP
• Exchange routes between
Autonomous Systems
• IETF Standard (RFC 4271)
• Policy-based routing
• Attributes
PE2
PE3
95

BGP Messages
96

BGP is not a particularly complicated protocol. There is no
neighbor discovery procedure, so you must tell a router
who its BGP neighbors are through configuration. BGP
relies on the Transmission Control Protocol (TCP) to
ensure reliable delivery of messages, so it doesn’t define
any special retransmission mechanisms or response
messages. Once the TCP connection has been
established, both routers send an Open message. This
message contains the router’s BGP identifier, autonomous
system number, timer values and other protocol options. If
the proposed parameters are acceptable to the neighbor,
it responds with a Keep-Alive message. The routers next
use BGP Update messages to exchange their BGP routes.
After the initial exchange of routes, the routers update
each other if something changes in their routing tables. In
the meantime, they periodically send Keep-Alive
messages to confirm that the BGP session remains up. If
a router’s routing policy changes, it may send a Route-
Refresh message to request that its neighbor re-send its
BGP routes. Either router may gracefully close the BGP
session simply by closing its underlying TCP connection. In
the event of an error, the router may also send a BGP
Notification message before closing the TCP connection.
BGP Messages
MPLS Core
AS 1
Open Open
Update
Update
Open TCP Connection
4G Data
AS 110
CE PE
No Neighbor
Discovery
Keep-
Alive
Keep-Alive
Initial Route
Exchange
Periodic
Keep-Alives
Update
Send Update if
something
changes
Route-
Refresh
Update
Please send me
those routes
again.
Here they are
Close the BGP
session Notification
Close TCP Connection
97

Route distribution is straight-forward in BGP. A router
sends a BGP Update message to its neighbor. The Update
message may include two sets of information: routes that
currently exist in its BGP table; and routes that it had
previously advertised, but is now withdrawing. Any given
update message may include one or the other or both sets
of information. Generally, the router includes the entire
contents of its BGP table when the BGP session is initially
established or in response to a Route-Refresh request.
Otherwise, it generally includes only new and updated
routes. The Update message also includes a set of
attributes associated with the routes.
When a router receives an Update message from a
neighbor, it updates its own BGP table as needed. It may
in turn send an Update message of its own to its other
neighbors, thus propagating the routing information
throughout the network.
In our sample network, the Beta Net router, GW3, sends a
BGP Update message to the mobile network router, GW4.
The Update message indicates that GW3 is withdrawing
the 150.13.5.0/24 route and advertising four other
routes 88.1.2.0/24, 88.2.1.0/24, 88.3.4.0/24 and
88.4.3.0/24.
San Jose
BGP Update
AS 1
3G Data
AS 120
4G Data
AS 110 CE4
CE5 PE2
Beta Net
AS 8800 GW3
Update
AS 4000 CE6
GW4
Update Update
Withdrawn
Routes
150.13.5.0/24
Advertised
Routes
88.1.2.0/24
Attributes
88.2.1.0/24
88.3.4.0/24
88.4.3.0/24
PE1
PE3
98

The figure uses router PE2 to illustrate the relationship of
the BGP table to the routing table. BGP maintains a table
of routes that it has learned from its neighbors. The table
stores a set of information associated with each of the
routes, including a set of attributes and the neighbor from
which it was learned. BGP uses this information to select
routes to be copied into the routing table.
Note that BGP does not copy every route that it learns into
the routing table. If BGP learns multiple routes to the
same destination, it typically selects a best route and copy
that to the routing table. In the example shown, PE2 has
learned multiple routes to 75.0.0.0/8. BGP selects the
route that it learned from CE6 and copies it to the routing
table. The router may also have learned routes from other
sources, such as OSPF or static routes, that take
precedence over the routes it learns through BGP. In the
example shown, BGP has learned a route to 10.3.0.0/16,
but the router also has a static route configured for that
destination. The static route takes precedence over the
BGP route, so the BGP route does not get copied to the
routing table.
4G Data
AS 110
3G Data
AS 120
ISP
AS 4000
BGP Table Example
PE2 BGP Table
Route Neighbor Attributes
10.2.16.0/21 CE4 AS Path, Next-Hop, Origin
75.0.0.0/8 PE1 AS Path, Next-Hop, Origin
PE2 Routing Table
Route Next-Hop Metric Exit I/F
B 10.2.16.0/21 CE4 20 gi0/1
B 10.2.24.0/21 CE5 0 gi0/2
B 75.0.0.0/8 CE6 0 gi0/3
B 10.1.0.0/16 PE1 0 gi0/0
S 10.3.0.0/16 PE5 0 gi0/4
B 10.4.0.0/16 PE4 0 gi0/0
B 10.5.0.0/16 PE5 0 gi0/0
B 10.6.0.0/16 PE6 0 gi0/0
AS 1
PE2
PE1
PE3
PE4
PE5
PE6
CE4
CE5
CE6
99

BGP Attributes and
Routing Policy
100

The BGP router maintains a data structure called the BGP
table that includes all of the BGP routes that it has either
originated itself or learned from its neighbors. The BGP
table stores the BGP routes and their associated
attributes.
The BGP router implements a set of default behaviors.
The router accepts all incoming route updates from its
neighbors. Similarly, the router shares the entire contents
of its BGP table with its neighbors. Finally, BGP also
implements a default path determination algorithm that
selects the best routes to be copied into the routing table.
This default behavior may not be desirable in all cases.
The network administrator may wish to override the
default behavior to implement specific routing policies.
This can be accomplished by installing a set of inbound
filters that accept some route updates and reject others.
The inbound filters may also manipulate the contents of
the routes as they are copied to the BGP tables. Similarly,
a set of outbound filters may select choose certain routes
to be shared with the router’s neighbors and manipulate
the contents of the routes as the advertisements are sent
out.
BGP Routing Policies
BGP Table
Route Attributes
10.0.0.0/8 AS Path, Next-Hop, Origin, …
Routing Table
Route Source Metric Next-Hop Exit Interface
10.0.0.0/8 B 0 IPC gi0/1
10.0.8.0/24 B 0 IPD gi0/2
10.0.16.0/21 B 0 IPA fa0/1
10.0.24.0/21 B 0 IPB fa0/2
Inbound
Policy
Filters
Receive
BGP Update
Rejected
Routes
Outbound
Policy
Filters
Send
BGP Update
Best Routes
101

BGP defines several different attributes that may be
associated with routes in the BGP table. The table shown
is not an exhaustive list of BGP attributes, but is a sample
of the attributes that the routing policy may examine when
deciding whether to accept a route, how to prioritize a
route and whether to advertise the route to other
neighbors. The routing policy may also manipulate the
values of these attributes.
Some attributes are mandatory and are associated with all
BGP routes. Others are optional. Transitive attributes
should be included when the router propagates the route
to another autonomous system. Non-transitive attributes
are intended to be used only within the current
autonomous system and should not be included with the
route if it is advertised to any external BGP neighbors.
BGP Attributes
Attribute
Mandatory/Optional
Transitive/Non-Transitive
Description
AS Path Mandatory, Transitive
Sequence of ASs the route has
traversed
Next-Hop Mandatory, Transitive Address of neighbor
Origin Mandatory, Transitive
Indicates whether or not BGP on
originating router learned the route
through redistribution
Multiple Exit
Discriminator (MED)
Optional, Non-transitive
Determines best path for inbound
traffic
LOCAL_PREF Optional, Non-transitive
Determines best path for outbound
traffic; used only on iBGP neighbors
Community Optional, Transitive Assigns a marker to a route
102

The Autonomous System (AS) Path attribute is a
mandatory attribute. Every BGP route has an associated
AS Path attribute. When a router originates a route, it puts
its own ASN into the AS Path attribute. When a router
propagates a route to an eBGP neighbor, it adds its own
ASN to the front of the AS Path attribute (note that it does
not do this when it forwards routes to an iBGP neighbor).
So the AS Path attribute is basically a list of autonomous
systems one would have to traverse to reach the
destination specified by the route.
The example shown traces the 88.1.2.0/24 route from
the Alpha Corp network to the 3G Data network in
Sacramento. Alpha Corp originates the 88.1.2.0/24 route.
When router GW1 sends a BGP Update message to GW2,
it sets the AS Path attribute to its own ASN 7700. GW2
forwards the Update to CE3 (not shown) on the slide. This
is an iBGP session, so the AS Path does not change. CE3
sends an Update to PE1, inserting ASN 4000 in front of
the AS Path attribute. PE1 forwards the Update to PE3.
This is also an iBGP session, so the AS Path attribute does
not change. PE3 sends an Update to CE8, inserting ASN 1
in front of the AS Path attribute. The AS Path attribute
value would be “1, 4000, 7700” when CE8 receives the
final Update message.
This example illustrates the route propagation to a single
router. The route would similarly be propagated to the
other routers in the network.
Sacramento
San Francisco
MPLS
Backbone
AS 1
AS Path Attribute
4G Data
AS 110 CE1
3G Data
AS 120 CE2
ISP
AS 4000 CE3
GW2
Alpha
AS 7700 GW1
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
Update
PE3
Update
PE1
Update
88.1.2.0/24 AS Path: 7700
eBGP: Add ASN to AS Path
iBGP: Do not modify AS Path
Update
88.1.2.0/24 AS Path: 1, 4000, 7700
Update
88.1.2.0/24 AS Path: 4000, 7700
103

The AS Path attribute also helps to avoid routing loops.
When a router receives an Update from an eBGP
neighbor, and sees that its own ASN is already in the AS
Path attribute, it rejects the route (i.e., not add the route to
its BGP table).
In the example shown, GW2 advertises the
198.51.100.0/24 route to the Alpha Corp network, which
in turn forwards it to the Charlie Com network. When the
Charlie Com router, GW5 forwards the route to GW8, the
AS Path attribute lists the three Autonomous Systems that
the route traversed (9900, 7700, 4000). Router GW6
observes ASN 4000 is already in the AS Path, so it rejects
the route.
MPLS
Backbone
AS 1
Sacramento
San Francisco
AS Path Loop Prevention
4G Data
AS 110 CE1
3G Data
AS 120 CE2
ISP
AS 4000 CE3
GW2
Alpha
AS 7700 GW1
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
PE3
Update
PE1
GW6 rejects the route,
because ASN 4000 already
appears in the AS Path.
Update
198.51.100.0/24 AS Path: 4000
Update
Update
198.51.100.0/24
AS Path: 7700,
4000
Update
Update
198.51.100.0/24
AS Path: 9900,
7700, 4000
104

Rejecting a route because its ASN already exists in the AS
Path attribute prevents routing loops in many
circumstances, but may prevent legitimate routing
exchanges in one specific scenario. Consider the network
configuration in our sample network and notice how each
of the ASs (4G Data, 3G Data, ISP, etc.) is disjointed. They
are spread across several network locations, connected by
a common backbone. Let’s say that the 4G data network
in San Francisco originates the 192.0.2.0/24 route and
sends it to PE1. It puts ASN 110 in the AS Path attribute.
PE1 uses iBGP to forward the route to PE3. Ordinarily, PE3
would add ASN 1 to the AS Path and forward the route to
CE7. CE7 would therefore see ASN 110 in the AS Path
attribute. Rejecting the route would not be helpful in this
instance.
The AS Override feature works around this problem. If we
configured the AS override feature on router PE3, then it
would replace the 4G data network’s ASN 110 with its
ASN 1. Then, when CE7 receives the route update, it does
not see its own ASN in the AS Path attribute and therefore
does not reject the route.
MPLS
Backbone
AS 1
Sacramento
San Francisco
AS Override
4G Data
AS 110 CE1
3G Data
AS 120 CE2
ISP
AS 4000 CE3
GW2
Alpha
AS 7700 GW1
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
PE3
PE1
Rather than add its ASN to the AS
Path attribute, PE3 overrides the
AS Path entirely.
Update (without AS Override)
192.0.2.0/24 AS Path: 1, 110
Update
192.0.2.0/24 AS Path: 110
Update (with AS Override)
192.0.2.0/24 AS Path: 1, 1
105

The Next-Hop is a mandatory attribute. Every BGP route
has an associated Next-Hop attribute. As its name
indicates, the Next-Hop attribute is the address of the
router that is one step closer to the destinations specified
by the route.
When a router advertises a route through an eBGP
session, it sets the Next-Hop attribute to its own address.
When a router advertises a route through an iBGP session,
it leaves the Next-Hop attribute intact. This is a subtle, but
important point. In this circumstance, the router is
essentially telling its neighbor “I know how to get to this
destination. If you have any packets for this destination,
send them to that router over there.” This is sometimes
known as a third-party next-hop (examples of which are
marked with a red star in the example shown).
In the example shown, the 4G data network in Modesto
originates the route 120.0.0.0/8 and sets the Next-Hop
attribute to an IP address on router CE10. PE4 leaves the
Next-Hop attribute alone when it forwards the route to its
iBGP neighbor PE3. When PE3 advertises the route to its
eBGP neighbor, it sets the Next-Hop attribute to one of its
own IP addresses. The connection between CE9 and GW6
is an iBGP session, so CE9 does not change the Next-Hop
attribute. GW6 has an eBGP session with GW5, so it does
set the Next-Hop attribute.
Fresno
Modesto
Sacramento
MPLS
Backbone
AS 1
Next-Hop Attribute
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
4G Data
AS 110
CE10
3G Data
AS 120
CE11
4G Data
AS 110
CE12
3G Data
AS 120
CE13
PE5
PE3
PE4
eBGP Update from CE10 to PE4
120.0.0.0/8 Next-Hop: IPCE10
eBGP: Replace Next-Hop attribute
iBGP: Do not modify Next-Hop
iBGP Update from PE4 to PE3
120.0.0.0/8 Next-Hop: IPCE10
eBGP Update from PE3 to CE9
120.0.0.0/8 Next-Hop: IPPE3
iBGP Update from CE9 to GW6
eBGP Update from GW6 to GW5
120.0.0.0/8 Next-Hop: IPGW6
106

One of the fundamental rules in BGP concerns the
reachability of the Next-Hop attribute. The rule states that
a route’s Next-Hop attribute must be reachable in order
for that route to be copied to the routing table or
advertised to any other neighbors. In other words, the
routing table must have an entry that matches the
address in the route’s Next-Hop attribute. The entry could
be a directly connected or static route, or it could have
been learned from a routing protocol.
In the example shown, the local router has learned four
BGP routes. The 10.0.0.0/24 route has a next-hop
address of 120.1.5.1. The routing table has an entry to
120.1.5.0/24 (which it learned from OSPF), so 120.1.5.1
is reachable. Therefore, the 10.0.0.0/24 route works just
fine. BGP copies it to the routing table and advertises it to
its neighbors.
The 10.0.8.0/24 route has a next-hop address of
120.2.5.1, for which there is no matching entry in the
routing table. The 10.0.8.0/24 route therefore remains in
the BGP table, but BGP cannot copy it to the routing table
or advertise it to any other neighbors.
The remaining two BGP routes are 10.0.16.0/24 and
10.0.24.0/24. Their next-hop addresses are 130.1.43.1
and 130.1.79.1, respectively. Both of these addresses
are matched by the 130.1.0.0/16 entry in the routing
table (which is a static route). So, both of these routes
work just fine as well.
Note that the reachability of next-hop addresses may
change as the routing table gets updated. If a next-hop
address becomes reachable, then the corresponding BGP
route becomes valid. Likewise, if a next-hop address
becomes unreachable, then the corresponding BGP route
becomes invalid. In our example, the 10.0.8.0/24 route
would become valid (i.e., copied to routing table and
advertised to neighbors) if the router learns a route to the
120.2.5.1 address. Likewise, if the 120.1.50/24 or
130.1.0.0/16 routes are removed from the routing table,
the corresponding BGP routes would become invalid (i.e.,
removed from routing table and withdrawn from
neighbors).
Next-Hop Must be Reachable
BGP Table
Route Attributes
10.0.0.0/24 Next-Hop: 120.1.5.1
10.0.8.0/24 Next-Hop: 120.2.5.1
10.0.16.0/24 Next-Hop: 130.1.43.1
10.0.24.0/24 Next-Hop: 130.1.79.1
Routing Table
Route Source Metric Next-Hop Exit Interface
120.1.5.0/24 O 20 33.54.1.3 fa0/1
130.1.0.0/16 S 1 33.54.42.9 fa0/2
10.0.0.0/24 B 0 120.1.5.1 -
10.0.16.0/24 B 0 130.1.43.1 -
10.0.24.0/24 B 0 130.1.79.1 -
Path Determination
Algorithm
120.2.5.1 is not reachable
10.0.8.0/24 cannot be
copied to routing table or
advertised to neighbors
107

BGP requires that the address in a route’s Next-Hop
address be reachable in order for that route to be
considered valid. Also, by default, BGP does not modify
the value of the Next-Hop attribute when sharing routes
with iBGP neighbors. This can be a problem if the iBGP
neighbor does not already have a route to the route’s next-
hop address.
In the example shown, CE10 originates a route to PE4.
The Next-Hop attribute is IPCE10. Ordinarily, PE4 would
propagate the route to PE3 without changing the Next-Hop
attribute. But if PE3 does not have a route to IPCE10, then
PE3 would consider the route to be invalid. It could not
install the route to 120.0.0.0/8 or propagate the route to
CE7, CE8 or CE9.
The Next-Hop-Self feature addresses this problem. The
feature instructs the router to replace the Next-Hop
attribute with one of its own addresses when it advertises
a route over an iBGP session. Remember, it already does
this for eBGP sessions, but not iBGP sessions.
The example illustrates what happens if we use the next-
hop-self command on routers PE4 and CE9. Both of them
place their address in the next-hop field.
Sacramento
Fresno
Modesto
MPLS
Backbone
AS 1
Next-Hop-Self
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
4G Data
AS 110
CE10
3G Data
AS 120
CE11
4G Data
AS 110
CE12
3G Data
AS 120
CE13
PE5
PE3
PE4
eBGP Update from CE10 to PE4
120.0.0.0/8 Next-Hop: IPCE10
Use next-hop-self command on PE4
and CE9.
eBGP Update from PE3 to CE9
iBGP Update from GW6 to GW5
120.0.0.0/8 Next-Hop: IPCE9
120.0.0.0/8 Next-Hop: IPGW6
108

The Local Preference (LOCAL_PREF) Attribute provides a
means for the local routing policy to indicate the degree to
which the route is preferred. The attribute is a simple,
unsigned integer value. Higher values indicate the route is
more preferred. The LOCAL_PREF attribute only has
significance within a single Autonomous System (AS). In
fact, the attribute cannot be included when advertising
routes to External BGP (eBGP) neighbors.
In general, when a router receives a route from an eBGP
neighbor, the local routing policy may determine degree to
which the route is preferred and attach the LOCAL_PREF
attribute to the route. The router includes the
LOCAL_PREF attribute when it advertises the route to its
Internal BGP (iBGP) neighbors. When a BGP router
determines that it has multiple BGP routes to the same
destination, BGP selects the route with the higher
LOCAL_PREF value to be copied into the routing table and
advertised to its other neighbors.
In our example network, both the 120.0.0.0/8 route
originates in ASN 4398. Both the Beta Net and Charlie
Com networks learn the route and advertise it to the
mobile network. The ASN 4000 routers in San Jose and
Sacramento propagate the route to routers PE2 and PE3,
respectively. These routers have been configured with a
local routing policy that calculates a local preference
value. PE2 sets the LOCAL_PREF attribute to 200. PE3
sets the it to 150. When PE2 and PE3 propagate their
routes to the other routers in ASN 1, they all learn that the
preferred path to the 120.0.0.0/8 destination is through
PE2.
San Jose
Fresno
Sacramento
MPLS
Backbone
AS 1
Local Preference
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
4G Data
AS 110
CE12
3G Data
AS 120
CE13
PE5
PE3
120.0.0.0/8
AS Path: 4000, 9900, 4398
LOCAL_PREF: 150
120.0.0.0/8 AS Path: 9900, 4398
Update
4G Data
AS 110 CE4
3G Data
AS 120 CE5
ISP
AS 4000 CE6
GW4
Beta
AS8800 GW3
PE2
Update
120.0.0.0/8 AS Path: 8800, 4398
Update
120.0.0.0/8
AS Path: 4000, 8800, 4398
LOCAL_PREF: 200
BetaNet and Charlie Com advertise 120.0.0.0/8
PE2 sets LOCAL_PREF to 200
PE3 sets LOCAL_PREF to 150
BetaNet route is preferred
109

The Community attribute is an optional attribute. A route
may have zero or more community attributes associated
with it. Community attributes are used as markers to tag a
route with a particular value whose semantics are defined
by the autonomous system’s routing policy. A policy-aware
router would look for incoming routes with particular
Community attributes. It may use the Community
attributes to decide which routes to accept or reject, how
to prioritize the routes in the routing table, and whether or
not to advertise the route to its neighbors.
In the example shown, the Customer Edge (CE) routers for
the 3G and 4G data networks tag their routes with
different community attributes. The other routers in the
network may use those attributes to decide whether to
accept, reject or propagate the routes.
Fresno
AS 1
Community Attributes
• Markers that are
attached to routes
• Used to implement
Routing Policy
4G
Data
CE12
3G
Data
CE13
PE5
PE4
PE6
PE1
PE3
PE2
eBGP Update
85.2.0.0/16
Next-Hop: IPCE12
Community: 4G
eBGP Update
120.0.0.0/8
Next-Hop: IPCE13
Community: 3G 3G
4G
110

Route Reflectors
111

By default, when a BGP router learns routes from an eBGP
neighbor, it propagates those routes to its iBGP neighbors.
Similarly, when it learns routes from an iBGP neighbor, it
propagates those routes to its eBGP neighbors. The router
does not, however, propagate routes that it learns from an
iBGP neighbor any of its other iBGP neighbors. The
implications of this behavior are that, in order to
thoroughly distribute routes throughout the Autonomous
System, a BGP router must establish one iBGP connection
to every other BGP router in the Autonomous System (AS).
This is sometimes referred to as the iBGP full-mesh
requirement.
The full-mesh rule presents a scalability problem.
Mathematically speaking, if there are N number of BGP
routers in the AS, each one would need to establish N-1
iBGP sessions. The total number of iBGP sessions would
be calculated as N(N-1)/2. In the sample network shown,
there are six BGP routers in the MPLS backbone (AS 1).
Each one needs to maintain iBGP sessions to five different
neighbors. There are a total of 15 iBGP sessions
throughout the AS. Consider the numbers if there were 10
BGP routers. Each would maintain nine iBGP sessions.
There would be a total of forty-five sessions. The sheer
number of connections complicates router configuration
and troubleshooting. And the problem gets much worse as
the number of routers increases.
iBGP Scalability Issues
San Jose
Sacramento
San Francisco
CE1
CE2
CE3
GW2
Alpha GW1
Modesto
CE10
CE11
Fresno
Bakersfield
PE1
PE4
PE5
PE6
CE4
CE5
CE6
GW4
Beta GW3
CE7
CE8
CE9
GW6
Charlie GW5
PE2
PE3
CE12
CE13
CE14
CE15
iBGP Full-Mesh Requirement =
Too many iBGP sessions!
112

One solution to the iBGP scalability problem is to use what
are known as Route Reflectors. A Route Reflector
specially-configured so that it propagates routes that it
learns from one iBGP neighbor to its other iBGP neighbors
(overriding the default rules). It therefore acts as a sort of
centralized iBGP route distribution hub. Each of the BGP
routers in the AS establishes an iBGP session to the Route
Reflector. As the edge routers learn routes from their
eBGP neighbors, they propagate them to the Route
Reflector, which in turn forwards them to the other BGP
routers in the network. In this way, the routes are
thoroughly distributed throughout the AS and the number
of iBGP sessions is minimized.
Because the Route Reflector plays such an important role
in route distribution, it is common to deploy them in
redundant pairs. In the example shown, each of the six
Provider Edge (PE) routers establishes an iBGP session to
each of the two Route Reflectors. The Route Reflectors
also peer with each other. There are a total of 13 iBGP
sessions throughout the AS.
Route Reflectors
San Jose
Sacramento
San Francisco
CE1
CE2
CE3
GW2
Alpha GW1
Modesto
CE10
CE11
Fresno
Bakersfield
PE1
PE4
PE5
PE6
CE4
CE5
CE6
GW2
Beta GW1
CE7
CE8
CE9
GW2
Charlie GW1
PE2
PE3
CE12
CE13
CE14
CE15
Centralized iBGP Route Distributor
Minimize iBGP Sessions
RR1
RR2
113

Summary
• BGP supports policy-based routing.
• Policy determines the routes that a router
accepts, advertises, and uses.
• BGP attributes include AS Path, Next-Hop,
and Community.
• Route reflectors use iBGP to distribute
routes to all BGP routers in the AS.
• eBGP runs between routers in different ASs.
• iBGP runs between routers in the same AS.
114

A portion of the sample network is shown on the slide. A
number of BGP sessions have been highlighted. Mark
each of the sessions as being either an External BGP
(eBGP) or Internal BGP (iBGP) session.
Sacramento
Fresno
Review - I
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
4G Data
AS 110
CE12
3G Data
AS 120
CE13
PE5
PE3
RR
Interface
BGP Session Type
(eBGP or iBGP)
GW5 ↔ GW6
GW6 ↔ CE9
CE9 ↔ PE3
PE3 ↔ RR
RR ↔ PE5
PE5 ↔ CE13
115

The Charlie Com network advertises 198.51.100.0/24 to
our sample network. The BGP update is shown at the top
of the diagram. The AS Path attribute is 9900 and the
Next-Hop attribute is set to the IP address of GW5.
Recalling the behavior of the AS Path and Next-Hop
attribute on both eBGP and iBGP connections, complete
the remaining update messages as the route is
propagated through the sample network, eventually
reaching CE1.
Sacramento
San Francisco
MPLS
Backbone
AS 1
Review - II
4G Data
AS 110 CE1
3G Data
AS 120 CE2
ISP
AS 4000 CE3
GW2
Alpha
AS 7700 GW1
4G Data
AS 110 CE7
3G Data
AS 120 CE8
ISP
AS 4000 CE9
GW6
Charlie
AS9900 GW5
Update 1
PE3
Update
4
PE1
Update 1 – GW5 to GW6
198.51.100.0/2
4
AS Path: 9900
Next-Hop: IPGW5
Update 2
Update 2 – GW6 to CE9
198.51.100.0/2
4
AS Path:
Next-Hop:
Update – CE9 to PE3
198.51.100.0/2
4
AS Path:
Next-Hop:
RR
Update
5 Update 4 – PE3 to RR
198.51.100.0/2
4
AS Path:
Next-Hop:
Update 5 – RR to PE1
198.51.100.0/2
4
AS Path:
Next-Hop:
Update 6 – PE1 to CE1
198.51.100.0/2
4
AS Path:
Next-Hop:
116

7 | BGPv4 in Wireless Networks
Chapter 7:
BGPv4 in Wireless
Networks
117

Objectives
• Improve routing performance
―External Fast Failover, BFD Route Supervision,
Graceful Restart
• Use the route dampening feature to reduce network
instability due to recurring failures
• Use the maximum paths feature to implement load-
balancing
• Use the multi-hop feature to connect to distant
neighbors
• Use the maximum prefix feature to protect against
unpredictable routing behavior
118

The figure illustrates a hypothetical network that consists
of switching offices in the Northeast region of the country.
Each switching office contains a 3G data network, a 4G
data network and a voice network. They would likely
contain other networks too, but these three are sufficient
for our discussion. Each of the networks constitutes its
own Autonomous System. The figure illustrates the
Autonomous System Numbers that have been assigned to
them.
Additionally, the Boston office contains a Virtual Private
Network (VPN) connection to a third-party application
hosting company, AppCom.
The core network consists of pairs of Provider Edge (PE)
routers located at each site.
Internet
Sample Network
Springfield
Hartford
Bridgeport
Boston
MPLS
Backbone
AS 1
4G Data
AS110 CE1
3G Data
AS120 CE2
PE1
Voice
AS 130 CE3
4G Data
AS410
CE5
PE4
3G Data
AS410
CE6
Voice
AS410
CE7
4G Data
AS510
CE8
3G Data
AS510
CE9
Voice
AS510
CE10
4G Data
AS610
CE11
3G Data
AS610
CE12
Voice
AS610
CE13
Services
AS 1000 CE4
AppCom
AS 5000 R1
VPN
VPN
PE2
PE3
PE6
PE5
PE8
PE7
119

If a BGP router learns multiple routes to a given
destination, the BGP path selection algorithm ordinarily
selects a single best route to be copied into the routing
table. The BGP Multipath feature instructs BGP to copy
multiple best routes to the routing table so that the router
may distribute traffic among the multiple routes. Each of
the routes must be equally good in order for all of them to
be copied to the routing table. If the path selection
algorithm determines that there is a clearly better route
(as determined by the local routing policy), then BGP
continues to copy only that single route to the routing
table.
In our sample network, each of the Customer Edge (CE)
routers connects to a pair of Provider Edge (PE) routers in
the local site. The CE router likely learns the same set of
routes from both of the PE routers. Assuming that the two
PE routers are equally capable of carrying the network
traffic, enabling the BGP multipath feature allows the CE
routers to perform load balancing across the two PE
routers.
BGP Multipath
CE6 BGP Table
Route Attributes
10.0.16.0/21 Next-Hop: PE3
10.0.16.0/21 Next-Hop: PE4
10.0.24.0/21 Next-Hop: PE3
10.0.24.0/21 Next-Hop: PE4
CE6 Routing Table
Route Source Next-Hop Exit Interface
10.0.16.0/21 B IPPE3 fa0/1
10.0.16.0/21 B IPPE4 fa0/2
10.0.24.0/21 B IPPE3 fa0/1
10.0.24.0/21 B IPPE4 fa0/2
How many
“best” routes?
Springfield
4G Data
AS410
3G Data
AS410
Voice
AS410
CE5
CE6
CE7
PE4
PE3
Enables Equal Cost
Multipath (ECMP)
120

When BGP runs between routers in two different
autonomous systems, we refer to that as an External BGP
(eBGP) session. By default, BGP assumes that eBGP
neighbors are directly connected to each other and does
not establish an eBGP session unless that is the case. The
BGP Multi-hop feature overrides this behavior. The feature
must be enabled if the eBGP neighbors are not adjacent
to each other.
In the example shown, eBGP runs between the CE and PE
routers. They are directly connected to each other, so no
special configuration is required. We also want to use
eBGP to exchange routes with our partner, App.Com. The
mobile network connects to the App.Com network through
a VPN router located in Boston. According to our network
configuration, the VPN router simply implements the
tunnel between the two networks. CE4 implements the
routing policy that governs the exchange of routes with
App.Com. Since CE4 is not directly connected to the
App.Com router, R1, the eBGP Multi-hop feature must be
enabled in order to establish the eBGP session.
Internet
eBGP Multi-Hop
Springfield
Hartford
Bridgeport
Boston
MPLS
Backbone
AS 1
4G Data
AS110 CE1
3G Data
AS120 CE2
PE1
Voice
AS 130 CE3
4G Data
AS410
CE5
PE4
3G Data
AS410
CE6
Voice
AS410
CE7
4G Data
AS510
CE8
3G Data
AS510
CE9
Voice
AS510
CE10
4G Data
AS610
CE11
3G Data
AS610
CE12
Voice
AS610
CE13
Services
AS 1000 CE4
AppCom
AS 5000 R1
VPN
VPN
PE2
PE3
PE6
PE5
PE8
PE7
eBGP
eBGP
eBGP
eBGP
Enable
eBGP Multi-hop
121

The autonomous system’s routing policy determines the
number of routes that a router sends to its peers. Under
stable conditions, this number should not vary widely.
Large variations from the normal number of routes may
indicate that a configuration error exists. For example, the
policy filters may have been deleted or BGP may be
inadvertently importing routes from OSPF. The
configuration error may have occurred in a nearby router
or in a distant neighbor.
To insulate the network from such unexpected changes,
the router may be configured to accept a maximum
number of BGP routes from a neighbor. Each neighbor
may have its own threshold. The router may generate a
warning message as the number of routes approaches the
threshold. If the number of routes exceeds the threshold,
the router may be configured to simply generate another
warning message, or to drop the BGP session entirely.
In the example shown, routers CE1, CE2 and CE3 each
advertise 20 routes to PE1 and PE2 under normal
circumstances. A configuration error results in CE2
sending 150 routes. PE1 and PE2 have been configured
to only generate a warning message. They process all of
the routes offered by CE2 (of course, the number that are
accepted or rejected depends on the routing policy).
Similarly, router R1 sent 65 routes to CE4, instead of the
typical 10 routes. CE4 has been configured to drop the
BGP session if the number of routes exceeds 20, in effect
rejecting all of the routes that R1 offers. This results in a
service outage for the services hosted by App.Com. The
system does not recover until somebody addresses the
routing policy discrepancy between the number of routes
sent by R1 and the number of routes expected by CE4.
Limiting Number of Routes
Boston
MPLS
Backbone
AS 1
4G Data
AS110 CE1
3G Data
AS120 CE2
PE1
Voice
AS 130 CE3
Services
AS 1000 CE4
VPN
PE2
Internet
AppCom
AS 5000 R1
VPN
CE1, CE2, CE3
Typically advertise
20 routes
Error
R1 sends 65 routes
Error
CE2 sends 150 routes
R1
Typically advertises
10 routes
PE1, PE2
Route limit: 100
Action: Warning
CE4
Route limit: 20
Action: Drop Session
122

The BGP hold timer is used to detect the loss of a
neighbor. If the router does not receive a BGP message
from its neighbor before the hold timer expires, then the
router concludes that that neighbor is dead, terminate its
BGP session and invalidate any BGP routes that were
learned from it. The hold timer is typically set to be on the
order of tens of seconds.
External BGP (eBGP) neighbors are typically directly
connected to each other. The Fast External Failover
feature instructs BGP to monitor the status of the physical
interface that connects to the eBGP neighbor. If the
physical interface becomes disabled (for example, due to
a loss of signal or configuration error), BGP may react
immediately to declare the neighbor to be dead rather
than wait for the hold timer to expire.
In the example shown, the CE routers directly connect to
the PE routers. The hold timer has been configured to be
twenty seconds. If a link failure occurs, the physical
interface immediately notifies the BGP process. If the fast
external failover feature were not enabled, the BGP
processes would take up to twenty seconds to react to the
failure and update their routing tables. Customer services
may be adversely affected during this interval.
Fast External Failover
Hartford
MPLS
Backbone
AS 1
4G Data
AS110 CE1
3G Data
AS120 CE2
PE1
Voice
AS 130 CE3
PE2
BGP
TCP
IP
GigE
BGP
TCP
IP
GigE
Keep-Alive
Hold-Timer
20 seconds
Loss of Signal
Notification
Tear down BGP session
immediately.
123

Internal BGP (iBGP) neighbors typically are not directly
connected to each other. A failure may occur anywhere in
the path between the neighbors without either of the them
being aware of it. The Bidirectional Forwarding Detection
(BFD) protocol may be used to reduce failure detection
times in this case. BFD proactively monitors the path
between the neighbors by sending another keep-alive
message. Unlike the BGP keep-alive mechanism, BFD
typically detects a loss communications within a couple
hundred milliseconds. If BFD detects a communication
failure, it may notify BGP long before the hold timer
expires.
BFD Route Supervision
MPLS
Backbone
AS 1
PE1
PE2
BGP
TCP
IP
GigE
BGP
TCP
IP
GigE
Keep-Alive
Hold-Timer
20 seconds
Tear down BGP session
immediately.
PE7
PE8
BFD
BFD Timer
150 ms
Loss of
Communications
Notification
124

Under ordinary circumstances, if a BGP router detects that
a neighbor goes down, it deletes any routes it learned
from that neighbor and sends an update to its remaining
neighbors (who may, in turn, propagate the change to
their neighbors, and so on). When the router subsequently
re-establishes a BGP session with its failed neighbor, it
again must update its routing tables and then update its
other neighbors (who, again, update their neighbors, and
so on). When a router fails and then recovers in a short
period of time, this is known as route flapping and causes
routing instability in the network.
As its name implies, the Graceful Restart feature allows
the network to handle this situation more gracefully. The
two neighbors must indicate support for the feature when
they open the BGP session.
If the neighbor subsequently goes down, the router does
not immediately purge its routes from the routing table.
Instead, it marks the routes as stale, set a timer and
continue forwarding packets.
If the neighbor recovers, re-opens the BGP session and re-
transmits its routing information before the timer expires,
then the stale routes may be reactivated (assuming they
are still valid). Otherwise, the router proceeds to delete
the stale routes from the routing table. Six minutes is a
typical value for the recovery timer.
Graceful Restart
CE6 BGP Table
Route Attributes
10.0.8.0/21 Next-Hop: PE3
10.0.16.0/21 Next-Hop: PE3
10.0.24.0/21 Next-Hop: PE3
10.0.8.0/21 Next-Hop: PE4
10.0.16.0/21 Next-Hop: PE4
10.0.24.0/21 Next-Hop: PE4
Springfield
4G Data
AS410
3G Data
AS410
Voice
AS410
CE5
CE6
CE7
PE4
PE3
1. Negotiate on OPEN
2. PE3 goes down, saves
routing table
3. CE routers mark PE3’s
routes as stale, but
continue using them to
forward packets
4. PE3 restarts, marks all
routes as stale, but begins
to use them to forward
packets
5. Re-open BGP sessions
6. Re-send Routing
Information
7. Update routing tables
stale
stale
stale
125

Summary
• Several features improve routing convergence:
– Fast External Failover,
– BFD Route Supervision, and
– Graceful Restart.
• BGP Multipath enables Equal Cost Multipath (BGP
typically selects only one best path).
• eBGP Multi-hop enables eBGP to run between
neighbors that are not directly connected.
• The Maximum Route feature verifies that neighbors
send the expected number of routes.
126

Review
BFD Route Supervision
Fast External Failover
Maximum Paths
Graceful Restart
a) Avoids unnecessary routing updates in the rare
circumstance that a router reboots
b) Allows the network to function with fewer iBGP
connections
c) Rapidly detects loss of communication to a directly
connected neighbor
d) Rapidly detects loss of communication with a distant
neighbor
e) May terminate the BGP connection if a neighbor sends
too many routes
f) Avoids unnecessary routing updates in the event of an
intermittent or recurring link failure
g) Allows a router to form a BGP session with a neighbor
that is not directly adjacent
Connect the BGP features in the left column to their
functions or definitions in the right column.
127

128

8 | L3VPN in Wireless Networks
Chapter 8:
L3VPN in Wireless
Networks
129

Objectives
• Draw the L3VPN architecture
• Draw a design for an L3VPN application in an
EVDO/UMTS PS-CN and LTE-EPC
• Sketch the L3VPN design in EVDO-UMTS-LTE
transport
• Show the interconnection between MTSOs using
L3VPN
• Highlight the components and protocols of the
L3VPN network
• Briefly explain the operation of L3VPN in wireless
130

Interconnecting MTSOs
131

Prior to deploying MPLS, a service provider has to
maintain multiple separate networks such as ATM, TDM
(T1/E1), Frame Relay (FR) and IP. This is a costly
proposition as each network requires different equipment
and operating expertise. Basically, the service provider
had to maintain multiple networks to provide multiple
connectivity services.
With MPLS, the service provider can provide ATM, FR,
TDM and IP connectivity service to its customers with only
one MPLS core network. Hence, the service provider
maintains only one network to provide many different
connectivity services to its customers. In addition, the
service provider can provide more advanced services such
as Ethernet as well as L2 and L3 VPN services with QoS-
based Service Level Agreements (SLAs).
L3VPN is secure, flexible, easy to deploy/manage and very
popular among the wireless operators. L3VPN is very
widely deployed technology in many wireless operator
networks, Internet Service Provider networks, enterprise
networks and more. L3VPN uses the Virtual Routing and
Forwarding (VRF) inside the Provider Edge routers to
isolate the user plane, control plane and OA&M traffic.
VPN customer routes are distributed between VRFs by a
protocol known as Multi-Protocol Border Gateway Protocol
(MP-BGP).
In the Peer-to-Peer L3VPN model, designated customer
routers called Customer Edge (CE) routers peer at Layer 3
with service Provider Edge (PE) routers. Inside the MPLS
network, the PE routers connect to Provider (P) routers.
L3VPN: Application Domains
L3VPN
LTE-EVDO -
UMTS
Transport
EVDO/UMTS
PS-CN
EVDO/UMTS
Backhaul
LTE Backhaul
LTE-EPC
132

The EVDO-UMTS and LTE transport network is a pure IP-
based core network and is transparent to any IP traffic
flowing through it. Most backbone networks are MPLS
based to reduce the latency as voice, video, data and
other control data are carried in this network
transparently. To segregate the traffic of LTE, EVDO and
UMTS networks, L3VPN is used in the core.
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS/
NB
UE
1x EVDO /UMTS
Network
BTS/
NB
BTS/
Node B
UE
1x EVDO/UMTS
Network
BTS/
Node B
UE
eNB
eNB eNB
LTE-EPC
Network
L3VPN: Transport
CE/MTSO
Router
MPLS Transport
Network
CSR
CSR
Backhaul
Backhaul
Backhaul
Backhaul
UMTS/EVDO Routes
LTE Routes
CE/MTSO
Router
CSR
CSR
CE/MTSO
Router
CE/MTSO
Router
PE PE
P
P
133

This picture shows how the MPLS backbone-based L3VPN
solution may be deployed to connect different Mobile
Telecommunication Switch Offices (MTSOs) to each other
to create wireless core network. Various MTSOs are
interconnected using L3VPN for both the EV-DO and the
LTE networks. This is achieved using two VRFs at the
Provide Edge (PE) routers. These VRFs help keep the EV-
DO and LTE traffic separate and also allow for possibly
using overlapping IP addresses.
Interconnecting MTSOs
MTSO/CE1
Palm Bay-CE1
AS 110 & eBGP
MTSO/CE2
MTSO/CE1
MTSO/CE2
MTSO/CE1
MTSO/CE2
MTSO/CE1
MTSO/CE2
PE1 PE2
PE1
PE1
PE1 PE2
PE2
PE2
P2-RR2
Core AS1
BTS-1
HA P-GW
MME/
S-GW PDSN
eNodeB-2
BTS-2 eNodeB-1
VRF-LTE
VRF-EVDO Palm Bay-CE2
AS 120 & eBGP
Miami-CE1
AS 110 & eBGP
Miami-CE2
AS 120 & eBGP
Tampa-CE1
AS 110 & eBGP
Tampa-CE2
AS 120 & eBGP
Orlando-CE2
AS 120 & eBGP
Orlando CE1
AS 110 & eBGP
P1-RR1
OSPF/LDP/
MP-iBGP
134

L3VPN Architecture
135

The Virtual Private Networks (VPNs) have to meet certain
requirements in terms of security, scalability, flexibility and
performance. Since a service provider may support
thousands of VPNs, there must be the ability to
differentiate between VPNs in terms of QoS and
performance.
• Security: Security is an important requirement for
VPNs. The service provider must ensure that packets
from one VPN are not routed into other VPNs nor may
packets from outside sources be injected into VPNs.
• Scalability: The network must be able to support
hundreds of VPNs with thousands of sites. The VPN
solution should not require a linear increase in
resources as the number of VPNs and the number of
sites increase.
• Flexibility: VPNs must be flexible in order to add sites
quickly while meeting bandwidth and transport
requirements. New site addition and VPN discovery
must be automated.
• Performance: Performance guarantees are part of
every Service Level Agreement, and VPN-provider
networks must support different levels of QoS and
reliability for different VPNs.
The provider-customer model shown above meets all the
requirements for VPN customers in terms of security,
scalability, flexibility and performance.
This model has three parts: the customer networks,
provider networks and the links connecting the provider
and the customer networks.
ORL_PE
VRF
EVDO
P1
MPLS Core
Network
MIA_PE
VRF LTE
L3VPN Architecture
CE CE
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS
UE
1x EVDO
Network
BTS
BTS
UE
1x EVDO
Network
BTS
UE
eNB
eNB eNB
LTE-EPC
Network
P
GRT
CE CE
Provider Domain
MPLS Labeled Packets
Customer
Domain IP
Packets
Customer
Domain IP
Packets
VRF
EVDO
VRF LTE
GRT
136

Customer Network
The interface to the provider network is a customer router
called the Customer Edge (CE) router. This router
exchanges routing information with the provider network
as well as the other customer domains in the network.
Provider Network
In the Provider’s network, the edge router that interacts
with the CE router is the Provider Edge (PE) router. The CE
routers are connected to virtual routers created on the PE
routers. These virtual routers are called Virtual Routing
and Forwarding (VRF). Each VRF has its own routing and
forwarding table.
Transit routers (interior to the MPLS core) transport
customer traffic and routing information. They have no
need of customer routes and do not use VRF. Instead they
use the MPLS labels to move traffic through the MPLS
core. These routers are known as Provider (P) routers.
PE-CE Links
The CE connects to PE on a VRF. The PE and CE exchange
routing on this link. Only IP traffic is handled on this link.
PE-PE
A modified form of BGP known as MP-iBGP handles the
routing exchange between the VRFs across all the PEs.
Labeled Packets are transported in the MPLS core. MP-
iBGP connects only the VRFs of same VPNs.
In our example only, VRF LTE of ORL_PE is connected to
VRF LTE of MIA_PE and VRF EVDO of ORL_PE is
connected to VRF EVDO of MIA_PE using the MP-iBGP
protocol.
Creation of VRFs and their interconnections are easy to
configure. connecting the customer interfaces to VRFs and
Linking the like VRFs belong to same VPN are achieved by
very simple procedure or commands. Thus, a provider
using MPLS in the core is able to meet all the customer
requirements in terms of security, isolation of customer
networks, scalability, flexibility and performance.
ORL_PE
VRF
EVDO
P1
MPLS Core
Network
MIA_PE
VRF LTE
L3VPN Architecture (Continued)
CE CE
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS
UE
1x EVDO
Network
BTS
BTS
UE
1x EVDO
Network
BTS
eNB
eNB eNB
LTE-EPC
Network
P
GRT
CE CE
Provider Domain
MPLS Labeled Packets
Customer
Domain IP
Packets
Customer
Domain IP
Packets
VRF
EVDO
VRF LTE
GRT
UE
137

High-Level Operations
138

The MPLS core network consists of PE routers, P routers,
the loopback interfaces of each of these routers, and the
interfaces connecting PE-PE and PE-P. The MPLS Core
uses single area OSPF to advertise the links and loopback
addresses of the core network. LDP is enabled on the
MPLS core to distribute the labels for the core network
and to build LSPs for every known destination between
the P routers and the PE routers.
CEs are connected to PEs and isolation of customer’s
traffic is achieved by using virtual routers known as VRF.
In the example shown above, the EVDO networks and LTE
Networks at Orlando site are connected to VRF EVDO and
VRF LTE created on ORL_PE. At the Miami site, the EVDO
networks and LTE Networks are connected to VRF EVDO
and VRF LTE in the same fashion.
To differentiate the standard routing table of ORL_PE from
routing tables created by the VRFs, the standard routing
table is called the Global Routing Table (GRT) in L3VPN
scenario.
The GRTs of all PEs and the GRT of the P routers form the
MPLS Core Network. Note: VRFs are not used on the P
routers.
The CE and the respective VRF form an isolated network.
We have four such isolated networks in the above
diagram. They are listed below.
1. CE_EVDO and VRF EVDO of ORL_PE
2. CE_LTE and VRF LTE of ORL_PE
3. CE_EVDO and VRF EVDO of MIA_PE
4. CE_LTE and VRF LTE of MIA_PE
Counting the MPLS core, there are five isolated networks
in this diagram.
ORL_PE P1
MPLS Core
Network
MIA_PE
Protocols Used in Provider
Customer Model
CE CE
CE
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS
UE
1x EVDO
Network
BTS
BTS
UE
1x EVDO
Network
BTS
CE
UE
eNB
eNB eNB
LTE-EPC
Network
MP-iBGP
MP-iBGP
OSPF
LDP
OSPF
LDP
P
LDP: IGP Label Distribution
MP-iBGP: VPN Label Distribution
VRF
EVDO
VRF LTE
GRT
VRF
EVDO
VRF LTE
GRT
139

PE to CE Routing Protocol
CE routers transfer their routes to the VRFs on PE using
any of the protocols listed below.
eBGP
Normal eBGP runs on the CE side and in the VRF instance
on the PE side.
The advantages of using eBGP on PE-CE are:
1. No mutual redistribution is required between the
eBGP on PE-CE with MP-iBGP on PE-PE and vice
versa.
2. On the PE router, MP-iBGP and the customer eBGP
inside the VRF instances are configured in a single
section of BGP.
3. The issues given below for OSPF, ISIS and RIP are
avoided, making eBGP the best PE-CE routing
protocol.
OSPF
OSPF runs on the CE. On the PE, OSPF runs inside the VRF
instance of either EVDO or LTE. The disadvantage is that
we must run multiple OSPF process on the PE; one for the
MPLS core and the other for the PE to CE link. The PE to
CE OSPF process runs inside the respective VRF instance.
The other disadvantage is that the mutual redistribution of
routes is required between the OSPF on PE-CE with MP-
iBGP on PE-PE and vice versa.
ISIS and RIP
The implementation of ISIS and RIP as PE-CE protocols is
similar to OSPF with the same disadvantages.
Static/Default Routing
In static/default routing implementation, no routing
protocol is used. A static route is created inside the VRF
table for the customer networks. It is redistributed into
MP-iBGP towards the other PEs. The CEs create a default
entry pointing toward the PE router to reach any network.
No routing protocol running between the CE and PE
results in efficient bandwidth utilization. The disadvantage
is that all new customer routes must be added manually
to the VRFs as they are added.
ORL_PE P1
MPLS Core
Network
MIA_PE
Protocols Used in Provider Customer
Model (Continued - I)
CE CE
CE
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS
UE
1x EVDO
Network
BTS
BTS
UE
1x EVDO
Network
BTS
CE
UE
eNB
eNB eNB
LTE-EPC
Network
MP-iBGP
MP-iBGP
OSPF
LDP
OSPF
LDP
P
VRF
EVDO
VRF LTE
GRT
VRF
EVDO
VRF LTE
GRT
140

MP-iBGP between PE-PE
Normally, iBGP is used inside the core network to
transport the customer network routes to PEs. In the case
of VRFs, we may encounter the following problem.
The routes in VRFs are customer routes that may contain
private or public IP addresses overlapping or non-
overlapping with each other. In the event that any of the
customer’s routes in a VRF overlap with other VRF(s), the
iBGP in the core network advertises only one best route
based on the path determination steps. In this case, we
are depriving a VPN service to other customers which is
undesirable.
The standard BGP is modified to address this issue. The
new protocol is known as Multiple Protocol-BGP (MP-BGP).
Since MP-BGP runs within the same AS in our case it is
known as MP-iBGP.
Each VRF adds a unique 64-bit number known as a Route
Distinguisher (RD) to the IPv4 (32-bit address) while
transporting across the MP-iBGP towards other PEs. The
resulting address is known as VPNv4 address of 96 bits.
The default format of RD is an AS Number (2-bytes:4-
bytes) prepended with a type field of 2 bytes.
MP-iBGP transports VPNv4 Address, Next-hop attribute, a
VPN specific Route Target Attribute to indicate where to
populate the VPNv4 routes along with the VPN label.
MP-BGP is capable of transporting standard IPv4 routes
between the PEs, IPv6 routes between the PEs, VPNv4
routes between the PEs and VPNv6 routes between the
PEs; hence the name, Multi-Protocol BGP.
ORL_PE P1
MPLS Core
Network
MIA_PE
Protocols Used in Provider Customer
Model (Continued - II)
CE CE
CE
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS
UE
1x EVDO
Network
BTS
BTS
UE
1x EVDO
Network
BTS
CE
UE
eNB
eNB eNB
LTE-EPC
Network
MP-iBGP
MP-iBGP
OSPF
LDP
OSPF
LDP
P
VRF
EVDO
VRF LTE
GRT
VRF
EVDO
VRF LTE
GRT
141

The Legacy VPN needs only an IP network in the core and
IPSec or L2TP to tunnel the customer packets securely
over the public Internet. The IP network in the core uses
OSPF along with BGPv4 to transport the customer routes.
This solution is not scalable due to the IP bottleneck and
the manual provisioning VPN tunnels.
L3VPN based on MPLS technology breaks the IP
bottleneck. The VRFs on the PE routers enable the perfect
isolation between the VPN customers, and the
configuration involves are very few steps. L3VPN uses a
single-area OSPF and LDP to build the MPLS LSPs in the
core. The MP-iBGP protocol advertises the customer
routes of VRFs across the MPLS domain to the VRFs of all
other PEs belong to the same VPN. The customer has a
choice of several protocols between the CEs and the
respective customer VRF on the Pes, but eBGP is
preferred.
In the chart shown above, two VPN customers, EVDO and
LTE networks of the Orlando site, should be connected to
the EVDO and LTE networks of the Miami site. MP-iBGP is
used for linking customer VRFs and to transfer the routes
between them.
Before the L3VPN routing happens, the MPLS core builds
the LSPs for an all-IP network in the core using LDP. The
LSP is one way, and two LSP tunnels re-signaled to carry
the IP packets between ORL_PE and MIA_PE.
The CE routers advertise their routes into the VRFs they
are connected to using the eBGP protocol. The EVDO and
LTE VRFs are now populated with the customer routes.
The contents of the EVDO and LTE VRFs are shown below
after the eBGP updates are exchanged between PEs-CEs.
An MP-iBGP session is established between PEs. The P
router need not participate in MP-iBGP as it has no
customers/VRFs.
ORL_PE advertises the contents of VRF EVDO and VRF
LTE routes X and A. MIA_PE does the same and advertises
the contents of VRF EVDO and VRF LTE routes Y and B.
The routes received from other PEs over MP-iBGP are
advertised toward the CEs over eBGP and the customer
routing table is updated accordingly. The end-to-end
L3VPN routing is ready between the two sites after this
process and ready to forward the customer traffic
between EVDO and LTE networks.
NW Y
NWA NW B
NW X
L3VPN Routing
ORL_PE P1 MIA_PE
P
LDP: Label=20
LDP: Label=3
LDP: Label=3
LDP: Label=18 CE_EVDO
CE_LTE
CE_EVDO
CE_LTE
MP-iBGP (Route-Y and B)
MP-iBGP
e-BGP
e-BGP
MPiBGP (Route-X and A)
MP-iBGP
e-BGP
e-BGP
VRF
EVDO
VRF LTE
VRF
EVDO
VRF LTE
MPLS-LSP
MPLS-LSP
142

The end-to-end L3VPN routing is ready between Orlando
and Miami sites. The network is now ready to handle the
end-to-end VPN traffic.
The above chart describes the L3VPN forwarding of traffic
from Orlando sites towards Miami sites.
Traffic from X to Y
• CE_EVDO of Orlando: CE_EVDO of the Orlando site
sends an IP packet to destination Y, which is
parented to CE_EVDO of the Miami site. The IP packet
arrives at ORL_PE and VRF EVDO is referred for
further routing.
• ORL_PE: VRF EVDO checks the entry Y and forwards
the IP packet with Labels 18, 25; 18 being the outer
label which leads to the NH MIA_PE’s loopback
Address and 25 being the VPN Label represents the
VRF route Y on MIA_PE.
• P router: The P router pops (PHP) the label and
forwards the packet with Label 25 toward MIA_PE.
• MIA_PE: VPN Label 25 was advertised by MIA_PE for
the VRF EVDO route Y. Hence, the packet is
forwarded to VRF EVDO after popping Label 25. The
VRF EVDO refers entry Y and forwards the IP packet
toward the CE_EVDO of the Miami site.
Traffic from A to B:
• In the same way, the IP packets from the Orlando LTE
networks are forwarded toward the Miami LTE sites
using inner label 26 and outer label 18.
Traffic from Y to X and B to A:
• Traffic from Y to X and B to A follow in the same
manner described above with different set of labels,
as shown in the chart above.
NW Y
NWA NW B
NW X
L3VPN Forwarding
ORL_PE P1 MIA_PE
CE_EVDO
P
CE_LTE
CE_EVDO
CE_LTE
LDP: Label=20
LDP: Label=3
LDP: Label=3
LDP: Label=18
IP Packet 26
IP Packet 26 18
IP Packet 25
IP Packet 25 18
IP Packet
35
IP Packet
35
20
IP Packet
36
IP Packet
36
20
VRF
EVDO
VRF LTE
VRF
EVDO
VRF LTE
143

Summary
• L3VPN can be used in EVDO-UMTS-LTE backhaul.
• L3VPN is a good choice for EVDO-UMTS-PS-CN and LTE-
EPC interconnection.
• MTSOs are interconnected using VRFs for various
customer traffic using L3VPN technology.
• L3VPN has CE-PE-P routers and uses OSPF, LDP and
MP-iBGP in the core network.
• L3VPN can use eBGP as a PE-CE protocol.
• Customers’ eBGP routes are advertised to other PE
peers using MP-iBGP.
144

Review Questions
1. Which protocol carries the customer routes (L3VPN) in the MPLS-Core?
a) OSPF
b) LDP
c) MP-iBGP
d) None of the above
2. Which protocols work together to form the LSPs in the backbone
network?
a) MP-iBGP and eBGP
b) OSPF and LDP
c) None of the above
3. Why the Core Router (P-Router) is not participating in MP-iBGP route
exchange?
a) No Protocol Support on P Routers
b) No L3VPN Customers on P-Routers
c) None of the above
145

146

9 | L3VPN Routing
Chapter 9:
L3VPN Routing
147

9 | L3VPN Routing
Objectives
• Identify the routing protocols and associated
protocols used in L3VPN networks
• Describe a VRF and its related parameters
• List the MP-iBGP address families
• Define the role of RD and VPNv4 address
• Explain the use of Route-Target and VPN Labels
• Describe the use of Site-of-Origin and iBGP-
Multipath in multi-homing scenario
148

9 | L3VPN Routing
Provider-Customer
Model
149

As shown above, the L3VPN solution requires OSPF and
LDP to support MPLS.
It uses MP-iBGP to distribute customer network
information between customer networks.
eBGP is used between the CE and the PE at the edge of
the customer and provider network. The eBGP supplies
routes to the VRFs found at the PEs.
9 | L3VPN Routing
Protocols used in Provider
Customer Model
ORL_PE P1
MPLS Core
Network
MIA_PE
CE CE
CE
UE
eNB
eNB
eNB
LTE-EPC
Network
BTS
UE
1x EVDO
Network
BTS
BTS
UE
1x EVDO
Network
BTS
CE
UE
eNB
eNB eNB
LTE-EPC
Network
MP-iBGP
MP-iBGP
OSPF
LDP
OSPF
LDP
P
VRF
EVDO
VRF LTE
GRT
VRF
EVDO
VRF LTE
GRT
150

9 | L3VPN Routing
MPLS Router
151

MPLS routers are based on standard routers with
additional software to support the MPLS function.
This chart demonstrates the control plane and forwarding
plane of an MPLS router. Like a standard router, the
routing protocol functions as described earlier. We can say
that all MPLS routers can function as standard routers,
but only those routers with MPLS software can function as
MPLS routers.
Like standard routers, in an MPLS router, the routing and
forwarding functions are separated for efficient packet
forwarding. Forwarding functions are implemented in
hardware (Forwarding Plane) and Routing functions, like
exchange of routing information, sending OSPF hellos, and
updates, are processed in software (Control Plane). The
IGP routing process (for example OSPF) updates the
Routing Table (RIB) and LDP (Label Distribution Protocol)
distributes labels for the routes available in RIB. The local
labels are distributed to the LSP neighbors and the
remote labels are those received from the LDP neighbors.
All labels, ingress and egress, are stored in the Label
Information Base (LIB).
From the information in the RIB and the LIB, Forwarding
Information Bases (FIBs) are created and implemented in
hardware. FIBs allow efficient and fast forwarding
decisions to be made for each packet received.
There are four forwarding modes possible:
• Inbound IP packet leaves as standard IP packet
• Inbound IP packet leaves as labeled packet
• Inbound labeled packet leaves as labeled packet
• Inbound labeled packet leaves as standard IP packet.
Standard routing applies when an inbound IP packet
leaves as a standard IP packet. The destination address is
compared to the FIB and the longest match in the table
determines the interface that the packet must be
forwarded from to reach the next hop in its route.
When a router is an ingress router for an MPLS network, it
is called the Label Edge Router (LER). LERs use the FIB to
determine the label to be placed on a packet based on its
IP destination address. The addition of a label to a packet
is called Pushing a label. Ingress routers are the first point
of contact with the MPLS network for a packet.
9 | L3VPN Routing
RIB-LIB-FIB-LFIB
OSPF, IS-IS
eBGP etc
PROTOCOL ROUTE NEXT-HOP
O 172.16.0.131/32 GE 0/0.408
OSPF, IS-IS
eBGP etc
RIB
PE
Router
ROUTE LABEL NEXT-HOP
172.16.0.131/32 32 GE 0/0.408
LFIB
IN-
LABEL
OUT-
LABEL
ROUTE NEXT-HOP
22 32 172.16.0.131/30 GE 0/0.408
172.16.0.131/32
Local Binding=22
172.16.0.131/32
Remote Binding=37
172.16.0.131/32
Local Binding=22
172.16.0.131/32
Remote Binding=32
Label Distribution Protocol
FIB
IP Packets
Labeled Packets
Routing Process
Labeled Packets
+
IP Packets
GE 0/0.410
GE 0/0.408
ROUTE:172.16.0.131/32
LOCAL/REMOTE LABEL LSR ID
LOCAL LABEL 22 172.16.0.135:0
REMOTE LABEL 32 172.16.0.137:0
REMOTE LABEL 37 172.16.0.136:0
LIB
152

Routers in the middle of an MPLS network are called
transit routers and they swap labels to move packets
through the MPLS network. Inbound packets have labels
and only the label is examined to determine the new label
that must be swapped. As a labeled packet moves across
the MPLS network it may encounter 0–253 transit routers
until is reaches the edge of the MPLS cloud. Transit
routers use the LFIB (Label Forwarding Information Base)
to swap labels.
The last two routers on an LSP remove the label and
prepare the packet to be routed to its final destination
using standard routing procedures. The final router, know
as the egress router or ultimate router, receives an
unlabeled packet and processes it using standard routing
processes. The second to the last router on an LSP,
immediately before the egress router, is called the
penultimate router. This router removes the label and
forwards to the egress router. The label is removed here
to save double lookup at the egress router – MPLS
lookup, followed by an IP route lookup. Removing a label
is know as popping the label. When we pop the label of an
IP packet at the penultimate router it is known as a
Penultimate Hop POP (PHP) .
An LSP is a predefined path that begins at an ingress
router and continues to an egress router. The path is one
way.
FIB and LFIB are prepared based on the dynamic
information available in RIB and LIB. When the RIB and
FIB are updated based on the status of the network
topology, the contents of FIB and LFIB are also updated.
9 | L3VPN Routing
RIB-LIB-FIB-LFIB (Continued)
OSPF, IS-IS
eBGP etc
PROTOCOL ROUTE NEXT-HOP
O 172.16.0.131/32 GE 0/0.408
OSPF, IS-IS
eBGP etc
RIB
PE
Router
ROUTE LABEL NEXT-HOP
172.16.0.131/32 32 GE 0/0.408
LFIB
IN-
LABEL
OUT-
LABEL
ROUTE NEXT-HOP
22 32 172.16.0.131/30 GE 0/0.408
172.16.0.131/32
Local Binding=22
172.16.0.131/32
Remote Binding=37
172.16.0.131/32
Local Binding=22
172.16.0.131/32
Remote Binding=32
Label Distribution Protocol
FIB
IP Packets
Labeled Packets
Routing Process
Labeled Packets
+
IP Packets
GE 0/0.410
GE 0/0.408
ROUTE:172.16.0.131/32
LOCAL/REMOTE LABEL LSR ID
LOCAL LABEL 22 172.16.0.135:0
REMOTE LABEL 32 172.16.0.137:0
REMOTE LABEL 37 172.16.0.136:0
LIB
153

9 | L3VPN Routing
VPN Routing and
Forwarding
154

VPN customers spread across geography need a private
network (virtual) interconnectivity for their sites. The
virtual private network (VPN) provides the necessary
privacy and security for their operations. The service
provider network (MPLS Core) provides a VPN service for
these customers.
The MPLS networks provides VPN services by creating a
VRF Table for each customer and carrying the VRF routes
separately from the routes of other customers or the core
network.
Each customer has a Virtual Router called a VRF. Each
VRF creates its own routing table. When a VRF is created
a unique RIB and FIB are also created for each VRF,
hence the name Virtual Routing and Forwarding.
CE-PE routing protocols talk to the routing process
associated with VRFs and populate the routes in the
Routing Table (RIB) of VRF.
These routes are written in FIB of the VRF and are ready
to forward the IP packets between the customer and
MPLS core networks.
Since VRF is not distributing labels, the LIB and LFIB are
absent. In some advanced MPLS implementations, like
Inter-AS MPLS, labels are distributed to customers,
resulting in a seamless MPLS Network. In this case, LIB
and LFIB exist as well.
The VRFs and GRT are completely isolated and no internal
communication or transfer of routes possible except with
the MP-BGP Table.
9 | L3VPN Routing
ORL_PE P1
MPLS Core
Network
What is VRF?
UE
eNodeB
eNodeB eNodeB
LTE-EPC
Network
BTS
UE
BTS
1x EVDO
Network
CE
OSPF
LDP
P MIA_PE
OSPF
LDP
Routing
Process
RIB
FIB
VRF EVDO
Routing
Process
RIB
FIB
VRF LTE
Routing
Process
RIB
FIB
GRT
LDP
LIB
LFIB
CE
VRF
EVDO
VRF LTE
GRT GRT
VRF
EVDO
VRF LTE
155

Since VRFs may contain private and overlapping IP
addresses for different customers, we need to
differentiate these routes using a unique Route
Distinguisher (RD) per VRF in order for MP-BGP to carry all
customer routes. Remember that default BGP behavior
advertises only one best route outbound among the
multiple inbound advertisements received based on the
path determination algorithm.
The RD converts the customer routes of a VRF into an
unique VPNv4 route.
MP-iBGP, which is common for all customers, carries the
customer routes without dropping any as the RD ensures
that every route is unique.
The RD is not a VPN-specific number. It simply
differentiates customer routes on VRFs of a router.
RD has two formats:
1. AS Number:Number (16-bits:32-bits)
Example 1:110 where 1 is the AS Number of the PE
router and 110 is the number assigned for the
specific VRF.
2. IP Address:Number (32-bits:16-bits)
Example 172.16.0.135:110 where 172.16.0.135 is
Loopback IP Address of the PE router and 110 is the
number assigned for the specific VRF.
9 | L3VPN Routing
VRF Parameters
VRF
Parameter
Description Format Example
Route
Distinguisher
(RD)
Distinguishes the
VPN routes of
different customers
AS:Number 1:110
IP:Number 172.16.0.135:110
Export Route
Target
(RT)
Outgoing VPN routes
are identified by this
parameter
AS:Number 1:110
IP:Number 172.16.0.135:110
Import Route
Target
(RT)
Incoming VPN routes
are filtered by this
parameter
AS:Number 1:110
IP:Number 172.16.0.135:110
156

The Route Target (RT) identifies every VPN across all
locations. The RT must be the same for geographically
separated VRFs that belong to a specific VPN on different
PEs. Hence, the RT values must be unique per VPN
customer. VRFs are interconnected by this parameter.
RT has two formats:
1. Type-1 is AS Number:Number (16-bits:32-bits)
Example 1:110 where 1 is AS Number of the PE
router and 110 is the number assigned for the
specific VPN represented by VRF
2. Type-2 is IP Address:Number (32-bits:16-bits)
Example 172.16.0.135:110 where 172.16.0.135 is
Loopback IP Address of the PE router and 110 is the
number assigned for the specific VPN represented by
VRF.
Cisco, by default, uses Type-1 format for RT and RD. Type-
1‘s advantage is that it has a common AS in it. All the PE’s
fall under the same AS number (Core AS).
RT has two purposes. The RT is advertised with the VPNv4
routes to indicate the target VRFs. This is known as export
RT. The RT allows the incoming VPNv4 routes advertised
by MP-iBGP with a specific RT into VRFs after converting
back into IPv4 address. The route target configured to
filter routes with a specific RT is known as import RT. The
export and import routers must be configured per VRF.
As a convention, RT values and RD values may be the
same (110 in the example shown above).
RDs only distinguishes the overlapping routes on a router
and need not be VPN specific.
9 | L3VPN Routing
VRF Parameters (continued)
VRF
Parameter
Description Format Example
Route
Distinguisher
(RD)
Distinguishes the
VPN routes of
different customers
AS:Number 1:110
IP:Number 172.16.0.135:110
Export Route
Target
(RT)
Outgoing VPN routes
are identified by this
parameter
AS:Number 1:110
IP:Number 172.16.0.135:110
Import Route
Target
(RT)
Incoming VPN routes
are filtered by this
parameter
AS:Number 1:110
IP:Number 172.16.0.135:110
157

A customer’s routers are connected on specific interfaces
with non-overlapping IP addresses. These interfaces by
default connected to the Global Routing table of the
router. These customer interfaces must be attached to the
respective customer VRFs for the VPN operation. Once
connected the customers directly interact with the routing
protocols associated with the VRFs and advertise and
receive the routes.
This is done by a simple command issued at the
respective customer interface. Cisco routers use the
command ip vrf forwarding <name of the customer VRF>.
This command detaches the interface from the GRT and
attaches to the VRF mentioned in the command. The
process of detaching an interface from GRT and attaching
it to a VRF resets or clears the IP Address allocation.
Hence IP address and Mask must be reassigned again
manually when this action is done.
Since the interface is detached from GRT it no longer
appears in GRT as a connected route. It starts appearing
as s connected route in VRF which can be verified by a
command show ip route vrf <VRF name> on Cisco routers.
Before attaching the interface to VRFs:
The CE_EVDO and CE_LTE routers are attached to the
Orlando PE (ORL_PE) using 192.168.4.8/30 and
192.168.4.4/30 address blocks on the interfaces GE
0/0.403 and GE 0/0.402 respectively. Since by default
all the interfaces are connected to GRT these networks
appear in the Global Routing Table as connected route.
After attaching the interface to VRFs:
A command ip vrf forwarding vrf <VRF Name> is issued
on the customer interface to detach from the GRT and
attach it to the specific VRF mentioned in the command.
In the process the IP address configuration is lost and we
have to re-configure the IP address for the customer
interface on the PE side now connected to the customer
VRF. Once the IP address is configured the network
appears in VRF table instead of GRT.
9 | L3VPN Routing
Attaching an Interface to VRF
158

Facts about VRFs and interfaces:
• Many customer sites belonging to same VPN can be
connected to a specific VRF via their CE routers. That
means many interfaces can connect to the same VRF.
• An customer site cannot be connected to two
different VRFs
9 | L3VPN Routing
Attaching an Interface to VRF (Continued)
159

9 | L3VPN Routing
VPN Route Distribution
using MP-iBGP
160

Before getting deep into the MP-BGP let’s examine the
major modifications from the existing protocol BGP.
Route Advertisement
BGP is capable of transporting only IPv4 addresses. The
BGP routes thus advertised are updated into the Global
Routing Table. In the public domain the private IP
addresses defined in RFC 1918 (10.0.0.0/8;
172.16.0.0/12; 192.168.0.0/16) are not routed hence
BGP is not configured to carry these routes. In private
network, BGP can transport the private IP addresses.
MP-BGP transports IPv4 (32 bits), IPv6 (128 bits), VPNv4
(96 bits), VPNv6 (192 bits) Addresses. The VPNv4 and
VPNv6 routes belong to Private Networks and they are
populated inside the respective IPv4 VRFs or IPv6 VRFs.
You can expect RFC 1918 private IP addresses in these
VRFs. MP-BGP transports these private IP addresses in
the form of VPNv4 and VPNv6 addresses inside a public
domain but these routes are not populated into the Global
Routing Table but it goes into the respective VRFs. Hence
MP-BGP is capable of carrying both private and public
addresses in the public domain.
Route Manipulation
The route manipulation, network isolation and filtering of
the routes involve complex configuration in BGP, whereas
MP-BGP employs a simple method using Route-Targets to
manipulate the routes.
Transport of Networks
BGP is capable of transporting routes and populating the
GRT. MP-BGP can transport the routes and populate VRFs
and GRT.
Community
BGP transports only standard community of the format AS
Number:Number (16 bits:16 bits) MP-BGP can transport
both the standard community as well as the extended
community. The extended community has two formats.
The type 1 format is AS Number:Number (16 bits:32 Bits)
and the type-2 format is IP Address:Number (32 bits:16
bits).
Label
BGP is not capable of distributing a label. MP-BGP is
capable of distributing a label for the advertised routes.
9 | L3VPN Routing
BGP vs. MP-BGP
BGP
Transports only IPv4 Addresses
Distributes Customer’s Public IP
address in Public Network
Route Manipulation is Complex
Transports Networks from Global
Routing Table
Uses only the Standard
Community Attributes
Can not distribute a Label
MP-BGP
Transports IPv4, IPv6, VPNv4 and
VPNv6 Addresses
Distributes Customer’s Private
and Public IP addresses also
Route Manipulation is Simple by
the use of Route Targets
Transports Networks from Global
Routing Table and VRFs
Use both the Standard and
Extended Community Attributes
Distributes VPN Labels for VRF
routes
161

9 | L3VPN Routing
Route Distinguisher
162

The above chart represents two customers EVDO and LTE
of Orlando uses the same IP address blocks for their
networks. Two unique VRFs are created on ORL_PE router
and they are connected to CE_EVDO and CE_LTE routers
respectively. Both the CEs advertise their routes towards
PEs and they are populated in VRF EVDO and VRF LTE. So
far so good.
MP-BGP tries to carry both the networks of VRF EVDO and
VRF LTE. Since the Network numbers are same
(10.0.96.0/20) it resorts to Path Determination steps to
decide the best path for outgoing advertisement.
Path determination goes like this:
1. Weight: Since we have not set any weight it is be “0”
for both.
2. Local Preference: By default the Local Preference is
100 for both the routes.
3. Locally Originated: Both the routes are not locally
generated. Since the next-hop is other than 0.0.0.0
for both the networks, i.e., the next-hop is
192.168.4.9 EVDO and 192.168.4.5 for LTE
networks.
4. AS Path length: Both the AS Path length is 1 for both
the networks since these networks are parented to
AS 120 and AS 110 and received directly from the
respective ASs.
5. Origin: The origin for both the networks are IGP.
6. MED: No Metrics (MED) are set for the Customer
network and it is “0” for both.
7. eBGP or iBGP: Both are eBGP received routes.
8. Lowest IGP Metric to Peer: The Lowest metric is not
applicable here as both or eBGP received routes.
9. Router ID of the Peer: RID are same since both the
networks EVDO and LTE are using same RID.
10. Peer ID of the Router: The Peer ID of CE_EVDO is
192.168.4.9 and the Peer ID of CE_LTE is
192.168.4.5. The lowest Peer ID wins. Thus the
network 10.0.96.0/20 from LTE VRF is advertised
and populated across all the LTE VRFs on other PEs.
9 | L3VPN Routing
Overlapping Customer Addresses
CE_LTE
P
VRF-EVDO
PROTOCOL ROUTE
B 10.0.96.0/20
VRF-LTE
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE
MPiBGP Drops this Advertisement
IPv4 Route 10.0.96.0/20
Next-Hop IP Address ORL_PE’s Loopback
PE
PE
PE
MPiBGP Advertisement to all other PEs
IPv4 Route 10.0.96.0/20
MP-iBGP
MP-iBGP
CE_EVDO
RID: 10.0.96.65
Peer: 192.168.4.9/30
RID: 10.0.96.65
Peer: 192.168.4.5/30
Customer Addresses are Overlapping (10.0.96.0/20)
BGP Resorts to Path Selection Algorithm
CE_LTE Route with RT 1:110 is advertised
CE_EVDO Route with RT 1:120 is dropped (undesirable effect)


AS 120
RID: 10.0.96.65, Origin IGP, Metric =0
AS 110
RID: 10.0.96.65, Origin IGP, Metric=0
163

Is it a desirable effect? Will the EVDO customer like it? No.
We are depriving the VPN service for the EVDO customers.
What is the remedy then?
The VRFs will be assigned a special parameter, known as
a Route Distinguisher (RD), 64-bits in length and
prepended to the existing 32-bit IPv4 addresses residing
in the VRFs before advertisement over MP-iBGP. The RD
makes the overlapping addresses unique and MP-iBGP
advertises both the customer routes without resorting to
Path Determination steps.
9 | L3VPN Routing
Overlapping Customer Addresses
(Continued)
CE_LTE
P
VRF-EVDO
PROTOCOL ROUTE
B 10.0.96.0/20
VRF-LTE
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE
MPiBGP Drops this Advertisement
IPv4 Route 10.0.96.0/20
PE
PE
PE
IPv4 Route 10.0.96.0/20
MP-iBGP
MP-iBGP
CE_EVDO
RID: 10.0.96.65
Peer: 192.168.4.9/30
RID: 10.0.96.65
Peer: 192.168.4.5/30
Customer Addresses are Overlapping (10.0.96.0/20)
BGP Resorts to Path Selection Algorithm
CE_LTE Route with RT 1:110 is advertised
CE_EVDO Route with RT 1:120 is dropped (undesirable effect)


AS 120
AS 110
164

The overlapping address problem is solved with Route
Distinguisher (RD). The normal BGP protocol can not carry
this extended address. It is modified as MP-BGP, which
can carry multiple protocol addresses of various length.
A unique 8-byte (64-bit) Route Distinguisher is added to
the customer routes in VRF before transporting on MP-
iBGP. The route created is known as a VPNv4 route. The
VPNv4 address is 96 bits long. RD (64 bits) + IPv4 route
(32 bits) = 96-bit VPNv4. Each VRF is assigned with a
unique RD. The default format used is [AS No:Number]. By
adding a unique RD the customer routes, though
overlapping, look unique.
We assign the RD value by a one-line command: rd <AS
No :Number> inside the specific VRF.
The example above shows how RD is assigned.
We assign the RD 1:120 for EVDO VRF using the default
format [AS Number:Number]. The core AS “1” and the
customer AS “120” to derive the unique RD here. For LTE
VRF we assign the RD 1:110 using the same principle
core AS “1” and the customer AS “110”.
MP-iBGP while transporting the customer routes of VRF
prepends the pre-defined RD to the IPv4 address to make
it unique.
The EVDO network 10.0.96.0/20 after prepending the RD
looks like 1:120:10.0.96.0/116.
You may have a question here how the subnet-mask 20
has become 116. Keep this question reserved until the
RD format is discussed in the next slide.
The LTE network 10.0.96.0/20 after prepending the RD
looks like 1:110:10.0.96.0/116.
The MP-iBGP carries both the routes now as they are
unique.
9 | L3VPN Routing
Route Distinguisher
CE_LTE
P
VRF-EVDO RD 1:120; RT 1:120
PROTOCOL ROUTE
B 10.0.96.0/20
VRF-LTE RD 1:110; RT 1:110
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE
VPNv4 Route 1:120: 10.0.96.0/116
Extended Community RT 1:120
VPN Label 25
PE
PE
PE
VPNv4 Route 1:110: 10.0.96.0/116
Extended Community RT 1:110
VPN Label 26
MP-iBGP
MP-iBGP
CE_EVDO
RID: 10.0.96.65
Peer: 192.168.4.9/30
RID: 10.0.96.65
Peer: 192.168.4.5/30
RD 1:120
RD 1:110


The Route Distinguisher allows both the routes to be advertised
AS 120
AS 110
165

The Route Distinguisher uses a 64-bit format as shown in
the chart above. Two formats are currently defined.
1. Type-1 RD Format: The Type-1 RD uses [AS Number:
Number] format of [16 bits:32 bits]. A two byte type
field is prepended to this value. Examples of Type-1
RD are 1:120, 1:110.
2. Type-2 RD Format: The Type-2 RD uses [Loopback IP
address of PE:Number] of [ 32bits :16 bits]. A two
byte type field is prepended to this value. Examples of
Type-2 RD are 172.16.0.129:120,
172.16.0.129:110.
The total length of the RD, including the type field in both
the formats, is 64 bits (8 bytes). The total length of a
VPNv4 address is 96 bits, i.e., RD 64 bits + IPv4 address
32 bits = 96 bits of VPNv4 address.
Cisco routers by default uses the Type-1 RD format.
MP-iBGP does not advertise the VPNv4 address as it is as
described above. It adds the unique VPN label for this
route (picked up from the common Label base that LDP is
also using) and attach to the resultant VPNv4 address.
Three bytes comprising of a VPN label, experimental field
and S-bit are attached to the VPNv4 address. Label 20
bits + Experimental 3 bits + Bottom of the Stack bit (S-bit)
1 bit = 24 bits = 3 bytes. The experimental bits are set to
“000” if not manipulated by QoS Policy and the S-bit is set
to “1” as the VPN label is the bottom-most label next to IP
header.
Finally, the prefix length field of 1 byte in length, that was
an existing field of normal BGP to carry the subnet mask
value of the route, is also added in the beginning with the
modified subnet mask as 116 to represent the Network
Part and the remaining 12 bits as the host part of the
VPNv4 address. The Subnet Mask in VPNv4 is arrived at
thusly: Original subnet Mask Length 20 bits + RD 64 bits
+ Label-EXP-S 24 bits + Prefix-Length field 8 bits = 116
bits.
The format of 128 bits VPNv4+ VPN Label+ Prefix length
is governed by the IETF standard SAFI-128 or Subsequent
-Address Family Identifier – 128 bits.
9 | L3VPN Routing
RD Format and VPNv4 Address
Type=1 AS Number Number
(2 Bytes) (2 Bytes) (4 Bytes)
Route Distinguisher Format Type-1
8 Bytes (64 bits)
Type=2 Number
PE’s Loopback Address
Route Distinguisher Format Type-2
8 Bytes (64 bits)
Route Distinguisher Format
Type=1 AS=1 Number=110
IP=10.0.96.0
(4 Bytes)
Prefix=20
(1 Byte)
VPN Label = 26
(3 Bytes)
EXP, S
(20 Bits) (4 Bits)
Prefix=116  Prefix -Length=116 (96+20), MPLS Label=26 , EXP=0, S=1
Prefix + MPLS Label-EXP-S + RD+ IPv4 Network = VPNv4 Advertisement = SAFI 128
 Type 1 RD 1:110
IPv4:10.0.96.0/20
VPN Label = 26
(3 Bytes)
EXP, S
(20 Bits) (4 Bits)
Prefix=116 Type=1 AS=1 Number=110
IP=10.0.96.0
(4 Bytes)
(1 Byte)
(1 Byte)
VPNv4 Follows the SAFI-128 Format = 128 bits
96+20=116
IPv4 to VPNv4 conversion Process
IPv4 Address + 32 bits
RD + 64 bits
MPLS Label,-EXP-S + 24 bits
Prefix Length + 08 bits
VPNv4 Address = 128 Bits
166

9 | L3VPN Routing
VPNv4 and IPv4
Address Families
167

MP-BGP is an extended form of BGP to support many
address families. BGPv4 currently supports only IPv4
address families. Most of the MP-BGP configuration is
similar to the Normal BGP configuration. The normal BGP
is designed to transport only IPv4 advertisements. MP-
BGP carries Multiple Address Family Prefixes in one single
container between the peers.
A sample MP-BGP configuration done on Cisco Routers is
shown above.
In MP-BGP, all configurations are grouped under the same
BGP configurations but separated by different address-
families. You may notice a new command neighbor <IP
Address of the Peer> activate. All the neighbors need an
additional activate command to become functional. The
activate command is entered in their respective address
families.
The Multiple Protocol Prefixes are listed below:
• Address Family IPv4:32 bits: All IPv4 peering between
the PEs, PE-P, PE-Non-VPN CE and the related
configurations are done under this address family.
Each neighbor needs to be activated for IPv4
advertisement
• Address Family VPNv4 (64 bits RD + 32 bits IPv4): 96
bits: All additional MP-iBGP configurations between
PEs are done here. The main peering between MP-
iBGP peers are done under the BGP global
configurations as shown above.
• Address Family IPv4 VRF XYZ: The VPN customer
specific configurations are done here. eBGP for VRF
customers is configured here. In case a VRF customer
uses OSPF protocol, that routing information is
redistributed into this VRF instance so that it can be
transported across MP-BGP
In addition to the address families shown above, MP-BGP
can also transport the IPv6, VPNv6, IPv4 Multicast and
IPv6 Multicast a brief information is shown below.
• Address Family IPv6: 128 bits
• Address Family VPNv6 (64 bits RD + 128 bits IPv6):
192 bits
• IPv4 Multicast: 32 bits
• IPv6 Multicast: 128 bits
9 | L3VPN Routing
MP-iBGP and Address Families
168

9 | L3VPN Routing
Route Target
169

The RT is an extended 8-byte Community Attribute. A
unique RT extended community has to be assigned to
each VPN customer. While advertising outbound on MP-
iBGP, we attach a VPN specific RT to every MP-iBGP Peer.
Format of RT is same as RD. By default Cisco routers use
Type-1 format [AS No:Number]
RT is the VPN specific value. It should be same across all
the VRFs belong to the same customer.
The RD need not be same across the across all VRFs of a
customer (RD is locally specific on a router to differentiate
the routes from other VRFs) but, by convention, we use
the same value that was assigned to RT.
RT configuration has two parts. One is known as export
RT, which is attached to MP-BGP advertisements as
Extended Route-Target Community Attribute, along with
the VPNv4 routes advertisements. The other one is import
RT, which is to filter out only the required VPNv4 routes
with the matching RT community as in the import RT
configured for that VRF.
There are two methods to configure the route targets for
VRFs. The first one is by command “route-target both <AS
No: Number>”, which assigns the same RT for both import
and export. The other method to assign RTs is by using
commands route-target export <AS No: Number> and
route-target import <AS No: Number> to assign the export
and import RTs separately. In the case of Extranet
implementation, we use the second method to configure
different RTs to import and export.
9 | L3VPN Routing
Export/Import RT 1:130
Route-Target
MIA_PE
ORL_PE
MPBGP Table
1:130:192.168.2.128/124; RT 1:130
1:110:10.0.32.0/116; RT 1:110
1:120:10.0.48.0/116; RT 1:120
1:130:192.168.4.128/124; RT 1:130
1:110:10.0.96.0/116; RT 1:110
1:120:10.0.112.0/116; RT 1:120
VRF LTE
10.0.32.0/20
10.0.96.0/20
MPBGP Table
1:130:192.168.4.128/124; RT 1:130
1:110:10.0.96.0/116; RT 1:110
1:120:10.0.112.0/116; RT 1:120
1:130:192.168.2.128/124; RT 1:130
1:110:10.0.32.0/116; RT 1:110
1:120:10.0.48.0/116; RT 1:120
VRF LTE
10.0.96.0/20
10.0.32.0/20
VRF EVDO
10.0.112.0/20
10.0.48.0/20
VRF OAM
192.168.4.128/28
192.168.2.128/28
VRF EVDO
10.0.48.0/20
10.0.112.0/20
VRF OAM
192.168.2.128/28
192.168.4.128/28
Export RT
Import RT MP-iBGP
Export/Import RT 1:110 Export/Import RT 1:120
170

The example shown above explains the exchange of VRF
routes between ORL_PE and MIA_PE. ORL_PE has been
created with VRF LTE, VRF EVDO and VRF OAM. The LTE
customer’s route 10.0.96.0/20 is populated in VRF LTE.
The EVDO customer’s route 10.0.112.0/20 is populated
in VRF EVDO. The OAM interface’s route
192.168.4.128/28 is populated in VRF OAM.
These routes are transferred to MP-BGP table as VPNv4
routes (by prepending the RD) along with the export RT
configured.
In the same way, MIA_PE has been created with VRF LTE,
VRF EVDO and VRF OAM. The LTE customer’s route
10.0.32.0/20 is populated in VRF LTE. The EVDO
customer’s route 10.0.48.0/20 is populated in VRF EVDO.
The OAM interface’s route 192.168.2.128/28 is
populated in VRF OAM.
These routes are transferred to MP-BGP table as VPNv4
routes (by prepending the RD) along with the export RT
configured.
Now the MP-iBGP is ready to transport the routes across
to other PEs. ORL_PE receives the advertisement from
MIA_PE and vice versa.
The import RT configured in each VRF filters out the
required route with the matching RT, removes the RD and
modifies the prefix-length and writes into the IPv4 VRF.
The export RT is indicated in the chart above with an
arrow from the VRF toward the MP-BGP table and the
import of the route is shown by an arrow from the MP-BGP
table toward the VRF via an import RT filter.
The VRF LTE of ORL_PE can see only the routes of VRF
LTE belong to MIA_PE and vice versa. The same is the
case with VRF EVDO and VRF OAM.
The routes received from other PEs via MP-iBGP are
advertised toward the CE router, which is not shown in the
diagram for simplicity.
9 | L3VPN Routing
Route-Target (Continued)
MIA_PE
ORL_PE
MPBGP Table
1:130:192.168.2.128/124; RT 1:130
1:110:10.0.32.0/116; RT 1:110
1:120:10.0.48.0/116; RT 1:120
1:130:192.168.4.128/124; RT 1:130
1:110:10.0.96.0/116; RT 1:110
1:120:10.0.112.0/116; RT 1:120
VRF LTE
10.0.32.0/20
10.0.96.0/20
MPBGP Table
1:130:192.168.4.128/124; RT 1:130
1:110:10.0.96.0/116; RT 1:110
1:120:10.0.112.0/116; RT 1:120
1:130:192.168.2.128/124; RT 1:130
1:110:10.0.32.0/116; RT 1:110
1:120:10.0.48.0/116; RT 1:120
VRF LTE
10.0.96.0/20
10.0.32.0/20
VRF EVDO
10.0.112.0/20
10.0.48.0/20
VRF OAM
192.168.4.128/28
192.168.2.128/28
VRF EVDO
10.0.48.0/20
10.0.112.0/20
VRF OAM
192.168.2.128/28
192.168.4.128/28
Export RT
Import RT MP-iBGP
Export/Import RT 1:110 Export/Import RT 1:120
171

9 | L3VPN Routing
L3VPN Routing
172

Before the L3VPN routing happens the MPLS core builds
the LSPs for all of the IP network.
MIA_PE assigns and advertises Label 3 for its loopback IP
address since it is directly connected. The P router assigns
Label 18 for MIA_PE’s loopback IP address and advertises
toward ORL_PE. The LSP, with a sequence of label 18–3,
from ORL_PE to MIA_PE is signaled successfully. The
Orlando site uses this tunnel to forward the IP packets
toward the Miami site.
ORL_PE assigns and advertises Label 3 for its loopback IP
address since it is directly connected. The P router assigns
Label 20 for ORL_PE’s loopback IP address and
advertises toward MIA_PE. The LSP, with a sequence of
label 20–3, from MIA_PE to ORL_PE is signaled
successfully. The Miami site uses this tunnel to forward
the IP packets toward the Orlando site. Remember that
these LSP tunnels are one way for the IP traffic.
The CE routers of EVDO and LTE advertise their routes into
the VRFs they are connected to using the eBGP protocol.
The EVDO and LTE VRFs are now populated with the
customer routes.
Orlando: VRF EVDO:10.0.112.0/20 via CE_EVDO,
VRF LTE :10.0.96.0/20 via CE_LTE
Miami: VRF EVDO:10.0.48.0/20 via CE_EVDO,
VRF LTE :10.0.32.0/20 via CE_LTE
An MP-iBGP session is established between the loopback
address of the PEs. Full-Mesh MP-iBGP is must between
all PEs. The P router need not participate in MP-iBGP as it
has no customers/VRFs.
9 | L3VPN Routing
L3VPN Routing
ORL_PE P1 MIA_PE
VRF EVDO
VRF LTE
VRF EVDO
GRT
P
GRT
Pro Network NHOP Label(s)
B 10.0.112.0/20 CE_EVDO --------
B 10.0.48.0/20 MIA_PE 18, 25
VRF LTE
B 10.0.96.0/20 CE_LTE --------
B 10.0.32.0/20 MIA_PE 18, 26
B 10.0.48.0/20 CE_EVDO --------
B 10.0.112.0/20 ORL_PE 20, 35
B 10.0.32.0/20 CE_LTE --------
B 10.0.96.0/20 ORL_PE 20, 36
LDP: Label=20
LDP: Label=3
LDP: Label=3
LDP: Label=18
CE_EVDO
CE_LTE
CE_EVDO
CE_LTE
e-BGP
e-BGP
e-BGP
e-BGP
VPNv4=1:120 10.0.112.0/116, RT=1:120, NH=ORL_PE,
VPN Label = 35
VPNv4=1:110 10.0.96.0/116, RT=1:110, NH=ORL_PE,
VPN Label = 36
MP-iBGP
VPNv4=1:120 10.0.48.0/116, RT=1:120, NH=MIA_PE,
VPN Label = 25
VPNv4=1:110 10.0.32.0/116, RT=1:110, NH=MIA_PE,
VPN Label = 26 MP-iBGP
173

ORL_PE advertises the contents of VRF EVDO and VRF
LTE as VPNv4 routes along with the Next-Hop, Route-
Target and VPN Label toward MIA_PE.
• VPNv4=1:120:10.0.112.0/116; RT=1:120;
NH=ORL_PE’s Loopback Address; VPN Label=35
• VPNv4=1:110:10.0.96.0/116; RT=1:110;
NH=ORL_PE’s Loopback Address; VPN Label=36
MIA_PE does the same toward ORL_PE.
• VPNv4=1:120:10.0.48.0/116; RT=1:120;
NH=MIA_PE’s Loopback Address; VPN Label=25
• VPNv4=1:110:10.0.32.0/116; RT=1:110;
NH=MIA_PE’s Loopback Address; VPN Label=26
The VRF EVDO and VEF LTE of Orlando and Miami sites
are updated with the routes received over MP-IBGP. The
import Route Target configured per VRF filters and allow
only the routes with the matching RT.
The contents of EVDO and LTE VRFs are shown below
after the MP-iBGP updates are exchanged between
ORL_PE and MIA_PE.
Orlando:
• VRF EVDO:10.0.112.0/20 via CE_EVDO
10.0.48.0/20 via MIA_PE ; Label imposed { 18, 25}
• VRF LTE :10.0.96.0/20 via CE_LTE
10.0.32.0/20 via MIA_PE ; Label imposed { 18, 26}
Miami:
• VRF EVDO:10.0.48.0/20 via CE_EVDO
10.0.112.0/20 via ORL_PE ; Label imposed { 20, 35}
• VRF LTE :10.0.32.0/20 via CE_LTE
10.0.96.0/20 via ORL_PE ; Label imposed { 20, 36}
These routes received from other PEs over MP-iBGP are
advertised as IPv4 routes toward the CEs over eBGP and
the customer routing table is updated accordingly. The
CEs routing tables are not shown in the chart.
The end-to-end L3VPN routing is ready between the two
sites after this process and ready to forward the customer
traffic between EVDO Networks and LTE networks.
9 | L3VPN Routing
L3VPN Routing (Continued)
ORL_PE P1 MIA_PE
VRF EVDO
VRF LTE
VRF EVDO
GRT
P
GRT
B 10.0.112.0/20 CE_EVDO --------
B 10.0.48.0/20 MIA_PE 18, 25
VRF LTE
B 10.0.96.0/20 CE_LTE --------
B 10.0.32.0/20 MIA_PE 18, 26
B 10.0.48.0/20 CE_EVDO --------
B 10.0.112.0/20 ORL_PE 20, 35
B 10.0.32.0/20 CE_LTE --------
B 10.0.96.0/20 ORL_PE 20, 36
LDP: Label=20
LDP: Label=3
LDP: Label=3
LDP: Label=18
CE_EVDO
CE_LTE
CE_EVDO
CE_LTE
e-BGP
e-BGP
e-BGP
e-BGP
VPNv4=1:120 10.0.112.0/116, RT=1:120, NH=ORL_PE,
VPN Label = 35
VPNv4=1:110 10.0.96.0/116, RT=1:110, NH=ORL_PE,
VPN Label = 36
MP-iBGP
VPNv4=1:120 10.0.48.0/116, RT=1:120, NH=MIA_PE,
VPN Label = 25
VPNv4=1:110 10.0.32.0/116, RT=1:110, NH=MIA_PE,
VPN Label = 26 MP-iBGP
174

The end-to-end L3VPN routing is ready between Orlando
and Miami sites. The network is now ready to handle the
end-to-end VPN traffic. The above chart describes the
L3VPN forwarding of traffic from Orlando sites towards
Miami sites.
CE_EVDO of Orlando:
CE_EVDO of Orlando site sends an IP packet to the
destination 10.0.48.65, which is parented to CE_EVDO of
the Miami site. The IP packet arrives at ORL_PE and VRF
EVDO is referred for further routing.
ORL_PE:
VRF EVDO checks the entry, 10.0.48.0/20, and forwards
the IP packet with Labels 18, 25; 18 being the outer label,
which leads to the NH MIA_PE’s loopback address and 25
being the VPN label represents the VRF route
10.0.48.0/20 on MIA_PE.
P router:
The P router pops (PHP) the label and forwards the packet
with Label 25 toward MIA_PE.
MIA_PE:
The VPN Label 25 was advertised by MIA_PE for the VRF
EVDO route 10.0.48.0/20. The packet is forwarded to
VRF EVDO after popping Label 25. The VRF EVDO refers
the entry 10.0.48.0/20 and forwards the IP packet
toward the CE EVDO of the Miami site.
In the same way, the IP packets from Orlando LTE
networks are forwarded toward Miami LTE sites using
inner label 26 and outer label 18.
9 | L3VPN Routing
L3VPN Forwarding ORL to MIA
ORL_PE P1 MIA_PE
CE_EVDO
VRF EVDO
VRF LTE
VRF EVDO
GRT
P
GRT
CE_LTE
CE_EVDO
CE_LTE
VRF LTE LDP: Label=20
LDP: Label=3
LDP: Label=3
LDP: Label=18
IP Packet 26
IP Packet 26 18
IP Packet 25
IP Packet 25 18
B 10.0.112.0/20 CE_EVDO --------
B 10.0.48.0/20 MIA_PE 18, 25
B 10.0.96.0/20 CE_LTE --------
B 10.0.32.0/20 MIA_PE 18, 26
B 10.0.48.0/20 CE_EVDO --------
B 10.0.112.0/20 ORL_PE 20, 35
B 10.0.32.0/20 CE_LTE --------
B 10.0.96.0/20 ORL_PE 20, 36
175

The above chart describes the L3VPN forwarding of traffic
from Miami sites towards Orlando sites.
CE_EVDO of Miami:
CE_EVDO of Miami site sends an IP packet to the
destination 10.0.112.65, which is parented to CE_EVDO
of the Orlando site. The IP packet arrives at MIA_PE and
VRF EVDO is referred for further routing.
MIA_PE:
VRF EVDO checks the entry, 10.0.112.0/20, and forwards
the IP packet with Labels 20, 35; 20 being the outer label,
which leads to the NH ORL_PE’s loopback address, and
35 being the VPN Label represents the VRF route
10.0.112.0/20 on ORL_PE.
P router:
The P router pops (PHP) the label and forwards the packet
with Label 35 toward ORL_PE.
ORL_PE:
The VPN Label 35 was advertised by ORL_PE for the VRF
EVDO route 10.0.112.0/20. The packet is forwarded to
VRF EVDO after popping Label 35. The VRF EVDO refers
the entry 10.0.112.0/20 and forwards the IP packet
toward the CE EVDO of Orlando Site.
In the same way, the IP Packets from Miami LTE networks
are forwarded toward Orlando LTE sites using inner label
36 and outer label 20.
9 | L3VPN Routing
L3VPN Forwarding MIA to ORL
ORL_PE P1 MIA_PE
CE_EVDO
VRF EVDO
VRF LTE
VRF EVDO
GRT
P
GRT
CE_LTE
CE_EVDO
CE_LTE
VRF LTE LDP: Label=20
LDP: Label=3
LDP: Label=3
LDP: Label=18
IP Packet
35
IP Packet
35
20
IP Packet
36
IP Packet
36
20
B 10.0.112.0/20 CE_EVDO --------
B 10.0.48.0/20 MIA_PE 18, 25
B 10.0.96.0/20 CE_LTE --------
B 10.0.32.0/20 MIA_PE 18, 26
B 10.0.48.0/20 CE_EVDO --------
B 10.0.112.0/20 ORL_PE 20, 35
B 10.0.32.0/20 CE_LTE --------
B 10.0.96.0/20 ORL_PE 20, 36
176

The Site-of-Origin (SoO) is the Extended Community
Attribute that is attached with MP-BGP advertisements
when configured. It uses a 64-bit format. RD and RT also
uses the same format. Two formats are currently defined.
Type-1: [AS Number: Number] format of [16 bits: 32 bits].
Type-2: [Loopback Address of PE: Number]. Cisco routers
use Type-1 SoO format by default.
SoO is useful in the multi-homing scenario shown for CE
routers. SoO is always implemented when the AS_Override
feature is used L3VPN. With AS _Override the original AS
number is replaced with the Core AS number and the loop
cannot be prevented based on the AS_Path attribute by
comparing the self’s AS number in the AS_Path attribute.
In this situation SoO plays an important role.
SoO identifies the Site-of-Origin. Let’s assign SoO for EVDO
and LTE networks of Orlando Site-4: CE_EVDO of Orlando
is 120:4 and CE_LTE of Orlando is 110:4. In our example
above, CE_EVDO and CE_LTE of Orlando site are
connected to ORL_PE1 and ORL_PE2 for redundancy.
CE_EVDO advertises 10.0.112.0/20 with AS_Path
attribute 120 using eBGP. The ORL_PE1 and ORL_PE2
routers records this route in VRF EVDO.
CE_LTE advertises 10.0.96.0/20 with AS_Path attribute
110 using eBGP. The ORL_PE1 and ORL_PE2 routers
records this route in VRF LTE.
The AS_Override feature is used in the Core Network to
connect all the EVDO and LTE networks as the same AS
number is used across all the sites. We have to advertise
the SoO along with the VPNv4, RT, NH and Label.
9 | L3VPN Routing
AS 110
Site-of-Origin
P
VRF-EVDO
PROTOCOL ROUTE
B 10.0.112.0/20
VRF-LTE
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE2
PE
MIA_PE1
CE_LTE
VRF-EVDO
PROTOCOL ROUTE
B 10.0.112.0/20
VRF-LTE
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE1
eBGP
CE_EVDO
Site-of-Origin
120:4
Site-of-Origin
110:4
eBGP
eBGP
eBGP
AS 120
VRF EVDO
VRF LTE
MIA_PE2
VRF EVDO
VRF LTE

SoO 120:4
SoO 110:4

SoO 120:4
SoO 110:4




177

ORL_PE1 advertises the SoO 120:4 and 110:4 for EVDO
and LTE networks over MP-iBGP. ORL_PE2 advertises the
same. These advertisements are received by all other
sites that have different SoO configured. The SoO of other
sites are not shown in the diagram.
ORL_PE1 is also peering with ORL_PE2 and vice versa.
ORL_PE1’s advertisement with SoO 120:4 is received by
ORL_PE2 for EVDO routes. The VRF EVDO on ORL_PE2
rejects these routes since it is matching with the SoO
configured for the VRF EVDO. The same is the case with
the routes of VRF LTE with SoO 110:4.
Thus the Site-of-Origin (SoO) prevents a routing loop of the
customer routes when the AS_Override feature is being
used.
9 | L3VPN Routing
Site-of-Origin (Continued)
AS 110
P
VRF-EVDO
PROTOCOL ROUTE
B 10.0.112.0/20
VRF-LTE
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE2
PE
MIA_PE1
CE_LTE
VRF-EVDO
PROTOCOL ROUTE
B 10.0.112.0/20
VRF-LTE
PROTOCOL ROUTE
B 10.0.96.0/20
ORL_PE1
eBGP
CE_EVDO
Site-of-Origin
120:4
Site-of-Origin
110:4
eBGP
eBGP
eBGP
AS 120
VRF EVDO
VRF LTE
MIA_PE2
VRF EVDO
VRF LTE

SoO 120:4
SoO 110:4

SoO 120:4
SoO 110:4




178

RT and SoO are Extended Community Attributes that are
attached with MP-BGP advertisements when configured to
do so.
They use a 64-bit format as shown in the chart above. RD
also uses the same format. Two formats are currently
defined.
• Type-1 RT/SoO Format: [AS Number: Number] format
of [16 bits: 32 bits]. A two-byte type field is
prepended to this value. The type field contains
additional information to differentiate the RT from
SoO.
Examples of Type-1 RT/SoO are: 1:120, 1:110.
• Type-2 RT/SoO Format: The Type-2 RT/SoO uses
[Loopback Address of PE: Number] format of [32 bits:
16 bits]. A two byte type field is prepended to this
value. The type field contains additional information
to differentiate the RT from SoO.
Examples of Type-2 RT/SoO are 172.16.0.129:120,
172.16.0.129:110.
The total Length of RT/SoO including the type field in both
the formats is 64 bits (8 bytes).
Cisco routers use the Type-1 RT/SoO format by default.
9 | L3VPN Routing
Route-Target/Site-of Origin Format
Type=1 AS Number Number
Route Target and Site-of-Origin Format Type-1
8 Bytes (64 bits)
Type=2 Number
PE’s Loopback Address
Route Target and Site-of-Origin Format Type-2
8 Bytes (64 bits)
Route Target and Site-of-Origin Format
179

BGP multipath is the feature of MP-iBGP to install the
multiple paths to the same destination in the routing table
instead of choosing the best one based on the Path
Determination algorithm. When this feature is enabled,
the path determination algorithm is ignored. When CEs
are multi-homing, this feature can be used. The
advantages of BGP multipath are load balancing and fast
convergence in the MPLS Core.
In the chart shown above, the EVDO network of Palm Bay
Site-1 is multi-homed to PALM_PE1 and PALM_PE2, and
advertises 10.0.16.0/20 with AS_Path 120.
These advertisements reach TAM_PE1 and TAM_PE2
routers at Tampa Site-3. Both the PE routers at the Tampa
site receives an advertisement from PALM_PE1 and
PALM_PE2.
Since the iBGP multipath feature is configured in the VRFs
of TAM_PE1 and TAM_PE2, it overrides the path
determination algorithm and records both the paths for
the destination 10.0.16.0/20.
The iBGP multipath feature is available on MPLS enabled
routers. In the case that CE routers are MPLS-capable we
can implement the eBGP multipath feature on CEs to
install the multiple paths.
9 | L3VPN Routing
iBGP Multipath Example
PALM_PE2 P1 TAM_PE2
CE CE
BTS
UE
1x EVDO
Network
BTS
P2
AS 120
1xEVDO
TAM Site-3
MP-iBGP
PALM_PE1 P1
Core Network AS 1
TAM_PE1
P1
MP-iBGP
VRF
EVDO
VRF
EVDO
VRF
EVDO
VRF
EVDO
AS 120
1xEVDO
PALM Site-1
BTS
UE
1x EVDO
Network
BTS
10.0.16.0/20
AS_Path: 1
NH:172.16.0.129
10.0.16.0/20
AS_Path: 1
NH:172.16.0.130
AS_Override 120  1
180

9 | L3VPN Routing
Summary
• L3VPN uses the Provider-Customer Model.
• L3VPN requires OSPF, LDP and MPLS in the Core.
• eBGP is usually used between the PE and CE.
• MP-iBGP is used to exchange the routes between VRFs.
• MP-iBGP adds RD to the VRF routes, converts to VPNv4 and
advertises to other PEs.
• The Route-Target, Next-Hop, and VPN Label are also
advertised for each VPNv4 Route by MP-iBGP.
• The IP Packets of VPN customers are forwarded over the
MPLS Core by stacking with VPN Label (inner label) and IGP
Label (outer label).
181

9 | L3VPN Routing
Review Questions - I
1. The Forwarding Information Base (FIB) is used to forward:
A. Only IP packets.
B. Only labelled packets.
C. Both IP packets and labelled IP packets.
2. The Label Forwarding Information Base (LFIB) is used to forward:
A. Only IP packets.
B. Only labelled packets.
C. Both IP packets and labelled IP packets.
3. The VRF parameters are:
A. RD, Import-RT, Export-RT and Next-Hop Attribute.
B. RD, Import-RT and Export RT.
C. RD and Export RT.
182

9 | L3VPN Routing
Review Questions - II
4. The purpose of the Import-RT is to:
1. Allows only the route with the matching RT .
2. Allows only the route with the matching RD.
3. Allows only the route with matching RT and RD.
5. Site-of-Origin (SoO) is advertised in MP-iBGP to:
1. To prevent routing loops for the customer routes.
2. To prevent routing loops for the provider routes.
3. To prevent routing loops for all network routes.
6. The advantage of the iBGP Multipath feature in multi-homing
scenario is:
1. The convergence time is negligible in case of single-link failure.
2. Load balancing in the MPLS Core in not required.
3. MPLS Core Bandwidth is multiplied.
183

184

Acronyms
3G Third Generation Wireless Systems
4G Fourth Generation Wireless Systems
AAA Authentication, Authorization and Accounting
ABR Area Border Router
AP Access Point
AS Autonomous System
ASBR Autonomous System Boundary Router
AT Access Terminal
BDR Backup Designated Router
BGP Border Gateway Protocol
BGPv4 Border Gateway Protocol version 4
BTS Base Transceiver Station
CE Customer Edge
CIDR Classless Inter-Domain Routing
CN Core Network
DP Data Path
DR Designated Router
eBGP exterior Border Gateway Protocol
EGP External Gateway Protocol
eNB Evolved NodeB or E-UTRAN NodeB
EPC Evolved Packet Core
EXP Experimental
FIB Forwarding Information Base
FL Forward Link
GGSN Gateway GPRS Support Node
GigE Gigabit Ethernet
GPRS General Packet Radio Service
GRT Global Routing Table
GW Gateway
HA Home Agent
HSS Home Subscriber Server
IANA Internet Assigned Numbers Authority
iBGP interior Border Gateway Protocol
ICMP Internet Control Message Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IMS IP Multimedia Subsystem
IP Internet Protocol
IPS Intrusion Prevention System
IPv4 Internet Protocol version 4
185

Acronyms
IPv6 Internet Protocol version 6
IS Interim Standard
ISP Internet Service Provider
L3VPN Layer 3 Virtual Private Network
LAN Local Area Network
LDP Label Distribution Protocol
LER Label Edge Router
LFIB Label Forwarding Information Base
LIB Label Information Base
LSA Link State Advertisement
LSDB Link State Database
LSP Labeled Switched Path
LSR Label Switched Router
LTE Long Term Evolution
MAC Medium Access Control
MED Multi Exit Discriminator
MLS Multi Layer Switch
MME Mobility Management Entity
MP-BGP Multi Protocol Border Gateway Protocol
MPLS Multi Protocol Label Switching
MSC Mobile Switching Center
MSTP Multiple Spanning Tree Protocol
MTSO Mobile Telephone Switching Office
MTU Maximum Transmission Unit
NTE Network Termination Equipment
OAM Operations, Administration and Maintenance
OSPF Open Shortest Path First
P Provider node
PCF Packet Control Function
PDSN Packet Data Serving Node
PE Provider Edge
P-GW Packet Data Network Gateway
PHP Penultimate Hop Pop
POP Point of Presence
PS Packet-Switched
PS-CN Packet Switched Core Network
PVSTP+ Per-VLAN Spanning Tree Protocol Plus
QoS Quality of Service
RD Route Distinguisher
RFC Request For Comment
RIB Routing Table
186

Acronyms
RID Router ID
RIP Routing Information Protocol
RNC Radio Network Controller
RR Route Reflector
RSTP Rapid Spanning Tree Protocol
RT Route Target
S1-U S1 - User Plane
SAFI Subsequent-Address Family Identifier
SGSN Serving GPRS Support Node
S-GW Serving Gateway
SoO Site-of-Origin
SPF Shortest Path First
STP Spanning Tree Protocol
SW Switch
TCP Transmission Control Protocol
UE User Equipment
UMTS Universal Mobile Telecommunications System
VLAN Virtual Local Area Network
VPN Virtual Private Network
VPNv4 Virtual Private Network Version 4 (Cisco)
VRF Virtual Routing and Forwarding
187

188

References
Standards
1. Moy, J., OSPF Version 2, RFC 2328, RFC 2328, April 1998.
2. Berger, L., Bryskin, I., et al, The OSPF Opaque LSA Option, RFC 5250, July 2008.
3. Rekhter, Y. (ed.), Li T. (ed.), and Hares, S. (ed.), A Border Gateway Protocol 4, RFC 4271, January 2006.
4. T. Bates, R. Chandra, D. Katz, Y. Rekhter , Multiprotocol Extensions for BGP-4 , RFC4760, January 2007 DRAFT
STANDARD
5. Rosen, E., Viswanatha, A., and Callon, R., Multiprotocol Label Switching Architecture, RFC 3031, January 2001.
6. E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta , MPLS Label Stack Encoding ,
RFC3032, January 2001 PROPOSED STANDARD
7. Andersson, L. (ed.), Minei, I. (ed.), and Thomas, B. (ed.), LDP Specification, RFC 5036, October 2007.
8. B. Thomas, E. Gray , LDP Applicability, RFC3037, January 2001, INFORMATIONAL RFC
9. Rosen, E., and Rekhter, Y., BGP/MPLS IP Virtual Private Networks (VPNs), RFC 4364, February 2006.
10. IEEE Std 802.1q-2005, IEEE Standard for Local and Metropolitan Area Networks – Virtual Bridged Local Area
Networks.
11. IEEE Std 802.1d-2004, IEEE Standard for Local and Metropolitan Area Networks – Media Access Control
(MAC) Bridges.
Web Sites
1. http://www.ietf.org
2. http://www.ieee.org
3. http://www.iana.org
4. http://www.cisco.com
5. http://www.ciscopress.com
Books
1. Jeff Doyle - CCIE No. 1919, Jennifer Carroll - CCIE No. 1402, CCIE Professional Development Routing TCP/IP,
Volume I, Second Edition, Cisco Press, October 2005
2. Jeff Doyle, Jennifer DeHaven Carroll, Routing TCP/IP, Volume II (CCIE Professional Development), Cisco Press,
Apr 2001
3. Ivan Pepelnjak, Jim Guichard, MPLS and VPN Architectures, Cisco Press, Oct 2000
4. Ivan Pepelnjak, Jim Guichard, Jeff Apcar, MPLS and VPN Architectures, Volume II, Cisco Press, Jun 2003
5. Lancy Lobo - CCIE No. 4690, Umesh Lakshman, MPLS Configuration on Cisco IOS Software, Cisco Press,
October 2005
189

Exploring IP Routing and Ethernet Bridging.pdf

More Related Content

Similar to Exploring IP Routing and Ethernet Bridging.pdf (20)

More from RandyDookheran1 (11)

Recently uploaded (20)

Exploring IP Routing and Ethernet Bridging.pdf