Implementing Complex MP-BGP Over-Lapping VPNs

Department of Computer Science, BZU
BSTS (2005-2008)
FINAL
IMPLEMENTING COMPLEX MP-BGP
DISSERTATION
REPORT OVER-LAPPING VPNS
M. Shahrukh Baig (0520) | Khurram Aziz Shah (0504)

Supervised by: Sir Engineer Ahmad Mustufa
Implementing Complex MP-BGP Over-Lapping VPNs
Undertaken by
M. Shahrukh Baig (0520)

&
Khurram Aziz Shah (0504)
BS (Telecommunication Systems)
Session 2005-2008
Supervised by
Sir Engineer Ahmad Mustufa

A dissertation submitted as partial fulfillment for the requirement of the degree
of BS (Telecommunication Systems).
Department of Computer Science,

Bahauddin Zakariya University, Multan, Pakistan
Implementing Complex
MP-BGP Over-Lapping
VPNs
Final Approval
This is to certify that we have read this dissertation report titled “IMPLENTING COMPLEX MP-
BGP OVER-LAPPING VPNs” submitted by M. Shahrukh Baig, roll # 0520 & Khurram Aziz Shah,
roll # 0504 and it is our sound verdict that the document is of decent standard to endorse its
acceptance by the Department of Computer Science, Bahauddin Zakariya University, Multan for
the accomplishment of the degree of BS (Telecommunication Systems).
Committee:
Supervisor: Sir Engineer Ahmad Mustufa
Signature: Dated:
Internal Examiner: Sir M. Ateeq

Signature: Dated:
External Examiner:
Signature: Dated:
Chairman: M. Aziz Akhtar

Signature: Dated:
Acknowledgements
First of all, we are thankful to Almighty ALLAH who gave us the courage and patience to
complete the dissertation.
No doubt, many individuals have profoundly influenced us during our graduate studies at the
Bahauddin Zakariya University, Multan and it is a matter of great pleasure to acknowledge the
guidance and support extended by all these benevolent fellows.
We would like to express out most revered thanks to our supervisor: Engineer Ahmad Mustufa,
who has always extended out of turn support and guidance to us to work on this project. No
doubt, he has scarified plenty of his precious time and his brain to make us handle this arduous
project. Had not be encouraged us from time to time by taking the time to read and critique out
thesis, we would have surrounded the mission unaccomplished.
We are deeply grateful to our teachers especially Madam Sarwat, Sir Imran, Engineer Laeeq
Akhtar, Engineer Abdul Mannan, Engineer Tariq Aziz, Engineer Aqeel, for their prudence and
foresightedness to inspire us to execute into such interesting and innovative studies like this.
Obviously, all of them have been kind enough to us during execution of the project by sharing
their Knowledge and as well as giving us nice pieces of advice, appositely, adequately and
generously.
Another round of applause goes to our special friends – to name some of them – Zohaib Aslam,
Rumman Ahmad, Assam Hammad, Sufyan Masuod, Akmal Khan Warsi & Talal Mehmood.
Surely, these people have been true benefactors in our whole study session at BZU.
And last but obviously not the least, we wish our kind Parents & Siblings who extended their
invaluable support during whole of our life.
Khurram Aziz Shah

M. Shahrukh Baig
Dedication
The dissertation study is whole heartedly dedicated to our

BELOVED PARENTS.
Contents
Prolusion
Episode 0 – Baseline Configuration 1
The Topology 2
Episode 1 – Configuration of the Core with IS-IS & MPLS 5
1.1 – an eye into IS-IS 6
1.2 – Configuring the core with IS-IS 8
1.3 – an eye into MPLS 12
1.4 – Configuration of the Core with MPLS 15
Episode 2 – Establishing iBGP neighborship among Provider Edges 18
2.1 – an eye into BGP 19
2.2 – Configuration of iBGP neighborship among Provider Edges 21
Episode 3 – Multi-Protocol BGP 23
3.1 – an eye into Multi-Protocol BGP 24
3.2 – Configuration of MP-BGP 26
Episode 4 – Virtual Private Networks 27
4.1 – an eye into VPNs 28
4.2 – Configuration of VPNs at Provider Edges 33
Episode 5 – PE to CE Routing Protocols 37
5.1 – Open Shortest Path First 38
5.1.1 – an eye into OSPF 38
5.1.2 – Configuration of OSPF for Customer A sites 39
5.2 – EIGRP 42
5.2.1 – an eye into EIGRP 42
5.2.2 – Configuration of EIGRP for Customer C sites 43
5.3 – Configuration of BGP for Customer B sites 46
Episode 6 – Over-Lapping VPNs or Extranets 49
6.1 – an eye into Over-Lapping VPNs or Extranets 50
6.2 – Configuration of Over-Lapping VPNs 51
Denotations
Dissertation Brief
Prolusion
MPLS has become popular and has seen many implementations and deployments by service
providers. MPLS—or Tag Switching as it was called originally—has seen success that has
surprised many people in the networking industry.
A big part of the sensation is the result of the huge success of MPLS VPN in the industry. Service
providers quickly recognized the great benefits of MPLS VPN and deployed it quickly while
features for it were still being developed. These days even enterprise customers are looking at
MPLS VPN with interest. They might have already deployed MPLS VPN for the benefit of a
greater scalability. Other benefits to them are the separation of departments, or the easier
deployment of PE and CE routers.
The Overlapping VPNs or Extranets have evolved as one of the most deployed features of MPLS.
As per the growing connectivity requirements of the corporate world today, Overlapping VPNs
have confronted a tremendous success. The demand for extranets is increasing with time for
they provide greater scalability, security and easier implementation of the network machines.
Now days, the corporates require a secure & easily implemented connectivity solution to have
their uninterrupted relation with their counterparts all over the world. The dissertation
document addresses this surprising technology in the most apprehensible way. These writings
showcase that how two or more organizations can colligate with each other by the use of MP-
BGP VPNs.
Episode 0 Baseline Configuration
Episode 0
Baseline Configuration
Implementing Complex MP-BGP Overlapping VPNs 1

