SlideShare a Scribd company logo
Fall 2017
EE 358 Information Theory
Course Project
VPN Routing via MPLS Technique
Ahmad Sameer Mohammad(26), Ahmad Atta Mohammad(30), Hussam Aldeen Ahmad(87), Rafik Hisham(101), Omar
Aldalil(134).
Affiliations (i.e., Electronics and communication department, Alexandria University)
Ahmed3ta@gmail.com
Abstract. Multiprotocol Label Switching (MPLS) networks are the next generation of networks designed to allow
enterprises to create end-to-end circuits across any type of transport medium using any available wide area network
(WAN) technology. Until recent years, enterprises with the need to connect remote offices in locations across the
country were restricted to the limited WAN options that service providers offered—usually frame relay or T1/E1
dedicated links.
MPLS VPNs combine the power of MPLS and the Border Gateway Protocol (BGP) routing protocol. MPLS is used to
forward packets over the provider’s network backbone, and BGP is used for distributing routes over the backbone.
1. Introduction
VPLS, MPLS VPNs, MPLS and VPNs are terms often used interchangeably, but erroneously so. Confusion about
MPLS VPNs stems from the multitudinous words that vendors and marketers often use to describe the same service. So
what actually is an MPLS VPN?
"MPLS" and "VPN" are two different technology types. Multiprotocol Label Switching (MPLS) is a standards-based
technology used to speed up the delivery of network packets over multiple protocols – such as the Internet Protocol (IP),
Asynchronous Transport Mode (ATM) and frame relay network protocols. A virtual private network (VPN) uses shared
public telecom infrastructure, such as the Internet, to provide secure access to remote offices and users in a cheaper way
than an owned or leased line. VPNs are secure because they use tunneling protocols and procedures such as Layer Two
Tunneling Protocol (L2TP). With those definitions understood, an MPLS VPN is a VPN that is built on top of an MPLS
network, usually from a service provider, to deliver connectivity between enterprise office locations. The terms "MPLS
IP VPN," "MPLS VPN" and "MPLS-based VPN" can be used synonymously. Understanding these terms are important
when mastering MPLS VPN fundamentals.
2. Background/Related Work
MPLS Technique:
In this section we will talk about the mechanisms of MPLS and how it works.
First, data carried over MPLS network has one or more MPLS headers applied in order to transport it
across the network. The MPLS header structure is shown in Figure 1.
It contains those fields:
1. A 20-bit label value. MPLS pack-
ets are forwarded on the basis of this
field. This value is used as an index
into the MPLS forwarding table.
2. Traffic Class (TC) field (3 bits).
Previously known as the EXP bits,
convey the Class of Service to be ap-
plied to the packet. For example, LSRs and LERs can use these bits to determine the queue into which the
packet should be placed. Note that in some cases the MPLS label value also determines the queuing behavior
applied to the packet.
3. Bottom of stack bit (S-bit). MPLS headers can be stacked. The S-bit is set on the header of the MPLS
packet at the bottom of the stack.
4. Time-to-live (TTL) field. This is used to avoid forwarding loops and can also be used for path-tracing.
The value is decremented at each hop and the packet is discarded should the value reach zero.
But actually before dig-
ging into how it works and
how the header is added,
let’s first define the MPLS
network Architecture Fig-
ure 2 and see its compo-
nents.
Figure 2: Very simple MPLS network architecture
Figure 1: MPLS Header
1. Label Edge Router (LER): It exists on the both edges of the network on the entry and exit points of
the network:
a. Ingress Label Edge Router (ILER): It exists at the beginning of an MPLS network and is an en-
try point where the data packet originates from its source. This edge router imposes label
(PUSH) and forward packets to destination through the domain. This ingress edge router ini-
tiates packet-forwarding process in MPLS core network.
b. Egress Label Edge Router (ELER): It exists at the end of an MPLS network and is an exit point
where the data packet reaches its destination. This edge router performs label disposition or
removal (POP) and forwards IP packet to destination. It disposes label from the arrived
packet only when bottom-of-stack indicator identifies if the encountered label is bottom la-
bel of the stack or not.
2. Label Switch Router (LSR): This router receives a labeled packet, swaps it with an outgoing one, and
forwards the new packet to an appropriate interface. Depending on its location in MPLS domain,
this router performs label disposition (removal, POP), label imposition (addition, PUSH) or label
swapping (replacing the top label in a stack with a new outgoing label value). When the data stream
(files or multimedia traffic) arrives from the access network to the MPLS core, it is segregated into
separate FEC in this router. As an acknowledgement of label bindings, LSR creates entries in Label In-
formation Base. This table comprises of I/O ports and I/O port labels indicating the label-FEC map-
ping.
3. Label Switch Path (LSP): LSP is the path which the packet takes to reach its destination through an
MPLS-enabled network. The path is unidirectional so this allows packets to be switched from one
edge to the other by passing through several intermediate switch routers. Every network location
needs LSPs to be established for data transfer. For example, packet data from LER1 traverses among
several intermediate nodes to LER2 using LSP1, then another path LSP2 is set out for packet transfer
to other end directly, which is the shortest path to arrive the destination. However, path switching is
derived from IGP routing information and may diverge from Interior Gateway Protocol preferred
path to the target network.
How MPLS works
As a packet enters ingress router, this ingress LER assigns labels to the packets for data transmission
through the network. The labels in MPLS header are inserted into data packet that has to be transmitted.
These fixed-length labels carry the information; all the subsequent routing switches perform packet for-
warding based only on those labels they never look as far as the IP header.
As each node forwards the packet, it swaps current label for the most appropriate label to the subse-
quent node to route the packet. Finally, the egress router removes the label(s) and forwards the original IP
packet toward its final destination. This mechanism enables very-high-speed packet switching through the
core MPLS domain.
VPN
Traditional router-based networks connect customer sites through routers connected via dedicated
point-to-point links (leased lines).VPNs replace dedicated point-to-point links with emulated
point-to-point links that share common infrastructure. Customers use VPNs primarily to reduce their op-
erational costs.
Advantages of VPNs
• Cost savings: Replacing expensive long-distance leased lines with much less expensive dedicated
connection to the service provider (DSL, fiber). And: Offload-
ing support costs
• Scalabil-
ity: Add-
ing a new branch office is fast and simple by adding an additional link to the ISP (adding a site to the
customer VPN).
• Improved security: Use of encryption protocols and authentication
• Better performance: More high-capacity data service options can be used (cheaper bandwidth).
• Flexibility and reliability: Wide spread availability of fiber, DSL, and other broadband options.
And: Using more than one ISP
• Greater access to mobile users: Increases productivity and responsiveness for employees working
from home or on business trips.
VPN Terminology
Provider Edge (PE) Devices
Provider Edge (PE) Devices
Provider network (P-network): The service
provider infrastructure used to provide VPN services
Customer network (C-network): The part of the
network still under customer control
Customer site: A contiguous part of the customer
network (can encompass many physical locations)
Provider (P) Core DevicesCustomer Site
Large Customer Site
Customer Premises
Equipment (CPE) or
Router
CPE
RoutVirtual
Other
Customer
Virtual
Customer Site
Large Customer Site
Provider (P) Core Devices
Customer Premises
Equipment (CPE) or
Customer Edge (CE)
Router
CPE Router
Virtual
Circuit 2
Other
Customer
Routers
Virtual
Circuit 1
Figure 3: VPN Simple Model
Figure 4: VPN Terminology
VPNs
Overlay VPN Peer-to-Peer VPN
Layer 2 VPN Layer 3 VPN
ACLs
(Shared router)
MPLS VPN
Split routing
(dedicated router)
X.25
Frame Relay
ATM
GRE
DMVPN
IPsec
GET VPN
L2TPv3
SSL VPN
P device: The device in the provider network with no customer connectivity
PE device: The device in the provider network to which the customer devices are connected
CE device: The device in the customer network that links to the provider network (sometimes also
called CPE)
PE-CE link: A link between a PE router and a CE router.
VPN Models
VPN services can be offered based on two major models:
• Overlay model, in which the service provider provides virtual point-to-point links between
customer sites
• Peer-to-peer model, in which the service provider participates in the customer routing
Overlay Implemntation techniques
Overlay Layer 2 VPN
- The service provider establishes Layer 2 VCs between customer sites.
- The customer is responsible for all higher layers.
Overlay layer 3 VPN
The service provider infrastructure appears as point-to-point links to the customer.
The service provider does not see customer routes and is responsible only for providing the point-to-
point transport of customer data.
Layer 3 VPN – IP tunneling
- Routing protocols run directly between customer routers.
- GRE is simple (and quicker).
Figure 5: VPN Models
- IPsec provides authentication and security.
Layer 2 VPN – Layer 2 forwarding
- Transparent tunneling of Layer 2 over IP
 Over lay Layer 2, VPN is implemented with IP-over-Frame Relay or ATM tunnels:
- The service provider establishes Layer 2 VCs between customer sites.
- The customer is responsible for all higher layers.
 Over lay Layer 3, VPN is implemented with IP-over-IP tunnels (GRE):
- Tunnels are established with GRE (Generic Routing Encapsulation).
- Tunnel interfaces are point-to-point.
- Enables dynamic routing and multicast
- Runs GRE over IPsec to secure tunnel payload
 Over lay Layer, 3 VPN is implemented with IP-over-IP tunnels (DMVPN):
