VPN Connectivity Management Report

NETWORKING - VPN CONNECTIVITY AND THEIR
MANAGEMENT
A project report submitted
to
SIKKIM MANIPAL INSTITUTE OF TECHNOLOGY

(A CONSTITUENT INSTITUTE OF SIKKIM DEEMED UNIVERSITY)
For Partial Fulfillment of the Requirement for the

Award of the Degree
of
BACHELOR OF TECHNOLOGY
in
ELECTRONICS AND COMMUNICATION ENGINEERING

by
VARUN LAKHOTIA
( 200412136 )
Under the Guidance of
Mr. PUNEET KHANNA

Sr.Network Engineer, Tulip Telecom
&
Dr. SUSHABHAN CHOUDHURY

Professor, Department of Electronics and Communication Engineering

MAJITAR, RANGPO, EAST SIKKIM - 737132

MAJITAR, RANGPO, EAST SIKKIM - 737132
CERTIFICATE
This is to certify that the project titled NETWORKING VPN
CONNECTIVITY AND THEIR MANAGEMENT is a bonafide work of
VARUN LAKHOTIA
200412136
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
Mr. Puneet Khanna

Sr.Network Engineer
Tulip Telecom
New Delhi
Dr.Sushabhan Choudhury
Professor
Department of ECE
SMIT, Majitar
Dr. (Prof.) R.N.Bera

Head Of Department,
Department of ECE
SMIT, Majitar
ACKNOWLEDGEMENT
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
inputs helped me immensely in completing this project.
I would also like to show my deep sense of gratitude to my team members Mr.Prashaant
Sadeeza, Ms.Payal Sharma, Mr.Rahul Mishra and Mr.Abhro Roychoudhary at Tulip
Telecom, Delhi who helped me in ways of encouragement, suggestions and 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
this great opportunity of industrial training at Tulip Telecom.
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,
suggestions and guidance during this entire period.
I extend my heartiest thanks to Prof R.N. Bera (HOD, Electronics and
Communication Engineering, SMIT) for giving me the opportunity to undergo this
industrial/project training at Tulip Telecom, New Delhi.
And last, but not the least, I would like to thank the people at Tulip TELECOM for
being so cordial and cooperative throughout the period of my training.
ABSTRACT
Tulip Telecom is the largest MPLS based VPN provider in India and has been the frontrunner in provisioning and managing of multi location wide area network VPNs using
last mile wireless connectivity.
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 Internet or a shared service provider network.
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
for site to site VPN implementation.
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
remotely monitored and managed by me as an L1 trainee at the Network Operations
Centre(NOC) of Tulip Telecom is presented.
ii
TABLE OF CONTENTS
Page
ACKNOWLEDGEMENT.
ABSTRACT ...
ii
LIST OF FIGURES
viii
ABBREVATIONS .
CHAPTER 1
ABOUT TULIP TELECOM
1.1
Company Profile..
1.2
Company Objectives...
1.3
Infrastructure
1.4
Network Architecture.
1.4.1
The Core and Aggregation Network.. .
1.4.2
The Customer Access Network. .
1.5
Network Management. .
1.6
Services Offered.. .
CHAPTER 2
VIRTUAL PRIVATE NETWORK (VPN)
2.1
Introduction...
2.2
Need for VPN...
2.3
Basic VPN Requirements....
2.4
VPN Devices and Terminology...
2.5
VPN Configurations......
2.6
VPN Models..
11
iii
2.6.1
Overlay VPN Model
11
2.6.2
Peer-to-Peer VPN Model.
11
2.7
Approaches to VPN.
13
2.8
VPN Enabling Protocols and Technologies
14
CHAPTER 3
TUNNEL BASED VPNs
3.1
Tunneling.....
15
3.2
Layer 3 Tunneling Protocols.......
16
3.2.1
16
IPSecurity (IPSec)...
3.2.2
Generic Routing Encapsulation (GRE)..
20
3.2.3
3.3
GRE-IPSec Tunnel..
21
Layer 2 Tunneling Protocols...
22
3.3.1
Point-to-Pont Tunneling Protocol (PPTP)..
22
3.3.2
Layer 2 Tunneling Protocol (L2TP)...
23
3.3.3
L2TP/IPSec..
24
3.3.4
PPTP Compared to L2TP/IPSec.
25
CHAPTER 4
MULTI PROTOCOL LABEL SWITCHING (MPLS)

AND VPNs
4.1
Introduction to MPLS..
26
4.2
MPLS Concepts and Components..
27
4.2.1
Forwarding Equivalence Class (FEC)
27
4.2.2
MPLS Label.
28
4.2.3
Label Switch Router (LSR).
29
iv
4.2.4
Label Edge Router (LER).
30
4.2.5
Label Switched Path (LSP)..
30
4.2.6
Label Distribution Protocol.
30
4.2.7
Label Information Base (LIB)....
30
4.2.8
Label Forwarding Information Base (LFIB)..
31
4.3
MPLS Operation.
31
4.4
Routing in MPLS..
33
4.4.1
Hop-by-Hop Routing..
34
4.4.2
Explicit Routing..
34
4.5
MPLS Based Virtual Private Networks (MPLS VPNs)..
34
4.6
Virtual Router (VR) Concept in MPLS VPN.
35
4.6.1
VR VPN Implementation...
36
4.6.2
VPN Auto-Discovery.
37
4.7
Application of MPLS..
38
4.8
MPLS and L2TPv3..
39
4.8.1
Layer 2 Tunneling Protocol version 3 (L2TPv3)..
40
4.8.2
MPLS-over-L2TPv3
41
CHAPTER 5
5.1
BGP/MPLS VPN NETWORKS
Implementation of the Virtual Router Concept..
43
5.1.1
VPN Routing and Forwarding Tables (VRFs)...
44
5.1.2
Route Distinguisher (RD)...
44
5.2
Network Architecture
45
5.3
Operation and Illustration of a BGP/MPLS VPN...
46
5.3.1
49
VPN Route Distribution in Control plane..
5.3.2
VPN Data Forwarding in Data Plane..
CHAPTER 6
54
WIRELESS LAST MILE REMOTE SITE

CONNECTIVITY
6.1
Introduction..
56
6.2
Remote Site Connectivity....
57
6.3
Radios..........
58
6.3.1
Airspan....
58
6.3.2
Radwin.
60
6.3.3
Firepro..
60
CHAPTER 7
REMOTE NETWORK MONITORING AND