The Topology

The following tables list the interface addresses of the Core routers:
Router Interface Address

Provider (P) S1/0 192.168.1.9/30
Provider (P) S1/1 192.168.1.13/30
Provider (P) S1/2 192.168.1.17/30
Provider (P) Loopback 0 192.168.1.4/32

Provider Edge 1 S1/0 192.168.1.10/30
Provider Edge 1 S1/1 150.1.1.18/30
Provider Edge 1 S1/2 150.1.3.22/30
Provider Edge 1 Loopback 0 192.168.1.1/32

Provider Edge 2 S1/0 192.168.1.14/30
Provider Edge 2 S1/1 150.1.3.18/30
Provider Edge 2 S1/2 150.1.2.22/30

Provider Edge 3 S1/0 192.168.1.18/30
Provider Edge 3 S1/1 150.1.1.22/30
Provider Edge 3 S1/2 150.1.2.18/30

This table lists the interface addresses of the Customer Edge A routers:

CEA1 S1/0 150.1.1.17/30
CEA1 Loopback 0 10.1.1.1/32
CEA1 Loopback 100 10.1.1.17/28
CEA1 Loopback 200 10.1.1.33/28
CEA2 S1/0 150.1.1.21/30
CEA2 Loopback 0 10.1.1.2/32
CEA2 Loopback 100 10.1.1.49/28
CEA2 Loopback 200 10.1.1.65/28
The next table lists the interface addresses of Customer Edge B machines:

CEB1 S1/0 150.1.2.17/30
CEB1 Loopback 0 10.1.2.1/32
CEB1 Loopback 100 10.1.2.17/28
CEB1 Loopback 200 10.1.2.33/28
CEB2 S1/0 150.1.2.21/30
CEB2 Loopback 0 10.1.2.2/32
CEB2 Loopback 100 10.1.2.49/28
CEB2 Loopback 200 10.1.2.65/28
This table lists the interface addresses of Customer Edge C devices:

CEC1 S1/0 150.1.3.17/30
CEC1 Loopback 0 10.1.3.1/32
CEC1 Loopback 100 10.1.3.17/28
CEC1 Loopback 200 10.1.3.33/28
CEC2 S1/0 150.1.3.21/30
CEC2 Loopback 0 10.1.3.2/32
CEC2 Loopback 100 10.1.3.49/28
CEC2 Loopback 200 10.1.3.65/28

Episode 1 Establishing the Core with IS-IS & MPLS
Episode 1
Establishing the Core with IS-IS & MPLS

PART 1.1 an eye into IS-IS

Integrated System to Integrated System is the strongest and efficient IGP ever created in the
routing world. IS-IS was created for OSI in the first place then tuned to work for TCP/IP protocol
and renamed as integrated IS-IS.
In the world of IS-IS, a router is known as intermediate system, so it was named as IS to IS

routing protocol.
It is a link state routing protocol maintaining
• neighbor table
• routing table
• topology table
while it is based on SPF algorithm.
However, as a matter of fact, SPF is rarely used. SPF is only used to find OSI neighbors. Actually,
it uses Partial Route Calculation (PRC) to calculate IP reachability.
Summarization is done on exiting side of area towards backbone.
Hierarchical design of Areas

IS-IS disseminates the network into areas and assigns the routers a different level according to
the position and responsibilities of it in that area
• Level 1 (L1) router maintains the topology database of its own area.
• Level 2 (L2) routers are considered as back bone routers maintaining the backbone of
the whole network. And the back bone runs to all areas.
• Whereas Level 1-2 (L-1-2) routers carry the relations with both L1 & L2 routers to bridge
between L1 and the back bone L2 routers.
• L1 & L2 routers form like relationships but maintain different databases for level 1
routers and level 2 routers. They actually maintain two relationships with each other
i.e., leve1 and level 2 associations separately.
• L-1-2 routers actually act as OSPF’s ABRs.
• In IS-IS, a router belongs to one area at a time unlike OSPF where a router can be in
different areas.
• End systems participating in the process are known to be End System- Intermediate
System (ES-IS).

IS-IS possesses different routing domains
• L0 describes routing between an IS and an ES.

• L1 routing describes routing between ISs in the same area.
• L2 describes routing among ISs of different areas.
• L3 is routing between the ISs of different ASs.
ISIS advantages over contemporary link state protocols
• ISIS handles updates efficiently

• Much faster to detect failures and coverage
• Has limited design constraints
• Easy to adapt to Ipv6
Address format
• OSI uses Connectionless Network Protocol Service (CLNS) which is equivalent to IP in

