final project report vpn

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 KHANNASr.Network Engineer, Tulip Telecom

&Dr. SUSHABHAN CHOUDHURY

Professor, Department of Electronics and Communication Engineering

SIKKIM MANIPAL INSTITUTE OF TECHNOLOGY

MAJITAR, RANGPO, EAST SIKKIM - 737132SIKKIM MANIPAL INSTITUTE OF TECHNOLOGY

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 Dr.Sushabhan ChoudhurySr.Network Engineer ProfessorTulip Telecom Department of ECENew Delhi SMIT, Majitar

Dr. (Prof.) R.N.BeraHead 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.

i

ABSTRACT

Tulip Telecom is the largest MPLS based VPN provider in India and has been the front-

runner in provisioning and managing of multi location wide area network VPNs using

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………………………………………………. i

ABSTRACT ……………………………………………………………... ii

LIST OF FIGURES ……………………………………………………… viii

ABBREVATIONS ………………………………………………………. x

CHAPTER 1 ABOUT TULIP TELECOM

1.1 Company Profile..……………………………………………… 1

1.2 Company Objectives….……………………………………….. 1

1.3 Infrastructure…………………………………………………… 2

1.4 Network Architecture……………………………………………. 3

1.4.1 The Core and Aggregation Network………………….. . 3

1.4.2 The Customer Access Network………………………. . 4

1.5 Network Management…………………………………………. . 4

1.6 Services Offered……………………………………………….. . 5

CHAPTER 2 VIRTUAL PRIVATE NETWORK (VPN)

2.1 Introduction……..………………………………………………. 6

2.2 Need for VPN…………….…..………………………………… 7

2.3 Basic VPN Requirements.……………………………………... 7

2.4 VPN Devices and Terminology………………………………... 8

2.5 VPN Configurations………..…………………….……………... 9

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 IPSecurity (IPSec)……………………………………... 16

3.2.2 Generic Routing Encapsulation (GRE)………………..

20

3.2.3 GRE-IPSec Tunnel…………………………………….. 21

3.3 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 BGP/MPLS VPN NETWORKS

5.1 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 VPN Route Distribution in Control plane…………….. 49

v

5.3.2 VPN Data Forwarding in Data Plane…………….……. 54

CHAPTER 6 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 SNMP Messages…………………………………...…... 63

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 8 CLIENT CASE STUDIES

vi

8.1 Reliance L2 Circuits…………………………………..….…..... 74

8.1.1 Working………………………………………………... 75

8.1.2 Troubleshooting…………………….…………………. 76

8.2 Indiabulls……………………….………………………………. 80

8.2.1 Working………………………………………………... 80

8.2.2 Troubleshooting……………………………………….. 81

CHAPTER 9 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…………………………………………. 3

2.1 VPN Defined………………………………………………………… 6

2.2 Customer and Provider Network Devices…..……………………… 9

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 VR VPN with Direct Connectivity between VRs………………….. 37

Figure Title 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 Airspan BSR…………………………………….………………….. 59

6.3 Airspan SPR………..………………………………………………. 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……………. 80

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

x

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

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 India’s 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 end-

to-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 1

Grow the business rapidly while maintaining the highest quality of service.

Impact the rural economy by providing connectivity right upto to the last village.

1.5 INFRASTRUCTURE

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 copper-

based last mile connectivity provided by incumbent service providers. Tulip also offers

customer premises connectivity over fiber for high speed bandwidth applications. Tulip's

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 state-

of-the-art Tier 3 Data Center facilities in Delhi, Mumbai and two other cities.


CHAPTER 2

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

provider’s private network with a defined Service Level Agreement (SLA) between the

VPN customer and the VPN service provider, thus emulating the characteristics of an IP-

based 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


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 point-

to-point transport of data between the customer sites. However, the CE can be connected

to the Service Provider network (to some PE) via various forms of adjacency, ranging

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


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 customer’s 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)


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

.


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


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.


http://en.wikipedia.org/wiki/VPN

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 fully-

routable since the IP header is sent as plain text. Transport mode is used for host-to-host

communication.


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


http://en.wikipedia.org/wiki/Sliding_window

http://en.wikipedia.org/wiki/Replay_attack

original IP packet to be reconstituted at the other end. At receiving end once the

IPSec headers have been validated, they’re 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


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


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


http://en.wikipedia.org/wiki/Stateless_server

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.


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


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


http://en.wikipedia.org/wiki/Data_link_layer

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


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.


CHAPTER 4

MULTI PROTOCOL LABEL SWITCHING (MPLS) AND VPNs

4.1 INTRODUCTION TO MPLS

Multi Protocol Label Switching (MPLS) is a data-carrying mechanism that belongs to the