TROUBLESHOOTING
7.1
Simple Network Management Protocol (SNMP)...
61
7.1.1
63
SNMP Messages......
7.2
Role of L1 Member in NOC......
63
7.3
Tools.
65
7.3.1
Telnet Client....
65
7.3.2
Host Monitor
65
7.3.3
WipManage..
67
7.3.4
Multi Route Traffic Grapher (MRTG)...
70
7.3.5
Paessler Route Traffic Grapher (PRTG)....
71
7.3.6
Virtual NOC (VNOC)..
73
CHAPTER
CLIENT CASE STUDIES
vi
8.1
8.2
Reliance L2 Circuits........
74
8.1.1
Working...
75
8.1.2
Troubleshooting..
76
Indiabulls..
80
8.2.1
Working...
80
8.2.2
Troubleshooting..
81
CHAPTER
DISCUSSION AND FUTURE SCOPE
9.1
Discussion........
82
9.2
Future Scope and Improvements
83
9.3
Conclusion
84
vii
LIST OF FIGURES
Figure
Title
Page
1.1
Tulip Network Architecture.
2.1
VPN Defined
2.2
Customer and Provider Network Devices..
2.3
Remote Access and Site to Site VPNs
10
2.4
VPN Overlay and Peer Model....
12
2.5
Approaches to VPN
13
2.6
VPN Enabling Protocols and Tehnologies.
14
3.1
Tunneling.
16
3.2
AH in Transport Mode
18
3.3
ESP in Tunnel Mode...
19
3.4
GRE Encapsulated Packet Format..
20
3.5
GRE-IPSec Tunnel Application..
21
3.6
Structure of a PPTP Packet Containing User Data.
22
3.7
Structure of a L2TP packet Containing User Data....
23
3.8
Encryption of an L2TP packet with IPSec ESP.
24
4.1
A MPLS Network....
26
4.2
MPLS Label Format.......................
27
4.3
Structure of a LSR.......................................................................... .......
29
4.4
Structure of a MPLS Packet............................................................
31
4.5
Packet Transfer using MPLS.......................................................... .......
32
4.6
VR VPN Reference Model............................................................. .......
36
viii
4.7
Figure
VR VPN with Direct Connectivity between VRs..

Title
37
Page
4.8
VR VPN with a Backbone VR...
37
4.9
L2TPv3 Packet Transfer Mechanism.
40
4.10
MPLS-over-L2TPv3 Encapsulation
41
5.1
Layered view of a BGP/MPLS VPN..
43
5.2
Network Architecture of a BGP/MPLS Network..
45
5.3
BGP/MPLS VPN Routing and Forwarding Tables (VRFs)...
47
5.4
PE-to-PE pre establishment of iBGP sessions and LSPs..
48
5.5
CE to PE Route Distribution...
50
5.6
PE to PE Route Distribution...
52
5.7
PE to CE Route Distribution..
53
5.8
Data Forwarding across the Backbone..
54
6.1
A Typical Wireless Last Mile Remote Site Connectivity.
57
6.2
AirspanBSR...
59
6.3
AirspanSPR...
59
7.1
Manager-Agent model used in SNMP..
62
7.2
Hierarchy followed for Link Troubleshooting.
64
7.3
Host Monitor Interface..
66
7.4
WipManage Interface
68
7.5
SPR BER Performance Monitoring..
69
7.6
SPR RSSI Performance Monitoring.
69
7.7
PRTG Graph showing Bandwidth Utilization.
72
7.8
Proactive Monitoring and Fault Logging by VNOC
73
8.1
Reliance L2 Network Connectivity with Fiber interconnect.. .
74
8.2
Reliance L2 Network Connectivity with RF interconnect .
75
ix
8.3
Basic Indiabulls VPN Network Connectivity Layout.
ABBREVIATIONS
AH
Authentication Header
AS
Autonomous System
ATM
Asynchronous Transfer Mode
BER
Bit Error Rate
BGP
Border Gateway Protocol
BoD
Bandwidth on Demand
BSR
Base Station Radio
BTS
Base Transceiver Station
CE
Customer Edge
CPE
Customer Premises Equipment
DC
Direct Current
DS3
Digital Signal 3
EBGP
External Border Gateway Protocol
ESP
Encapsulation Security Protocol
FDD
Frequency Division Duplex
FEC
Forward Equivalence Class
FTP
File Transfer Protocol
GRE
Generic Routing Encapsulation
HTML
Hyper Text Markup Language
iBGP
Internal Border Gateway Protocol
IGP
Interior Gateway Protocol
80
IP
Internet Protocol
IPSec
Internet Protocol Security
ISIS
Intermediate System to Intermediate System
ISP
Internet Service Provider
IT
Information Technology
L2F
Layer 2 Forwarding
L2TP
Layer 2 Tunneling Protocol
L2TPv3
Layer 2 Tunneling Protocol version 3
L2VPN
Layer 2 Virtual Private Network
L3VPN
Layer 3 Virtual Private Network
LAN
Local Area Network
LDP
Label Distribution Protocol
LER
Label Edge Router
LFIB
Label Forwarding Information Base
LIB
Label Information Base
LOS
Line of Sight
LSP
Label Switched Path
LSR
Label Switch Router
MAC
Media Access Control
MIB
Management Information Base
MMP
Multipoint-to-Multipoint
MPLS
Multi Protocol Label Switching
MRTG
Multi Router Traffic Grapher
xi
NBVPN
Network Based Virtual Private Network
NI
Network Integration
NLOS
Non Line of Sight
NMS
Network Management System
NOC
Network Operation Center
OSI
Open System Interconnection
OSPF
Open Shortest Path First
P2P
Point to Point
PE
Provide Edge
PMP
Point to Multi Point
PoE
Power over Ethernet
POP
Point of Presence
PPP
Point to Point Protocol
PPTP
Point to Point Tunneling Protocol
PRTG
Paessler Router Traffic Grapher
QoS
Quality of Service
RD
Route Distinguisher
ASN
Autonomous System Number
RF
Radio Frequency
RIP
Routing Information Protocol
RSSI
Received Signal Strength Indication
RSVP
Resource Reservation Protocol
RT
Route Target
xii
SLA
Service Level Agreement
SMI
Structure of Management Information
SNMP
Simple Network Management Protocol
SONET
Synchronous Optical Network
SP
Ser vice Provider
SPR
Subscriber Premises Radio
STM
Synchronous Transport Module
TCP
Transmission Control Protocol
TDD
Time Division Duplex
TDM
Time Division Multiplexing
TFTP
Trivial File Transfer Protocol
TTL
Time to Live
UDP
User Datagram Protocol
VC
Virtual Circuit
VLAN
Virtual Local Area Network
VNOC
Virtual Network Operation Centre
VPN
Virtual Private Network
VR
Virtual Router
VRF
Virtual Private Network Routing and Forwarding Table
WAN
Wide Area Network
xiii
xiv
CHAPTER 1
ABOUT TULIP TELECOM

1.1
COMPANY PROFILE
Tulip Telecom Limited is a data telecom service and IT solutions provider that offers
innovative IP based infrastructural solutions to its customers. Tulip is Indias largest
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
consulting services to enterprises.
Tulip, today, is the only service provider in its domain that provides customers with endto-end connectivity services include network integration, bandwidth as well as managed
services.
1.2
COMPANY OBJECTIVES
Provide end to end managed data services to include Data Connectivity,