TCP/IP. When we assign CLNP addresses to a router, they are called Network Service
Access Point (NSAP) addresses.
• When applying CLNP addresses to Cisco routers, they are also called Network Entity Title
(NET) addresses.
• The addresses follow hexadecimal format. ISIS uses only one address per node (router)
and not per interface.
• NET addresses can be up to 20 bytes in length. NET address may be divided into five
parts but Cisco’s implementation of NET address tells about the area, which the node is
in, the system ID & the NSAP selector (NSEL).
For instance: 49.1234.AA15.B322.1841.00

PART 1.2 Configuring the Core with IS-IS
To configure IS-IS on Provider router, first we configure IS-IS in the global configuration mode,
giving its NET & defining the level of the router. Provider is deep in the core, so it must be a
level-2 router. Then, the intended interfaces are configured step by step. As the Provider router
exists deep inside the core, so all of its interfaces are configured for IS-IS. The isis circuit-type
command tweaks the interface to send only the intended level packets, thus saving bandwidth.

The configuration follows:
The Provider Edge 1 router is being configured here as a level-1-2 router as it is connected to
the Provider level-2 router & on any other of its interfaces, it can establish a level-1 relationship
if needed, e.g., with any new Customer who might be running IS-IS. Here, we only need to
include interface serial 1/0 and interface loopback 0 in the IS-IS routing process. The
configuration is as under:
The Provider Edge 2 router is also configured here as a level-1-2 router as it is connected to the
Provider level-2 router & at any other of its interfaces, it can establish a level-1 relationship if
needed, e.g., with any new Customer who might be running IS-IS. Here, we only need to include

interface serial 1/0 and interface loopback 0 in the IS-IS routing process. The configuration is as
under:
The Provider Edge 3 router is also configured here as a level-1-2 router as it is connected to the
Provider level-2 router & on any other of its interfaces, it can establish a level-1 relationship if
needed, e.g., with any new Customer who might be running IS-IS. Here, we only need to include
interface serial 1/0 and interface loopback 0 in the IS-IS routing process. The configuration is as
under:
To verify the IS-IS routing process, we run show clns neighbors command to confirm the IS-IS
neighbors of the provider & we can see that all the core machines are participating in IS-IS
process. The next verification command is show isis topology, which gives a peak into the
whole of IS-IS topology while we sit at the Provider router.


PART 1.3 an eye into MPLS

Multiprotocol Label Switching (MPLS) is a popular networking technology that uses labels
attached to packets to forward them through the network. The MPLS labels are advertised
between routers so that they can build a label-to-label mapping.
These labels are attached to the IP packets, enabling the routers to forward the traffic by
looking at the label and not the destination IP address. The packets are forwarded by label
switching instead of by IP switching.
Optimizes IP
IP is broadly accepted as the platform for converged network services, but the traditional IP
networks have faced shortcoming especially in the field of scalability, security and quality of
service. MPLS technology is designed to address the shortcomings of the IP network and
enabling the providers to ensure the amenities of QoS scalability and security to the network.
Terminologies
• The routers within an MPLS network that are responsible for label processing are known
as Label Switched Routers (LSRs)
• The path followed by data is known as a Label Switched Path (LSP).
• The Tag Distribution Protocol (TDP) is Cisco’s proprietary protocol that is used to bind
tags (which are the same as MPLS labels) to network routes in the routing table.
• The Label Distribution Protocol (LDP) is the IETF version of Cisco’s TDP. LDP is used to
bind labels to network routes.
• The label information base (LIB) is a mapping of incoming labels to outbound labels,
along with outbound interface and link information.
• The LFIB is a subset of the LIB.
• An additional component that resides in the forwarding plane is the forwarding
information base (FIB).The FIB is built by Cisco Express Forwarding (CEF). The FIB is
essentially a cached version of the IP routing table that eliminates the need for a route-
cache. For Cisco MPLS or tag switching to work, CEF must be enabled.
The two architectural components of MPLS are:
Forwarding Plane or Data Plane
An MPLS-enabled router switches IP packets instead of forwarding them traditionally. The

forwarding component of the MPLS architecture (known as the forwarding plane or data plane)

is where information created and maintained from the control plane is actually used. Simply
put, we can think of the forwarding plane as being like a big cache.
Control Plane
The routing table is built in the control plane and cached in the forwarding plane. For labels, the
LIB is built in the control plane, and only those labels in use reside in the label forwarding
information base (LFIB).
Operation
On entry to an MPLS network, a fixed-format label is inserted at the front of each packet. This
label tells switching nodes throughout the network how to process and forward the data. The
packet's path through the network is defined by its initial labeling; the subsequent mapping of
labels is consistent at each node.
Each LSR in the MPLS network runs a Label Distribution Protocol (LDP). LDP distributes the
labels that are to be used to forward packets across the MPLS network using peer-to-peer
negotiation from network edge to network edge. These labels are bound to Forwarding
Equivalence Classes (FECs) each of which defines an IP address prefix for an egress point from
the network. The point to be noted is that these labels only have significance between these
LSR-peers.
On entry to an MPLS network, the destination IP address of the packet is longest-matched

against the FECs that the LSR has stored. The MPLS label bound to this FEC is then inserted at
the front of this packet. Each packet's IP header thus only needs to be examined closely on
entry to the MPLS network, at the ingress or edge LSR, where the first label is applied. At
subsequent LSRs, only the label is checked, thus avoiding the need for complex decision making
at each hop. The result is faster processing and thus faster transition through the core network.

Benefits of MPLS
• The use of one unified network infrastructure
• Better IP over ATM integration
• Border Gateway Protocol (BGP)-free core
• The peer-to-peer model for MPLS VPN
• Optimal traffic flow
• Traffic engineering