- Tunnels are established with mGRE.
- Tunnel interfaces are point-to-multipoint.
- Enables dynamic routing and multicast
- Runs mGRE over IPSec to secure tunnel payload
 Over lay Layer 3, VPN is implemented with IP-over-IP tunnels (IPSec):
- Tunnels are established with IPsec (tunnel mode).
- Enables static routing (no multicast)
- Secures payload
 Over lay Layer 3, L2TPv3 is used as a tunneling mechanism to deploy Layer 2 transparent services
over IP:
- L2TPv3 includes support for multiple Layer 2 encapsulations, including 802.1Q VLAN, QinQ, and
Ethernet.
 Over lay Layer 3, SSL VPN enables remote-access connectivity from almost any Internet-enabled
location:
- Easy integration of the SSL VPN gateway into a shared MPLS network
Peer-to-Peer VPNs: Implementation Techniques
- PE-CE routing information is exchanged between CE and PE routers.
 Peer-to-Peer VPN: ACLs (Shared Router)
- POP router carries all customer routes.
- Isolation between customers is achieved with the use of ACLs (packet filters) on PE-to-CE interfaces.
 Peer-to-Peer VPN: Split Routing (Dedicated Router)
- The P router contains all customer routes.
- Each customer has a dedicated PE router that carries only its routes.
- Isolation between customers is achieved through the lack of routing information on the PE router.
 GET VPN:
- Does not use tunnels, behaves almost like transport mode Ipsec
- Large-scale solution accommodating multicast
- Uses group security association and shared encryption key
- Centralized policy and key server with periodic rekeying
 MPLS VNP
- CE routers route traffic to PE routers.
- Each customer has its own isolated routing table instance on PE router.
- P routers do not have customer route information.
- Label switching is enabled in service provider core.
Benefits of VPN Implementations
 Overlay VPN:
- Well-known and easy to implement
- Service provider does not participate in customer routing.
- Customer network and service provider network are well isolated.
 Peer-to-peer VPN:
- Guarantees optimum routing between customer sites
- Easier to provision an additional VPN
- Only sites provisioned, not links between them
Drawbacks of VPN Implementations
 Overlay VPN:
- Implementing optimum routing requires a full mesh of VCs.
- VCs have to be provisioned manually.
- Bandwidth must be provisioned on a site-to-site basis.
- Overlay VPNs always incur encapsulation overhead (GRE or IPsec).
 Peer-to-peer VPN:
- The service provider participates in customer routing. Filters should be applied to customer
links.
- The service provider becomes responsible for customer convergence.
- PE routers carry all routes from all customers.
- A secure environment must be provided for customers.
- Complex configuration
- The service provider needs detailed IP routing knowledge.
3. MPLS VPN
Why MPLS VPN
In the MPLS VPN model, the best features of the overlay and point-to-point models are implemented.
An MPLS-enabled core and edge network provides a very fast and efficient data switching environ-
ment based on MPLS labels.
PE routers exchange routing information with customer CE routers and use separate isolated routing
tables for each customer. Special routing protocol contexts are used for route exchange between PE and
CE routers.
Routes are then exchanged between PE devices using the Multiprotocol BGP (MP-BGP) routing algo-
rithm. For scalability reasons, service provider core routers do not have any customer routing information.
PE routers label packets with MPLS labels and P routers use these labels for fast label-switching packets.
a. Implementation
MPLS Architecture
In the MPLS VPN architecture, the edge routers carry customer routing information, providing optimal routing for
traffic that belongs to the customer for inter-site traffic. The MPLS-based VPN model also accommodates customers
who use overlapping address spaces, unlike the traditional peer-to-peer model, in which optimal routing of customer
traffic required the provider to assign IP addresses to each of its customers (or the customer to implement Network Ad-
dress Translation [NAT]) to avoid overlapping address spaces.
MPLS VPN is an implementation of the peer-to-peer model; the MPLS VPN backbone and customer sites exchange
Layer 3 customer routing information, and data is forwarded between customer sites using the MPLS-enabled service
provider IP backbone.
The MPLS VPN domain, like the traditional VPN, consists of the customer network and the provider network. The
MPLS VPN model is very similar to the dedicated provider edge (PE) router model in a peer-to-peer VPN implementa-
tion. However, instead of deploying a dedicated PE router per customer, customer traffic is isolated on the same PE rout-
er that provides connectivity into the service provider network for multiple customers.
In the MPLS VPN implementation, the PE router performs multiple functions. The PE router must first be capable of
isolating customer traffic if more than one customer is connected to the PE router. Each customer, therefore, is assigned
an independent routing table (virtual routing table or virtual routing and forwarding [VRF] table) similar to a dedicated
PE router in the initial peer-to-peer discussion. Routing across the service provider backbone is performed using a rout-
ing process in the global routing table. P routers provide label switching between PE routers and are unaware of VPN
routes. CE routers in the customer network are not aware of the P routers, and thus the internal topology of the service
provider network is transparent to the customer. And to enable scaling the networkto a large number of customer VPNs,
Multiprotocol Border Gateway Protocol (MP-BGP) isconfigured between PE routers to carry customer routes.
Figure 6: Simple VPN Architecture
The P routers are responsible only for label switching of packets. They do not carry VPN routes and do not participate
in MPLS VPN routing. The PE routers exchange IPv4 routes with connected CE routers using individual routing proto-
col contexts. To enable scaling the network to a large number of customer VPNs, Multiprotocol Border Gateway Proto-
col (MP-BGP) is configured between PE routers to carry customer routes.
Virtual Routing and Forwarding tables (VRFs)
The global routing table (or forwarding in case of
Layer 2 switching) is not the same as the VRF as the
global interface includes only the IPV4 or IPV6 infor-
mation (or MAC addresses per interface in case of
Layer 2 switching) and only one global
routing table can exist in a single router.
The VRFs instead can contain more infor-
mation as explained next and more than one
VRF can coexist in the same router.
The VRF contains an IP routing table that is analo- gous to the global IP
routing table, a Cisco Express Forwarding
table, a list of interfaces that are part of the
VRF, and a set of rules defining routing
protocol exchange with attached CE routers (routing protocol contexts). In addition, the VRF also contains VPN identifi-
ers and VPN membership information (route distinguisher [RD] and route target [RT] are covered in the next section).
The interface that is part of the VRF must support Cisco Express Forwarding switching. The number of interfaces that
can be bound to a VRF is limited only by the number of interfaces on the router, and a single interface (logical or physi-
cal) can be associated with only one VRF.
In the MPLS VPN routing model, the PE router provides isolation between customers using VRFs. However, this in-
formation must be carried between PE routers to enable data transfer between customer sites via the MPLS VPN back-
bone. The PE router must be capable of implementing processes that enable overlapping address spaces in connected
customer networks.
The PE router must also learn these routes from attached customer networks and propagate this information using the
shared provider backbone. This is done by the association of an RD per virtual routing table on a PE router.
MP-BGPV4
The next design decision to be made is the choice of the routing protocol running between PE routers. Given that the
total number of customer routes is expected to be very large, the only well-known protocol with the required scalability
is Border Gateway Protocol version 4 (BGP4). In fact, BGP4 is used in the MPLS VPN architecture to transport custom-
er routes directly between PE routers. MPLS VPN architecture differs in an important way from traditional peer-to-peer
VPN solutions: MPLS VPNs support overlapping customer address spaces.
MP-BGP is also responsible for the assignment of a VPN label. Packet forwarding in an MPLS VPN mandates that
the router specified as the next hop in the incoming BGP update is the same router that assigns the VPN label. An MP-
BGP session between PE routers in a single BGP AS is called a Multiprotocol Internal Border Gateway Protocol (MP-
IBGP) session and follows rules as in the implementation of IBGP with regards to BGP attributes. If the VPN extends
beyond a single AS, VPNv4 routes will be exchanged between autonomous systems at the AS boundaries using a Multi-
protocol External Border Gateway Protocol (MP-EBGP) session.
Route Distinguisher
With the deployment of a single routing protocol (that is, BGP4) exchang-
ing all customer routes between PE routers, an important issue arises: how
can BGP4 propagate several identical prefixes, belonging to different cus-
tomers, between PE routers? The only solution to this dilemma is the expan-
sion of customer IP prefixes with a unique prefix that makes them
unique even if they had previously overlapped. A 64- bit prefix
Figure 7: Explaining VRFs
Figure 8: RD Header
called the route distinguisher (RD) is used in MPLS VPNs to convert non-unique 32-bit customer addresses into 96-bit
unique addresses that can be transported between PE routers.
An RD is a 64-bit unique identifier that is prepended to the 32-bit customer prefix or route learned from a CE router,
which makes it a unique 96-bit address that can be transported between the PE routers in the MPLS domain. Thus, a
unique RD is configured per VRF on the PE router. The resulting address, which is 96 bits total (32-bit customer prefix
plus 64-bit unique identifier or RD), is called a VPNv4 address.
VPNv4 addresses are exchanged only between PE routers; they are never used between CE routers. Between PE rout-
ers, BGP must therefore support the exchange of traditional IPv4 prefixes and the exchange ofVPNv4 prefixes. A BGP
session between PE routers is therefore called a Multiprotocol Border Gateway Protocol (MP-BGP) session. The format
of an RD is shown in the figure. An RD can be of two formats. If the provider does not have a BGP autonomous system
(AS) number, the IP address format can be used, and if the provider does have an AS number, the AS number format can
be used.
RD process flow
- Step 1: The CE router sends an IPv4 routing update to the PE router
- Step 2: The PE router prepends a 64-bit RD to the IPv4 routing update, resulting in a globally unique 96-bit VPNv4 prefix.
- Step 3: The VPNv4 prefix is propagated via an MP-IBGP session to other PE routers.
- Step 4: The receiving PE routers strip the RD from the VPNv4 prefix, resulting in an IPv4 prefix. RD is used to match the proper VRF routing
table.
- Step 5: The IPv4 prefix is forwarded to other CE routers within an IPv4 routing update.
Route Target (RT)
Route targets (RTs) were introduced into the MPLS VPN architecture to support identifying a site that participates in
more than one VPN. RTs are additional identifiers used in the MPLS VPN that identify the VPN membership of the
routes learned from that particular site. RTs are implemented by the use of extended BGP communities in which the
higher-order 16 bits of the BGP extended community (64 total bits) is encoded with a value corresponding to the VPN
membership of the specific site. When a VPN route learned from a CE router is injected into VPNv4 BGP, a list of VPN
route target extended community attributes is associated with it.
When implementing complex VPN topologies, such as extranet VPN, Internet access VPNs, network management
VPN, and so on, using MPLS VPN technology, the RT plays a pivotal role. A single prefix can be associated to more
than one export route target when propagated across the MPLS VPN network. The RT can, as a result, be associated to
sites that might be a member of more than one VPN.
VPN Label
The VPN label (4 bytes) is assigned for each prefix that is learned from the IGP process of the connected CE router
within a VRF by the MP-BGP process of the PE router. MP-BGP running in the service provider MPLS domain thus
carries the VPNv4 prefix (IPv4 prefix with prepended RD) in addition to the BGP route target extended community.
A simple MPLS-oriented approach to MPLS VPN packet forwarding across the MPLS VPN backbone would be to
label the customer packet with the label assigned by Label Distribution Protocol (LDP) for the egress PE router. The core
routers consequently would never see the customer IP packet; instead, the core routers would see just a labeled packet
targeted toward the egress PE router. The core routers would perform simple label-switching operations, eventually de-
livering the customer packet to the egress PE router. Unfortunately, the customer IP packet would contain no VPN or
VRF information that could be used to perform VRF lookup on the egress PE router. The egress PE router would not
know which VRF to use for packet lookup and would need to drop the packet.
An MPLS label stack can be used to tell the egress PE router what to do with the VPN packet. When using the label
stack, the ingress PE router labels the incoming IP packet with two labels. The top label in the stack is the LDP label for
the egress PE router; this label guarantees that the packet will traverse the MPLS VPN backbone and arrive at the egress
PE router. The second label in the stack is assigned by the egress PE router, and tells how to forward the incoming VPN
packet. The second label could point directly toward an outgoing interface, in which case the egress PE router would
perform label lookup only on the VPN packet. The second label could also point to a VRF, in which case the egress PE
router would first perform a label lookup to find the target VRF, and then perform an IP lookup within the VRF.
IGP scoop
The next hops on PE routers must not be advertised in the BGP process but must be learned from the IGP for MPLS
VPN implementation. The VPN label is depicted by the entries VI and V2 in the figure.
The designers of MPLS VPN technology were faced with these routing requirements:
• CE routers should not be MPLS VPN-aware; CE routers should run standard IP routing software.
• PE routers must support MPLS VPN services and traditional Internet services.
To make the MPLS VPN solution scalable, P routers must not participate in customer VPN routing. P routers use only
label switching.
Traffic flow
Penultimate hop popping (PHP) is the
removal of the top label in the stack on
the hop prior to the egress router. PHP
can be performed in frame-based MPLS
networks. In these networks, the last P router in
the label-switched path (LSP) tunnel pops the LDP
label (as previously requested by the egress
PE router through LDP), and the PE
router receives a labeled packet that con-
tains only the VPN label. In most cases, a
single label lookup performed on that
packet in the egress PE router is enough
to forward the packet toward the CE
router. The full IP lookup through the
forwarding information base (FIB) is performed only once, in the ingress PE router, even without PHP.
Summary
An MP-BGP update exchange between PE routers contains these elements:
• VPNv4 address
• Extended BGP communities (for example, RTs are required)
• Label used for VPN packet forwarding
• Mandatory BGP attributes (for example, AS path). Optionally, the MP-BGP update can contain any other BGP at-
tribute, such as local preference, multi-exit discriminator (MED), or standard BGP community.
The PE routers receiving MP-BGP updates import the incoming VPNv4 routes into their VRFs based on RTs attached
to the incoming routes and based on import RTs configured in the VRFs. The VPNv4 routes installed in the VRFs are
converted to IPv4 routes and then propagated to the CE routers.
The RTs that are attached to a route and the import RTs that are configured in the VRF direct the propagation of the
routes to the CE router. Incoming VPNv4 routes are imported into VRFs on the receiving PE router only if at least one
RT attached to the route matches at least one import RT that is configured in the VRF.
Figure 9: MPLS Backbone Traffic flow
b. Simulation Scenarios and Testbeds
Requirements
(a) GNS3 Simulator to implement and run MPLS L3
VPN
(b) 4GB RAM, in minimum, installed in the laptop/ PC
running GNS3
(c) Cisco IOS Image c7200
(d) configuring all the networks with scalability in
mind
Figure 10:the MPLS L3VPN Topology implemented
using GNS3
All configurations are written in the Global Configu-
ration Mode
Configure a loopback interface to use later as
router id
PE Router (R2):
interface Loopback0
ip address 2.2.2.2 255.255.255.255
P Router (R3):
interface Loopback0
ip address 3.3.3.3 255.255.255.255
PE Router (R4):
interface Loopback0
ip address 4.4.4.4 255.255.255.255
Customer Router (R1) 1st
bransh
interface Loopback0
ip address 1.1.1.1 255.255.255.255
Customer Router (R5) 2nd
bransh
interface Loopback0
ip address 5.5.5.5 255.255.255.255
Configure IP addresses:
R2:
interface GigabitEthernet0/0
ip address 192.168.23.2 255.255.255.0
interface GigabitEthernet1/0
ip address 192.168.12.2 255.255.255.0
R1:
interface GigabitEthernet0/0
ip address 192.168.12.1 255.255.255.0
interface GigabitEthernet0/0
ip address 192.168.45.5 255.255.255.0
R3:
interface GigabitEthernet0/0
ip address 192.168.23.3 255.255.255.0
interface GigabitEthernet1/0
ip address 192.168.34.3 255.255.255.0
R4:
interface GigabitEthernet0/0
ip address 192.168.45.4 255.255.255.0
interface GigabitEthernet1/0
ip address 192.168.34.4 255.255.255.0
R5:
interface GigabitEthernet0/0
ip address 192.168.45.5 255.255.255.0
:Configure LDP
R2(config)#mpls ldp router-id Loopback0
R3(config)#mpls ldp router-id Loopback0
R4(config)#mpls ldp router-id Loopback0
Enabling MPLS on interfaces connected in the
ISP network:
R2:
interface GigabitEthernet0/0
mpls ip
R3:
interface GigabitEthernet1/0
mpls ip
interface GigabitEthernet0/0
mpls ip
R4:
interface GigabitEthernet1/0
mpls ip
Configure backbone network IGP
R2:
router ospf 1
log-adjacency-changes
network 2.2.2.2 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
R3:
router ospf 1
log-adjacency-changes
network 3.3.3.3 0.0.0.0 area 0
network 192.168.23.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
R4:
router ospf 1
log-adjacency-changes
network 4.4.4.4 0.0.0.0 area 0
network 192.168.34.0 0.0.0.255 area 0
Configure MP-BGP for vpnv4 route exchange be-
tween PE routers
R4:
router bgp 1
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended
exit-address-family
R2:
router bgp 1
bgp log-neighbor-changes
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-community extended
exit-address-family
Configure Customer VRFs:
On both R2 and R4 (the provider edges):
ip vrf customer1
rd 100:1
route-target export 1:100
route-target import 1:100
Associating the VRFs with customer interfaces:
R2:
interface GigabitEthernet1/0
ip vrf forwarding customer1
ip address 192.168.12.2 255.255.255.0
R4:
interface GigabitEthernet0/0
ip vrf forwarding customer1
ip address 192.168.45.4 255.255.255.0
Setting Up Routing For the Client
R5:
router eigrp 100
network 5.0.0.0
network 192.168.45.0
no auto-summary
R1:
router eigrp 100
network 1.0.0.0
network 192.168.12.0
no auto-summary
Redistribute EIGRP into BGP
router bgp 1
address-family ipv4 vrf customer1
redistributing the eigrp routes to bgp:
redistribute eigrp 100
exit-address-family
Redistribute BGP into EIGRP
router eigrp 1
address-family ipv4 vrf customer1
redistribute bgp 1 metric 1 1 1 1 1
network 192.168.12.0
no auto-summary
autonomous-system 100
exit-address-family
R4
Redistribute BGP into EIGRP
router eigrp 1
address-family ipv4 vrf customer1
redistribute bgp 1 metric 1 1 1 1 1
network 192.168.45.0
no auto-summary
autonomous-system 100
exit-address-family
Redistribute EIGRP into BGP
router bgp 1
address-family ipv4 vrf customer1
redistribute eigrp 100
exit-address-family
4. Conclusions
The most scalable method of exchanging customer routes across a provider network is the use of an MP-BGP
between PE routers.
RDs transform non-unique 32-bit addresses into 96-bit unique addresses.
RTs are used to identify VPN membership in overlapping topologies.
• In MPLS VPNs:
CE routers run standard routing protocols to the PE routers.
PE routers provide the VPN routing and services via MP-BGP.
P routers do not participate in VPN routing, and only provide core IGP backbone routing to the PE routers.
• PE routers forward packets across the MPLS VPN backbone using label
5. Future Work
a. VPNv6 on the MPLS:
In this overview we only used the IPv4 of the traffic data, the implementation of IPv6 on the same way
can be more challenging
b. Layer 2 MPLS VPN:
We worked only on the Layer 3 MPLS VPN, and we look forward to see the results on the Layer 2
MPLS VPN.
c. Other vendors VPN MPLS:
At the start Cisco Studying material were available, so we only worked on the environment that is suit-
able for Cisco, also other vendors can be tricky to find academic material for, we are keen to see the
differences of other vendors in concept and implementation.
d. Security point of view:
We didn’t study the subject from the security perspective, so it would be a great benefit to study it se-
curity-wise.
6. References
[1] Cicso SPNGN1, SPNGN2, SPCORE material
[2] MPLS Enabled applications, Third edition.
[3] MPLS Virtual Private Networks, Luca Cittadini, Giuseppe Di Battista, Maurizio Patrignani..
[4] Implementation of MPLS L3VPN using GNS3, Akashy, Pooja Ahlawat
Contents
1. Introduction .............................................................................................................................................................1
2. Background/Related Work ......................................................................................................................................2
MPLS Technique: ........................................................................................................................................................2
How MPLS works........................................................................................................................................................3
VPN..............................................................................................................................................................................4
Advantages of VPNs ................................................................................................................................................4
VPN Terminology....................................................................................................................................................4
VPN Models.............................................................................................................................................................5
3. MPLS VPN..............................................................................................................................................................8
Why MPLS VPN..........................................................................................................................................................8
a. Implementation ...................................................................................................................................................9
MPLS Architecture ..................................................................................................................................................9
Virtual Routing and Forwarding tables (VRFs) .....................................................................................................10
MP-BGPV4............................................................................................................................................................10
b. Simulation Scenarios and Testbeds...................................................................................................................13
4. Conclusions ...........................................................................................................................................................15
5. Future Work...........................................................................................................................................................15
6. References .............................................................................................................................................................15
Contents .........................................................................................................................................................................16
Figure 1: MPLS Header ...................................................................................................................................................2
Figure 2: Very simple MPLS network architecture..........................................................................................................2
Figure 3: VPN Simple Model...........................................................................................................................................4
Figure 4: VPN Terminology ............................................................................................................................................4
Figure 5: VPN Models .....................................................................................................................................................5
Figure 6: Simple VPN Architecture .................................................................................................................................9
Figure 7: Explaining VRFs ............................................................................................................................................10
Figure 8: RD Header ......................................................................................................................................................10
Figure 9: MPLS Backbone Traffic flow.........................................................................................................................12
Figure 10:the MPLS L3VPN Topology implemented using GNS3 ...............................................................................13