equipment and managed network services to meet all data connectivity
requirements of customers.
Be the trusted advisor of the customers for all their data connectivity / networking
needs.
Department of Electronics and Communication, SMIT
Grow the business rapidly while maintaining the highest quality of service.
Impact the rural economy by providing connectivity right upto to the last village.
INFRASTRUCTURE
1.5
Tulip's IP/MPLS network is a carrier grade infrastructure built using state-of-the-art

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 copperbased last mile connectivity provided by incumbent service providers. Tulip also offers
customer premises connectivity over fiber for high speed bandwidth applications. Tulip's
IP/MPLS network is designed with 'no-single-points-of-failure' architecture. All critical
equipment and links are deployed in redundant mode.
The entire Tulip Network Infrastructure is designed to ensure the following:
Highest redundancy levels to ensure no single point of failure.
Highest levels of scalability to handle both geographic expansions and bandwidth

growth
Flexibility in solution design, implementation and expansion through the use of

multiple technologies.
End-to-end assured network security.
End-to-end assured quality of service
1.4
NETWORK ARCHITECTURE
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.
1.4.1
The Core & Aggregation Network
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.
Fig. 1.1 Tulip Network Architecture
1.4.2
The Customer Access Network
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
network nationwide with thousands of wireless links in operation today. Advanced
wireless technologies are innovatively being used reach out to our remotes customers.
1.5
NETWORK MANAGEMENT
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
to proactively detect, diagnose and resolve network problems
1.6
SERVICES OFFERED
A vast portfolio of services is enabled on the carrier-grade Tulip network. Using the latest
state-of-the-art technology and solutions.
Layer 3 MPLS VPN : Fully managed hub-and-spoke and full-mesh VPN for
secure and flexible any-to-any connectivity. MPLS VPNs allow connecting
virtually any type of customer networks seamlessly across different locations.
Layer 2 MPLS VPN: MPLS based Virtual Leased Line solutions with flexible
bandwidth configurations. Multiple Layer 2 technologies are supported including
Ethernet, PPP, Frame Relay and ATM.
IP VPN Services: Secure point-to-point and multipoint IP connectivity using

IPSec and GRE tunneling.
Internet Access Services: High speed internet access at any of 800 locations in
India.
Managed Security Services: Provide network-wide protection from attacks and

intrusions through centralized and distributed managed firewalls.
Dial Back-up Services: In case of primary link failure, last mile back-up
connectivity using ISDN is available for customers.
Video conferencing: Point-to-point and multi-point video conferencing
Multicast VPN: Multicast traffic carriage within VPNs
Data Center Solutions: Tulip offers co-location and hosting services in its stateof-the-art Tier 3 Data Center facilities in Delhi, Mumbai and two other cities.
CHAPTER
VIRTUAL PRIVATE NEWORK (VPN)
2.1
INTRODUCTION
A virtual private network (VPN) is a private communications network often used within a
company, or by several companies or organizations, to communicate confidentially over 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
providers private network with a defined Service Level Agreement (SLA) between the
VPN customer and the VPN service provider, thus emulating the characteristics of an IPbased private network at a much lower cost .
Fig. 2.1 VPN Defined
2.2
NEED FOR VPN
Extend geographic connectivity
Improve security
Reduce operational costs versus traditional WAN
Reduce transit time and transportation costs for remote users
Simplify network topology
Provide global networking opportunities
Provide broadband networking compatibility
2.3
BASIC VPN REQUIREMENTS
Security
Because sensitive and mission critical company data must travel across an
extremely insecure network, such as the Internet. User data security features
( such as confidentiality, integrity, authentication and reply attack prevention) is
the top-most requirement.
Support of overlapping IP addresses

A layer 3 VPN service shall support overlapping customer addresses, as IP
addresses must be unique only within the set of sites reachable from the VPNs of
which a particular site is member (but non-unique as for different customers
VPNs).
Constrained distribution of data and routing information

A means to constrain, or isolate the distribution of routing information to only
those VPN sites which are determined by customer routing and/or configuration
must be provided. The VPN solution must ensure that traffic is exchanged only
with those sites that are in the same VPN.
Performance
Encryption, which is a very important aspect of VPNs, is a CPU-intensive
operation. Therefore, it is necessary to select devices capable of performing tasks,
such as data encryption, quickly and efficiently.
Network management
It should be possible to configure, manage, and troubleshoot VPN-related
problems from one location or application.
Policy management
To ensure high performance, high availability, and guaranteed QoS.
2.4
VPN DEVICES AND TERMINOLOGY
The VPN devices are categorized as :
Customer
Customer network (C-Network): part of the network under customer control.
Customer (C) devices: C devices are simply devices such as routers and switches
located within the customer network. These devices do not have direct
connectivity to the service provider network.
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).
This device is usually a router and is normally referred as the CE router
Provider
Provider network (P-Network): the service provider infrastructure that is used to
provide VPN services.
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.
Fig. 2.2 Customer and Provider Network Devices
2.5
VPN CONFIGURATIONS
Remote Access VPNs

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.
Site to Site VPNs

Site-to-site VPNs are deployed for interconnecting geographically dispersed corporate
sites. Site-to-site VPNs are an extension of legacy WAN networks.
There are two types of site-to-site VPN:
Intranet VPNs--Allow connectivity between sites of a single organization
Extranet VPNs--Allow connectivity between organizations such as business

partners or a business and its customers
Fig. 2.3 Remote Access and Site to Site VPNs
10
2.6
VPN MODELS
VPNs are modeled as Overlay VPNs or Peer-to-Peer VPNs
2.6.1
Overlay VPN Model
In an overlay VPN model, a Virtual Circuit (VC) or tunnel connects CE devices. IP

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 pointto-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
from layer 1 to layer 3.
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.
2.6.2
Peer-to-Peer VPN Model
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
11
does NOT have any routing adjacency with other CEs. As a result, it gains IP
connectivity with the other sites via this PE router and because the service provider now
participates in customer routing, provider-assigned or public address space needs to be
deployed at the customers network
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).
Fig. 2.4 VPN Overlay and Peer model

(The dotted lines indicate direct routing adjacency)
12
2.7
APPROACHES TO VPN
Based on the Overlay and Peer VPNs, the various approaches to the deployment of a
Virtual Private Network is illustrated below.
Fig. 2.5 Approaches to VPN