PART 1.4 Configuration of the core with MPLS
All of the interfaces of the Provider router are configured to run MPLS as follows:
The above trend is followed for interfaces serial 1/0 of all the three Provider Edges routers.
Now, to verify MPLS, we run show mpls ldp neighbor command at Provider. This command
shows us all the MPLS neighbors of the Provider.

Hence, we can see that the Provider router has established MPLS neighborship with the
Provider Edge routers. So, we don’t need to verify this on Provider Edges. Another interesting
command here is show mpls forwarding-table, which showcases the labels assigned to the
networks. And we do have the output cuts of this command for all the four core routers.


Episode 2 Establishing iBGP Neighborship among Provider Edges
Episode 2
Establishing iBGP Neighbor-ships among

Provider Edges

PART 2.1 an eye into BGP

Border Gateway Protocol is the protocol of the internet. It is the only External Gateway
Protocol (EGP) used between autonomous systems where an AS is a collection of networks
under single technical administration.
Features
• BGP runs on top of TCP (port 179).
• Updates are incremental & triggered.
• BGP is the slowest protocol on the planet to converge.
• BGP resides over an IGP.
• It is one of the most tunable and flexible routing protocol.
Supports two flavors

• Internal BGP (iBGP) runs between routers running under same authority or same
autonomous system. iBGP neighbors may not have direct physical connectivity.
• External BGP (eBGP) peers must be directly connected. eBGP bridges two neighbors of
different autonomous systems. And the neighbors are configured manually.
Attributes
• It uses compound set of metrics also called attributes.
• BGP attributes are of two types: well-known (every vendor supports) and optional.
• Well-known attributes might be mandatory (must be in the update) or discretionary.
• While optional attributes might be transitive (travel from router to router or AS-AS) or
non-transitive.
1. Well-known Attributes
AS path (mandatory) - is actually the list of AS numbers that a route has traversed in order to
reach a destination. It helps in loop prevention.
Next hop address (mandatory) - is the next hop IP address that is used to reach a certain
destination.
Origin (mandatory) - defines the origin of the path information. The origin attribute can assume
three values:
o IGP: This normally happens when we use the BGP network command or when IGP is
redistributed into BGP, than the origin of the path info will be IGP. This is indicated with
an “i” in the BGP table.

o EGP: NLRI is learned via EGP (Exterior Gateway Protocol). This is indicated with an “e” in
the BGP table.
o INCOMPLETE: A route is unknown or learned via some other means. This usually occurs
when we redistribute a static route into BGP and the origin of the route will be
incomplete. This is indicated with an “?” in the BGP table.
Local preference (discretionary) - is an indication to the AS about which path is preferred to exit
the AS in order to reach a certain network. A path with a higher local preference is more
preferred. The default value for local preference is 100.
Atomic aggregate (discretionary) – informs router that a route has been summarized.
2. Optional Attributes
Multi-exit discriminator - The metric attribute which is also called multi exit discriminator (MED,
BGP4) or Inter-As (BGP3) is a hint to external neighbors about the preferred path into an AS.
This is a dynamic way to influence another AS on which way to choose in order to reach a
certain route given that we have multiple entry points into that AS. A lower value of a metric is
more preferred.
Aggregator – goes right along the Atomic aggregator & tells actually who (router) has
summarized the route.
Community - The community attribute is a transitive, optional attribute in the range 0 to

4,294,967,200. The community attribute is a way to group destinations in a certain community
and apply routing decisions (accept, prefer, redistribute, etc.) according to those communities.
It is used for route tagging.

PART 2.2 Configuration of iBGP Neighborship among Provider Edges

Here comes the configuration of Internal BGP neighbors in our core at Provider Edge 1 router.
Here above, there iBGP neighborships are being established between loop backs of PE1-PE2,
PE1-PE3, under same Autonomous System with the command neighbor 192.168.1.2 remote-as
65000.
The Update- source loopback 0 command forces BGP to use the loopback IP address as the
source in the TCP neighbor connection. We use loopbacks for the neighborships so that they
never get down.
The next-hop-self command will allow us to force BGP to use a specified IP address as the next
hop rather than letting the protocol choose the next hop. By default, iBGP neighbors do not
change the next hop in the updates. Say, a neighbor A sends updates to the neighbor B, this
command tells the neighbor B to use the router A as the next hop for that update.
Here it goes at Provider Edge 2 & 3 respectively.

And now, as usual, the verification procedure. Sh ip bgp neighbors command shows the brief
description of neighborships with the BGP peers. On Provider Edge 1 down here, we can see
that it is forming iBGP neighborships with Provider Edge2 & 3 respectively.

Episode 3 Multi-Protocol BGP
Episode 3
Multi-Protocol BGP

PART 3.1 an eye into Multi Protocol - BGP

Multi-Protocol BGP (MP-BGP) is a requirement for the proper operation of MPLS VPNs. From a
network design standpoint, an IGP runs in the service provider core, and BGP runs between
edge routers. To enable the edge routers to support MPLS VPNs, MP-BGP must be configured.
In an MPLS-enabled network, it is not necessary for every device in the network to know about
every possible network route. In addition, labels can be stacked. In the case of MPLS VPNs, IP
packets enter the network as unlabeled IP. The edge-LSR not only applies a label for the packet
to move through the network, but it also provides a VPN label. This process is called label
stacking. The following figure shows the label stacking process.
Now, the question that teases here is that why is the VPN label important? Well, the answer is
“how else does an egress LSR know which VPN a packet is destined for?” Two Customers might
have an address space that may over-lap. In that case, the edge router will have no idea about
where to route the packet?
To remedy situations like these, the Provider Edge routers assign labels to customer routes that
show up in the VRF. Those labels are then propagated through Multi-Protocol BGP (MP-BGP).
MP-BGP must be configured for an MPLS VPN to work. In the following figure, the PE1 router