More Related Content

What's hot

Ch 18 intro to network layer - section 2
Ch 18   intro to network layer - section 2Ch 18   intro to network layer - section 2
Ch 18 intro to network layer - section 2
Hossam El-Deen Osama
 
QOS of MPLS
QOS of MPLSQOS of MPLS
QOS of MPLS
IOSR Journals
 
Multi-Protocol Label Switching
Multi-Protocol Label SwitchingMulti-Protocol Label Switching
Multi-Protocol Label Switchingseanraz
 
International Journal of Engineering Research and Development (IJERD)
International Journal of Engineering Research and Development (IJERD)International Journal of Engineering Research and Development (IJERD)
International Journal of Engineering Research and Development (IJERD)
IJERD Editor
 
Ch 18 intro to network layer - section 3
Ch 18   intro to network layer - section 3Ch 18   intro to network layer - section 3
Ch 18 intro to network layer - section 3
Hossam El-Deen Osama
 
Ch 18 intro to network layer - section 1
Ch 18   intro to network layer - section 1Ch 18   intro to network layer - section 1
Ch 18 intro to network layer - section 1
Hossam El-Deen Osama
 
Tunneling in MPLS
Tunneling in MPLSTunneling in MPLS
Tunneling in MPLS
Shehzad Amanat
 
Ch 19 Network-layer protocols Section 1
Ch 19  Network-layer protocols Section 1Ch 19  Network-layer protocols Section 1
Ch 19 Network-layer protocols Section 1
Hossam El-Deen Osama
 
CS6551 COMPUTER NETWORKS
CS6551 COMPUTER NETWORKSCS6551 COMPUTER NETWORKS
CS6551 COMPUTER NETWORKS
Kathirvel Ayyaswamy
 
QSpiders - Good to Know Network Concepts
QSpiders - Good to Know Network ConceptsQSpiders - Good to Know Network Concepts
QSpiders - Good to Know Network Concepts
Qspiders - Software Testing Training Institute
 
Ch4 net layer network
Ch4 net layer networkCh4 net layer network
Ch4 net layer network
cairo university
 
BETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORK
BETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORKBETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORK
BETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORK
cscpconf
 
MPLS (Multiprotocol Label Switching)
MPLS (Multiprotocol Label Switching)MPLS (Multiprotocol Label Switching)
MPLS (Multiprotocol Label Switching)
Netwax Lab
 
Unit 4 - Network Layer
Unit 4 - Network LayerUnit 4 - Network Layer
Unit 4 - Network Layer
Chandan Gupta Bhagat
 
Final several design issues at network layer
Final several design issues at network layerFinal several design issues at network layer
Final several design issues at network layerKashyap Davariya
 
Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2
Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2
Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2
csandit
 

What's hot (20)

Ch 18 intro to network layer - section 2
Ch 18   intro to network layer - section 2Ch 18   intro to network layer - section 2
Ch 18 intro to network layer - section 2
 
QOS of MPLS
QOS of MPLSQOS of MPLS
QOS of MPLS
 
Multi-Protocol Label Switching
Multi-Protocol Label SwitchingMulti-Protocol Label Switching
Multi-Protocol Label Switching
 
International Journal of Engineering Research and Development (IJERD)
International Journal of Engineering Research and Development (IJERD)International Journal of Engineering Research and Development (IJERD)
International Journal of Engineering Research and Development (IJERD)
 
Ch 18 intro to network layer - section 3
Ch 18   intro to network layer - section 3Ch 18   intro to network layer - section 3
Ch 18 intro to network layer - section 3
 
Chapter7 l1
Chapter7 l1Chapter7 l1
Chapter7 l1
 
Ch 18 intro to network layer - section 1
Ch 18   intro to network layer - section 1Ch 18   intro to network layer - section 1
Ch 18 intro to network layer - section 1
 
Tunneling in MPLS
Tunneling in MPLSTunneling in MPLS
Tunneling in MPLS
 
Ch 19 Network-layer protocols Section 1
Ch 19  Network-layer protocols Section 1Ch 19  Network-layer protocols Section 1
Ch 19 Network-layer protocols Section 1
 
CS6551 COMPUTER NETWORKS
CS6551 COMPUTER NETWORKSCS6551 COMPUTER NETWORKS
CS6551 COMPUTER NETWORKS
 
QSpiders - Good to Know Network Concepts
QSpiders - Good to Know Network ConceptsQSpiders - Good to Know Network Concepts
QSpiders - Good to Know Network Concepts
 
Ch4 net layer network
Ch4 net layer networkCh4 net layer network
Ch4 net layer network
 
BETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORK
BETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORKBETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORK
BETTER SCALABLE ROUTING PROTOCOL FOR HYBRID WIRELESS MESH NETWORK
 
MPLS ppt
MPLS pptMPLS ppt
MPLS ppt
 
MPLS (Multiprotocol Label Switching)
MPLS (Multiprotocol Label Switching)MPLS (Multiprotocol Label Switching)
MPLS (Multiprotocol Label Switching)
 
Unit 4 - Network Layer
Unit 4 - Network LayerUnit 4 - Network Layer
Unit 4 - Network Layer
 
Vp ns
Vp nsVp ns
Vp ns
 
Final several design issues at network layer
Final several design issues at network layerFinal several design issues at network layer
Final several design issues at network layer
 
Cna
CnaCna
Cna
 
Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2
Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2
Performance Evaluation of a Layered WSN Using AODV and MCF Protocols in NS-2
 

Similar to VPN Using MPLS Technique

Mpls
MplsMpls
J010136172
J010136172J010136172
J010136172
IOSR Journals
 
MPLS-jpl.ppt
MPLS-jpl.pptMPLS-jpl.ppt
MPLS-jpl.ppt
demon667714
 
Auto-Bandwidth Allocation in Multicast Aware VPLS Netowrks
Auto-Bandwidth Allocation in Multicast Aware VPLS NetowrksAuto-Bandwidth Allocation in Multicast Aware VPLS Netowrks
Auto-Bandwidth Allocation in Multicast Aware VPLS NetowrksAllan Kweli
 