.
13
2.8
VPN ENABLING PROTOCOLS AND TECHNOLOGIES
The diagram below shows the various VPN enabling technologies and protocols
Fig. 2.6 VPN Enabling Protocols and Technologies
14
CHAPTER 3
TUNNEL BASED VPNs
Most VPNs rely on tunneling to create a private network that reaches across the Internet
or service provider network.
3.1
TUNNELING
Tunneling is a method of using an internetwork infrastructure to transfer data for one

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
traverse
the
intermediate
(sometimes
incompatible)
internetwork.
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.
Tunneling includes this entire process (encapsulation, transmission, and decapsulation of
packets). Tunneling protocols generally use data encryption to transport insecure payload
protocols over a public network to provide VPN functionality.
15
Fig. 3.1 Tunneling
VPNs using tunneling technology can be based on either a Layer 2 or a Layer 3 tunneling
protocol or a combination of both.
3.2
LAYER 3 TUNNELING PROTOCOLS
Layer 3 protocols correspond to the network layer and use packets as their unit of
exchange.
3.2.1
IPSecurity (IPSec)
IPSec (IP Security) is a standardized framework for securing Internet Protocol (IP)
communications by encrypting and/or authenticating and providing integrity to each IP
packet in a data stream traveling to and from the network.
There are two modes of IPSec operation:
Transport Mode
In transport mode only the payload (message) of the IP packet is encrypted. It is fullyroutable since the IP header is sent as plain text. Transport mode is used for host-to-host
communication.
16
Tunnel Mode
In tunnel mode, the entire IP packet is encrypted. It must then be encapsulated into a new
IP packet for routing to work.
Tunnel mode is used for network-to-network
communications (secure tunnels between routers). Since encryption and encapsulation

are
done
by
routers/gateways,
end
systems
need
not
support
this.
The IPSec VPN is based on secure tunnel establishment between two peers.
Protocols used for securing traffic in IPSec are AH and ESP.
Authentication Header (AH)

Authentication Header (AH) is intended to guarantee connectionless integrity and
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
operates directly on top of IP.
An AH packet diagram in transport mode is shown in figure 2.1. The IP packet is

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
17
original IP packet to be reconstituted at the other end. At receiving end once the IPSec
headers have been validated, theyre stripped off and the original protocol type (TCP,
UDP, etc.) is stored back in the IP header.
Fig. 3.2 AH in Transport Mode
Encapsulated Security Payload (ESP)
The Encapsulating Security Payload (ESP) header provides origin authenticity, integrity,
and confidentiality of a packet. It works by encrypting the entire data packet, including
18
the payload with the sensitive information. ESP also supports encryption-only and
authentication-only configurations, but using encryption without authentication is
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.)
Fig. 3.3 ESP in Tunnel Mode
19
3.2.2
Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation (GRE) is a protocol designed for performing

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
flexibility of reconfiguring their IP architectures without worrying about connectivity.
Fig. 3.4 GRE Encapsulated packet format
A GRE tunnel creates a virtual point-to-point link with routers at end points on an IP
internetwork.
GRE Tunnel Security
20
For the purpose of tunnel security, GRE provides two options: tunnel interface key and
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.
3.2.3
GRE-IPSec Tunnel
Fig. 3.5 GRE-IPSec tunnel applicationIFu
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.
21
3.3
LAYER 2 TUNNELING PROTOCOLS
Layer 2 protocols correspond to the data-link layer and use frames as their unit of
exchange.
3.3.1
Point-to-Point Tunneling protocol (PPTP)
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
of the encapsulated PPP frames can be encrypted and/or compressed.
Fig. 3.6 Structure of a PPTP packet containing user data
22
3.3.2
Layer 2 Tunneling Protocol (L2TP)
L2TP acts like a data link layer protocol for tunneling network traffic between two peers
over an existing network. It is a combination of PPTP and Layer 2 Forwarding (L2F).
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
PPP frames can be encrypted and/or compressed.
L2TP provides reliability features for the control packets, but no reliability for data
packets
Fig. 3.7 Structure of an L2TP packet containing user data
23
3.3.3
L2TP/IPSec
L2TP relies on Internet Protocol security (IPSec) for encryption services. The
combination of L2TP and IPSec is known as L2TP/IPSec. L2TP/IPSec provides the
primary virtual private network (VPN) services of encapsulation and encryption of
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
address that corresponds to the VPN client and VPN server
Fig. 3.8 Encryption of an L2TP packet with IPSec ESP
24
3.3.4
PPTP Compared to L2TP/IPSec
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,
therefore, PPP authentication) is completed. With L2TP/IPSec, data encryption
begins before the PPP connection process by negotiating an IPSec security
association.
PPTP connections require only user-level authentication through a PPP-based

authentication protocol. L2TP/IPSec connections require the same user-level
authentication and, in addition, computer-level authentication using computer
certificates.
25
CHAPTER4
MULTIPROTOCOLLABELSWITCHING(MPLS)ANDVPNs
4.1
INTRODUCTIONTOMPLS
MultiProtocolLabelSwitching(MPLS)isadatacarryingmechanismthatbelongstothe
family of packetswitched networks. MPLS operates at an OSI Model layer that is
generallyconsideredtoliebetweentraditionaldefinitionsofLayer2(DataLinkLayer)
andLayer3(NetworkLayer),andthusisoftenreferredtoasa"Layer2.5"protocol.It
wasdesignedtoprovideaunifieddatacarryingserviceforbothcircuitbasedclientsand
packetswitchingclientswhichprovideadatagramservicemodel.Itcanbeusedtocarry
manydifferentkindsoftraffic,includingIP.
26
Fig. 4.1 An MPLS Network

