Professional Documents
Culture Documents
Networking - VPN Connectivity and Their Management: Sikkim Manipal Institute of Technology
Networking - VPN Connectivity and Their Management: Sikkim Manipal Institute of Technology
MANAGEMENT
to
of
BACHELOR OF TECHNOLOGY
in
ELECTRONICS AND COMMUNICATION ENGINEERING
by
VARUN LAKHOTIA
( 200412136 )
CERTIFICATE
carried out in partial fulfillment of the requirements for awarding the degree
of Bachelor of Technology under Sikkim Manipal Institute of
Technology during the academic year 2007 – 2008
I take this opportunity to express my deepest gratitude to my team leader and project
guide Mr. Puneet Khanna (Sr. Network Engineer) for his able guidance and support in
this phase of transition from an academic to a professional life.. His support and valuable
I would also like to show my deep sense of gratitude to my team members Mr.Prashaant
technical inputs, thus contributing either directly or indirectly to the various stages of the
project.
I am also grateful to Mr. Ashish Gupta (NOC Head, Tulip Telecom) for providing me
Also, I would like show my sincere gratitude to Dr. Sushabhan Choudhury (Professor,
Department of ECE, SMIT) my internal supervisor and guide, for his continuous help,
And last, but not the least, I would like to thank the people at Tulip TELECOM for
i
ABSTRACT
Tulip Telecom is the largest MPLS based VPN provider in India and has been the front-
runner in provisioning and managing of multi location wide area network VPNs using
VPN is a cost effective and secure way for different corporations to provide user access
to the corporate network and for remote networks to communicate with each other across
The report presents a comprehensive overview of VPNs. The most important VPN
architectures and technologies are described. IPsec, GRE and MPLS technologies
together with various tunneling protocols are studied as the main enabling technologies
The report also discusses Tulips last mile wireless network connectivity and their remote
monitoring. An insight into the connectivity of some of the VPN clients that were
ii
TABLE OF CONTENTS
Page
ACKNOWLEDGEMENT………………………………………………. i
ABSTRACT ……………………………………………………………... ii
ABBREVATIONS ………………………………………………………. x
1.3 Infrastructure…………………………………………………… 2
2.1 Introduction……..………………………………………………. 6
iii
2.6.1 Overlay VPN Model…………………………………… 11
3.1 Tunneling…….……………………………………………….... 15
20
3.3.3 L2TP/IPSec…………………………………………….. 24
AND VPNs
iv
4.2.4 Label Edge Router (LER)………………………………. 30
4.8.2 MPLS-over-L2TPv3…………………………………… 41
v
5.3.2 VPN Data Forwarding in Data Plane…………….……. 54
CONNECTIVITY
6.1 Introduction.……………………………………………………. 56
6.3 Radios…..…………………………………………………........ 58
6.3.1 Airspan……………………………………………….... 58
6.3.2 Radwin…………………………………………….…… 60
6.3.3 Firepro………………………………………………….. 60
TROUBLESHOOTING
7.3 Tools………………………………………………………….… 65
7.3.3 WipManage………………………………………….…. 67
vi
8.1 Reliance L2 Circuits…………………………………..….…..... 74
8.1.1 Working………………………………………………... 75
8.1.2 Troubleshooting…………………….…………………. 76
8.2 Indiabulls……………………….………………………………. 80
8.2.1 Working………………………………………………... 80
8.2.2 Troubleshooting……………………………………….. 81
9.1 Discussion……………………………………………..….…..... 82
9.3 Conclusion……………………………………………………… 84
vii
LIST OF FIGURES
3.1 Tunneling……………………………………………………………. 16
viii
4.7 VR VPN with Direct Connectivity between VRs………………….. 37
ix
8.3 Basic Indiabulls VPN Network Connectivity Layout……………. 80
ABBREVIATIONS
AH Authentication Header
AS Autonomous System
CE Customer Edge
DC Direct Current
x
IP Internet Protocol
IT Information Technology
MMP Multipoint-to-Multipoint
xi
NBVPN Network Based Virtual Private Network
NI Network Integration
PE Provide Edge
RD Route Distinguisher
RF Radio Frequency
RT Route Target
xii
SLA Service Level Agreement
VC Virtual Circuit
VR Virtual Router
xiii
xiv
CHAPTER 1
Tulip Telecom Limited is a data telecom service and IT solutions provider that offers
MPLS VPN player and has been the front-runner in provisioning and managing multi
location wide area networks for various industry verticals. Tulip is a public limited
company and is listed on the Bombay Stock Exchange and National Stock Exchange in
India. Tulip provides network integration (NI), corporate data connectivity (MPLS VPNs
and Internet) within and outside India, infrastructure management services and IT
Tulip, today, is the only service provider in its domain that provides customers with end-
services.
requirements of customers.
Be the trusted advisor of the customers for all their data connectivity / networking
needs.
Impact the rural economy by providing connectivity right upto to the last village.
1.5 INFRASTRUCTURE
networking equipment. It is the only network in the country offering MPLS VPN services
at over 1100 locations. The entire network is connected over high speed fiber backbone
and offers multiple access technology options including wireless in the last mile. This
unique approach allows customers to get connected quickly and easily with very short
time lead times, eliminating many of the hindrances encountered in traditional copper-
based last mile connectivity provided by incumbent service providers. Tulip also offers
customer premises connectivity over fiber for high speed bandwidth applications. Tulip's
growth
multiple technologies.
Tulip's IP/MPLS network is a hierarchical network designed for high performance and
scalability. It follows a three-tier model with Core, Aggregation and Access layers.
The Core network of Tulip consists of high speed interconnects between the twelve major
cities in India. All these cities are dual-homed to high-capacity core routers at Delhi and
Mumbai. The core routers are capable of processing up to 120 Gbps of data traffic.
Tulip's network has twelve centers for traffic aggregation, each of which is dual-homed
to the core routers over STM-1/DS3 capacity links. The links are in redundant mode and
follow independent fiber routes between the POPs. Besides, each of the twelve
aggregation points have dual aggregation routers for additional level of redundancy.
The most critical aspect of a network is the access link to the customer or what is called
as the "last mile" connectivity. With the explosion in requirements for data connectivity
the last mile invariably turns out to be weakest links in the entire network. To address this
solution, Tulip has built infrastructure to address all types of customer locations and
terrains. Tulip offers multiple modes of last mile connectivity including leased lines, fiber
and wireless. Tulip is the only service provider to have deployed a large scale wireless
wireless technologies are innovatively being used reach out to our remotes customers.
Besides creating one of the most advanced service provider networks in India, Tulip has
significantly invested in setting up the best customer support infrastructure to manage and
maintain the vast network. Tulip operates a nationwide 24x7 customer support network to
ensure round the clock operations for all customers. Tulip has Full-fledged Network
Operations Centers (NOCs) in Delhi and Mumbai for centralized network monitoring and
management. Besides, Tulip also has regional NOCs in all major cities to allow quick
resolution to customer problems. The NOCs use sophisticated network monitoring tools
A vast portfolio of services is enabled on the carrier-grade Tulip network. Using the latest
Layer 3 MPLS VPN : Fully managed hub-and-spoke and full-mesh VPN for
Layer 2 MPLS VPN: MPLS based Virtual Leased Line solutions with flexible
Internet Access Services: High speed internet access at any of 800 locations in
India.
Dial Back-up Services: In case of primary link failure, last mile back-up
Data Center Solutions: Tulip offers co-location and hosting services in its state-
of-the-art Tier 3 Data Center facilities in Delhi, Mumbai and two other cities.
2.1 INTRODUCTION
A virtual private network (VPN) is a private communications network often used within a
a publicly accessible network. VPN message traffic can be carried over a shared public
networking infrastructure (e.g. the Internet) on top of standard protocols, or over a service
provider’s private network with a defined Service Level Agreement (SLA) between the
VPN customer and the VPN service provider, thus emulating the characteristics of an IP-
Improve security
Security
Because sensitive and mission critical company data must travel across an
extremely insecure network, such as the Internet. User data security features
addresses must be unique only within the set of sites reachable from the VPNs of
VPNs).
those VPN sites which are determined by customer routing and/or configuration
Performance
Network management
Policy management
Customer
Customer (C) devices: C devices are simply devices such as routers and switches
located within the customer network. These devices do not have direct
Customer Edge (CE) devices: CE devices, are located at the edge of the customer
network and connect to the provider network (via Provider Edge [PE] devices).
Provider (P) device: the device in the P-Network with no customer connectivity
and without any “knowledge” of the VPN. This device is usually a router .
Provider edge (PE) device: the device in the P-Network to which the CE devices
are connected. This device is usually a router and is often referred as the PE
router.
Remote access VPNs allow remote users (home users or mobile users) to access an
organization's resources remotely. A mobile user can make a local call to their Internet
service provider (ISP) to access the corporate network wherever they may be.
routing adjacency occurs directly between CEs (thus creating a sort of vitual backbone
over the Service Provider Network). The PE devices are unaware of customer network
address space and do not route customer traffic based on customer network addressing
but forward customer traffic based on globally unique addressing. The service provider
has no knowledge of the customer routes and is simply responsible for providing point-
to-point transport of data between the customer sites. However, the CE can be connected
to the Service Provider network (to some PE) via various forms of adjacency, ranging
This form of VPN is also referred to as CE-based VPNs since the VPN logic is
concentrated at the CEs and the PEs are unaware of the VPN.
In a peer VPN model, PE devices are aware of customer network addressing and route
customer data traffic according to customer network addressing. Both provider and
customer network use the same network protocol and all the customer routes are carried
within the core network (service provider network). Customer traffic is (usually)
forwarded between PE devices over VPN tunnels. A CE is the routing peer of a PE and
connectivity with the other sites via this PE router and because the service provider now
This form of VPN is also referred to as PE-based VPNs since the VPN logic is
concentrated at the PEs. They are also known as Network-Based VPN (NBVPN).
Based on the Overlay and Peer VPNs, the various approaches to the deployment of a
The diagram below shows the various VPN enabling technologies and protocols
Most VPNs rely on tunneling to create a private network that reaches across the Internet
3.1 TUNNELING
network over another network. The data to be transferred (or payload) can be the frames
(or packets) of another protocol. Instead of sending a frame as it is produced by the and
originating node, the tunneling protocol encapsulates the frame in an additional header.
The additional header provides routing information so that the encapsulated payload can
The encapsulated packets are then routed between tunnel endpoints over the
internetwork. The logical path through which the encapsulated packets travel through the
internetwork is called a tunnel. Once the encapsulated frames reach their destination on
the internetwork, the frame is decapsulated and forwarded to its final destination.
packets). Tunneling protocols generally use data encryption to transport insecure payload
VPNs using tunneling technology can be based on either a Layer 2 or a Layer 3 tunneling
Layer 3 protocols correspond to the network layer and use packets as their unit of
exchange.
IPSec (IP Security) is a standardized framework for securing Internet Protocol (IP)
Transport Mode
In transport mode only the payload (message) of the IP packet is encrypted. It is fully-
routable since the IP header is sent as plain text. Transport mode is used for host-to-host
communication.
In tunnel mode, the entire IP packet is encrypted. It must then be encapsulated into a new
The IPSec VPN is based on secure tunnel establishment between two peers.
data origin authentication of IP datagrams. It does not encrypt the data packet nor the
information, but merely creates a copy of the sensitive data transferred to check
against, ensuring that nothing has been illegally modified during transit .Further, it
can optionally protect against replay attacks by using the sliding window technique
and discarding old packets. AH tries to protect IP payload and all header fields of an
IP datagram except for mutable fields, i.e. those that might be altered in transit. AH
modified only slightly to include the new AH header between the IP header and the
protocol payload (TCP, UDP, etc.), and there is a shuffling of the protocol code that
links the various headers together. This protocol shuffling is required to allow the
IPSec headers have been validated, they’re stripped off and the original protocol type
The Encapsulating Security Payload (ESP) header provides origin authenticity, integrity,
and confidentiality of a packet. It works by encrypting the entire data packet, including
strongly discouraged because it is insecure. Unlike AH, the IP packet header is not
protected by ESP. (Although in tunnel mode ESP, protection is afforded to the whole
inner IP packet, including the inner header; the outer header remains unprotected.)
encapsulation of one network layer protocol (IP OR IPX) over another network layer
protocol (for example, IP). It is used to carry IP packets with private addresses, over the
service provider network using delivery packets with public IP addresses. In this case, the
delivery and payload protocols are compatible, but the payload addresses are
incompatible with those of the delivery network. GRE tunnels were designed to be
stateless i.e. the tunnel end-points do not monitor the state or availability of other tunnel
end-points. This feature helps service providers support IP tunnels for clients, who won't
know the service provider's internal tunneling architecture and it gives clients the
A GRE tunnel creates a virtual point-to-point link with routers at end points on an IP
internetwork.
end-to-end checksum. If the Key Present field of a GRE packet header is set to 1, the Key
field will carry the key for the receiver to authenticate the source of the packet. This key
must be the same at both ends of a tunnel. Otherwise, packets delivered over the tunnel
will be discarded. If the Checksum Present bit of a GRE packet header is set to 1, the
Checksum field contains valid information. The sender calculates the checksum for the
GRE header and the payload and sends the packet containing the checksum to the peer.
The receiver calculates the checksum for the received packet and compares it with that
carried in the packet. If the checksums are the same, the receiver considers the packet
intact and continues to process the packet. Otherwise, the receiver discards the packet.
A GRE-IPSec tunnel allows data packets like routing protocol, voice, and video packets
to be first encapsulated by GRE and then encrypted by IPSec, providing a very secure
VPN connectivity.
Layer 2 protocols correspond to the data-link layer and use frames as their unit of
exchange.
PPTP is a Layer 2 protocol that encapsulates PPP frames in IP datagrams for transmission
over an IP internetwork based. PPTP can be used for remote access and router-to-router
VPN connections.
PPTP uses a TCP connection for tunnel maintenance and a modified version of Generic
Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads
L2TP acts like a data link layer protocol for tunneling network traffic between two peers
L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or Asynchronous
Transfer Mode (ATM) networks. When configured to use IP as its datagram transport,
L2TP can be used as a tunneling protocol over the Internet. L2TP over IP internetworks
uses UDP and a series of L2TP messages for tunnel maintenance. L2TP also uses UDP to
send L2TP-encapsulated PPP frames as the tunneled data. The payloads of encapsulated
L2TP provides reliability features for the control packets, but no reliability for data
packets
L2TP relies on Internet Protocol security (IPSec) for encryption services. The
private data.
Encapsulation
A PPP frame (an IP datagram) is wrapped with an L2TP header and a UDP header. The
resulting L2TP message is then wrapped with an IPSec Encapsulating Security Payload
(ESP) header and trailer, an IPSec Authentication trailer that provides message integrity
and authentication, and a final IP header. In the IP header is the source and destination IP
Both PPTP and L2TP/IPSec use PPP to provide an initial envelope for the data, and then
append additional headers for transport through the internetwork. However, there are the
following differences:
With PPTP, data encryption begins after the PPP connection process (and,
association.
certificates.
Multi Protocol Label Switching (MPLS) is a data-carrying mechanism that belongs to the
generally considered to lie between traditional definitions of Layer 2 (Data Link Layer)
and Layer 3 (Network Layer), and thus is often referred to as a "Layer 2.5" protocol. It
was designed to provide a unified data-carrying service for both circuit-based clients and
packet-switching clients which provide a datagram service model. It can be used to carry
with similar and/or identical characteristics which may be forwarded the same way i.e.
they may be bound to the same MPLS label. The classification of FECs is very flexible. It
can be based on any combination of source address, destination address, source port,
destination port, protocol type and VPN or service requirements for a packet, such as low
latency.
A Forward Equivalence Class tends to correspond to a label switched path (LSP). The
reverse is not true, however an LSP may be (and usually is) used for multiple FECs.
The set of packets in an FEC are forwarded to the same next hop, out the same interface
A label is a short fixed length identifier for identifying a FEC. A FEC may correspond to
multiple labels in scenarios where, for example, load sharing is required, while a label
A label is carried in the header of a packet. It does not contain any topology information
a 1-bit bottom of stack flag. If this is set, it signifies that the current label is the
Multiprotocol Label Switching (MPLS) network. It is responsible for switching the labels
used to route packets. When an LSR receives a packet, it uses the label included in the
packet header as an index to determine the next hop on the Label Switched Path (LSP)
and a corresponding label for the packet from a look-up table. The old label is then
removed from the header and replaced with the new label before the packet is routed
forward.
An LSR consists of a Control plane which Implements label distribution and routing,
establishes the LFIB, and builds and tears LSPs and a Forwarding plane which forwards
An LER forwards both labeled packets and IP packets on the forwarding plane and
therefore uses both the LFIB and the FIB. An ordinary LSR only needs to forward
Label Edge Router is a LSR at the edge of an MPLS Network. When forwarding IP
datagrams into the MPLS domain, it uses routing information to determine appropriate
labels to be affixed, labels the packet accordingly, and then forwards the labeled packets
into the MPLS domain. Likewise, upon receiving a labeled packet which is destined to
exit the MPLS domain, the Edge LSR strips off the label and forwards the resulting IP
packet using normal IP forwarding rules. The router which first prefixes the MPLS
header to a packet is called an ingress router. The last router in an LSP, which pops the
Label switched path (LSP) means the path along which a FEC travels through an MPLS
network and is set up by a signaling protocol such as LDP. The path is set up based on
criteria in the forwarding equivalence class (FEC). An LSP is a unidirectional path from
the ingress of the MPLS network to the egress. It functions like a virtual circuit in ATM
or frame relay. Each node of an LSP is an LSR. Along an LSP, two neighboring LSRs are
Due to the forwarding of packets through an LSP being opaque to higher network layers,
Label Distribution Protocol (LDP) is a protocol for the purpose of distributing labels in
maintains LSPs. Using LDP two Label Switch Routers (LSR) exchange label mapping
information. The two LSRs are called LDP peers and the exchange of information is bi-
directional. LDP is used to build and maintain LSR databases that are used to forward
It is the software table maintained by IP/MPLS capable routers to store the details of port
MPLS packets.
It is a table created by a label switch-capable device (LSR) that indicates where and how
MPLS works by prefixing packets with an MPLS header, containing one or more 'labels'.
These short, fixed-length labels carry the information that tells each switching node
(router) how to process and forward the packets, from source to destination. They have
significance only on a local node-to-node connection. As each node forwards the packet,
it swaps the current label for the appropriate label to route the packet to the next node.
This mechanism enables very-high-speed switching of the packets through the core
MPLS network.
1) First, the LDP protocol and the traditional routing protocol (such as OSPF and ISIS)
work together on each LSR to establish the routing table and the label information
base (LIB) for intended FECs. Label Switch Routers in an MPLS network regularly
exchange label and reachability information with each other using standardized
procedures in order to build a complete picture of the network they can then use to
forward packets.
2) Upon receiving a packet, the ingress LER completes the Layer 3 functions,
determines the FEC to which the packet belongs, pushes the MPLS labels onto the
the packet presented to the LER already may have a label, so that the new LSR
packets to the next hop based on the topmost label of the packet and a corresponding
lookup in the label forwarding information base (LFIB). This includes the operation
In a swap operation the label is swapped with a new label, and the packet is
forwarded along the path associated with the new label. In a push operation a new
label is pushed on top of the existing label, effectively "encapsulating" the packet in
another layer of MPLS. This allows hierarchical routing of MPLS packets. Notably,
this is used by MPLS VPNs. In a pop operation the label is removed from the packet,
which may reveal an inner label below. This process is called "decapsulation". None
4) When the egress LER receives the packet, it pops the last MPLS label off packet and
MPLS networks establish Label-Switched Paths (LSPs) for data crossing the network. An
LSP is defined by a sequence of labels assigned to nodes on the packet’s path from
In hop-by-hop routing, each MPLS router independently selects the next hop for a given
Forwarding Equivalency Class (FEC). In the case of hop-by-hop routing, MPLS uses the
(IGPs) routing protocols such as OSPF etc. This process is similar to traditional routing
in IP networks, and the LSPs follow the routes the IGPs dictate.
In explicit routing, the entire list of nodes traversed by the LSP is specified in advance
and hence a tunnel is established. The path specified could be optimal or not, but is based
on the overall view of the network topology and, potentially, on additional constraints.
in the network to optimize use of bandwidth. In this case the path is called an explicitly
routed tunnel.
MPLS VPN is a family of methods for harnessing the power of Multiprotocol Label
Switching (MPLS) to create Virtual Private Networks (VPNs). The MPLS VPN solution
combines the best of both worlds (overlapping and peer VPN). Here the PE routers
participate in C-routing which allows for easy provisioning and optimum site-
connections. But the core routers do not need to carry much routing information. Only the
It can be used to replace existing physical links. The specification is based on the
Martini drafts, which define methods to transport layer 2 packets across MPLS
networks, and methods to encapsulate transport protocols such as ATM, Ethernet, and
SONET.
A layer 3 MPLS VPN, also known as L3VPN, combines enhanced BGP signaling,
MPLS traffic isolation and router support for VRFs (Virtual Routing/Forwarding) to
create a virtual network. This solution is more scalable and less costly than classic
concept of Virtual Routers (VRs are central to the concept of establishing a Layer 3
VPN.
The virtual router (VR) concept is functionally equivalent to a physical router, it must
support exactly the same mechanisms and tools and should appear for all purposes
router. Each virtual router has its own separate set of IP interfaces, forwarding table and
instances of routing protocols which guarantee isolation between different VPNs. Any
A VR-based VPN can be created by assigning interfaces that are attached to the VPN
customer sites and establishing a connection (e.g. ATM VC, Frame Relay DLCI) to
another system that also supports customers of the same VPN. Isolation of VPN routing
tables enables the overlapping of address spaces by different VPNs. We restrict the
establishment of VRs to the network edge and interconnect these VRs through the
the service provider core network. These tunnels may be configured either statically or
interconnect all the VRs from two PEs. The backbone VR connects each PE to a shared
backbone infrastructure, allowing the aggregation of VRs from multiple VPNs and
VPN membership information refers to the set of PEs that have customers in a particular
Multicast
A single PE may accommodate several different mechanisms for different VPNs. BGP
MPLS enables a single converged network to support both new and legacy
MPLS enables traffic engineering and supports QoS for service differentiation
Explicit traffic routing and engineering help squeeze more data into available
bandwidth.
Packets can be marked for high quality, enabling providers to maintain a specified
The forwarding of the packet is done based on the contents of the labels, which
at each hop.
In an MPLS network the FEC is determined only once, at the Ingress to an LSP,
Relay in the WAN, while reducing the need for encryption on public IP networks.
MPLS VPNs scale better than customer-based VPNs since they are provider-
customer.
Scalability: MPLS VPNs scale easily to thousands of users and sites since they do
automatically where the VPN is provisioned, and are unique for a given customer.
When there are long distance private lines, the MPLS backbone requires extra work in
configuring and managing the protocols that distribute labels. A provider with thousands
of PEs would incur a substantial operational burden in carrying and managing all the host
routes required by MPLS VPNs. Therefore long distance secure communication can be
packets across native IP networks in support of MPLS VPN services. Then solution like
traffic over IP networks. Like L2TP, L2TPv3 provides a ‘pseudo-wire’ service, but
MPLS and pure IP backbones. L2TPv3 adds important new features such as increasing
the session and tunnel ID space from 16 to 32 bits, which dramatically increases the
tunnel ingress/egress interface. Consequently, traffic does not need to be routed into the
tunnel by the provider’s router. As packets arrive at the interface, they are encapsulated
and forwarded directly toward the remote tunnel endpoint. Once received and de-
encapsulated, the original packet can be forwarded out of the egress interface if the tunnel
4.8.2 MPLS-over-L2TPv3
The 20-byte IP delivery header contains the sending and receiving PE routers’ IP
address
associated with each session ID. It allows remote or receiving PE routers to quickly
verify that each arriving packet was originated by a valid sending or source PE.
BGP/MPLS VPNs are network-based IPVPNs which allows service providers to use their
IP backbone in order to provide VPN services to their customers. BGP/MPLS VPNs use
BGP to distribute VPN routing information across the provider’s backbone and
BGP/MPLS network in implemented with the help of VPN Routing and Forwarding table
VPN routing and forwarding (VRF) table can be considered as the individual routing
tables of each of the VRs in a BGP/MPLS VPN network. Thus, VRFs allow overlapping
of customer addresses for different VPNs. The VRFs for different VPNs is identified
based on the Route distinguisher assigned by the service provider. Each VRF within a
A route distinguisher is an address qualifier used only within a single provider MPLS
Network used to distinguish the distinct VPN routes of separate customers who connect
to the provider. It is an 8-byte field prefixed to the customer's IP address. The resulting
needs to be configured to associate each route distinguisher with routes which lead to a
particular CE router. The PE router may be configured to associate all routes leading to
the same CE router with the same route distinguisher, or it may be configured to associate
different routes with different route distinguishers, even if they lead to the same CE
router.
The route distinguisher makes IPv4 prefixes globally unique. It is used only by edge
routers to identify which VPN a packet belongs to. For example, for a PE router to be
able to distinguish between the IP address 10.0.0.0 of one customer from the 10.0.0.0 of
another customer, the network administrator must add a unique route distinguisher to
each.
(6 bytes). The Type field determines the lengths of the Value field’s two subfields
field. The use of the public ASN space or the public IP address space guarantees that
each RD is globally unique. Globally unique RDs provide a mechanism that allows each
service provider to administer its own address space and create globally unique VPN-
IPv4 addresses without conflicting with the RD assignments made by other service
providers.
The service provider associates each interface with a VPN routing table.
A CE router advertises the site’s local VPN routes to the PE router, and learns remote
VPN routes from the PE router. PE routers exchange routing information with CE routers
using static routing, RIP, OSPF or EBGP. The PE router maintains VPN routing
information for those VPNs to which it is directly attached. This design eliminates the
need for PE routers to maintain all of the service provider’s VPN routes. Each customer
routers have the ability to maintain multiple forwarding tables that support the per-VPN
other PE routers using IBGP. Finally, P routers function as MPLS transit LSRs when
forwarding VPN data traffic between PE routers. Since traffic is forwarded across the
MPLS backbone using a two layer label stack, P routers are only required to maintain
routes to the provider’s PE routers; they are not required to maintain specific VPN
The operation of BGP/MPLS VPNs can be distributed into various phases. The various
At a PE, a VRF represents the context that is specific to an attached VPN; a VRF is
primarily associated to (is identified by) the one or more sub-interfaces through which the
The illustration below shows a Service Provider network attached to a number of sites
that represent 3 VPNs (Red, Blue and Green). Site 5 is part of two VPNs. In the
illustration all the VRFs have only one sub-interface but VRF Green at PE3 that has two
The other parameters that must be defined at VRF creation time are the route
distinguisher (RD) and the route targets (RT) for the Import and Export policies. These
parameters are used when the VPN private routes are distributed via the backbone to the
other sites. The RTs enable the distribution of VPN routes to the relevant remote sites.
For VPN sites to be attached and be operational, there are two prerequisites to be
sessions between PEs and the set-up of MPLS label switch paths between PEs.
Multi-protocol BGP must be used for the sessions between PEs. MP-BGP is required
because it enables routers to convey other routes than the classical 4-byte IPv4 routes.
VPN routes are not distributed within the backbone as IPv4 routes but are prefixed with
MPLS LSPs are unidirectional and therefore a pair of LSPs must be established between
PEs ( for QoS purposes, several pairs could be set-up with different queuing priorities ).
In the perspective of the data transfer phase number shown at the ingress side of the LSP,
represents the “outer” label. The labels shown at the egress side of a P router represents
is the penultimate hop in the path. LSPs are established using either LDP or RSVP.
The use of BGP for the distribution of VPN routes through the SP backbone and
establish LSPs.
The use of MPLS for the IP traffic forwarding itself, more exactly the transfer of
Distribution of VPN routes is shown in several phases. These processes occurs either
when a site is attached or detached (join and prune operations), or when some
CE to PE
From the customer perspective, routing occurs normally. Once agreed with the SP
which sites are parts of which VPN and what is the logical topology, the CE peers
with its PE and advertises its routes. The routing protocols may be interior routing
When the PE receives routes over a VRF sub-interface, it stores them in the
associated VRF. These local routes are at the classical IP format (and are stored as
such in the VRF). In the VRF, they are associated to the VRF sub-interface and are
assigned a label value. This label is known as the “VPN label” (also known as “inner
label” or “bottom label” in regards to its conveyance within the LSP). The VPN label
value is a PE’s local matter. It identifies the VRF sub-interface by which this route is
learned. Hence, routes learned over the same VRF sub-interface will have the same
label value. This will enable the PE when receiving traffic towards one of these routes
connectivity directly via the VRF that they share (Sites 6 and 7 in illustration). In the
figure, the VRF are “dimensioned” according to the number of routes they will
eventually contain. The local routes in the VRF are represented in plain colour.
PE to PE
Once the PE has learned local routes from its CEs, it will advertise them - via BGP -
to the other PEs, according to the Route Distinguisher and Export Route Target(s)
that were defined at VRF creation time. The VPN routes could not be conveyed as
such via BGP (since IP address overlapping can normally occur between VPNs)
otherwise only one route would be kept, thus making the others unreachable. Routes
are therefore prefixed with an 8-byte Route Distinguisher that typically consists of the
SP’s AS number plus the VPN identifier. Besides, the VPN label that was allocated to
each local route must also be conveyed with this route. The VPN routes will also be
flagged - as extended BGP community attributes - with their one or more Route
Targets. Finally, the Next Hop BGP attribute value is the (advertising) PE loopback
address itself.
An example of the VPN route distribution from PE3 to other PEs is shown in Figure
5.6. PE3 exports the local routes of its two VRFs according to the RD and Export RT
of each VRF. When PE1 and PE2 receive these BGP updates, they will filter the
labeled VPN routes according to the Import Policy of each of their VRFs, before
completing these VRFs with the relevant VPN routes. In the illustration the remote
routes in VRFs “Red” and “Blue” at PE1, as well as in VRFs “Red” and “Brown” at
PE2, are shown with a different pattern (with transversal lines). They are stored in the
VRF as IPv4 routes (the RD has been removed) along with the suitable interface and
label stack (where the outmost label represents the LSP ingress label enabling this PE
to reach the egress PE - as mentioned in the BGP Next Hop parameter - while the
inner label is the VPN label just received with this VPN route).
of all the PEs contain both their local routes as well as the remote routes.
PE to CE
When a VRF at a PE is updated with a remote route, it advertises this route to the
attached CEs that are associated to this VRF. As shown in Figure 5.7, there is then
full IP connectivity between the sites belonging to the same VPN. For example Site 1
has learned via its peer PE (PE1) the routes from Sites 4 and 8. Similarly, Site 5,
which is shared between VPN Blue and VPN Green, has learned routes from remote
Route distribution on the control plane has enabled the building of the VRFs and thus
prepared the transfer of IP traffic between sites. Figure 5.8 illustrates two simultaneous
data transfers: (1) from a host at Site 1 to, for example, some server at Site 4 (with IP
address 10.2.4.2); and (2) from a host at Site 3 to some other server at Site 5 (with IP
address 10.4.1.8).
When the IP packet with destination address 10.2.4.2 is received by PE1 from CE1, the
Red VRF is interrogated and the entry corresponding to 10.2/16 route indicates if_1a as
output interface, 12+2001 as label stack, as well as (not shown) a data link header. The
the label stack and the resulting frame is queued on the output interface. Similarly, when
the IP packet with destination address 10.4.1.8 is recieved by PE1 from CE3, the
Green VRF is interrogated and the entry corresponding to 10.4/16 route indicates
if_1a as output interface, 12+2002 as label stack, as well as (not shown) a data link
header. The label stack is inserted in front of the IP packet, the data link header is
inserted in front of the label stack and the resulting frame is queued on the output
interface.
The two frames are sent on the LSP egress path (PE1’s output interface: if_1a); at Px
router, the top labels are swapped (19 replaces 12) and the labelled packets forwarded
towards Py, which is the penultimate hop in the LSP. As a result, the outer labels are
popped and the packets sent towards PE2 with only the inner label in front. At egress
PE2, the relevant VRF sub-interface is retrieved from the VPN label and the original
IPv4 packet is finally forwarded to the CE enabling us to reach the server within the site.
6.1 INTRODUCTION
Remote client sites in the Tulip VPN Service were connected using wireless last mile.
Wireless last mile connectivity is provided with the help of Point of Presence (PoP) or the
base stations which are installed at various locations. These PoPs are connected to the
core backbone network using fibers or sometimes wireless connections. The remote client
sides are connected to this PoP using wireless radios and antenna. This intern gives them
a connection to the backbone network. Radios communicate with each other using radio
Operating the client site with the help of one base station radio at the Pop end and one
Operating multiple remote sites using a single radio at the PoP and one each at the
The base stations or PoPs are connected with the core network using optical fibers or
redundant RF links. This connectivity is provided with the PoP end router. This router is
intern connected to a switch. The radios in the base station are connected to this switch at
At the client side, we have an antenna installed which is again connected to the client end
radio using a pigtail cable. The client end radio is connected to the client router via a PoE
(Power over Ethernet) device which provides DC voltage to power the modem. The
transmitted using the antenna. The client end antenna receives this signal and the client
6.3 RADIOS
Wireless last mile connectivity is established with the help of Radios and antennas. Based
on the purpose and requirements different radios were used at Tulip. Each of the radio
procedure.
6.3.1 Airspan
These use IP technology and have an operating range in excess of 20 kilometers line of
sight (LOS) and around 3 kilometers of Non Line of Sight (NLOS). It is capable of
delivering data speeds up to 3.2 Mbps to each customer with a support for Quality of
Service (QoS) and Bandwidth on Demand (BoD). Variety of network topologies are
supported, including P2P, Point to Multipoint (PMP) for traditional Wireless Local Loop
Airspan supports Time Division Duplex (TDD) operation in the unlicensed band and both
Frequency Division Duplex (FDD) and TDD modes of operation in the licensed band
module providing a 9 pin D-type port for RS-232 serial interface and a 15 pin D-type
port for data, synchronization, and power interfaces. The BSR is available in two
models - with an integral antenna or with two N-type ports for attaching up to two
external antennas.
The radio at the client end is known as the SPR. It is an encased outdoor radio module
providing access to a 15 pin D-type port for Ethernet, serial, and power interfaces.
The SPR model is also available in two models - with an integral antenna or with an
The radios can either be configured in bridge mode or in routing mode. It allows full
remote and local management through Simple Network Management Protocol (SNMP)
6.3.2 Radwin
These radios are primarily used in the backbone to provide redundant backbone RF links
to the fiber network. The system provides up to point to point 48 Mbps wireless link and
supports range up to 80 km. It combines legacy TDM and Ethernet services over 2.4 GHz
and 5.x GHz license exempt bands. Operation over 2.4GHz and 5.x GHz bands is not
affected by harsh weather conditions, such as fog, heavy rain etc. Radwin employs Time
Division Duplex (TDD) transmission. This technology simplifies the installation and
configuration procedure. There is no need to plan and to allocate separate channels for
6.3.3 Firepro
These radios can be used for both point to point and point to multi-point wireless
of up to 2 Mbps in a dedicated fashion and supports network range upto 60 kms. It can
be configured in bridging and routing modes. The main advantage of Firepro is that it can
It allows full remote and local management through SNMP using the tool WinBox.
CHAPTER 7
TROUBLESHOOTING
network from the Service Provider point of view. When the network devices are more
and the network is widespread, local management is tedious and impossible. Therefore,
there arises the need to manage the network remotely. This is enhanced by SNMP.
At the Network Operation Centre (NOC) of Tulip, various VPN client links were
remotely monitored and logical link problems were remotely fixed. Various tools were
schema, and a set of data objects. SNMP is based on the manager/agent model consisting
SNMP devices and the network protocol. The SNMP manager provides the interface
between the human network manager and the management system. The SNMP agent
provides the interface between the manager and the physical device(s) being managed.
The SNMP network management is composed of three parts to which both the
specify the format for defining managed objects or the devices that are accessed
using SNMP.
SNMP TRAP message allows the agent to spontaneously inform the SNMP manager
of an "important" event.
manager when it wants to retrieve some data from a network element. For example,
the Network Management System (NMS) might query a router for the utilization on a
WAN link every 5 minutes. It could then create charts and graphs from that data, or it
could warn the operator when the link was over utilized.
GET-NEXT message to the manager, with either the information requested or error
indication
when it wants to change data on a network element. For example, the Netwotk
Management System may wish to alter a static route on a router. The agent would
accomplished.
In the Network Operation Centre (NOC) of Tulip Telecom, my role was that of a Level1
(L1) member. The task of an L1 member is to proactively monitor and manage the
network links and provide first level troubleshooting, in case a customer’s remote VPN
link is down or some problems in the connectivity are being faced. For the remote
monitoring fault identification in the client link various tools are used. The following
flowchart illustrates the hierarchy followed for link troubleshooting in Tulip NOC.
1) Each team has respective team leaders which handle different clients. Handling of
these clients is the responsibility of the L1 Engineers. The teams are also referred to
as the Access Teams. The entire network is managed from Delhi NOC.
2) To every call of client fault ticket number is raised and basic troubleshooting is done
7.3 TOOLS
Telnet is a part of the TCP/IP protocol suite that allows virrtual terminal emulation. It
allows a user on a remote client machine, called the Telnet client, to access the resources
of another machine, the Telnet server. These emulated terminals are of the text-mode
type and can execute refined procedures like displaying menus that give users the
opportunity to choose options from them and access the applications on the duped server.
Users begin a Telnet session by running the Telnet client software and then logging into
Telnet allows for remote configuration and/or check up on the routers or switches without
Host Monitor is a Windows based system management tool for monitoring server
availability and performance 24/7 used for pro-active monitoring. It sends an alert a
monitored device does not respond to a test using your own parameters, and can take any
Web Service, Telnet Service and Remote Control Console simplifies remote
management
using Remote Monitoring Agents for Windows, Linux, Solaris etc. we may easily
HostMonitor can check any TCP service, ping a host, check a route, monitor Web, FTP,
Mail, DNS servers. It can check the available disk space, monitor size of a file or folder,
check integrity of the files and web site. HostMonitor is a network administration
notifications alert people near the machine. E-mail and pager notifications inform a wider
range of remote operators. HostMonitor can take actions that are designed to recover
from a failure automatically without human intervention (e.g. "restart service", "reboot
computer" actions).
Host Monitor was used in the NOC for active monitoring of network links and in order to
7.3.2 WipManage
WipManage enables local remote management of the Airspan system and every unit
within the system. WipManage can access every unit using a top-down hierarchy. At the
top of the hierarchy are the base stations. From the base stations the system manager can
WipManage uses SNMP and TFTP to perform the following tasks on an airspan system
Installation
Configuration
Trap management
Fault management
Performance Monitoring
feature per element or per many elements simultaneously (multi device operation)
WipManage is location-independent and can be used to manage any Airspan unit in the
WipManage was primarily used in the NOC for the connection and performance
monitoring of RF links and the BSR and SPR. These included checking the BER (Bit
Error Rate) and the Received Signal Strength Indication (RSSI), which is a measurement
traffic load on network links. It allows the user to see traffic load on a network over time
in graphical form. MRTG is written in Perl and works on Unix/Linux as well as Windows
MRTG uses the Simple Network Management Protocol (SNMP) to send requests with
two object identifiers (OIDs) to a device. The device, which must be SNMP-enabled, will
have a management information base (MIBs) to lookup the OID's specified. After
collecting the information it will send back the raw data encapsulated in an SNMP
protocol. MRTG records this data in a log on the client along with previously recorded
data for the device. The software then creates an HTML document from the logs,
Features
Gets its data via an SNMP agent, or through the output of a command line.
Typically collects data every five minutes (it can be configured to collect data less
frequently).
Creates an HTML page per target that features 4 graphs (GIF or PNG images).
Results are plotted vs time into day, week, month and year graphs, with the I
Automatically scales the Y axis of the graphs to show the most detail.
Adds calculated Max, Average and Current values for both I and O to the target's
HTML page.
In the NOC, MRTG was primarily used to check if the high latencies and drops in the
Paessler Router Traffic Grapher (PRTG) is a network monitoring and bandwidth use
software for Microsoft Windows by Paessler AG. With PRTG bandwidth usage of a
network can be monitored and classified using the three most common bandwidth data
acquisition methods:
SNMP: Reads traffic counters of network devices like switches, routers and
servers
Packet Sniffer: Looks at all data packets travelling through a network using the
promiscuous mode and analyzes the network packets to find out the IP addresses,
Using SNMP not only bandwidth usage but also many other network readings (e.g. CPU
The usage data is constantly recorded and the historic data can be analyzed e.g. with data
tables for usage billing and graphs for trend analysis via a web server interface and in a
Windows GUI.
client. The PRTG graphs were used to confirm if the latencies and drops faced in a
VNOC is a software developed by Tulip. The main motto of VNOC is to enable proactive
monitoring system. Any link which is flapping or is not up will be reflected immediately
stipulated time, if no action is taken a ticket is further logged automatically. This along
CHAPTER 8
Tulip provided a variety of VPN services to its clients. Two of the circuits that were
Tulip provided last mile connectivity to Reliance customers at Layer 2. In this case Tulip
8.1.1 Working
Frames from the client end are tagged at the SPR end.
L2TPV3 (Xconnect) tunnel is created from that router port (in which 2950 is
terminated) till the LAN side port of Cisco 7200 in Okhla office.
Again L2 traffic is terminated in a trunk port of Cisco 4500 switch at Okhla side.
In turn Cisco 4500 is connected via trunk ports to Reliance Attrica and traffic is
1) The tagged frame reaches the remote Tulip POP and lands on the trunk port.
2) The trunk port throws the frames on router via another trunk port.
X-Connect.
4) The frame now lands on the LAN port of main Tulip POP router where X-connect
ends. Here the X-connect throws the frame on the trunk port of Tulip switch.
5) Tulip switch in turn throws it via another trunk port on the RF which is configured in
6) RF link is the interconnect link between Reliance Base Transceiver Station and Tulip
At the time of installation, we make sure that we allow only SPECIFIC VLANs at all the
trunk ports. They are not configured in default mode allowing all the VLANS
8.1.2 Troubleshooting
To illustrate the troubleshooting procedures, let us assume that the SPR is being tagged
by a VLAN Tag-777. Suppose now we get a call from customer that the link is not
a) Visit the client site and terminate the link in the laptop/machine.
b) Assign the Customer router WAN port IP, also known as CE IP to the laptop.
c) Ping the Reliance PE IP (Given at the time of installation along with VLAN TAG and
CE IP)
d) If we are able to ping then the problem is with client router or LAN which is
can use the router CE IP for further tests or we can keep it terminated and
remove the VLAN 777 from the trunk port of Tulip switch in which the link is
f) Now RF link from the CE router is removed so that when we use the CE IP for
g) Assuming that we are not able to ping even from the laptop after assigning it the
CE IP, then we need to check the last mile RF link for proper TAG configuration.
h) When we check the client end radio for TAG configuration, we need to change
i) After making sure that RF last mile and tagging is proper then we keep the link
unterminated (or remove specific VLAN as mentioned above) and move to the POP
j) Get an ACCESS port against VLAN 777 created in the switch (in which link is
k) Assign the CE IP to the laptop and try to ping the Reliance PE IP.
l) If we are able to ping then clearly the problem is in RF last mile, if not then
clearly problem is beyond Tulip remote POP where we are doing the
troubleshooting.
m) If we are able to ping PE and have concluded that problem is in last mile then
we concentrate on last mile and troubleshooting that should not be an issue, however
n) Before moving beyond we must make sure that last mile is absolutely fine .
p) If the last mile RF is absolutely fine then our laptop IP should collide with CE router
q) As soon as this happens, we know that last mile is working, since we have already
tested trying PE IP from POP and we were unsuccessful in that. So we can now
assign PE IP to the laptop (since connectivity with Reliance is not working so it won’t
r) Now the big problem still remains and i.e. we are not able to ping the Reliance PE
from the remote POP. There can be some issue with Reliance itself. So we create an
access port against VLAN 777 in the Tulip main POP switch in which
interconnect is terminated.
t) Remove the client end RF link from CE router and use the CE IP again on the
v) If we are not able to ping then clearly the issue is in Interconnect or reliance side.
w) Suppose other Reliance L2 circuits are perfectly working then obviously the problem
is with Reliance end. If this is the only circuit then the integration of Tulip main POP
x) Now suppose we are not able to ping Reliance PE IP from the access port of main
POP switch, then we first make sure that part of L2 circuit inside Tulip network is
working fine. To do this we assign Reliance PE IP to the laptop (it won’t collide as
the logical connectivity with Reliance is already not working) and revert the client
network is working fine. Otherwise there may be a major problem as we are neither
able to reach Reliance PE nor Customer CE. This can also happen when access port
to which we are connected is not working or some issue with laptop or connectivity
z) If we are able to ping CE IP using Reliance PE IP on laptop, then we now know that
Reliance.
Again if many links are working through this interconnect and only this PE IP is
not working then it is evidently Reliance end problem. However if this is the only link
currently live via Interconnect and we are not able to figure out whether Interconnect RF
is passing the VLAN then we simply arrange a standalone cisco 2950 or any manageable
switch and put it in Reliance Base Transceiver Station, terminate the RF link (otherwise
terminated in Reliance switch trunk port) in the trunk port of arranged switch. Create an
access port against VLAN 777 and try pinging the CE Router IP. If we are able to ping
8.2 INDIABULLS
POP Routers
8.2.1 Working
Indiabulls was one of the clients who were provided Layer 3 VPN Services. The network
considering only a few locations for the sake of simplicity. We see the Indiabulls Head
Office located at Gurgaon, to which for which the primary link was provided through RF
from Gurgaon Sector 18 POP. MPLS tunnel is provided to the Head Office using NDEL
7206 router. The regional offices are connected to the nearest Tulip POP using RF
connectivity. A logical GRE tunnel is established from these CE routers to the PE routers
in the MPLS cloud. Thus, all the packets to the Head Office travel through the Tulip
MPLS cloud. This provided intranet VPN among various offices of Indiabulls. The Tulip
8.2.2 Troubleshooting
1) First we check router IP. If it is not pinging then get checked the cable from modem
3) If BSR IP is not pinging then the call is assigned to support engineer and the regional
NOC.
4) In case if all these are working fine then we go for logical checking. We check end to
end ping of tunnel from client to HO & vice versa as well as check end to end MPLS
5) In case of latency & drops we check RF parameter as well check utilization of client
on PRTG. In case of RSSI & BER problem, we coordinate with field engineers.
CHAPTER 9
9.1 DISCUSSION
We have studied the enabling technologies for both Layer 2 and Layer 3 site to site VPNs.
Both have their advantages and disadvantages. It is clear that the setup and provisioning
of a VPN service is not a straightforward process due to the large number and diversity of
components involved. The wide range of available technologies and the number of VPN
variants make the design of an IPVPN solution a nontrivial task. From the point of view
a number of factors depending on is the service provider willing to manage a high number
(potentially hundreds) of VPN routing tables or does he prefer to push this responsibility
to the customers and the kind of approach used by the service provider to manage and
control QoS and if the present customer’s corporate network based on a layer 2 VPN (e.g.
Frame Relay, ATM). Also layer 2 and layer 3 VPNs are not mutually exclusive. As was
mentioned before, the same MPLS-based backbone allows the deployment of both VPN
models simultaneously.
IPsec and MPLS are undoubtedly the two main enabling technologies to build Layer 3
VPNs. While IPsec is particularly suited to handle security since it is the only VPN
technology to support data encryption, it can be deployed over any IP-based network and
is only limited by the scope of the service provider network domain. MPLS is mainly
oriented to cope with such requirements as scalability, traffic engineering and QoS control
and is the only feasible solution to support large scale IPVPN implementations. However,
place in the service provider networks. IPsec is the natural choice for small enterprise
In certain VPN scenarios, both IPsec and MPLS can be used as complementary
technologies. IPsec should be used in those cases where strong authentication and
confidentiality are required (typically, remote VPN access through the public Internet or
implementations.
Several methods to implement the VPN models have been discussed. However, in the future a lot
has to be done regarding the internetworking of different solutions. The multi-provider scenarios
available so far cover only the case where multiple MPLS domains support the same VPN type
Also, so far VPN solutions have dealt primarily with IPv4 at the network layer level. As IPv6
comes into implementation, the definition of IPv6 VPN address family would be required. Also an
already existing MPLS backbone would need to upgrade the PE routers to support IPv6 VPN
customers. Further user mobility, fostered by IPv6 and the dissemination of wireless terminals,
will be crucial requirement in future corporate networks. Up to now, mobility issues have been
Multicast is presently an essential feature in a high number of corporate networks and this trend
will likely increase in the future. For BGP/MPLS VPNs, based on BGP extensions, multicast
support is not so straightforward as of now. A lot of work needs to be done in this avenue as well.
9.3 CONCLUSION
VPNs have become the de facto standard today for corporate site to site connectivity with
significant cost savings and flexibility coupled with security, reliability and assured level
of service guaranteed by VPN Service Providers as per the Service Level Agreements.
The relatively new VPN technology in the form of MPLS VPNs has been specially
emphasized on. With the help of Tulip Telecom, one of the largest VPN providers in
India, practically working on live MPLS VPN customer connections in the form of remote
VPN management and troubleshooting gave me a logical insight to the VPN enabling
technologies and the problems associated with it. We saw that MPLS addresses issues
related to scalability and routing (based on QoS and service quality metrics) and can exist
over existing ATM and frame-relay networks. IPSec and L2TPv3, coexisting with MPLS
will play an important role in the routing, switching, and forwarding of packets securely
through the next-generation network in order to meet the service demands of the users.
This project was an enlightening one, giving an insight into the latest VPN technologies
REFERENCES
1. Davie B. and Rekhter Y., MPLS Technology and Applications, Morgan Kaufmann
Publishers
3. Lammle, Todd, Cisco Certified Network Associate Study Guide, Wiley Publishing
Inc.
5. Repiquet, Joël, White Paper, Keep it Simple with BGP/MPLS Virtual Private
Networks
Professional
7. www.wikipedia.org, Internet
8. www.vpnc.org, Internet
9. www.cisco.com, Internet