has assigned a label of 32 to the 10.0.0.0 network for Customer A and propagated that to P.
When a packet arrives at PE3, the router sees the VPN label first. Since PE1 assigned the label, it
knows exactly where the packet goes.
MP-BGP must be configured between all routers that need to propagate or exchange VPN
routes. To configure MP-BGP, the address-family vpnv4 command is used from within the
traditional BGP configuration. An address family is sometimes referred to as a routing context.
In this case, the address family vpnv4 command is used within global BGP configuration.
Therefore, this special context does not need a new BGP process. (Only one BGP process is
supported at a time on a Cisco IOS router). Neighbors, if already configured in global BGP,
simply need to be activated.
Communities must be configured as well. There are two types of communities: extended and
standard. Standard communities have not been replaced by extended communities. It is
necessary to specify extended communities between MP-BGP neighbors for proper VPN
operation. The default operation of BGP is to send no community values. Therefore, we must
manually configure MP-BGP to send both standard and extended communities.

PART 3.2 Configuration of MP-BGP
Here above, already iBGP neighborships are activated for address-families with command
neighbor 192.168.x.x activate.
Send-community both command will allow the address families to carry standard and extended
communities.

Episode 4 Virtual Private Networks
Episode 4
Virtual Private Networks

PART 4.1 an eye into VPNs

A Virtual Private Network (VPN) enables a secure, private connection between geographically
remote customer sites over a shared backbone. The issue we are discussing here is related to
customer sites connected to a common service provider network offering an IP service. VPNs
can be used to implement corporate intranets, linking remote offices or mobile workers, and
extranets, extending the services to customers, suppliers or other communities of interest.
The term VPN actually covers a wide variety of alternative architectures.
IP-based Overlay or Tunneling VPNs
• Virtual circuit-based VPN solutions deliver IP services across a public Frame Relay or
ATM network. This architecture uses a Layer 2 overlay model to map logical networks on
top of physical ones.
• Layer 3 IP tunneling architectures operate across routed core networks (e.g., using GRE
or IPSec). A tunnel applies to specific traffic and serves to hide certain information from
the rest of the network.
However, these technologies can be associated with scalability problems, largely because they
depend on creating and administering connections, not networks. Scalability suffers so much
because of the high volume of virtual circuits that have to be provisioned and because each
new customer or site added to a VPN will require new connections to be created and
supported.
MPLS-based peer-to-peer VPNs
In MPLS based VPNs, routing information is exchanged between a customer site and a service
provider edge site, and the service provider is responsible for establishing and maintaining
paths through the core and propagating routes between customer sites.
• Scalability is one of the foremost advantages of MPLS VPNs. They are based on
networks, not connections, hence they are easier to scale. There is no need to create a
full mesh of tunnels or permanent VCs between all sites in the VPN. Deploying and
maintaining an MPLS VPN is therefore easier than the VC-based or IP tunneling options.
• Security and privacy within an MPLS VPN is achieved by limiting the distribution of
routing information to all members of the VPN. Routes to VPN sites are only advertised
to members of the same VPN, and are not shared with devices outside the VPN.

MPLS VPN Terminologies
In an MPLS VPN, routers are classified according to the roles they perform:
• Provider Edge (PE) routers are those routers within a service provider core network that
connect directly to a router at the customer's site.
• Provider (P) routers are all those routers within the VPN core network that are not edge
routers.
• Customer Edge (CE) routers are those routers at the customer premises that have a
direct interface to the PE router. These are sometimes known as CPE devices.
The PE routers actually define the membership of the VPN by maintaining configuration
information to link together all sites in the VPN. Members of a VPN are aware only of other
members, although sites can be in multiple VPNs. Provider core routers do not maintain any
VPN routing information but are responsible for forwarding traffic throughout the network
using MPLS.
Route distinguishers
• MPLS VPNs enable customer site networks to use private address space, rather than
globally registered IP addresses. This is achieved by ensuring unique public addresses for
use within the VPN, by means of Route Distinguishers (RDs).
• A route distinguisher (RD) creates routing and forwarding tables and specifies the
default route-distinguisher for a VPN.
• The RD is added to the beginning of the customer's IPv4 prefixes to change them into
globally unique VPN-IPv4 prefixes.
• An RD is either ASN-relative, in which case it is composed of an autonomous system
number and an arbitrary number, or it is IP-address-relative, in which case it is
composed of an IP address and an arbitrary number.
We can enter an RD in either of these formats:
16-bit AS number: your 32-bit number. For example, 101:3

32-bit IP address: your 16-bit number. For example, 192.168.122.15:1
VRF tables
• One of the key points about a VPN is the maintenance of security and separation of
data; it must prevent communication between sites that are not in the same VPN.

