TA6 Switching (: IP-Multi Protocol Label Ip-Mpls)
TA6 Switching (: IP-Multi Protocol Label Ip-Mpls)
TA6 Switching (: IP-Multi Protocol Label Ip-Mpls)
इरिसेट IRISET
TA 6
Multi Protocol Label Switching
(MPLS)
September 2021
TA 6
IP MPLS
Contents
Page
Ch.No. Chapter
No.
Abbreviations i
1. Introduction of MPLS 1
1.1 Introduction
1.2 Functioning of MPLS
1.3 MPLS Components
1.4 Working of IP MPLS
1.4.1 MPLS Packet Forwarding and Label Switching
1.5 MPLS Operations
1.6 Routing mechanism in MPLS
1.6.1 Data flow in IP MPLS
References 65
Annexure-1: Railway Board Circular on MPLS on IR 66
Annexure-2: TAN on implementation of IP MPLS on IR 68
Annexure-3: Committee Report On Future Of Telecommunication On IR 86
Annexure-4: Article on Design and Implementation of IP MPLS
117
Network in SR
Applications 125
Index 128
Prepared by : Shri. D Anandam, ITE1, Shri. K Mohana Krishna, INW1,
Shri. Vidya Bhushan, ICP2
Reviewed by : Shri. R Dinesh, PT, Shri. D Janardhan, LIT
Approved by : Shri. Susheel Namdeo, SPT-2
DTP and Drawings : Shri. K Srinivas,JE(D)
Version No. : 1.0
No. of Pages : 140
No. of Sheets : 70
© IRISET
“This is the intellectual property for exclusive use of Indian Railways. No part of this publication
may be stored in a retrieval system, transmitted or reproduced in any way, including but not
limited to photo copy, photograph, magnetic, optical or other record without the prior agreement
and written permission of IRISET, Secunderabad, India”
http://www.iriset.indianrailways.gov.in
Abbreviations
Terms Abbreviations
ABR Area Border Router
AD Administrative Distance
AFI Authority and Format Identifier
ARPANET Advance Research Projects Agency Network
AS Autonomous System
ASBR Autonomous System Border Router
ASN Autonomous System Number
ATM Asynchronous Transfer Mode
BDR Backup Designated Router
BGP Boarder Gateway Protocol
CAR Committed Access Rate
CBR Constraint Based Routing
CE Customer Edge
CLI Command Line Interface
CLNP Connectionless Network Protocol
CoS Class of Service
CSNP Complete Sequence Number PDU
DBD Data-Base Description
DMNR Dynamic Mobile Network Routing
DR Designated Router
DSL Digital Subscriber Line
DSP Domain Specific Part
ECN Explicit Congestion Notification
EGP Exterior Gateway Protocol
EIGRP Enhanced Interior Gateway Routing Protocol
FEC Forward Equivalence Class
FRR Fast Re-Route
HO-DSP High Order DSP
IDI Initial Domain Identifier
IDP Initial Domain Part
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
i
IOS Internetwork Operating System
ISP Internet Service Provider
LDP Label Distribution Protocol
LER Label Edge Router
LIB Label Information Base
LSA Link State Advertisement
LSAck Link State Acknowledgement
LSP Level Switched Path
LSP Label Switched Path
LSR Label Switched Router
LSU Link State Update
MOSPF Multicast OSPF
MP-BGP Multiprotocol BGP
MPLS Multi-Protocol Label Switching
MPLS-TE MPLS Traffic Engineering
MQC Modular Quality of Service Command-Line Interface
NBMA Non-Broadcast Multi-Access network
NHRP Next Hop Resolution Protocol
NRLI Network Layer Reachability Information
NSAP Network Service Access Point
ODR On Demand Routing
OSI Open System Interconnect
OSPF Open Shortest Path First
PE Provider Edge
PHP Penultimate Hop Popping
QoS Quality of Service
RD Route Distinguisher
RIB Routing Information Base
RIP Routing Information Protocol
RIPng RIP next generation
RSVP Resource Reservation Protocol
RT Route Target
SLA Service Level Agreements
SONET Synchronous Optical Networking
ii
TCP Transmission Control Protocol
TDP Tag Distribution Protocol
ToS Type of Service
UDP User Datagram Protocol
UHP Ultimate Hop Popping
VLSM Variable Length Subnet Mask
VPLS Virtual Private LAN Service
VPN Virtual Private Network
VRF Virtual Routing and Forwarding
WFQ Weighted For Queuing
WRED Weighted Random Early Detection
iii
THIS PAGE IS LEFT BLANK INTENTIONALLY
iv
Back to Contents
CHAPTER-1
INTRODUCTION OF MPLS
1.1 INTRODUCTION
What this means is that the router no longer forwards packets based on a software dependent
and longer look-up in the route table but fast switches packets based on the label. This delivers
huge performance benefits as well as flexibility.
MPLS is scalable and protocol-independent. In an MPLS network, data packets are assigned
labels. Packet-forwarding decisions are made solely on the contents of this label, without the
need to examine the packet itself. This allows one to create end-to- end circuits across any type
of transport medium, using any protocol. The primary benefit is to eliminate dependence on a
particular OSI model data link layer (layer 2) technology, such as Asynchronous Transfer Mode
(ATM), Frame Relay, Synchronous Optical Networking (SONET) or Ethernet, and eliminate the
need for multiple layer-2 networks to satisfy different types of traffic. Multiprotocol label
switching belongs to the family of packet-switched networks.
MPLS operates at a layer that is generally considered to lie between traditional definitions of
OSI Layer 2 (data link layer) and Layer 3 (network layer), and thus is often referred to as a layer
2.5 protocol. It was designed to provide a unified data-carrying service for both circuit-based
clients and packet switching clients which provide a datagram service model. It can be used to
carry many different kinds of traffic, including IP packets, as well as native ATM, SONET, and
Ethernet frames.
A number of different technologies were previously deployed with essentially identical goals,
such as Frame Relay and ATM. Frame Relay and ATM use "labels" to move frames or cells
throughout a network. The header of the Frame Relay frame and the ATM cell refers to the
virtual circuit that the frame or cell resides on. The similarity between Frame Relay, ATM, and
MPLS is that at each hop throughout the network, the ―label‖ value in the header is changed.
This is different from the forwarding of IP packets. MPLS technologies have evolved with the
strengths and weaknesses of ATM in mind. MPLS is designed to have lower overhead than
ATM while providing connection-oriented services for variable-length frames, and has replaced
much use of ATM in the market.
LER's are located at the boundary of the MPLS network. They apply label to packets for
transmission across the MPLS network. LER's are responsible for classifying incoming IP traffic
and relating the traffic to the appropriate label. The LER converts IP packets into MPLS
packets, and MPLS packets into IP packets. In MPLS, this classification process is called
forward equivalence class (FEC).
These devices are routers, and they examine incoming packets, providing that a label is
present. The LSR will look up and follow the label instruction and then forward the packet
according to the instruction. In general, the LSR performs a label swapping function.
When the packets leave the LER, they are destined for LSR where they are examined for the
presence of label. The LSR looks to its forwarding table (called a label information base LIB or a
connectivity table) for instructions. The LSR will swap labels according to the LIB instructions.
In between LER and LSR paths are established, these paths are called LSP. The paths are
designed for their traffic characteristic; as such, they are very similar to ATM paths. The traffic
handling capabilities of each path is calculated. These characteristics can include peak traffic
load, inter-packet variation, and dropped packet percentage calculation.
LDP's are used to distribute label information between LSR's and LER's. It also defines a new
protocol, existing protocols, such as BGP and RSVP, have been extended to enable label
distribution to be stacked on them.
When a packet arrives on the ingress Label Switch Router (LSR), also called the Provider Edge
(PE) router, the PE router assigns a label to transport the packet through the MPLS network.
As shown in each LSR performs a specific function; for example, the LSR at the edge performs
either label imposition (also known as the push functions) or label removing (also known as the
pop function). Other LSRs in the path simply swap the labels.
MPLS works by prefixing packets with an MPLS header, containing one or more labels. This is
called a label stack. Each entry in the label stack contains four fields:
A 20-bit label value. A label with the value of 1 represents the router alert label.
A 3-bit Traffic Class field for QoS (equality of service) priority and ECN (Explicit Congestion
Notification). Prior to 2009 this field was called EXP.
A 1-bit bottom of stack flag. If this is set, it signifies that the current label is the last in the
stack.
An 8-bit TTL (time to live)field.
MPLS LABEL
…………………………
0 1 2 19 20 21 22 23 24 25 26 27 28 29 30 31
………
Label-20 bits TC-3 bits S-1bit TTL-8 bits
These MPLS-Label packets are switched after a label lookup/switch instead of a lookup into the
IP table. As mentioned above, when MPLS was conceived, label lookup and label switching
were faster than a Routing table or RIB (Routing Information Base) lookup because they could
take place directly within the switched fabric and avoid having to use the OS.
The presence of such a label, however, has to be indicated to the router/switch. In the case of
Ethernet frames this is done through the use of Ether Type values 0x8847 and 0x8848, for
unicast and multicast connections respectively.
When an unlabelled packet enters the ingress router and needs to be passed on to an MPLS
tunnel, the router first determines the forwarding equivalence class (FEC) for the packet and
then inserts one or more labels in the packet’s newly created MPLS header. The packet is then
passed on to the next hop router for this tunnel.
The MPLS Header is added between the network layer header and link layer header of the OSI-
model.
When a labelled packet is received by an MPLS router, the topmost label is examined. Based
on the contents of the label a swap, push (impose) or pop (dispose) operation is performed on
the packet’s label stack. Routers can have prebuilt lookup tables that tell them which kind of
operation to do based on the topmost label of the incoming packet so they can process the
packet very quickly.
In a swap operation the label is swapped with a new label, and the packet is forwarded along
the path associated with the new label.
In a push operation a new label is pushed on top of the existing label, effectively
―encapsulating‖ the packet in another layer of MPLS. This allows hierarchical routing of
MPLS packets. Notably, this is used by MPLS VPNs.
In a pop operation the label is removed from the packet, which may reveal an inner label
below. This process is called ―decapsulation‖. If the popped label was the last on the label
stack, the packet ―leaves‖ the MPLS tunnel. This can be done by the egress router, but see
Penultimate Hop Popping (PHP) below.
During these operations, the contents of the packet below the MPLS Label stack are not
examined. Indeed, transit routers typically need only to examine the topmost label on the stack.
The forwarding of the packet is done based on the contents of the labels, which allows
―protocol-independent packet forwarding‖ that does not need to look at a protocol-dependent
routing table and avoids the expensive IP longest prefix match at each hop.
At the egress router, when the last label has been popped, only the payload remains. This can
be an IP packet or any of a number of other kinds of payload packet. The egress router must,
therefore, have routing information for the packet’s payload since it must forward it without the
help of label lookup tables. An MPLS transit router has no such requirement.
Usually (by default with only one label in the stack, accordingly to the MPLS specification), the
last label is popped off at the penultimate hop (the hop before the egress router). This is called
penultimate hop popping (PHP). This may be interesting in cases where the egress router has
many packets leaving MPLS tunnels, and thus spends inordinate amounts of CPU time on this.
By using PHP, transit routers connected directly to this egress router effectively offload it, by
popping the last label themselves. In the label distribution protocols, this PHP label pop action is
advertised as label value 3 « implicit-null» (which is never found in a label, since it means that
the label is to be popped).
This optimization is no longer that useful (like for initial rationales for MPLS – easier operations
for the routers). Several MPLS services (including end-to-end QoS management, and 6PE)
imply to keep a label even between the penultimate and the last MPLS router, with a label
disposition always done on the last MPLS router: the «Ultimate Hop Popping» (UHP). Some
specific label values have been notably reserved for this use:
0: «explicit-null» forIPv4
2: «explicit-null» forIPv6
PE1 does a Layer 3 lookup, performs P does a label lookup, swaps labels (L2),
label imposition, prepends label (L1) and forwards the packet to PE3
(also known as the push function), and
forwards the packet to Provider (P) router.
P
(LSR)
L1 IP Packet L2 IP Packet
IP Packet arrives at the Provider PE3 does a label lookup, performs label
Edge (PE1) router, which is also disposition, (also known as the pop function),
the Edge LSR (Label Switch Router) does a Layer 3 lookup and forwards the packet to
the next-hop CE as per routing table.
Definitions
CE/PE = Customer Edge (CE) router connects to the
Provider Edge (PE) router (also known as LSR, Label
Switch Router) via some sort of attachment circuit, for
example, Ethernet, PPP, Frame Relay, or ATM.
All the salient features of MPLS network is achieved just by Label switching using LDP protocol
which is incorporated in TCP/IP protocol suit. LDP is a 32 bit length additional layer incorporated
in between Network layer and Data link layer. Hence it is also called 2.5 layer or Shin layer. The
Label switching mechanism combines the advantages of layer 2 switching technologies with
layer 3 routing technologies. The beauty of MPLS is that it’s not tied to any underlying
technology.
The Label Distribution Protocol (LDP) is a protocol defined by the IETF for the purpose of
distributing and mapping labels for underlying routing information provided by an IGP protocols
like OSPF, IS-IS in order to forward packets by using labels in an MPLS environment. LDP
allows routers to establish label-switched paths (LSPs) through a network by mapping network-
layer routing information directly to data link layer-switched paths. Multiple labels can be used
for MPLS packet encapsulation, outer label always used for switching MPLS packets in network
and remaining inner labels used for services (VPNs etc.)
Like a static route, a static LSP requires each router along the path to be configured explicitly.
You must manually configure the path and its associated label values. Static LSPs require less
processing by the LSRs because no signalling protocol is used. However, because paths are
statically configured, they cannot adapt to network conditions. Topology changes and network
outages can create black holes in the LSP that exist until you manually reconfigure the LSP.
Dynamic LSPs use signalling protocols to establish themselves and propagate LSP information
to other LSRs in the network. You configure the inbound router with LSP information that is
transmitted throughout the network when you enable the signalling protocols across the LSRs.
Because the LSRs must exchange and process signalling packets and instructions, dynamic
LSPs consume more resources than static LSPs. However, dynamic LSPs can avoid the
network black holes of static LSPs by detecting topology changes and outages and propagating
them throughout the network.
LDP is a protocol that automatically generates and exchanges labels between routers. LDP first
establishes a neighbour adjacency before it exchanges label information. Each router will locally
generate labels for its prefixes and will then advertise the label values to its neighbours. It's a
standard, based on Cisco's proprietary TDP (Tag Distribution Protocol).
First adjacent routers send UDP multicast hello packets to discover other neighbours. Once two
routers decide to become neighbours, they build the neighbour adjacency using a TCP
connection. This connection is then used for the exchange of label information. Normally a
loopback interface is used for the neighbour adjacency.
The hello packets are sent to multicast address 224.0.0.2 using source/destination UDP port 646.
Each router has a unique ID called the LSR (Label Switch Router) ID. This is similar to how
most protocols select an ID; by default, it will select the highest IP address on a loopback
interface. If it doesn’t have any loopback interfaces then it will use the highest IP address on a
physical interface and use to build the actual TCP connection. LDP will only form a single
neighbour adjacency, no matter how many interfaces the routers have in between.
LDP is a signalling protocol that runs on a device configured for MPLS support. The successful
configuration of both MPLS and LDP initiates the exchange of TCP packets across the LDP
interfaces. The packets establish TCP-based LDP sessions for the exchange of MPLS
information within the network. Enabling both MPLS and LDP on the appropriate interfaces is
sufficient to establish LSPs.
Because LDP runs on top of an IGP such as IS-IS or OSPF, LDP and the IGP must configure
on the same set of interfaces. After both are configured, LDP begins transmitting and receiving
LDP messages through all LDP-enabled interfaces. Because of LDP's simplicity, it cannot
perform the true traffic engineering which RSVP can perform. LDP does not support bandwidth
reservation or traffic constraints.
LDP can operate in many modes to suit different requirements; however, the most common
usage is unsolicited mode, which sets up a full mesh of tunnels between routers.
In solicited mode, the ingress router sends an LDP label request to the next hop router, as
determined from its IP routing table. This request is forwarded on through the network hop-by-
hop by each router. Once the request reaches the egress router, a return message is
generated. This message confirms the LSP and tells each router the label mapping to use on
each link for that LSP.
In unsolicited mode, the egress routers broadcast label mappings for each external link to all of
their neighbours. These broadcasts are fanned across every link through the network until they
reach the ingress routers. Across each hop, they inform the upstream router of the label
mapping to use for each external link, and by flooding the network they establish LSPs between
all of the external links.
Back to Contents
VPNs, in general, virtual private network extends a private network across a public network and
enables users to send and receive data across shared or public networks as if their computing
devices were directly connected to the private network. Instead of dedicated connections
between networks, VPNs use virtual connections routed (tunnelled) through public networks
that are typically service provider networks. VPNs are a cost-effective alternative to expensive
dedicated lines. Transportation of data between these ends is achieved by encapsulating an
entire data packet into a datagram, thereby allowing a safe exchange of data across public or
shared networks.
IP-based VPNs use Virtual Routing and Forwarding instance (VRF)-Lite to simplify Layer 3
network virtualization and allows customers to easily provide traffic separation and path isolation
on a shared network infrastructure, removing the need to deploy MPLS in the enterprise
network.
MPLS VPN is a family of methods for using multiprotocol label switching to create virtual private
networks. MPLS VPN is a flexible method to transport and route several types of network traffic
using an MPLS backbone.
There are three primary types of MPLS VPNs: Layer 2 VPNs, Layer 2 circuits, and Layer 3
VPNs.
L2VPN: Layer 2 VPNs virtualize the datalink layer (Layer 2) so as to make geographically
remote sites look as if they were operating in the same LAN network.
Virtual Private LAN Service (VPLS): A layer 2 network with VLAN support between multiple
sites.
L3 VPN: The customer peers with the service provider and the two exchange routes which are
stored in a separate routing table.
The basic VPN service is a pseudo wire, which as its name implies, can be used to simulate any
type of wired service. A pseudo wire can carry almost any kind of traffic, Layer 2 packets (for
example Ethernet), L3 packets, ATM cells, Frame Relay, TDM circuits etc. Given this flexibility,
pseudo wires are widely used in Carrier Ethernet and Mobile Backhaul.
MPLS does not provide encryption but it is a virtual private network which is why it is considered
secure. And it is also possible to encrypt your traffic. For example, with IPsec.
MPLS VPNs traffic flows from one customer site to another customer site or one customer site
to Internet, using a MPLS core network as a transit network
The core consists of PE and P routers. Customer routers (CEs) connect to the PEs. One PE
can hold several CEs of different VPNs or the same VPN. PE routers support VPN and MPLS
label functionality. In MPLS VPN networks, the control plane is defined by various routing
instances. The CE announces the IPv4 or IPv6 routes from its site to the PE, and the PE
announces to the CE the routes from other sites of the VPN. This can be done through static or
dynamic routing. In principle, any routing protocol is suitable for this link (BGP or OSPF, for
example).
The ingress PE distributes the site's routes received from the CE and stored in the VRF to all
other PEs that connect sites of this VPN. The routing protocol used for this is Multi-Protocol
Border Gateway Protocol (MP-BGP). Provider routers within the core of the provider's network
are not connected to any routers at a customer site but are part of the tunnel between pairs of
PE routers. Provider routers support LSP functionality as part of the tunnel support, but do not
support VPN functionality.
To keep the control information of various VPNs separate, the PE must distinguish various
VPNs. This is done by prepending a so-called route distinguisher (RD) to every VPN route
received from the CE. This effectively creates a new addressing scheme: instead of using
normal IP addresses, the MPLS core uses VPN-v4 or VPN-v6 addresses, which consist of the
route distinguisher plus the IP address of the VPN. So between PEs, MP-BGP exchanges VPN-
v4 or VPN-v6 routes.
On a PE, the VPN-specific routing exchange is controlled by route targets (RTs). RTs define
which routes on the MPLS core are imported to and exported from which VRF.
The CE does not have to know that it is connected to a VPN service. From the CE's
perspective, the PE is just a core router. It does not have visibility of any other VPN, nor of the
MPLS core. All VPN functions are performed by the PE routers. Neither CE routers nor provider
routers are required to perform any VPN functions.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given
site can be a member of multiple VPNs. However, a site can associate with only one VRF. A
customer-site VRF contains all the routes available to the site from the VPNs of which it is a
member.
Multiprotocol BGP (MP-BGP) peering of VPN community provider edge (PE) devices-MP-BGP
propagates virtual routing and forwarding (VRF) reachability information to all members of a
VPN community. MP-BGP peering must be configured on all PE devices within a VPN
community.
MPLS can be used to efficiently exchange routes using the Border Gateway Protocol. BGP can
be deployed at the edge of a network with an MPLS core. MPLS provides end to end transport
for BGP routes. The PEs in the provider network using MPLS BGP use the Multiprotocol-Border
Gateway Protocol (MP-BGP) to dynamically communicate with each other. This MPLS BGP
model enhances the efficiency and scalability of routing/forwarding features of the underlying
network infrastructure.
MP-BGP supports IPv4 unicast/multicast, IPv6 unicast/multicast and it has support for VPNv4
routes. To exchange VPNv4 routes, MP-BGP uses a new NLRI (Network Layer Reachability
Information) format that has the attributes: RD (Route Distinguisher), IPv4 prefix, Next Hop,
VPN Label (This NRLI also has an attribute called the VPN label)
As its name implies, a route distinguisher (RD) distinguishes one set of routes (one VRF) from
another. It is a unique number prepended to each route within a VRF to identify it as belonging
to that particular VRF or customer. The RD helps BGP understand that network X from one VRF
is not the same as the network X from another VRF.
MPLS L3VPN functionality allows multiple customers who are very likely using overlapping IP
addresses. If customer A is sending 10.0.0.0/8 and customer B is sending 10.0.0.0/8, MPLS
allows distinct VPNs to use the same address space. This is achieved by adding a 64-bit route
distinguisher (RD) to each IPv4 route, making VPN-unique addresses also unique in the MPLS
core. This "extended" address is also called a VPN-IPv4 address. Thus, customers of an MPLS
service do not need to change current addressing in their networks. The basic requirement is to
avoid that packet destined to a host a.b.c.d within a given VPN reach a host with the same
address in another VPN or the core. MPLS-based VPNs employ BGP to communicate between
PEs to facilitate customer routes. This is made possible through extensions to BGP that carry
addresses other than IPv4 addresses. It is required to make the same-looking networks unique
within BGP update.
Across the MPLS core to the other PE routers, this routing separation is maintained by adding
unique VPN identifiers by prefacing our 32-bit (4 byte) IPv4 prefix with a 64-bit RD (8 byte) we
create a 96-bit (12 byte) VPNv4 prefix. RD can come in three different forms. The most common
type is type 0 but it’s really a matter of whatever format you decide to use so long as you’re
consistent across all routers that will carry the VPNv4 prefixes.
VPN routes are exclusively exchanged by MP-BGP across the core, and this BGP information is
not redistributed to the core network, but only to the other PE routers, where the information is
kept again in VPN-specific VRFs. Thus, routing across an MPLS network is separate per VPN.
Both RT and RD have the same format but that is their only similarity. RD must be present
exactly once in each VRF on a single PE and needs to be unique. RT must be present at least
once in each VRF and does not need to be unique (if VRF route leaking is desired). RD
becomes a part of the network address within BGP updates, RTs are carried as attributes of
these networks. RDs are never used to sort routes among VRFs - that is the purpose of RTs.
That is also the reason why the RD may or may not be the same in two corresponding VRFs on
two different PEs - it actually does not matter.
The VPN routing and forwarding table (VRF) is a key element in the MPLS VPN technology.
VRFs exist on PEs only. Every PE router maintains a separate Virtual Routing and Forwarding
instance (VRF) for each connected VPN. Each VRF on the PE router is populated with routes
from one VPN, through statically configured routes or through routing protocols that run
between the PE and the CE router. Since every VPN result in a separate VRF, there are no
interferences between the VPNs on the PE router.
VRF is a technology which allows having more than one routing table on a single router. The
concept of VRFs on routers (WANs) is similar to VLANs on switches (LANs). VRFs are the
TCP/IP layer 3 equivalent of a VLAN. VRFs are typically used in combination with MPLS VPNs.
VRF lite is considered a way of using VRF's to segment networks without MPLS.
Because the routing instances are independent, the same or overlapping IP addresses can be
used without conflicting with each other. Network functionality is improved because network
paths can be segmented without requiring multiple routers.
The basic MPLS service is a pseudo wire, which as its name implies, can be used to simulate
any type of wired service. A pseudo wire can carry almost any kind of traffic, Layer 2 packets
(for example Ethernet), ATM cells, Frame Relay, TDM circuits etc. Given this flexibility, pseudo
wires are widely used in Carrier Ethernet and Mobile Backhaul.
MPLS L3VPN functionality allows multiple customers who are very likely using overlapping IP
addresses. If customer A is sending 10.0.0.0/8 and customer B is sending 10.0.0.0/8, MPLS
allows distinct VPNs to use the same address space.
Back to Contents
MPLS-Traffic Engineering
3.1 INTRODUCTION
Networks exist to deliver data packets between different endpoints. In a traditional IP-based
network, data packets are forwarded on a per-hop basis. Each router between the source and
destination performs a look-up of the packet’s destination IP address in the routing table and
selects the lowest cost path to forward the packets.
This method has a disadvantage: If one path is found to be optimal due to its low cost, every
router in the network will prefer to use that path to forward packets even when there are several
other routes available. This is because Interior Gateway Protocols (IGPs) are designed to
choose least-cost paths to forward packets. But when numerous forwarding routers prefer the
same path, it can lead to over-utilization of the links along this path, resulting in congestion and
packet drops. The preference for the shortest path holds true even when other under-utilized or
idle paths are available. Thus, the per-hop routing approach to data transmission can affect
data delivery and overall network performance in some networks.
With Traffic Engineering (TE), rather than per-hop routing decisions, the network operator’s
headend ingress router controls the path taken by traffic between a source and destination.
Instead of sending traffic through a least-cost but congested path, TE directs designated traffic
through under-utilized or idle paths, thereby distributing the bandwidth load in the network. TE
tunnels also provide a mechanism for creating paths with certain Quality of Service (QoS)
characteristics.
PE 1 Central Router PE 2
R3
Customer Site A R5 Customer Site B
R4
For TE to work, the headend router that creates the TE tunnels must be aware of the latest
network topology, traffic patterns, and the availability of resources, such as bandwidth on links.
This information is collected with the help of IGPs, such as Open Shortest Path First (OSPF)
and Intermediate System to Intermediate System (IS-IS). In addition to traffic bandwidth
requirements, TE tunnels may also factor Class of Service (CoS) requirements of the data to be
forwarded.
They then update this information to all the other routers within the IGP domain.
IRISET 16 TA6 – MPLS
MPLS-TE
This data helps the headend ingress router in the provider network to compute multiple, distinct
paths between the same source and destination edge routers to be used by the TE tunnels.
Once the TE tunnels are created, packets are assigned MPLS labels and forwarded across the
network based on the labels. Thus, this method of packet forwarding is referred to as MPLS
Traffic Engineering.
The major advantages of MPLS Traffic Engineering are congestion avoidance and efficient use
of existing network resources that can be idle or under-utilized. By driving traffic from over-
utilized links to under-utilized ones, TE avoids network congestion caused by too much traffic on
the least-cost link. This helps prevent packet drops and ensures data delivery.
Another advantage is the efficient use of resources, especially network bandwidth. With better
utilization of available bandwidth, operators can save money and increase revenue. They can
avoid spending CAPEX on additional links with higher bandwidth to meet new traffic demands.
The optimization of existing network resources also allows the network service provider to
provide more services to customers, thus bringing in higher revenue.
In addition to cost savings and helping with congestion avoidance, TE also helps with failover.
When a primary path or tunnel between two endpoints in the network fails, TE drives traffic
through idle links, thus providing Fast Reroute (FRR)on the TE tunnels. Finally, TE helps enable
Constraint Based Routing (CBR), where the best possible path for traffic from a source to
destination can be computed based on the resource availability and the demands of the traffic.
Now that we have covered what Traffic Engineering is and the basics of how it works, let us look
at the different TE mechanisms. The most widely used mechanism is RSVP-TE, which we
referred to in the Evolution of Traffic Engineering section. The other is Segment Routing (SR),
an emerging technology that is beginning to be adopted in many service provider networks.
Resource Reservation Protocol (RSVP) is a protocol that is used to reserve resources along the
end-to-end path of a traffic flow in an IP network. RSVP messages are sent by the headend
router in a network to identify resource availability. An RSVP request consists of a Flow Spec
that specifies the Quality of Service (QoS) requirement for the traffic flow and a Filter Spec that
defines which flow must receive the QoS priority. Once the necessary bandwidth is reserved
along the path with RSVP, the application that made the request begins to transmit the traffic.
RSVP is primarily used by real-time and multimedia applications to set up bandwidth
reservations.
RSVP thus communicates the requirements of specific traffic flows to the network. The RSVP
signalling protocol was extended with MPLS features to support MPLS TE. This enabled RSVP
to set up Label Switched Paths (LSP) in an MPLS TE network.
RSVP PATH message: This message is used to check the availability of resources along the
TE path and acts as a reservation request. The ingress Label Switched Router (LSR)—which is
the headend router generates a PATH message. It traverses downstream to the tail end router
through the future path of the TE tunnel and checks for the availability of the resources.
RSVP RESERVATION message: When the tail end router in the domain receives the PATH
message, it generates an RSVP RESERVATION message to confirm the availability of
resources requested.
RSVP Error messages: If a resource requested by the PATH message is not available, then
the router that is unable to reserve the resource generates an RSVP Error message and sends
it to the router from which it received the request or reply. There are two types of error
messages.
PATH ERROR message: This error is triggered when a router receives a PATH message
generated by the headend router but is unable to find the resources requested of it. PATH
ERROR messages are sent to the upstream router from which the PATH message was
received.
RESERVATION ERROR (RESVERR) message: This error is generated if a router fails to
find resources after an RSVP PATH message has reached the tail end router but before the
RSVP RESERVATION message from the tail end router reaches it. RESERVATION ERROR
messages are sent to the downstream router.
RSVP Tear messages—This message is used to tear down a reservation and release the
resources so other TE tunnels can use them.
QoS represents the set of techniques necessary to manage network bandwidth, delay, jitter,
and packet loss. From a business perspective, it is essential to assure that the critical
applications are guaranteed the network resources they need, despite varying network traffic
load.
MPLS CoS functionality enables network administrators to provide differentiated services across
an MPLS network. Network administrators can satisfy a wide range of networking requirements
by specifying the class of service applicable to each transmitted IP packet. Different classes of
service can be established for IP packets by setting the IP precedence bit in the header of each
packet.
MPLS CoS enables you to duplicate Cisco IOS XE IP CoS (Layer 3) features as closely as
possible in MPLS devices, including label edge switch routers (edge LSRs) and label switch
routers (LSRs). MPLS CoS functions map nearly one-for-one to IP CoS functions on all types of
interfaces.
LSRs used at the edge of an MPLS network backbone are routers running MPLS software. The
edge LSRs can be at the ingress or the egress of the network.
In either case, LSRs enforce the defined differentiation by continuing to employ WRED or
CBWFQ on every ingress router.
LSRs used at the core of an MPLS network are routers running MPLS software. These routers
at the core of an MPLS network process packets as follows:
1. MPLS labelled packets coming from the edge routers or other core routers enter the core
router.
2. A lookup is done at the core router to determine the next hop LSR.
3. An appropriate label is placed (swapped) on the packet and the MPLS EXP bits are copied.
4. The labelled packet is then forwarded to the output interface for processing.
5. The packets are differentiated by the MPLS EXP field marking and treated appropriately,
depending on the WRED and CBWFQ configuration.
3.5 Benefits of MPLS CoS in IP Backbone network
You realize the following benefits when you use MPLS CoS in a backbone consisting of IP
routers running MPLS:
• Future service enhancements—MPLS CoS provides building blocks for future service
enhancements (such as virtual leased lines) by meeting bandwidth requirements.
Back to Contents
Back to Contents
CHAPTER-4
ROUTING PROTOCOLS
4.1 INTRODUCTION
Routing Protocols are the set of defined rules used by the routers to communicate between
source & destination. They do not move the information to the source to a destination, but only
update the routing table that contains the information.
Network Router protocols helps you to specify way routers communicate with each other. It
allows the network to select routes between any two nodes on a computer network.
Static
Dynamic
RIPv1 IGRP
Static routing protocols are used when an administrator manually assigns the path from source
to the destination network. It offers more security to the network. Used in smaller networks that
are not expected to grow significantly used to represent a path to any network that does not
have a more specific match with another route in the routing table.
Advantages
Minimal CPU Processing.
Only the administrator is able to add routes.
Easy to configure
Bandwidth Consumption is less.
IRISET 22 TA6 – MPLS
Routing Protocols
Disadvantages
The administrator requires complete knowledge of the entire network for proper
implementation.
Configuration and maintenance are time-consuming.
Not an ideal option for large networks as it is time intensive.
Does not scale well with growing networks; maintenance becomes cumbersome.
Configuration is error-prone, especially in large networks.
Dynamic routing protocols are another important routing protocol, typically used in larger
networks to ease the administrative and operational overhead of using only static routes. It
helps routers to add information to their routing tables from connected routers automatically.
These types of protocols also send out topology updates whenever the network changes’
topological structure.
Dynamic routing protocols have evolved over several years to meet the demands of changing
network requirements. Although many organizations have migrated to more recent routing
protocols such as Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest
Path First (OSPF), many of the earlier routing protocols, such as Routing Information Protocol
(RIP), are still in use today.
Dynamic routing protocols have been used in networks since the early 1980s. The first version
of RIP was released in 1982, but some of the basic algorithms within the protocol were used on
the ARPANET as early as 1969. As networks have evolved and become more complex, new
routing protocols have emerged.
Figure 4.2 shows a timeline of IP routing protocols, with a chart that helps classify the various
protocols.
IRISET 23 TA6 – MPLS
Routing Protocols
One of the earliest routing protocols was RIP. RIP has evolved into a newer version: RIPv2.
However, the newer version of RIP still does not scale to larger network implementations. To
address the needs of larger networks, two advanced routing protocols were developed: OSPF
and Intermediate System–to–Intermediate System (IS-IS). Cisco developed Interior Gateway
Routing Protocol (IGRP) and Enhanced IGRP (EIGRP). EIGRP also scales well in larger
network implementations.
Additionally, there was the need to interconnect different internetworks and provide routing
among them. Border Gateway Protocol (BGP) is now used between Internet service providers
(ISP) as well as between ISPs and their larger private clients to exchange routing information.
With the advent of numerous consumer devices using IP, the IPv4 addressing space is nearly
exhausted.
Thus, IPv6 has emerged. To support the communication based on IPv6, newer versions of the
IP routing protocols have been developed.
What exactly are dynamic routing protocols? Routing protocols are used to facilitate the
exchange of routing information between routers. Routing protocols allow routers to dynamically
learn information about remote networks and automatically add this information to their own
routing tables, as shown in Figure 4.3.
Routing protocols determine the best path to each network, which is then added to the routing
table. One of the primary benefits of using a dynamic routing protocol is that routers exchange
routing information whenever there is a topology change. This exchange allows routers to
automatically learn about new networks and also to find alternate paths if there is a link failure
to a current network.
Compared to static routing, dynamic routing protocols require less administrative overhead.
However, the expense of using dynamic routing protocols is dedicating part of a router’s
resources for protocol operation, including CPU time and network link bandwidth. Despite the
benefits of dynamic routing, static routing still has its place. There are times when static routing
is more appropriate and other times when dynamic routing is the better choice.
A routing protocol is a set of processes, algorithms, and messages that are used to exchange
routing information and populate the routing table with the routing protocol’s choice of best paths.
Data structures: Some routing protocols use tables or databases for their operations. This
information is kept in RAM.
Routing protocol messages: Routing protocols use various types of messages to discover
neighbouring routers, exchange routing information, and do other tasks to learn and maintain
accurate information about the network.
Interior gateway protocols (IGP): Used for intra-autonomous system routing, that is,
routing inside an autonomous system
Exterior gateway protocols (EGP): Used for inter-autonomous system routing, that is,
routing between autonomous systems.
Exterior Gateway
Protocol:
BGP
Autonomous Autonomous
System 100 System 200
Interior Gateway
Protocols:
RIP
IGRP
EIGRP
OSPF
IS-IS
IGPs are used for routing within a routing domain, those networks within the control of a single
organization. An autonomous system is commonly composed of many individual networks
belonging to companies, schools, and other institutions. An IGP is used to route within the
autonomous system and also used to route within the individual networks themselves. For
example, Indian Railways operates an autonomous system composed of various Zonal
Railways, Production Units, and Training Centre. Hence Indian railways use an IGP to route
within its autonomous system to interconnect all of these regions and Institutions. Each of the
regions and Institutions uses an IGP of its own choosing to route within its own individual
network. The IGP used by each entity provides best path determination within its own routing
domains, just as the IGP used in Indian railways to provide best-path routes within the
autonomous system itself. IGPs for IP include RIP, IGRP, EIGRP, OSPF, and IS-IS.
EGPs, on the other hand, are designed for use between different autonomous systems that are
under the control of different administrations. BGP is the only currently viable EGP and is the
routing protocol used by the Internet. BGP is a path vector protocol that can use many different
attributes to measure routes. At the ISP level, there are often more important issues than just
choosing the fastest path. BGP is typically used between ISPs and sometimes between a
company and an ISP.
Metric
A metric is the quantitative value used to measure the distance to a given route. Metrics are a
way to measure or compare the best path to a network with the lowest metric. Routing protocols
use metrics to determine which route is the best path. Dynamic routing protocols typically use
their own rules and metrics to build and update routing tables.
Purpose of a Metric
There are cases when a routing protocol learns of more than one route to the same destination.
To select the best path, the routing protocol must be able to evaluate and differentiate among
the available paths. For this purpose, a metric is used. A metric is a value used by routing
protocols to assign costs to reach remote networks. The metric is used to determine which path
is most preferable when there are multiple paths to the same remote network.
The primary objective of the routing protocol is to determine the best paths for each route to
include in the routing table. The routing algorithm generates a value, a metric for each path
through the network. Metrics can be based on either a single characteristic or several
characteristics of a path. Some routing protocols can base route selection on multiple metrics,
combining them into a single metric. The smaller the value of the metric, the better the path.
Metric Parameters
Hop count: A simple metric that counts the number of routers a packet must traverse.
Bandwidth: Influences path selection by preferring the path with the highest bandwidth.
Reliability: Assesses the probability of a link failure, calculated from the interface error count
or previous link failures.
Cost: A value determined either by the IOS or by the network administrator to indicate
preference for a route. Cost can represent a metric, a combination of metrics, or a policy.
RIP: Hop count: Best path is chosen by the route with the lowest hop count.
IGRP and EIGRP: Bandwidth, delay, reliability, and load: Best path is chosen by the
route with the smallest composite metric value calculated from these multiple parameters. By
default, only bandwidth and delay are used.
IS-IS and OSPF: Cost: Best path is chosen by the route with the lowest cost. The Cisco
implementation of OSPF uses bandwidth to determine the cost.
Load Balancing
Individual routing protocols use metrics to determine the best route to reach remote networks.
Suppose two or more routes to the same destination have identical metric values than how the
router decides which path to use for packet forwarding? In this case, the router does not choose
only one route. Instead, the router load balances between these equal-cost paths. The packets
are forwarded using all equal-cost paths. This process is called load balancing. Load balancing
can be done either per packet or per destination.
This is a number of arbitrary unit assigned to dynamic routes, static routes and directly-
connected routes. The value is used in routers to rank routes from most preferred (low AD
value) to least preferred (high AD value). Administrative distance is an integer value from 0 to
255. An administrative distance of 0 is the most preferred. Only a directly connected network
has an administrative distance of 0, which cannot be changed. An administrative distance of
255 means the routing information source cannot be trusted at all and should be ignored.
When multiple paths to the same destination are available in its routing table, the router uses
the route with the lowest administrative distance.
Administrative distance (AD) defines the preference of a routing source. Each routing source
including specific routing protocols, static routes, and even directly connected networks is
prioritized in order of most to least preferable using an administrative distance value. Cisco
routers use the AD feature to select the best path when they learn about the same destination
network from two or more different routing sources.
Cisco Routers
Juniper routers
Distance vector means that routes are advertised as vectors of distance and direction. Distance
is defined in terms of a metric such as hop count, and direction is simply the next hop router or
exit interface. Distance vector protocols typically use the Bellman-Ford algorithm for the best-
path route determination.
A router using a distance vector routing protocol does not have the knowledge of the entire path
to a destination network. Instead, the router knows only
Distance vector protocols periodically send complete routing tables to all connected neighbours.
In large networks, these routing updates can become enormous, causing significant traffic on
the links.
Distance vector protocols use routers as signposts along the path to the final destination. The
only information a router knows about a remote network is the distance or metric to reach that
network and which path or interface to use to get there. Distance vector routing protocols do not
have an actual map of the network topology.
The network is simple and flat and does not require a hierarchical design.
The administrators do not have enough knowledge to configure and troubleshoot link state
protocols.
RIP is a standardized Distance Vector protocol, designed for use on smaller networks. RIP was
originally specified in RFC 1058. It has the following key characteristics:
RIP uses a form of distance as its metric (in this case, hop count)
RIP sends out the full routing table every periodic update
RIP uses the Bellman-Ford Distance Vector algorithm to determine the best ―path‖ to a
particular destination
RIP has a maximum hop count of 15 hops, If the hop count for a network is greater than 15,
RIP cannot supply a route to that network.
If multiple paths exist to a particular destination, RIP will load balance between those paths
(by default, up to 4) only if the metric (hop count) is equal, maximum up to 16 paths.
RIP uses a round-robin system of load-balancing between equal metric routes, which can
lead to pinhole congestion. Ex: - Two paths might exist to a particular destination, one going
through a E1 baud link, the other via a T1. If the metric (hop count) is equal, RIP will load-
balance, sending an equal amount of traffic down the E1 baud link and the T1. This will
(obviously) cause the slower link to become congested.
RIP Versions
RIPv1 (RFC 1058) is classful, and thus does not include the subnet mask with its routing table
updates. Because of this, RIPv1 does not support Variable Length Subnet Masks (VLSMs). When
using RIPv1, networks must be contiguous, and subnets of a major network must be configured
with identical subnet masks. Otherwise, route table inconsistencies (or worse) will occur.
RIPv2 (RFC 2543) is classless, and thus does include the subnet mask with its routing table
updates. RIPv2 fully supports VLSMs, allowing discontinuous networks and varying subnet
masks to exist. Other enhancements offered by RIPv2 include:
Routing updates are sent via multicast, using address 224.0.0.9
Encrypted authentication can be configured between RIPv2 routers
Route tagging is supported (explained in a later section)
IRISET 31 TA6 – MPLS
Routing Protocols
We can control the version of RIP a particular interface will ―send‖ or ―receive.‖ Unless RIPv2 is
manually specified, a Cisco will default to RIPv1 when configuring RIP.
RIPng
RIPng (RIP next generation), defined in (RFC 2080) is an extension of RIPv2 for support of IPv6,
the next generation Internet Protocol. The main differences between RIPv2 and RIPng are:
Support of IPv6 networking.
While RIPv2 supports RIPv1 updates authentication, RIPng does not.
IPv6 routers were, at the time, supposed to use IPsec for authentication.
RIPv2 encodes the next-hop into each route entry,
RIPng requires specific encoding of the next hop for a set of route entries.
RIPng sends updates on UDP port 521
It uses multicast group ff02::9.
RIP Timers
RIP has four basic timers:
Update Timer (default 30 seconds) – indicates how often the router will send out a routing
table update.
Invalid Timer (default 180 seconds, i.e., 30 + 150sec) – indicates how long a route will remain
in a routing table before being marked as invalid, if no new updates are heard about this route.
The invalid timer will be reset if an update is received for that particular route before the timer
expires.
A route marked as invalid is not immediately removed from the routing table. Instead, the route
is marked (and advertised) with a metric of 16, indicating it is unreachable, and placed in a hold-
down state.
Hold-down Timer (default 180 seconds) – indicates how long RIP will ―suppress‖ a route that it
has placed in a hold-down state. RIP will not accept any new updates for routes in a hold-down
state, until the hold-down timer expires.
Flush Timer (default 240 seconds) – indicates how long a route can remain in a routing table
before being flushed, if no new updates are heard about this route. The flush timer runs
concurrently with the invalid timer, and thus will flush out a route 60 seconds after it has been
marked invalid.
RIP timers must be identical on all routers on the RIP network, otherwise massive instability will
occur.
IGRP sends out the full routing table every periodic update.
IGRP uses a form of distance as its metric (in this case, a composite of bandwidth and delay).
GRP uses the Bellman-Ford or Ford-Fulkerson Distance Vector algorithm to determine the
best ―path‖ to a particular destination.
IGRP, by default, supports a maximum of 100 hops. This value can be adjusted to a
maximum of 255 hops.
IGRP uses Bandwidth and Delay of the Line, by default, to calculate its distance metric.
Reliability, Load, and MTU are optional attributes that can be used to calculate the distance
metric.
IGRP requires that you include an Autonomous System (AS) number in its configuration. Only
routers in the same Autonomous system will send updates between each other.
IGRP Timers
Update Timer (default 90 seconds): indicates how often the router will send out a routing table
update.
Invalid Timer (default 270 seconds): indicates how long a route will remain in a routing table
before being marked as invalid, if no new updates are heard about this route. The invalid timer
will be reset if an update is received for that particular route before the timer expires.
A route marked as invalid is not immediately removed from the routing table. Instead, the route
is marked (and advertised) with a metric of 101 (remember, 100 maximum hops is default),
indicating it is unreachable, and placed in a hold-down state.
Hold-down Timer (default 280 seconds): indicates how long IGRP will ―suppress‖ a route that
it has placed in a hold-down state. IGRP will not accept any new updates for routes in a hold-
down state, until the hold-down timer expires.
An update has been received from another router, marking that route with a metric of 101
(unreachable).
An update has been received from another router, marking that route with a higher metric
than what is currently in the routing table (this is to prevent loops).
Flush Timer (default 630 seconds) – indicates how long a route can remain in a routing table
before being flushed, if no new updates are heard about this route. The flush timer runs
concurrently with the invalid timer, and thus will flush out a route 360 seconds after it has been
marked invalid.
IGRP timers must be identical on all routers on the IGRP network, otherwise massive instability
will occur.
EIGRP will form neighbor relationships with adjacent routers in the same Autonomous System
(AS).
Reliable Transport Protocol (RTP) is used to ensure delivery of most EIGRP packets.
EIGRP routers do not send periodic, full-table routing updates. Updates are sent when a
change occurs, and include only the change.
EIGRP applies an Administrative Distance of 90 for routes originating within the local
Autonomous System.
EIGRP applies an Administrative Distance of 170 for external routes coming from outside the
local Autonomous System
EIGRP uses Bandwidth and Delay of the Line, by default, to calculate its distance metric. It
also supports three other parameters to calculate its metric: Reliability, Load, and MTU.
EIGRP has a maximum hop-count of 224, though the default maximum hop-count is set to
100.
EIGRP might act like a link-state routing protocol, but it is still a distance vector routing
protocol.
EIGRP TABLES
o Contains entries for all destination, along with the feasible distance and the advertised
distance.
Routing table: contains the best route for each known network.
Hello packets are used to form neighbor relationships, Hello packets are always multicast to
address 224.0.0.10. it main functions are neighbor discovery, neighbor Formation and to
keep Alive
Update packets are sent between neighbors to build the topology and routing tables.
Updates sent to new neighbors are sent as unicast. However, if a route’s metric is changed,
the update is sent out as a multicast to address 224.0.0.10.
Query packets are sent by a router when a Successor route fails, and there are no Feasible
Successors in the topology table. The router places the route in an Active state, and queries
its neighbors for an alternative route. Query packets are sent as a multicast to address
224.0.0.10.
Reply packets are sent in response to Query packets, assuming the responding router has
an alternative route (feasible successor). Reply packets are sent as a unicast to the querying
router. Recall that EIGRP utilizes the Reliable Transport Protocol (RTP) to ensure reliable
delivery of most EIGRP packets. Delivery is guaranteed by having packets acknowledged
using Acknowledgment packets.
Acknowledgment packets (also known as ACK’s) are simply Hello packets with no data,
other than an acknowledgment number. ACK’s are always sent as unicast.
The following packet types employ RTP to ensure reliable delivery via ACK’s:
Update Packets
Query Packets
Reply Packets
Hello and Acknowledgments (ha!) packets do not utilize RTP, and thus do not require
acknowledgement.
EIGRP Metrics
EIGRP can utilize 5 separate metrics to determine the best route to a destination:
By default, only Bandwidth and Delay of the Line are used. This is identical to IGRP, except that
EIGRP provides a more granular metric by multiplying the bandwidth and delay by 256.
Bandwidth and delay are determined by the interfaces that lead towards the destination
network.
By default, the full formula for determining the EIGRP metric is:
The bandwidth value represents the link with the lowest bandwidth in the path, in kilobits.
The delay is the sum of all delays of the links along interfaces in the path.
As indicated above, each metric is symbolized with a ―K‖ and then a number. When configuring
EIGRP metrics, we actually identify which metrics we want EIGRP to consider.
Again, by default, only Bandwidth and Delay are considered. Thus, using on/off logic: K1 = 1,
K2 = 0, K3 = 1, K4 = 0, K5 = 0 If all metrics were set to ―on,‖ the full formula for determining the
EIGRP metric would be:
Remember, the ―K‖ value is either set to on (―1‖) or off (―0‖). Substituting the K values the
formula is synthesize to
An EIGRP route can exist in one of two states, in the topology table:
Active state
Passive State
A Passive state indicates that a route is reachable, and that EIGRP is fully converged. A stable
EIGRP network will have all routes in a Passive state.
A route is placed in an Active state when the Successor and any Feasible Successors fail,
forcing the EIGRP to send out Query packets and reconverge. Multiple routes in an Active state
indicate an unstable EIGRP network. If a Feasible Successor exists, a route should never enter
an Active state.
Routes will become Stuck-in-Active (SIA) when a router sends out a Query packet, but does not
receive a Reply packet within three minutes. In other words, a route will become SIA if EIGRP
fails to re-converge. The local router will clear the neighbour adjacency with any router(s) that
has failed to Reply, and will place all routes from that neighbour(s) in an Active state.
Components of EIGRP
Consider the follow example to determine the various components of EIGRP
Router A to Router B is 8
Router B to Router E is 2
Router E to Router H is 6
Router A to Router C is 4
Router C to Router F is 14
Router F to Router H is 9
Router A to Router D is 2
Router D to Router G is 5
Router D to Router H is 4
Router A has three separate paths to the Destination Network, either through Router B, C, or D.
If we add up the metrics to form a ―distance‖ (the metrics are greatly simplified in this example),
we can determine the following:
Router A calculates the total distance to the Destination network by adding the AD of the
advertising router, with its own distance to reach that advertising router.
For example, Router A’s metric to Router B is 8 and advertised distance is 8 thus, the total
distance will be 16 to reach the Destination Network through Router B.
Router A’s metric to Router C is 4 and advertised distance is 23 thus, the total distance will be
27 to reach the Destination Network through Router C.
Router A’s metric to Router D is 2 and advertised distance is 9 thus, the total distance will be 11
to reach the Destination Network through Router D.
Thus, the route through Router D (metric of 11) would become the Feasible Distance for Router
A, and is added to the routing table as the best route. This route is identified as the Successor.
To allow convergence to occur quickly if a link fails, EIGRP includes backup routes in the
topology table called Feasible Successors (FS). A route will only become a Successor if its
Advertised Distance is less than the current Feasible Distance. This is known as a Feasible
Condition (FC).
For example, we determined that Router A’s feasible Distance to the destination is 11, through
Router D.
Router C’s Advertised Distance is 23, and thus would not become a Feasible Successor, as it
has a higher metric than Router A’s current Feasible Distance. Routes that are not Feasible
Successors become route Possibilities.
Router B’s Advertised Distance is 8, which is less than Router A’s current Feasible Distance.
Thus, the route through Router B to the Destination Network would become a Feasible
Successor. Feasible Successors provide EIGRP with redundancy, without forcing routers to re-
converge (thus stopping the flow of traffic) when a topology change occurs. If no Feasible
Successor exists and a link fails, a route will enter an Active (converging) state until an alternate
route is found.
EIGRP Load-Balancing
EIGRP will automatically load-balance across equal-metric routes (four by default, six
maximum).
EIGRP also supports load-balancing across routes with an unequal metric. Variance should be
configured for Unequal cost Load balancing
EIGRP will not load-balance between these two routes, as their metrics are different (11 through
Router D, 16 through Router B). We must use the variance command to tell EIGRP to load-
balance across these unequal-metric links:
RouterA(config-router) # variance 2
RouterA(config-router) # maximum-paths 6
The variance command assigns a ―multiplier,‖ in this instance of 2. We multiply this variance
value by the metric of our Feasible Distance (2 x 11 = 22).
Thus, any Feasible Successors with a metric within twice that of our Feasible Distance (i.e., 12
through 22) will now be used for load balancing by EIGRP.
Remember, only Feasible Successors can be used for load balancing, not Possibilities (such as
the route through Router C). The maximum-paths command adjusts the number of links EIGRP
can load balance across.
EIGRP v6
Link state routing protocol can create a ―complete view,‖ or topology, of the network by
gathering information from all the other routers. Think of using a link-state routing protocol as
having a complete map of the network topology. The signposts along the way from source to
destination are not necessary, because all link-state routers are using an identical ―map‖ of the
network.
A link-state router uses the link-state information to create a topology map and to select the best
path to all destination networks in the topology. Each router can create its own topological map
of the network and independently calculate the shortest path to every network.
Link-state routing protocols do not use periodic updates. After the network has converged, a
link-state update is only sent when there is a change in the topology. Link-state protocols work
best in situations were
The administrators have a good knowledge of the implemented link-state routing protocol.
Link-state routing protocols are also known as shortest path first protocols and are built around
Dijkstra’s shortest path first (SPF) algorithm.
Open Shortest Path First (OSPF): OSPF was designed by the IETF (Internet Engineering Task
Force) OSPF Working Group, which still exists today. The development of OSPF began in
1987, and there are two current versions in use:
OSPFv1: was published in 1989(RFC 1131), It was an experimental routing protocol that was
never deployed.
OSPFv2: OSPF for IPv4 networks (RFC 1247 and RFC 2328)
Most of the work on OSPF was done by John Moy, author of most of the RFC’s regarding
OSPF. His book, OSPF, Anatomy of an Internet Routing Protocol, provides interesting insight
into the development of OSPF. Rob Coltun, and Dennis Ferguson has contributed for OSPF v3.
OSPF will form neighbor relationships with adjacent routers in the same Area.
Instead of advertising the distance to connected networks, OSPF advertises the status of
directly connected links using Link-State Advertisements (LSAs).
OSPF sends updates (LSAs) when there is a change to one of its links, and will only send
the change in the update. LSAs are additionally refreshed every 30 minutes.
OSPF traffic is multicast either to address 224.0.0.5 (all OSPF routers) or 224.0.0.6 (all
Designated Routers).
OSPF uses the Dijkstra Shortest Path First algorithm to determine the shortest path.
Load balancing via 4 equal cost paths by default (unequal cost load balancing not supported)
OSPF uses cost as its metric, which is computed based on the bandwidth of the link.
Cost= 108/Bandwidth
OSPF has no hop-count limit.
OSPF determines the best (or shortest) path to a destination network using a cost metric, which
is based on the bandwidth of interfaces. The total cost of a route is the sum of all outgoing
interface costs. Lowest cost is preferred. And calculated using the formula
Cost= 108/Bandwidth
TYPE COST
Serial (56K) 1785
Serial (64K) 1562
T1 (1.544Mbps) 64
Token Ring (4Mbps) 25
Ethernet (10 Mbps) 10
Token Ring (16 Mbps) 6
Fast Ethernet 1
OSPF TABLES
A neighbor table:
A topology table:
o contains a list of all possible routes to all known networks within an area.
A routing table:
OSPF Neighbors
OSPF forms neighbour relationships, called adjacencies, with other routers in the same Area by
exchanging Hello packets to multicast address 224.0.0.5. Only after an adjacency is formed can
routers share routing information.
Each OSPF router is identified by a unique Router ID. The Router ID can be determined in one
of three ways:
If not manually specified, the highest IP address configured on any Loopback interface on
the router will become the Router ID.
If no loopback interface exists, the highest IP address configured on any Physical interface
will become the Router ID.
By default, Hello packets are sent out OSPF-enabled interfaces every 10 seconds for broadcast
and point-to-point interfaces, and 30 seconds for non-broadcast and point-to-multipoint
interfaces.
OSPF also has a Dead Interval, which indicates how long a router will wait without hearing any
hellos before announcing a neighbour as ―down.‖ Default for the Dead Interval is 40 seconds for
broadcast and point-to-point interfaces, and 120 seconds for non-broadcast and point-to-
multipoint interfaces. Notice that, by default, the dead interval timer is four times the Hello
interval.
The data portion of an OSPF message is encapsulated in a packet. This data field can include
one of five OSPF packet types.
The OSPF packet header is included with every OSPF packet, regardless of its type. The OSPF
packet header and packet type-specific data are then encapsulated in an IP packet. In the IP
packet header, the protocol field is set to 89 to indicate OSPF, and the destination address is
typically set to one of two multicast addresses: 224.0.0.5 or 224.0.0.6. If the OSPF packet is
encapsulated in an Ethernet frame, the destination MAC address is also a multicast address:
01-00-5E-00-00-05 or 01-00-5E-00-00-06.
OSPF packet Type 1 is the OSPF Hello packet. Hello packets are used to do the following:
Elect the Designated Router and Backup Designated Router on multiaccess networks such
as Ethernet and Frame Relay
List of Neighbors: Lists the OSPF Router ID of the neighboring router (s)
IRISET 44 TA6 – MPLS
Routing Protocols
Non-broadcast Multi-access Network (NBMA): indicates a topology where one interface can
connect to multiple destinations; however, broadcasts cannot be sent across a NBMA network.
To reduce the amount of OSPF traffic on multi access networks, OSPF elects a Designated
Router (DR) and Backup Designated Router (BDR). The DR is responsible for updating all other
OSPF routers (called DR Others) when a change occurs in the multi access network. The BDR
monitors the DR and takes over as DR if the current DR fails.
In the below example, four routers are connected into the same multi-access segment. Using
the following formula (where ―n‖ is the number of routers): n(n-1)/2. It is apparent that 6 separate
adjacencies are needed for a fully meshed network. Increase the number of routers to five, and
10 separate adjacencies would be required. This leads to a considerable amount of
unnecessary Link State Advertisement (LSA) traffic.
If a link off of Router A were to fail, it would flood this information to all neighbours. Each
neighbour, in turn, would then flood that same information to all other neighbours. This is a
waste of bandwidth and processor load.
To prevent this, OSPF will elect a Designated Router (DR) for each multi access networks,
accessed via multicast address 224.0.0.6. For redundancy purposes, a Backup Designated
Router (BDR) is also elected.
OSPF routers will form adjacencies with the DR and BDR. If a change occurs to a link, the
update is forwarded only to the DR, which then forwards it to all other routers. This greatly
reduces the flooding of LSAs.
DR and BDR elections are determined by a router’s OSPF priority, which is configured on a per-
interface basis (a router can have interfaces in multiple multi-access networks). The router with
the highest priority becomes the DR; second highest becomes the BDR. If there is a tie in
priority, whichever router has the highest Router ID will become the DR. To change the priority
on an interface:
Default priority on Cisco routers is 1. A priority of 0 will prevent the router from being elected DR
or BDR.
Note: The DR election process is not preemptive. Thus, if a router with a higher priority is added
to the network, it will not automatically supplant an existing DR. Thus, a router that should never
become the DR should always have its priority set to 0.
Init: Indicates a Hello packet has been heard from the neighbor, but two-way communication
has not yet been initialized.
2-Way: Indicates that bidirectional communication has been established. Recall that Hello
packets contain a neighbor field. Thus, communication is considered 2-Way once a router
sees its own Router ID in its neighbor’s Hello Packet. Designated and Backup Designated
Routers are elected at this stage.
ExStart: Indicates that the routers are preparing to share link state information. Master/slave
relationships are formed between routers to determine who will begin the exchange.
Exchange: Indicates that the routers are exchanging Database Descriptors (DBDs). DBDs
contain a description of the router’s Topology Database. A router will examine a neighbor’s
DBD to determine if it has information to share.
Loading: Indicates the routers are finally exchanging Link State Advertisements, containing
information about all links connected to each router. Essentially, routers are sharing their
topology tables with each other.
Full: Indicates that the routers are fully synchronized. The topology table of all routers in the
area should now be identical. Depending on the ―role‖ of the neighbor, the state may appear
as:
Full/DR: indicating that the neighbor is a Designated Router (DR)
Full/BDR: indicating that the neighbor is a Backup Designated Router (BDR)
Full/DROther: indicating that the neighbor is neither the DR or BDR
On a multi-access network, OSPF routers will only form Full adjacencies with DRs and BDRs.
Non-DRs and non-BDRs will still form adjacencies, but will remain in a 2-Way State. This is
normal OSPF behaviour.
OSPF is a hierarchical system that separates an Autonomous System into individual areas.
OSPF traffic can either be intra-area (within one area), inter-area (between separate areas), or
external (from another AS).
OSPF routers build a Topology Database of all links within their area, and all routers within an
area will have an identical topology database. Routing updates between these routers will only
contain information about links local to their area. Limiting the topology database to include only
the local area conserves bandwidth and reduces CPU loads.
Area 0 is required for OSPF to function, and is considered the ―Backbone‖ area. As a rule, all
other areas must have a connection into Area 0. Area 0 is often referred to as the transit area to
connect all other areas.
OSPF routers can belong to multiple areas, and will thus contain separate Topology databases
for each area. These routers are known as Area Border Routers (ABRs).
Consider the above example. Three areas exist: Area 0, Area 1, and Area 2. Area 0, again, is
the backbone area for this Autonomous System. Both Area 1 and Area 2 must directly connect
to Area 0.
Routers A and B belong fully to Area 1, while Routers E and F belong fully to Area 2. These are
known as Internal Routers.
Router C belongs to both Area 0 and Area 1. Thus, it is an ABR. Because it has an interface in
Area 0, it can also be considered a Backbone Router. The same can be said for Router D, as it
belongs to both Area 0 and Area 2.
Now consider the above example. Router G has been added, which belongs to Area 0. However,
Router G also has a connection to the Internet, which is outside this Autonomous System.
This makes Router G an Autonomous System Border Router (ASBR). A router can become
an ASBR in one of two ways:
ASBRs provide access to external networks. OSPF defines two ―types‖ of external routes:
Type 2 (E2) – Includes only the external cost to the destination network. External cost is the
metric being advertised from outside the OSPF domain. This is the default type assigned to
external routes.
Type 1 (E1) – Includes both the external cost, and the internal cost to reach the ASBR, to
determine the total metric to reach the destination network. Type 1 routes are always
preferred over Type 2 routes to the same destination.
OSPF routers keep track of the status of links within their respective areas. A link is simply a
router interface. From these lists of links and their respective statuses, the topology database is
created. OSPF routers forward link-state advertisements (LSAs) to ensure the topology
database is consistent on each router within an area.
Router LSA (Type 1): Contains a list of all links local to the router, and the status and ―cost‖ of
those links. Type 1 LSAs are generated by all routers in OSPF, and are flooded to all other
routers within the local area.
Network LSA (Type 2): Generated by all Designated Routers in OSPF, and contains a list of all
routers attached to the Designated Router.
Network Summary LSA (Type 3) – Generated by all ABRs in OSPF, and contains a list of all
destination networks within an area. Type 3 LSAs are sent between areas to allow inter-area
communication to occur.
ASBR Summary LSA (Type 4) – Generated by ABRs in OSPF, and contains a route to any
ASBRs in the OSPF system. Type 4 LSAs are sent from an ABR into its local area, so that
Internal routers know how to exit the Autonomous System.
External LSA (Type 5) – Generated by ASBRs in OSPF, and contain routes to destination
networks outside the local Autonomous System. Type 5 LSAs can also take the form of a
default route to all networks outside the local AS. Type 5 LSAs are flooded to all areas in the
OSPF system.
OSPF v3
It is an OSPF for IPv6
It runs directly over IPv6
It uses the same SPF or Dijkstra algorithm
Mechanism for neighbor and adjacency formation are same as OSPF v2
LS flooding and aging mechanism are same
It distributes IPv6 prefixes
It still uses Router ID from IPv4 Address.
It is a standardized link-state protocol that was developed to be the definitive routing protocol for
the OSI (Open Systems Interconnect) Model, which was developed by ISO (International
Standards Organization).
IS-IS shares many similarities to OSPF. Though it was designed as an interior gateway protocol
(IGP), IS-IS is predominantly used by ISPs, due to its scalability.
IS-IS Tables:
A neighbor table: contains a list of all neighboring routers.
A topology table: contains a list of all possible routes to all known networks within an area.
A routing table: contains the best route for each known network. IS-IS is only available on
enterprise versions of the Cisco IOS.
Hello packets are exchanged for neighbour discovery. Three types of IS-IS Hello packets exist:
IIH (IS-IS Hello): exchanged between routers (or IS’s) to form neighbor adjacencies.
ESH (ES Hello): sent from an ES to discover a router.
ISH (IS Hello): sent from an IS to announce its presence to ES’s
An LSP (Link State Packet) is used to share topology information between routers. There are
separate LSPs for Level 1 and Level 2 routing. LSP’s are covered in great detail shortly.
A CSNP (Complete Sequence Number PDU) is an update containing the full link-state
database. IS-IS routers will refresh the full database every 15 minutes.
IRISET 51 TA6 – MPLS
Routing Protocols
IS-IS consists of three sub-protocols that work in tandem to achieve end-to-end routing which
ISO defined as Connectionless Network Service (CLNS):
CLNP (Connectionless Network Protocol): serves as the Layer-3 protocol for IS-IS (and was
developed by ISO).
ES-IS (End System -to- Intermediate System): used to route between hosts and routers.
IS-IS (Intermediate System -to- Intermediate System): used to route between routers.
IS-IS was originally developed to route ISO CLNP addresses (outlined in RFC 1142). However,
CLNP addressing never became prominently used. Thus, IS-IS was modified to additionally
support IP routing, and became Integrated (or Dual) IS-IS (outlined in RFC 1195).
The IS-IS CLNP address is hexadecimal and of variable length, and can range from 64 to 160
bits in length. The CLNP address contains three ―sections,‖ including:
Thus, the CLNP address identifies the ―Area‖ in which a device is located, the actual host ―ID,‖
and the destination application on that host, in the form of the ―SEL‖ field. The CNLP address is
logically segmented even further, as demonstrated by the following table:
Observe the top row of the above figure. The ISO CLNP address provides granular control by
separating internal and external routing information:
The IDP (Initial Domain Part) portion of the address identifies the Autonomous System of
the device (and is used to route to or between Autonomous Systems)
The DSP (Domain Specific Part) portion of the address is used to route within the
autonomous system.
The IDP portion of the address is separated into two ―sections,‖ including:
AFI (Authority and Format Identifier): specifies the organization authorized to assign
addresses, and the format and length of the rest of the CLNP address. The AFI is always 8 bits.
IDI (Initial Domain Identifier): identifies the ―suborganization‖ under the parent AFI
organization. The length of the IDI is dependent on the chosen AFI.
An AFI of 0x49 indicates a private CLNP address, which cannot be routed globally (the
equivalent of an IPv4 private address).
An AFI of 0x47 is commonly used for global IS-IS networks, with the IDI section identifying
specific organizations.
The AFI plus the IDI essentially identify the autonomous system of the address. However, this is
not the equivalent of a BGP AS number, nor is it compatible with BGP as an exterior routing
protocol.
The DSP portion of the address is separated into three ―sections,‖ including:
HO-DSP (High Order DSP): Identifies the area within an autonomous system
System ID: Identifies the specific host. Usually 48 bits (or 6 octets) in length, to
accommodate MAC addresses
NSEL: Identifies the destination upper layer protocol of the host (always 8 bits)
NET address: does not contain upper-layer information (in other words, the SEL field is
always set to 0x00)
NSAP address: the ―full‖ CLNP address, with populated Area, ID, and SEL fields. Please
note: A NET address is simply an NSAP address with a zero value in the SEL field.
Route Redistribution allows routes from one routing protocol to be advertised into another
routing protocol. The routing protocol receiving these redistributed routes usually marks the
routes as external. External routes are usually less preferred than locally-originated routes.
At least one redistribution point needs to exist between the two routing domains. This device will
actually run both routing protocols. Thus, to perform redistribution in the following example,
Router B would require at least one interface in both the EIGRP and the OSPF routing domains:
It is possible to redistribute from one routing protocol to the same routing protocol, such as
between two separate OSPF domains (distinguished by unique process ID’s). Static routes and
connected interfaces can be redistributed into a routing protocol as well.
Routes will only be redistributed if they exist in the routing table. Routes that are simply in a
topology database (for example, an EIGRP Feasible Successor), will never be redistributed.
Routing metrics are a key consideration when performing route redistribution. With the
exception of IGRP and EIGRP, each routing protocol utilizes a unique (and thus incompatible)
metric. Routes redistributed from the injecting protocol must be manually (or globally) stamped
with a metric that is understood by the receiving protocol.
RIP is a standardized Distance-Vector routing protocol that uses hop-count as its distance
metric. Consider the following example
RouterB is our redistribution point between IGRP and RIP. To redistribute all IGRP routes into
RIP:
First, the router rip process was enabled. Next, RIP was configured to advertise the network of
172.16.0.0/16. Finally, RIP was configured to redistribute all igrp routes from Autonomous
System 10, and apply a hopcount metric of 2 to the redistributed routes. If a metric is not
specified, RIP will assume a metric of 0, and will not advertise the redistributed routes.
Still using the above example, to redistribute all RIP routes into IGRP:
First, the router igrp process was enabled for Autonomous System 10. Next, IGRP was
configured to advertise the network of 10.0.0.0/8. Finally, IGRP was configured to redistribute all
rip routes, and apply a metric of 10000 (bandwidth), 1000 (delay), 255 (reliability), 1 (load), and
1500 (MTU) to the redistributed routes.
IRISET 54 TA6 – MPLS
Routing Protocols
First, the router eigrp process was enabled for Autonomous System 15. Next, EIGRP was
configured to advertise the network of 10.1.2.0/24. Finally, EIGRP was configured to redistribute
all ospf routes from processID 20, and apply a metric of 10000 (bandwidth), 1000 (delay), 255
(reliability), 1 (load), and 1500 (MTU) to the redistributed routes.
RIP and IGRP also support the default-metric command. Though IGRP/EIGRP use only
bandwidth and delay by default to compute the metric, it is still necessary to specify all five
metrics when redistributing. If the default-metric or a manual metric is not specified,
IGRP/EIGRP will assume a metric of 0, and will not advertise the redistributed routes.
Redistribution will occur automatically between IGRP and EIGRP on a router, if both processes
are using the same Autonomous System number.
EIGRP, by default, will auto-summarize internal routes unless the no auto summary command is
used. However, EIGRP will not auto-summarize external routes unless a connected or internal
EIGRP route exists in the routing table from the same major network of the external routes.
OSPF is a standardized Link-State routing protocol that uses cost (based on bandwidth) as its
link-state metric. An OSPF router performing redistribution automatically becomes an ASBR.
First, the router ospf process was enabled with a process-ID of 20. Next, OSPF was configured
to place any interfaces in the network of 172.16.0.0/16 into area 0. Then, OSPF will redistribute
all eigrp routes from AS 15. Finally, a default-metric of 30 was applied to all redistributed routes.
If the default-metric or a manual metric is not specified for the redistributed routes, a default
metric of 20 will be applied to routes of all routing protocols except for BGP. Redistributed BGP
routes will have a default metric of 1 applied by OSPF.
By default, OSPF will only redistribute classful routes into the OSPF domain. To configure
OSPF to accept subnetted networks during redistribution, the subnets parameter must be used:
Routes redistributed into OSPF are marked external. OSPF identifies two types of external
routes, Type-1 (which is preferred) and Type-2 (which is default). To change the type of
redistributed routes:
Route redistribution introduces unique problems when there are multiple points of redistribution.
Consider the following diagram:
The first issue is caused by Administrative Distance (AD), which determines which routing
protocol is ―trusted‖ the most. By default, OSPF routes have an AD of 110, whereas RIP routes
have an AD of 120. Lowest AD is preferred, thus making the OSPF routes the most trusted.
Assume mutual redistribution has been performed on RouterC and RouterD. The following
networks will be injected from RIP into OSPF: 10.1.1.0/24, 10.1.2.0/24, 10.1.3.0/24, 10.1.4.0/24,
and 10.1.5.0/24.
RouterC will eventually receive OSPF routes to the above networks from RouterD, in addition to
the RIP routes already in its table. Likewise, RouterD will receive OSPF routes to these
networks from RouterC.
Because OSPF’s AD is lower than RIP’s, both RouterC and RouterD will prefer the sub-optimal
path through OSPF to reach the non-connected networks. Thus, RouterC will choose the OSPF
route for all the 10.x.x.x/24 networks except for 10.1.1.0/24, as it is already directly connected.
This actually creates a routing loop. RouterC will prefer the OSPF path through RouterA to
reach the 10.x.x.x networks (except for 10.1.1.0/24), and Router A will likely consider RouterC
its shortest path to reach those same networks. Traffic will be continuously looped between
these two routers.
Even if RouterC managed to send the traffic through RouterA and RouterB to RouterD, the
preferred path to the 10.x.x.x networks for RouterD is still through OSPF. Thus, the routing loop
is inevitable.
Distribution-list: The first method involves filtering incoming routes using a distribution-list,
preventing RouterC and RouterD from accepting any routes that originated in RIP from their
OSPF neighbors.
An access-list was created that is denying the RIP networks in question, and permitting all other
networks. Under the OSPF process, a distribute-list is created for routes coming inbound off of
the fastethernet0/0 interface. The access-list and distribute-list numbers must match. RouterD’s
configuration would be similar.
This prevents each router from building OSPF routes for the networks that originated in RIP,
and thus eliminates the possibility of a loop. However, redundancy is also destroyed – if Router
C’s fa0/1 interface were to fail, it could not choose the alternate path through OSPF.
Distance
The second method involves using the distance command to adjust the AD of specific routes.
This can accomplish two ways:
To force the RIP routes to be preferred, Router C’s configuration would be as follows:
An access-list was created that is permitting the RIP networks in question, and denying all other
networks. Under the RIP process, an administrative distance of 70 is applied to updates from
routers on the 10.1.1.0 network, for the specific networks matching access-list 10. RouterD’s
configuration would be similar.
Thus, the RIP-originated networks will now have a lower AD than the redistributed routes from
OSPF. The loop has again been eliminated. Another solution would be to raise the AD of the
external OSPF routes. OSPF provides a simple mechanism to accomplish this:
The Exterior Gateway Protocol (EGP) is an interdomain reachability protocol used in the
Internet, a large, international network connecting research institutions, government agencies,
universities, and private commercial businesses.
EGP is documented in (RFC) 904, published in April 1984. As the first exterior gateway protocol
to gain widespread acceptance in the Internet, EGP served a valuable purpose. Unfortunately,
the weaknesses of EGP have become more apparent as the Internet has grown and matured.
Because of these weaknesses, EGP is currently being phased out of the Internet, and is being
replaced by other exterior gateway protocols such as the Border Gateway Protocol (BGP) and
the Interdomain Routing Protocol (IDRP).
BGP is a standardized exterior gateway protocol (EGP), as opposed to RIP, OSPF, and EIGRP
which are interior gateway protocols (IGP’s).
Contrary to popular opinion, BGP is not a necessity when multiple connections to the Internet
are required. Fault tolerance or redundancy of outbound traffic can easily be handled by an IGP,
such as OSPF or EIGRP.
BGP is also completely unnecessary if there is only one connection to an external AS (such as
the Internet). There are over 100,000 routes on the Internet, and interior routers should not be
needlessly burdened.
Multiple connections exist to external AS’s (such as the Internet) via different providers.
Multiple connections exist to external AS’s through the same provider, but connect via a
separate CO or routing policy.
The existing routing equipment can handle the additional demands.
BGP’s true benefit is in controlling how traffic enters the local AS, rather than how traffic exits it.
For BGP to function, BGP routers (called speakers) must form neighbour relationships (called
peers). BGP neighbours are routers forming a TCP connection for exchanging BGP updates
iBGP Peers: BGP neighbors within the same autonomous system. IBGP neighbors doesn’t
need to be directly connected
eBGP Peers: BGP neighbors connecting separate autonomous systems. e-BGP neighbors
need to be directly connected.
In the above figure, RouterB and RouterC in AS 200 would form an iBGP peer relationship.
RouterA in AS 100 and RouterB in AS 200 would form an eBGP peering.
Once BGP peers form a neighbour relationship, they share their full routing table. Afterwards,
only changes to the routing table are forwarded to peers.
By default, BGP assumes that eBGP peers are a maximum of one hop away. This restriction
can be bypassed using the ebgp-multihop option with the neighbour command (demonstrated
later in this guide).
iBGP peers do not have a hop restriction, and are dependent on the underlying IGP of the AS to
connect peers together. By default, all iBGP peers must be fully meshed within the Autonomous
System.
A Cisco router running BGP can belong to only one AS. The IOS will only allow one BGP
process to run on a router.
The Administrative Distance for routes learned outside the Autonomous System (eBGP routes)
is 20, while the AD for iBGP and locally-originated routes is 200.
As a BGP peer session is forming, it will pass through several states. This process is known as
the BGP Finite-State Machine (FSM):
If a peer session is stuck in an Active state, potential problems can include: no IP connectivity
(no route to host), an incorrect neighbour statement, or an access-list filtering TCP port 179.
Neighbor Tables
o List of BGP Neighbors
BGP forwarding Table/database
o List of all networks learned from each neighbor
o Can contain multiple pathways to destination networks
o Database contains BGP attributes for each pathway
IP routing table
o List of best paths to destination networks
Community (optional transitive): Tags routes that share common characteristics into
communities.
Multi-Exit-Discriminator (MED) (optional non-transitive): Provides a preference to eBGP
peers to a specific inbound router.
Weight (Cisco Proprietary): Similar to Local Preference, provides a local weight to
determine the best path for outbound traffic.
ORIGIN Code1
AS-Path Code2
Next Hop Code3
MED Code4
Local Preference Code5
Automatic Aggregate Code6
Aggregator Code7
Community Code8
If BGP contains multiple routes to the same destination, it compares the routes in pairs, starting
with the newest entries (listed higher in the routing table), and working towards the oldest
entries (listed lower in the table).
BGP determines the best path by successively comparing the attributes of each ―route pair.‖
The attributes are compared in a specific order:
Peer IP Address: Which route originated from the router with the lowest IP?
When applying attributes, Weight and Local Preference are applied to inbound routes, dictating
the best outbound path.
AS-Path and MED are applied to outbound routes, dictating the best inbound path.
Also referred as Multicast BGP and defined in IETF RFC 4760is an extension to Border
Gateway Protocol (BGP) that allows different types of addresses (known as address families) to
be distributed in parallel. Whereas standard BGP supports only IPv4 unicast addresses,
Multiprotocol BGP supports IPv4 and IPv6 addresses and it supports unicast and multicast
variants of each. Multiprotocol BGP allows information about the topology of IP multicast-
capable routers to be exchanged separately from the topology of normal IPv4 unicast routers.
Thus, it allows a multicast routing topology different from the unicast routing topology. Although
MBGP enables the exchange of inter-domain multicast routing information, other protocols such
as the Protocol Independent Multicast family are needed to build trees and forward multicast
traffic.
As an enhancement of BGP-4, MP-BGP provides routing information for various protocols, such
as IPv6 (BGP4+) and multicast:
MP-BGP maintains unicast and multicast routing information, and stores both types in
different routing tables to ensure their separation.
MP-BGP supports unicast and multicast, and constructs different network topologies for
each.
MP-BGP can maintain unicast and multicast routes based on routing policies. The unicast
routing policies and configurations supported by BGP-4 can mostly be applied to multicast.
Multiprotocol BGP is also widely deployed in case of MPLS L3 VPN, to exchange VPN labels
learned for the routes from the customer sites over the MPLS network, in order to distinguish
between different customer sites when the traffic from the other customer sites comes to
the Provider Edge router (PE router) for routing.
Back to Contents
References
https://www.routeralley.com/guides.html
https://networklessons.com/mpls
https://www.arista.com/en/um-eos/eos-bgpmpls-l3-vpn
https://ccieblog.co.uk/mpls/difference-between-the-rd-and-rt
https://packetlife.net/blog/2013/jun/10/route-distinguishers-and-route-targets/
https://media.ciena.com/documents/All+About+MPLS+Traffic+Engineering+E+Book.pdf
https://www.cisco.com/c/en/us/td/docs/ios/ios_xe/mpls/configuration/guide/mp_qos_xe.html#
wp115662
ANNEXURE 1
Back to Contents
ANNEXURE 2
Back to Contents
ANNEXURE 3
Back to Contents
ANNEXURE 4
Back to Contents
APPLICATIONS
1G
- Up
k link
plin
-U
1G
MPLS
Location 5 Cloud
IP MPLS Cloud
Back to Contents
Back to Contents
Index
A H
adjacencies, 42, 44, 46, 47, 51 headend, 16, 17, 18
administrative, 23, 24, 27, 28, 29, 31, 41, 51, 58 header, 2, 4, 5, 18, 19, 20, 43
advertisement, 13 hexadecimal, 52
algorithm, 25, 27, 30, 31, 33, 39, 40, 41, 50, 51 hopcount, 31, 54
arbitrary, 28, 51 hybrid, 55
authentication, 31, 32
I
B igrp, 54
backup, 38 implicit, 6
baud, 31 inbound, 7, 58, 63, 64
bottlenecks, 19 inconsistencies, 31
broadcasts, 8, 31, 45 infinity, 31
ingress, 3, 5, 8, 10, 16, 17, 18, 19, 20
C
injecting, 54
classful, 31, 33, 56
interdomain, 59
clients, 2, 24
ipospf, 46
D
J
datalink, 9
jitter, 18
decapsulation, 5
discontiguous, 31 L
labeled, 20
E
lite, 13
ebgp, 61
egress, 5, 8, 19, 20 M
eigrp, 39, 55, 56 matured, 59
encapsulate, 1 metric, 13, 27, 28, 30, 31, 32, 33, 34, 35, 36, 38,
39, 41, 49, 51, 54, 55, 56
encrypt, 9
multiaccess, 44, 45, 46
equivalence, 2, 5
multihop, 61
explicit, 6
extensions, 12 N
exterior, 26, 53, 59, 63 neighbor, 7, 8, 34, 35, 37, 38, 40, 41, 42, 44, 45,
46, 47, 50, 51, 60, 61, 62
F
neighboring, 35, 41, 47, 51
failover, 17
neighboringrouter, 44
G
O
granular, 36, 52
ospf, 55, 56, 57, 58
guarantees, 21
P T
penultimate, 5, 6 tagging, 31
pinhole, 31 tailend, 18
pop, 3, 5, 6 tandem, 52
preemptive, 46 timeline, 23
prone, 23, 25 timer, 32, 33, 34, 42, 61
proprietary, 7, 33, 34, 54, 55 tolerance, 60
protocol, 1, 2, 3, 5, 7, 8, 10, 17, 23, 24, 25, 27, topology, 7, 16, 23, 24, 26, 30, 35, 37, 38, 39, 40,
28, 30, 31, 33, 34, 35, 40, 41, 43, 48, 41, 45, 47, 49, 51, 54, 64
50, 51, 52, 53, 54, 55, 56, 59, 63
torn, 61
pseudo, 9
traffic, 1, 2, 3, 8, 9, 10, 14, 16, 17, 18, 19, 20, 28,
pseudowire, 14 30, 31, 34, 39, 41, 45, 46, 47, 57, 60, 62,
63, 64
Q
transit, 5, 6, 10, 48
queueing, 19, 20
triggered, 18, 59
R tunnel, 5, 10, 17, 18
redistribution, 53, 54, 56
U
redundancy, 39, 46, 58, 60
unicast, 5, 11, 35, 45, 59, 64
robin, 31
unstable, 37
routers, 2, 5, 6, 7, 8, 10, 12, 13, 16, 17, 19, 20,
upstream, 8, 18
22, 23, 24, 25, 26, 28, 29, 30, 31, 32, 33,
34, 35, 39, 40, 41, 42, 43, 44, 45, 46, 47,
V
48, 49, 51, 52, 57, 58, 60, 62, 64
variable, 2, 52
S
variance, 39
scalability, 11, 50
vector, 27, 30, 35
scheduling, 19
version, 23, 24, 32
session, 61, 62
signaling, 7, 8, 17
signposts, 30, 40
slave, 47
solicited, 8
stacked, 3
strip, 62
stubby, 49
subnet, 31
suit, 7, 8
supplant, 46
swap, 2, 3, 5
Back to Contents