family of packet-switched networks. MPLS operates at an OSI Model layer that is

generally considered to lie between traditional definitions of Layer 2 (Data Link Layer)

and Layer 3 (Network Layer), and thus is often referred to as a "Layer 2.5" protocol. It

was designed to provide a unified data-carrying service for both circuit-based clients and

packet-switching clients which provide a datagram service model. It can be used to carry

many different kinds of traffic, including IP .


http://en.wikipedia.org/wiki/Datagram

http://en.wikipedia.org/wiki/Packet-switching

http://en.wikipedia.org/wiki/Telecommunication_circuit

http://en.wikipedia.org/wiki/Network_Layer

http://en.wikipedia.org/wiki/Data_Link_Layer

http://en.wikipedia.org/wiki/OSI_Model

http://en.wikipedia.org/wiki/Packet_switching

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

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


http://en.wikipedia.org/wiki/Label_switched_path

http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching

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.

an 8-bit TTL (time to live) field.

4.2.3 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

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.


http://en.wikipedia.org/wiki/Look-up_table

http://en.wikipedia.org/wiki/Label_Switched_Path

http://en.wikipedia.org/wiki/Packet_(information_technology)


http://en.wikipedia.org/wiki/Router

http://en.wikipedia.org/wiki/Time_to_live

http://en.wikipedia.org/wiki/Quality_of_Service

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

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


http://en.wikipedia.org/w/index.php?title=Egress_router&action=edit&redlink=1

http://en.wikipedia.org/wiki/Ingress_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-

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.


http://en.wikipedia.org/wiki/Router


http://en.wikipedia.org/wiki/MPLS

http://en.wikipedia.org/wiki/Label_Switch_Router

http://en.wikipedia.org/wiki/Protocol_(computing)

http://en.wikipedia.org/wiki/Forwarding_equivalence_class

http://en.wikipedia.org/wiki/Label_Distribution_Protocol

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

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.


http://en.wikipedia.org/wiki/Stack_(data_structure)

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

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 packet’s 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

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 packet’s path from

source to destination. LSPs direct packets in one of two ways:


http://en.wikipedia.org/wiki/MPLS_VPN

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.

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 site-

connections. But the core routers do not need to carry much routing information. Only the

PE routers must have some power.


http://en.wikipedia.org/wiki/Virtual_Private_Network



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.

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.

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.

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

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 provider-

network-based, reducing the configuration and management requirements for the

customer.

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


http://en.wikipedia.org/wiki/Longest_prefix_match

http://en.wikipedia.org/wiki/Routing_table

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

keep-alive 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 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


http://en.wikipedia.org/wiki/Pseudo-wire

http://en.wikipedia.org/wiki/Internet_Protocol

http://en.wikipedia.org/wiki/Layer_2

http://en.wikipedia.org/wiki/Multiprotocol_Encapsulation

http://en.wikipedia.org/wiki/Encapsulation_(networking)

http://en.wikipedia.org/wiki/MPLS

http://en.wikipedia.org/wiki/L2TP

With L2TPv3, the physical interface connecting to a customer’s network becomes the

tunnel ingress/egress interface. Consequently, traffic does not need to be routed into the

tunnel by the provider’s router. As packets arrive at the interface, they are encapsulated

and forwarded directly toward the remote tunnel endpoint. Once received and de-

encapsulated, the original packet can be forwarded out of the egress interface if the tunnel

identifier is recognized by the router. If it isn’t, the packet is discarded.

4.8.2 MPLS-over-L2TPv3

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.


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 provider’s backbone and

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)

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.


http://en.wikipedia.org/wiki/IP_address

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 field’s 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 VPN-

IPv4 addresses without conflicting with the RD assignments made by other service

providers.

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 site’s local VPN routes to the PE router, and learns remote

VPN routes from the PE router. PE routers exchange routing information with CE routers


using static routing, RIP, OSPF or EBGP. The PE router maintains VPN routing

information for those VPNs to which it is directly attached. This design eliminates the

need for PE routers to maintain all of the service provider’s VPN routes. Each customer

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 provider’s 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).

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.

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 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

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 PE’s local matter. It identifies the VRF sub-interface by which this route is

learned. Hence, routes learned over the same VRF sub-interface will have the same

label value. This will enable the PE when receiving traffic towards one of these routes

to choose the suitable sub-interface.

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

SP’s AS number plus the VPN identifier. Besides, the VPN label that was allocated to

each local route must also be conveyed with this route. The VPN routes will also be

flagged - as extended BGP community attributes - with their one or more Route

Targets. Finally, the Next Hop BGP attribute value is the (advertising) PE loopback

address itself.


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).


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


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


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 (PE1’s output interface: if_1a); at Px

router, the top labels are swapped (19 replaces 12) and the labelled packets forwarded