• One of the ways in which this is achieved is by ensuring that VPNs have their own
routing and forwarding tables in the PE router, so a customer site that belongs to a VPN
can access only the set of routes contained in that routing table.
• Each PE router maintains a number of separate forwarding tables known as VRFs (VPN
Routing and Forwarding tables), and each site (i.e., each PE interface or sub-interface
connected to a CE device) must be mapped to one of those VRFs.
• The vital point here is that a VRF table does not necessarily correspond to a particular
VPN. Its purpose is to hold the routes that are available to a particular site connected to
a PE device. If a site is in multiple VPNs, the VRF associated with that site contains
routes from all the VPNs of which it is a member.
• VRF tables are propagated to other PE devices. But since a VRF table is not mapped
directly on to a VPN, it is necessary to identify the VPN to which each route applies. This
is achieved by means of route targets.

Route Targets
• Every route that is distributed from a VRF is tagged with an export route target attribute
identifying its VPN.
• Each VRF is tagged with one or more import route target attributes, indicating the VPNs
that it wants to import routes for.
• When routes are distributed, any route marked with a particular export route target
attribute will be installed in VRF tables marked with the same import route target
attribute.
• For a fully-meshed VPN, each site's VRF table imports and exports the same routes.
• For a hub and spoke VPN, the VRF table at the hub site imports routes from all sites,
while the VRF tables at the spoke sites import only routes from the hub site VRF.
To create a route-target extended community for a VRF, we use the route-target VRF sub-mode
command.
route-target {import | export | both} route-target-ext-community
Syntax Description
import Imports routing information from the target VPN extended community.
export Exports routing information to the target VPN extended community.
both Imports both import and export routing information to the target VPN
extended community.
route-target-ext- Adds the route-target extended community attributes to the VRF's list of
community import, export, or both (import and export) route-target extended
communities.
Address Families
• To support the Multiprotocol behavior of BGP in Cisco IOS, the BGP routing process has
the concept of address families. The four address families that are currently supported
are IPv4, IPv6, vpnv4 (VPN-IPv4), and vpnv6 (VPN-IPv6).
• Virtual Routing & Forwarding tables work under address families in the routing
protocols. To pass VPN routes from one Provider Edge router to another, a BGP VPN
address family is established.

• Also, under the routing protocols processes, which run from Provider Edge machines to
Customer Edge machines, we need to establish IPv4 address families & they are
associated with the related VRFs.
• Next process is the redistribution of PE-CE protocols into BGP process & vice versa.

PART 4.2 Configurations of VPNs at Provider Edges
In the previous section, we established VPNv4 neighborships so, next step asks for the creation
of VRFs & the Route Distinguishers along with the Route Targets. Also, the related interfaces
are then bounded with their VRFs. And here we go for the Provider edges step by step:


Provider Edge 1 S1/1 150.1.1.18/30
Provider Edge 1 S1/2 150.1.3.22/30
Provider Edge2 S1/1 150.1.3.18/30
Provider Edge2 S1/2 150.1.2.22/30
Provider Edge3 S1/1 150.1.1.22/30
Provider Edge3 S1/2 150.1.2.18/30
And here we go for the Provider edges step by step:
Here above, on Pedge1 a VRF for customer A is created with command ip vrf custa (where
custa is the name of VRF) and route distinguisher of 1:10 for vrf is created with command rd
1:10.
Routes to be exported or imported with this vrf are set by commands route-target import 1:10,
route-target export 1:10.
Binding the vrf custa with s1/1 through command ip vrf forwarding custa.
Here above, on Pedge1 a VRF for customer C is created with command ip vrf custc (where custc
is the name of VRF) and route distinguisher of 1:30 for vrf is created with command rd 1:30.

Binding the vrf custc with s1/2 through command ip vrf forwarding custc.
Instead of using both import & export versions of route-target command, we can simply use
route-target both command as shown above & in next configurations.
For Provider Edge 2, the sequence follows:
Here above, on Pedge2 a VRF for customer B is created with command ip vrf custb (where
custb is the name of VRF) and route distinguisher of 1:20 for vrf is created with command rd
1:20.
Binding the vrf custb with s1/2 through command ip vrf forwarding custc.
Down under is the configuration for custc on Provider Edge 2 router.
The following configuration is for custa & custb on Provider Edge 3 router respectively.

After VRFs, let’s jump onto PE to CE routing protocols.

Episode 5 PE to CE Routing Protocols
Episode 5
PE to CE Routing Protocols

PART 5.1 Open Shortest Path First
SECTION 5.1.1 an eye into OSPF
• OSPF is link state routing protocol maintaining three tables:

o Neighbor table
o Topology table
o Routing table
• It uses Dijkstra’s Shortest Path First algorithm which appears to be processor intensive.
• It sends triggered updates to announce network changes and periodic updates on long
intervals.
• OSPF divides the network into multiple areas & all areas must connect to area 0 which is
the area created for the first time and is the backbone area.
• Every area has a bunch of routers. All routers in an area have the same road map about
their area. The goal is to localize the updates within an area.
• OSPF requires a hierarchical design.
• One area connects to the other area through Area Border Routers (ABR). An ABR has it’s
interfaces in different areas with one interface in area 0 for sure.
• An Autonomous System Border Router (ASBR) is the router sitting at the boundary of
the autonomous system.
• OSPF elects one router to be a Designated Router (DR) & one router to be a Backup DR
(BDR) on multi-access segments.

SECTION 5.1.2 Configuration of OSPF for Customer A sites
Let’s configure OSPF for customer A sites connected to Provider Edge 1 & Provider Edge 3
router respectively.