4.2
MPLS CONCEPTS AND COMPONENTS
4.2.1
Forwarding Equivalence Class (FEC)
It is a term used in Multiprotocol Label Switching (MPLS) to describe a set of packets

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
and with the same treatment (such as queuing).
4.2.2
MPLS Label
27
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
can only represent a single FEC.
A label is carried in the header of a packet. It does not contain any topology information
and is local significant. A label is four octets, or 32 bits, in length
Fig. 4.2 MPLS Label Format
Each label entry contains four fields:
A 20-bit label value.
a 3-bit field for QoS (Quality of Service) priority (experimental).
a 1-bit bottom of stack flag. If this is set, it signifies that the current label is the
last in the stack.
4.2.3
an 8-bit TTL (time to live) field.
Label Switch Router (LSR)
A Label Switch Router (LSR) is a type of a router located in the middle of a

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
28
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
packets according to the LFIB.
Fig. 4.3 Structure of a LSR
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 labeled
packets and therefore uses only the LFIB.
4.2.4
Label Edge Router (LER)
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
29
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 from the packet, is called an egress router
4.2.5
Label Switched Path (LSP)
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
called upstream LSR and downstream LSR respectively
Due to the forwarding of packets through an LSP being opaque to higher network layers,
an LSP is also sometimes referred to as an MPLS tunnel.
4.2.6
Label Distribution Protocol (LDP)
Label Distribution Protocol (LDP) is a protocol for the purpose of distributing labels in
an MPLS environment. It classifies FECs, distributes labels, and establishes and
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-
30
directional. LDP is used to build and maintain LSR databases that are used to forward
traffic through MPLS networks.
4.2.7
Label Information Base (LIB)
It is the software table maintained by IP/MPLS capable routers to store the details of port
and the corresponding MPLS outer label to be popped/pushed on incoming/outgoing
MPLS packets.
4.2.8
Label Forwarding Information Base (LFIB)
It is a table created by a label switch-capable device (LSR) that indicates where and how
to forward frames with specific label values
4.3
MPLS OPERATION
MPLS works by prefixing packets with an MPLS header, containing one or more 'labels'.
This is called a label stack.
Fig. 4.4 Structure of a MPLS packet
31
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.
Fig. 4.5 Packet transfer using MPLS
The following steps describe the working of MPLS:

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
32
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
packet, and forwards the labeled packet to the next hop along the LSP. Sometimes,
the packet presented to the LER already may have a label, so that the new LSR
pushes a second label onto the packet
3) After receiving a packet, each transit LSR switches/forwards these MPLS-labeled

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
of swap, push (impose) or pop (dispose) on the packets label stack.
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
of the transit LSRs performs Layer 3 processing
33
4) When the egress LER receives the packet, it pops the last MPLS label off packet and
performs IP forwarding based on routing table look up.
4.4
ROUTING IN MPLS
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 packets path from source
to destination. LSPs direct packets in one of two ways:
4.4.1
Hop-by-Hop Routing
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
network topology information distributed by traditional Interior Gateway Protocols
(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 this case the path so followed is known as a hop-by-hop routed tunnel.
4.4.2
Explicit Routing
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.
This is called Constraint-Based Routing. This permits traffic engineering to be deployed
in the network to optimize use of bandwidth. In this case the path is called an explicitly
routed tunnel.
34
4.5
MPLS BASED VIRTUAL PRIVATE NETWORKS (MPLS VPNS)
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 siteconnections. But the core routers do not need to carry much routing information. Only the
PE routers must have some power.
MPLS based VPNs can be categorized as:
Layer 2 MPLS VPN

A layer 2 MPLS VPN, also known as L2VPN, is a point-to-point pseudowire service.
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.
Layer 3 MPLS VPN

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
provider-based frame relay or ATM-based networks, or IPsec- ased VPNs. The
concept of Virtual Routers (VRs are central to the concept of establishing a Layer 3
VPN.
35
4.6
VIRTUAL ROUTER (VR) CONCEPT IN MPLS 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
(configuration, management, monitoring and troubleshooting) like a dedicated physical
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
routing protocol can be used, and no modification or extension is needed to the standard
routing protocols (e.g. RIP, OSPF, IS-IS, and BGP).
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
network core for scalability.
36
Fig. 4.6 VR VPN Reference model
4.6.1
VR VPN Implementation
A VPN is created by interconnecting VRs located in PE routers through tunnels through

the service provider core network. These tunnels may be configured either statically or
dynamically. The tunnels between PEs may be configured in several different ways. One
of the alternatives is the direct connectivity between VRs.
Fig. 4.7 VR VPN with direct connectivity between VRs
An alternative approach, is based on the utilization of a single backbone VR to

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
improving the scalability.
37
Fig. 4.8 VR VPN with a backbone VR

4.6.2
VPN Auto-Discovery
VPN membership information refers to the set of PEs that have customers in a particular
VPN. In order to establish VPN-specific connectivity, the VRs belonging to a given
VPN, physically located in several PE routers, need to learn about each other. Because a
solution based on manual configuration is not scalable, an auto-discovery mechanism is
required. Several VPN discovery approaches can be implemented in VR VPNs
Directory servers (VRs query a server to determine their neighbours)
Configuration through a management platform
Distributing VPN membership and topology information with BGP
Multicast
A single PE may accommodate several different mechanisms for different VPNs. BGP
and multicast are currently the most relevant approaches.
4.7
APPLICATION OF MPLS
38
MPLS enables a single converged network to support both new and legacy
services, creating an efficient migration path to an IP-based infrastructure. MPLS
operates
over
both
legacy
(DS3,
SONET)
and
new
infrastructure
(10/100/1000/10G Ethernet) and networks (IP, ATM, Frame Relay, Ethernet)
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
low end-to-end latency for voice and video.
The forwarding of the packet is done based on the contents of the labels, which
allows "protocol-independent packet forwarding" that does not need to look at a
protocol-dependent routing table and avoids the expensive IP longest prefix match
at each hop.
In an MPLS network the FEC is determined only once, at the Ingress to an LSP,
rather than at every router hop along the path
MPLS reduces router processing requirements, since routers simply forward

packets based on fixed labels.
MPLS provides the appropriate level of security to make IP as secure as Frame

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 providernetwork-based, reducing the configuration and management requirements for the
customer.
39
Scalability: MPLS VPNs scale easily to thousands of users and sites since they do
not involve site-to-site peering.
Security: MPLS VPNs use a technique called route distinguishers to provide

traffic - separation between VPNs of different customers. These are assigned
automatically where the VPN is provisioned, and are unique for a given customer.
4.8
MPLS and L2TPv3
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
made by establishing and employing IP tunnels (rather than MPLS LSPs) to forward
packets across native IP networks in support of MPLS VPN services. Then solution like
GRE and L2TPv3 comes into picture.
4.8.1
Layer 2 Tunneling Protocol version 3 (L2TPv3)
Layer 2 Tunneling Protocol Version 3 is a draft version of L2TP that is proposed as an

alternative protocol to MPLS for encapsulation of multiprotocol Layer 2 communications
traffic over IP networks. Like L2TP, L2TPv3 provides a pseudo-wire service, but scaled
to fit carrier requirements. It is a stateless protocol with no inherent signaling or keepalive mechanism. L2TPv3 is a robust alternative to creating Layer 2 VPNs across MPLS
and pure IP backbones. L2TPv3 adds important new features such as increasing the
40
session and tunnel ID space from 16 to 32 bits, which dramatically increases the number
of tunnels from 65,000 to more than 4 billion.
Fig. 4.9 L2TPv3 packet transfer mechanism

With L2TPv3, the physical interface connecting to a customers network becomes the
tunnel ingress/egress interface. Consequently, traffic does not need to be routed into the
tunnel by the providers router. As packets arrive at the interface, they are encapsulated
and forwarded directly toward the remote tunnel endpoint. Once received and deencapsulated, the original packet can be forwarded out of the egress interface if the tunnel
identifier is recognized by the router. If it isnt, the packet is discarded.
4.8.2
MPLS-over-L2TPv3
41
Fig. 4.10 MPLS-over-L2TPv3 encapsulation
The encapsulation of an MPLS packet in L2TPv3 comprises of:
The 20-byte IP delivery header contains the sending and receiving PE routers IP
address
The session ID is an automatically generated 32-bit number used to define individual

services or service contexts on the egress PE router.
The cookie is an automatically generated (optional) 64-bit random number that is

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.
42
CHAPTER 5
BGP/MPLS VPN NETWORKS
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 providers backbone and
43
MPLS to forward VPN traffic from one VPN site to another.
Fig. 5.1 Layered view of a BGP/MPLS VPN
5.1
IMPLEMENTATION OF THE VIRTUAL ROUTER CONCEPT
A BGP/MPLS Network VPN Network is based on the VR concept. The VR in a

BGP/MPLS network in implemented with the help of VPN Routing and Forwarding table
(VRF) and Route Distinguisher (RD)
5.1.1
VPN Routing and Forwarding Tables (VRFs)
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
VPN can use its own Route Distinguisher.
5.1.2
Route Distinguisher (RD)
44
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
12-byte field is a unique "VPN-IPv4" address. Within an MPLS network, a PE router
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.
The route distinguisher (RD) has 2 major fields, the Type Field (2 bytes) and Value Field
(6 bytes). The Type field determines the lengths of the Value fields two subfields
(Administrator and Assigned Number), as well as the semantics of the Administrator
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 VPNIPv4 addresses without conflicting with the RD assignments made by other service
providers.
45
5.2
Network Architecture
A customer site is connected to the service provider network by one or more interfaces.
The service provider associates each interface with a VPN routing table.
Fig. 5.2 Network architecture of a BGP/MPLS Network
A CE router advertises the sites 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
46
need for PE routers to maintain all of the service providers VPN routes. Each customer
connection is mapped to a specific VRF. The interface on the PE router is associated with
a VRF; multiple interfaces on a PE router can be associated with a single VRF. PE routers
have the ability to maintain multiple forwarding tables that support the per-VPN
separation of routing information. A PE router exchanges VPN routing information with
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 providers PE routers; they are not required to maintain specific VPN
routing information for each customer site
.
5.3
OPERATION AND ILLUSTRATION OF A BGP/MPLS VPN
The operation of BGP/MPLS VPNs can be distributed into various phases. The various
phases of a BGP/MPLS VPNs operation are illustrated with a case study.
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
sites belonging to this VPN are connected.
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
sub-interfaces (those of Site 6 and 7).
47
Fig. 5.3 BGP/MPLS VPN Routing & Forwarding tables (VRFs)
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
performed at SP network configuration time - the establishment of internal BGP (iBGP)
sessions between PEs and the set-up of MPLS label switch paths between PEs.
48
Fig. 5.4 PE-to-PE pre established iBGP sessions and LSPs
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
the route distinguisher and are therefore 12-bytes long.
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
the
swap
labels
(19
and
29
between
PE1
49
and
PE2). The labels numbered 3 represent a special label value indicating that this P router
is the penultimate hop in the path. LSPs are established using either LDP or RSVP.
The fundamental mechanisms used by BGP/MPLS VPNs can be summarized as:
On the Control Plane

The use of BGP for the distribution of VPN routes through the SP backbone and
establish LSPs.
On the Data plane

The use of MPLS for the IP traffic forwarding itself, more exactly the transfer of VPN
data through the SP backbone.
5.3.1
VPN Route Distribution in Control Plane
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
routes are added, modified or removed at a site
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
50
protocols (RIP, OSPF) or BGP. It is also possible not to use any routing protocol and
instead have static routing configured at each site.
Fig. 5.5 CE to PE Route Distribution
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 PEs 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
to choose the suitable sub-interface.
51
When two sites (or more) attached to one PE are in the same VPN, they gain
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
SPs 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.
52
Fig. 5.6 PE to PE Route Distribution
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).
53
Once all the VPN routes have been distributed through the SP backbone, all the VRFs
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 site 2
(Blue) as well as remote sites 3, 6 and 7 (Green).
Fig. 5.7 PE to CE Route Distribution
54
5.3.2
VPN Data Forwarding in Data Plane
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).
Fig. 5.8 Data forwarding across the backbone
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
55
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. 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 (PE1s 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.
CHAPTER6
56
WIRELESSLASTMILEREMOTESITECONNECTIVITY
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
and microwave frequency.
The wireless last mile were provided using two topologies
Point to Point (P2P)

Operating the client site with the help of one base station radio at the Pop end and one
radio at client end.
Point to Multipoint (PMP)

Operating multiple remote sites using a single radio at the PoP and one each at the
various remote sites.
The links are secured using MAC address bindings between the end radios.
57
6.2
REMOTE SITE CONNECTIVITY
Fig. 6.1 A typical wireless last mile remote site connectivity
ThebasestationsorPoPsareconnectedwiththecorenetworkusingopticalfibersor
redundantRFlinks.ThisconnectivityisprovidedwiththePoPendrouter.Thisrouteris
internconnectedtoaswitch.Theradiosinthebasestationareconnectedtothisswitchat
oneendandtheantennaatanotherusingapigtailcable.
Attheclientside,wehaveanantennainstalledwhichisagainconnectedtotheclientend
radiousingapigtailcable.TheclientendradioisconnectedtotheclientrouterviaaPoE
(Powerover Ethernet) device which provides DCvoltage to powerthe modem. The
routeristhenconnectedtotheinternalclientLAN.
58
The information which arrives at the base station is modulated in the radio and
transmittedusingtheantenna.Theclientendantennareceivesthissignalandtheclient
radiodemodulatesitandsendsitacrosstotheclientenddevices.
6.3
RADIOS
WirelesslastmileconnectivityisestablishedwiththehelpofRadiosandantennas.Based
onthepurposeandrequirementsdifferentradioswereusedatTulip.Eachoftheradio
has a different running frequency range, distinct monitoring and troubleshooting
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
applications and multipoint-to-multipoint (MMP) for base station interconnection.
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
Base Station Radio (BSR)

The radio at the base station is known as a BSR. It is an encased outdoor radio
module providing a 9 pin D-type port for RS-232 serial interface and a 15 pin D-type
59
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.
Fig. 6.2 Airspan BSR
Subscriber Premises Radio (SPR)

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
N-type port for attaching an external antenna.
Fig. 6.3 Airspan SPR
60
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)
using the tool WipManage.
6.3.2
Radwin
TheseradiosareprimarilyusedinthebackbonetoprovideredundantbackboneRFlinks
tothefibernetwork.Thesystemprovidesuptopointtopoint48Mbpswirelesslinkand
supportsrangeupto80km.ItcombineslegacyTDMandEthernetservicesover2.4GHz
and5.xGHzlicenseexemptbands. Operationover2.4GHzand5.xGHzbandsisnot
affectedbyharshweatherconditions,suchasfog,heavyrainetc.RadwinemploysTime
Division Duplex (TDD) transmission. This technology simplifies the installation and
configurationprocedure.Thereisnoneedtoplanandtoallocateseparatechannelsfor
theuplinkanddownlinkdatastreams.
.
6.3.3
Firepro
These radios can be used for both point to point and point to multipoint wireless
connections.Howeveritisprimarilyusedforpointtopointlinks,whereitcantakeaload
ofupto2Mbpsinadedicatedfashionandsupportsnetworkrangeupto60kms.Itcan
beconfiguredinbridgingandroutingmodes.ThemainadvantageofFireproisthatitcan
actlikeaminirouterinitself.
61
ItallowsfullremoteandlocalmanagementthroughSNMPusingthetoolWinBox.
CHAPTER 7
REMOTE NETWORK MONITORING AND