towards Py, which is the penultimate hop in the LSP. As a result, the outer labels are

popped and the packets sent towards PE2 with only the inner label in front. At egress

PE2, the relevant VRF sub-interface is retrieved from the VPN label and the original

IPv4 packet is finally forwarded to the CE enabling us to reach the server within the site.


CHAPTER 6

WIRELESS LAST MILE REMOTE SITE CONNECTIVITY

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.

6.2 REMOTE SITE CONNECTIVITY

Fig. 6.1 A typical wireless last mile remote site connectivity

The base stations or PoPs are connected with the core network using optical fibers or

redundant RF links. This connectivity is provided with the PoP end router. This router is

intern connected to a switch. The radios in the base station are connected to this switch at

one end and the antenna at another using a pigtail cable.

At the client side, we have an antenna installed which is again connected to the client end

radio using a pigtail cable. The client end radio is connected to the client router via a PoE

(Power over Ethernet) device which provides DC voltage to power the modem. The

router is then connected to the internal client LAN.


The information which arrives at the base station is modulated in the radio and

transmitted using the antenna. The client end antenna receives this signal and the client

radio demodulates it and sends it across to the client end devices.

6.3 RADIOS

Wireless last mile connectivity is established with the help of Radios and antennas. Based

on the purpose and requirements different radios were used at Tulip. Each of the radio

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

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

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

These radios are primarily used in the backbone to provide redundant backbone RF links

to the fiber network. The system provides up to point to point 48 Mbps wireless link and

supports range up to 80 km. It combines legacy TDM and Ethernet services over 2.4 GHz

and 5.x GHz license exempt bands. Operation over 2.4GHz and 5.x GHz bands is not

affected by harsh weather conditions, such as fog, heavy rain etc. Radwin employs Time

Division Duplex (TDD) transmission. This technology simplifies the installation and

configuration procedure. There is no need to plan and to allocate separate channels for

the uplink and downlink data streams.

.

6.3.3 Firepro

These radios can be used for both point to point and point to multi-point wireless


connections. However it is primarily used for point to point links, where it can take a load

of up to 2 Mbps in a dedicated fashion and supports network range upto 60 kms. It can

be configured in bridging and routing modes. The main advantage of Firepro is that it can

act like a mini router in itself.

It allows full remote and local management through SNMP using the tool WinBox.

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

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.

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 customer’s remote VPN

link is down or some problems in the connectivity are being faced. For the remote

monitoring fault identification in the client link various tools are used. The following

flowchart illustrates the hierarchy followed for link troubleshooting in Tulip NOC.


Fig. 7.2 Hierarchy followed for link troubleshooting

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.

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

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

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.

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.


http://en.wikipedia.org/wiki/Signal_(electrical_engineering)

http://en.wikipedia.org/wiki/Radio

http://en.wikipedia.org/wiki/Electric_power

Fig. 7.5 SPR BER Performance Monitoring

Fig. 7.6 SPR RSSI Performance Monitoring

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.

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.

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

.

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

CHAPTER 8


CLIENT CASE STUDIES

Tulip provided a variety of VPN services to its clients. Two of the circuits that were

handled by as an L1 member in the team were Reliance L2 circuits and Indiabulls

Layer 3 MPLS VPN circuits.

8.1 RELIANCE L2 CIRCUITS

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.

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:

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)

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


http://en.wikipedia.org/wiki/Base_Transceiver_Station

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.

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 won’t

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.

x) Now suppose we are not able to ping Reliance PE IP from the access port of main

POP switch, then we first make sure that part of L2 circuit inside Tulip network is

working fine. To do this we assign Reliance PE IP to the laptop (it won’t collide as

the logical connectivity with Reliance is already not working) and revert the client

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.

8.2 INDIABULLS


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.

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

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 customer’s corporate network based on a layer 2 VPN (e.g.

Frame Relay, ATM). Also layer 2 and layer 3 VPNs are not mutually exclusive. As was

mentioned before, the same MPLS-based backbone allows the deployment of both VPN

models simultaneously.

IPsec and MPLS are undoubtedly the two main enabling technologies to build Layer 3

VPNs. While IPsec is particularly suited to handle security since it is the only VPN

technology to support data encryption, it can be deployed over any IP-based network and

is only limited by the scope of the service provider network domain. MPLS is mainly

oriented to cope with such requirements as scalability, traffic engineering and QoS control


and is the only feasible solution to support large scale IPVPN implementations. However,

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

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.

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, Joël, White Paper, Keep it Simple with BGP/MPLS Virtual Private

Networks

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


http://www.tuliptelecom.com/

http://www.cisco.com/

http://www.vpnc.org/

http://www.wikipedia.org/

final project report vpn

Documents