Up here, the router ospf 1 vrf custa command is starting the OSPF process & also establishes a
VRF for Customer A. We did not use the keyword address-family here because the above
syntax is defined as it is for OSPF.
Then the network is propagated in the OSPF process through the network command.
The redistribute bgp 65000 subnets command redistributes the classless subnet routes from
BGP into OSPF.
After entering into router BGP process, redistributing OSPF routes into BGP with command
redistribute ospf 1.
This vice versa process of redistribution is necessary as BGP takes OSPF routes from 1 OSPF site
and takes them to another OSPF site through Provider Edge routers.
Now, at the Customer Edge A 1 (cea1), we will do the normal OSPF configuration as under:
As we can see in the mid of our configuration, the OSPF neighborship between Provider Edge 1
& Customer Edge 1 has been established. Now, to Provider Edge 3:
And Customer Edge A 2 (cea2) here:

See, the loading is done. We are up with the OSPF neighbors. Obviously, this is the confirmation
time. Let’s check whether the Customer A’s both sites can reach each other! For the purpose,
we can use sh ip route command on both Customer Edges to ensure they receive each other’s
routes.
So, both the sites are receiving each other’s routes, means they can ping each other.

Part 5.2 EIGRP
SECTION 5.2.1 an eye into EIGRP
• Enhanced Interior Gateway Protocol is referred to as hybrid routing protocol because of

its having both distance vector and link state characteristics.
• EIGRP is the only routing protocol that supports backup routes.
• EIGRP also maintains three tables

o Neighbor table
o Topology table
o Routing table
• EIGRP doesn’t send link state packets like OSPF does, it sends traditional distance-vector
updates containing information about the networks plus the cost of reaching them from
the perspective of the advertising router.
• It synchronizes routing tables between neighbors at startup and then sends specific
updates only when topology changes occur.
• This makes EIGRP suitable for large networks. It has a maximum hop count of 255.
• It supports unequal cost load balancing. Actually it combines best of distance vector and
link state protocols.
• It uses a sophisticated composite metric that includes bandwidth, delay, reliability, load
and MTU.
• EIGRP uses Diffusing Update Algorithm (DUAL) for selecting and maintaining the best
path to each remote network.

SECTION 5.2.2 Configuration of EIGRP for Customer C sites
Let’s move on to establishing Customer C’s connectivity. First, to Provider Edge 2:

On Provider Edge 2 above, under EIGRP process, we created a vrf for custc through address-
family command.
Then, it’s the network propagation. And after that, we have to define the autonomous system
through autonomous-system command as it is necessary to mention under creating VRFs.
The no auto-summary command is used not to summarize the connected and propagated
networks. Then it’s the redistribution command with the default K values of EIGRP.
And lastly, under the VRF for Customer C in BGP process, EIGRP is redistributed.
Now, at Customer Edge C 1, we follow the normal EIGRP configuration:
See, we are up with the EIGRP neighborship between Provider Edge 2 & Customer Edge C 1.
Now, its Provider Edge 1:
Customer Edge C 2 here:

Well, the neighbors are up! So, now let’s move towards the confirmation.
We can see both the remote sites now know about each other’s networks.

PART 5.3 Configuration of BGP for Customer B sites

This time we get straight to the configuration of Customer B’s sites as BGP has already been
elaborated above in Episode 2 past 2.1 of the dissertation document.
First to Provider Edge 3:

Here, as we use BGP as PE-CE protocol, we will establish an eBGP neighbor relation with
Customer B sites under VRF custb.
The activate command activates the relation under VRF.
The as-override command helps receive routes with repeated autonomous system numbers. If
this command is not used, BGP won’t pass routes from one site of B to the other site of B as
both the sites of Customer B are in same autonomous system number.
The redistribute connected command redistributes connected network routes into BGP.
Now, at Customer Edge B 1, the normal BGP configuration will follow:
Provider Edge 2:
Customer Edge B 2 here:

Having seen the neighbors up, let’s move to verifications:
So, both the sites are receiving each other’s networks & are done.

Episode 6 Overlapping VPNs or Extranets
Episode 6
Overlapping VPNs or Extranets

PART 6.1 an eye into Overlapping VPNs or Extranets

So far, we peeped into and configured simple VPNs. Talking about Overlapping; it’s a situation
where a site participates in more than one VPN. Simply put, we are creating extranets.
In the context of today’s complex connectivity requirements, where organizations deal with
each other, demand connectivity with each other. Through the use of extranet topology, this is
achievable. Say, the main sites of two different organizations are capable of communicating
directly across the MP-BGP VPN backbone as they import each other’s routes into their VRFs.
The above implementation shows three customers as we have configured separate VPNs for
them. However, the three customers want their head-sites (CEA1, CEB1, and CEC1) only to

communicate with each other. The scenario above shows three customers with their head sites
namely CEA1, CEB1 & CEC2 and their remote sites namely CEA2, CEB2 & CEC2 respectively. It
also shows three different VPNs plus the extranet connectivity among the head sites.
PART 6.2 Configurations of Over-lapping VPNs

Provider Edge 1 S1/1 150.1.1.18/30
Provider Edge2 S1/1 150.1.3.18/30
Provider Edge3 S1/2 150.1.2.18/30
First, we’ll configure Provider Edge 1 router as follows:
Here above, on pedge1 we have configured a overlapping vrf named custabc with route
distinguisher 1:100 participating in multiple sites of A, B, & C.