TROUBLESHOOTING
Remote network monitoring and troubleshooting enables efficient management of a

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
used for remote monitoring and fault detection.
7.1
SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)
The Simple Network Management Protocol (SNMP) forms part of the internet protocol
suite. SNMP is used in network management systems to monitor network-attached
devices for conditions that warrant administrative attention. It consists of a set of
standards for network management, including an Application Layer protocol, a database
schema, and a set of data objects. SNMP is based on the manager/agent model consisting
of an SNMP manager, an SNMP agent, a database of management information, managed
62
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.
Fig. 7.1 Manager-Agent model used in SNMP
The SNMP network management is composed of three parts to which both the
management applications and agents conform. They are:
The protocol, which defines the functioning of the basic operations of SNMP and
the format of the messages exchanged by management systems and agents.
Structure of Management Information (SMI), which is a set of rules used to

specify the format for defining managed objects or the devices that are accessed
using SNMP.
Management Information Base (MIB) is a collection of definitions, which

define the properties of the managed object or the device.
63
7.1.1
SNMP Messages
There are primarily five types of SNMP messages:
SNMP TRAP message allows the agent to spontaneously inform the SNMP manager
of an "important" event.
An SNMP GET and GET-NEXT message is a message which is initiated by the

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.
SNMP GET-RESPONSE message is issued by the agent in response to a GET or