I41026670
I41026670I41026670
I41026670
IJERA Editor
 
G010314853
G010314853G010314853
G010314853
IOSR Journals
 
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...ijceronline
 
Switching systems lecture8 mpls
Switching  systems lecture8 mplsSwitching  systems lecture8 mpls
Switching systems lecture8 mpls
Jumaan Ally Mohamed
 
Research paper ( MPLS as a Software-Defined Network )
Research paper ( MPLS as a Software-Defined Network )Research paper ( MPLS as a Software-Defined Network )
Research paper ( MPLS as a Software-Defined Network )
Chinmay Upasani
 
Digital network lecturer3
Digital network  lecturer3Digital network  lecturer3
Digital network lecturer3
Jumaan Ally Mohamed
 
V25112115
V25112115V25112115
V25112115
IJERA Editor
 
MPLS_SDN.pdf
MPLS_SDN.pdfMPLS_SDN.pdf
MPLS_SDN.pdf
mohamed590260
 
MPLS
MPLSMPLS
Next generation-ptn-white-paper
Next generation-ptn-white-paperNext generation-ptn-white-paper
Next generation-ptn-white-paperslahiri00
 
International Journal of Engineering Research and Development
International Journal of Engineering Research and DevelopmentInternational Journal of Engineering Research and Development
International Journal of Engineering Research and Development
IJERD Editor
 
Mpls Traffic Engineering ppt
Mpls Traffic Engineering pptMpls Traffic Engineering ppt
Mpls Traffic Engineering pptNitin Gehlot
 
Computer Networking Tasks.docx
Computer Networking Tasks.docxComputer Networking Tasks.docx
Computer Networking Tasks.docx
UsamaAliLone3
 
MPLS
MPLSMPLS
Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...
Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...
Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...
CSCJournals
 

Similar to VPN Using MPLS Technique (20)

Mpls
MplsMpls
Mpls
 
J010136172
J010136172J010136172
J010136172
 
MPLS-jpl.ppt
MPLS-jpl.pptMPLS-jpl.ppt
MPLS-jpl.ppt
 
Auto-Bandwidth Allocation in Multicast Aware VPLS Netowrks
Auto-Bandwidth Allocation in Multicast Aware VPLS NetowrksAuto-Bandwidth Allocation in Multicast Aware VPLS Netowrks
Auto-Bandwidth Allocation in Multicast Aware VPLS Netowrks
 
I41026670
I41026670I41026670
I41026670
 
G010314853
G010314853G010314853
G010314853
 
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...IJCER (www.ijceronline.com) International Journal of computational Engineerin...
IJCER (www.ijceronline.com) International Journal of computational Engineerin...
 
Switching systems lecture8 mpls
Switching  systems lecture8 mplsSwitching  systems lecture8 mpls
Switching systems lecture8 mpls
 
Research paper ( MPLS as a Software-Defined Network )
Research paper ( MPLS as a Software-Defined Network )Research paper ( MPLS as a Software-Defined Network )
Research paper ( MPLS as a Software-Defined Network )
 
Digital network lecturer3
Digital network  lecturer3Digital network  lecturer3
Digital network lecturer3
 
V25112115
V25112115V25112115
V25112115
 
MPLS_SDN.pdf
MPLS_SDN.pdfMPLS_SDN.pdf
MPLS_SDN.pdf
 
MPLS
MPLSMPLS
MPLS
 
MPLS
MPLSMPLS
MPLS
 
Next generation-ptn-white-paper
Next generation-ptn-white-paperNext generation-ptn-white-paper
Next generation-ptn-white-paper
 
International Journal of Engineering Research and Development
International Journal of Engineering Research and DevelopmentInternational Journal of Engineering Research and Development
International Journal of Engineering Research and Development
 
Mpls Traffic Engineering ppt
Mpls Traffic Engineering pptMpls Traffic Engineering ppt
Mpls Traffic Engineering ppt
 
Computer Networking Tasks.docx
Computer Networking Tasks.docxComputer Networking Tasks.docx
Computer Networking Tasks.docx
 
MPLS
MPLSMPLS
MPLS
 
Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...
Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...
Application of N jobs M machine Job Sequencing Technique for MPLS Traffic Eng...
 

Recently uploaded

How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...
Product School
 
Elevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object CalisthenicsElevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object Calisthenics
Dorra BARTAGUIZ
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
Product School
 
FIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdfFIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance
 
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using SmithyGenerating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using Smithy
g2nightmarescribd
 
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdfFIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance
 
Monitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR EventsMonitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR Events
Ana-Maria Mihalceanu
 
Connector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a buttonConnector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a button
DianaGray10
 
UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3
DianaGray10
 
The Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and SalesThe Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and Sales
Laura Byrne
 
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdfLeading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
OnBoard
 
GraphRAG is All You need? LLM & Knowledge Graph
GraphRAG is All You need? LLM & Knowledge GraphGraphRAG is All You need? LLM & Knowledge Graph
GraphRAG is All You need? LLM & Knowledge Graph
Guy Korland
 
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
Sri Ambati
 
The Future of Platform Engineering
The Future of Platform EngineeringThe Future of Platform Engineering
The Future of Platform Engineering
Jemma Hussein Allen
 
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfKey Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdf
Cheryl Hung
 
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Tobias Schneck
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Jeffrey Haguewood
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
DianaGray10
 
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
DanBrown980551
 
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Product School
 

Recently uploaded (20)

How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...
 
Elevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object CalisthenicsElevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object Calisthenics
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
 
FIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdfFIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdf
 
Generating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using SmithyGenerating a custom Ruby SDK for your web service or Rails API using Smithy
Generating a custom Ruby SDK for your web service or Rails API using Smithy
 
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdfFIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
 
Monitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR EventsMonitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR Events
 
Connector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a buttonConnector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a button
 
UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3UiPath Test Automation using UiPath Test Suite series, part 3
UiPath Test Automation using UiPath Test Suite series, part 3
 
The Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and SalesThe Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and Sales
 
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdfLeading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
 
GraphRAG is All You need? LLM & Knowledge Graph
GraphRAG is All You need? LLM & Knowledge GraphGraphRAG is All You need? LLM & Knowledge Graph
GraphRAG is All You need? LLM & Knowledge Graph
 
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
GenAISummit 2024 May 28 Sri Ambati Keynote: AGI Belongs to The Community in O...
 
The Future of Platform Engineering
The Future of Platform EngineeringThe Future of Platform Engineering
The Future of Platform Engineering
 
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfKey Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdf
 
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024
 
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
 
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...
 
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...
 