Command route-target both 1:100 and route-target both 1:10 , will import and export routes
of Customer A site 2 & the of Customer B 1 and Customer C 1.
Then we bound the new VRF custabc to the interface s1/1 with ip vrf forwarding custabc, while
disassociating the vrf custa with it.
Now, the OSPF process is started for the new VRF custabc which neighbors with CEA1 as before,
but this time CEA1 receives the routes from CEA2, CEB1 and CEC1 as intended.
And then the new VRF needs to be distributed in the BGP address family for custabc.
Configuration on Provider Edge 2:
The same configuration is repeated here except that as we are forming neighborship with CEC1
under the new VRF custabc so we have imported and exported routes for both 1:30 (Customer
C) & 1:100 (Customer A1, B1).
And, lastly on Provider Edge 3:

The same configuration is repeated here except that as we are forming neighborship with CEB1
under the new VRF custabc so we have imported and exported routes for both 1:20 (Customer
B) & 1:100 (Customer A1, C1).
And last but not the least, the verification process: we run the most famous sh ip route
command on all the three over-lapped sites i.e., CEA1, CEB1 & CEC1.


And, BRAVO!!! , we are receiving the routes.


Denotations
• Sir Engineer Ahmad Mustufa – B.Sc. Electrical Engineering & CCIP
• MPLS Fundamentals by Luc De Ghein
• CCIP MPLS Study Guide by James Reagan
• MPLS & VPN Architectures by Jim Guichard and Ivan Pepelnjak
• BGP 4 Case Studies by Sam Halabi
• www.knowledgenet.com
• www.cisco.com
• www.tdap.com
Dissertation Brief
Title Implementing Complex MP-BGP Over-Lapping VPNs
Undertaken by M. Shahrukh Baig (0520) & Khurram Aziz Shah (0504)
Supervised by Engineer Ahmad Mustufa
Internal Examiner Sir M. Ateeq
External Examiner
Starting Date November 2008
Completion Date March 2009
Machine used Intel Core 2 Duo @ 2.20 GHz with 1024 MB DDR-II memory
Operating System used Microsoft Windows XP SP2
Softwares used Dynagen 9.2, Dynamips 0.2.7
Router Images used Cisco 3600 series & 2600 series
Protocols used IS-IS, MPLS, BGP, OSPF, EIGRP

Implementing Complex MP-BGP Over-Lapping VPNs

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Implementing Complex MP-BGP Over-Lapping VPNs

Caricato da

Copyright:

Formati disponibili

Department of Computer Science, BZU

M. Shahrukh Baig (0520) | Khurram Aziz Shah (0504)

M. Shahrukh Baig (0520)

Sir Engineer Ahmad Mustufa

Department of Computer Science,

Internal Examiner: Sir M. Ateeq

Chairman: M. Aziz Akhtar

Khurram Aziz Shah

The dissertation study is whole heartedly dedicated to our

Implementing Complex MP-BGP Overlapping VPNs 1

Implementing Complex MP-BGP Overlapping VPNs 2

Router Interface Address

Router Interface Address

Router Interface Address

Router Interface Address

Implementing Complex MP-BGP Overlapping VPNs 3

Router Interface Address

Router Interface Address

This table lists the interface addresses of Customer Edge C devices:

Router Interface Address

Implementing Complex MP-BGP Overlapping VPNs 4

Establishing the Core with IS-IS & MPLS

Implementing Complex MP-BGP Overlapping VPNs 5

PART 1.1 an eye into IS-IS

In the world of IS-IS, a router is known as intermediate system, so it was named as IS to IS

It is a link state routing protocol maintaining

while it is based on SPF algorithm.

Summarization is done on exiting side of area towards backbone.

Hierarchical design of Areas

Implementing Complex MP-BGP Overlapping VPNs 6

IS-IS possesses different routing domains

• L0 describes routing between an IS and an ES.

ISIS advantages over contemporary link state protocols

• ISIS handles updates efficiently

• OSI uses Connectionless Network Protocol Service (CLNS) which is equivalent to IP in

Implementing Complex MP-BGP Overlapping VPNs 7

PART 1.2 Configuring the Core with IS-IS

Implementing Complex MP-BGP Overlapping VPNs 8

The configuration follows:

Implementing Complex MP-BGP Overlapping VPNs 9

Implementing Complex MP-BGP Overlapping VPNs 10

Implementing Complex MP-BGP Overlapping VPNs 11

PART 1.3 an eye into MPLS

The two architectural components of MPLS are:

Forwarding Plane or Data Plane

An MPLS-enabled router switches IP packets instead of forwarding them traditionally. The

Implementing Complex MP-BGP Overlapping VPNs 12

On entry to an MPLS network, the destination IP address of the packet is longest-matched

Implementing Complex MP-BGP Overlapping VPNs 13

Implementing Complex MP-BGP Overlapping VPNs 14

PART 1.4 Configuration of the core with MPLS

Implementing Complex MP-BGP Overlapping VPNs 15

Implementing Complex MP-BGP Overlapping VPNs 16

Implementing Complex MP-BGP Overlapping VPNs 17

Establishing iBGP Neighbor-ships among

Implementing Complex MP-BGP Overlapping VPNs 18

PART 2.1 an eye into BGP

Supports two flavors

Implementing Complex MP-BGP Overlapping VPNs 19

Community - The community attribute is a transitive, optional attribute in the range 0 to

Implementing Complex MP-BGP Overlapping VPNs 20

PART 2.2 Configuration of iBGP Neighborship among Provider Edges

Here it goes at Provider Edge 2 & 3 respectively.