GET-NEXT message to the manager, with either the information requested or error
indication
An SNMP SET is a message which is initiated by the Network Management System

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
response respond with a GET-RESPONSE message to indicate if the task has been
accomplished.
7.2
ROLE OF L1 MEMBER IN NOC
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 customers remote VPN
64
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.
Fig. 7.2 Hierarchy followed for link troubleshooting
65
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
by L1 Engineers. On success, the call is closed.
3) On escalation, call is assigned to L2 Engg who closes the call on success. For
physical issues, field engineers are assigned.
4) Still higher members are involved in further escalations.
5) MPLS configuration, Router & Switches configuration are done by L2 Engg.
6) Serious and complex issues are handled by L3 Engg, Team
7.3
TOOLS
7.3.1
Telnet client
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 the Telnet
server, which are usually the routers or switches.
Telnet allows for remote configuration and/or check up on the routers or switches without
using a console cable.
66
7.2.1
Host Monitor
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
of 25 pre-defined actions such as email message or shutting down a service.
HostMonitor creates various log files using different detail levels and file formats
Web Service, Telnet Service and Remote Control Console simplifies remote
management
using Remote Monitoring Agents for Windows, Linux, Solaris etc. we may easily
monitor remote networks
67
Fig. 7.3 Host Monitor Interface
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
software, it provides different ways to respond on failed services. Audio and visual
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
immediately alert the user of a link failure.
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
zoom-in
on
and
manage
each
unit
on
each
subscriber
site.
WipManage uses SNMP and TFTP to perform the following tasks on an airspan system
Installation
Configuration
68
Trap management
Fault management
Performance Monitoring
Setting RF parameters, IP configuration, security policies, VLANs and any other