VPN Using MPLS Technique

  • 1. Fall 2017 EE 358 Information Theory Course Project VPN Routing via MPLS Technique Ahmad Sameer Mohammad(26), Ahmad Atta Mohammad(30), Hussam Aldeen Ahmad(87), Rafik Hisham(101), Omar Aldalil(134). Affiliations (i.e., Electronics and communication department, Alexandria University) Ahmed3ta@gmail.com Abstract. Multiprotocol Label Switching (MPLS) networks are the next generation of networks designed to allow enterprises to create end-to-end circuits across any type of transport medium using any available wide area network (WAN) technology. Until recent years, enterprises with the need to connect remote offices in locations across the country were restricted to the limited WAN options that service providers offered—usually frame relay or T1/E1 dedicated links. MPLS VPNs combine the power of MPLS and the Border Gateway Protocol (BGP) routing protocol. MPLS is used to forward packets over the provider’s network backbone, and BGP is used for distributing routes over the backbone. 1. Introduction VPLS, MPLS VPNs, MPLS and VPNs are terms often used interchangeably, but erroneously so. Confusion about MPLS VPNs stems from the multitudinous words that vendors and marketers often use to describe the same service. So what actually is an MPLS VPN? "MPLS" and "VPN" are two different technology types. Multiprotocol Label Switching (MPLS) is a standards-based technology used to speed up the delivery of network packets over multiple protocols – such as the Internet Protocol (IP), Asynchronous Transport Mode (ATM) and frame relay network protocols. A virtual private network (VPN) uses shared public telecom infrastructure, such as the Internet, to provide secure access to remote offices and users in a cheaper way than an owned or leased line. VPNs are secure because they use tunneling protocols and procedures such as Layer Two Tunneling Protocol (L2TP). With those definitions understood, an MPLS VPN is a VPN that is built on top of an MPLS network, usually from a service provider, to deliver connectivity between enterprise office locations. The terms "MPLS IP VPN," "MPLS VPN" and "MPLS-based VPN" can be used synonymously. Understanding these terms are important when mastering MPLS VPN fundamentals.
  • 2. 2. Background/Related Work MPLS Technique: In this section we will talk about the mechanisms of MPLS and how it works. First, data carried over MPLS network has one or more MPLS headers applied in order to transport it across the network. The MPLS header structure is shown in Figure 1. It contains those fields: 1. A 20-bit label value. MPLS pack- ets are forwarded on the basis of this field. This value is used as an index into the MPLS forwarding table. 2. Traffic Class (TC) field (3 bits). Previously known as the EXP bits, convey the Class of Service to be ap- plied to the packet. For example, LSRs and LERs can use these bits to determine the queue into which the packet should be placed. Note that in some cases the MPLS label value also determines the queuing behavior applied to the packet. 3. Bottom of stack bit (S-bit). MPLS headers can be stacked. The S-bit is set on the header of the MPLS packet at the bottom of the stack. 4. Time-to-live (TTL) field. This is used to avoid forwarding loops and can also be used for path-tracing. The value is decremented at each hop and the packet is discarded should the value reach zero. But actually before dig- ging into how it works and how the header is added, let’s first define the MPLS network Architecture Fig- ure 2 and see its compo- nents. Figure 2: Very simple MPLS network architecture Figure 1: MPLS Header
  • 3. 1. Label Edge Router (LER): It exists on the both edges of the network on the entry and exit points of the network: a. Ingress Label Edge Router (ILER): It exists at the beginning of an MPLS network and is an en- try point where the data packet originates from its source. This edge router imposes label (PUSH) and forward packets to destination through the domain. This ingress edge router ini- tiates packet-forwarding process in MPLS core network. b. Egress Label Edge Router (ELER): It exists at the end of an MPLS network and is an exit point where the data packet reaches its destination. This edge router performs label disposition or removal (POP) and forwards IP packet to destination. It disposes label from the arrived packet only when bottom-of-stack indicator identifies if the encountered label is bottom la- bel of the stack or not. 2. Label Switch Router (LSR): This router receives a labeled packet, swaps it with an outgoing one, and forwards the new packet to an appropriate interface. Depending on its location in MPLS domain, this router performs label disposition (removal, POP), label imposition (addition, PUSH) or label swapping (replacing the top label in a stack with a new outgoing label value). When the data stream (files or multimedia traffic) arrives from the access network to the MPLS core, it is segregated into separate FEC in this router. As an acknowledgement of label bindings, LSR creates entries in Label In- formation Base. This table comprises of I/O ports and I/O port labels indicating the label-FEC map- ping. 3. Label Switch Path (LSP): LSP is the path which the packet takes to reach its destination through an MPLS-enabled network. The path is unidirectional so this allows packets to be switched from one edge to the other by passing through several intermediate switch routers. Every network location needs LSPs to be established for data transfer. For example, packet data from LER1 traverses among several intermediate nodes to LER2 using LSP1, then another path LSP2 is set out for packet transfer to other end directly, which is the shortest path to arrive the destination. However, path switching is derived from IGP routing information and may diverge from Interior Gateway Protocol preferred path to the target network. How MPLS works As a packet enters ingress router, this ingress LER assigns labels to the packets for data transmission through the network. The labels in MPLS header are inserted into data packet that has to be transmitted. These fixed-length labels carry the information; all the subsequent routing switches perform packet for- warding based only on those labels they never look as far as the IP header. As each node forwards the packet, it swaps current label for the most appropriate label to the subse- quent node to route the packet. Finally, the egress router removes the label(s) and forwards the original IP packet toward its final destination. This mechanism enables very-high-speed packet switching through the core MPLS domain.
  • 4. VPN Traditional router-based networks connect customer sites through routers connected via dedicated point-to-point links (leased lines).VPNs replace dedicated point-to-point links with emulated point-to-point links that share common infrastructure. Customers use VPNs primarily to reduce their op- erational costs. Advantages of VPNs • Cost savings: Replacing expensive long-distance leased lines with much less expensive dedicated connection to the service provider (DSL, fiber). And: Offload- ing support costs • Scalabil- ity: Add- ing a new branch office is fast and simple by adding an additional link to the ISP (adding a site to the customer VPN). • Improved security: Use of encryption protocols and authentication • Better performance: More high-capacity data service options can be used (cheaper bandwidth). • Flexibility and reliability: Wide spread availability of fiber, DSL, and other broadband options. And: Using more than one ISP • Greater access to mobile users: Increases productivity and responsiveness for employees working from home or on business trips. VPN Terminology Provider Edge (PE) Devices Provider Edge (PE) Devices Provider network (P-network): The service provider infrastructure used to provide VPN services Customer network (C-network): The part of the network still under customer control Customer site: A contiguous part of the customer network (can encompass many physical locations) Provider (P) Core DevicesCustomer Site Large Customer Site Customer Premises Equipment (CPE) or Router CPE RoutVirtual Other Customer Virtual Customer Site Large Customer Site Provider (P) Core Devices Customer Premises Equipment (CPE) or Customer Edge (CE) Router CPE Router Virtual Circuit 2 Other Customer Routers Virtual Circuit 1 Figure 3: VPN Simple Model Figure 4: VPN Terminology
  • 5. VPNs Overlay VPN Peer-to-Peer VPN Layer 2 VPN Layer 3 VPN ACLs (Shared router) MPLS VPN Split routing (dedicated router) X.25 Frame Relay ATM GRE DMVPN IPsec GET VPN L2TPv3 SSL VPN P device: The device in the provider network with no customer connectivity PE device: The device in the provider network to which the customer devices are connected CE device: The device in the customer network that links to the provider network (sometimes also called CPE) PE-CE link: A link between a PE router and a CE router. VPN Models VPN services can be offered based on two major models: • Overlay model, in which the service provider provides virtual point-to-point links between customer sites • Peer-to-peer model, in which the service provider participates in the customer routing Overlay Implemntation techniques Overlay Layer 2 VPN - The service provider establishes Layer 2 VCs between customer sites. - The customer is responsible for all higher layers. Overlay layer 3 VPN The service provider infrastructure appears as point-to-point links to the customer. The service provider does not see customer routes and is responsible only for providing the point-to- point transport of customer data. Layer 3 VPN – IP tunneling - Routing protocols run directly between customer routers. - GRE is simple (and quicker). Figure 5: VPN Models
  • 6. - IPsec provides authentication and security. Layer 2 VPN – Layer 2 forwarding - Transparent tunneling of Layer 2 over IP  Over lay Layer 2, VPN is implemented with IP-over-Frame Relay or ATM tunnels: - The service provider establishes Layer 2 VCs between customer sites. - The customer is responsible for all higher layers.  Over lay Layer 3, VPN is implemented with IP-over-IP tunnels (GRE): - Tunnels are established with GRE (Generic Routing Encapsulation). - Tunnel interfaces are point-to-point. - Enables dynamic routing and multicast - Runs GRE over IPsec to secure tunnel payload  Over lay Layer, 3 VPN is implemented with IP-over-IP tunnels (DMVPN): - Tunnels are established with mGRE. - Tunnel interfaces are point-to-multipoint. - Enables dynamic routing and multicast - Runs mGRE over IPSec to secure tunnel payload  Over lay Layer 3, VPN is implemented with IP-over-IP tunnels (IPSec): - Tunnels are established with IPsec (tunnel mode). - Enables static routing (no multicast) - Secures payload  Over lay Layer 3, L2TPv3 is used as a tunneling mechanism to deploy Layer 2 transparent services over IP: - L2TPv3 includes support for multiple Layer 2 encapsulations, including 802.1Q VLAN, QinQ, and Ethernet.  Over lay Layer 3, SSL VPN enables remote-access connectivity from almost any Internet-enabled location: - Easy integration of the SSL VPN gateway into a shared MPLS network Peer-to-Peer VPNs: Implementation Techniques - PE-CE routing information is exchanged between CE and PE routers.  Peer-to-Peer VPN: ACLs (Shared Router) - POP router carries all customer routes. - Isolation between customers is achieved with the use of ACLs (packet filters) on PE-to-CE interfaces.  Peer-to-Peer VPN: Split Routing (Dedicated Router) - The P router contains all customer routes. - Each customer has a dedicated PE router that carries only its routes. - Isolation between customers is achieved through the lack of routing information on the PE router.  GET VPN: - Does not use tunnels, behaves almost like transport mode Ipsec - Large-scale solution accommodating multicast - Uses group security association and shared encryption key - Centralized policy and key server with periodic rekeying  MPLS VNP - CE routers route traffic to PE routers.
  • 7. - Each customer has its own isolated routing table instance on PE router. - P routers do not have customer route information. - Label switching is enabled in service provider core. Benefits of VPN Implementations  Overlay VPN: - Well-known and easy to implement - Service provider does not participate in customer routing. - Customer network and service provider network are well isolated.  Peer-to-peer VPN: - Guarantees optimum routing between customer sites - Easier to provision an additional VPN - Only sites provisioned, not links between them Drawbacks of VPN Implementations  Overlay VPN: - Implementing optimum routing requires a full mesh of VCs. - VCs have to be provisioned manually. - Bandwidth must be provisioned on a site-to-site basis. - Overlay VPNs always incur encapsulation overhead (GRE or IPsec).  Peer-to-peer VPN: - The service provider participates in customer routing. Filters should be applied to customer links. - The service provider becomes responsible for customer convergence. - PE routers carry all routes from all customers. - A secure environment must be provided for customers. - Complex configuration - The service provider needs detailed IP routing knowledge.
  • 8. 3. MPLS VPN Why MPLS VPN In the MPLS VPN model, the best features of the overlay and point-to-point models are implemented. An MPLS-enabled core and edge network provides a very fast and efficient data switching environ- ment based on MPLS labels. PE routers exchange routing information with customer CE routers and use separate isolated routing tables for each customer. Special routing protocol contexts are used for route exchange between PE and CE routers. Routes are then exchanged between PE devices using the Multiprotocol BGP (MP-BGP) routing algo- rithm. For scalability reasons, service provider core routers do not have any customer routing information. PE routers label packets with MPLS labels and P routers use these labels for fast label-switching packets.
  • 9. a. Implementation MPLS Architecture In the MPLS VPN architecture, the edge routers carry customer routing information, providing optimal routing for traffic that belongs to the customer for inter-site traffic. The MPLS-based VPN model also accommodates customers who use overlapping address spaces, unlike the traditional peer-to-peer model, in which optimal routing of customer traffic required the provider to assign IP addresses to each of its customers (or the customer to implement Network Ad- dress Translation [NAT]) to avoid overlapping address spaces. MPLS VPN is an implementation of the peer-to-peer model; the MPLS VPN backbone and customer sites exchange Layer 3 customer routing information, and data is forwarded between customer sites using the MPLS-enabled service provider IP backbone. The MPLS VPN domain, like the traditional VPN, consists of the customer network and the provider network. The MPLS VPN model is very similar to the dedicated provider edge (PE) router model in a peer-to-peer VPN implementa- tion. However, instead of deploying a dedicated PE router per customer, customer traffic is isolated on the same PE rout- er that provides connectivity into the service provider network for multiple customers. In the MPLS VPN implementation, the PE router performs multiple functions. The PE router must first be capable of isolating customer traffic if more than one customer is connected to the PE router. Each customer, therefore, is assigned an independent routing table (virtual routing table or virtual routing and forwarding [VRF] table) similar to a dedicated PE router in the initial peer-to-peer discussion. Routing across the service provider backbone is performed using a rout- ing process in the global routing table. P routers provide label switching between PE routers and are unaware of VPN routes. CE routers in the customer network are not aware of the P routers, and thus the internal topology of the service provider network is transparent to the customer. And to enable scaling the networkto a large number of customer VPNs, Multiprotocol Border Gateway Protocol (MP-BGP) isconfigured between PE routers to carry customer routes. Figure 6: Simple VPN Architecture The P routers are responsible only for label switching of packets. They do not carry VPN routes and do not participate in MPLS VPN routing. The PE routers exchange IPv4 routes with connected CE routers using individual routing proto- col contexts. To enable scaling the network to a large number of customer VPNs, Multiprotocol Border Gateway Proto- col (MP-BGP) is configured between PE routers to carry customer routes.
  • 10. Virtual Routing and Forwarding tables (VRFs) The global routing table (or forwarding in case of Layer 2 switching) is not the same as the VRF as the global interface includes only the IPV4 or IPV6 infor- mation (or MAC addresses per interface in case of Layer 2 switching) and only one global routing table can exist in a single router. The VRFs instead can contain more infor- mation as explained next and more than one VRF can coexist in the same router. The VRF contains an IP routing table that is analo- gous to the global IP routing table, a Cisco Express Forwarding table, a list of interfaces that are part of the VRF, and a set of rules defining routing protocol exchange with attached CE routers (routing protocol contexts). In addition, the VRF also contains VPN identifi- ers and VPN membership information (route distinguisher [RD] and route target [RT] are covered in the next section). The interface that is part of the VRF must support Cisco Express Forwarding switching. The number of interfaces that can be bound to a VRF is limited only by the number of interfaces on the router, and a single interface (logical or physi- cal) can be associated with only one VRF. In the MPLS VPN routing model, the PE router provides isolation between customers using VRFs. However, this in- formation must be carried between PE routers to enable data transfer between customer sites via the MPLS VPN back- bone. The PE router must be capable of implementing processes that enable overlapping address spaces in connected customer networks. The PE router must also learn these routes from attached customer networks and propagate this information using the shared provider backbone. This is done by the association of an RD per virtual routing table on a PE router. MP-BGPV4 The next design decision to be made is the choice of the routing protocol running between PE routers. Given that the total number of customer routes is expected to be very large, the only well-known protocol with the required scalability is Border Gateway Protocol version 4 (BGP4). In fact, BGP4 is used in the MPLS VPN architecture to transport custom- er routes directly between PE routers. MPLS VPN architecture differs in an important way from traditional peer-to-peer VPN solutions: MPLS VPNs support overlapping customer address spaces. MP-BGP is also responsible for the assignment of a VPN label. Packet forwarding in an MPLS VPN mandates that the router specified as the next hop in the incoming BGP update is the same router that assigns the VPN label. An MP- BGP session between PE routers in a single BGP AS is called a Multiprotocol Internal Border Gateway Protocol (MP- IBGP) session and follows rules as in the implementation of IBGP with regards to BGP attributes. If the VPN extends beyond a single AS, VPNv4 routes will be exchanged between autonomous systems at the AS boundaries using a Multi- protocol External Border Gateway Protocol (MP-EBGP) session. Route Distinguisher With the deployment of a single routing protocol (that is, BGP4) exchang- ing all customer routes between PE routers, an important issue arises: how can BGP4 propagate several identical prefixes, belonging to different cus- tomers, between PE routers? The only solution to this dilemma is the expan- sion of customer IP prefixes with a unique prefix that makes them unique even if they had previously overlapped. A 64- bit prefix Figure 7: Explaining VRFs Figure 8: RD Header
  • 11. called the route distinguisher (RD) is used in MPLS VPNs to convert non-unique 32-bit customer addresses into 96-bit unique addresses that can be transported between PE routers. An RD is a 64-bit unique identifier that is prepended to the 32-bit customer prefix or route learned from a CE router, which makes it a unique 96-bit address that can be transported between the PE routers in the MPLS domain. Thus, a unique RD is configured per VRF on the PE router. The resulting address, which is 96 bits total (32-bit customer prefix plus 64-bit unique identifier or RD), is called a VPNv4 address. VPNv4 addresses are exchanged only between PE routers; they are never used between CE routers. Between PE rout- ers, BGP must therefore support the exchange of traditional IPv4 prefixes and the exchange ofVPNv4 prefixes. A BGP session between PE routers is therefore called a Multiprotocol Border Gateway Protocol (MP-BGP) session. The format of an RD is shown in the figure. An RD can be of two formats. If the provider does not have a BGP autonomous system (AS) number, the IP address format can be used, and if the provider does have an AS number, the AS number format can be used. RD process flow - Step 1: The CE router sends an IPv4 routing update to the PE router - Step 2: The PE router prepends a 64-bit RD to the IPv4 routing update, resulting in a globally unique 96-bit VPNv4 prefix. - Step 3: The VPNv4 prefix is propagated via an MP-IBGP session to other PE routers. - Step 4: The receiving PE routers strip the RD from the VPNv4 prefix, resulting in an IPv4 prefix. RD is used to match the proper VRF routing table. - Step 5: The IPv4 prefix is forwarded to other CE routers within an IPv4 routing update. Route Target (RT) Route targets (RTs) were introduced into the MPLS VPN architecture to support identifying a site that participates in more than one VPN. RTs are additional identifiers used in the MPLS VPN that identify the VPN membership of the routes learned from that particular site. RTs are implemented by the use of extended BGP communities in which the higher-order 16 bits of the BGP extended community (64 total bits) is encoded with a value corresponding to the VPN membership of the specific site. When a VPN route learned from a CE router is injected into VPNv4 BGP, a list of VPN route target extended community attributes is associated with it. When implementing complex VPN topologies, such as extranet VPN, Internet access VPNs, network management VPN, and so on, using MPLS VPN technology, the RT plays a pivotal role. A single prefix can be associated to more than one export route target when propagated across the MPLS VPN network. The RT can, as a result, be associated to sites that might be a member of more than one VPN. VPN Label The VPN label (4 bytes) is assigned for each prefix that is learned from the IGP process of the connected CE router within a VRF by the MP-BGP process of the PE router. MP-BGP running in the service provider MPLS domain thus carries the VPNv4 prefix (IPv4 prefix with prepended RD) in addition to the BGP route target extended community. A simple MPLS-oriented approach to MPLS VPN packet forwarding across the MPLS VPN backbone would be to label the customer packet with the label assigned by Label Distribution Protocol (LDP) for the egress PE router. The core routers consequently would never see the customer IP packet; instead, the core routers would see just a labeled packet targeted toward the egress PE router. The core routers would perform simple label-switching operations, eventually de- livering the customer packet to the egress PE router. Unfortunately, the customer IP packet would contain no VPN or VRF information that could be used to perform VRF lookup on the egress PE router. The egress PE router would not know which VRF to use for packet lookup and would need to drop the packet. An MPLS label stack can be used to tell the egress PE router what to do with the VPN packet. When using the label stack, the ingress PE router labels the incoming IP packet with two labels. The top label in the stack is the LDP label for the egress PE router; this label guarantees that the packet will traverse the MPLS VPN backbone and arrive at the egress PE router. The second label in the stack is assigned by the egress PE router, and tells how to forward the incoming VPN
  • 12. packet. The second label could point directly toward an outgoing interface, in which case the egress PE router would perform label lookup only on the VPN packet. The second label could also point to a VRF, in which case the egress PE router would first perform a label lookup to find the target VRF, and then perform an IP lookup within the VRF. IGP scoop The next hops on PE routers must not be advertised in the BGP process but must be learned from the IGP for MPLS VPN implementation. The VPN label is depicted by the entries VI and V2 in the figure. The designers of MPLS VPN technology were faced with these routing requirements: • CE routers should not be MPLS VPN-aware; CE routers should run standard IP routing software. • PE routers must support MPLS VPN services and traditional Internet services. To make the MPLS VPN solution scalable, P routers must not participate in customer VPN routing. P routers use only label switching. Traffic flow Penultimate hop popping (PHP) is the removal of the top label in the stack on the hop prior to the egress router. PHP can be performed in frame-based MPLS networks. In these networks, the last P router in the label-switched path (LSP) tunnel pops the LDP label (as previously requested by the egress PE router through LDP), and the PE router receives a labeled packet that con- tains only the VPN label. In most cases, a single label lookup performed on that packet in the egress PE router is enough to forward the packet toward the CE router. The full IP lookup through the forwarding information base (FIB) is performed only once, in the ingress PE router, even without PHP. Summary An MP-BGP update exchange between PE routers contains these elements: • VPNv4 address • Extended BGP communities (for example, RTs are required) • Label used for VPN packet forwarding • Mandatory BGP attributes (for example, AS path). Optionally, the MP-BGP update can contain any other BGP at- tribute, such as local preference, multi-exit discriminator (MED), or standard BGP community. The PE routers receiving MP-BGP updates import the incoming VPNv4 routes into their VRFs based on RTs attached to the incoming routes and based on import RTs configured in the VRFs. The VPNv4 routes installed in the VRFs are converted to IPv4 routes and then propagated to the CE routers. The RTs that are attached to a route and the import RTs that are configured in the VRF direct the propagation of the routes to the CE router. Incoming VPNv4 routes are imported into VRFs on the receiving PE router only if at least one RT attached to the route matches at least one import RT that is configured in the VRF. Figure 9: MPLS Backbone Traffic flow
  • 13. b. Simulation Scenarios and Testbeds Requirements (a) GNS3 Simulator to implement and run MPLS L3 VPN (b) 4GB RAM, in minimum, installed in the laptop/ PC running GNS3 (c) Cisco IOS Image c7200 (d) configuring all the networks with scalability in mind Figure 10:the MPLS L3VPN Topology implemented using GNS3 All configurations are written in the Global Configu- ration Mode Configure a loopback interface to use later as router id PE Router (R2): interface Loopback0 ip address 2.2.2.2 255.255.255.255 P Router (R3): interface Loopback0 ip address 3.3.3.3 255.255.255.255 PE Router (R4): interface Loopback0 ip address 4.4.4.4 255.255.255.255 Customer Router (R1) 1st bransh interface Loopback0 ip address 1.1.1.1 255.255.255.255 Customer Router (R5) 2nd bransh interface Loopback0 ip address 5.5.5.5 255.255.255.255 Configure IP addresses: R2: interface GigabitEthernet0/0 ip address 192.168.23.2 255.255.255.0 interface GigabitEthernet1/0 ip address 192.168.12.2 255.255.255.0 R1: interface GigabitEthernet0/0 ip address 192.168.12.1 255.255.255.0 interface GigabitEthernet0/0 ip address 192.168.45.5 255.255.255.0 R3: interface GigabitEthernet0/0 ip address 192.168.23.3 255.255.255.0 interface GigabitEthernet1/0 ip address 192.168.34.3 255.255.255.0 R4: interface GigabitEthernet0/0 ip address 192.168.45.4 255.255.255.0 interface GigabitEthernet1/0 ip address 192.168.34.4 255.255.255.0 R5: interface GigabitEthernet0/0 ip address 192.168.45.5 255.255.255.0 :Configure LDP R2(config)#mpls ldp router-id Loopback0 R3(config)#mpls ldp router-id Loopback0 R4(config)#mpls ldp router-id Loopback0 Enabling MPLS on interfaces connected in the ISP network: R2: interface GigabitEthernet0/0 mpls ip R3: interface GigabitEthernet1/0 mpls ip interface GigabitEthernet0/0 mpls ip R4: interface GigabitEthernet1/0 mpls ip
  • 14. Configure backbone network IGP R2: router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 192.168.23.0 0.0.0.255 area 0 R3: router ospf 1 log-adjacency-changes network 3.3.3.3 0.0.0.0 area 0 network 192.168.23.0 0.0.0.255 area 0 network 192.168.34.0 0.0.0.255 area 0 R4: router ospf 1 log-adjacency-changes network 4.4.4.4 0.0.0.0 area 0 network 192.168.34.0 0.0.0.255 area 0 Configure MP-BGP for vpnv4 route exchange be- tween PE routers R4: router bgp 1 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 1 neighbor 2.2.2.2 update-source Loopback0 no auto-summary address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended exit-address-family R2: router bgp 1 bgp log-neighbor-changes neighbor 4.4.4.4 remote-as 1 neighbor 4.4.4.4 update-source Loopback0 no auto-summary address-family vpnv4 neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended exit-address-family Configure Customer VRFs: On both R2 and R4 (the provider edges): ip vrf customer1 rd 100:1 route-target export 1:100 route-target import 1:100 Associating the VRFs with customer interfaces: R2: interface GigabitEthernet1/0 ip vrf forwarding customer1 ip address 192.168.12.2 255.255.255.0 R4: interface GigabitEthernet0/0 ip vrf forwarding customer1 ip address 192.168.45.4 255.255.255.0 Setting Up Routing For the Client R5: router eigrp 100 network 5.0.0.0 network 192.168.45.0 no auto-summary R1: router eigrp 100 network 1.0.0.0 network 192.168.12.0 no auto-summary Redistribute EIGRP into BGP router bgp 1 address-family ipv4 vrf customer1 redistributing the eigrp routes to bgp: redistribute eigrp 100 exit-address-family Redistribute BGP into EIGRP router eigrp 1 address-family ipv4 vrf customer1 redistribute bgp 1 metric 1 1 1 1 1 network 192.168.12.0 no auto-summary autonomous-system 100 exit-address-family R4 Redistribute BGP into EIGRP router eigrp 1 address-family ipv4 vrf customer1 redistribute bgp 1 metric 1 1 1 1 1 network 192.168.45.0 no auto-summary autonomous-system 100 exit-address-family Redistribute EIGRP into BGP router bgp 1 address-family ipv4 vrf customer1 redistribute eigrp 100 exit-address-family
  • 15. 4. Conclusions The most scalable method of exchanging customer routes across a provider network is the use of an MP-BGP between PE routers. RDs transform non-unique 32-bit addresses into 96-bit unique addresses. RTs are used to identify VPN membership in overlapping topologies. • In MPLS VPNs: CE routers run standard routing protocols to the PE routers. PE routers provide the VPN routing and services via MP-BGP. P routers do not participate in VPN routing, and only provide core IGP backbone routing to the PE routers. • PE routers forward packets across the MPLS VPN backbone using label 5. Future Work a. VPNv6 on the MPLS: In this overview we only used the IPv4 of the traffic data, the implementation of IPv6 on the same way can be more challenging b. Layer 2 MPLS VPN: We worked only on the Layer 3 MPLS VPN, and we look forward to see the results on the Layer 2 MPLS VPN. c. Other vendors VPN MPLS: At the start Cisco Studying material were available, so we only worked on the environment that is suit- able for Cisco, also other vendors can be tricky to find academic material for, we are keen to see the differences of other vendors in concept and implementation. d. Security point of view: We didn’t study the subject from the security perspective, so it would be a great benefit to study it se- curity-wise. 6. References [1] Cicso SPNGN1, SPNGN2, SPCORE material [2] MPLS Enabled applications, Third edition. [3] MPLS Virtual Private Networks, Luca Cittadini, Giuseppe Di Battista, Maurizio Patrignani.. [4] Implementation of MPLS L3VPN using GNS3, Akashy, Pooja Ahlawat
  • 16. Contents 1. Introduction .............................................................................................................................................................1 2. Background/Related Work ......................................................................................................................................2 MPLS Technique: ........................................................................................................................................................2 How MPLS works........................................................................................................................................................3 VPN..............................................................................................................................................................................4 Advantages of VPNs ................................................................................................................................................4 VPN Terminology....................................................................................................................................................4 VPN Models.............................................................................................................................................................5 3. MPLS VPN..............................................................................................................................................................8 Why MPLS VPN..........................................................................................................................................................8 a. Implementation ...................................................................................................................................................9 MPLS Architecture ..................................................................................................................................................9 Virtual Routing and Forwarding tables (VRFs) .....................................................................................................10 MP-BGPV4............................................................................................................................................................10 b. Simulation Scenarios and Testbeds...................................................................................................................13 4. Conclusions ...........................................................................................................................................................15 5. Future Work...........................................................................................................................................................15 6. References .............................................................................................................................................................15 Contents .........................................................................................................................................................................16 Figure 1: MPLS Header ...................................................................................................................................................2 Figure 2: Very simple MPLS network architecture..........................................................................................................2 Figure 3: VPN Simple Model...........................................................................................................................................4 Figure 4: VPN Terminology ............................................................................................................................................4 Figure 5: VPN Models .....................................................................................................................................................5 Figure 6: Simple VPN Architecture .................................................................................................................................9 Figure 7: Explaining VRFs ............................................................................................................................................10 Figure 8: RD Header ......................................................................................................................................................10 Figure 9: MPLS Backbone Traffic flow.........................................................................................................................12 Figure 10:the MPLS L3VPN Topology implemented using GNS3 ...............................................................................13