feature per element or per many elements simultaneously (multi device operation)
Fig. 7.4 WipManage Interface
WipManage is location-independent and can be used to manage any Airspan unit in the
network as long as the Airspan is connected to the network.
69
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
of the power present in a received radio signal.
Fig. 7.5 SPR BER Performance Monitoring
Fig. 7.6 SPR RSSI Performance Monitoring
70
7.3.3
Multi Router Traffic Grapher (MRTG)
The Multi Router Traffic Grapher or just simply MRTG is software for monitoring the
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
and even Netware systems.
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,
containing a list of graphs detailing traffic for the selected device.
Features
Measures 2 values (I for Input, O for Output) per target.
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
plotted as a full green area, and the O as a blue line.
71
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.
Can also send warning emails if targets have values above a certain threshold.
In the NOC, MRTG was primarily used to check if the high latencies and drops in the
network link were due to overutilization of the bandwidth actually assigned.
7.3.4
Paessler Router Traffic Grapher (PRTG)
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,
protocols, etc. of the source and target machine
Analyses
Netflow
protocol
packets
used
mostly
by
Cisco
routers
Using SNMP not only bandwidth usage but also many other network readings (e.g. CPU
usages, disk usages, temperatures) can be monitored using SNMP OIDs.
72
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.
In the NOC, PRTG was primarily used to check utilization of assigned bandwidth by the
client. The PRTG graphs were used to confirm if the latencies and drops faced in a
network link is due to a problem in the link or as a result of overutilization of assigned
bandwidth by the client.
Fig. 7.7 PRTG Graph showing bandwidth utilization
73
7.3.5
Vitual NOC (VNOC)
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
in the VNOC interface. Further, only a warning will be displayed firstly. After a
stipulated time, if no action is taken a ticket is further logged automatically. This along
with tool.tulipconnect.com helps provide a very reliable and proactive manner of
monitoring of the clients by the Access Team.
Fig. 7.8 Proactive monitoring and fault logging by VNOC
74
CHAPTER 8
CLIENTCASESTUDIES
TulipprovidedavarietyofVPNservicestoitsclients.Twoofthecircuitsthatwere
handled by as an L1 member in the team were Reliance L2 circuits and Indiabulls
Layer3MPLSVPNcircuits.
8.1
RELIANCEL2CIRCUITS
Fig. 8.1 Reliance L2 network connectivity with fiber interconnect
Tulip provided last mile connectivity to Reliance customers at Layer 2. In this case Tulip
acted as the carrier of carriers.
75
8.1.1
Working
Frames from the client end are tagged at the SPR end.
VLAN tagged traffic is accepted by Cisco 2950 switch in POP and same is forwarded
to POP router which may be Cisco1800/2800.
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
forwarded via this path to Reliance.
Fig. 8.2 Reliance L2 network connectivity with RF interconnect
Now the traffic flow in the network takes place as follows:
76
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.
3) Router sends the frames to main Tulip POP (where Interconnect has been made) via
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
Pass all VLAN tag mode.
6) RF link is the interconnect link between Reliance Base Transceiver Station and Tulip
POP and is hence terminated in the trunk port of Reliance switch.
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
working then the following steps are followed:
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)
77
d) If we are able to ping then the problem is with client router or LAN which is
not in Tulip domain.
e) If we are not able to ping then either keep the RF link not terminated so that we
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
terminated at POP end.
f) Now RF link from the CE router is removed so that when we use the CE IP for
further trial, it does not collide.
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
the IP to Tulip subnet for sometime.
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
site to which link is connected.
j) Get an ACCESS port against VLAN 777 created in the switch (in which link is
terminated), and terminate the laptop in that port.
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.
78
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
if we are not able to ping PE IP then
n) Before moving beyond we must make sure that last mile is absolutely fine .
o) To check last mile, get the RF link at client side terminated back in router or add
specific VLAN back to the trunk port of switch.
p) If the last mile RF is absolutely fine then our laptop IP should collide with CE router
IP (because we have assigned CE IP to laptop).
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 wont
collide) and try pinging CE Router IP. It should ping.
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
laptop connected now to Tulip Main POP switch.
u) Try pinging the Reliance PE across the interconnect link.
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
switch with Reliance switch comes into question.
79
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 wont collide as
the logical connectivity with Reliance is already not working) and revert the client
end termination and try pinging CE Router IP, if we are pinging then Tulip part of
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
with switch (practically happens most of the time).
z) If we are able to ping CE IP using Reliance PE IP on laptop, then we now know that
Tulip part of L2 is working fine, so now we concentrate on connectivity with
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
then our Tulip end to end is working fine.
80
8.2
INDIABULLS
81
82
CE Routers
Logical GRE tunnel from CE to Regional PE Routers.
PE routers in MPLS cloud
POP Routers
RF link from CE router to POP router.
Fig. 8.3 Basic Indiabulls VPN Network connectivity layout
8.2.1
Working
Indiabulls was one of the clients who were provided Layer 3 VPN Services. The network
diagram shows a simplified network diagram of Indiabulls network connectivity
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
MPLS cloud is primarily a BGP/MPLS network.
8.2.2
Troubleshooting
1) First we check router IP. If it is not pinging then get checked the cable from modem to
router and the port where RF link terminated.
83
2) If Modem IP is not pinging then maybe the modem has hanged, cable connectivity is
loose or there may be a problem in the PoE.
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
ping. The call is assigned to L2 Engineers for major configuration issues.
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
DISCUSSION AND FUTURE SCOPE
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
84
of the service provider the decision to implement layer 2 or layer 3 VPNs is influenced by
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 customers 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,
it requires an MPLS-enabled backbone infrastructure. Both technologies should have their
place in the service provider networks. IPsec is the natural choice for small enterprise
network environments, whereas MPLS is used when scalability is a concern (both in
terms of the average customer network size)
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
85
any non-trusted network) whereas MPLS provides flexible VPN control functions and
enables traffic engineering and traffic differentiation required by large VPN
implementations.
9.2
FUTURE SCOPE AND IMPROVEMENTS
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
(e.g. multi-provider BGP/MPLS)
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
largely ignored by network based VPN standardization efforts.
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.
86
With this report, the various site to site VPN enabling technologies have been explained.
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
and the ever increasing domain of computer networks.
REFERENCES
1. Davie B. and Rekhter Y., MPLS Technology and Applications, Morgan Kaufmann
Publishers
2. Ghein, Luc De, MPLS Fundamentals, Cisco Press
3. Lammle, Todd, Cisco Certified Network Associate Study Guide, Wiley Publishing
Inc.
4. Lewis, Mark, Comparing, Designing, and Deploying VPNs, Cisco Press
5. Repiquet, Jol, White Paper, Keep it Simple with BGP/MPLS Virtual Private
Networks
87
6. Snader, Jon C. , VPNs Illustrated: Tunnels, VPNs, and IPsec, Addison Wesley
Professional
7. www.wikipedia.org, Internet
8. www.vpnc.org, Internet
9. www.cisco.com, Internet
10. www.tuliptelecom.com, Internet
88

VPN Connectivity Management Report

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VPN Connectivity Management Report

Uploaded by

Copyright:

Available Formats

NETWORKING - VPN CONNECTIVITY AND THEIR

SIKKIM MANIPAL INSTITUTE OF TECHNOLOGY

For Partial Fulfillment of the Requirement for the

ELECTRONICS AND COMMUNICATION ENGINEERING

Mr. PUNEET KHANNA

Dr. SUSHABHAN CHOUDHURY

SIKKIM MANIPAL INSTITUTE OF TECHNOLOGY

SIKKIM MANIPAL INSTITUTE OF TECHNOLOGY

Mr. Puneet Khanna

Dr. (Prof.) R.N.Bera

ABOUT TULIP TELECOM

The Core and Aggregation Network.. .

The Customer Access Network. .

VIRTUAL PRIVATE NETWORK (VPN)

Need for VPN...

Basic VPN Requirements....

VPN Devices and Terminology...

Overlay VPN Model

Peer-to-Peer VPN Model.

VPN Enabling Protocols and Technologies

TUNNEL BASED VPNs

Layer 3 Tunneling Protocols.......

Generic Routing Encapsulation (GRE)..

Layer 2 Tunneling Protocols...

Point-to-Pont Tunneling Protocol (PPTP)..

Layer 2 Tunneling Protocol (L2TP)...

PPTP Compared to L2TP/IPSec.

MULTI PROTOCOL LABEL SWITCHING (MPLS)

MPLS Concepts and Components..

Forwarding Equivalence Class (FEC)

Label Switch Router (LSR).

Label Edge Router (LER).

Label Switched Path (LSP)..

Label Distribution Protocol.

Label Information Base (LIB)....

Label Forwarding Information Base (LFIB)..

MPLS Based Virtual Private Networks (MPLS VPNs)..

Virtual Router (VR) Concept in MPLS VPN.

MPLS and L2TPv3..

Layer 2 Tunneling Protocol version 3 (L2TPv3)..

BGP/MPLS VPN NETWORKS

Implementation of the Virtual Router Concept..

VPN Routing and Forwarding Tables (VRFs)...

Route Distinguisher (RD)...

Operation and Illustration of a BGP/MPLS VPN...

VPN Route Distribution in Control plane..

VPN Data Forwarding in Data Plane..

WIRELESS LAST MILE REMOTE SITE

Remote Site Connectivity....

REMOTE NETWORK MONITORING AND

Simple Network Management Protocol (SNMP)...

Role of L1 Member in NOC......

Multi Route Traffic Grapher (MRTG)...

Paessler Route Traffic Grapher (PRTG)....

Virtual NOC (VNOC)..

CLIENT CASE STUDIES

DISCUSSION AND FUTURE SCOPE

Future Scope and Improvements

Tulip Network Architecture.

Customer and Provider Network Devices..

Remote Access and Site to Site VPNs

VPN Overlay and Peer Model....