Data Communication - DOC

Document Sample
Data Communication - DOC Powered By Docstoc
					Bharat Sanchar Nigam Limited Hkkjr lapkj fuxe fyfeVsM

       JTO Ph-II DATA NETWORK
               WEEK-3 (NIB II Project 1)




                       BSNL
               ES & IT FACULTY
           COURSE CODE – BRBCOIF114

     BHARAT RATNA BHIMRAO AMBEDKAR
      INSTITUTE OF TELECOM TRAINING,
       RIDGE ROAD, JABALPUR – 482 001
              (ISO-9008 : 2008 Certified)
                       ―DATA NETWORK‖ FOR JTOs PH-II


                PHASE II SPECIALIZATION TRAINING
                               ON
                   ―DATA NETWORKS‖ FOR JTOs

                                      INDEX

                  Week-III             NIB-II Project 1

S No    Topic                                               Page No.
   1.   NIB-II Overview                                     2
   2.   Overview of MPLS Technology MPLS based Layer-2 VPN, 24
        Basic MPLS Lab & MPLS based Layer-2 VPN
        Configuration and QOS


   3.   Label Distribution Protocol                         148

   4.   RSVP-TE                                             166
   5.   MPLS Based Layer-3 VPN                              220
   6.   Cisco Router Configuration: MPLS based Layer-3 VPN 225
        Configuration using MP-iBGP/eBGP, MP-iBGP/OSPF &
        MP-iBGP/Static/Default
   7.   NMS & EMS (Project-1) OSS/BS as part of Project 3   232
   8.   NGN, Wi-MAX, Voip, IMS                              245




BRBRAITT : June-2011                                                   1
                  ―DATA NETWORK‖ FOR JTOs PH-II




                       NIB-II OVERVIEW




BRBRAITT : June-2011                              2
                          ―DATA NETWORK‖ FOR JTOs PH-II


OVERVIEW OF NATIONAL INTERNET BACKBONE-II (NIB-II)

Introduction
BSNL has planned to setup NIB-II to provide world class infrastructure to offer
various value added services to a broader customer base county-wide that will help to
accelerate the Internet revolution in India. Moreover the NIB-II will create a platform,
which enables e-governance, e-banking, e-learning, etc. with the key point of Service
Level Agreements & Guarantee in tune with Global standards and customer
expectations.
   NIB-II has been grouped into following three major projects.

      Project 1: - MPLS based IP Network infrastructure covering 71 cities along
       with associated NMS, PMS, Firewall and Caching platforms.
      Project 2.1: Access Gateway platform using Dialup comprising of narrow
       band RAS and DSL equipment.
      Project 2.2: Access Gateway platform comprising of Broadband RAS and
       DSL equipment.
      Project 3:     Messaging and Storage platform and Provisioning, Billing and
       Customer care and Enterprise management system.
The network shall seamlessly integrate with the already existing network
infrastructure comprising of the TCP/IP based NIB-I and MPLS VPN network. The
NIB-II project comprises of Technology solutions from different product
manufacturers with the provision for future expansion.
SERVICES PLANNED IN NIB-II
Internet Access
    Dialup access services/ Leased Access Services.
    Digital Subscriber Line (DSL) Access Services: Broadband ―always-on-
       internet‖ access over copper cables.
    Direct Ethernet Access Services: Broadband ―always-on-internet‖ access
       using Fiber-to-the-building.
Virtual Private Network (VPN) Services
    Layer 2 MPLS VPN Services: Point-to-point connectivity between corporate
       LAN sites.
    Layer 3 MPLS VPN Intranet and Extranet Services: LAN interconnectivity
       between multiple Corporate LAN sites.
    Managed Customer Premises Equipment (CPE) Services.
Value Added Services
    Encryption Services: One of the end-to-end data security features.
    Firewall Services: One of the security features provided to customer.
    Network Address Translation (NAT) Services: Service that will enable private
       users to access public networks.
Messaging Services
Data Centre Services at Bangalore, Delhi and Mumbai
Broadband Services through DSL & Direct Ethernet
    Fast Internet Access Services
    Terminating Dialup and DSL/Direct Ethernet Customers on MPLS VPNs
    Multicast Video Streaming Services.
    Video on Demand Services


BRBRAITT : June-2011                                                                  3
                      ―DATA NETWORK‖ FOR JTOs PH-II


Network Architecture:
Core Network:The NIB-II shall constitute an integrated 2-layer IP and MPLS
network. The Layer 1 network will constitute the high speed Backbone comprising of
Core routers with built in redundancies supporting both TCP/IP and MPLS protocols
with link capacities in accordance with the traffic justification. Its function will
primarily be limited to high-speed packet forwarding between the core nodes. All the
A nodes in the NIB-I shall form the Core layer. The five major nodes at Mumbai,
Bangalore, Delhi, Kolkata and Chennai are configured in the full mesh with link
bandwidth of STM-16. The remaining 9 nodes of Pune, Hyderabad, Ahemdabad,
Luchnow, Jullundhar, Jaipur, Indore, Ernakulam and Patna are configured in dual
mesh with link bandwidths of STM-16, (Refer Figure 1(a),1(b) & 1(c)).




BRBRAITT : June-2011                                                              4
                  ―DATA NETWORK‖ FOR JTOs PH-II




Figure (a)




BRBRAITT : June-2011                              5
                                ―DATA NETWORK‖ FOR JTOs PH-II


                                                             A1 + A2 + A3 POPS
                                                              IP MPLS Core Network

                        Jullunder
                              Core
                              A3
                                          Del          Lucknow
            Jaipur
                                  Core
                                          hi      Core
                                                  A3
                Core              A1
                A3
                                                                     Patn
Ahmedabad                                                            a
                        Indore                                       Core
     Core                                                            A3
     A2
                         Core
                         A3



                       Pune                                           Core
       Core
                                                                      A1
       A1                              Hyderaba                             Kolkatta
Mumbai                 Core
                       A2
                                       d Core
                                         A2


 Mangalor                                                                                 STM –16 link
 e
            Bangalore Core                                                         Core
                                                                                          Cisco 12416
                                                Core                               (P)    Router
                        A1
                                                A1                                        Cisco 12410
                                                                                   Core
                                                   Chennai                         A2     Router
                Ernakulam       Core                                               Core
                                                                                          Cisco 12410
                                A3                                                 A3     Router


                                                       Figure 1(b)




BRBRAITT : June-2011                                                                                     6
                                 ―DATA NETWORK‖ FOR JTOs PH-II




                                                                     A1 + A2 + A3 + A4 POPS

                                                                      IP MPLS Core Network

                         Jullunder      Chandigarh
                                        Core
                                Core
                                        A4
                                A3
                                              Delhi      Lucknow
        Jaipur                                                         Allahabad                   Guwahati
                                     Core                Core
                                                         A3
                 Core                A1                             Core
                 A3                                                                                Core
                                                                    A4
                                                                                                   A4

     Ahmedabad
                                                                           Patna
                                                                           Core
      Core                                                                 A3      Core
      A2                   Indore                                                  A4
                                                                                      Ranchi
                           Core Nagpu
                           A3
                                r Core
                                        A4

                                           Raipur                           Core
        Core
                                                                            A1
        A1                      Pun Hyderabad Core
   Mumba                 Core                                                 Kolkatt
                                               A4
                         A2     e
   i                                  Core                            Core    a
                                             A2                       A4
                  Core                                                  Bhubaneshw               STM -1 LINK
                                                                Core
                  A4
 Mangalor                                                       A4      ar
                                                                                                 STM-16 LINK
 e                                                                   Vijayawa
                                                                     da               Core
                                                                                                 Cisco 12416
                          Core
             BangalorA1                            Core                                   (P)    Router
                                                   A1
             e                                                                            Core   Cisco 12410
                                                         Chenn                            A2
                                                         ai                                      Router
                 Ernakula        Core             Core   Coimbatore                       Core   Cisco 12410
                                 A3               A4                                      A3
                 m                                                                               Router
                                                                                                 Juniper M40e
                                                                                          Core
                                                                                          A4     Router



Project 1
(MPLS based IP Network infrastructure covering 71 cities along with associated
NMS, PMS, Firewall and Caching platforms.)

MPLS based networks provide a cost effective way to enhance customer networking
quality, rather than setting up and managing individual point-to-point circuits between
each office, customers need to provide only one connection from their office router to
a service-provider edge router. The service-provider edge router either forwards the IP
packets in the IP network or in the case of MPLS configured access labels the packets
and routes them through its MPLS core to the edge closest to destination. IP/TCP
connectivity shall be provided through Provider (P) routers and Provider Edge (PE)
routers. The city-wise categorization of nodes under NIB-II Project 1 is given in Table
1.




BRBRAITT : June-2011                                                                                            7
                       ―DATA NETWORK‖ FOR JTOs PH-II


           Table 1: City-wise categorization of nodes under NIB-II Project 1

Node type      No of Cities     Name of cities               Devices

A1             5                Chennai,        Mumbai, Core router - Cisco 12416
                                Bangalore,   Delhi and
                                Kolkata                 Edge Router Cisco 7613

A2             3                Hyderabad,       Pune   and Core router - Cisco 12410
                                Ahemdabad
                                                             Edge Router Cisco 7613

A3             6                Lucknow,        Jullundhar, Core router - Cisco 12410
                                Jaipur, Indore, Ernakulam
                                and Patna                   Edge Router Cisco 7613

A4             10               Coimbtore, Chandigarh, Core router - Juniper M40
                                Allahabad,     Guwahati,
                                Ranchi,    Bhuvneshwar, Edge Router Cisco 7613
                                Raipur,       Mangalore,
                                Nagpur, and Vijaivwada

B1             21               --                           Edge Router Cisco 7613

B2             26               --                           Edge Router Cisco 7613


MPLS based network is a 2-layer centrally managed IP backbone network designed to
provide reliable routes to cover all possible designations within and outside the
country.
Network Architecture of Project 1:
The Layer - 1 Core network (A1, A2, and A3 cities) constitutes the high speed
Backbone (STM-16) as shown in Figure 1. The Layer - 1 nodes consist of high end
fully redundant Core routers, and are interfaced to Edge routers through Gigabit
Ethernet interfaces.

The Layer - 2 Edge network is the second layer of the IP backbone network and
primarily supports MPLS edge functionality. The function of this layer is to enforce
QoS and other administrative policies. This layer provides customer access through
following three mechanisms,
        Dialup
        Dedicated Access and
        Broadband access.

This layer provides connectivity to secure VPNs as well as to Internet Data Centers.

Edge routers in 71 cities are connected to the Core layer either locally through the
Gigabit Ethernet interfaces or remotely through dual homed STM-1 links.




BRBRAITT : June-2011                                                                   8
                       ―DATA NETWORK‖ FOR JTOs PH-II


The network is envisaged to provide QoS features associated with MPLS technology
with all traffic shaping and traffic engineering features. It provides peering interfaces
to other domains and serves as an Internet Exchange to ISPs. It supports IP
networking and Border Gateway Protocol (BGP)/ Multi Protocol Label Switching
(MPLS) technology. The network supports data, voice and video applications over
Layer 2 and Layer 3 MPLS VPNs.

The network architecture of NIB-II provides for integration of other networks such as
NIB-I and MPLS VPN of BSNL. It shall provide a common Network Management
System (NMS) and VPN / Bandwidth Provisioning System for the entire integrated IP
network infrastructure. The network infrastructure for NIB-II is intended to provide IP
network access, both on retail as well as wholesale basis, to dialup, DSL and leased
access customers. The network provides a common IP infrastructure that supports all
smaller open networks and sub-networks.
The Primary objectives in setting up the MPLS based IP network
    Building a common IP infrastructure that shall support all smaller networks
      and sub networks. The platform is intended to be used for convergent services,
      integrating data, voice and video and shall be the primary source of Internet
      bandwidth for ISPs, Corporate, Institutions, Government bodies and retail
      users.
    Making the service very simple for customers to use even if they lack
      experience in IP routing, along with Service Level Agreement (SLA)
      offerings.
    Make a service very scalable and flexible to facilitate large-scale deployment.
    Capable of meeting a wide range of customer requirements, including security,
      quality of service (QoS), and any-to-any connectivity.
    Capable of offering fully managed services to customers.
Caching Platform:
The Caching platform makes the contents (HTTP, MMS, FTP etc.) available at the
POP/ Core locations and saves upstream International bandwidth. The Caching
platform enables faster responses from web.

The web caching solution needs to be deployed at 8 cities with International
Gateways. The web caching solution should meet the bandwidth requirements and
shall be scalable to future expansions of bandwidth at these locations.




BRBRAITT : June-2011                                                                   9
                       ―DATA NETWORK‖ FOR JTOs PH-II


Services planned to be offered under Project 1:
   The following services shall be offered to customers using the MPLS based IP
   networks.
Layer 3 MPLS VPN Services
    Intranet-Managed & Unmanaged
    Extranet Managed & Unmanaged
    Internet Access services
Layer 2 MPLS VPN Services
    Ethernet over MPLS
    Frame relay over MPLS
    PPP over MPLS
    Cisco HDLC over MPLS (Optional)
    VPLS (Virtual Private LAN service)
    Layer 2 Any-to-Any Interworking (Except ATM)


   1. Encryption Services

   2. Multicast Services

   3. Firewall Services

   4. Network Address Translation (NAT) Services


Project 2
(Access Gateway Platform)
The NIB-II Access Gateway platform shall provide Internet Access at any time of the
day, from any place, using any device such as PC, analog phone, wireless or mobile
phone, or Personal Digital Assistant (PDA). The Access Gateway Platform (AGP) is
built around two distinct platforms, one supporting a unified dialing network
architecture that delivers voice, data and fax services through an open programmable
gateway and the other supporting a unified always-on Internet Access platform on
Ethernet-IP. The open programmable dialing gateway is dimensioned to provide 80%
plain data RAS and 20% Universal RAS ports. The always-on Internet Access
platform is built around the DSL technology using ADSL, SHDSL and VDSL that
delivers voice, data and video services over increasingly larger bandwidths directly on
Ethernet-IP local networks to residential and corporate users, enabling applications
like Broadcast TV, Video on Demand, Pay per View, Content Delivery, Interactive
gaming, Music Services, Video-Conferencing, IP-Multicasting Services, Education on
Demand, Interactive distant learning, Remote Medical Treatment, GIS based
applications, IP PBX, IP Centrex, VoIP, VoDSL, High speed Internet, MPLS VPN
etc.

NIB-II Universal Access Gateway infrastructure is conceived as an open
infrastructure for carrying various services.




BRBRAITT : June-2011                                                                10
                       ―DATA NETWORK‖ FOR JTOs PH-II


The following services are proposed to be provided as part of the scope of work.
        Dial VPN/Internet Access service
        ADSL, SHDSL & VDSL IP-Ethernet High speed services            (0.5 to 50 Mbps
         over existing Copper cables)
        Wholesale Dial or port retailing service
        Internet Call Waiting service
        IP based Unified Messaging Service
        Teleconferencing Service
        Internet Telephony Service
        Hosted voice services / IP Centrex.

The implementation of the Project 2 shall be deployed in two phases.
Project 2.1 is for narrow band access
Project 2.2 is for broadband access

Project 2.1: - This project is for the deployment of narrow band services in 71 Cities.
Including validation nodes Kolkata (A1), Mumbai (A3), Agra (B1) and Shimla (B2).
City-wise classification of Nodes under Project 2.1 of NIB-II is given in Tables 2 and
3.

Table 2: City-wise classification of Nodes under Project 2.1 of NIB-II for L2 Bidder
(M/s. UTStarcom Inc.)

Type of Number        Name of City
Node    of Cities

A1         1          Kolkata

A2         0          --

A3         5          Jallandhar, Mumbai, New Delhi, Lucknow, Patna,

A4         3          Chandigarh, Guwahati,

                      Ranchi

B1         6          Agra, Noida, Jammu, Amritsar, Ludhiana, Shilong

B2         8          Jamshedpur, Durgapur, Siliguri, Dehradun, Ferozpur, Shimla,
                      Ghaziabad, Meerut


Table 3: City-wise classification of Nodes under Project 2.1 of NIB-II for L1 Bidder
(M/s. ITI LTD.)




BRBRAITT : June-2011                                                                11
                       ―DATA NETWORK‖ FOR JTOs PH-II


 Type of Number         Name of City
 Node    of Cities

 A1            2        Chennai, Bangalore

 A2            3        Hyderabad, Ahemedabad, Pune

 A3            3        Ernakulam, Indore, Jaipur

 A4            7        Coimbatore,   Maangalore,      Vijaywada             (Krishana),
                        Bhuvaneswar, Raipur, Allahabad, Nagpur

 B1            15       Madurai, Trivandrum, Mysore, Vizag, Bhopal, Gwalior,
                        Rajkot, Surat, Vadodara, Faridabad, Gurgoan, Kanpur,
                        Varanasi, Jodhpur, Nasik

 B2            18       Trichy, Pondicherry, Cannanore, Palghat, Trichur, Belgaum,
                        Hubli, Kakinada, Cuddapah, Dimapur, Jabalpur, Mehsana,
                        Ambala, Ajmer, Kalyan, Aurangabad, Panjim, Kolhapur



Components of Narrow Band Access Network
   Narrow Band Remote Access Server
   LAN Switch
   eMS Server

Project 2.2:
This Project is for the deployment of broadband services in 198 cities with 69
important cities where Digital Subscriber Line Access Multiplexer (DSLAM) shall be
deployed. The cities are categorized under A1 (3 cites), A2 (3 cites), A3 (6 cites), A4
(10 cites), B1 (21 cites), B2 (26 cites), and others (129 cities). Delhi and Mumbai will
not have any broadband equipment under Project 2.2 of NIB-II.
Services planned through Project 2.2
    Primary source of Internet bandwidth for retail users for application such as
       Web browsing, e-commerce etc
    Multicast video services, video on demand etc through Broadband Remote
       Access Server (BRAS).
    Allow wholesale BRAS ports to be assigned to smaller ISPs through the
       franchises model wherein the later has a separate network of DSLAMs, AAA,
       LDAP through a revenue scheme of BSNL.
    Dialup VPN (VPDN) user connects to NIB-II through the Narrow band RAS
       and is connected to its private network through a secure L2TP tunnel
       established between Narrowband RAS and Broadband RAS.
    Support for both prepaid and postpaid Broadband services.

Components of Broad Band Access Network
   Broad Band Remote Access Server (BBRAS)
   Gigabit and Fast Ethernet Aggregation Switches (LAN Switches)
   Digital Subscriber Line Access Multiplexers (DSLAMs)


BRBRAITT : June-2011                                                                 12
                     ―DATA NETWORK‖ FOR JTOs PH-II


      SSSS/SSSC (Subscriber Service Selection System/ Centre)
      Servers for AAA, LDAP at Pune
      Provisioning and configuration management at NOC




                   Broadband connectivity Diagram in A cities




                   Broadband connectivity Diagram in B cities


BRBRAITT : June-2011                                             13
                       ―DATA NETWORK‖ FOR JTOs PH-II




Project 3:
[Messaging and Storage Service Platform, Provisioning, Billing & Customer care,
Enterprise Management System (EMS) and Security System.]

The Core messaging system shall be the heart of NIB-II that will enable BSNL to add
users across varied value added services. This shall envisage design and up gradation
of the current messaging system to grow from the existing infrastructure in NIB-I
supporting 650,000 users to support the increasing user base. The messaging systems
and associated Storage will be implemented in phases, in accordance with phased
induction of Access equipment.

The system shall be an integrated provisioning, billing, customer care and accounting
platform and shall support billing for the complete range of IP based services
mentioned and meet next-generation requirements as well.
   The salient aspects of the projects are summarized as follows:
    Setting up proven, robust, scalable Messaging Solution with best in class
      security components.
    Roll out across the country supported by 5 Messaging & associated storage
      systems at Delhi, Mumbai, Bangalore, Chennai and Kolkata.
    Designed with High Availability architecture with no single point of failure.
   
Components of the Solution:
The proposed solution shall consist of the following components with the items of
functionality listed below:
    (i) Messaging
    a) DNS, AAA
    b) MMP
    c) LDAP (Consumer, Replicator Hub, Primary and Secondary)
    d) SMTP IN & OUT
    e) Messaging Servers
    f) Address Book Servers, etc.
    (ii) Storage
    a) SAN Switch & SAN Storage
    b) Tape Library
    c) Staging Servers, etc.
Storage platform
Various Applications servers placed at the 5 Messaging Storage locations like LDAP,
AAA, EMS, Messaging, UMS & Billing etc. would require Data storage capacities
for storing User‘s mailboxes, Billing data etc. Such huge storage requirements need to
be met with the Fast, Reliable & Scalable storage devices that would be deployed as
―End to End High Performance Switched Architecture Fiber Channel SAN (Storage
Area Networks) providing No Single Point of Failure‖.




BRBRAITT : June-2011                                                               14
                       ―DATA NETWORK‖ FOR JTOs PH-II


 Such storage device should be compatible with all the Servers of major companies
such as HP, IBM, SUN, Dell etc. so that choice of Application Servers Platform
remains independent of the storage device.
System Dimensioning:
The user base will be serviced through 5 Messaging and associated Storage systems
that will be set up in the 5 cities. Each of the cities will be connected through the IP
Backbone. Since the proposed user base is envisaged to increase in a phased manner,
the associated messaging system is also proposed to be upgraded in phases
correspondingly.
The system should be designed to support:
    On-line services such as Internet, pay-per-view TV and video on demand or a
       combination of all or some of the above.
    Periodic charges, such as telephone line and cable TV rental.
    One-time costs, such as connection fees.
    Events, such as telephone calls, data service usage, pay-per-view TV
       selections, home shopping purchases, utility metered usage – such as
       electricity supply (live site example)
    Financial services ASP services.
    Telephony services.
    Enterprise Backup Systems.
The billing system shall be capable of
    Providing electronic versions of bills to customers over the Internet.
    Creation/modification of service.
    Processing Service requests in real time and non-real time and accounting in
       real time.
    Producing flexible billing depending upon the use of service.

Security Systems
These include the following.
     Load Balancers
     Firewall Appliances
     Intrusion Detection System
     Antivirus system, etc.

Network Operation Center (NOC)
The NOC shall provide facility for centralized Network Management and end-to-end
Provisioning of multiple services, giving a single view of the entire network services
being delivered countywide. The servers for the NOC shall be connected through a
Gigabit Ethernet link from Core router with three zones of firewall within the Centre.

The network shall be centrally managed from Network Operation Centre (NOC)
located at two sites, one of them being master and the other the disaster recovery site.
The main NOC is at Bangalore with Disaster Recovery is at Pune. Interface to the
NMS back-office facility shall be provided along with Firewall security in the Data
Centre. All customer databases shall reside centrally at NOC.

The NMS of NIB-II project 1 is the comprehensive NMS for entire NIB-II including
NIB-I, MPLS VPN, Project 2.1, Project 2.2, which will support entire F (Fault), C
(Configuration), A (Accounting including Access/Inventory), P (Performance) and S


BRBRAITT : June-2011                                                                 15
                      ―DATA NETWORK‖ FOR JTOs PH-II


(Security functionality). The conceptual view of eMS, NMS OSS/BSS for NIB-II is
given in figure 4 and the connectivity Architecture of NOC at Bangalore is shown in
figure 5.




                 Conceptual view of eMS, NMS, EMS OSS/BSS for NIB-II




BRBRAITT : June-2011                                                            16
                       ―DATA NETWORK‖ FOR JTOs PH-II

                      Fig. 5: Bangalore NOC Connectivity Architecture.

Service Level Agreement (SLA):

It shall be possible to support SLA i.e. the level of service that the customer can
expect together with any penalties to be levied by the service provider for failure to
deliver. It should be possible to provide at least 4 classes of services. The SLA
parameters shall include measurements of service delivery, availability, latency,
throughput and restoration time etc. It should be possible to generate management
reports providing information on customer node configuration and charges, faults and
achievement against the SLAs. It shall be possible to deliver network management
reports via a secure Website.
Implementation of OSS, Messaging, Storage, Billing, EMS & Security Solutions

Messaging
   Messaging Solution of NIB-II will provide the SMTP, POP3, IMAP4,
      WEBMAIL, WAPMAIL and Notifications services as a Class Of Service to
      all the customers of NIB-II and NIB-I
   Will support for Country wide roaming for dial up and message store access
      through any data center.
   The Messaging Server will support Wireless messaging and Directory services
      to WAP enabled phones and laptop users
   Message store will be content aware to support different types of services to
      be created by BSNL ranging from text email to multi-media messaging service
   Will provide Family Mailbox where the head of the family can manage
      options for Family members. Options will include setting of allowed and block
      senders and recipients and control of Anti-SPAM settings.
   Messaging solution shall provide flexible control of message aging to define
      the conditions under which messages are automatically erased
   Web mail interface will support multimedia message types for voice and fax
      mail, providing unified messaging interface in future
   Message Transfer Agent (MTA) will be designed to handle peak loads without
      service degradation or message loss
   MTAs will be designed to handle large message queues. There will be
      capability available to analyze and manage large message queues generated
      due to unreachability of message store (internal) and mail exchangers of other
      ISPs (external) or SPAM
Web Hosting
   Web space (Data Storage) on servers based on UNIX and Microsoft for
      hosting HTML pages with browser
   Ftp access for uploading and downloading pages as per the plan. Restriction
      on simultaneous ftp sessions
   FrontPage etc. access for Web-publishing
   Multiple Email Ids per domain with flexible email quota, as per the plan
   Web Interface for centralized administration by user and administrators for
      services, usage reports, invoice and other reports
   It will provide access to customers for analyzing the Web-site performance
      through analysis tools
   Interface for online registration of domain name




BRBRAITT : June-2011                                                               17
                       ―DATA NETWORK‖ FOR JTOs PH-II


Web Collocation
    Necessary Security measures will be implemented both from customer and
       BSNL‘s perspective
    Billing for this will be done on the basis of usage
    One of the service differentiator will be bandwidth on which the server is
       collocated.
Security Solution
    Anti-Virus solution: It will provide a mechanism to detect unknown virus. The
       solution will protect any Gateway and SMTP traffic from virus
    Notification: For mails containing repeated complaints regarding abuse from
       the same IP address, mail will be sent automatically to the technical contact of
       the assignee of that IP address
    Network Intrusion detection System: The NIDS will detect unauthorized
       internal/external intrusion attempts into the data centers of NIB-II and will
       enable to apply appropriate policies on the firewall so as to prevent such
       attacks in real time. Suitable alarms will also be sent to the Security Control
       Console
    Anti Control System: It is provided for Database servers, Messaging Stores,
       Web-Hosting Servers and NIDS
    Self-protection: Must be able to prevent hackers with root/administrator access
       from circumventing or shutting down the security engine
    Resource protection: Must allow controlling of access to all system resources
       including data files, devices, processes/services and audit files
    Rights delegation: Must provide the ability to designate specific users as
       administrators, auditors and password managers etc with appropriate rights
    Program Controls: Must provide protection against Back Doors and Trojan
       Horses
Enterprise Management System
    Objective of EMS is to provide a snap-shot graphical view of the health of
       NIB-II IT infrastructure as a whole including networking equipment, servers
       and services (business and process view)
    Reporting system will be able to generate customized reports such as event-
       level, performance -level and service-level reports grouped by specific data
       fields such as time period, location, customer, series type, device type etc
    Security Management will display alarm and events specified by the criteria
       such as alarm type, vendor, service, location, source of attack, type of attack
       and impacted services
    Event Management will capture all the events that are being generated across
       the complete IT infrastructure, correlates them and initiate corrective actions
       automatically, as defined
    System& Application Management will measure the availability and
       performance of heterogeneous host systems on a 24x7x365 basis and initiate
       preventive and corrective actions automatically
    System& Application Management will monitor and manage multiple
       attributes (such as status, memory usage, size and resident size, process time,
       threads, response time, average throughput and CPU utilization etc) of a
       running process and problems and perform restart when processes go down. It
       will generate reports on QOS and capacity planning




BRBRAITT : June-2011                                                                18
                                                                                          ―DATA NETWORK‖ FOR JTOs PH-II


OSS ARCHITECTURE

                                                                                    WEB SELF CARE PORTAL/IVRS (CTI)



                     Database                                                                                       DB
                                                                                                                                                                                    Rating

                                                                                                                                                                   Billing &                                      Wholesale
                                                                                                                                                                   Remittance                                     settlement
                                               OM work Flow




                                                                                                             ticketing/Help desk




                                                                                                                                                                                       DB
   management




                                                                                   Provisioning                                                                    Payment                                        Reporting
                                                                                   Subscriber

                                                                                                                                                                   Accounting

                                                                                                             Trouble
   Order




                                                                                                                                                                                    GL &
                                                                                                                                                                                    others




                                                   MIDDLEWARE-ENTERPRISE APPLICATION INTEGRATION (EAI)
                      Performance Management




                                                                                                                                                                                                                         Enterprise Management
                                                                                                  Database




                                                                                                                                                                                             Voucher Management
  Fault Management




                                                              Service Activation




                                                                                                                                   Network Inventory



                                                                                                                                                       Mediation




                                                                                                                                                                         Database




                                                                                                                                                                                                                         system
                                                                                                                                                                                             system


NIB-II Network Infrastructure (NE&NEManagers)                                                                                                                          All NIB-II Servers (Networking and
procured in project 1,2.1,2.2                                                                                                                                          Security Appliances and their Element
                                                                                                                                                                       Managers)




Web Portal
   Web Portal will be the gateway for customer and CSR based on their
     authorizations for accessing various system, services etc
   Portal will have an integration, with NMS, EMS and OSS for providing
     services to the BSNL‘s customer service representatives (direct, indirect,
     helpdesk, supervisor) and account managers
   Portal services Ranging from business, process, network, customer specific
     maps/views, trouble-ticketing, pre-sales query, post-sales order-booking, order
     tracking, trouble –shooting etc
   Portal will integrate with components like Service Provisioning, Order
     Management, Billing, Customer Care, EMS and Messaging etc. to provide a
     unified view of the network and services to the customers and CSRs for all the
     front office functions and some back office functions



BRBRAITT : June-2011                                                                                                                                                                                                             19
                       ―DATA NETWORK‖ FOR JTOs PH-II


      Order status and history provide both subscribers and the customer service
       representatives with sufficient data to fully manage and monitor the service
       selection and delivery process
      It will be possible to provide a user friendly interface for customers to plan
       and schedule their bandwidth for Band width on Demand services

Services provided by portal to the customers
    Customer registration services for both pre-paid and post-paid customer
    Self-registration for getting information about products and services
    Self-registration for availing services such as post-paid dialup service based on
       telephone number authentication
    Shopping cart for procuring services
    Access to services such as messaging, web-hosting, storage and content-
       services etc. This will include on demand services like video on demand and
       online gaming etc
    Booking an order for services. Allow the user to submit, and track service
       requests online at any time
    View current bill status in real time including billed, unbilled and pre-billed
       services, payment-details and other related information
    Reporting a problem by opening a fault docket and tracking its solution
    View the status of related network and services subscribed
    View the status of SLA compliance, SLA resolution and rebates applied
       through integration with billing and NMS

ORDER MANAGEMENT
OM will have
   Customer Interface Management
   Order Entry and Validation
     Workflow Management

Customer Interface Management &Order Entry and Validation:
    Order will be entered through Web-portal by CSR or Customer directly
    CSR will accept the order after completion of signed order form by the
      customer. He will scan it and attach it with the online order form
    All orders will be checked against the feasibility from the RMS For all
      committed orders, check will be made for customers credit worthiness/default
      and the billing system will generate a unique ID for the customer
    It will be possible to query the status of order, service, billing etc. on the basis
      of unique ID
    OM will track the order status
    OM will inform the billing system of successful provisioning or else it will
      roll back all the steps
    Record all the transactions between OM and customer
    Record the details of the services provisioned for the customer
    Purge customer data from RDBMS and LDAP databases based on pre-defined
      and configurable policies when the customer surrenders service

Work Flow Management:
   Work Flow Management will automate the process that controls and monitors
     the execution of an order according to the customer requirements. This



BRBRAITT : June-2011                                                                  20
                       ―DATA NETWORK‖ FOR JTOs PH-II


       involves the steps of qualification, reservation, configuration and verification
       of a service fulfillment instance
      Work Flow Management will integrate OM and provisioning Management
       systems (PMS) being procured under project-1, project –2.2 and Whole-sale
       Dial Application being procured under project-2.1

Subscriber Provisioning Management System (SPMS)
SPMS will cover the provisioning of following services under project 2.1 and project
3 through configurations in files. Subscriber Provisioning will be fully flexible to
support all the requirements of services
     Dial up Internet Access with different variants
     Messaging with different Variants
     Web Hosting
     Web Collocation
     Domain Hosting
     Broadband Internet Access with Content delivery through SSSC.
Mediation
   Billing mediation will be responsible for collecting usage and other charging
      data from the various network nodes, normalize the data into a consistent
      format and distribute it to other applications and billing system for processing
      this information
   System will collect different parameters from different sources to provide
      Cflow and Netflow based collection and mediation for usage based billing of
      different services including MPLS-VPN, Web-hosting, Message-Hosting etc
   Parameters are
   Bandwidth
   Volume
   Time of day/ day of week/ month (Peak/off peak)
   Application (WWW, Email (POP3/IMAP4), Video, E-commerce etc )
   Destination
   Type of Service (Gold, Silver, Bronze/best efforts) etc

DATABASE
   Latest Oracle RDBMS will be used with all applications
   RDBMS will work in fail over mode over geographical locations
   RDBMS will work in a distributed mode across multiple servers
   RDBMS will work in a cluster mode
   Provisioning will be made for data replication to or from databases of project
    1,2.1 and 2.2

HELP DESK AND TROUBLE TICKETING
   Whenever a customer reports a problem, a unique trouble ticket-ID will be
     generated by the system. This will be intimated to the customer, so that he can
     track the status on the basis of this ID
   It will be possible for customers to submit and check the status of reported
     problems through web interface
   System will automatically track, log and escalate user interactions and
     requests
   CSRs will be able to view, change the status of the calls, reassign/ transfer the
     trouble tickets to others CSRs or technical specialist through the web interface


BRBRAITT : June-2011                                                                21
                         ―DATA NETWORK‖ FOR JTOs PH-II


         Will be able to generate various customized Service Level Reports e.g. Open
          Call Reports, closed Call Reports, problem area/ Location Specific Reports
         Will have the capability for accepting queries through various sources
          including Telephone, email or Web interface
         System will check for tickets status and escalation and notify the management
          or next level of support staff based on predefined Service Level Agreement
          (SLA) which will include criteria like Service application, Severity and
          customer etc
         It will have bulletin board to allow CSRs, Managers and Customers to post
          and review messages about critical issues
         It will be possible to track the time spent on specific case
         It will be possible to generate work orders for field staff or technicians for
          fault repair
         Trouble ticketing system will interface with SLA and performance
          management systems to account for the period of network or service
          unavailability
         Trouble ticketing system will be able to extract all incidents, resolution
          progress reports and all affected services via its interface with the inventory
          system
         The trouble tickets will be attached to a work-flow where ever there are
          multiple steps required for resolution
         It will be possible to include information about the equipment, circuit built up
          details etc in the trouble ticket automatically after obtaining the same from
          inventory
         Will integrate with web-portal for report trouble ticket status
         System will allow CSR to check the network fault status as part of problem
          investigation

Billing
     Billing engine will cater to all the billing requirements of BSNL include Retail
      Billing (Prepaid and Postpaid), Wholesale and third party billing, Inter connect
      and content billing, Dealers and Agents Commissions etc
    Billing system will support the preparation of detailed bill, Differential tariff,
      Cross product discounting, Sponsored/split billing. Bundled accounting, Hot
      billing/On-demand billing, Hierarchy/ Corporate billing, Discounts &
      Promotions, Taxes, Notification system, Dealers and Agent commissions,
      Content Billing
    Billing system will allow customers the option of receiving complete event
      details along with their invoice or view them online through the Web portal.
      Provision will also be available for the customer to print the event-details from
      the Web portal in a printable format
Content Billing
    System will provide BSNL subscribers to access services provided by external
      content providers and be able to handle the revenue sharing with the content
      provider within the single billing platform
    System will allow content providers who do not have their own customer care
      and billing system to use the billing system of BSNL




BRBRAITT : June-2011                                                                   22
                      ―DATA NETWORK‖ FOR JTOs PH-II


Authentication, Authorization and Accounting
    Irrespective of mode of access (such as Dial-up Internet access, outsourced
      remote access, managed VPNs, Broadband etc), it will manage the
      Authentication of all users/customers- both locally and via proxy RADIUS-
      and deliver the appropriate level of service to each customer
    It will enable defining access schemes by time-of days, days-of-week, call
      type (PSTN, ISDN and DSL etc.), calling number and called number etc
    It will be capable of authenticating through CLI, DNIS, Voucher number, pin
      code etc
    Radius server will be able to handle at least 10,000 concurrent sessions per
      second
    It will integrate with Billing server for providing real time pre-paid balance
      management and session management across multiple sessions of multiple
      services of a user.




BRBRAITT : June-2011                                                            23
                  ―DATA NETWORK‖ FOR JTOs PH-II




         OVERVIEW OF MPLS TECHNOLOGY AND QOS




BRBRAITT : June-2011                              24
                       ―DATA NETWORK‖ FOR JTOs PH-II


Basic MPLS VPN Overview and Configuration
MPLS technology is being widely adopted by service providers worldwide to
implement VPNs to connect geographically separated customer sites. Previous
chapters introduce the basic concepts of MPLS and its operation, as well as
configuring MPLS for data forwarding. This chapter builds on that foundation and
shows how to use MPLS to provide VPN services to customers. This chapter also
presents the terminology and operation of various devices in an MPLS network used
to provide VPN services to customers.

The following topics will be covered in this chapter:
    Overlay and peer-to-peer VPN models
    Overview of MPLS VPN components and architecture
    VRFs, route distinguishers, and route targets
    MP-BGP operation and interaction
    Control plane and data plane operation in MPLS VPN
    Configuration of basic MPLS VPN
    Quality of Service
VPN Categories
VPNs were originally introduced to enable service providers to use common physical
infrastructure to implement emulated point-to-point links between customer sites. A
customer network implemented with any VPN technology would contain distinct
regions under the customer's control called the customer sites connected to each other
via the service provider (SP) network. In traditional router-based networks, different
sites belonging to the same customer were connected to each other using dedicated
point-to-point links. The cost of implementation depended on the number of customer
sites to be connected with these dedicated links. A full mesh of connected sites would
consequently imply an exponential increase in the cost associated.

Frame Relay and ATM were the first technologies widely adopted to implement
VPNs. These networks consisted of various devices, belonging to either the customer
or the service provider, that were components of the VPN solution. Generically, the
VPN realm would consist of the following regions:

Customer network— Consisted of the routers at the various customer sites. The
routers connecting individual customers' sites to the service provider network were
called customer edge (CE) routers.

Provider network— Used by the service provider to offer dedicated point-to-point
links over infrastructure owned by the service provider. Service provider devices to
which the CE routers were directly attached were called provider edge (PE) routers.
In addition, the service provider network might consist of devices used for forwarding
data in the SP backbone called provider (P) routers.

Depending on the service provider's participation in customer routing, the VPN
implementations can be classified broadly into one of the following:
      Overlay model
      Peer-to-peer model




BRBRAITT : June-2011                                                               25
                       ―DATA NETWORK‖ FOR JTOs PH-II


When Frame Relay and ATM provided customers with emulated private networks,
the provider did not participate in customer routing. The service provider was only
responsible for providing the customer with transport of customer data using virtual
point-to-point links. As a result, the service provider would only provide customers
with virtual circuit connectivity at Layer 2; this implementation was referred to as the
Overlay model. If the virtual circuit was permanent or available for use by the
customer at all times, it was called a permanent virtual circuit (PVC). If the circuit
was established by the provider on-demand, it was called a switched virtual circuit
(SVC). The primary drawback of an Overlay model was the full mesh of virtual
circuits between all customer sites for optimal connectivity (except in the case of hub
and spoke or partial hub and spoke deployments). If the number of customer sites was
N, N(N-1)/2 was the total number of circuits that would be necessary for optimal
routing.

Overlay VPNs were initially implemented by the SP by providing either Layer 1
(physical layer) connectivity or a Layer 2 transport circuit between customer sites. In
the Layer 1 implementation, the SP would provide physical layer connectivity
between customer sites, and the customer was responsible for all other layers. In the
Layer 2 implementation (depicted in Figure ), the SP was responsible for
transportation of Layer 2 frames (or cells) between customer sites, which was
traditionally implemented using either Frame Relay or ATM switches as PE devices.
Therefore, the service provider was not aware of customer routing or routes. Later,
overlay VPNs were also implemented using VPN services over IP (Layer 3) with
tunneling protocols like L2TP, GRE, and IPSec to interconnect customer sites. In all
cases, the SP network was transparent to the customer, and the routing protocols were
run directly between customer routers.




BRBRAITT : June-2011                                                                 26
                      ―DATA NETWORK‖ FOR JTOs PH-II


                   Figure 3-1. Overlay and Peer-to-Peer Models
                                  [View full size image]




The peer-to-peer model was developed to overcome the drawbacks of the Overlay
model and provide customers with optimal data transport via the SP backbone. Hence,


BRBRAITT : June-2011                                                            27
                       ―DATA NETWORK‖ FOR JTOs PH-II


the service provider would actively participate in customer routing. In the peer-to-peer
model, routing information is exchanged between the customer routers and the service
provider routers, and customer data is transported across the service provider's core,
optimally. Customer routing information is carried between routers in the provider
network (P and PE routers) and customer network (CE routers). The peer-to-peer
model, consequently, does not require the creation of virtual circuits. As illustrated in
Figure , the CE routers exchange routes with the connected PE routers in the SP
domain. Customer routing information is propagated across the SP backbone between
PE and P routers and identifies the optimal path from one customer site to another.

Separation of customer-specific routing information is achieved by implementing
packet filters at the routers connecting to the customer network. Additionally, IP
addressing for the customer is handled by the service provider. This process is also
referred to as the shared PE peer-to-peer implementation. Figure 3-2 depicts the
various implementations of the peer-to-peer model.
                   Figure. Peer-to-Peer Model Implementations
                                    [View full size image]




Controlled route distribution was another method of implementing the peer-to-peer
model; routers in the core of the service provider's network contained network layer
reachability information for all customers' networks. The PE routers (connecting
customer network to provider network) in the provider network would contain only
information pertaining to their connected customers. A dedicated PE router was
required for each customer's site connecting to the provider network, and controlled
route distribution would occur between P and PE routers in the SP backbone network.
Only pertinent customer routes would be propagated to PE routers that were
connected to sites belonging to a specific customer. BGP with communities was
usually used in the SP backbone because it offered the most versatile route-filtering
tools. This implementation is often referred to as the dedicated PE peer-to-peer
model. This implementation, however, did not prove to be a viable operating business
model due to the higher equipment costs that were incurred by the provider to
maintain dedicated edge routers for customer sites connecting into the provider
backbone. A need arose for deploying efficient VPN architectures that could
implement a scalable peer-to-peer model.




BRBRAITT : June-2011                                                                  28
                       ―DATA NETWORK‖ FOR JTOs PH-II


MPLS VPN Architecture and Terminology
In the MPLS VPN architecture, the edge routers carry customer routing information,
providing optimal routing for traffic belonging to the customer for inter-site traffic.
The MPLS-based VPN model also accommodates customers using overlapping
address spaces, unlike the traditional peer-to-peer model in which optimal routing of
customer traffic required the provider to assign IP addresses to each of its customers
(or the customer to implement NAT) to avoid overlapping address spaces. MPLS
VPN is an implementation of the peer-to-peer model; the MPLS VPN backbone and
customer sites exchange Layer 3 customer routing information, and data is forwarded
between customer sites using the MPLS-enabled SP IP backbone.

The MPLS VPN domain, like the traditional VPN, consists of the customer network
and the provider network. The MPLS VPN model is very similar to the dedicated PE
router model in a peer-to-peer VPN implementation. However, instead of deploying a
dedicated PE router per customer, customer traffic is isolated on the same PE router
that provides connectivity into the service provider's network for multiple customers.
The components of an MPLS VPN shown in Figure are highlighted next.

                    Figure 3-3. MPLS VPN Network Architecture
                                   [View full size image]




The main components of MPLS VPN architecture are
      Customer network, which is usually a customer-controlled domain consisting
       of devices or routers spanning multiple sites belonging to the customer. In
       Figure , the customer network for Customer A consists of the routers CE1-A
       and CE2-A along with devices in the Customer A sites 1 and 2.
      CE routers, which are routers in the customer network that interface with the
       service provider network. In Figure , the CE routers for Customer A are CE1-
       A and CE2-A, and the CE routers for Customer B are CE1-B and CE2-B.
      Provider network, which is the provider-controlled domain consisting of
       provider edge and provider core routers that connect sites belonging to the
       customer on a shared infrastructure. The provider network controls the traffic
       routing between sites belonging to a customer along with customer traffic




BRBRAITT : June-2011                                                                29
                        ―DATA NETWORK‖ FOR JTOs PH-II


     isolation. In Figure , the provider network consists of the routers PE1, PE2,
     P1, P2, P3, and P4.
   PE routers, which are routers in the provider network that interface or
     connect to the customer edge routers in the customer network. PE1 and PE2
     are the provider edge routers in the MPLS VPN domain for customers A and
     B in Figure .
   P routers, which are routers in the core of the provider network that interface
     with either other provider core routers or provider edge routers. Routers P1,
     P2, P3, and P4 are the provider routers in Figure .
MPLS VPN Routing Model
An MPLS VPN implementation is very similar to a dedicated router peer-to-peer
model implementation. From a CE router's perspective, only IPv4 updates, as well as
data, are forwarded to the PE router. The CE router does not need any specific
configuration to enable it to be a part of a MPLS VPN domain. The only requirement
on the CE router is a routing protocol (or a static/default route) that enables the router
to exchange IPv4 routing information with the connected PE router.

In the MPLS VPN implementation, the PE router performs multiple functions. The PE
router must first be capable of isolating customer traffic if more than one customer is
connected to the PE router. Each customer, therefore, is assigned an independent
routing table similar to a dedicated PE router in the initial peer-to-peer discussion.
Routing across the SP backbone is performed using a routing process in the global
routing table. P routers provide label switching between provider edge routers and are
unaware of VPN routes. CE routers in the customer network are not aware of the P
routers and, thus, the internal topology of the SP network is transparent to the
customer. Figure depicts the PE router's functionality.



                         Figure 3-4. MPLS VPN Architecture
                                     [View full size image]




The P routers are only responsible for label switching of packets. They do not carry
VPN routes and do not participate in MPLS VPN routing. The PE routers exchange
IPv4 routes with connected CE routers using individual routing protocol contexts. To
enable scaling the network to large number of customer VPNs, multiprotocol BGP is
configured between PE routers to carry customer routes.




BRBRAITT : June-2011                                                                   30
                       ―DATA NETWORK‖ FOR JTOs PH-II


VRF: Virtual Routing and Forwarding Table
Customer isolation is achieved on the PE router by the use of virtual routing tables or
instances, also called virtual routing and forwarding tables/instances (VRFs). In
essence, it is similar to maintaining multiple dedicated routers for customers
connecting into the provider network. The function of a VRF is similar to a global
routing table, except that it contains all routes pertaining to a specific VPN versus the
global routing table. The VRF also contains a VRF-specific CEF forwarding table
analogous to the global CEF table and defines the connectivity requirements and
protocols for each customer site on a single PE router. The VRF defines routing
protocol contexts that are part of a specific VPN as well as the interfaces on the local
PE router that are part of a specific VPN and, hence, use the VRF. The interface that
is part of the VRF must support CEF switching. The number of interfaces that can be
bound to a VRF is only limited by the number of interfaces on the router, and a single
interface (logical or physical) can be associated with only one VRF.

The VRF contains an IP routing table analogous to the global IP routing table, a CEF
table, list of interfaces that are part of the VRF, and a set of rules defining routing
protocol exchange with attached CE routers (routing protocol contexts). In addition,
the VRF also contains VPN identifiers as well as VPN membership information (RD
and RT are covered in the next section). Figure shows the function of a VRF on a PE
router to implement customer routing isolation.

                    Figure 3-5. VRF Implementation on PE Router




As shown in Figure , Cisco IOS supports a variety of routing protocols as well as
individual routing processes (OSPF, EIGRP, etc.) per router. However, for some
routing protocols, such as RIP and BGP, IOS supports only a single instance of the
routing protocol. Therefore, to implement per VRF routing using these protocols that
are completely isolated from other VRFs, which might use the same PE-CE routing
protocols, the concept of routing context was developed.



BRBRAITT : June-2011                                                                  31
                       ―DATA NETWORK‖ FOR JTOs PH-II


Routing contexts were designed to support isolated copies of the same VPN PE-CE
routing protocols. These routing contexts can be implemented as either separated
processes, as in the case of OSPF, or as multiple instances of the same routing
protocol (in BGP, RIP, etc.). If multiple instances of the same routing protocol are in
use, each instance has its own set of parameters.

Cisco IOS currently supports either RIPv2 (multiple contexts), EIGRP (multiple
contexts), OSPFv2 (multiple processes), and BGPv4 (multiple contexts) as routing
protocols that can be used per VRF to exchange customer routing information
between CE and PE.

Note that the VRF interfaces can be either logical or physical, but each interface can
be assigned to only one VRF.
Route Distinguisher, Route Targets, MP-BGP, and Address Families
In the MPLS VPN routing model, the PE router provides isolation between customers
using VRFs. However, this information needs to be carried between PE routers to
enable data transfer between customer sites via the MPLS VPN backbone. The PE
router must be capable of implementing processes that enable overlapping address
spaces in connected customer networks. The PE router must also learn these routes
from attached customer networks and propagate this information using the shared
provider backbone. This is done by the association of a route distinguisher (RD) per
virtual routing table on a PE router.

A RD is a 64-bit unique identifier that is prepended to the 32-bit customer prefix or
route learned from a CE router, which makes it a unique 96-bit address that can be
transported between the PE routers in the MPLS domain. Thus, a unique RD is
configured per VRF on the PE router. The resulting address, which is 96-bits total
(32-bit customer prefix + 64-bit unique identifier or RD), is called a VPN version 4
(VPNv4) address.

VPNv4 addresses are exchanged between PE routers in the provider network in
addition to IPv4 (32-bit) addresses. The format of an RD is shown in Figure . As
shown in Figure , RD can be of two formats. If the provider does not have a BGP AS
number, the IP address format can be used, and, if the provider does have an AS
number, the AS number format can be used. Figure also shows the same IP prefix,
172.16.10.0/24, received from two different customers, is made unique by prepending
different RD values, 1:100:1 and 1:101, prior to propagating the addresses as VPNv4
addresses on the PE router.




BRBRAITT : June-2011                                                                32
                      ―DATA NETWORK‖ FOR JTOs PH-II


                       Figure . RD Operation in MPLS VPN
                                   [View full size image]




The protocol used for exchanging these VPNv4 routes between PE routers is
multiprotocol BGP (MP-BGP). BGP capable of carrying VPNv4 (96-bit) prefixes in
addition to other address families is called MP-BGP. The IGP requirement to
implement iBGP (internal BGP) still holds in the case of an MPLS VPN
implementation. Therefore, the PE router must run an IGP that provides NLRI
information for iBGP if both PE routers are in the same AS. Cisco currently supports
both OSPFv2 and ISIS in the MPLS provider network as the IGP. MP-BGP is also
responsible for assignment of a VPN label. Packet forwarding in an MPLS VPN
mandates that the router specified as the next hop in the incoming BGP update is the
same router that assigns the VPN label. Scalability was a primary reason for the
choice of BGP as the protocol to carry customer routing information. In addition,
BGP enables the use of VPNv4 address in an MPLS VPN router environment that
enables overlapping address ranges with multiple customers.

An MP-BGP session between PE routers in a single BGP AS is called an MP-iBGP
session and follows rules as in the implementation of iBGP with regards to BGP
attributes. If the VPN extends beyond a single AS, VPNv4 routes will be exchanged
between AS at the AS boundaries using an MP-eBGP session.

Route targets (RTs) are additional identifiers used in the MPLS VPN domain in the
deployment of MPLS VPN that identify the VPN membership of the routes learned
from that particular site. RTs are implemented by the use of extended BGP
communities in which the higher order 16 bits of the BGP extended community (64
total bits) are encoded with a value corresponding to the VPN membership of the
specific site. When a VPN route learned from a CE router is injected into VPNv4
BGP, a list of VPN route target extended community attributes is associated with it.
The export route target is used in identification of VPN membership and is associated
to each VRF. This export route target is appended to a customer prefix when it is
converted to a VPNv4 prefix by the PE router and propagated in MP-BGP updates.



BRBRAITT : June-2011                                                              33
                      ―DATA NETWORK‖ FOR JTOs PH-II


The import route target is associated with each VRF and identifies the VPNv4 routes
to be imported into the VRF for the specific customer. The format of a RT is the same
as an RD value. The interaction of RT and RD values in the MPLS VPN domain as
the update is converted to an MP-BGP update is shown in Figure .

                  Figure . RT and RD Operation in an MPLS VPN
                                   [View full size image]




When implementing complex VPN topologies, such as extranet VPN, Internet access
VPNs, network management VPN, and so on, using MPLS VPN technology, the RT
plays a pivotal role. A single prefix can be associated to more than one export route
target when propagated across the MPLS VPN network. The RT can, as a result, be
associated to sites that might be a member of more than one VPN.

The following processes occur during route propagation in an MPLS VPN, as shown
in Figure :

    The prefix 172.16.10.0/24 is received from CE1-A, which is part of VRF
    CustomerA on PE1-AS1.

    PE1 associated an RD value of 1:100 and an export RT value of 1:100 as
    configured in the VRF definition on the PE1-AS1 router.

    Routes learned from connected CE routers CE1-A are redistributed into the MP-
    BGP process on PE1-AS1 where the prefix 172.16.10.0/24 is prepended with the
    RD value of 1:100 and appended with the route target extended community value
    (export RT) of 1:100 prior to sending the VPNv4 prefix as part of the MP-iBGP
    update                   between                  PE                   routers.

    The VPN label (3 bytes) is assigned for each prefix learned from the connected
    CE router's IGP process within a VRF by the PE router's MP-BGP process. MP-


BRBRAITT : June-2011                                                              34
                        ―DATA NETWORK‖ FOR JTOs PH-II


    BGP running in the service provider MPLS domain thus carries the VPNv4 prefix
    (IPv4 prefix + prepended RD) in addition to the BGP route target extended
    community. Note that although the RT is a mandatory configuration in an MPLS
    VPN for all VRFs configured on a router, the RT values can be used to
    implement complex VPN topologies in which a single site can be a part of more
    than one VPN. In addition, RT values can also be used to perform selective route
    importing into a VRF when VPNv4 routes are learned in MP-iBGP updates. The
    VPN label is only understood by the egress PE (data plane) that is directly
    connected to the CE router advertising the prefix. Note that the next hops on PE
    routers must not be advertised in the BGP process but must be learned from the
    IGP for MPLS VPN implementation. The VPN label has been depicted by the
    entries V1 and V2 in Figure .

    The MP-BGP update is received by the PE router PE2, and the route is stored in
    the appropriate VRF table for Customer A based on the VPN label.

    The received MP-BGP routes are redistributed into the VRF PE-CE routing
    processes, and the route is propagated to CE2-A.

In addition, other BGP extended community attributes such as site of origin (SoO) can
also be applied to the MP-iBGP update prior to propagation. The SoO attribute is used
to identify the specific site from which the PE learns the route and is used in the
identification and prevention of routing loops. The SoO extended community is a
BGP extended community attribute used to identify routes that have originated from a
site so that the re-advertisement of that prefix back to the source site can be prevented,
thus preventing routing loops. The SoO extended community uniquely identifies the
site from which a PE router has learned a route. SoO enables filtering of traffic based
on the site from which it was originated. SoO filtering manages MPLS VPN traffic
and prevents routing loops from occurring in complex and mixed network topologies
in which the customer sites might possess connectivity across the MPLS VPN
backbone as well as possess backdoor links between sites.

The implementation of a MPLS VPN in which all VPN sites belonging to a customer
can speak to all other sites in the same customer domain is called a simple VPN
implementation or intranet VPN. As mentioned earlier, RTs can be used to implement
complex VPN topologies in which certain sites that are part of one customer's domain
are also accessible by other customers' VPN sites. This implementation is called an
extranet VPN. In addition, variants of extranet VPN, such as network management
VPN as well as central services VPN and Internet access VPN, can also be deployed.

It is important to understand the concept of address families and their place in the
operation of MP-BGP to enable the transport of VPNv4 routes with extended
community attributes. Prior to RFC 2283, "Multiprotocol Extensions for BGP-4,"
BGP version 4 was capable of carrying routing information only pertaining to IPv4.
RFC 2283 defines extensions to BGP-4 that enable BGP-4 to carry information for
multiple network layer protocols. RFC 2283 states that to enable BGP-4 to support
routing for multiple network layer protocols, the additions to BGP-4 must account for
the ability of a particular network layer protocol to be associated with a next hop as
well as the NLRI (network layer reachability information). The two new attributes
that were added to BGP were Multiprotocol Reachable NLRI (MP_REACH_NLRI),


BRBRAITT : June-2011                                                                   35
                       ―DATA NETWORK‖ FOR JTOs PH-II


and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI). MP_REACH_NLRI
carries the set of reachable destinations together with the next-hop information to be
used for forwarding to these destinations. MP_UNREACH_NLRI carries the set of
unreachable destinations. Both of these attributes are optional and nontransitive.
Therefore, a BGP speaker that does not support these multiprotocol capabilities will
just ignore the information carried in these attributes and will not pass it to other BGP
speakers.

An address family is a defined network layer protocol. An address family identifier
(AFI) carries an identity of the network layer protocol associated with the network
address in the multiprotocol attributes in BGP. (Address family identifiers for network
layer protocols are defined in RFC 1700, "Assigned Numbers.")

The PE router, in essence, is an Edge LSR and performs all the functions of an Edge
LSR. The PE router requires LDP for label assignment and distribution as well as
forward labeled packets. In addition to the functions of an Edge LSR, the PE
implements a routing protocol (or static routes) with connected CE routers per virtual
routing table and requires MP-BGP to propagate prefixes learned from CE routers as
VPNv4 prefixes in MP-iBGP updates to other PE routers along with the VPN label.

The P router's requirements are to run an IGP (either OSPF or ISIS) as well as have
MPLS enabled to forward labeled packets (data plane) between PE routers. The IGP
is used to provide, as well as propagate, NLRI to connected P and PE routers to
implement an MP-iBGP session between PE routers (control plane). As explained in
Chapters 1 and 2, LDP is run on the P router for label assignment and distribution.
MPLS VPN Control Plane Operation
The control plane in MPLS VPN implementation contains all the Layer 3 routing
information and the processes within to exchange reachability information for a
specific Layer 3 IP prefix in addition to label assignment and distribution using LDP
(as explained in Chapter 1). The data plane performs the functions relating to the
forwarding of both labeled as well as IP packets to the next hop toward a destination
network. Figure outlines the interactions of protocols in the control plane in an MPLS
VPN implementation.




BRBRAITT : June-2011                                                                  36
                       ―DATA NETWORK‖ FOR JTOs PH-II


                  Figure . Control Plane Interactions in MPLS VPN
                                    [View full size image]




   

The CE routers are connected to the PE routers, and an IGP, BGP, or static route is
required on the CE routers in conjunction with attached PE routers to gather and
advertise NLRI information. In the MPLS VPN backbone consisting of P and PE
routers, an IGP (usually either OSPF or ISIS) in addition to LDP is used between PE
and P routers. LDP is used for allocation as well as distribution of labels in the MPLS
domain. The IGP is used for NLRI information exchange as well as to map this NLRI
into MP-BGP. MP-BGP sessions are maintained between PE routers in an MPLS
VPN domain and exchange MP-BGP updates consisting of unique VPNv4 addresses
in addition to BGP extended community attributes associated with specific VPNv4
addresses.

Packets from CE to PE are always propagated as IPv4 packets. Operation of the
MPLS VPN control plane is shown in Figure . Figure shows a simple VPN
implementation with two sites belonging to Customer A connected to one another
across a service provider's MPLS backbone.


                         Figure 3-9. Control Plane Operation
                                    [View full size image]




BRBRAITT : June-2011                                                                37
                      ―DATA NETWORK‖ FOR JTOs PH-II


The following are the steps for control plane operation in MPLS VPN. The steps are
outlined for prefixes advertised by the CEA-1 router and are shown in Figure :

Step 1.   IPv4 update for network 172.16.10.0 is received by the egress PE router
          (data plane).

Step 2.   PE1-AS1 accepts and transforms the IPv4 route, 172.16.10.0/24, to a
          VPNv4 route by assigning an RD 1:100, SoO, and RT 1:100 based on the
          VRF configuration on PE1-AS1. It then allocates a VPNv4 label V1 to the
          172.16.10.0/24 update and rewrites the next-hop attribute to the PE1-AS1
          loopback0 IP address 10.10.10.101. PE1-AS1 loopback 10.10.10.101 is
          reachable via IGP (OSPF) and LDP. Figure shows the control plane
          operation and the label propagation for prefix 10.10.10.101/32 from PE1-
          AS1 to PE2-AS1 inside the provider network. This propagation takes place
          as soon as the MPLS VPN provider network is established and is always in
          place prior to any VPNv4 prefix being propagated across the MPLS VPN
          provider network. The following steps are performed in the label
          propagation process for prefix 10.10.10.101/32. This operation is shown
          for clarity:
                 2a: In Figure , Edge LSR PE2-AS1 requests a label for the
                  10.10.10.101/32 prefix using the LDP label mapping request from
                  its downstream neighbor, LSR P2-AS1. P2-AS1 requests a label
                  for the 10.10.10.101/32 prefix using the LDP label mapping
                  request from its downstream neighbor LSR P1-AS1. P1-AS1, in
                  turn, requests a label for the 10.10.10.101/32 prefix using the LDP
                  label mapping request from its downstream neighbor, Edge LSR
                  PE1-AS1. Edge LSR PE1-AS1 allocates a label of implicit-null
                  (penultimate hop popping) to 10.10.10.101/32, modifies the entry
                  in the LFIB corresponding to 10.10.10.101/32, and sends it to P1-
                  AS1 using an LDP reply.
                 2b: P1-AS1 uses the implicit-null label received from PE1-AS1 as
                  its outbound label value, allocates a label (L1) to prefix
                  10.10.10.101/32, and modifies the LFIB entry for 10.10.10.101/32.
                  P1-AS1 then sends this label value to P2-AS1 via an LDP reply.
                 2c: P2-AS1 uses the label (L1) received from P1-AS1 as its
                  outbound label value, allocates a label (L2) to prefix
                  10.10.10.101/32, and modifies the LFIB entry for 10.10.10.101/32.
                  P2-AS1 then sends this label value to PE2-AS1 via an LDP reply.
Step 3.   PE1-AS1 has the VRF configured to accept routes with RT 1:100 and
          therefore translates the VPNv4 update to IPv4 and inserts the route in VRF
          for Customer A. It then propagates this route to the CE2-A.




BRBRAITT : June-2011                                                              38
                       ―DATA NETWORK‖ FOR JTOs PH-II


MPLS VPN Data Plane Operation
The prior section discussed update propagation along with the label assignment and
distribution, both for MPLS packet forwarding as well as the VPN label. MPLS VPN
data plane operation involves the usage of the label stack in which the top label in the
label stack is the label assigned for the egress PE routers (data plane) next-hop
address, and the second label in the label stack is the VPN label as assigned by the
egress PE router connected to the CE router advertising the prefix. When using the
label stack in an MPLS VPN implementation, the ingress/upstream PE router thus
labels the incoming IP packet for a remote VPN destination with two labels.

The second label in the stack points toward an outgoing interface whenever the CE
router is the next hop of the VPN route. The second label in the stack points to the
VRF table for aggregate VPN routes, VPN routes pointing to null interface, and
routes for directly connected VPN interfaces. This will be explained in more detail in
the section "MPLS VPN Basic Configuration." P routers perform label switching on
the LDP-assigned label toward the egress PE router. The egress PE router identifies
the VPN label assigned with a VRF (that it has previously assigned) and either
forwards the IP packet toward the CE router or performs another IP lookup in the
VRF table to identify the next hop toward the destination.

Figure depicts the various steps in the data plane forwarding of customer data from
one customer site CE2-A to CE1-A connected using the SP's infrastructure.

                      Figure . MPLS VPN Data Plane Operation
                                    [View full size image]




When data is forwarded to a specific prefix belonging to a VPN across the MPLS-
enabled core, the top label in the label stack is the only one swapped as the packet
traverses the backbone. The VPN label is kept intact and is removed only in the
egress/downstream PE router. The resulting prefix is associated with an outgoing
interface belonging to a specific VRF on the router depending on the value in the
VPN label.




BRBRAITT : June-2011                                                                 39
                       ―DATA NETWORK‖ FOR JTOs PH-II


Here are the steps in the data plane forwarding shown in Figure :

Step 1.    CE2-A originates a data packet with the source address of 172.16.20.1 and
           destination of 172.16.10.1.

Step 2.    PE2-AS1 receives the data packet and appends the VPN label V1 and

           LDP label L2 and forwards the packet to P2-AS1.

Step 3.    P2-AS1 receives the data packet destined to 172.16.10.1 and swaps LDP
           label L2 with L1.

Step 4.    P1-AS1 receives the data packet destined to 172.16.10.1 and pops the top
           label because it receives an implicit-null label mapping for
           10.10.10.101/32 from PE1-AS1. The resulting labeled packet (with VPN
           Label V1) is forwarded to PE1-AS1.

Step 5.    PE1-AS1 pops the VPN label and forwards the data packet to CE1-A
           where the 172.16.10.0 network is located.

The key to understanding the operation of MPLS VPN is that the VPN label is never
touched until it reaches the egress PE router toward the FEC. All the forwarding of
traffic is done as explained in Chapter 1; the next-hop label mapping to the
downstream PE router's loopback is used to forward the packet (in this case, labeled
IP because of the presence of a VPN label) through the MPLS domain.
MPLS VPN Basic Configuration
This section outlines the generic configurations required on the routers in the service
provider domain to implement MPLS VPN. The configurations of the PE and P
routers will be covered in this section. The subsequent sections in this chapter delve
into each of the configuration blocks on the PE and P routers alone. The
configurations required to implement PE-CE routing sessions are discussed in
Chapters 4 through 6, depending on the PE-CE protocol in use.

All configurations outlined in the following sections are performed in the network
shown in Figure . For simplicity, only connected networks that are part of the VRF
will be redistributed into the MP-BGP processes.




BRBRAITT : June-2011                                                                40
                       ―DATA NETWORK‖ FOR JTOs PH-II


          Figure . Network Topology: MPLS VPN PE and P Configuration
                                    [View full size image]




The topology in Figure 3-11 attempts to implement a simple intranet VPN between
two sites belonging to Customer A, site 1 and site 2. The customer network consists
of the CE routers CE1-A and CE2-A. In addition, two loopbacks (loopback 1) on
PE1-AS1 and PE2-AS1 will be configured as part of the VRF CustomerA and be
redistributed into the MP-BGP routing contexts.
Configuration of CE Routers
The configuration of route exchange between PE and CE routers involves the
implementation of a routing protocol (or static/default routes) on the CE routers. No
specific configuration other than the regular routing protocol configuration is required
on the CE routers. On the PE router, VRF routing contexts (or address family
contexts) are required for route exchange between the PE and CE. These routes are
then mutually redistributed with the MP-BGP process per VRF. Configurations for
the above based on protocol choice between PE and CE will be covered in Chapters 4
through 6.
Configuring MPLS Forwarding and VRF Definition on PE Routers
Configuring MPLS forwarding is the first step to provision the service provider's
MPLS VPN backbone. This step ensures the service provider's readiness to provide
MPLS-related services to prospective customers. At a minimum, the steps to
configure MPLS forwarding on PE routers are




BRBRAITT : June-2011                                                                 41
                      ―DATA NETWORK‖ FOR JTOs PH-II




Step 1.   Enable CEF.

Step 2.   Configure IGP routing protocol on the PE router.

Step 3.   Configure MPLS or label forwarding on the PE interfaces connected to P.

These steps have already been discussed in Chapters 1 and 2 and thus have not been
shown.

In this section, we configure VRFs on the PE routers. Figure 3-12 shows the
configuration steps on the PE routers to configure VRF definition.

          Figure 3-12. VRF Definition on PE Routers: Configuration Steps
                                  [View full size image]




Step 1.   Configure VRF on PE router—Configure the VRF CustomerA on PE1
          and PE2-AS1 router. This results in the creation of a VRF routing table
          and a Cisco Express Forwarding (CEF) table for CustomerA. Example 3-
          1 shows CustomerA VRF being configured on PE1-AS1 router. Note the
          VRF name is case sensitive.
          Example 3-1. VRF Definition
          PE1-AS1(config)#ip                       vrf                    CustomerA
          Note that creation or deletion of a VRF results in removal of the IP address
          from the interface. Example 3-2 illustrates the message that occurs on VRF
          deletion.
          Example 3-2. VRF Deletion
          PE1-AS1(config-vrf)#no ip vrf CustomerA


BRBRAITT : June-2011                                                               42
                      ―DATA NETWORK‖ FOR JTOs PH-II



          % IP addresses from all interfaces in VRF CustomerA have been removed


Step 2.   Configure the RD—The RD creates routing and forwarding tables. The
          RD is added to the beginning of the customer's IPv4 prefixes to convert
          them into globally unique VPNv4 prefixes. Example 3-3 shows the
          configuration for defining the RD under the VRF.
          Example 3-3. Configuring VRF Parameters: RD
          PE1-AS1(config-vrf)#rd 1:100

          The RD can be used in either of these formats:
                 - 16-bit AS number: Your 32-bit number (for example, 1:100)
                 - 32-bit IP address: Your 16-bit number (for example,
                  10.10.10.101:1)
          RD for an existing VRF can be changed only after deletion of that VRF.
          Example 3-4 illustrates the concept.
          Example 3-4. Redefining VRF RD Value
          PE1-AS1(config)#ip vrf CustomerA

          PE1-AS1(config-vrf)#rd 1:100

          % Do "no ip vrf " before redefining the VRF

          RD has to be unique for that particular VRF. No two VRFs on the same
          router can have similar RD. Trying to set the same RD on the VRF on the
          same router results in the message shown in Example 3-5.
          Example 3-5. RD Uniqueness
          PE1-AS1(config)#ip vrf CustomerA
          PE1-AS1(config-vrf)#rd 1:100
          % Cannot set RD, check if it's unique

Step 3.   Configure the import and export policy—Configure the import and
          export policy for the MP-BGP extended communities. The policy is used
          for filtering routes for that particular RT. Example 3-6 provides the
          relevant configuration for defining import and export policy.
          Example 3-6. Configuring VRF Parameters: RT
          PE1-AS1(config-vrf)#route-target both 1:100

          The both keyword in the previous command results in the configuration of
          import and export policy, and the configuration output is shown in
          Example 3-7.
          Example 3-7. RT Configuration Options
          PE1-AS1#sh run


BRBRAITT : June-2011                                                           43
                       ―DATA NETWORK‖ FOR JTOs PH-II



           Building configuration...

           ip vrf CustomerA

           rd 1:100

           route-target export 1:100

           route-target import 1:100

Step 4.    Associate VRF with the interface—Associate virtual routing/forwarding
           instance (VRF) with an interface or subinterface in this CustomerA.
           Associating the VRF to an interface results in removal of the IP address
           from that interface. This is only if VRF was associated to an interface that
           had the IP address already configured. This means that the IP address will
           have to be reconfigured after the VRF is associated with that interface.
           Example 3-8 shows the configuration for associating the VRF to an
           interface. Example 3-9 shows the removal of the IP address when no ip
           vrf forwarding vrfname is configured on the interface.
           Example 3-8. Associating VRF with Interface
           PE1-AS1(config)#interface serial4/0

           PE1-AS1(config-if)#ip add 172.16.1.1 255.255.255.252

           PE1-AS1(config-if)# ip vrf forwarding CustomerA

           % Interface Serial4/0 IP address 172.16.1.1 removed due to enabling VRF
           CustomerA

           PE1-AS1(config-if)#ip add 172.16.1.1 255.255.255.252
           Example 3-9. VRF Association to Interface IP Address
           PE1-AS1(config-if)#no ip vrf forwarding CustomerA

           % Interface Serial4/0 IP address 172.16.1.1 removed due to disabling VRF
           CustomerA
Final VRF Configuration on PE1-AS1 Router
Example 3-10 shows the VRF configuration on the PE1-AS1 router.

Example 3-10. VRF Configuration of PE1-AS1

ip vrf CustomerA



rd 1:100

route-target export 1:100



BRBRAITT : June-2011                                                                44
                       ―DATA NETWORK‖ FOR JTOs PH-II


route-target import 1:100

interface Serial1/0

description PE-CE link to CE1-A

ip vrf forwarding CustomerA

ip address 172.16.1.1 255.255.255.0

Interface Loopback1

ip vrf forwarding CustomerA

ip address 172.16.100.1 255.255.255.255
Verification of VRF Configuration on PE Routers
The show ip vrf command is used to verify if the correct VRF exists on the interface.
Example 3-11 indicates that the correct VRF CustomerA is configured on the
Serial1/0 interface on the PE1 router.
Example 3-11. show ip vrf on PE1-AS1
PE1-AS1#show ip vrf

Name                  Default RD          Interfaces

 CustomerA                 1:100           Se1/0

                                           Lo1

The show ip vrf interfaces command provides the listing of interfaces that are
activated for a particular VRF. Example 3-12 shows that Serial1/0 is active for VRF
VRF-Static.
Example 3-12. show ip vrf interfaces on PE1-AS1
PE1-AS1#show ip vrf interfaces

Interface     IP-Address      VRF                Protocol

Serial1/0     172.16.1.1      CustomerA            up

Lo1          172.16.100.1     CustomerA            up

Configuration of BGP PE-PE Routing on PE Routers
Configuring BGP PE-PE routing between the PE routers is the next step in an MPLS
VPN deployment. The purpose of this step is to ensure that VPNv4 routes can be
transported across the service provider backbone using MP-iBGP. The P router is
transparent to this entire process and, therefore, does not carry any customer routes.
Figure 3-13 illustrates the steps for configuring BGP PE-PE routing sessions between
the PE routers.




BRBRAITT : June-2011                                                               45
                    ―DATA NETWORK‖ FOR JTOs PH-II




             Figure 3-13. BGP PE-PE Routing Configuration Steps
                               [View full size image]




Step 1. Configure BGP routing on PE routers—Enable BGP routing and identify the AS on
        the PE1-AS1 and PE2-AS1 routers. Example 3-13 highlights the configuration.

      Example 3-13. Configuring BGP Routing on PE Routers

      PE1-AS1(config)#router bgp 1

      ________________________________________________________________

      PE2-AS1(config)#router bgp 1




BRBRAITT : June-2011                                                     46
                      ―DATA NETWORK‖ FOR JTOs PH-II


Step 2. Configure the MP-iBGP neighbors—Configure the remote MP-iBGP neighbor and use
        the loopback interface as the source of BGP messages and updates. Note that you have to
        use the update-source command only when the neighbor is peering to your loopback
        address. This is irrespective of whether it is an iBGP or eBGP neighbor. Example 3-14
        shows the configuration for the PE1-AS1 and PE2-AS1 router.

       Example 3-14. Configuring MP-iBGP Neighbors

       PE1-AS1(config-router)#neighbor 10.10.10.102 remote-as 1

       PE1-AS1(config-router)#neighbor 10.10.10.102 update-source loopback0

       ____________________________________________________________

       PE2-AS1(config-router)#neighbor 10.10.10.101 remote-as 1



       PE2-AS1(config-router)#neighbor 10.10.10.101 update-source loopback0



Step 3. Configure the VPNv4 address family—Configure the address family for VPNv4 under
        the BGP configuration process. This step allows you to enter the VPNv4 address family
        to activate the VPNv4 neighbors. Activate the iBGP neighbor, which is essential for
        transporting VPNv4 prefixes across the service provider backbone. Using next-hop-self is
        optional and is primarily used when the service provider has an eBGP PE-CE routing
        with the customers, because internal BGP (iBGP) sessions preserve the next-hop attribute
        learned from eBGP peers, which is why it is important to have an internal route to the
        next hop. Otherwise, the BGP route is unreachable. To make sure you can reach the
        eBGP next hop, include the network that the next hop belongs to in the IGP or use the
        next-hop-self neighbor command to force the router to advertise itself, rather than the
        external            peer,             as            the            next             hop.

       In addition, configure the propagation of the extended communities with BGP routes so
       as to enable RT propagation, which identifies the VPNs that the routes have to be
       imported into. The configuration of the VPNv4 address family for PE1-AS1 and PE2-
       AS1 is shown in Example 3-15. Note that on some versions of IOS, adding the neighbor
       for VPNv4 route exchange using the neighbor ip-address activate command also
       automatically adds the neighbor ip-address send-community extended command. If the
       neighbor needs to be configured for both standard and extended community exchange,
       you will explicitly have to configure the neighbor ip-address send-community both
       command under the VPNv4 address family.

       Example 3-15. Configuring BGP VPNv4 Address Family

       PE1-AS1(config-router)#address-family vpnv4




BRBRAITT : June-2011                                                              47
                      ―DATA NETWORK‖ FOR JTOs PH-II


       PE1-AS1(config-router-af)# neighbor 10.10.10.102 activate

       PE1-AS1(config-router-af)# neighbor 10.10.10.102 send-community extended

       ________________________________________________________________________

       PE2-AS1(config-router)#address-family vpnv4

       PE2-AS1(config-router-af)# neighbor 10.10.10.101 activate

       PE2-AS1(config-router-af)# neighbor 10.10.10.101 send-community extended

Step 4. Configure the IPv4 address family—Configure the peer VRF IPv4 address family
        under the BGP configuration process. This step allows you to enter the IPv4 networks
        that will be converted to VPNv4 routes in MP-BGP updates. In Chapters 4, 5, and 6, the
        individual PE-CE routing protocol interaction configuration involving redistribution of
        PE-CE routing protocol contexts or instances will be configured in the IPv4 address
        family per VRF under the BGP process. For simplicity, redistribution of all connected
        networks is configured into the MP-BGP process. Example 3-16 shows the configuration
        on PE1-AS1 and PE2-AS1 routers.

       Example 3-16. Configuring BGP per VRF IPv4 Address Family (Routing Context)

       PE1-AS1(config-router)#address-family ipv4 vrf CustomerA

       PE1-AS1(config-router-af)# redistribute connected

       PE1-AS1(config-router-af)# exit-address-family

       _________________________________________________________

       PE2-AS1(config-router)#address-family ipv4 vrf CustomerA

       PE2-AS1(config-router-af)# redistribute connected

       PE2-AS1(config-router-af)# exit-address-family
BGP PE-PE Routing Final Configuration on PE1-AS1 and PE2-AS1 Router
Example 3-17 shows the final BGP PE-PE routing configuration on the PE1-AS1 and
PE2-AS1 router.
Example 3-17. BGP PE-PE Configurations of PE1-AS1 and PE2-AS1 Routers
!PE1-AS1 Router:


router bgp 1

no synchronization

neighbor 10.10.10.102 remote-as 1

no auto-summary



BRBRAITT : June-2011                                                             48
                         ―DATA NETWORK‖ FOR JTOs PH-II



address-family vpnv4

neighbor 10.10.10.102 activate

neighbor 10.10.10.102 send-community extended

exit-address-family

address-family ipv4 vrf CustomerA

redistribute connected

no auto-summary

no synchronization

exit-address-family
_____________________________________________________________________

!PE2-AS1 Router:


router bgp 1

no synchronization

bgp log-neighbor-changes

neighbor 10.10.10.101 remote-as 1

neighbor 10.10.10.101 update-source Loopback0

no auto-summary

 address-family vpnv4

neighbor 10.10.10.101 activate

neighbor 10.10.10.101 send-community extended

exit-address-family

address-family ipv4 vrf CustomerA

redistribute connected

no auto-summary

no synchronization

exit-address-family




BRBRAITT : June-2011                                                    49
                          ―DATA NETWORK‖ FOR JTOs PH-II


Verification and Monitoring of BGP PE-PE Routing on PE Routers
After configuring BGP PE-PE routing between the PE routers, you can verify that the
MP-iBGP neighbors are operational by issuing any of the following commands:
      show ip bgp vpnv4 * summary
      show IP bgp vpnv4 all
      show ip bgp summary
      show ip bgp neighbor ip-address
Example 3-18 shows that the VPNv4 neighbor relationship is formed.

Example 3-18. VPN Neighbor Relationship Verification

PE1#show ip bgp vpnv4 all summary


BGP router identifier 10.10.10.101, local AS number 1

BGP table version is 7, main routing table version 7

Neighbor              V    AS MsgRcvd MsgSent          TblVer       InQ OutQ Up/Down
State/PfxRcd

10.10.10.102    4     1   202   200     7    0    0 00:00:39     0
_____________________________________________________________________


PE2#show ip bgp vpnv4 all summary

BGP router identifier 10.10.10.102, local AS number 1

BGP table version is 1, main routing table version 1

Neighbor              V    AS MsgRcvd MsgSent          TblVer       InQ OutQ Up/Down
State/PfxRcd

10.10.10.101    4     1   11    11    1     0    0 00:07:16     0

Configuration of P Router
No special configurations need to be performed on the P routers P1-AS1 and P1-AS2
for MPLS VPN support. Because the P routers only participate in MPLS labeled
packet forwarding, the only requirements are those of an LSR in an MPLS network,
namely, IGP for NLRI exchange and LDP for label assignment and distribution. As
always, CEF needs to be enabled on all interfaces configured for MPLS forwarding.
Configuration of the P1-AS1 router is shown in Example 3-19.

Example 3-19. P1-AS1 Configuration

mpls ldp router-id loopback0



interface Serial0/0


BRBRAITT : June-2011                                                              50
                       ―DATA NETWORK‖ FOR JTOs PH-II




 ip address 10.10.10.2 255.255.255.252

mpls ip

interface Serial1/0

 ip address 10.10.10.5 255.255.255.252

mpls ip

Interface loopback0

ip address 10.10.10.200 255.255.255.255

router ospf 1

network 10.0.0.0 0.255.255.255 area 0

Label Verification and Control and Data Plane Operation
After configuring devices in the network as per the previous steps, the verification of
label allocation and propagation can be performed on the PE and P routers using the
commands described in Figure 3-14.

    Figure 3-14. Label Allocation Verification and Control/Data Plane Operation
                                    [View full size image]




The control plane and data plane operation for network 172.16.100.1 as part of VRF
CustomerA is depicted in Figure 3-14. Note that the outgoing label mapped to prefix
172.16.100.1 on PE1-AS1 is aggregate and not untagged. For all networks that are


BRBRAITT : June-2011                                                                51
                       ―DATA NETWORK‖ FOR JTOs PH-II


directly connected to the PE router (like loopbacks or interface IP networks) that are
part of a VRF, the outgoing label mapped in the LFIB is the aggregate label. If,
however, the incoming VPN packet is to be forwarded to a next-hop address (like that
of a connected CE router), the outgoing label mapping is untagged. Thus, aggregate
and untagged labels that were explained in Chapter 1 are encountered in MPLS VPN
implementations.
Outbound Route Filters
When implementing large-scale MPLS VPN networks, sites belonging to different
customers might not be connected to all the PE routers in the MPLS VPN domain.
The PE router in the MPLS VPN network can, therefore, conserve resources by
importing only VPNv4 routes that are to be imported into VRF instances configured
on the PE router. To enable such filtering of VPNv4 route information, the PE router
must be capable of filtering MP-iBGP updates so that information pertaining to these
superfluous routes is not received. The procedure for filtering routes based on the
VRF configuration on the PE routers is called automatic route filtering. Automatic
route filtering is enabled by default on all Cisco routers that are configured as PE
routers. The exception is in the case of a PE router also performing the functions of a
route-reflector. The route-reflector must be capable of receiving routes that might not
be associated to any locally configured VRFs and reflect them to clients. Therefore,
on a PE router functioning as a route-reflector, the automatic route filtering process is
disabled to enable propagation of VPNv4 routes between route-reflector clients.

Automatic route filtering enables the PE router to reduce resource consumption by
rejecting information not pertaining to the VRFs configured on the router. Automatic
route filtering, however, does not avoid the superfluous routes from being received by
the PE routers.

Outbound route filtering (ORF) enables a PE router to advertise to its peers, outbound
route filters that peering PE routers can use while sending information to a PE router.
The ORF feature on PE routers works in conjunction with the route-refresh BGP
capability. The route-refresh BGP capability enables the PE router to request routing
updates from its MP-iBGP peers after undergoing a configuration change. In the event
of an addition, deletion, or modification of VRFs or their associated configurations on
a PE router, the route-refresh capability enables the PE router to update its routing
tables. The route-refresh feature is enabled by default on all Cisco routers configured
for PE functionality. The ORF entries are exchanged during session establishment
between two PE routers through the use of the BGP OPEN message as part of the
route-refresh message. The format of a route-refresh message is shown in Figure 3-15.




BRBRAITT : June-2011                                                                  52
                       ―DATA NETWORK‖ FOR JTOs PH-II


             Figure 3-15. Route-Refresh Message and Working of ORF




In large networks, the PE router might receive updates and then filter a list of
unwanted routes based on its local inbound route filter. The ORF feature enables a PE
router to push its inbound route filter to a remote peer and apply a filter from a remote
peer as its outbound route filter. ORFs can be either prefix-based or extended-
community based in VPNv4 route filtering. The prefix-based ORF allows a PE to
export and/or receive the inbound route filter information with a peer based on the
prefix associated with the route. In the extended-community based ORF, the PE can
export/receive inbound route filter based on the extended community attributes
associated with a VPNv4 route. Because the RT values are coded as part of the
extended-community attributes in VPNv4 routes, the ORF feature can be used to
advertise a subset of RTs for which the PE router can receive VPNv4 routing
information. This process essentially reduces the burden of superfluous routing
information being propagated in the MP-iBGP backbone as the peering PE router
does not send VPNv4 routes pertaining to the subset of RTs configured as part of the
ORF.

Figure 3-16 shows the operation and sample configuration for implementation of a
prefix-based ORF. PE1-AS1 is configured with an inbound prefix-list that is
propagated using the ORF capability configuration to PE2-AS1. PE2-AS1 will not
accept this filter if the command neighbor 10.10.10.1 capability orf prefix-list
receive is configured under the VPNv4 address-family. The verification of the ORF
application on PE2-AS1 is also illustrated in Figure 3-16 with the output of the show
ip bgp neighbor command. The output of this command depicts the ORF has been
received with two entries. Note that because this ORF applies only to VPNv4 routes
learned from PE2-AS1, this will not affect regular IPv4 route exchanges between
PE1-AS1 and PE2-AS1.




BRBRAITT : June-2011                                                                  53
                  ―DATA NETWORK‖ FOR JTOs PH-II


               Figure 3-16. ORF Operation and Configuration
                              [View full size image]




BRBRAITT : June-2011                                          54
                      ―DATA NETWORK‖ FOR JTOs PH-II


Command Reference
Command                                         Description

Router(config)#router bgp as-number             Configures the BGP routing
                                                process.

Router(config-router)#neighbor {ip-address |    Specifies a remote BGP neighbor
peer-group-name} remote-as as-number            to establish a BGP session.

Router(config-router)#neighbor {ip-address |  Allows the BGP sessions to use any
ipv6-address | peer-group-name} update-source operational interface for TCP
interface-type interface-number               connections. The loopback
                                              interface is used frequently.

Router(config-router)#address-family vpnv4      Places the router in address family
[unicast]                                       configuration mode, from which
                                                you can configure routing sessions
                                                that use VPN Version 4 address
                                                prefixes.

Router(config-router-af)#neighbor {ip-address | Enables the exchange of
peer-group-name | ipv6-address} activate        information with a BGP
                                                neighboring router.

Router(config)#neighbor {ip-address | peer-     Configures the router as the next
group-name} next-hop-self                       hop for a BGP-speaking neighbor
                                                or peer group.

Router#show ip bgp neighbors [neighbor-          Displays information about the
address] [received-routes | routes | advertised- TCP and BGP connections to
routes | {paths regexp} | dampened-routes |      neighbors.
received prefix-filter]

Router#show ip bgp summary                      Displays the status of all BGP
                                                connections.

Router(config)#ip vrf vrf-name                  Configures a VPN
                                                routing/forwarding instance (VRF)
                                                routing table.

Router(config-vrf)#rd route-distinguisher       Creates routing and forwarding
                                                tables for a VPN VRF.

Router(config-vrf)#route-target {import |       Creates a route target extended
export | both} route-target-ext-community       community for a VPN VRF. route-
                                                target-ext-community adds the



BRBRAITT : June-2011                                                              55
                        ―DATA NETWORK‖ FOR JTOs PH-II


Command                                              Description

                                                     route target extended community
                                                     attributes to the VRF's list of
                                                     import, export, or both (import and
                                                     export) route target extended
                                                     communities.

Router(config-if)#ip vrf forwarding vrf-name         Associates a VRF with an interface
                                                     or subinterface.

Router#show ip vrf [brief | detail | interfaces |    Displays the set of defined VPN
id] [vrf-name] [output-modifiers]                    VRFs and associated interfaces.

Router(config-router-af)#neighbor ip-address         Enables the ORF capability to be
capability orf prefix-list [receive | send | both]   sent as part of BGP open message
or                                                   and route-refresh messages to
Router(config-router)# neighbor ip-address           configured neighbors.
capability orf prefix-list [receive | send | both]

Router(config-router-af)# neighbor ip-address        Associates a prefix list to a
prefix-list prefix-list-name [in | out]              configured BGP neighbor.
or
Router(config-router)# neighbor ip-address
prefix-list prefix-list-name [in | out]

Router(config)# ip prefix-list list-name [seq        Creates a prefix list with
seq-value] {deny network/length | permit             configured entries in which len <
network/length}[ge ge-value] [le le-value]           ge-value < le-value <= 32.

Router#show ip bgp vpnv4 {all | rd route-            Displays VPN address information
distinguisher | vrf vrf-name} [rib-failure] [ip-     from the BGP table.
prefix/length [longer-prefixes] [output-
modifiers]] [network-address [mask] [longer-
prefixes] [output-modifiers]] [cidr-only]
[community] [community-list] [dampened-
paths] [filter-list] [flap-statistics]
[inconsistent-as] [neighbors] [paths [line]]
[peer-group] [quote-regexp] [regexp]
[summary] [labels]


Quality of Service Deficiencies in IP Networks
In order to have guaranteed QoS in a network, all of the data packets sent in each
direction, during each session, must follow the same path (in network jargon,
beconnection oriented) and some means for reserving resources along that path
mustexist. IP is not connection oriented, and IP routers don't generally have


BRBRAITT : June-2011                                                                     56
                        ―DATA NETWORK‖ FOR JTOs PH-II


sophisticated mechanisms for committing resources at each hop; that's why ensuring
a specified QoS is so difficult over an IP network. Two mechanisms have attempting
to solve this problem unsuccessfully.

The Differentiated Services (DiffServ) protocol was defined to enable different levels
of services to be provided across IP networks, Their protocol uses a space in the IP
header to indicate different traffic types and priorities. Routers in the network are able
to look at this information and prioritize traffic accordingly while DiffServ provides
no guarantees. For example, congestion and queuing can increase latency, reduce
available bandwidth, and thereby reduce voice quality. By itself, DiffServ is not
adequate for VoIP.

The Resource Reservation Protocol (RSVP) is a signaling protocol used in IP
networks to reserve resources for certain specified data flows. Although RSVP can
reserve theresources, it cannot guarantee that traffic will flow along the path on which
the resource was reserved: as nodes and links are added or removed in an IP network,
the path along which data flows can change. RSVP attempts to recover and create an
updated path reflecting the new technology, but there can be no guarantee that the
QoS will be maintained, and it is possible that RSVP will fail to create an updated
path.
Working towards QoS
Transport services are concerned with the transfer of user and control-plane data
across networks. The services are provided by wireline or wireless access networks. A
major problem at the transport layer is how to ensure reliable, predictable QoS for
timesensitive applications across an IP infrastructure originally designed for best-
effort data transport. Today the problem is generally solved, by running IP-over-
ATM, and using the built-in ATM QoS mechanisms. The limitations of this approach
are obvious for carriers that do not intend to implement ATM.

The alternative has been to over-provision the IP network so that in the absence of
congestion, traffic can be forwarded through the network with minimum latency, jitter
and packet loss. Throwing bandwidth at the problem is certainly not a sustainable
solution fora large-scale network. To deliver IP QoS, embryonic stage intelligence
service layers schemes such as MPLS are in development. With MPLS, service
providers can define specific packet delivery paths for traffic through the IP networks,
rather than allow intermediate routers to make the packet-forwarding decisions.
Conventional packet routing sends traffic along the shortest available path through the
network. By moving traffic flows onto less congested paths, MPLS can better balance
a networks traffic load and overall network response time and throughput.




BRBRAITT : June-2011                                                                   57
                       ―DATA NETWORK‖ FOR JTOs PH-II



Multi-Protocol Label Switching (MPLS) solves the QoS issue by setting up explicit
paths through the network. MPLS is a technique that facilitates high-performance
transport of IP traffic across Wide Area Networks. In particular, it marries
connectionless IP technology to connection-oriented technologies like ATM. MPLS
assigns labels to IP flows placing them in IP frames. The frames can then be
transported across packet or cell-based networks and switched on the labels rather
then being routed using IP address lookup. Using MPLS techniques it is possible to
set up explicit routes for data flows that are constrained by path, resource availability
and requested Quality of Service.

The path is defined by the sequence of IP addresses of the nodes to be traversed. All
of the data that constitutes a flow is given the same label (fixed format data field
inserted at the front of each packet) on entry into the MLPS network. At each node
the packet is routed based on the label value and incoming interface and sent on its
way with a new label value on the outgoing interface. The paths are referred to as
label-switched paths (LSP). Since an LSP is a well-defined path through an IP
network, it provides a means for ensuring a specified quality of service where QoS is
provided by the underlying infrastructure. The multi-protocol nature of MPLS means
it can be used to support IP networks over any Layer 2 infrastructure – Asynchronous
Transfer mode (ATM), packetover-SONET, Gigabit Ethernet, frame relay, etc.

The Constraint-based Routing Label Distribution protocol (CR-LDP) has been co
developed from the ground up by ITEF specifically for MPLS networks. Companies
are just beginning to provide MPLS devices based on the new technology. Labels-
RSVP and CR-LDP both have strong advocates. However, the market is initially
focused on RSVP, although it is likely that CR-LDP implementations will become
available.




BRBRAITT : June-2011                                                                  58
                      ―DATA NETWORK‖ FOR JTOs PH-II


MPLS-VPN Lab

1. Click Start, Run

2. Type ‗‘cmd‘‘ in the command window and press ok to get C:\> (Command
Prompt)

3. Enter the telnet command as shown in the following table against your Router.
Eg. to access PE-3 Router:
C:\> telnet 210.212.90.11 2007
PE-3>

4. Enter the enable command and the enable password as shown in the following
table
PE-3>enable
Password:xxxxx
PE-3#

     Old        New           Telnet command from C:\>         Telnet       Enable
hostname of hostname of                prompt                 password     password
 the Router  the Router
    P-1        Kolkata-PE   telnet 210.212.90.11 2001           alttc        alttc
    P-2         Pune-PE     telnet 210.212.90.11 2002           alttc        alttc
    P-3        Hyderabad    telnet 210.212.90.11 2003           alttc        alttc
    P-4         Bangalore   telnet 210.212.90.11 2004           alttc        alttc
   PE-1         Guwahati    telnet 210.212.90.11 2005           alttc        alttc
   PE-2        Ahmedabad telnet 210.212.90.11 2006              alttc        alttc
   PE-3        Chennai-PE telnet 210.212.90.11 2007             alttc        alttc
   PE-4        Trivandrum   telnet 210.212.90.11 2008           alttc        alttc
  Core-1         Delhi-P    telnet 210.212.90.11 2009           alttc        alttc
  Core-2       Mumbai-P     telnet 210.212.90.11 2010           alttc        alttc




BRBRAITT : June-2011                                                                 59
                       ―DATA NETWORK‖ FOR JTOs PH-II


MPLS-VPN Lab Module: 1
(Preliminery Configuration for MPLS)

Kolkata-PE (Old hostname: P-1) Preliminary configuration

User Access Verification

Password:xxxxx

P-1>en

Password:xxxxx

P-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

P-1(config)#hostname Kolkata-PE

Kolkata-PE(config)#interface GigabitEthernet2/2

Kolkata-PE(config-if)# ip address 172.16.16.46 255.255.255.252

Kolkata-PE(config-if)#no shut

Kolkata-PE(config-if)#end

Kolkata-PE#write memory

Building configuration...

[OK]

Kolkata-PE#

PUNE-PE (Old hostname: P-2) Preliminary configuration

User Access Verification

Password:xxxxx

P-1>en

Password:xxxxx

P-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

P-1(config)#hostname PUNE-PE

PUNE-PE(config)#interface GigabitEthernet2/2



BRBRAITT : June-2011                                             60
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config-if)# ip address 172.16.16.50 255.255.255.252

PUNE-PE(config-if)#no shut

PUNE-PE(config-if)#end

PUNE-PE#write memory

Building configuration...

[OK]

PUNE-PE#
YDERABAD (Old hostname: P-3) Preliminary configuration
User Access Verification

Password:xxxxx

P-2>en

Password:xxxxx

P-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

P-2(config)#hostname HYDERABAD

HYDERABAD(config)#interface GigabitEthernet2/2

HYDERABAD(config-if)# no shutdown

HYDERABAD(config-if)#ip add 172.16.16.33 255.255.255.252

HYDERABAD(config-if)#end

HYDERABAD#write memory

Building configuration...

[OK]

HYDERABAD#

BANGALORE (Old hostname: P-4) Preliminary configuration
User Access Verification

Password:xxxxx

P-2>en

Password:xxxxx


BRBRAITT : June-2011                                           61
                           ―DATA NETWORK‖ FOR JTOs PH-II


P-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

P-2(config)#hostname BANGALORE

BANGALORE(config)#interface GigabitEthernet2/2

BANGALORE(config-if)#no shutdown

BANGALORE(config-if)#ip add 172.16.16.37 255.255.255.252

BANGALORE(config-if)#end

BANGALORE#write memory

Building configuration...

[OK]

BANGALORE#
GUWAHATI (Old hostname: PE-1) Preliminary configuration
User Access Verification

Password:xxxxx

PE-1>en

Password:xxxxx

PE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE-1(config)#hostname GUWAHATI

GUWAHATI(config)#interface GigabitEthernet3/1

GUWAHATI(config-if)#no shutdown

GUWAHATI(config-if)#ip add 172.16.16.54 255.255.255.252

GUWAHATI(config-if)#interface GigabitEthernet2/2

GUWAHATI(config-if)# description ** P-3-PE-1 GigE link **

GUWAHATI(config-if)# ip address 172.16.16.34 255.255.255.252

GUWAHATI(config-if)# no shutdown

GUWAHATI(config-if)# end

GUWAHATI#write memory


BRBRAITT : June-2011                                           62
                       ―DATA NETWORK‖ FOR JTOs PH-II


Building configuration...

[OK]

GUWAHATI#
AHMEDABAD (Old hostname: PE-2) Preliminary configuration
User Access Verification

Password:xxxxx

PE-1>en

Password:xxxxx

PE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE-1(config)#hostname AHMEDABAD

AHMEDABAD(config)#interface GigabitEthernet3/1

AHMEDABAD(config-if)#no shutdown

AHMEDABAD(config-if)#ip add 172.16.16.58 255.255.255.252

AHMEDABAD(config-if)#interface GigabitEthernet2/2

AHMEDABAD(config-if)# description ** P-3-PE-1 GigE link **

AHMEDABAD(config-if)# ip address 172.16.16.38 255.255.255.252

AHMEDABAD(config-if)# no shutdown

AHMEDABAD(config-if)# end

AHMEDABAD#write memory

Building configuration...

[OK]

AHMEDABAD#




BRBRAITT : June-2011                                            63
                       ―DATA NETWORK‖ FOR JTOs PH-II



CHENNAI (Old hostname: PE-3) Preliminary configuration

User Access Verification

Password:xxxxx

PE-2>en

Password:xxxxx

PE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE-2(config)#hostname CHENNAI

CHENNAI(config)#controller e1 4/0/0

CHENNAI(config- controller)#channel group 0 time-slot 1-31

CHENNAI(config- controller)#exit

CHENNAI(config)#interface serial 4/0/0:0

CHENNAI(config-if)# no shutdown

CHENNAI(config-if)# ip add 172.16.16.65 255.255.255.252

CHENNAI#write memory

Building configuration...

[OK]

CHENNAI#

TRIVANDRUM (Old hostname: PE-4) Preliminary configuration

User Access Verification

Password:xxxxx

PE-2>en

Password:xxxxx

PE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

PE-2(config)#hostname TRIVANDRUM


BRBRAITT : June-2011                                           64
                       ―DATA NETWORK‖ FOR JTOs PH-II


TRIVANDRUM(config)#controller e1 4/0/0

TRIVANDRUM(config- controller)#channel group 0 time-slot 1-31

TRIVANDRUM(config- controller)#exit

TRIVANDRUM(config)#interface serial 4/0/0:0

TRIVANDRUM(config-if)# no shutdown

TRIVANDRUM(config-if)# ip add 172.16.16.66 255.255.255.252

TRIVANDRUM#write memory

Building configuration...

[OK]

TRIVANDRUM#

DELHI-P Preliminary configuration

User Access Verification

Password:xxxxx

P-3>en

Password:xxxxx

P-3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

P-3(config)# hostname DELHI-P

DELHI-P(config)# interface GigabitEthernet 7/0/0

DELHI-P(config-if)# ip address 172.16.16.41 255.255.255.252

DELHI-P(config-if)# no shutdown

DELHI-P(config-if)# interface GigabitEthernet 7/0/1

DELHI-P(config-if)# ip address 172.16.16.45 255.255.255.252

DELHI-P(config-if)# no shutdown

DELHI-P(config-if)# interface GigabitEthernet 7/1/0

DELHI-P(config-if)# ip address 172.16.16.53 255.255.255.252

DELHI-P(config-if)# no shutdown


BRBRAITT : June-2011                                            65
                       ―DATA NETWORK‖ FOR JTOs PH-II


DELHI-P(config-if)# interface GigabitEthernet 7/1/1

DELHI-P(config-if)# ip address 172.16.16.61 255.255.255.252

DELHI-P(config-if)# no shutdown

DELHI-P(config-if)# interface loopback 0

DELHI-P(config-if)# ip address 192.168.8.254 255.255.255.255

DELHI-P(config-if)#end

DELHI-P#wr

Building configuration...

[OK]

DELHI-P#

MUMBAI-P Preliminary configuration

User Access Verification

Password:xxxxx

P-3>en

Password:xxxxx

P-3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

P-3(config)# hostname MUMBAI-P

MUMBAI-P(config)# interface GigabitEthernet 7/0/0

MUMBAI-P(config-if)# ip address 172.16.16.42 255.255.255.252

MUMBAI-P(config-if)# no shutdown

MUMBAI-P(config-if)# interface GigabitEthernet 7/0/1

MUMBAI-P(config-if)# ip address 172.16.16.49 255.255.255.252

MUMBAI-P(config-if)# no shutdown

MUMBAI-P(config-if)# interface GigabitEthernet 7/1/0

MUMBAI-P(config-if)# ip address 172.16.16.58 255.255.255.252

MUMBAI-P(config-if)# no shutdown


BRBRAITT : June-2011                                           66
                       ―DATA NETWORK‖ FOR JTOs PH-II


MUMBAI-P(config-if)# interface loopback 0

MUMBAI-P(config-if)# ip address 192.168.9.254 255.255.255.255

MUMBAI-P(config-if)#end

MUMBAI-P#wr

Building configuration...

[OK]

MUMBAI-P#




BRBRAITT : June-2011                                            67
                      ―DATA NETWORK‖ FOR JTOs PH-II


MPLS-VPN Lab Module: 2
(Basic MPLS Lab using LDP)
DELHI-P

User Access Verification

Password:xxxxx

DELHI-P >en

Password:xxxxx

DELHI-P # conf t

Enter configuration commands, one per line. End with CNTL/Z.

Configuring OSPF 9829:-

DELHI-P (config)#router ospf 9829

DELHI-P (config-router)#auto-cost reference-bandwidth 1000

DELHI-P (config-router)#network 172.16.16.40 0.0.0.3 area 0

DELHI-P (config-router)#network 172.16.16.44 0.0.0.3 area 0

DELHI-P (config-router)#network 172.16.16.52 0.0.0.3 area 0

DELHI-P (config-router)#network 192.168.8.254 0.0.0.0 area 0

DELHI-P (config-router)#passive-interface loopback 0

DELHI-P (config-router)#exit

DELHI-P (config)#

Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-


DELHI-P(config)# ip cef distributed

DELHI-P(config)#mpls ip

DELHI-P(config)#mpls label protocol ldp

DELHI-P(config)# interface GigabitEthernet 7/0/0

DELHI-P(config-if)# mpls ip

DELHI-P(config-if)# mpls label protocol ldp



BRBRAITT : June-2011                                                        68
                       ―DATA NETWORK‖ FOR JTOs PH-II


DELHI-P(config-if)# interface GigabitEthernet 7/0/1

DELHI-P(config-if)# mpls ip

DELHI-P(config-if)# mpls label protocol ldp

DELHI-P(config-if)# interface GigabitEthernet 7/1/0

DELHI-P(config-if)# mpls ip

DELHI-P(config-if)# mpls label protocol ldp

DELHI-P(config-if)# interface GigabitEthernet 7/1/1

DELHI-P(config-if)# mpls ip

DELHI-P(config-if)# mpls label protocol ldp

DELHI-P(config-if)#end

DELHI-P#wr

Building configuration...

[OK]

DELHI-P#
MUMBAI-P

User Access Verification

Password:xxxxx

MUMBAI-P >en

Password:xxxxx

MUMBAI-P # conf t

Enter configuration commands, one per line. End with CNTL/Z.

Configuring OSPF 9829:-

MUMBAI-P (config)#router ospf 9829

MUMBAI-P (config-router)#auto-cost reference-bandwidth 1000

MUMBAI-P (config-router)#network 172.16.16.40 0.0.0.3 area 0

MUMBAI-P (config-router)#network 172.16.16.48 0.0.0.3 area 0

MUMBAI-P (config-router)#network 172.16.16.56 0.0.0.3 area 0


BRBRAITT : June-2011                                           69
                       ―DATA NETWORK‖ FOR JTOs PH-II


MUMBAI-P (config-router)#network 192.168.9.254 0.0.0.0 area 0

MUMBAI-P (config-router)#passive-interface loopback 0

MUMBAI-P (config-router)#exit

MUMBAI-P (config)#

Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-

MUMBAI-P(config)# ip cef distributed

MUMBAI-P(config)#mpls ip

MUMBAI-P(config)#mpls label protocol ldp

MUMBAI-P(config)# interface GigabitEthernet 7/0/0

MUMBAI-P(config-if)# mpls ip

MUMBAI-P(config-if)# mpls label protocol ldp

MUMBAI-P(config-if)# interface GigabitEthernet 7/0/1

MUMBAI-P(config-if)# mpls ip

MUMBAI-P(config-if)# mpls label protocol ldp

MUMBAI-P(config-if)# interface GigabitEthernet 7/1/0

MUMBAI-P(config-if)# mpls ip

MUMBAI-P(config-if)# mpls label protocol ldp

MUMBAI-P(config-if)# interface GigabitEthernet 7/1/1

MUMBAI-P(config-if)# mpls ip

MUMBAI-P(config-if)# mpls label protocol ldp

MUMBAI-P(config-if)#end

MUMBAI-P#wr

Building configuration...

[OK]

MUMBAI-P#

KOLKATA-PE




BRBRAITT : June-2011                                                        70
                      ―DATA NETWORK‖ FOR JTOs PH-II



User Access Verification



Password:xxxxx

KOLKATA-PE >en

Password:xxxxx

KOLKATA-PE # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-

KOLKATA-PE (config)#router ospf 9829

KOLKATA-PE (config-router)#auto-cost reference-bandwidth 1000

KOLKATA-PE (config-router)#network 172.16.16.0 0.0.0.3 area 0

KOLKATA-PE (config-router)#network 172.16.16.12 0.0.0.3 area 0

KOLKATA-PE (config-router)#network 172.16.16.16 0.0.0.3 area 0

KOLKATA-PE (config-router)#network 172.16.16.44 0.0.0.3 area 0

KOLKATA-PE (config-router)#network 192.168.0.254 0.0.0.0 area 0

KOLKATA-PE (config-router)#passive-interface loopback 0

KOLKATA-PE (config-router)#exit

KOLKATA-PE (config)#
Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-
KOLKATA-PE(config)# ip cef distributed

KOLKATA-PE(config)#mpls ip

KOLKATA-PE(config)#mpls label protocol ldp

KOLKATA-PE(config)# interface pos 3/2

KOLKATA-PE(config-if)# mpls ip

KOLKATA-PE(config-if)# mpls label protocol ldp

KOLKATA-PE(config-if)# interface pos 3/1

KOLKATA-PE(config-if)# mpls ip


BRBRAITT : June-2011                                                        71
                       ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-if)# mpls label protocol ldp

KOLKATA-PE(config-if)# interface GigabitEthernet 2/1

KOLKATA-PE(config-if)# mpls ip

KOLKATA-PE(config-if)# mpls label protocol ldp

KOLKATA-PE(config-if)# interface GigabitEthernet 2/2

KOLKATA-PE(config-if)# mpls ip

KOLKATA-PE(config-if)# mpls label protocol ldp

KOLKATA-PE(config-if)#end

KOLKATA-PE#wr

Building configuration...

[OK]

KOLKATA-PE#

PUNE-PE

User Access Verification

Password:xxxxx

PUNE-PE >en

Password:xxxxx

PUNE-PE # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-
PUNE-PE (config)#router ospf 9829

PUNE-PE (config-router)#auto-cost reference-bandwidth 1000

PUNE-PE (config-router)#network 172.16.16.0 0.0.0.3 area 0

PUNE-PE (config-router)#network 172.16.16.4 0.0.0.3 area 0

PUNE-PE (config-router)#network 172.16.16.20 0.0.0.3 area 0

PUNE-PE (config-router)#network 172.16.16.48 0.0.0.3 area 0

PUNE-PE (config-router)#network 192.168.2.254 0.0.0.0 area 0




BRBRAITT : June-2011                                           72
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE (config-router)#passive-interface loopback 0

PUNE-PE (config-router)#exit

PUNE-PE (config)#
Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-

PUNE-PE(config)# ip cef distributed

PUNE-PE(config)#mpls ip

PUNE-PE(config)#mpls label protocol ldp

PUNE-PE(config)# interface pos 3/2

PUNE-PE(config-if)# mpls ip

PUNE-PE(config-if)# mpls label protocol ldp

PUNE-PE(config-if)# interface pos 3/1

PUNE-PE(config-if)# mpls ip

PUNE-PE(config-if)# mpls label protocol ldp

PUNE-PE(config-if)# interface GigabitEthernet 2/1

PUNE-PE(config-if)# mpls ip

PUNE-PE(config-if)# mpls label protocol ldp

PUNE-PE(config-if)# interface GigabitEthernet 2/2

PUNE-PE(config-if)# mpls ip

PUNE-PE(config-if)# mpls label protocol ldp

PUNE-PE(config-if)#end

PUNE-PE#wr

Building configuration...

[OK]

PUNE-PE#
GUWAHATI
User Access Verification

Password:xxxxx

GUWAHATI >en


BRBRAITT : June-2011                                                        73
                     ―DATA NETWORK‖ FOR JTOs PH-II


Password:xxxxx

GUWAHATI # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-

GUWAHATI (config)#router ospf 9829

GUWAHATI (config-router)#auto-cost reference-bandwidth 1000

GUWAHATI (config-router)#network 172.16.16.52 0.0.0.3 area 0

GUWAHATI (config-router)#network 172.16.16.32 0.0.0.3 area 0

GUWAHATI (config-router)#network 172.16.16.16 0.0.0.3 area 0

GUWAHATI (config-router)#network 192.168.1.254 0.0.0.0 area 0

GUWAHATI (config-router)#passive-interface loopback 0

GUWAHATI (config-router)#exit

GUWAHATI (config)#
Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-
GUWAHATI(config)# ip cef distributed

GUWAHATI(config)#mpls ip

GUWAHATI(config)#mpls label protocol ldp

GUWAHATI(config)# interface gigabitEthernet 3/1

GUWAHATI(config-if)# mpls ip

GUWAHATI(config-if)# mpls label protocol ldp

GUWAHATI(config-if)# interface GigabitEthernet 2/1

GUWAHATI(config-if)# mpls ip

GUWAHATI(config-if)# mpls label protocol ldp

GUWAHATI(config-if)# interface GigabitEthernet 2/2

GUWAHATI(config-if)# mpls ip

GUWAHATI(config-if)# mpls label protocol ldp

GUWAHATI(config-if)#end

GUWAHATI#wr


BRBRAITT : June-2011                                                        74
                       ―DATA NETWORK‖ FOR JTOs PH-II


Building configuration...

[OK]

GUWAHATI#

AHMEDABAD
User Access Verification

Password:xxxxx

AHMEDABAD >en

Password:xxxxx

AHMEDABAD # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-

AHMEDABAD (config)#router ospf 9829

AHMEDABAD (config-router)#auto-cost reference-bandwidth 1000

AHMEDABAD (config-router)#network 172.16.16.56 0.0.0.3 area 0

AHMEDABAD (config-router)#network 172.16.16.36 0.0.0.3 area 0

AHMEDABAD (config-router)#network 172.16.16.20 0.0.0.3 area 0

AHMEDABAD (config-router)#network 192.168.3.254 0.0.0.0 area 0

AHMEDABAD (config-router)#passive-interface loopback 0

AHMEDABAD (config-router)#exit

AHMEDABAD (config)#
Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-

AHMEDABAD(config)# ip cef distributed

AHMEDABAD(config)#mpls ip

AHMEDABAD(config)#mpls label protocol ldp

AHMEDABAD(config)# interface gigabitEthernet 3/1

AHMEDABAD(config-if)# mpls ip

AHMEDABAD(config-if)# mpls label protocol ldp



BRBRAITT : June-2011                                                        75
                       ―DATA NETWORK‖ FOR JTOs PH-II


AHMEDABAD(config-if)# interface GigabitEthernet 2/1

AHMEDABAD(config-if)# mpls ip

AHMEDABAD(config-if)# mpls label protocol ldp

AHMEDABAD(config-if)# interface GigabitEthernet 2/2

AHMEDABAD(config-if)# mpls ip

AHMEDABAD(config-if)# mpls label protocol ldp

AHMEDABAD(config-if)#end

AHMEDABAD#wr

Building configuration...

[OK]

AHMEDABAD#

HYDERABAD

User Access Verification

Password:xxxxx

HYDERABAD >en

Password:xxxxx

HYDERABAD # conf t

Enter configuration commands, one per line. End with CNTL/Z.

Configuring OSPF 9829:-

HYDERABAD (config)#router ospf 9829

HYDERABAD (config-router)#auto-cost reference-bandwidth 1000

HYDERABAD (config-router)#network 172.16.16.8 0.0.0.3 area 0

HYDERABAD (config-router)#network 172.16.16.12 0.0.0.3 area 0

HYDERABAD (config-router)#network 172.16.16.24 0.0.0.3 area 0

HYDERABAD (config-router)#network 172.16.16.32 0.0.0.3 area 0

HYDERABAD (config-router)#network 192.168.4.254 0.0.0.0 area 0



BRBRAITT : June-2011                                             76
                           ―DATA NETWORK‖ FOR JTOs PH-II


HYDERABAD (config-router)#passive-interface loopback 0

HYDERABAD (config-router)#exit

HYDERABAD (config)#

Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-
HYDERABAD(config)# ip cef distributed

HYDERABAD(config)#mpls ip

HYDERABAD(config)#mpls label protocol ldp

HYDERABAD(config)# interface pos 3/2

HYDERABAD(config-if)# mpls ip

HYDERABAD(config-if)# mpls label protocol ldp

HYDERABAD(config-if)# interface pos 3/1

HYDERABAD(config-if)# mpls ip

HYDERABAD(config-if)# mpls label protocol ldp

HYDERABAD(config-if)# interface GigabitEthernet 2/1

HYDERABAD(config-if)# mpls ip

HYDERABAD(config-if)# mpls label protocol ldp

HYDERABAD(config-if)# interface GigabitEthernet 2/2

HYDERABAD(config-if)# mpls ip

HYDERABAD(config-if)# mpls label protocol ldp

HYDERABAD(config-if)#end

HYDERABAD#wr

Building configuration...

[OK]

HYDERABAD#

BANGALORE
User Access Verification

Password:xxxxx



BRBRAITT : June-2011                                                        77
                     ―DATA NETWORK‖ FOR JTOs PH-II


BANGALORE >en

Password:xxxxx

BANGALORE # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-
BANGALORE (config)#router ospf 9829

BANGALORE (config-router)#auto-cost reference-bandwidth 1000

BANGALORE (config-router)#network 172.16.16.4 0.0.0.3 area 0

BANGALORE (config-router)#network 172.16.16.8 0.0.0.3 area 0

BANGALORE (config-router)#network 172.16.16.28 0.0.0.3 area 0

BANGALORE (config-router)#network 172.16.16.36 0.0.0.3 area 0

BANGALORE (config-router)#network 192.168.6.254 0.0.0.0 area 0

BANGALORE (config-router)#passive-interface loopback 0

BANGALORE (config-router)#exit

BANGALORE (config)#

Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-

BANGALORE(config)# ip cef distributed

BANGALORE(config)#mpls ip

BANGALORE(config)#mpls label protocol ldp

BANGALORE(config)# interface pos 3/2

BANGALORE(config-if)# mpls ip

BANGALORE(config-if)# mpls label protocol ldp

BANGALORE(config-if)# interface pos 3/1

BANGALORE(config-if)# mpls ip

BANGALORE(config-if)# mpls label protocol ldp

BANGALORE(config-if)# interface GigabitEthernet 2/1

BANGALORE(config-if)# mpls ip



BRBRAITT : June-2011                                                        78
                       ―DATA NETWORK‖ FOR JTOs PH-II


BANGALORE(config-if)# mpls label protocol ldp

BANGALORE(config-if)# interface GigabitEthernet 2/2

BANGALORE(config-if)# mpls ip

BANGALORE(config-if)# mpls label protocol ldp

BANGALORE(config-if)#end

BANGALORE#wr

Building configuration...

[OK]

BANGALORE#
CHENNAI-PE

User Access Verification

Password:xxxxx

CHENNAI-PE >en

Password:xxxxx

CHENNAI-PE # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-

CHENNAI-PE (config)#router ospf 9829

CHENNAI-PE (config-router)#auto-cost reference-bandwidth 1000

CHENNAI-PE (config-router)#network 172.16.16.24 0.0.0.3 area 0

CHENNAI-PE (config-router)#network 172.16.16.64 0.0.0.3 area 0

CHENNAI-PE (config-router)#network 192.168.5.254 0.0.0.0 area 0

CHENNAI-PE (config-router)#passive-interface loopback 0

CHENNAI-PE (config-router)#exit

CHENNAI-PE (config)#

Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-

CHENNAI-PE(config)# ip cef distributed


BRBRAITT : June-2011                                                        79
                       ―DATA NETWORK‖ FOR JTOs PH-II


CHENNAI-PE(config)#mpls ip

CHENNAI-PE(config)#mpls label protocol ldp

CHENNAI-PE(config)# interface GigabitEthernet 2/1

CHENNAI-PE(config-if)# mpls ip

CHENNAI-PE(config-if)# mpls label protocol ldp

CHENNAI-PE(config-if)# interface serial 4/0/0:0

CHENNAI-PE(config-if)# mpls ip

CHENNAI-PE(config-if)# mpls label protocol ldp

CHENNAI-PE(config-if)#end

CHENNAI-PE#wr

Building configuration...

[OK]

CHENNAI-PE#

TRIVANDRUM

User Access Verification

Password:xxxxx

TRIVANDRUM >en

Password:xxxxx

TRIVANDRUM # conf t

Enter configuration commands, one per line. End with CNTL/Z.
Configuring OSPF 9829:-
TRIVANDRUM (config)#router ospf 9829

TRIVANDRUM (config-router)#auto-cost reference-bandwidth 1000

TRIVANDRUM (config-router)#network 172.16.16.28 0.0.0.3 area 0

TRIVANDRUM (config-router)#network 172.16.16.64 0.0.0.3 area 0

TRIVANDRUM (config-router)#network 192.168.7.254 0.0.0.0 area 0

TRIVANDRUM (config-router)#passive-interface loopback 0



BRBRAITT : June-2011                                              80
                       ―DATA NETWORK‖ FOR JTOs PH-II


TRIVANDRUM (config-router)#exit

TRIVANDRUM (config)#

Configuring/saving MPLS/Cisco Express Forwarding(cef) on all interfaces:-

TRIVANDRUM(config)# ip cef distributed

TRIVANDRUM(config)#mpls ip

TRIVANDRUM(config)#mpls label protocol ldp

TRIVANDRUM(config)# interface GigabitEthernet 2/1

TRIVANDRUM(config-if)# mpls ip

TRIVANDRUM(config-if)# mpls label protocol ldp

TRIVANDRUM(config-if)# interface serial 4/0/0:0

TRIVANDRUM(config-if)# mpls ip

TRIVANDRUM(config-if)# mpls label protocol ldp

TRIVANDRUM(config-if)#end

TRIVANDRUM#wr

Building configuration...

[OK]

TRIVANDRUM#




BRBRAITT : June-2011                                                        81
                       ―DATA NETWORK‖ FOR JTOs PH-II




                       MPLS-VPN LAB MODULE: 3
MPLS Traffic-engineering Tunnels using RSVP
DELHI-P
Global Configuration Commands on all MPLS-TE Routers:

DELHI-P#conf t

Enter configuration commands, one per line. End with CNTL/Z.

DELHI-P(config)#mpls traffic-eng tunnels
Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
DELHI-P(config)#int gigabitethernet 7/0/0

DELHI-P(config-if)# mpls traffic-eng tunnels

DELHI-P(config-if)#ip rsvp bandwidth 100000

DELHI-P(config)#int gigabitethernet 7/0/1

DELHI-P(config-if)# mpls traffic-eng tunnels

DELHI-P(config-if)#ip rsvp bandwidth 100000
OSPF Configuration for traffic-eng:
DELHI-P(config)#router ospf 9829

DELHI-P(config-router)#mpls traffic-eng area 0

DELHI-P(config-router)#mpls traffic-eng router-id loopback 0

DELHI-P(config- router)#end

DELHI-P#wr

Building configuration...

[OK]

DELHI-P#

MUMBAI-P

Global Configuration Commands on all MPLS-TE Routers:

MUMBAI-P#conf t

Enter configuration commands, one per line. End with CNTL/Z.


BRBRAITT : June-2011                                                   82
                       ―DATA NETWORK‖ FOR JTOs PH-II


MUMBAI-P(config)#mpls traffic-eng tunnels
Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
MUMBAI-P(config)#int gigabitethernet 7/0/1

MUMBAI-P(config-if)# mpls traffic-eng tunnels

MUMBAI-P(config-if)#ip rsvp bandwidth 100000

MUMBAI-P(config-if)#int gigabitethernet 7/0/1

MUMBAI-P(config-if)# mpls traffic-eng tunnels

MUMBAI-P(config-if)#ip rsvp bandwidth 100000
OSPF Configuration for traffic-eng:
MUMBAI-P(config)#router ospf 9829

MUMBAI-P(config-router)#mpls traffic-eng area 0

MUMBAI-P(config-router)#mpls traffic-eng router-id loopback 0

MUMBAI-P(config- router)#end

MUMBAI-P#wr

Building configuration...

[OK]

MUMBAI-P#

KOLKATA-PE

Global Configuration Commands on all MPLS-TE Routers:

KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#mpls traffic-eng tunnels
Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
KOLKATA-PE(config)#int gigabitethernet 7/0/1

KOLKATA-PE(config-if)# mpls traffic-eng tunnels

KOLKATA-PE(config-if)#ip rsvp bandwidth 100000

KOLKATA-PE(config-if)#int pos 3/1



BRBRAITT : June-2011                                                   83
                     ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-if)# mpls traffic-eng tunnels

KOLKATA-PE(config-if)#ip rsvp bandwidth 100000
OSPF Configuration for traffic-eng:
KOLKATA-PE(config)#router ospf 9829

KOLKATA-PE(config-router)#mpls traffic-eng area 0

KOLKATA-PE(config-router)#mpls traffic-eng router-id loopback 0
Create Tunnel Interface (At the tunnel headend)
KOLKATA-PE(config)#interface tunnel 2

KOLKATA-PE(config-if)#ip unnumbered to loopback 0

KOLKATA-PE(config-if)#tunnel destination 192.168.2.254

KOLKATA-PE(config-if)#tunnel mode mpls traffic-eng

KOLKATA-PE(config-if)#tunnel mpls traffic-eng bandwidth 40000

KOLKATA-PE(config-if)#tunnel mpls traffic-eng path-option 1 explicit name secret1

KOLKATA-PE(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

KOLKATA-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf
Creating Explicit Path for tunnel (Headend)
KOLKATA-PE(config)#ip explicit path name secret1

KOLKATA-PE(chg-ip-expl-path)#next-address 172.16.16.13

KOLKATA-PE(chg-ip-expl-path)#next-address 172.16.16.9

KOLKATA-PE(chg-ip-expl-path)#next-address 172.16.16.5

KOLKATA-PE(chg-ip-expl-path)#end

KOLKATA-PE#wr

PUNE-PE

Global Configuration Commands on all MPLS-TE Routers:

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#mpls traffic-eng tunnels




BRBRAITT : June-2011                                                          84
                      ―DATA NETWORK‖ FOR JTOs PH-II



Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
PUNE-PE(config)#int gigabitethernet 7/0/1

PUNE-PE(config-if)# mpls traffic-eng tunnels

PUNE-PE(config-if)#ip rsvp bandwidth 100000

PUNE-PE(config-if)#int pos 3/1

PUNE-PE(config-if)# mpls traffic-eng tunnels

PUNE-PE(config-if)#ip rsvp bandwidth 100000
OSPF Configuration for traffic-eng:
PUNE-PE(config)#router ospf 9829

PUNE-PE(config-router)#mpls traffic-eng area 0

PUNE-PE(config-router)#mpls traffic-eng router-id loopback 0
Create Tunnel Interface (At the tunnel headend)
PUNE-PE(config)#interface tunnel 2

PUNE-PE(config-if)#ip unnumbered to loopback 0

PUNE-PE(config-if)#tunnel destination 192.168.0.254

PUNE-PE(config-if)#tunnel mode mpls traffic-eng

PUNE-PE(config-if)#tunnel mpls traffic-eng bandwidth 40000

PUNE-PE(config-if)#tunnel mpls traffic-eng path-option 1 explicit name open-secret1

PUNE-PE(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

PUNE-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use
tunnel interface to calculate spf

Creating Explicit Path for tunnel (Headend)

PUNE-PE(config)#ip explicit path name open-secret1

PUNE-PE(chg-ip-expl-path)#next-address 172.16.16.6

PUNE-PE(chg-ip-expl-path)#next-address 172.16.16.10

PUNE-PE(chg-ip-expl-path)#next-address 172.16.16.14

PUNE-PE(chg-ip-expl-path)#end



BRBRAITT : June-2011                                                            85
                     ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE#wr

HYDERABAD

Global Configuration Commands on all MPLS-TE Routers:

HYDERABAD#conf t

Enter configuration commands, one per line. End with CNTL/Z.

HYDERABAD(config)#mpls traffic-eng tunnels
Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
HYDERABAD(config)#int pos 3/1

HYDERABAD(config-if)# mpls traffic-eng tunnels

HYDERABAD(config-if)#ip rsvp bandwidth 100000

HYDERABAD(config-if)#int pos 3/2

HYDERABAD(config-if)# mpls traffic-eng tunnels

HYDERABAD(config-if)#ip rsvp bandwidth 100000
OSPF Configuration for traffic-eng:
HYDERABAD(config)#router ospf 9829
HYDERABAD(config-router)#mpls traffic-eng area 0

HYDERABAD(config-router)#mpls traffic-eng router-id loopback 0
Create Tunnel Interface (At the tunnel headend)
HYDERABAD(config)#interface tunnel 1

HYDERABAD(config-if)#ip unnumbered to loopback 0

HYDERABAD(config-if)#tunnel destination 192.168.6.254

HYDERABAD(config-if)#tunnel mode mpls traffic-eng

HYDERABAD(config-if)#tunnel mpls traffic-eng bandwidth 70000

HYDERABAD(config-if)#tunnel mpls traffic-eng path-option 1 explicit name long-
path

HYDERABAD(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

HYDERABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf




BRBRAITT : June-2011                                                       86
                     ―DATA NETWORK‖ FOR JTOs PH-II



Creating Explicit Path for tunnel (Headend)
HYDERABAD(config)#ip explicit path name long-path

HYDERABAD(chg-ip-expl-path)#next-address 172.16.16.14

HYDERABAD(chg-ip-expl-path)#next-address 172.16.16.45

HYDERABAD(chg-ip-expl-path)#next-address 172.16.16.42

HYDERABAD(chg-ip-expl-path)#next-address 172.16.16.50

HYDERABAD(chg-ip-expl-path)#next-address 172.16.16.6

HYDERABAD(chg-ip-expl-path)#end

HYDERABAD#wr

BANGALORE

Global Configuration Commands on all MPLS-TE Routers:

BANGALORE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

BANGALORE(config)#mpls traffic-eng tunnels
Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:
BANGALORE(config)#int pos 3/1

BANGALORE(config-if)# mpls traffic-eng tunnels

BANGALORE(config-if)#ip rsvp bandwidth 100000

BANGALORE(config-if)#int pos 3/2

BANGALORE(config-if)# mpls traffic-eng tunnels

BANGALORE(config-if)#ip rsvp bandwidth 100000
OSPF Configuration for traffic-eng:
BANGALORE(config)#router ospf 9829

BANGALORE(config-router)#mpls traffic-eng area 0

BANGALORE(config-router)#mpls traffic-eng router-id loopback 0




BRBRAITT : June-2011                                                   87
                     ―DATA NETWORK‖ FOR JTOs PH-II



Create Tunnel Interface (At the tunnel headend)
BANGALORE(config)#interface tunnel 1

BANGALORE(config-if)#ip unnumbered to loopback 0

BANGALORE(config-if)#tunnel destination 192.168.4.254

BANGALORE(config-if)#tunnel mode mpls traffic-eng

BANGALORE(config-if)#tunnel mpls traffic-eng bandwidth 70000

BANGALORE(config-if)#tunnel mpls traffic-eng path-option 1 explicit name very-
long-path

BANGALORE(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

BANGALORE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf
Creating Explicit Path for tunnel (Headend)
BANGALORE(config)#ip explicit path name very-long-path

BANGALORE(chg-ip-expl-path)#next-address 172.16.16.5

BANGALORE(chg-ip-expl-path)#next-address 172.16.16.49

BANGALORE(chg-ip-expl-path)#next-address 172.16.16.41

BANGALORE(chg-ip-expl-path)#next-address 172.16.16.46

BANGALORE(chg-ip-expl-path)#next-address 172.16.16.13

BANGALORE(chg-ip-expl-path)#end

BANGALORE#wr

CHENNAI-PE

No Configuration

TRIVANDRUM


No Configuration




BRBRAITT : June-2011                                                       88
                      ―DATA NETWORK‖ FOR JTOs PH-II



MPLS-VPN Lab Module: 3a
MPLS Traffic-Engineering enabling Forwarding-Adjacency
Note : - The configuration is to be done only at head-end of the tunnel. The tunnels
has to be bi-directional i.e same forward & return path for IGP to advertise to other
routers.
KOLKATA-PE
KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#interface tunnel 2

KOLKATA-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf

KOLKATA-PE(config-if)#end

KOLKATA-PE#wr
PUNE-PE
PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#interface tunnel 2

PUNE-PE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use
tunnel interface to calculate spf
HYDERABAD
HYDERABAD#conf t

Enter configuration commands, one per line. End with CNTL/Z.

HYDERABAD(config)#interface tunnel 1

HYDERABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf
BANGALORE

Global Configuration Commands on all MPLS-TE Routers:

BANGALORE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

BANGALORE(config)#interface tunnel 1




BRBRAITT : June-2011                                                              89
                            ―DATA NETWORK‖ FOR JTOs PH-II


BANGALORE(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf

MPLS-VPN Lab Module: 4
MPLS Traffic-Engineering Node Protection

AHMEDABAD

Global Configuration Commands on all MPLS-TE Routers:

AHMEDABAD#conf t

Enter configuration commands, one per line. End with CNTL/Z.

AHMEDABAD(config)#mpls traffic-eng tunnels


Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:

AHMEDABAD(config)#int gigabitethernet 2/1

AHMEDABAD(config-if)# mpls traffic-eng tunnels

AHMEDABAD(config-if)#ip rsvp bandwidth 100000

OSPF Configuration for traffic-eng:


AHMEDABAD(config)#router ospf 9829

AHMEDABAD(config-router)#mpls traffic-eng area 0

AHMEDABAD(config-router)#mpls traffic-eng router-id loopback 0

Create Tunnel Interface (At the tunnel headend)

AHMEDABAD(config)#interface tunnel 1

AHMEDABAD(config-if)#ip unnumbered to loopback 0

AHMEDABAD(config-if)#tunnel destination 192.168.1.254

AHMEDABAD(config-if)#tunnel mode mpls traffic-eng

AHMEDABAD(config-if)#tunnel mpls traffic-eng bandwidth 50000

AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 1 explicit name
MAINPATH

AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 2 dynamic



BRBRAITT : June-2011                                                      90
                     ―DATA NETWORK‖ FOR JTOs PH-II


AHMEDABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf



AHMEDABAD(config)#interface tunnel 2

AHMEDABAD(config-if)#ip unnumbered to loopback 0

AHMEDABAD(config-if)#tunnel destination 192.168.1.254

AHMEDABAD(config-if)#tunnel mode mpls traffic-eng

AHMEDABAD(config-if)#tunnel mpls traffic-eng bandwidth 50000

AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 1 explicit name
NODE_PROTECTION_FOR_PUNE

AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

AHMEDABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf



AHMEDABAD(config)#interface tunnel 3

AHMEDABAD(config-if)#ip unnumbered to loopback 0

AHMEDABAD(config-if)#tunnel destination 192.168.1.254

AHMEDABAD(config-if)#tunnel mode mpls traffic-eng

AHMEDABAD(config-if)#tunnel mpls traffic-eng bandwidth 50000

AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 1 explicit name
NODE_PROTECTION_FOR_KOLKATA

AHMEDABAD(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

AHMEDABAD(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to
use tunnel interface to calculate spf




Creating Explicit Path for tunnel (Headend)

AHMEDABAD(config)#ip explicit path name MAINPATH

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.21

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.1


BRBRAITT : June-2011                                                      91
                     ―DATA NETWORK‖ FOR JTOs PH-II


AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.18

AHMEDABAD(chg-ip-expl-path)#exit



AHMEDABAD(config)#ip explicit path name NODE_PROTECTION_FOR_PUNE

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.57

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.41

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.46

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.18

AHMEDABAD(chg-ip-expl-path)#exit



AHMEDABAD(config)#ip      explicit                        path         name
NODE_PROTECTION_FOR_KOLKATA

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.21

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.49

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.41

AHMEDABAD(chg-ip-expl-path)#next-address 172.16.16.54

AHMEDABAD(chg-ip-expl-path)#end

AHMEDABAD#wr


GUWAHATI


Global Configuration Commands on all MPLS-TE Routers:

GUWAHATI#conf t

Enter configuration commands, one per line. End with CNTL/Z.

GUWAHATI(config)#mpls traffic-eng tunnels



Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:



BRBRAITT : June-2011                                                     92
                     ―DATA NETWORK‖ FOR JTOs PH-II


GUWAHATI(config)#int gigabitethernet 2/1

GUWAHATI(config-if)# mpls traffic-eng tunnels

GUWAHATI(config-if)#ip rsvp bandwidth 100000

OSPF Configuration for traffic-eng:

GUWAHATI(config)#router ospf 9829

GUWAHATI(config-router)#mpls traffic-eng area 0

GUWAHATI(config-router)#mpls traffic-eng router-id loopback 0

Create Tunnel Interface (At the tunnel headend)

GUWAHATI(config)#interface tunnel 1

GUWAHATI(config-if)#ip unnumbered to loopback 0

GUWAHATI(config-if)#tunnel destination 192.168.3.254

GUWAHATI(config-if)#tunnel mode mpls traffic-eng

GUWAHATI(config-if)#tunnel mpls traffic-eng bandwidth 50000

GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 1 explicit name
MAINPATH

GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

GUWAHATI(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use
tunnel interface to calculate spf

GUWAHATI(config)#interface tunnel 2

GUWAHATI(config-if)#ip unnumbered to loopback 0

GUWAHATI(config-if)#tunnel destination 192.168.3.254

GUWAHATI(config-if)#tunnel mode mpls traffic-eng

GUWAHATI(config-if)#tunnel mpls traffic-eng bandwidth 50000

GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 1 explicit name
NODE_PROTECTION_FOR_KOLKATA

GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

GUWAHATI(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use
tunnel interface to calculate spf



BRBRAITT : June-2011                                                         93
                     ―DATA NETWORK‖ FOR JTOs PH-II


GUWAHATI(config)#interface tunnel 3

GUWAHATI(config-if)#ip unnumbered to loopback 0

GUWAHATI(config-if)#tunnel destination 192.168.3.254

GUWAHATI(config-if)#tunnel mode mpls traffic-eng

GUWAHATI(config-if)#tunnel mpls traffic-eng bandwidth 50000

GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 1 explicit name
NODE_PROTECTION_FOR_PUNE

GUWAHATI(config-if)#tunnel mpls traffic-eng path-option 2 dynamic

GUWAHATI(config-if)#tunnel mpls traffic-eng autoroute announce ! for ospf to use
tunnel interface to calculate spf


Creating Explicit Path for tunnel (Headend)
GUWAHATI(config)#ip explicit path name MAINPATH

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.17

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.2

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.22

GUWAHATI(chg-ip-expl-path)#exit

GUWAHATI(config)#ipexplicitpathname

NODE_PROTECTION_FOR_KOLKATA
GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.53

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.42

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.50

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.22

GUWAHATI(chg-ip-expl-path)#exit

GUWAHATI(config)#ip explicit path name NODE_PROTECTION_FOR_PUNE

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.17

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.45

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.42

GUWAHATI(chg-ip-expl-path)#next-address 172.16.16.58


BRBRAITT : June-2011                                                         94
                      ―DATA NETWORK‖ FOR JTOs PH-II


GUWAHATI(chg-ip-expl-path)#end

GUWAHATI#wr

PUNE-PE

Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:

PUNE-PE(config)#int gigabitethernet 2/1

PUNE-PE(config-if)# mpls traffic-eng tunnels

PUNE-PE(config-if)#ip rsvp bandwidth 100000

PUNE-PE(config)#int pos 3/2

PUNE-PE(config-if)# mpls traffic-eng tunnels

PUNE-PE(config-if)#ip rsvp bandwidth 100000

PUNE-PE(config-if)#end

PUNE-PE#wr


KOLKATA-PE

Interface configuration Commands On MPLS-TE Routers participating in
Tunnels:

KOLKATA-PE(config)#int gigabitethernet 2/1

KOLKATA-PE(config-if)# mpls traffic-eng tunnels

KOLKATA-PE(config-if)#ip rsvp bandwidth 100000

KOLKATA-PE(config)#int pos 3/2

KOLKATA-PE(config-if)# mpls traffic-eng tunnels

KOLKATA-PE(config-if)#ip rsvp bandwidth 100000

KOLKATA-PE(config-if)#end

KOLKATA-PE#wr




BRBRAITT : June-2011                                                   95
                       ―DATA NETWORK‖ FOR JTOs PH-II




MPLS-VPN Lab Module: 5
(MPLS based L3 VPN using MP-BGP/ eBGP Lab)


DELHI-P:
Enabling & disabling interfaces:-

DELHI-P(config)#int gi 7/1/1

DELHI-P(config-if)#no shut

DELHI-P(config-if)#int gi 7/1/0

DELHI-P(config-if)#shut

Re-configuring OSPF 9829:-

DELHI-P#conf t

Enter configuration commands, one per line. End with CNTL/Z.

DELHI-P(config)#no router ospf 9829

DELHI-P(config)#router ospf 9829

DELHI-P(config-router)#auto-cost reference-bandwidth 1000

DELHI-P(config-router)#network 172.16.16.40 0.0.0.3 area 0

DELHI-P(config-router)#network 172.16.16.44 0.0.0.3 area 0

DELHI-P(config-router)#network 172.16.16.60 0.0.0.3 area 0

DELHI-P(config-router)#network 192.168.8.254 0.0.0.0 area 0

DELHI-P(config-router)#passive-interface loopback 0

DELHI-P(config-router)#end

DELHI-P#write memory

Building configuration...

[OK]

DELHI-P#



BRBRAITT : June-2011                                           96
                       ―DATA NETWORK‖ FOR JTOs PH-II


Note: Re-configuring MPLS/Cisco Express Forwarding(cef) on all interfaces is not
required for P router

MUMBAI-P:

Enabling & disabling interfaces:-

MUMBAI-P(config-if)#int gi 7/1/0

MUMBAI-P(config-if)#shut

Re-configuring OSPF 9829:-

MUMBAI-P#conf t

Enter configuration commands, one per line. End with CNTL/Z.

MUMBAI-P(config)#no router ospf 9829

MUMBAI-P(config)#router ospf 9829

MUMBAI-P(config-router)#auto-cost reference-bandwidth 1000

MUMBAI-P(config-router)#network 172.16.16.40 0.0.0.3 area 0

MUMBAI-P(config-router)#network 172.16.16.48 0.0.0.3 area 0

MUMBAI-P(config-router)#network 192.168.9.254 0.0.0.0 area 0

MUMBAI-P(config-router)#passive-interface loopback 0

MUMBAI-P(config-router)#end

MUMBAI-P#write memory

Building configuration...

[OK]

MUMBAI-P#


Note: Re-configuring MPLS/Cisco Express Forwarding(cef) on all interfaces is not
required for P router




BRBRAITT : June-2011                                                         97
                     ―DATA NETWORK‖ FOR JTOs PH-II




KOLKATA-PE: MPLS based L3 VPN configuration using MP-
BGP/eBGP:-

Enabling & disabling interfaces:-

KOLKATA-PE (config-if)#int pos 3/2

KOLKATA-PE (config-if)#shut


Re-configuring OSPF 9829:-

KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#no router ospf 9829

KOLKATA-PE(config)#router ospf 9829

KOLKATA-PE(config-router)#auto-cost reference-bandwidth 1000

KOLKATA-PE(config-router)#network 172.16.16.44 0.0.0.3 area 0

KOLKATA-PE(config-router)#network 192.168.0.254 0.0.0.0 area 0

KOLKATA-PE(config-router)#passive-interface loopback 0

KOLKATA-PE(config-router)#exit

KOLKATA-PE(config)#

Disabling MPLS on interfaces (not in MPLS Domain):-

KOLKATA-PE(config)#interface GigabitEthernet2/1

KOLKATA-PE(config-if)#no mpls ip

KOLKATA-PE(config-if)# no mpls label protocol ldp

KOLKATA-PE(config-if)#exit

KOLKATA-PE(config)#interface POS 3/1

KOLKATA-PE(config-if)#no mpls ip

KOLKATA-PE(config-if)# no mpls label protocol ldp

KOLKATA-PE(config-if)#end


BRBRAITT : June-2011                                             98
                       ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE#write memory

Building configuration...

[OK]

KOLKATA-PE#
Creation of VPN (vrf-table) and assigning Route-distinquisher/Route-target:-

KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#ip vrf ibm

KOLKATA-PE(config-vrf)#rd 9829:1

KOLKATA-PE(config-vrf)#route-target both 9829:10

KOLKATA-PE(config-vrf)#exit

KOLKATA-PE(config)#ip vrf sun

KOLKATA-PE(config-vrf)#rd 9829:2

KOLKATA-PE(config-vrf)#route-target both 9829:20

KOLKATA-PE(config-vrf)#exit

KOLKATA-PE(config)#

Assigning an interface to the VRF table:-

KOLKATA-PE(config)#interface pos 3/1

KOLKATA-PE(config-if)#ip vrf forwarding ibm

% Interface GigabitEthernet2/2 IP address 172.16.16.14 removed due to enabling
VRF ibm

KOLKATA-PE(config-if)#ip address 172.16.16.14 255.255.255.252

KOLKATA-PE(config-if)#exit

KOLKATA-PE(config)#interface gigabitEthernet 2/1

KOLKATA-PE(config-if)#ip vrf forwarding sun

% Interface GigabitEthernet2/1 IP address 172.16.16.17 removed due to enabling
VRF sun

KOLKATA-PE(config-if)#ip address 172.16.16.17 255.255.255.252


BRBRAITT : June-2011                                                           99
                       ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-if)#end

KOLKATA-PE#write memory

Building configuration...

[OK]

KOLKATA-PE#

Configuring MP-BGP

KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#router bgp 9829

KOLKATA-PE(config-router)#neighbor 192.168.5.254 remote-as 9829

KOLKATA-PE(config-router)#neighbor 192.168.5.254 update-source loopback 0

KOLKATA-PE(config-router)#neighbor 192.168.2.254 remote-as 9829

KOLKATA-PE(config-router)#neighbor 192.168.2.254 update-source loopback 0

KOLKATA-PE(config-router)#no bgp default ipv4-unicast

KOLKATA-PE(config-router)#address-family ipv4 vrf ibm

KOLKATA-PE(config-router-af)#neighbor 172.16.16.13 remote-as 20

KOLKATA-PE(config-router-af)#neighbor 172.16.16.13 next-hop-self

KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#address-family ipv4 vrf sun

KOLKATA-PE(config-router-af)#neighbor 172.16.16.18 remote-as 50

KOLKATA-PE(config-router-af)#neighbor 172.16.16.18 next-hop-self

KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#address-family vpnv4

KOLKATA-PE(config-router-af)#neighbor 192.168.5.254 activate

KOLKATA-PE(config-router-af)#neighbor 192.168.5.254 next-hop-self

KOLKATA-PE(config-router-af)#neighbor 192.168.5.254 send-community both

KOLKATA-PE(config-router-af)#neighbor 192.168.2.254 activate


BRBRAITT : June-2011                                                        100
                       ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-router-af)#neighbor 192.168.2.254 next-hop-self

KOLKATA-PE(config-router-af)#neighbor 192.168.2.254 send-community both

KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#no synchronization

KOLKATA-PE(config-router)#no auto-summary

KOLKATA-PE(config-router)#end

KOLKATA-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

KOLKATA-PE#


PUNE-PE: MPLS based L3 VPN configuration using MP-
BGP/eBGP:-

Enabling & disabling interfaces & configuring controller:-

PUNE-PE (config)#controller e1 4/0/0

PUNE-PE (config-controller)#channel-group 0 time-slot 1-31

PUNE-PE (config-c0ntroller)#exit

PUNE-PE (config)#int pos 3/2

PUNE-PE (config-if)#shut

PUNE-PE (config)#int gi 2/1

PUNE-PE (config-if)#shut

Re-configuring OSPF 9829:-

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#no router ospf 9829

PUNE-PE(config)#router ospf 9829


BRBRAITT : June-2011                                                      101
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config-router)#auto-cost reference-bandwidth 1000

PUNE-PE(config-router)#network 172.16.16.48 0.0.0.3 area 0

PUNE-PE(config-router)#network 192.168.2.254 0.0.0.0 area 0

PUNE-PE(config-router)#passive-interface loopback 0

PUNE-PE(config-router)#exit

PUNE-PE(config)#

Disabling MPLS on interfaces (not in MPLS Domain):-

PUNE-PE(config)#interface POS 3/1

PUNE-PE(config-if)#no mpls ip

PUNE-PE(config-if)# no mpls label protocol ldp

PUNE-PE(config-if)#end

PUNE-PE#write memory

Building configuration...

[OK]

PUNE-PE#



Creation of VPN (vrf-table) and assigning Route-distinquisher/Route-target:-

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#ip vrf ibm

PUNE-PE(config-vrf)#rd 9829:1

PUNE-PE(config-vrf)#route-target both 9829:10

PUNE-PE(config-vrf)#exit

PUNE-PE(config)#ip vrf sun

PUNE-PE(config-vrf)#rd 9829:2

PUNE-PE(config-vrf)#route-target both 9829:20

PUNE-PE(config-vrf)#exit


BRBRAITT : June-2011                                                           102
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config)#

Assigning an interface to the VRF table:-

PUNE-PE(config)#interface serial 4/0/0:0

PUNE-PE(config-if)#ip vrf forwarding ibm

PUNE-PE(config-if)#ip address 172.16.16.69 255.255.255.252

PUNE-PE(config-if)#exit

PUNE-PE(config)#interface pos 3/1

PUNE-PE(config-if)#ip vrf forwarding sun

% Interface GigabitEthernet2/1 IP address 172.16.16.5 removed due to enabling VRF
sun

PUNE-PE(config-if)#ip address 172.16.16.5 255.255.255.252

PUNE-PE(config-if)#end

PUNE-PE#write memory

Building configuration...

[OK]

PUNE-PE#

Configuring MP-BGP

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#router bgp 9829

PUNE-PE(config-router)#neighbor 192.168.5.254 remote-as 9829

PUNE-PE(config-router)#neighbor 192.168.5.254 update-source loopback 0

PUNE-PE(config-router)#neighbor 192.168.0.254 remote-as 9829

PUNE-PE(config-router)#neighbor 192.168.0.254 update-source loopback 0

PUNE-PE(config-router)#no bgp default ipv4-unicast

PUNE-PE(config-router)#address-family ipv4 vrf ibm

PUNE-PE(config-router-af)#neighbor 172.16.16.70 remote-as 10


BRBRAITT : June-2011                                                         103
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config-router-af)#neighbor 172.16.16.70 next-hop-self

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#address-family ipv4 vrf sun

PUNE-PE(config-router-af)#neighbor 172.16.16.6 remote-as 40

PUNE-PE(config-router-af)#neighbor 172.16.16.6 next-hop-self

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#address-family vpnv4

PUNE-PE(config-router-af)#neighbor 192.168.5.254 activate

PUNE-PE(config-router-af)#neighbor 192.168.5.254 next-hop-self

PUNE-PE(config-router-af)#neighbor 192.168.5.254 send-community both

PUNE-PE(config-router-af)#neighbor 192.168.0.254 activate

PUNE-PE(config-router-af)#neighbor 192.168.0.254 next-hop-self

PUNE-PE(config-router-af)#neighbor 192.168.0.254 send-community both

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#no synchronization

PUNE-PE(config-router)#no auto-summary

PUNE-PE(config-router)#end

PUNE-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

PUNE-PE#




BRBRAITT : June-2011                                                   104
                     ―DATA NETWORK‖ FOR JTOs PH-II




CHENNAI-PE:

Enabling & disabling interfaces:-

CHENNAI-PE (config)#int gi 2/1

CHENNAI-PE (config-if)#shut


Re-configuring OSPF 9829:-

CHENNAI-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

CHENNAI-PE(config)#no router ospf 9829

CHENNAI-PE(config)#router ospf 9829

CHENNAI-PE(config-router)#auto-cost reference-bandwidth 1000

CHENNAI-PE(config-router)#network 172.16.16.60 0.0.0.3 area 0

CHENNAI-PE(config-router)#network 192.168.5.254 0.0.0.0 area 0

CHENNAI-PE(config-router)#passive-interface loopback 0

CHENNAI-PE(config-router)#exit

CHENNAI-PE(config)#

Disabling MPLS on interfaces (not in MPLS Domain):-

CHENNAI-PE(config)#interface GigabitEthernet2/1

CHENNAI-PE(config-if)#no mpls ip

CHENNAI-PE(config-if)# no mpls label protocol ldp

CHENNAI-PE(config-if)#exit



Creation of VPN (vrf-table) and assigning Route-distinquisher/Route-target:-

CHENNAI-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.



BRBRAITT : June-2011                                                           105
                       ―DATA NETWORK‖ FOR JTOs PH-II


CHENNAI-PE(config)#ip vrf ibm

CHENNAI-PE(config-vrf)#rd 9829:1

CHENNAI-PE(config-vrf)#route-target both 9829:10

CHENNAI-PE(config-vrf)#exit

CHENNAI-PE(config)#

Assigning an interface to the VRF table:-

CHENNAI-PE(config)#interface serial 4/0/0:0

CHENNAI-PE(config-if)#ip vrf forwarding ibm

CHENNAI-PE(config-if)#ip address 172.16.16.65 255.255.255.252

CHENNAI-PE(config-if)#end

CHENNAI-PE#write memory

Building configuration...

[OK]

CHENNAI-PE#

Configuring MP-BGP

CHENNAI-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

CHENNAI-PE(config)#router bgp 9829

CHENNAI-PE(config-router)#neighbor 192.168.0.254 remote-as 9829

CHENNAI-PE(config-router)#neighbor 192.168.0.254 update-source loopback 0

CHENNAI-PE(config-router)#neighbor 192.168.2.254 remote-as 9829

CHENNAI-PE(config-router)#neighbor 192.168.2.254 update-source loopback 0

CHENNAI-PE(config-router)#no bgp default ipv4-unicast

CHENNAI-PE(config-router)#address-family ipv4 vrf ibm

CHENNAI-PE(config-router-af)#neighbor 172.16.16.66 remote-as 20

CHENNAI-PE(config-router-af)#neighbor 172.16.16.66 next-hop-self



BRBRAITT : June-2011                                                        106
                       ―DATA NETWORK‖ FOR JTOs PH-II


CHENNAI-PE(config-router-af)#exit-address-family

CHENNAI-PE(config-router)#address-family vpnv4

CHENNAI-PE(config-router-af)#neighbor 192.168.0.254 activate

CHENNAI-PE(config-router-af)#neighbor 192.168.0.254 next-hop-self

CHENNAI-PE(config-router-af)#neighbor 192.168.0.254 send-community both

CHENNAI-PE(config-router-af)#neighbor 192.168.2.254 activate

CHENNAI-PE(config-router-af)#neighbor 192.168.2.254 next-hop-self

CHENNAI-PE(config-router-af)#neighbor 192.168.2.254 send-community both

CHENNAI-PE(config-router-af)#exit-address-family

CHENNAI-PE(config-router)#no synchronization

CHENNAI-PE(config-router)#no auto-summary

CHENNAI-PE(config-router)#end

CHENNAI-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

CHENNAI-PE#


IBM-CE-1 : eBGP configuration:-

Enabling & disabling interfaces:-

IBM-CE-1 (config)#controller e1 4/0/0

IBM-CE-1 (config-controller)#channel-group 0 time-slot 1-31

IBM-CE-1 (config-c0ntroller)#exit

IBM-CE-1 (config)#int pos 3/2

IBM-CE-1 (config-if)#shut

IBM-CE-1 (config-if)#int serial 4/0/0:0

IBM-CE-1 (config-if)#ip add 172.16.16.70 255.255.255.252


BRBRAITT : June-2011                                                      107
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-CE-1 (config-if)#exit




Removing OSPF 9829:-

IBM-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-1(config)#no router ospf 9829

IBM-CE-1(config)#


Configuring BGP 10 & creating loopback 1 interface:-

IBM-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-1(config)#interface loopback 1

IBM-CE-1(config-if)#ip address 10.10.0.1 255.255.0.0

IBM-CE-1(config-if)#exit

IBM-CE-1(config)#router bgp 10

IBM-CE-1(config-router)#no synchronization

IBM-CE-1(config-router)#no auto-summary

IBM-CE-1(config-router)#neighbour 172.16.16.33 remote-as 9829

IBM-CE-1(config-router)#network 10.10.0.0 mask 255.255.0.0

IBM-CE-1(config-router)#network 192.168.3.254 mask 255.255.255.255

IBM-CE-1(config-router)#end

IBM-PE#write memory

Building configuration...

[OK]

IBM-CE-1#




BRBRAITT : June-2011                                                 108
                     ―DATA NETWORK‖ FOR JTOs PH-II




IBM-CE-2 : eBGP configuration:-

Enabling & disabling interfaces:-

IBM-CE-2 (config)#int pos 3/2

IBM-CE-2 (config-if)#shut


Removing OSPF 9829:-

IBM-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-2(config)#no router ospf 9829

IBM-CE-2(config)#

Configuring BGP 20 & creating loopback 1 interface:-

IBM-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-2(config)#interface loopback 1

IBM-CE-2(config-if)#ip address 10.20.0.1 255.255.0.0

IBM-CE-2(config-if)#exit

IBM-CE-2(config)#router bgp 20

IBM-CE-2(config-router)#no synchronization

IBM-CE-2(config-router)#no auto-summary

IBM-CE-2(config-router)#neighbour 172.16.16.14 remote-as 9829

IBM-CE-2(config-router)#network 10.20.0.0 mask 255.255.0.0

IBM-CE-2(config-router)#network 192.168.4.254 mask 255.255.255.255

IBM-CE-2(config-router)#end




BRBRAITT : June-2011                                                 109
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-PE#write memory

Building configuration...

[OK]

IBM-CE-2#

IBM-CE-3 : eBGP configuration:-

Enabling & disabling interfaces:-

IBM-CE-3 (config)#controller e1 4/0/0

IBM-CE-3 (config-controller)#channel-group 0 time-slot 1-31

IBM-CE-3 (config-c0ntroller)#exit

IBM-CE-3 (config-if)#int serial 4/0/0:0

IBM-CE-3 (config-if)#ip add 172.16.16.66 255.255.255.252

IBM-CE-3 (config-if)#exit


Removing OSPF 9829:-

IBM-CE-3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-3(config)#no router ospf 9829

IBM-CE-3(config)#


Configuring BGP 30 & creating loopback 1 interface:-

IBM-CE-3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-3(config)#interface loopback 1

IBM-CE-3(config-if)#ip address 10.30.0.1 255.255.0.0

IBM-CE-3(config-if)#exit

IBM-CE-3(config)#router bgp 30

IBM-CE-3(config-router)#no synchronization



BRBRAITT : June-2011                                           110
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-CE-3(config-router)#no auto-summary

IBM-CE-3(config-router)#neighbour 172.16.16.65 remote-as 9829

IBM-CE-3(config-router)#network 10.30.0.0 mask 255.255.0.0

IBM-CE-3(config-router)#network 192.168.7.254 mask 255.255.255.255

IBM-CE-3(config-router)#end

IBM-PE#write memory

Building configuration...

[OK]

IBM-CE-3#



SUN-CE-1 : eBGP configuration:-

Removing OSPF 9829:-

SUN-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-1(config)#no router ospf 9829

SUN-CE-1(config)#

Disabling MPLS on interfaces (not in MPLS Domain):-

SUN-CE-1(config)#no ip cef distributed

SUN-CE-1(config)#no mpls ip

SUN-CE-1(config)#no mpls label protocol ldp

SUN-CE-1(config)#no mpls ldp router-id loopback 0

SUN-CE-1(config)#interface pos 3/1

SUN-CE-1(config-if)#no mpls ip

SUN-CE-1(config-if)#no mpls label protocol ldp

SUN-CE-1(config-if)#end

SUN-PE#write memory



BRBRAITT : June-2011                                                 111
                       ―DATA NETWORK‖ FOR JTOs PH-II


Building configuration...

[OK]

SUN-CE-1#



Configuring BGP 40 & creating loopback 1 interface:-

SUN-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-1(config)#interface loopback 1

SUN-CE-1(config-if)#ip address 20.40.0.1 255.255.0.0

SUN-CE-1(config-if)#no shutdown

SUN-CE-1(config-if)#exit

SUN-CE-1(config)#router bgp 40

SUN-CE-1(config-router)#no synchronization

SUN-CE-1(config-router)#no auto-summary

SUN-CE-1(config-router)#neighbour 172.16.16.5 remote-as 9829

SUN-CE-1(config-router)#network 20.40.0.0 mask 255.255.0.0

SUN-CE-1(config-router)#network 192.168.6.254 mask 255.255.255.255

SUN-CE-1(config-router)#end

SUN-PE#write memory

Building configuration...

[OK]

SUN-CE-1#

SUN-CE-2 : eBGP configuration:-

Removing OSPF 9829:-

SUN-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.



BRBRAITT : June-2011                                                 112
                       ―DATA NETWORK‖ FOR JTOs PH-II


SUN-CE-2(config)# no router ospf 9829

SUN-CE-2(config)#




Configuring Controller & Disabling MPLS on interfaces (not in MPLS
Domain):-


SUN-CE-2(config)#controller e1 4/0/0

SUN-CE-2(config-controller)#channel-group 0 time-slot 1-31

SUN-CE-2(config-controller)#exit

SUN-CE-2(config)#no ip cef distributed

SUN-CE-2(config)#no mpls ip

SUN-CE-2(config)#no mpls label protocol ldp

SUN-CE-2(config)#no mpls ldp router-id loopback 0

SUN-CE-2(config)#interface GigabitEthernet2/1

SUN-CE-2(config-if)#no mpls ip

SUN-CE-2(config-if)#no mpls label protocol ldp

SUN-CE-2(config-if)#int serial 4/0/0:0

SUN-CE-2(config-if)#ip add 172.16.16.66 255.255.255.252

SUN-CE-2(config-if)#end

SUN-CE-2#write memory

Building configuration...

[OK]

SUN-CE-2#

Configuring BGP 50 & creating loopback 1 interface:-

SUN-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-2(config)#interface loopback 1


BRBRAITT : June-2011                                                 113
                       ―DATA NETWORK‖ FOR JTOs PH-II


SUN-CE-2(config-if)#ip address 20.50.0.1 255.255.0.0

SUN-CE-2(config-if)#no shutdown

SUN-CE-2(config-if)#exit

SUN-CE-2(config)#router bgp 50

SUN-CE-2(config-router)#no synchronization

SUN-CE-2(config-router)#no auto-summary

SUN-CE-2(config-router)#neighbour 172.16.16.29 remote-as 9829

SUN-CE-2(config-router)#network 10.20.0.0 mask 255.255.0.0

SUN-CE-2(config-router)#end

SUN-PE#write memory

Building configuration...

[OK]

SUN-CE-2#


Verification commands:-

Eg. For PUNE-PE router



PUNE-PE#show ip vrf

PUNE-PE#show ip vrf detail

PUNE-PE#show ip vrf interfaces

PUNE-PE#show ip protocols vrf ibm

PUNE-PE#show ip route vrf ibm

PUNE-PE#show ip bgp vpnv4 vrf ibm

PUNE-PE#show ip bgp vpnv4 vrf ibm neighbors

PUNE-PE#show ip bgp vpnv4 all summary

PUNE-PE#show ip bgp neighbors

PUNE-PE#show mpls forwarding vrf ibm



BRBRAITT : June-2011                                            114
                     ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE#show ip cef vrf ibm

PUNE-PE#ping vrf ibm 10.20.0.1

PUNE-PE#trace vrf ibm 10.20.0.1

PUNE-PE#telnet 10.20.0.1 /vrf ibm




BRBRAITT : June-2011                                 115
                      ―DATA NETWORK‖ FOR JTOs PH-II


MPLS-VPN Lab Module: 6
(MPLS based L3 VPN using MP-BGP/ OSPF Lab)

Delhi-P:


Note: No configuration needed in P-router


Mumbai-P:


Note: No configuration needed in P-router



PUNE-PE:


Configuring OSPF Process 10 for CE-PE link:-

PUNE-PE# conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#router ospf 10 vrf ibm

PUNE-PE(config-router)#auto-cost reference-bandwidth 1000

PUNE-PE(config-router)#network 172.16.16.68 0.0.0.3 area 0

PUNE-PE(config-router)#redistribute bgp 9829 subnets

PUNE-PE(config-router)#exit

PUNE-PE(config)#


Configuring OSPF Process 40 for CE-PE link:-

PUNE-PE(config)#router ospf 40 vrf sun

PUNE-PE(config-router)#auto-cost reference-bandwidth 1000

PUNE-PE(config-router)#network 172.16.16.4 0.0.0.3 area 0

PUNE-PE(config-router)#redistribute bgp 9829 subnets

PUNE-PE(config-router)#exit

PUNE-PE(config)#



BRBRAITT : June-2011                                           116
                       ―DATA NETWORK‖ FOR JTOs PH-II


Modifying the MP-BGP configuration:-

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#router bgp 9829

PUNE-PE(config-router)#address-family ipv4 vrf ibm

PUNE-PE(config-router-af)#no neighbor 172.16.16.70 remote-as 10

PUNE-PE(config-router-af)#no neighbor 172.16.16.70 next-hop-self

PUNE-PE(config-router-af)#redistribute ospf 10 match internal external 1 external 2

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#address-family ipv4 vrf sun

PUNE-PE(config-router-af)#no neighbor 172.16.16.6 remote-as 40

PUNE-PE(config-router-af)#no neighbor 172.16.16.6 next-hop-self

PUNE-PE(config-router-af)#redistribute ospf 40 match internal external 1 external 2

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#end

PUNE-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

PUNE-PE#


KOLKATA-PE:


Configuring OSPF Process 20 for CE-PE link:-

KOLKATA-PE# conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#router ospf 20 vrf ibm



BRBRAITT : June-2011                                                             117
                     ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-router)#auto-cost reference-bandwidth 1000

KOLKATA-PE(config-router)#network 172.16.16.12 0.0.0.3 area 0

KOLKATA-PE(config-router)#redistribute bgp 9829 subnets

KOLKATA-PE(config-router)#exit

KOLKATA-PE(config)#


Configuring OSPF Process 50 for CE-PE link:-

KOLKATA-PE(config)#router ospf 50 vrf sun

KOLKATA-PE(config-router)#auto-cost reference-bandwidth 1000

KOLKATA-PE(config-router)#network 172.16.16.64 0.0.0.3 area 0

KOLKATA-PE(config-router)#redistribute bgp 9829 subnets

KOLKATA-PE(config-router)#exit

KOLKATA-PE(config)#


Modifying the MP-BGP configuration:-

KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#router bgp 9829

KOLKATA-PE(config-router)#address-family ipv4 vrf ibm

KOLKATA-PE(config-router-af)#no neighbor 172.16.16.13 remote-as 20

KOLKATA-PE(config-router-af)#no neighbor 172.16.16.13 next-hop-self

KOLKATA-PE(config-router-af)#redistribute ospf 20 match internal external 1
external 2

KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#address-family ipv4 vrf sun

KOLKATA-PE(config-router-af)#no neighbor 172.16.16.18 remote-as 50

KOLKATA-PE(config-router-af)#no neighbor 172.16.16.18 next-hop-self

KOLKATA-PE(config-router-af)#redistribute ospf 50 match internal external 1
external 2


BRBRAITT : June-2011                                                   118
                       ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#end

KOLKATA-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

KOLKATA-PE#



CHENNAI-PE:


Configuring OSPF Process 30 for CE-PE link:-

CHENNAI-PE# conf t

Enter configuration commands, one per line. End with CNTL/Z.

CHENNAI-PE(config)#router ospf 30 vrf ibm

CHENNAI-PE(config-router)#auto-cost reference-bandwidth 1000

CHENNAI-PE(config-router)#network 172.16.16.64 0.0.0.3 area 0

CHENNAI-PE(config-router)#redistribute bgp 9829 subnets

CHENNAI-PE(config-router)#exit

CHENNAI-PE(config)#


Modifying the MP-BGP configuration:-

CHENNAI-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

CHENNAI-PE(config)#router bgp 9829

CHENNAI-PE(config-router)#address-family ipv4 vrf ibm

CHENNAI-PE(config-router-af)#no neighbor 172.16.16.66 remote-as 30

CHENNAI-PE(config-router-af)#no neighbor 172.16.16.66 next-hop-self




BRBRAITT : June-2011                                                  119
                       ―DATA NETWORK‖ FOR JTOs PH-II


CHENNAI-PE(config-router-af)#redistribute ospf 30 match internal external 1
external 2

CHENNAI-PE(config-router-af)#exit-address-family

CHENNAI-PE(config-router)#end

CHENNAI-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

CHENNAI-PE#




IBM-CE-1 : OSPF configuration:-

Removing BGP 10 and configuring OSPF 10:-

IBM-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-1(config)#no router bgp 10

IBM-CE-1(config)#router ospf 10

IBM-CE-1(config-router)#auto-cost reference-bandwidth 1000

IBM-CE-1(config-router)#network 172.16.16.68 0.0.0.3 area 0

IBM-CE-1(config-router)#network 10.10.0.0 0.0.255.255 area 0

IBM-CE-1(config-router)#passive-interface loopback 1

IBM-CE-1(config-router)#end

IBM-CE-1#write memory

Building configuration...

[OK]

IBM-CE-1#clear ip ospf 10 process

Reset OSPF process? [no]: y


BRBRAITT : June-2011                                                   120
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-CE-1#



IBM-CE-2 : OSPF configuration:-

Removing BGP 20 and configuring OSPF 20:-

IBM-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-2(config)#no router bgp 20

IBM-CE-2(config)#router ospf 20

IBM-CE-2(config-router)#auto-cost reference-bandwidth 1000

IBM-CE-2(config-router)#network 172.16.16.12 0.0.0.3 area 0

IBM-CE-2(config-router)#network 10.20.0.0 0.0.255.255 area 0

IBM-CE-2(config-router)#passive-interface loopback 1

IBM-CE-2(config-router)#end

IBM-CE-2#write memory

Building configuration...

[OK]

IBM-CE-2#clear ip ospf 20 process

Reset OSPF process? [no]: y

IBM-CE-2#

IBM-CE-3 : OSPF configuration:-

Removing BGP 30 and configuring OSPF 30:-

IBM-CE-3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-3(config)#no router bgp 30

IBM-CE-3(config)#router ospf 30

IBM-CE-3(config-router)#auto-cost reference-bandwidth 1000



BRBRAITT : June-2011                                           121
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-CE-3(config-router)#network 172.16.16.64 0.0.0.3 area 0

IBM-CE-3(config-router)#network 10.30.0.0 0.0.255.255 area 0

IBM-CE-3(config-router)#passive-interface loopback 1

IBM-CE-3(config-router)#end

IBM-CE-3#write memory

Building configuration...

[OK]

IBM-CE-2#clear ip ospf 30 process

Reset OSPF process? [no]: y

IBM-CE-2#

SUN-CE-1 : OSPF configuration:-

Removing BGP 40 and configuring OSPF 40:-

SUN-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-1(config)#no router bgp 40

SUN-CE-1(config)#router ospf 40

SUN-CE-1(config-router)#auto-cost reference-bandwidth 1000

SUN-CE-1(config-router)#network 172.16.16.4 0.0.0.3 area 0

SUN-CE-1(config-router)#network 20.40.0.0 0.0.255.255 area 0

SUN-CE-1(config-router)#passive-interface loopback 1

SUN-CE-1(config-router)#end

SUN-CE-1#write memory

Building configuration...

[OK]

SUN-CE-1#clear ip ospf 2100 process

Reset OSPF process? [no]: y



BRBRAITT : June-2011                                           122
                       ―DATA NETWORK‖ FOR JTOs PH-II


SUN-CE-1#



SUN-CE-2 : OSPF configuration:-

Removing BGP 50 and configuring OSPF 50:-

SUN-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-2(config)#no router bgp 50

SUN-CE-2(config)#router ospf 50

SUN-CE-2(config-router)#auto-cost reference-bandwidth 1000

SUN-CE-2(config-router)#network 172.16.16.16 0.0.0.3 area 0

SUN-CE-2(config-router)#network 20.50.0.0 0.0.255.255 area 0

SUN-CE-2(config-router)#passive-interface loopback 1

SUN-CE-2(config-router)#end

SUN-CE-2#write memory

Building configuration...

[OK]

SUN-CE-2#

SUN-CE-2#clear ip ospf 50 process

Reset OSPF process? [no]: y

SUN-CE-2#




BRBRAITT : June-2011                                           123
                      ―DATA NETWORK‖ FOR JTOs PH-II




MPLS-VPN Lab Module: 7
(MPLS based L3 VPN using MP-BGP/ Static Lab)


Delhi-P:

Note: No configuration needed in P-router

Mumbai-P:

Note: No configuration needed in P-router

PUNE-PE:

Removing OSPF Process & configuring Static Route:-

PUNE-PE (config)#no router ospf 10 vrf ibm

PUNE-PE (config)#no router ospf 40 vrf sun

PUNE-PE (config)#ip route vrf ibm 10.10.0.0 255.255.0.0 172.16.16.70

PUNE-PE (config)#ip route vrf sun 20.40.0.0 255.255.0.0 172.16.16.6

PUNE-PE (config)#

Modifying the MP-BGP configuration:-

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#router bgp 9829

PUNE-PE(config-router)#address-family ipv4 vrf ibm

PUNE-PE(config-router-af)#network 10.10.0.0 mask 255.255.0.0

PUNE-PE(config-router-af)#network 172.16.16.68 mask 255.255.255.252

PUNE-PE(config-router-af)#no redistribute ospf 10 match internal external 1 external
2

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#address-family ipv4 vrf sun


BRBRAITT : June-2011                                                            124
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config-router-af)#network 20.40.0.0 mask 255.255.0.0

PUNE-PE(config-router-af)#network 172.16.16.4 mask 255.255.255.252

PUNE-PE(config-router-af)#no redistribute ospf 40 match internal external 1 external
2

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#end

PUNE-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

PUNE-PE#

KOLKATA-PE:


Removing OSPF Process & configuring Static Route:-

KOLKATA-PE (config)#no router ospf 20 vrf ibm

KOLKATA-PE (config)#no router ospf 50 vrf sun

KOLKATA-PE (config)#ip route vrf ibm 10.20.0.0 255.255.0.0 172.16.16.13

KOLKATA-PE (config)#ip route vrf sun 20.40.0.0 255.255.0.0 172.16.16.18

KOLKATA-PE (config)#

Modifying the MP-BGP configuration:-

KOLKATA-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

KOLKATA-PE(config)#router bgp 9829

KOLKATA-PE(config-router)#address-family ipv4 vrf ibm

KOLKATA-PE(config-router-af)#network 10.20.0.0 mask 255.255.0.0

KOLKATA-PE(config-router-af)#network 172.16.16.12 mask 255.255.255.252

KOLKATA-PE(config-router-af)#no redistribute ospf 10 match internal external 1
external 2


BRBRAITT : June-2011                                                            125
                       ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#address-family ipv4 vrf sun

KOLKATA-PE(config-router-af)#network 20.50.0.0 mask 255.255.0.0

KOLKATA-PE(config-router-af)#network 172.16.16.16 mask 255.255.255.252

KOLKATA-PE(config-router-af)#no redistribute ospf 40 match internal external 1
external 2

KOLKATA-PE(config-router-af)#exit-address-family

KOLKATA-PE(config-router)#end

KOLKATA-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

KOLKATA-PE#


PUNE-PE:


Removing OSPF Process & configuring Static Route:-

PUNE-PE (config)#no router ospf 30 vrf ibm

PUNE-PE (config)#ip route vrf ibm 10.30.0.0 255.255.0.0 172.16.16.66

PUNE-PE (config)#

Modifying the MP-BGP configuration:-

PUNE-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

PUNE-PE(config)#router bgp 9829

PUNE-PE(config-router)#address-family ipv4 vrf ibm

PUNE-PE(config-router-af)#network 10.30.0.0 mask 255.255.0.0

PUNE-PE(config-router-af)#network 172.16.16.64 mask 255.255.255.252




BRBRAITT : June-2011                                                      126
                       ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config-router-af)#no redistribute ospf 30 match internal external 1 external
2

PUNE-PE(config-router-af)#exit-address-family

PUNE-PE(config-router)#end

PUNE-PE#wr

04:49:30: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

[OK]

PUNE-PE#



IBM-CE-1 :
Removing OSPF & Configuring Default route:-

IBM-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-1(config)#no router ospf 10

IBM-CE-1(config)#ip route 0.0.0.0 0.0.0.0 se 4/0/0:0

IBM-CE-1(config)#end

IBM-CE-1#write memory

Building configuration...

[OK]

IBM-CE-1#

IBM-CE-2 :

Removing OSPF & Configuring Default route:-

IBM-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-2(config)#no router ospf 20

IBM-CE-2(config)# ip route 0.0.0.0 0.0.0.0 pos 3/1


BRBRAITT : June-2011                                                            127
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-CE-2(config)#end

IBM-CE-2#write memory

Building configuration...

[OK]

IBM-CE-2#

IBM-CE-3 :

Removing OSPF & Configuring Default route:-

IBM-CE-3# conf t

Enter configuration commands, one per line. End with CNTL/Z.

IBM-CE-3(config)#no router ospf 30

IBM-CE-3(config)# ip route 0.0.0.0 0.0.0.0 Serial 4/0/0:0

IBM-CE-3(config)#end

IBM-CE-3#write memory

Building configuration...

[OK]

IBM-CE-2#

SUN-CE-1 :

Removing OSPF & Configuring Default route:-

SUN-CE-1# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-1(config)#no router ospf 40

SUN-CE-1(config)# ip route 0.0.0.0 0.0.0.0 pos 3/1

SUN-CE-1(config)#end

SUN-CE-1#write memory

Building configuration...

[OK]


BRBRAITT : June-2011                                           128
                       ―DATA NETWORK‖ FOR JTOs PH-II


SUN-CE-1#



SUN-CE-2 :

Removing OSPF & Configuring Default route:-

SUN-CE-2# conf t

Enter configuration commands, one per line. End with CNTL/Z.

SUN-CE-2(config)#no router ospf 50

SUN-CE-2(config)# ip route 0.0.0.0 0.0.0.0 pos 3/1

SUN-CE-2(config)#end

SUN-CE-2#write memory

Building configuration...

[OK]

SUN-CE-2#




BRBRAITT : June-2011                                           129
                      ―DATA NETWORK‖ FOR JTOs PH-II




MPLS-VPN Lab Module: 8
(MPLS L-2 VPN using X-connect & Frame-Relay)

Delhi-P:


Note: No configuration needed in P-router


Mumbai-P :


Note: No configuration needed in P-router

Chennai-PE:

Configuring pos link for up link connection


CHENNAI-PE#conf t

Enter configuration commands, one per line. End with CNTL/Z.

CHENNAI-PE(config)#int pos 3/1

CHENNAI-PE(config-if)#no shut

CHENNAI-PE(config-if)#encapsulation ppp

CHENNAI-PE(config-if)#clock source internal

CHENNAI-PE(config-if)#ip add 172.16.16.74 255.255.255.252

CHENNAI -PE(config-if)#mpls ip

CHENNAI -PE(config-if)#mpls label protocol ldp

CHENNAI-PE(config-if)#exit

CHENNAI-PE(config)#

Global Configuration for frame relay interface

CHENNAI-PE(config)#frame-relay switching

Configuring Serial link for frame relay interface



BRBRAITT : June-2011                                           130
                      ―DATA NETWORK‖ FOR JTOs PH-II


CHENNAI-PE(config)#int serial 4/0/0:0

CHENNAI-PE(config-if)# encapsulation frame-relay

CHENNAI-PE(config-if)# frame-relay interface-dlci 18 switched

CHENNAI-PE(config-if)# frame-relay lmi-type ansi

CHENNAI-PE(config-if)# frame-relay intf-type dce

CHENNAI-PE(config-if)#exit

CHENNAI-PE(config)#

Binding interface with virtual-circuit VC

CHENNAI-PE(config)#connect ibm-site1 serial 4/0/0:0 18 l2transport

CHENNAI-PE(config-psw-)#xconnect 192.168.2.254 321 encapsulation mpls

CHENNAI-PE(config-psw-)#end

CHENNAI-PE#wr


PUNE-PE:

Global Configuration for frame relay interface

PUNE-PE(config)#frame-relay switching

Configuring Serial link for frame relay interface

PUNE-PE(config)#int serial 4/0/0:0

PUNE-PE(config-if)#no ip address

PUNE-PE(config-if)# encapsulation frame-relay

PUNE-PE(config-if)# frame-relay interface-dlci 19 switched

PUNE-PE(config-if)# frame-relay lmi-type ansi

PUNE-PE(config-if)# frame-relay intf-type dce

PUNE-PE(config-if)#exit

PUNE-PE(config)#

Binding interface with virtual-circuit VC



BRBRAITT : June-2011                                                    131
                      ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config)#connect ibm-site1 serial 4/0/0:0 19 l2transport

PUNE-PE(config-psw-)#xconnect 192.168.5.254 321 encapsulation mpls

PUNE-PE(config-psw-)#end

PUNE-PE#wr


Binding fast-ethernet interface with virtual-circuit VC for sun


PUNE-PE(config)#int fast-ethernet 1/1

PUNE-PE(config-if)#no shut

PUNE-PE(config-if)#no ip add

PUNE-PE(config-if)# xconnect 192.168.0.254 123 encapsulation mpls

PUNE-PE(config-if)#end

PUNE-PE#wr


KOLKATA-PE:

Binding fast-ethernet interface with virtual-circuit VC for sun

KOLKATA-PE(config)#int gigabitethernet 2/1

KOLKATA-PE(config-if)#no shut

KOLKATA-PE(config-if)#no ip add

KOLKATA-PE(config-if)# xconnect 192.168.2.254 123 encapsulation mpls

KOLKATA-PE(config-if)#end

KOLKATA-PE#wr


IBM-CE-1 :

Global Configuration for frame relay interface

IBM-CE-1(config)#frame-relay switching

Configuring Serial link for frame relay interface




BRBRAITT : June-2011                                                   132
                       ―DATA NETWORK‖ FOR JTOs PH-II


IBM-CE-1 (config)#int serial 4/0/0:0

IBM-CE-1 (config-if)#encapsulation frame-relay ietf

IBM-CE-1 (config-if)#exit

IBM-CE-1 (config)#int serial 4/0/0:0.1 point-to-point

IBM-CE-1 (config-if)# frame-relay interface-dlci 19 ietf

IBM-CE-1 (config-if)#ip add 10.1.0.1 255.255.255.0

IBM-CE-1 (config-if)#end

IBM-CE-1#wr


IBM-CE-2 :

Global Configuration for frame relay interface

IBM-CE-1(config)#frame-relay switching



Configuring Serial link for frame relay interface

IBM-CE-1 (config)#int serial 4/0/0:0

IBM-CE-1 (config-if)#encapsulation frame-relay ietf

IBM-CE-1 (config-if)#exit

IBM-CE-1 (config)#int serial 4/0/0:0.1 point-to-point

IBM-CE-1 (config-if)# frame-relay interface-dlci 18 ietf

IBM-CE-1 (config-if)#ip add 10.1.0.2 255.255.255.0

IBM-CE-1 (config-if)#end

IBM-CE-1#wr


SUN-CE-1 :

Configuring fast-ethernet interface

SUN-CE-1 (config)#int fast-ethernet 1/1

SUN-CE-1 (config-if)#no shut




BRBRAITT : June-2011                                       133
                      ―DATA NETWORK‖ FOR JTOs PH-II


SUN-CE-1 (config-if)# ip add 10.0.0.1 255.255.255.0

SUN-CE-1 (config-if)#end

SUN-CE-1#wr


SUN-CE-2 :

Configuring gigabit-ethernet interface

SUN-CE-2 (config)#int gigabit-ethernet 2/1

SUN-CE-2 (config-if)#no shut

SUN-CE-2 (config-if)# ip add 10.0.0.2 255.255.255.0

SUN-CE-2 (config-if)#end

SUN-CE-2 #wr




BRBRAITT : June-2011                                  134
                       ―DATA NETWORK‖ FOR JTOs PH-II




MPLS-VPN Lab Module: 9
(Carrier Support Carrier)

Delhi-P:


DELHI-P#conf t

DELHI-P(config)#mpls ip

DELHI-P(config)#mpls label pro ldp

DELHI-P(config)#ip cef distri

DELHI-P(config-if)#int gi 7/0/0

DELHI-P(config-if)#mpls ip

DELHI-P(config-if)#mpls label pro ldp

DELHI-P(config-if)#int gi 7/0/1

DELHI-P(config-if)#no mpls ip

DELHI-P(config-if)#no mpls label pro ldp

DELHI-P(config-if)#exit

DELHI-P(config)#ip vrf mtnl

DELHI-P(config)#rd 9829:1

DELHI-P(config)#route-target 9829:1

DELHI-P(config)#exit

DELHI-P(config)#int gi 7/0/1

DELHI-P(config-if)#ip vrf forwarding mtnl

DELHI-P(config-if)#ip add 172.16.16.45 255.255.255.252

DELHI-P(config-if)#exit




BRBRAITT : June-2011                                     135
                      ―DATA NETWORK‖ FOR JTOs PH-II


DELHI-P(config)#no router ospf 9829

DELHI-P(config)#router ospf 9829

DELHI-P(config-router)#net 172.16.16.40 0.0.0.3 ar 0

DELHI-P(config-router)#net 192.168.8.254 0.0.0.0 ar 0

DELHI-P(config-router)#exit



DELHI-P(config)#router bgp 9829

DELHI-P(config-router)#neighbor 192.168.9.254 remote-as 9829

DELHI-P(config-router)#neighbor 192.168.9.254 update lo0

DELHI-P(config-router)#address-family ipv4 vrf mtnl

DELHI-P(config-router-af)#neigbor 172.16.16.46 remote-as 1000

DELHI-P(config-router-af)#neigbor 172.16.16.46 send-com extended

DELHI-P(config-router-af)#address-family vpnv4

DELHI-P(config-router-af)#neighbor 192.168.9.254 activate

DELHI-P(config-router-af)#neighbor 192.168.9.254 next-hop-self

DELHI-P(config-router-af)#neighbor 192.168.9.254 send-com extended

DELHI-P(config-router-af)#end

DELHI-P# wr


Mumbai-P :


MUMBAI-P#conf t

MUMBAI-P(config)#mpls ip

MUMBAI-P(config)#mpls label pro ldp

MUMBAI-P(config)#ip cef distri

MUMBAI-P(config-if)#int gi 7/0/0

MUMBAI-P(config-if)#mpls ip

MUMBAI-P(config-if)#mpls label pro ldp


BRBRAITT : June-2011                                                 136
                     ―DATA NETWORK‖ FOR JTOs PH-II


MUMBAI-P(config-if)#int gi 7/0/1

MUMBAI-P(config-if)#no mpls ip

MUMBAI-P(config-if)#no mpls label pro ldp

MUMBAI-P(config-if)#exit

MUMBAI-P(config)#ip vrf mtnl

MUMBAI-P(config)#rd 9829:1

MUMBAI-P(config)#route-target 9829:1

MUMBAI-P(config)#exit

MUMBAI-P(config)#int gi 7/0/1

MUMBAI-P(config-if)#ip vrf forwarding mtnl

MUMBAI-P(config-if)#ip add 172.16.16.49 255.255.255.252

MUMBAI-P(config-if)#exit



MUMBAI-P(config)#no router ospf 9829

MUMBAI-P(config)#router ospf 9829

MUMBAI-P(config-router)#net 172.16.16.40 0.0.0.3 ar 0

MUMBAI-P(config-router)#net 192.168.9.254 0.0.0.0 ar 0

MUMBAI-P(config-router)#exit

MUMBAI-P(config)#router bgp 9829

MUMBAI-P(config-router)#neighbor 192.168.8.254 remote-as 9829

MUMBAI-P(config-router)#neighbor 192.168.8.254 update lo0

MUMBAI-P(config-router)#address-family ipv4 vrf mtnl

MUMBAI-P(config-router-af)#neigbor 172.16.16.50 remote-as 2000

MUMBAI-P(config-router-af)#neigbor 172.16.16.50 send-com extended

MUMBAI-P(config-router-af)#address-family vpnv4

MUMBAI-P(config-router-af)#neighbor 192.168.8.254 activate

MUMBAI-P(config-router-af)#neighbor 192.168.8.254 next-hop-self



BRBRAITT : June-2011                                                137
                     ―DATA NETWORK‖ FOR JTOs PH-II


MUMBAI-P(config-router-af)#neighbor 192.168.8.254 send-com extended

MUMBAI-P(config-router-af)#end

MUMBAI-P# wr




KOLKATA-PE:

KOLKATA-PE#conf t

KOLKATA-PE(config)#mpls ip

KOLKATA-PE(config)#mpls label pro ldp

KOLKATA-PE(config)#ip cef distri

KOLKATA-PE(config-if)#int gi 2/1

KOLKATA-PE(config-if)#mpls ip

KOLKATA-PE(config-if)#no shut

KOLKATA-PE(config-if)#mpls label pro ldp

KOLKATA-PE(config-if)#int gi 2/2

KOLKATA-PE(config-if)#no shut

KOLKATA-PE(config-if)#no mpls ip

KOLKATA-PE(config-if)#no mpls label pro ldp

KOLKATA-PE(config-if)#exit

KOLKATA-PE(config)#no router ospf 9829

KOLKATA-PE(config)#router ospf 1000

KOLKATA-PE(config-router)#net 172.16.16.16 0.0.0.3 ar 0

KOLKATA-PE(config-router)#net 192.168.0.254 0.0.0.0 ar 0

KOLKATA-PE(config-router)#exit



KOLKATA-PE(config)#router bgp 1000

KOLKATA-PE(config-router)#neighbor 192.168.1.254 remote-as 1000




BRBRAITT : June-2011                                                  138
                     ―DATA NETWORK‖ FOR JTOs PH-II


KOLKATA-PE(config-router)#neighbor 192.168.1.254 update lo0

KOLKATA-PE(config-router)#neighbor 192.168.1.254 next-hop-self

KOLKATA-PE(config-router)#neighbor 192.168.4.254 remote-as 1000

KOLKATA-PE(config-router)#neighbor 192.168.4.254 update lo0

KOLKATA-PE(config-router)#neighbor 192.168.4.254 next-hop-self

KOLKATA-PE(config-router)#neighbor 172.16.16.45 remote-as 9829

KOLKATA-PE(config-router)#neighbor 172.16.16.45 next-hop-self

KOLKATA-PE(config-router)#network 192.168.0.254 mask 255.255.255.255

KOLKATA-PE(config-router)#end

KOLKATA-PE# wr


PUNE-PE:

PUNE-PE#conf t

PUNE-PE(config)#mpls ip

PUNE-PE(config)#mpls label pro ldp

PUNE-PE(config)#ip cef distri

PUNE-PE(config-if)#int gi 2/1

PUNE-PE(config-if)#mpls ip

PUNE-PE(config-if)#no shut

PUNE-PE(config-if)#mpls label pro ldp

PUNE-PE(config-if)#int gi 2/2

PUNE-PE(config-if)#no shut

PUNE-PE(config-if)#no mpls ip

PUNE-PE(config-if)#no mpls label pro ldp

PUNE-PE(config-if)#exit

PUNE-PE(config)#no router ospf 9829

PUNE-PE(config)#router ospf 2000



BRBRAITT : June-2011                                                   139
                     ―DATA NETWORK‖ FOR JTOs PH-II


PUNE-PE(config-router)#net 172.16.16.20 0.0.0.3 ar 0

PUNE-PE(config-router)#net 192.168.2.254 0.0.0.0 ar 0

PUNE-PE(config-router)#exit




PUNE-PE(config)#router bgp 2000

PUNE-PE(config-router)#neighbor 192.168.3.254 remote-as 1000

PUNE-PE(config-router)#neighbor 192.168.3.254 update lo0

PUNE-PE(config-router)#neighbor 192.168.3.254 next-hop-self

PUNE-PE(config-router)#neighbor 192.168.6.254 remote-as 1000

PUNE-PE(config-router)#neighbor 192.168.6.254 update lo0

PUNE-PE(config-router)#neighbor 192.168.6.254 next-hop-self

PUNE-PE(config-router)#neighbor 172.16.16.49 remote-as 9829

PUNE-PE(config-router)#neighbor 172.16.16.49 next-hop-self

PUNE-PE(config-router)#network 192.168.2.254 mask 255.255.255.255

PUNE-PE(config-router)#end

PUNE-PE# wr

GUHAWATI:

GUHAWATI#conf t

GUHAWATI(config)#mpls ip

GUHAWATI(config)#mpls label pro ldp

GUHAWATI(config)#ip cef distri

GUHAWATI(config-if)#int gi 2/1

GUHAWATI(config-if)#mpls ip

GUHAWATI(config-if)#no shut

GUHAWATI(config-if)#mpls label pro ldp

GUHAWATI(config-if)#int gi 2/2


BRBRAITT : June-2011                                                140
                     ―DATA NETWORK‖ FOR JTOs PH-II


GUHAWATI(config-if)#no shut

GUHAWATI(config-if)#mpls ip

GUHAWATI(config-if)#mpls label pro ldp

GUHAWATI(config-if)#exit

GUHAWATI(config)#no router ospf 9829

GUHAWATI(config)#router ospf 1000

GUHAWATI(config-router)#net 172.16.16.32 0.0.0.3 ar 0

GUHAWATI(config-router)#net 172.16.16.16 0.0.0.3 ar 0

GUHAWATI(config-router)#net 192.168.1.254 0.0.0.0 ar 0

GUHAWATI(config-router)#exit



GUHAWATI(config)#router bgp 1000

GUHAWATI(config-router)#neighbor 192.168.0.254 remote-as 1000

GUHAWATI(config-router)#neighbor 192.168.0.254 update lo0

GUHAWATI(config-router)#neighbor 192.168.0.254 next-hop-self

GUHAWATI(config-router)#neighbor 192.168.4.254 remote-as 1000

GUHAWATI(config-router)#neighbor 192.168.4.254 update lo0

GUHAWATI(config-router)#neighbor 192.168.4.254 next-hop-self

GUHAWATI(config-router)#network 192.168.1.254 mask 255.255.255.255

GUHAWATI(config-router)#end

GUHAWATI# wr


AHMEDABAD:

AHMEDABAD#conf t

AHMEDABAD(config)#mpls ip

AHMEDABAD(config)#mpls label pro ldp

AHMEDABAD(config)#ip cef distri



BRBRAITT : June-2011                                                 141
                    ―DATA NETWORK‖ FOR JTOs PH-II


AHMEDABAD(config-if)#int gi 2/1

AHMEDABAD(config-if)#mpls ip

AHMEDABAD(config-if)#no shut

AHMEDABAD(config-if)#mpls label pro ldp

AHMEDABAD(config-if)#int gi 2/2

AHMEDABAD(config-if)#no shut

AHMEDABAD(config-if)#mpls ip

AHMEDABAD(config-if)#mpls label pro ldp

AHMEDABAD(config-if)#exit

AHMEDABAD(config)#no router ospf 9829

AHMEDABAD(config)#router ospf 2000

AHMEDABAD(config-router)#net 172.16.16.20 0.0.0.3 ar 0

AHMEDABAD(config-router)#net 172.16.16.36 0.0.0.3 ar 0

AHMEDABAD(config-router)#net 192.168.3.254 0.0.0.0 ar 0

AHMEDABAD(config-router)#exit



AHMEDABAD(config)#router bgp 1000

AHMEDABAD(config-router)#neighbor 192.168.2.254 remote-as 1000

AHMEDABAD(config-router)#neighbor 192.168.2.254 update lo0

AHMEDABAD(config-router)#neighbor 192.168.2.254 next-hop-self

AHMEDABAD(config-router)#neighbor 192.168.6.254 remote-as 1000

AHMEDABAD(config-router)#neighbor 192.168.6.254 update lo0

AHMEDABAD(config-router)#neighbor 192.168.6.254 next-hop-self

AHMEDABAD(config-router)#network 192.168.3.254 mask 255.255.255.255

AHMEDABAD(config-router)#end

AHMEDABAD# wr




BRBRAITT : June-2011                                                  142
                    ―DATA NETWORK‖ FOR JTOs PH-II


HYDERABAD:

HYDERABAD#conf t

HYDERABAD(config)#mpls ip

HYDERABAD(config)#mpls label pro ldp

HYDERABAD(config)#ip cef distri

HYDERABAD(config)#ip vrf sun

HYDERABAD(config)#rd 1000:1

HYDERABAD(config)#route-target both 1000:1

HYDERABAD(config-if)#int gi 2/1

HYDERABAD(config-if)#no mpls ip

HYDERABAD(config-if)#no shut

HYDERABAD(config-if)#no mpls label pro ldp

HYDERABAD(config-if)#ip vrf forwarding sun

HYDERABAD(config-if)#ip add 172.16.16.25 255.255.255.252

HYDERABAD(config-if)#int gi 2/2

HYDERABAD(config-if)#no shut

HYDERABAD(config-if)#mpls ip

HYDERABAD(config-if)#mpls label pro ldp

HYDERABAD(config-if)#exit

HYDERABAD(config)#no router ospf 9829

HYDERABAD(config)#router ospf 1000

HYDERABAD(config-router)#net 172.16.16.32 0.0.0.3 ar 0

HYDERABAD(config-router)#net 192.168.4.254 0.0.0.0 ar 0

HYDERABAD(config-router)#exit



HYDERABAD(config)#router bgp 1000

HYDERABAD(config-router)#neighbor 192.168.0.254 remote-as 1000


BRBRAITT : June-2011                                             143
                    ―DATA NETWORK‖ FOR JTOs PH-II


HYDERABAD(config-router)#neighbor 192.168.0.254 update lo0

HYDERABAD(config-router)#neighbor 192.168.0.254 next-hop-self

HYDERABAD(config-router)#neighbor 192.168.1.254 remote-as 1000

HYDERABAD(config-router)#neighbor 192.168.1.254 update lo0

HYDERABAD(config-router)#neighbor 192.168.1.254 next-hop-self

HYDERABAD(config-router)#neighbor 192.168.6.254 remote-as 2000

HYDERABAD(config-router)#neighbor 192.168.6.254 ebgp-multihop

HYDERABAD(config-router)#neighbor 192.168.6.254 update lo0

HYDERABAD(config-router)#network 192.168.4.254 mask 255.255.255.255

HYDERABAD(config-router)#address-family ipv4 vrf sun

HYDERABAD(config-router-af)#neighbor 172.16.16.26 remote-as 50

HYDERABAD(config-router-af)#neighbor 172.16.16.26 next-hop-self

HYDERABAD(config-router-af)#exit

HYDERABAD(config-router)#address-family vpnv4

HYDERABAD(config-router-af)#neighbor 192.168.6.254 activate

HYDERABAD(config-router-af)#neighbor 192.168.6.254 next-hop-self

HYDERABAD(config-router-af)#neighbor 192.168.6.254 send-community extended

HYDERABAD(config-router-af)#end

HYDERABAD# wr


BANGALORE:

BANGALORE#conf t

BANGALORE(config)#mpls ip

BANGALORE(config)#mpls label pro ldp

BANGALORE(config)#ip cef distri

BANGALORE(config)#ip vrf sun

BANGALORE(config)#rd 1000:1



BRBRAITT : June-2011                                                   144
                    ―DATA NETWORK‖ FOR JTOs PH-II


BANGALORE(config)#route-target both 1000:1

BANGALORE(config-if)#int gi 2/1

BANGALORE(config-if)#no mpls ip

BANGALORE(config-if)#no shut

BANGALORE(config-if)#no mpls label pro ldp

BANGALORE(config-if)#ip vrf forwarding sun

BANGALORE(config-if)#ip add 172.16.16.29 255.255.255.252

BANGALORE(config-if)#int gi 2/2

BANGALORE(config-if)#no shut

BANGALORE(config-if)#mpls ip

BANGALORE(config-if)#mpls label pro ldp

BANGALORE(config-if)#exit

BANGALORE(config)#no router ospf 9829

BANGALORE(config)#router ospf 2000

BANGALORE(config-router)#net 172.16.16.36 0.0.0.3 ar 0

BANGALORE(config-router)#net 192.168.6.254 0.0.0.0 ar 0

BANGALORE(config-router)#exit



BANGALORE(config)#router bgp 2000

BANGALORE(config-router)#neighbor 192.168.2.254 remote-as 2000

BANGALORE(config-router)#neighbor 192.168.2.254 update lo0

BANGALORE(config-router)#neighbor 192.168.2.254 next-hop-self

BANGALORE(config-router)#neighbor 192.168.3.254 remote-as 2000

BANGALORE(config-router)#neighbor 192.168.3.254 update lo0

BANGALORE(config-router)#neighbor 192.168.3.254 next-hop-self

BANGALORE(config-router)#network 192.168.6.254 mask 255.255.255.255

BANGALORE(config-router)#neighbor 192.168.4.254 remote-as 1000



BRBRAITT : June-2011                                                  145
                     ―DATA NETWORK‖ FOR JTOs PH-II


BANGALORE(config-router)#neighbor 192.168.4.254 ebgp-multihop

BANGALORE(config-router)#neighbor 192.168.4.254 update lo0

BANGALORE(config-router)#address-family ipv4 vrf sun

BANGALORE(config-router-af)#neighbor 172.16.16.30 remote-as 40

BANGALORE(config-router-af)#neighbor 172.16.16.30 next-hop-self

BANGALORE(config-router-af)#exit

BANGALORE(config-router)#address-family vpnv4

BANGALORE(config-router-af)#neighbor 192.168.4.254 activate

BANGALORE(config-router-af)#neighbor 192.168.4.254 next-hop-self

BANGALORE(config-router-af)#neighbor 192.168.4.254 send-community extended

BANGALORE(config-router-af)#end

BANGALORE# wr


CHENNAI-PE:

CHENNAI-PE#conf t

CHENNAI-PE(config)#int lo0

CHENNAI-PE(config-if)#ip add 200.0.0.0 255.0.0.0

CHENNAI-PE(config-if)#int gi 2/1

CHENNAI-PE(config-if)#no mpls ip

CHENNAI-PE(config-if)#no shut

CHENNAI-PE(config-if)#no mpls label pro ldp

CHENNAI-PE(config-if)#int gi 2/2

CHENNAI-PE(config-if)#shut

CHENNAI-PE(config-if)#exit

CHENNAI-PE(config)#no router ospf 9829

CHENNAI-PE(config)#router bgp 50

CHENNAI-PE(config-router)#neighbor 172.16.16.25 remote-as 1000



BRBRAITT : June-2011                                                   146
                    ―DATA NETWORK‖ FOR JTOs PH-II


CHENNAI-PE(config-router)#neighbor 172.16.16.25 next-hop-self

CHENNAI-PE(config-router)#network 192.168.5.254 mask 255.255.255.255

CHENNAI-PE(config-router)#network 200.0.0.0 255.0.0.0

CHENNAI-PE(config-router)#end

CHENNAI-PE# wr


TRIVANDRUM:

TRIVANDRUM#conf t

TRIVANDRUM(config)#int lo0

TRIVANDRUM(config-if)#ip add 100.0.0.0 255.0.0.0

TRIVANDRUM(config-if)#int gi 2/1

TRIVANDRUM(config-if)#no mpls ip

TRIVANDRUM(config-if)#no shut

TRIVANDRUM(config-if)#no mpls label pro ldp

TRIVANDRUM(config-if)#int gi 2/2

TRIVANDRUM(config-if)#shut

TRIVANDRUM(config-if)#exit

TRIVANDRUM(config)#no router ospf 9829

TRIVANDRUM(config)#router bgp 40

TRIVANDRUM(config-router)#neighbor 172.16.16.29 remote-as 2000

TRIVANDRUM(config-router)#neighbor 172.16.16.29 next-hop-self

TRIVANDRUM(config-router)#network 192.168.7.254 mask 255.255.255.255

TRIVANDRUM(config-router)#network 100.0.0.0 255.0.0.0

TRIVANDRUM(config-router)#end

TRIVANDRUM# wr




BRBRAITT : June-2011                                                   147
                  ―DATA NETWORK‖ FOR JTOs PH-II




               LABEL DISTRIBUTION PROTOCOL




BRBRAITT : June-2011                              148
                   ―DATA NETWORK‖ FOR JTOs PH-II




   Label Distribution Protocols
          Label distribution protocol is a set of rules and procedures that one LSR
    can use to inform another LSR about which label will be used to forward MPLS
     traffic between and through them

         The path set up by these bilateral agreement is called label switched path(LSP




    Label Distribution Protocols
          MPLS architecture does not assume a single label distribution protocol.
          A number of protocols have been standarised
               Label Distribution Protocol
                    LDP
               Constraint-based Routing with LDP
                       CR-LDP
               RSVP with TE extensions
                   RSVP-TE
               Distributing labels with BGP-4




BRBRAITT : June-2011                                                  149
                           ―DATA NETWORK‖ FOR JTOs PH-II




    Label Distribution Protocols
    Label distribution protocol is a set of rules and procedures that one LSR can
      use to inform another LSR about which label will be used to to forward
      MPLS traffic between and through them
     The path set up by these bilateral agreement is called label switched path
      (LSP)
    Label Distribution Protocols
       MPLS architecture does not assume a single label distribution protocol.
       A number of protocols have been standarised
         Label Distribution Protocol

            LDP
            


         Constraint-based Routing with LDP

            CR-LDP
            


         RSVP with TE extensions

            RSVP-TE
            


         Distributing labels with BGP-4




                   Labels assigned by downstream peer

                       


                       




BRBRAITT : June-2011                                                   150
                    ―DATA NETWORK‖ FOR JTOs PH-II






    Label Distribution Protocol
       Set of procedures and messages by which LSRs create LSPs through a
        network by mapping network layer routing information directly to data link
        layer switched paths
       LSPs may have their end point
          At a directly attached LSR

          At a network egress LSR i.e. number of LSRs away

       A FEC be defined for each of the LSP
       Each EFC contains one or more FEC elements
       Each element identifies which set of incoming packets will be mapped to an
        LSP at the ingress




    LDP Messages
     LDP communicate using messages
     There are 4 categories of LDP messages
        Discovery Messages

           Announce and maintain the presence of an LSR
            


        Session Messages

           Establish, maintain and terminate session between LDP peers
            


        Advertisement Messages

           Create, change and delete label mappings for FECs
            


        Notification Messages

           Advisory and signal error notification
            




BRBRAITT : June-2011                                                  151
                    ―DATA NETWORK‖ FOR JTOs PH-II






    LDP Messages
       Discovery messages provide a mechanism by which the LSRs indicate their
        presence in a network by sending Hello message periodically
       This is transmitted as a UDP packet
       When an LSR chooses to establish a session with another LSR learned via
        Hello message, uses LDP initialisation procedure over TCP transport
       When multiple sessions are required between two LSRs there is one TCP
        session for each LDP session




    LDP Messages
     Upon successful completion of the initialisation procedure, the two LSRs
      are LDP peers and may exchange advertisement messages
     LDP peers communicate over an LDP session created between them
     An LSP can be viewed as a series of LDP peers and their associated sessions
     Correct operation of LDP requires reliable and in order delivery of messages
        Uses the TCP transport for Session, Advertisement and Notification

         messages(Port-646)
        Uses UDP transport for Discovery messages(Port-646)




BRBRAITT : June-2011                                                 152
                  ―DATA NETWORK‖ FOR JTOs PH-II




   A      LDP          Discovery Msg         Session Msgs


   T                       UDP                    TCP


   N                                    IP


   D                       To/From Physical Layer


LDP Messages




BRBRAITT : June-2011                                    153
                  ―DATA NETWORK‖ FOR JTOs PH-II


LDP Messages & Codes



   S.No.        Message Name                      Message Value
      1.        Notification                      0001H
      2.        Hello                             0100H
      3.        Intialisation                     0200H
      4.        Keep Alive                        0201H
      5.        Address                           0300H
      6.        Address Withdraw                  0301H
      7.        Label Mapping                     0400H
      8.        Label Request                     0401H
      9.        Label Withdraw                    0402H
     10.        Label Release                     0403H
     11.        Label Abort Request               0404H




BRBRAITT : June-2011                                      154
                    ―DATA NETWORK‖ FOR JTOs PH-II




   LDP Message Exchange
     LDP message exchanges are accomplished by sending LDP protocol data
      units (PDUs) over LDP session TCP connections
     Each LDP PDU can carry one or more messages
     Messages in an LDP PDU need not be related to one another



    LDP PDU Message Format
    LDP Header (10Bytes)
       Version(2B)
          Present version is 1

       Length(2B)
          Total PDU length in octets

          Exclusive of the version and length fields

          Negotiated during session intialisation

          Maximum allowable length is 4096 Bytes



    LDP Header (10Bytes)
     LDP Identifier(6B)
     Uniquely identifies the label space of the sending LSR
        Router ID (4B)

           Identifies the LSR and must be a globally unique value

           Router ID is the IP address of this LSR

        Label Space ID (2B)

           Identifies the label space within the LSR




    LDP Message Format
     U bit-Unknown message bit
       Upon receipt of an unknown message, if

           U=0, a notification must be returned to the message originator

           U=1, the unknown message is silently ignored and the rest of message

            is processed

BRBRAITT : June-2011                                                 155
                   ―DATA NETWORK‖ FOR JTOs PH-II




    LDP Messages
     Message Type (15 b)

       Identifies the type of message

     Message Length (2B)
       Length in octets of the Message ID, Mandatory Parameters &

        Optional Parameters
     Message ID (4B)
       Notification messages, if to be sent, in response to this message carry

        this value back in the Status TLV
     Mandatory Parameters-Variable
     Optional Parameters-Variable



    Type-Length-Value Encoding
     LDP messages carry information, encoded in Type-Length-Value (TLV)
      format
        Maximum allowable length is 4096 Bytes




    Type-Length-Value Encoding
     U bit-Unknown TLV bit
       Upon receipt of an unknown TLV, if

           U=0, a notification must be returned to the message originator and
            ENTIRE message must be ignored
           U=1, the unknown TLV is silently ignored and the rest of message is
            processed


       F bit-Forward Unknown TLV bit
          Applies only when U=1, if

             F=0, the unknown TLV is NOT forwarded with the containing
              message
             F=1, the unknown TLV is forwarded with the containing message




BRBRAITT : June-2011                                               156
                     ―DATA NETWORK‖ FOR JTOs PH-II




    Type-Length-Value Encoding
     Type (14b)

        Identifies the various message types

     Length (2B)
        Length in octets of ONLY the value field

     Value-Variable
        String of octets that encodes the information

        TLVs can be nested i.e. Value field itself may contain further TLV

         encodings

    LDP OPERATION
     LDP Discovery
     Session Establishment
     Label Distribution
     Error Notification




    LDP Discovery
     LDP discovery is a mechanism that enables an LSR to discover potential
      LDP peers

          Basic discovery
            To discover LSR neighbors that are directly connected at the link level
            LSR periodically sends LDP link hellos out the interface as UDP
             packets using group multicast address
          Extended discovery
            To discover LSRs that are not directly connected at the link level
            LSR periodically sends LDP targeted hellos as UDP packets to a
             specific address




BRBRAITT : June-2011                                                   157
                  ―DATA NETWORK‖ FOR JTOs PH-II




    Hello Message

     Hold Time-Seconds
        0000-Default time of 15 sec for Link Hello and 45 sec for Targeted

         Hello
        FFFF-Means infinite

     T-Bit-Target Hello Bit
        0-Link Hello

        1-Targeted Hello

     R-Bit-Request Send Target Hello
        0-No Request

        1-Request the receiver to send Target Hello




    LDP Discovery
     LSR receiving hellos from another LSR maintains a hello adjacency
     If the parameters contained in the hello are acceptable
        LSRs proceed for LDP session establishment

     If the parameters contained in the hello are not acceptable
        LSRs ignore it and LDP session can not be established




BRBRAITT : June-2011                                               158
                  ―DATA NETWORK‖ FOR JTOs PH-II




    LDP Session Establishment

     Session establishment is a 2 step process:
        Transport connection establishment

        Session intialisation

     Transport connection establishment
        TCP connection will be established for a new LDP session by the

         Active LSR
        LSRs will compare the Transport Address exchanged in the optional

         parameter of Hellos
        The LSR with greater Transport Address will become Active LSR

        If NO Transport Addresses are negotiated LSR with greater Router

         ID will become Active LSR




    LDP Session Establishment
     Session intialisation
        Active LSR starts negotiating session parameters by exchanging LDP

         intialisation messages
           LDP Protocol version
           Label Distribution Method
           Timer Values etc.
        If the parameters are acceptable the session is established and keep-

         alive messages are periodically exchanged
        If the parameters are NOT acceptable the session can not be

         established and TCP connection is closed




BRBRAITT : June-2011                                              159
                   ―DATA NETWORK‖ FOR JTOs PH-II




    Initialisation Message
     Protocol Version (2B)

        LDP protocol version

     Keep-alive Time (2B)
        Time in seconds that may elapse between the receipt of successive

          PDUs from the LDP peer on the session TCP connection
     A-Bit-Label Advertisement Discipline
        0-Downstream Unsolicited Advertisement

        1-Downstream on demand

     D-Bit-Loop Detection
        0-Loop Detection Disabled

        1-Loop Detection enabled




    Initialisation Message
     PV Limit-Path Vector Limit (1B)
        Configured maximum path vector length

        Must be 0 if loop detection is disabled

     Maximum PDU Length (2B)
        Maximum allowable length for LDP PDUs

        Default is <=255 Octets

        Maximum is 4096 Octets

     Maximum PDU Length (2B)
        Identifies the receiver’s label space

        This together with sender’s LDP identifier in the PDU header

          enables the receiver to match the initialisation message with its hello
          adjacencies




BRBRAITT : June-2011                                                160
                  ―DATA NETWORK‖ FOR JTOs PH-II




    LDP Session Monitoring
     LDP includes mechanism to monitor the integrity of LDP session

     An LSR maintains a Keep-Alive timer for each peer session
     If Keep-Alive timer expires without receipt of an LDP-PDU, LDP session is
      terminated and TCP connection is closed

    Keep Alive Message
     An LSR must arrange that its peer receive an protocol message or a Keep-
      Alive message from it at least every Keep-Alive time




    LDP Identifiers & NH Addresses
     An LSR maintains learned labels in a LIB (Label Information Base)
     When the next hop for a prefix changes the LSR must retrieve the label
      advertised by the new next hop from the LIB for use in forwarding
     To enable LSRs to map between a peer LDP identifier and the peer‘s
      addresses, LSRs advertise their addresses using LDP Address and Address
      Withdraw messages




BRBRAITT : June-2011                                               161
                   ―DATA NETWORK‖ FOR JTOs PH-II




    Address Message
     An LSR sends the address message to advertise the interface address.


    Address Withdraw Message
     An LSR sends to withdraw previously advertised interface addresses



    LDP Label Distribution
     MPLS label distribution and management can be done in 2 ways
        Downstream on Demand Label Distribution

           FEC-Label bindings are distributed in response to an explicit request

            from another LSR
        Downstream Unsolicited

           FEC-Label bindings are distributed to LSRs that have not explicitly

            requested them
     Both of these techniques may be used in the same network at the same time




    LDP Label Distribution
     Each interface on an LSR is configured to operate in either Downstream on
      Demand Label Distribution or Downstream Unsolicited
     For any given session, each LSR must be aware of the label distribution
      method used by its peer
     LSRs exchange advertisement modes during initialisation
     Label Request and Label Mapping messages are exchanged for label
      distribution
     Loop Detection mechanism is used to prevent these messages going into
      loop




BRBRAITT : June-2011                                                 162
                   ―DATA NETWORK‖ FOR JTOs PH-II




    Label Distribution Control Mode
      Label Request of the
     The behavior Messageinitial setup of LSPs is determined by the label

      distribution control mode
        An upstream LSR sends this message to a downstream LDP peer to

        Independent Label Distribution Control for a FEC
         assign and advertise a binding (mapping)
            Mapping may advertise label mappings to its neighbor at any time
     LabelEach LSRMessage
             without waiting for sends mapping from the next hop
        A downstream LSR a label this message to the upstream LSR for a

        Ordered Label Distribution Control
         FEC
            The LSR must wait until a label from a downstream
        An LSR receiving this message should not use LSR is received
                                                                 the label for
             before mapping its routing table corresponding labels to exactly
         forwarding unlessthe FEC and passing contains an entry thatupstream
             LSRs
         matches the FEC element
     Label Abort Request Message
        An upstream LSR sends this message to abort an outstanding Label

         Request Message for FEC sent to downstream LSR
     Label Withdraw Message
        A downstream LSR sends this message to an upstream LSR that the

         peer may not continue to use specific FEC-Label mappings the LSR
         had previously advertised


    Label Retention Mode
          Distribution
     Specifies whether an LSR maintains a label binding for a FEC learned from
      Label Release Message
         An upstream not its next this message to
      aneighbor that is LSR sends hop for the FEC a downstream LSR that the
        Conservative Label Retention Mode
         peer no longer needs specific FEC-Label mappings previously
            Label mapping advertisements of all routes are received from all peers
         requested
          


            detection those mappings will
     Loop but only is a configurable optionbe retained which will be used to
            forward packets
        Path Vector TLV

            A message Retention by an
        Liberal Label propagated Mode LSR adds its LSR ID to the path vector
          


           Label
            list mapping advertisements of all routes are received and retained
           from all receiving a message containing its LSR ID detects for
            An LSR peers regardless of whether the LSR is the next hopthat the
            advertising mapping
            message has traversed a loop
           Also an LSR that detects a path vector has reached the maximum
            configured length treats as if the message has traversed a loop
        Hop Count TLV

           A message propagated by an LSR increments the hop count
           An LSR that detects a hop count has reached the configured value
            treats as if the message has traversed a loop
BRBRAITT : June-2011                                                 163
                     ―DATA NETWORK‖ FOR JTOs PH-II




    Error Notification
     Sent by LSR to inform LDP peer of a significant event

     Two types of Notification Messages
        Error Notification

           Signal fatal errors

               Expiration of a keep-alive timer
               


               Shutdown by a node
               

               Failure of an LSP session initialisation
               




           Advisory Notification
              Outcome of processing an LDP message

              State of the LDP session




    Notification Message
       Status TLV
          Indicates the event being signaled

             Malformed PDU

             Malformed TLV

             Expiry of Session Keep-alive Timer

             Unilateral Session Shutdown ……….




BRBRAITT : June-2011                                          164
                    ―DATA NETWORK‖ FOR JTOs PH-II




    Notification Message
    Notification Message

       Status TLV
          U-Bit

             0-Status TLV is sent in notification message
             1-Status TLV is sent in some other message
          F-Bit

             Same as F-Bit in Status Code field
       Status Code
          E-Bit- Fatal Error Bit

             0-Advisory Notification
             1-Fatal Error Notification
          F-Bit- Forward Bit

             0-Notification should not be forwarded
             1-Notification should be forwarded to the NH LSR




BRBRAITT : June-2011                                             165
                  ―DATA NETWORK‖ FOR JTOs PH-II




                           RSVP-TE




BRBRAITT : June-2011                              166
                        ―DATA NETWORK‖ FOR JTOs PH-II


                      MPLS TRAFFIC ENGINEERING
MPLS Traffic Engineering (MPLS TE) is a growing implementation in today's
service provider networks. MPLS adoption in service provider networks has increased
manifold due to its inherent TE capabilities. MPLS TE allows the MPLS-enabled
network to replicate and expand upon the TE capabilities of Layer 2 ATM and Frame
Relay networks. MPLS uses the reachability information provided by Layer 3 routing
protocols and operates like a Layer 2 ATM network. With MPLS, TE capabilities are
integrated into Layer 3, which can be implemented for efficient bandwidth utilization
between routers in the SP network.

This chapter provides you with information on the operation and configuration of
MPLS TE on Cisco routers.
TE Basics
TE is the process of steering traffic across to the backbone to facilitate efficient use of
available bandwidth between a pair of routers. Prior to MPLS TE, traffic engineering
was performed either by IP or by ATM, depending on the protocol in use between two
edge routers in a network. Though the term "traffic engineering" has attained
popularity and is used more in the context of MPLS TE today, traditional TE in IP
networks was performed either by IP or by ATM.

TE with IP was mostly implemented by manipulation of interface cost when multiple
paths existed between two endpoints in the network. In addition, static routes enabled
traffic steering along a specific path to a destination. Figure outlines a basic IP
network with two customers, A and B, connected to the same service provider.
Figure Traditional IP Networks




As illustrated in Figure, two paths exist between customer routers CE1-A and CE2-A
via the provider network. If all links between the routers in Figure were of equal cost,
the preferred path between customer routers CE1-A and CE2-A would be the one


BRBRAITT : June-2011                                                                   167
                       ―DATA NETWORK‖ FOR JTOs PH-II


with the minimum cost (via routers PE1-AS1, P3-AS1, and PE2-AS1) or PATH1. The
same would apply for the customer routers CE1-B and CE2-B belonging to Customer
B. If all the links were T3 links, for example, in the event of CE1-A sending 45 Mbps
of traffic and CE1-B simultaneously sending 10 Mbps of traffic, some packets will be
dropped at PE1-AS1 because the preferred path for both customers is using PATH1.
The path PATH2 will not be utilized for traffic forwarding; therefore, TE can utilize
this available bandwidth. To implement TE using IP whereby the paths PATH1 and
PATH2 are either load balanced or used equally, we will need to implement IGP
features such as maximum paths with variance or change the cost associated with the
suboptimal path, PATH2, to make it equal to the current optimal path, PATH1. In an
SP environment, this is often cumbersome to implement as the number of routers is
much larger.

With ATM networks, the solution is a lot more feasible; PVCs can be configured
between routers PE1-AS1 and PE2-AS1 with the same cost, but this would create a
full mesh of PVCs between a group of routers. Implementing ATM for TE, however,
has an inherent problem when a link or a node goes down. During link or node failure
used in conjunction with ATM for TE, messages are flooded on the network. The
Layer 3 topology must be predominantly fully meshed to take advantage of the Layer
2 TE implementation. Often, this might prove to be a scalability constraint for the IGP
in use, due to issues with reconvergence at Layer 3.

The main advantage of implementing MPLS TE is that it provides a combination of
ATM's TE capabilities along with the class of service (CoS) differentiation of IP. In
MPLS TE, the headend router in the network controls the path taken by traffic to any
particular destination in the network. The requirement to implement a full mesh of
VCs, as in ATM, does not exist when implementing MPLS TE. Therefore, when
MPLS TE is implemented, the IP network depicted in Figure transforms into the label
switched domain, as shown in Figure, in which the TE label switched paths or TE
tunnels (Tunnel1 and Tunnel2) define paths that can be used by traffic between PE1-
AS1 and PE2-AS1.




BRBRAITT : June-2011                                                               168
                       ―DATA NETWORK‖ FOR JTOs PH-II


MPLS TE




MPLS TE Theory
This section introduces you to the theoretical nuances in the implementation of MPLS
TE. The primary topics covered will be the components of MPLS TE as well as RSVP
and its function in the implementation of MPLS TE.
MPLS TE Overview
In a traditional IP forwarding paradigm, packets are forwarded on a per-hop basis
where a route lookup is performed on each router from source to destination. As cited
earlier, the destination-based forwarding paradigm leads to suboptimal use of
available bandwidth between a pair of routers in the service provider network.
Predominantly, the suboptimal paths are under-utilized in IP networks. To avoid
packet drops due to inefficient use of available bandwidth and to provide better
performance, TE is employed to steer some of the traffic destined to follow the
optimal path to a suboptimal path to enable better bandwidth management and
utilization between a pair of routers. TE, hence, relieves temporary congestion in the
core of the network on the primary or optimal cost links. TE maps flows between two
routers appropriately to enable efficient use of already available bandwidth in the core
of the network. The key to implementing a scalable and efficient TE methodology in
the core of the network is to gather information on the traffic patterns as they traverse
the core of the network so that bandwidth guarantees can be established. As illustrated
in Figure, TE tunnels, Tunnel1 and Tunnel2, can be configured on PE1-AS1 that can
map to separate paths (PATH1, PATH2), enabling efficient bandwidth utilization.

TE tunnels configured on routers are unidirectional. Therefore, to implement
bidirectional TE deployment between routers PE1-AS1 and PE2-AS1 in Figure, a pair
of tunnels must also be configured on PE2-AS1 in addition to Tunnel1 and Tunnel2
configured on PE1-AS1. In an MPLS network, all pertinent tunnel configurations are
always performed or provider edge (PE) routers. The TE tunnels or LSPs will be used
to link the edge routers across the core of the service provider network.



BRBRAITT : June-2011                                                                 169
                       ―DATA NETWORK‖ FOR JTOs PH-II


MPLS TE can also map to certain classes of traffic versus destinations. If Customer A
CE routers are connected into the SP network using OC3 links versus Customer B
connecting into the SP network using a 64 K dialup link, preferential treatment can be
configured on TE tunnels so that TE Tunnel1 can carry Customer A traffic and
Tunnel2 can carry Customer B traffic. This is shown in Figure. Also note that Figure
illustrates tunnels configured on both PE1-AS1 and PE2-AS1.
TE Tunnels Based on Customer CoS




TE tunnels are, thus, data flows between a specific source and destination that might
have properties or attributes associated with them. The attributes associated with a
tunnel, in addition to the ingress (headend) and egress (tailend) points of the network,
can include the bandwidth requirements and the CoS for data that will be forwarded
utilizing this tunnel. Traffic is forwarded along the path defined as the TE tunnel by
using MPLS label switching. Hence, TE tunnels are assigned specific label switched
paths (LSPs) in the network from source to destination, which are usually PE routers.
MPLS LSPs have a one-to-one mapping with TE tunnels, and TE tunnels are not
bound to a specific path through the SP network to a destination PE router. Unless
configured explicitly, TE tunnels can reroute packets via any path through the
network associated with an MPLS LSP. This path might be defined by the IGP used
in the core, which are discussed in the section on MPLS TE extensions.

The primary reason for the implementation of MPLS TE is to control paths along
which traffic flows through a network. MPLS TE also lends itself to a resilient design
in which a secondary path can be used when the primary path fails between two
routers in a network. Data plane information is forwarded using label switching; a
packet arriving on a PE from the CE router is applied labels and forwarded to the
egress PE router. The labels are removed at the egress router and forwarded out to the
appropriate destination as an IP packet.

OSPF or IS-IS with extensions for TE is used to carry information pertaining to the
tunnel configured on a router. The extensions carry information on available resources


BRBRAITT : June-2011                                                                170
                       ―DATA NETWORK‖ FOR JTOs PH-II


for building a tunnel, like bandwidth on a link. As a result, a link that does not have
the requested resources (like bandwidth) is not chosen to be a part of the LSP tunnel
or TE tunnel. Signaling in an MPLS TE environment uses resource reservation
protocol (RSVP) with extensions to support TE tunnel features.

The data plane ingress (headend) router in the MPLS domain requires information
pertaining to the resource availability on all links capable of being a part of the MPLS
TE tunnel. This information is provided by IGPs like OSPF and IS-IS due to the
inherent operation of flooding information about links to all routers in the IGP
domain. In IS-IS, a new TLV (type 22) has been developed to transmit information
pertaining to resource availability and link status in the LS-PDUs. In OSPF, the type
10 LSA provides resource and links status information. When this information is
flooded in IGP updates, the ingress (headend) router gathers information on all the
available resources in the network along with the topology, which defines tunnels
through the network between a set of MPLS-enabled routers.

The inspiration behind MPLS TE is Constraint Based Routing (CBR), which takes
into account the possibility of multiple paths between a specific source/destination
pair in a network. With CBR, the operation of an IP network is enhanced so the least
cost routing can be implemented as well as variables to find paths from a source to
destination. CBR requires an IGP, like OSPF or IS-IS, for its operation. CBR is the
backbone of the TE tunnel definition and is defined on the ingress routers to the
MPLS domain when implementing MPLS TE. Resource availability and link status
information are calculated using a constrained SPF calculation in which factors such
as the bandwidth, policies, and topology are taken into consideration to define
probable paths from a source to destination.

CSPF calculation results with an ordered set of IP addresses that map to next-hop IP
addresses of routers forming an LSP, in turn mapping to the TE tunnel. This ordered
set is defined by the headend router that is propagated to other routers in the LSP. The
intermediate routers, thus, do not perform the function of path selection. RSVP with
TE extensions is used to reserve resources in the LSP path as well as label association
to the TE tunnel. The operation of RSVP for MPLS TE is introduced in the next
section.
RSVP with TE Extensions: Signaling
RSVP reserves bandwidth along a path from a specific source to destination. RSVP
messages are sent by the headend router in a network to identify resource availability
along the path from a specific source to destination. The headend router is always the
source of the MPLS TE tunnel, and the tailend router is the router that functions as the
endpoint for the TE tunnel. After the RSVP messages are sent, the status of routers in
the path (resource availability) information is stored in the path message as it
traverses the network. RSVP, therefore, communicates the requirements of a specific
traffic flow to the network and gathers information about whether the requirements
can be fulfilled by the network.

The four main messages used in implementation of RSVP for TE are the RSVP PATH
message, the RSVP RESERVATION message, RSVP error messages, and RSVP tear
messages. In MPLS TE, RSVP is used to ensure and verify resource availability, as
well as apply the MPLS labels to form the MPLS TE LSP through the routers in the
network:


BRBRAITT : June-2011                                                                171
                       ―DATA NETWORK‖ FOR JTOs PH-II


RSVP PATH message— Generated by the headend router and is forwarded through
the network along the path of a future TE LSP. At each hop, the PATH message
checks the availability of requested resources and stores this information. In our
network, shown in Figure 9-4, the PATH message is generated by Router PE1-AS1,
the headend router, and is forwarded downstream where it checks resource
availability at each hop (P1-AS1 and PE2-AS1). The RSVP PATH message functions
as a label request in MPLS TE domain. Because all TE domains function with
downstream-on-demand label allocation mode, the request to assign a label is
generated at the headend router and propagated downstream.
RSVP PATH and RESERVATION Messages




RSVP RESERVATION message— Created by the tailend router in the MPLS TE
domain and used to confirm the reservation request that was sent earlier with the
PATH messages. In the network depicted in Figure , PE2-AS1 will generate the
RSVP RESERVATION message in response to the PATH message. Therefore,
PATH messages function as reservation requests and RESERVATION messages
function as reservation confirmations for the availability of requested resources. The
RSVP RESERVATION message performs the function of label assignment for a
particular LSP mapping to the TE tunnel. As the MPLS domain label allocation and
distribution is performed downstream-on-demand, the label mapping to a TE LSP is
first generated by the tailend router or egress Edge LSR and then propagated
upstream. This process is repeated at each hop upstream where local labels mapping
to a TE tunnel are assigned and propagated upstream until the headend router is
reached.

RSVP error messages— In the event of unavailability of the requested resources, the
router generates RSVP error messages and sends them to the router from which the
request or reply was received. If Router P1-AS1 is unable to accommodate requested
resources as defined in the PATH message generated by PE1-AS1 (headend router),
the router generates a PATH ERROR (PATHERR) message and sends it to its
upstream LSR PE1-AS1, as depicted in Figure 9-5.




BRBRAITT : June-2011                                                              172
                       ―DATA NETWORK‖ FOR JTOs PH-II


RSVP PATH Error and RESERVATION Error Messages




If the RSVP PATH message successfully reaches the tailend router, the tailend Router
PE2-AS1 generates a RESERVATION message. If in the time lapsed between P1-
AS1 receiving the PATH message from PE1-AS1 to receiving the RESERVATION
message from PE2-AS1, P1-AS1 identifies a lack of resources to confirm the request,
P1-AS1 will send a RESERVATION ERROR (RESVERR) message to its
downstream LSR PE2-AS1 denying the reservation, as depicted in Figure 9-5.

RSVP tear messages— RSVP creates two types of tear messages, namely, the PATH
tear message and the RESERVATION tear message. These tear messages clear the
PATH or RESERVATION states on the router instantaneously. The process of
clearing a PATH or RESERVATION state on a router using tear messages enables
the reuse of resources on the router for other requests. The PATH tear messages are
usually generated in inter-area LSP creation where the inter-area LSP is not
configured to be fast reroutable, and if a link failure occurs within an area, the LSR to
which the failed link is directly attached will generate an RSVP PATH error and an
RESV tear message to the headend. The headend will then generate an RSVP PATH
tear message. The corresponding path option will be marked as invalid for a certain
amount of time and the next path option will be immediately evaluated if it exists.
RSVP Operation in MPLS TE
As mentioned earlier, the result of a CSPF or CBR calculation on the headend router
is an ordered list of IP addresses that identifies the next hops along the path of the TE
tunnel or LSP. This list of routers is computed and is known only to the headend
router that is the source of the TE tunnel. Other routers in the domain do not perform
a CBR calculation. The headend router provides information to the routers in the TE
tunnel path via RSVP signaling to request and confirm resource availability for the
tunnel. RSVP with extensions for TE reserves appropriate resources on each LSR in
the path defined by the headend router and assigns labels mapping to the TE tunnel
LSP.



BRBRAITT : June-2011                                                                 173
                      ―DATA NETWORK‖ FOR JTOs PH-II


The RSVP extensions to enable RSVP use for signaling in an MPLS environment to
implement TE are defined in Table 9-1. The functions of each of these
extensions/objects in the messages are also outlined.

Table RSVP Objects

Object                    Message            Function

LABEL_REQUEST             PATH               Used to request a label mapping to the
                                             TE tunnel or LSP; generated by the
                                             headend router in the PATH message.

LABEL                     RESERVATION        Used to allocate labels mapping to the
                                             TE tunnel or LSP; generated by the
                                             tailend router in the RESERVATION
                                             message and propagated upstream.

EXPLICIT_ROUTE            PATH               Carried in PATH messages and is used
                                             to either request or confirm a specific
                                             path/route for the tunnel.

RECORD_ROUTE              PATH,              Similar to a record option with ICMP
                          RESERVATION        ping. It is added to the PATH or
                                             RESERVATION messages to notify
                                             the originating node about the actual
                                             route/path that the LSP TE tunnel
                                             traverses.

SESSION_ATTRIBUTE PATH                       Used to define specific session
                                             parameters local to the TE LSP tunnel.


During the path setup process for LSP TE tunnels, RSVP messages containing one or
more of these extensions are used to identify the significance of each message type
and its contents.

The path message contains the information outlined in Table

RSVP Objects in Path Message

Object                    Message

SESSION                   Defines the source and the destination of the LSP tunnel.
                          Usually identified by IP addresses of corresponding
                          loopback interfaces on headend and tailend routers.




BRBRAITT : June-2011                                                            174
                        ―DATA NETWORK‖ FOR JTOs PH-II


RSVP Objects in Path Message

Object                     Message

SESSION_ATTRIBUTE Defines the characteristics of the specific LSP tunnel, such
                  as the bandwidth requirements and resources that would
                  need to be allocated to the tunnel.

EXPLICIT_ROUTE             Populated by the list of next hops that are either manually
                           specified or calculated using constraint-based SPF. The
                           previous hop (PHOP) is set to the router's outgoing
                           interface address. The Record_Route (RRO) is populated
                           with the same address as well.

RECORD_ROUTE               Populated with the local router's outgoing interface address
                           in the path of the LSP tunnel.

SENDER_TEMPLATE            In addition to the previously mentioned attributes, the
                           sender template object in the path message depicts the
                           interface address that will be used as the LSP-ID for the
                           tunnel. This value is defined by the headend router.


The steps in the PATH and RESV message propagation in Figure are depicted here:

Step 1. The appropriate values for the fields mentioned in Table 9-1 applied by the
        headend Router PE1-AS1 and the PATH message is sent to the next-hop
        router in the LSP tunnel path.

Step 2. When P1-AS1 receives this PATH message, the router checks the
        EXPLICIT_ROUTE object to see if the next hop is a directly connected
        network. This is checked in the L-bit of the RSVP path message. If the L-bit
        is set, the local router is not directly connected to the next hop in the LSP
        tunnel path. Therefore, the router would perform a constrained-SPF
        calculation to identify the next hop in the tunnel path.

         If the L-bit is unset, the Router P1-AS1 knows that it is directly connected to
         the next hop in the LSP tunnel path. It then removes all entries in the
         EXPLICIT_ROUTE mapping to the local router (P1-AS1) and forwards the
         PATH message to the next hop as defined in the EXPLICIT_ROUTE object.
         In addition, P2-AS1 updates and appends the RECORD_ROUTE object to
         depict the local outgoing interface in the path of the LSP tunnel. Figure 9-6
         depicts the PATH message values as the PATH message is forwarded from
         P1-AS1 to P2-AS1 after the appropriate values are updated. As previously
         mentioned, P1-AS1 removes references to its local interface in the
         EXPLICIT_ROUTE object and adds the outgoing interface in the
         RECORD_ROUTE object.


BRBRAITT : June-2011                                                                175
                             ―DATA NETWORK‖ FOR JTOs PH-II


        RSVP PATH/RESERVATION Messages and Object Values
        [View full size image]




Step 3. The process is repeated at P2-AS1 in which references to its local interface in
        the EXPLICIT_ROUTE object are removed and appends the outgoing
        interface in the RECORD_ROUTE object.

Step 4. After the RSVP PATH message is received by the tailend Router PE2-AS1, it
        triggers the creation of a RESERVATION message. The key concept to note
        is that the label allocation process begins at the tailend router upon
        generation of the RESERVATION message upstream. Therefore, when PE2-
        AS1 generates a RESERVATION message, the router assigns a POP label to
        the LSP tunnel (penultimate hop popping). The RESERVATION message
        now has the RECORD_ROUTE object pointing to the outgoing interface on
        the tailend router toward the headend router. Therefore, the
        RECORD_ROUTE object is reinitiated in the RESERVATION message. The
        values are depicted in Figure 9-6.

Step 5. When this reservation message reaches P2-AS1, the RECORD_ROUTE is
        prepended with the outgoing interface and the local label mapping to the LSP
        is also generated and mapped in the LABEL object. An arbitrary value of 3
        has been depicted for this LABEL value in Figure 9-6.

Step 6. This process is again repeated on P1-AS1 and the RESERVATION message
        is then received by PE1-AS1.

Step 7. When PE1-AS1 receives the RESERVATION message, the
        RECORD_ROUTE identifies the traffic engineered LSP associated to a
        specific bandwidth or resource requirement as defined in the SESSION
        object. The labels mapped to the LSP are thus used as in regular MPLS in
        which a local label is mapped to a next-hop label at each router that now
        maps to an RSVP-learned TE LSP versus a normal LSP.



BRBRAITT : June-2011                                                               176
                       ―DATA NETWORK‖ FOR JTOs PH-II


In the implementation of RSVP for MPLS TE, RSVP with extensions for TE requests
as well as confirms the LSP, reserves resources as requested on all LSP path routers,
and applies MPLS labels to form the MPLS LSP through the network. Note that the
routers store a copy of the PATH request as the request is forwarded to the next-hop
LSR. This information identifies the interface as reservation messages are received on
the same LSR to an egress interface to the headend router. In the next section, you
will be introduced to the constraint-based SPF calculation process and the need for a
link-state protocol to enable MPLS TE dynamically in a service provider core.
Constraint-Based Routing and Operation in MPLS TE
The most important requirement of TE is that the characteristics, as well as resource
availability, on links on the network (in addition to bandwidth that would be used for
cost computations) be propagated across the network to allow efficient choice of
possible TE LSP paths. In link-state routing protocols, the preferred path still
predominantly takes into consideration the bandwidth on the link between any two
routers to compute the cost or metric associated with that path, prior to preferred path
allocation. Enabling the use of link-state routing protocols to efficiently propagate
information pertaining to resource availability in their routing updates is performed by
additional extensions to the actual operation of the link-state routing protocol. The
mechanics of operation of a link-state routing protocol involves the flooding of
updates in the network upon link-state or metric change or, in better terms, bandwidth
availability from a TE perspective. The resource attributes are flooded by the routers
in the network to make them available by the headend router in the TE tunnel during
LSP path computation (dynamic tunnels). Link-state announcements carry
information that lists that router's neighbors, attached networks, network resource
information, and other relevant information pertaining to the actual resource
availability that might be later required to perform a constraint-based SPF calculation.
OSPF and IS-IS have been provided with extensions to enable their use in an MPLS
TE environment to propagate information pertaining to resource availability and in
dynamic LSP path selection.
Maximum Versus Available Bandwidth
Available bandwidth (AB) is a key value taken into consideration during the LSP path
computation process to identify the preferred path for the TE tunnel. The available
bandwidths on interfaces are configured on a priority basis. The number of priorities
that can be configured in conjunction with the available bandwidth is 8: 0–7, where 0
represents the highest priority. When the available bandwidth for a certain priority
level on an interface is configured, it is subtracted from the available bandwidth on
all priority levels below the one it is configured on.

If Router PE1-AS1 has a serial interface (T1-1.544 Mbps), 1 Ethernet interface (10
Mbps) and one Fast Ethernet interface (100 Mbps), the actual bandwidths on the
interfaces map to the maximum bandwidth (MB) values on the respective links. The
available bandwidth is usually the bandwidth of the required reservation subtracted
from the maximum bandwidth. However, this does not hold true if the available
bandwidth value on the link is configured to be higher than the maximum bandwidth
value on the link. Though the available bandwidth on the link can be configured to be
higher than the max-bandwidth value, reservations exceeding the maximum
bandwidth value are rejected.




BRBRAITT : June-2011                                                                177
                        ―DATA NETWORK‖ FOR JTOs PH-II


When Router PE1-AS1 initially propagates information on the maximum bandwidth
and the available bandwidth on all its links, the values for the available bandwidth at
each priority level (P) for each link would be equal to their maximum bandwidth
values (1.544 Mbps for serial, 10 Mbps for Ethernet, and 100 Mbps for Fast Ethernet).

When a tunnel request is accepted and the bandwidth deducted from the available
bandwidth at a certain priority, it is also deducted from all the priorities lower than the
priority at which the resource request was performed. If an LSP tunnel creation on
PE1-AS1 consumes 40 Mbps of bandwidth on the Fast Ethernet interface at a priority
level of 5, the available bandwidth values at the appropriate priorities on the Fast
Ethernet interface would change for priorities 5 and above (100 – 40 = 60 Mbps).

Let us now consider the following sequence of requests:
   1. Request for 10 Mbps of bandwidth on Ethernet interface at priority 1
   2. Request for 20 Mbps of bandwidth on Fast Ethernet interface at priority 0
   3. Request for 1 Mbps of bandwidth on serial interface at priority 0
   4. Request for 2 Mbps of bandwidth on Ethernet interface at priority 3
This sequence will reduce the AB values, as depicted in Table 9-3.
PE1-AS1: Maximum Bandwidth and Available Bandwidth—All Interfaces

          AB     AB     AB     AB     AB     AB     AB     AB
          P = 0 P = 1 P = 2 P = 3 P = 4 P = 5 P = 6 P = 7
Interface (Mbps) (Mbps) (Mbps) (Mbps) (Mbps) (Mbps) (Mbps) (Mbps)

Serial     1.544 - 1.544 - 1.544 - 1.544 - 1.544 - 1.544 - 1.544 - 1.544 -
           1     = 1     = 1     = 1     = 1     = 1     = 1     = 1     =
           .544    .544    .544    .544    .544    .544    .544    .544

Ethernet 10          10 - 10 10 - 10 10 - 10 10 - 10 10 - 10 10 - 10 10 - 10
                     =0      =0      =0      =0      =0      =0      =0

Fast     100 - 100 - 100 - 100 - 100 - 60 - 20 60 - 20 60 - 20
Ethernet 20 = 80 20 = 80 20 = 80 20 = 80 20 = 80 = 40 = 40 = 40


The outputs of Table do not reflect the request for 2 Mbps of bandwidth on the
Ethernet interface at priority 3. This request is rejected due to unavailable bandwidth
at this priority level on the interface when the request is received. Link-state updates
pertaining to resource availability are flooded when the status of the link changes,
during manual reconfiguration of parameters mapping to the resource availability on
the link, periodic updates on links and their status, and when the LSP path setup fails
due to unavailability of requested resources for the LSP TE tunnel.

If the resources pertaining to the link change constantly, it will trigger update
generation, which clearly must be avoided. During the instant when the resources


BRBRAITT : June-2011                                                                   178
                       ―DATA NETWORK‖ FOR JTOs PH-II


pertaining to the links change constantly, the headend router might view the link as a
probable link in the LSP path. Therefore, this probable nonupdated link might be used
in path computation even though the link might not have the resources required for
LSP path setup. However, after LSP path computation when the LSP path
establishment is attempted, the router containing the link with the unavailable
resources generates an update with information affirming a lack of resources.

Thresholds can be set up on a per interface or link basis on a router whereby updates
are generated within a configured range of resource availabilities. Therefore, the
upper limit, as well as the lower limit, when an update will be generated on the router
containing the link, can be configured. For example, if the lower limit was configured
to be 50% of link bandwidth with steps at 60, 70, 80, and 90 with the upper limit
configured at 100%, updates with regards to link resource availability are generated
and flooded in the network when 50%, 60%, 70%, 80%, 90%, and 100% of
bandwidth are achieved.
Constraint-Based SPF
In the normal SPF calculation process, a router places itself at the head of the tree
with shortest paths calculated to each of the destinations, only taking into account the
least metric or cost route to the destination.

During regular SPF operation in the network, illustrated in Figure 9-7, only the cost is
taken into consideration, and the least cost path from a loopback on PE1-AS1 to a
loopback on PE2-AS1 is PE1-AS1->P1-AS1->PE2-AS1. In this calculation, a key
concept to note is no consideration to the bandwidth of the links on the other paths
from PE1-AS1 to PE2-AS1, namely via routers P3-AS1->P4-AS1 and P2-AS1. The
bandwidth of the links is shown as an ordered pair in Figure 9-7 with the first value
showing the cost of the link and the second showing the bandwidth across the link.
SPF




If the parameters chosen for the preferred path are not the least cost alone but also a
requirement to support a bandwidth of 50 Mbps in Figure 9-7, we can eliminate the


BRBRAITT : June-2011                                                                179
                       ―DATA NETWORK‖ FOR JTOs PH-II


links that do not allow for the mentioned requirement. The network capable of
supporting the requirement would look like what's shown in Figure 9-8.
CSPF




With the just mentioned constraints, the only path capable of being used as an LSP for
TE is the path from PE1-AS1 to PE2-AS1 via P3-AS1 and P4-AS1. If any of the links
between P1-AS1, P2-AS1, and PE2-AS1 were to support a bandwidth more than the
requirement, they would become a part of the CSPF tree structure with Router PE1-
AS1 or the headend router as the root of the tree.

With CSPF, we use more than the link cost to identify the probable paths that can be
used for TE LSP paths. The decision as to which path is chosen to set up a TE LSP
path is performed at the headend router after ruling out all links that do not meet a
certain criteria, such as bandwidth requirements in addition to the cost of the link. The
result of the CSPF calculation at the headend router is an ordered set of IP addresses
that maps to the next-hop addresses of routers that form the TE LSP. Therefore,
multiple TE LSPs could be used by the use of CSPF to identify probable links in the
network that meet the criteria. In addition, the user can configure a static TE tunnel or
LSP on the headend router that outlines the next hops in the TE LSP path and,
therefore, can use the statically defined LSP as the backup LSP path in the event of
the primary TE LSP failing.

The result of the CSPF calculation is then passed over to the RSVP process to begin
the RSVP request and reservation process, as mentioned in the earlier section. RSVP
thus is used along with the result computed by CSPF or list of next hops configured
by the user for LSP signaling and final establishment of the TE LSP. Note the TE LSP
formed as a result of this process is unidirectional in nature.

Constraint-based SPF can use either administrative weights or IGP metric (also called
TE metric) during the constraint-based computation. In the event of a tie, the path


BRBRAITT : June-2011                                                                 180
                       ―DATA NETWORK‖ FOR JTOs PH-II


with the highest minimum bandwidth takes precedence, followed by the least number
of hops along the path. If all else is equal, CSPF picks a path at random and chooses
the same to be the TE LSP path of preference.

Therefore, the sequence of steps in the creation of an MPLS TE tunnel LSP in the
network is as follows:

Step 1.    CSPF calculation is performed from the headend router based on the
           constraints defined in the tunnel definition and requirements. This
           calculation is performed by the IGP in use, either OSPF or IS-IS.

Step 2.    After the LSP path is calculated using the CSPF process, the output of the
           CSPF process, which is an ordered set of IP addresses mapping to next-
           hop addresses in the TE LSP, is passed to RSVP.

Step 3.    RSVP now performs the resource reservation request and confirmation on
           the LSP, as defined by the CSPF process, to determine if the LSP meets
           the requirements of the specific resources requested by the tunnel
           definition.

Step 4.    After the RSVP process receives a reservation message, it signals that the
           LSP is now established.

Step 5.    At this juncture, the TE tunnel is available for the IGP to use. By default,
           the tunnel information is not added into the routing table; however, the
           router can be configured so that the tunnel interface is added to the routing
           table. You will be introduced to the configurations involved for TE on
           Cisco routers in the next section.

Link admission control performs a check at each hop in the desired LSP path to see if
the resources requested are available prior to TE tunnel creation. The link admission
control function is performed on a per hop basis with each router in the LSP path
checking resource availability. If the requested resources are available, bandwidth is
reserved and the router waits for the RESERVATION message to confirm this
resource allocation. If, however, the resources requested are unavailable, the IGP in
use sends messages stating resource unavailability. Link admission control then
informs RSVP about lack of resources, and RSVP sends PATHERR messages to the
headend requesting the resources and notifying a lack of resources.

When setting up TE LSP paths in link admission control, it is important that the
priorities assigned to the available bandwidths are checked. Therefore, if the
requested bandwidth is in use by a lower priority session (priorities 0–7, with 0
having highest priority), the lower priority session can be preempted. If preemption is
supported, each preempted reservation leads to creation of PATHERR and RESVERR
messages because the preempted session no longer fits the profile of the resource
allocation.
OSPF Extension for MPLS TE
OSPF can be used as the link-state protocol of choice in MPLS TE for resource
allocation information flooding through the network by implementing OSPF


BRBRAITT : June-2011                                                                181
                      ―DATA NETWORK‖ FOR JTOs PH-II


extensions or Opaque LSAs. The type of Opaque LSA in use is defined by the
flooding scope of the LSA. OSPF also now possesses TLV and sub-TLV attributes
that can be configured to propagate resource availability information in link-state
routing updates.

Opaque LSAs are of Type 9, 10, and 11 and differ in the flooding scope. Type 9 LSAs
are not flooded beyond the local subnet and are of link-local scope. Type 10 LSAs are
not flooded beyond the ABR and have an area-local scope. Type 11 LSAs are flooded
throughout the autonomous system (AS). Cisco currently supports only Type 10 LSAs
that have area-local scopes and are flooded within the area.

The Type 10 LSA, which is used in MPLS TE, has a number of TLV and sub-TLV
values that map to specific resources in a TE domain. Figure 9-9 depicts the TLV and
sub-TLV values and the appropriate values that they map to enable OSPF use for
MPLS TE.




BRBRAITT : June-2011                                                             182
                       ―DATA NETWORK‖ FOR JTOs PH-II


OSPF TLV/Sub-TLV TE Extensions




The most important sub-TLV values pertaining to TE are 6, 7, and 8. Values for sub-
TLVs 6 and 7 are received from the RSVP configuration on the specific interface.
Sub-TLV 8 defines the bandwidth available for reservation on each of the eight
priorities. The value for sub-TLV 8 is received from the reservations active on the
specific interface.
IS-IS Extensions for MPLS TE
Similar to OSPF, IS-IS can also be used as the link-state protocol of choice in the TE
domain. IS-IS with extensions and newly defined TLVs can be used to propagate
information pertaining to resource allocation in an MPLS TE domain. The following
TLVs have been defined for the use of IS-IS as the link-state IGP in a MPLS TE
domain:
      TLV22: Extended IS reachability— This TLV propagates information about
       the state of links in the network and allows the use of "wide" metrics. In
       addition, this TLV provides information on resource availability, like link
       bandwidths.
      TLV134: Router ID— This TLV is used to identify the router with a distinct
       IP address, usually a loopback address. The source and destination IP
       addresses used to identify and define the tunnel endpoints must match the
       router ID.
      TLV135: Extended IP reachability— This TLV uses "wide" metrics and
       determines if a prefix is a level-1 or level-2 prefix. It also allows the flagging
       of routes when a prefix is leaked from level 2 into level 1.
In addition to the just mentioned TLVs, sub-TLVs have been defined that affix
information pertaining to TE resource allocations to updates. Each sub-TLV consists
of three octets except those explicitly mentioned in Figure 9-10. Most of the sub-
TLVs are defined in draft-ietf-isis-traffic-xx.txt. Figure 9-10 depicts the TLVs and
sub-TLVs in use by IS-IS to support MPLS TE functionality.




BRBRAITT : June-2011                                                                 183
                       ―DATA NETWORK‖ FOR JTOs PH-II


IS-IS TLV/Sub-TLVs for MPLS TE




The key TLVs to note are Sub-TLV 6 and 8, which map to the tunnel endpoints or
source and destination IP addresses that are usually loopback addresses; Sub-TLV 9
and 10, which map to the RSVP settings on a specific interface; and Sub-TLV 11,
which maps to the unreserved bandwidth per priority on an interface after current
resource allocations for active sessions have been established.
Configuring MPLS TE
This section introduces you to the steps involved in the configuration of Cisco routers
to implement MPLS TE. The first subsection identifies the stepwise procedure
involved in the configuration of Cisco routers for TE. It is then followed by a
subsection depicting the actual configuration process on a topology consisting of six
routers in which multiple paths can be used for TE purposes from a headend to tailend
router.




BRBRAITT : June-2011                                                               184
                             ―DATA NETWORK‖ FOR JTOs PH-II


MPLS TE Configuration Flowchart
The configuration of Cisco routers for MPLS TE support can be described in a
systematic flowchart as depicted in the top row of Figure..It is assumed that the
network is already configured with an IGP for NLRI exchange as well as MPLS
forwarding on the appropriate interfaces prior to performing the following steps:

Step 1. Configure a loopback interface for tunnel association to the TE tunnel, as
        depicted in Figure
        MPLS TE Configuration: Step 1




Step 2. The next step is the first configuration performed in relevance to enabling TE
        on the Cisco router. Figure 9-12 outlines the configurations performed on the
        Cisco router to enable TE functions globally on the router as well as interfaces
        that are possible candidates to be chosen for TE LSP paths.
         MPLS TE Configuration: Step 2
        [View full size image]




Step 3. Configure RSVP bandwidth parameters that will be used on the interface for
        signaling purposes and resource allocation for traffic engineered sessions.
        Figure outlines the configurations that need to be performed on the interface.




BRBRAITT : June-2011                                                               185
                       ―DATA NETWORK‖ FOR JTOs PH-II


        Figure 9-13. MPLS TE Configuration: Step 3




Step 4. After the interfaces that can be chosen to be a part of the LSP have been
        enabled for TE as well as RSVP parameters configured, the next step is to
        configure the tunnel interface. The main configurations of the tunnel interface
        would be association of the tunnel interface IP address to the loopback address
        configured earlier, the mode of the tunnel operation, and the destination
        address of the tunnel endpoint, which would map to the IP address of a
        loopback on the tailend router as well as the process by which the tunnel LSP
        path is chosen. In this step, if the path chosen for the LSP is done using the
        IGP and CSPF, the path option is chosen to be dynamic. Figure depicts the
        configuration involved in setting up the tunnel interface.
        Figure 9-14. MPLS TE Configuration: Step 4




Step 5. In addition to using the IGP for LSP path setup, the user can also define an
        explicit-path that will be used for the TE LSP. This optional step can be
        performed on the headend router so that the dynamic tunnel can be chosen to
        be the tunnel of choice for traffic forwarding and the explicit-path tunnel or
        user-defined static tunnel can be the backup path. In some cases, load
        balancing can also be achieved between the two types. Figure depicts the
        configurations to set up an explicit-path LSP.



BRBRAITT : June-2011                                                              186
                       ―DATA NETWORK‖ FOR JTOs PH-II




        MPLS TE Configuration: Step 5




Step 6. By default, the tunnel interface is not announced into the IGP for use in the
        routing table. This will have to be configured explicitly for the tunnel interface
        to be used as the next hop in the routing table by the IGP. Figure outlines the
        configurations that will have to be performed on the headend router to enable
        tunnel interface use as the next-hop address in the routing table for TE.
        MPLS TE Configuration: Step 6




Step 7. The final step in the configuration of MPLS TE is the configuration of the IGP
        for TE support. The IGP in use can be either OSPF or IS-IS. The IGP process
        used for TE is the same as what's defined for NLRI reachability. The
        configurations involved for enabling TE extensions for both these protocols
        are outlined in Figure 9-17.




BRBRAITT : June-2011                                                                 187
                       ―DATA NETWORK‖ FOR JTOs PH-II


        MPLS TE Configuration: Step 7




Configuring Dynamic Paths and Explicit Paths with MPLS TE
Figure outlines the layout of the devices in the network that will be used to configure
MPLS TE using dynamic and explicit paths. Prior to the following configurations, the
devices shown in Figure are configured with appropriate IP addresses on the
interfaces as well as OSPF as the IGP. In addition, MPLS forwarding has been
enabled on all interfaces in the network, as shown in Figure
MPLS TE Configuration Topology




BRBRAITT : June-2011                                                               188
                      ―DATA NETWORK‖ FOR JTOs PH-II


The following steps show how to configure dynamic paths and explicit paths with
MPLS TE:

Step 1.   Configure a loopback interface for tunnel association. This IP address can
          be used as the router ID in the various processes on the router (see
          Example
          Configure Loopback Interface for Tunnel Association
          PE1-AS1(config)#interface loopback 0

          PE1-AS1(config-if)# ip address 10.10.10.101 255.255.255.255

Step 2.   Enable TE globally on the router and per interface. Because we want the
          headend router to take all links in the network as possible links for LSP
          path setup, this interface-specific configuration is performed on all links in
          the network topology shown in Figure. Only the configuration pertaining
          to PE1-AS1 is shown in Example .

          Enable TE on the Router and per Interface

          PE1-AS1(config)#mpls traffic-eng tunnels

          PE1-AS1(config)#interface serial 2/0

          PE1-AS1(config-if)#mpls traffic-eng tunnels

          PE1-AS1(config-if)#interface serial 3/0

          PE1-AS1(config-if)#mpls traffic-eng tunnels

          PE1-AS1(config-if)#interface serial 4/0

          PE1-AS1(config-if)#mpls traffic-eng tunnels

Step 3.   Configuring RSVP bandwidth parameters—Because we have chosen to
          include all interfaces in the network topology to be considered for LSP
          path setup, this configuration is performed on all interfaces. The chosen
          RSVP bandwidth configured on all interfaces is 256 K with the maximum
          that can be allotted to a single flow also 256 K. The configuration of
          headend Router PE1-AS1 is shown in Example
          Configure RSVP Parameters per Interface
          PE1-AS1(config)#interface serial 2/0

          PE1-AS1(config-if)#ip rsvp bandwidth 256 256

          PE1-AS1(config-if)#interface serial 3/0

          PE1-AS1(config-if)#ip rsvp bandwidth 256 256




BRBRAITT : June-2011                                                                189
                      ―DATA NETWORK‖ FOR JTOs PH-II


          PE1-AS1(config-if)#interface serial 4/0

          PE1-AS1(config-if)#ip rsvp bandwidth 256 256

Step 4.   Configuring tunnel interface parameters on the headend router—On
          headend Router PE1-AS1, the tunnel destination is the loopback on Router
          PE2-AS1 (10.10.10.103). First, dynamic tunnels are configured in which
          the IGP performs a CSPF calculation and identifies the appropriate LSP
          path. Therefore, the path-option for this tunnel creation would be
          dynamic. The tunnel is defined with a priority of 1 and a bandwidth
          requirement of 100 K. In addition, the tunnel is also provided a setup and
          hold priority of 1 to define that this is the most preferred tunnel LSP in the
          domain. See Example

          Configure Tunnel Interface Parameters on PE1-AS1

          PE1-AS1(config)#interface Tunnel0

          PE1-AS1(config-if)# ip unnumbered Loopback0

          PE1-AS1(config-if)# tunnel destination 10.10.10.103

          PE1-AS1(config-if)# tunnel mode mpls traffic-eng

          PE1-AS1(config-if)# tunnel mpls traffic-eng priority 1 1

          PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 100

          PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic

Step 5.   Configuring dynamic tunnel announcement into IGP—In this step, the
          tunnel interface is configured to be added into the IGP routing table to
          enable traffic forwarding along the tunnel. See Example
          Announce Tunnel Interface into IGP
          PE1-AS1(config)#interface Tunnel0

          PE1-AS1(config-if)#tunnel mpls traffic-eng autoroute announce

Step 6.   Configure explicit-path tunnel—In this step, an explicit-path tunnel
          named LSP1 is configured via P2-AS1 between PE1-AS1 and PE2-AS1.
          Configure the tunnel interface with appropriate parameters. The tunnel is
          configured with association to the same loopback address as used earlier
          with the same destination address on PE2-AS1. The resource requirements
          of the tunnel are also maintained. However, the tunnel priorities are
          configured to be 2 versus 1 in the prior dynamic tunnel configuration so
          that the dynamic tunnel is not chosen over the explicit tunnel for
          establishing primary LSP. Also, the path-option maps to the name of an
          explicit-path are configured on the headend router that maps to next-hop
          addresses in the LSP path. See Example.



BRBRAITT : June-2011                                                                190
                     ―DATA NETWORK‖ FOR JTOs PH-II


          Configure Tunnel Interface on PE1-AS1
          PE1-AS1(config)#interface Tunnel1

          PE1-AS1(config-if)# ip unnumbered Loopback0

          PE1-AS1(config-if)# tunnel destination 10.10.10.103

          PE1-AS1(config-if)# tunnel mode mpls traffic-eng

          PE1-AS1(config-if)# tunnel mpls traffic-eng priority 2 2

          PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 100

          PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit
          name LSP1

Step 7.   Configure the explicit-path with next-hop IP addresses of routers in the
          LSP path, as depicted in Example .
          Configuration of Explicit LSP Path
          PE1-AS1(config)#ip explicit-path name LSP1

          PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.10

          Explicit Path name LSP1:

          1: next-address 10.10.10.10

          PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.14

          Explicit Path name LSP1:

          1: next-address 10.10.10.10

          2: next-address 10.10.10.14

          PE1-AS1(cfg-ip-expl-path)#next-address 10.10.10.103

          Explicit Path name LSP1:

          1: next-address 10.10.10.10

          2: next-address 10.10.10.14

          3: next-address 10.10.10.103

Step 8.   Configure the tunnel interface to be announced into IGP to be the preferred
          path for traffic engineered traffic in the domain. See Example
          Announce Tunnel Interface into IGP
          PE1-AS1(config)#interface Tunnel1



BRBRAITT : June-2011                                                             191
                          ―DATA NETWORK‖ FOR JTOs PH-II




             PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce

Step 9.      Enable IGP for MPLS TE—The configurations on Router PE1-AS1 to
             enable OSPF for MPLS TE are shown in Example. The router ID
             configured under the MPLS TE module in OSPF and IS-IS is the loopback
             interface on the local router. This configuration needs to be performed on
             all routers in the TE domain.

             Configure IGP for MPLS TE

             PE1-AS1(config)#router ospf 100

             PE1-AS1(config-router)#mpls traffic-eng area 0

             PE1-AS1(config-router)#mpls traffic-eng router-id loopback 0
Verification of MPLS TE Tunnel Creation
The following steps outline the various commands that can be entered on PE1-AS1
(after the just mentioned configuration) to determine if the TE tunnel has been created
successfully on the router (headend):

Step 1. Perform a show mpls traffic-eng tunnels brief on the headend Routers PE1-
        AS1 and P1-AS1 in the LSP path, as well as the tailend Router PE2-AS1 to
        verify the tunnel state is up/up. The output of the command also gives us
        information on the LSP path in the tunnel setup. UP IF defines the upstream
        interface for the tunnel, and DOWN IF defines the downstream interface for
        the tunnel. See Example .

          Example show mpls traffic-eng tunnels brief on Tunnel LSP Path Routers

          PE1-AS1#show mpls traffic-eng tunnels brief

          Signalling Summary:

            LSP Tunnels Process:           running

            RSVP Process:                  running

            Forwarding:                    enabled

            Periodic reoptimization:       every 3600 seconds, next in 3206 seconds

            Periodic FRR Promotion:         Not Running

            Periodic auto-bw collection:    every 300 seconds, next in 206 seconds




BRBRAITT : June-2011                                                                  192
                      ―DATA NETWORK‖ FOR JTOs PH-II


      TUNNEL NAME                           DESTINATION              UP IF     DOWN IF
      STATE/PROT

      PE1-AS1_t0                   10.10.10.103    -       Se3/0     up/up

      PE1-AS1_t1                   10.10.10.103    -       Se2/0     up/up

      Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails

      ________________________________________________________________
      ______________

      P1-AS1#show mpls traffic-eng tunnels brief

      Signalling Summary:

        LSP Tunnels Process:           running

        RSVP Process:                  running

        Forwarding:                    enabled

        Periodic reoptimization:       every 3600 seconds, next in 2951 seconds

        Periodic FRR Promotion:         Not Running

        Periodic auto-bw collection:    every 300 seconds, next in 251 seconds

      TUNNEL NAME                           DESTINATION              UP IF     DOWN IF
      STATE/PROT

      PE1-AS1_t0                   10.10.10.103    Se2/0     Se4/0     up/up

      Displayed 1 (of 1) heads, 1 (of 1) midpoints, 0 (of 0) tailsPE2-AS1#show mpls
      traffic-eng tunnels brief

      Signalling Summary:

        LSP Tunnels Process:           running

        RSVP Process:                  running

        Forwarding:                    enabled

        Periodic reoptimization:        every 3600 seconds, next in 2857 seconds

        Periodic FRR Promotion:          Not Running

        Periodic auto-bw collection:    every 300 seconds, next in 157 seconds




BRBRAITT : June-2011                                                               193
                      ―DATA NETWORK‖ FOR JTOs PH-II


       TUNNEL NAME                           DESTINATION             UP IF      DOWN IF
       STATE/PROT

       PE1-AS1_t0                   10.10.10.103      Se3/0    -     up/up

       PE1-AS1_t1                   10.10.10.103      Se2/0    -     up/up

Step 2. A view of the actual parameters of the tunnel can be retrieved by performing a
        show mpls traffic-eng tunnels destination ip-address (only Tunnel 0 depicted
        in Example ) or a show mpls traffic-eng tunnels tunnel interface-number. As
        illustrated in Example , the output shows the status of the tunnel and the
        information about the parameters associated with the tunnel. In addition, it
        shows the preferred path chosen by the CSPF process under the explicit-path
        field in the output of the command, as shaded in Example

       Example MPLS TE Verification: Tunnel Parameters

       PE1-AS1#show mpls traffic-eng tunnels destination 10.10.10.103

       Name: PE1-AS1_t0                            (Tunnel0) Destination: 10.10.10.103

       Status:

       Admin: up       Oper: up      Path: valid      Signalling: connected

       path option 1, type dynamic (Basis for Setup, path weight 20)

       Config Parameters:

        Bandwidth: 100      kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF

        Metric Type: TE (default)

        AutoRoute: enabled LockDown: disabled Loadshare: 100                 bw-based

        auto-bw: disabled

        Active Path Option Parameters:

        State: dynamic path option 1 is active

        BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

        InLabel : -

        OutLabel : Serial3/0, 26

        RSVP Signalling Info:

        Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71




BRBRAITT : June-2011                                                                    194
                      ―DATA NETWORK‖ FOR JTOs PH-II




      RSVP Path Info:

      My Address: 10.10.10.101

      Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103

      Record Route: NONE

      Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

       RSVP Resv Info:

       Record Route:     NONE

       Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

       History:

       Tunnel:

       ime since created: 3 hours, 42 minutes

       Time since path change: 33 minutes, 26 seconds

       Current LSP:

       Uptime: 33 minutes, 26 seconds

      PE1-AS1#show mpls traffic-eng tunnels tunnel 0

      Name: PE1-AS1_t0                          (Tunnel0) Destination: 10.10.10.103

      Status:

      Admin: up        Oper: up   Path: valid      Signalling: connected

      path option 1, type dynamic (Basis for Setup, path weight 20)

      Config Parameters:

      Bandwidth: 100       kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF

      Metric Type: TE (default)

      AutoRoute: enabled LockDown: disabled Loadshare: 100             bw-based




BRBRAITT : June-2011                                                              195
                        ―DATA NETWORK‖ FOR JTOs PH-II


      Au

      to-bw: disabled

      Active Path Option Parameters:

      State: dynamic path option 1 is active

      BandwidthOverride: disabled LockDown: disabled Verbatim: disabled

      InLabel : -

      OutLabel : Serial3/0, 26

      RSVP Signalling Info:

      Src 10.10.10.101, Dst 10.10.10.103, Tun_Id 0, Tun_Instance 71

      RSVP Path Info:

      My Address: 10.10.10.101

      Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103

      Record Route: NONE

      Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

      RSVP Resv Info:

      Record Route: NONE

      Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits

      Shortest Unconstrained Path Info:

      Path Weight: 20 (TE)

      Explicit Route: 10.10.10.2 10.10.10.6 10.10.10.103

      History:

      Tunnel:

      Time since created: 3 hours, 42 minutes

      Time since path change: 33 minutes, 47 seconds




BRBRAITT : June-2011                                                      196
                        ―DATA NETWORK‖ FOR JTOs PH-II


       Current LSP:

       Uptime: 33 minutes, 47 seconds

Step 3. Verify that the next hop to the destination IP address points to the tunnel
        interfaces in the IGP routing table. Only routes to network 10.10.10.103
        (destination) pointing to the tunnel interface as the next hop are shown for
        brevity. See Example 9-12. Because we have two tunnels configured on Router
        PE1-AS1 (dynamic and explicit) with the same parameters, the traffic to
        destination 10.10.10.103 is load balanced equally among the two paths, as
        shown in, because the bandwidths configured on the TE tunnels are the same.
        Traffic from PE1-AS1 to PE2-AS1 is equally load balanced across the two
        tunnels.

       Example. Verify Next-Hop Mapping to Tunnel Interface (Truncated)

       PE1-AS1#show ip route 10.10.10.103

       Routing entry for 10.10.10.103/32

       Known via "ospf 100", distance 110, metric 97, type intra area

       Routing Descriptor Blocks:

       directly connected, via Tunnel0

        Route metric is 97, traffic share count is 1

        directly connected, via Tunnel1

        Route metric is 97, traffic share count is 1

Step 4. By performing an extended ping to the destination loopback address on PE2-
        AS1, we see that the packets are load balanced across the two tunnel paths. See
        Example

       Example Extended Ping Verification for MPLS TE Tunnel Path

       PE2-AS1#ping

       Protocol [ip]:

       Target IP address: 10.10.10.103

       Repeat count [5]: 2

       Datagram size [100]:

       Timeout in seconds [2]:

       Extended commands [n]: y



BRBRAITT : June-2011                                                              197
                       ―DATA NETWORK‖ FOR JTOs PH-II




      Source address or interface: 10.10.10.101

      Type of service [0]:

      Set DF bit in IP header? [no]:

      Validate reply data? [no]:

      Data pattern [0xABCD]:

      Loose, Strict, Record, Timestamp, Verbose[none]: r

      Number of hops [ 9 ]: 4

      Loose, Strict, Record, Timestamp, Verbose[RV]:

      Sweep range of sizes [n]:

      Type escape sequence to abort.

      Sending 2, 100-byte ICMP Echos to 10.10.10.103, timeout is 2 seconds:

      Reply to request 0 (28 ms). Received packet has options

      Total option bytes= 40, padded length=40

      Record route:

      (10.10.10.103)

      (10.10.10.6)

      (10.10.10.2)

      (10.10.10.101) <*>

      End of list

      Reply to request 1 (28 ms). Received packet has options

      Total option bytes= 40, padded length=40

      Record route:

      (10.10.10.103)

      (10.10.10.14)




BRBRAITT : June-2011                                                          198
                         ―DATA NETWORK‖ FOR JTOs PH-II


         (10.10.10.10)

         (10.10.10.101) <*>

         End of list
Final Configurations for Dynamic and Explicit Tunnels with MPLS TE
Example and Example outline the final configurations for all devices in Figure for
implementation of dynamic and explicit tunnels from PE1-AS1 to PE2-AS1.
Example Final Configurations for PE1-AS1 and PE2-AS1 to Implement Dynamic
and Explicit Tunnels
hostname PE1-AS1

!

ip cef

!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.101 255.255.255.255

!

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 10.10.10.103

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng path-option 1 dynamic

tunnel MPLS traffic-eng bandwidth 100

!

interface Tunnel1



BRBRAITT : June-2011                                                          199
                       ―DATA NETWORK‖ FOR JTOs PH-II


ip unnumbered Loopback0

tunnel destination 10.10.10.103

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 2 2

tunnel mpls traffic-eng path-option 1 explicit name LSP1

tunnel MPLS traffic-end bandwidth 100

!

interface Serial2/0

ip address 10.10.10.9 255.255.255.252

mpls traffic-eng tunnels

tag-switching ip

fair-queue 64 256 48

ip rsvp bandwidth 1000

!

interface Serial3/0

ip address 10.10.10.1 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

interface Serial4/0

ip address 10.10.10.17 255.255.255.252

mpls traffic-eng tunnels

MPLS ip



BRBRAITT : June-2011                                       200
                       ―DATA NETWORK‖ FOR JTOs PH-II


ip rsvp bandwidth 1000

!

router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.0.0.0 0.255.255.255 area 0

!

ip explicit-path name LSP1 enable

next-address 10.10.10.10

next-address 10.10.10.14

next-address 10.10.10.103

!

end


hostname PE2-AS1

!

ip cef

!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.103 255.255.255.255

!

interface Serial2/0

ip address 10.10.10.14 255.255.255.252

mpls traffic-eng tunnels


BRBRAITT : June-2011                                   201
                      ―DATA NETWORK‖ FOR JTOs PH-II



mpls ip

ip rsvp bandwidth 1000

!

interface Serial3/0

ip address 10.10.10.6 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

interface Serial4/0

ip address 10.10.10.22 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.0.0.0 0.255.255.255 area 0

!

end

Example 9-15. Final Configurations for P1-AS1, P2-AS1, and P3-AS1 to Implement
Dynamic and Explicit Tunnels
hostname P1-AS1

!




BRBRAITT : June-2011                                                      202
                       ―DATA NETWORK‖ FOR JTOs PH-II


ip cef

!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.102 255.255.255.255

!

interface Serial2/0

ip address 10.10.10.2 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

interface Serial3/0

ip address 10.10.10.26 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

interface Serial4/0

ip address 10.10.10.5 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!



BRBRAITT : June-2011                                   203
                       ―DATA NETWORK‖ FOR JTOs PH-II


router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.0.0.0 0.255.255.255 area 0

!

end


hostname P2-AS1

!

ip cef

!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.104 255.255.255.255

!

interface Serial2/0

ip address 10.10.10.10 255.255.255.252

mpls traffic-eng tunnels

MPLS ip

ip rsvp bandwidth 1000

!

interface Serial3/0

ip address 10.10.10.13 255.255.255.252

mpls traffic-eng tunnels

mpls ip


BRBRAITT : June-2011                                   204
                       ―DATA NETWORK‖ FOR JTOs PH-II



ip rsvp bandwidth 1000

!

router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.0.0.0 0.255.255.255 area 0

!

end

hostname P3-AS1

!

ip cef

!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.105 255.255.255.255

!

interface Serial2/0

ip address 10.10.10.18 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

interface Serial3/0

ip address 10.10.10.25 255.255.255.252


BRBRAITT : June-2011                                   205
                       ―DATA NETWORK‖ FOR JTOs PH-II



no ip directed-broadcast

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

interface Serial4/0

ip address 10.10.10.21 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 1000

!

router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.0.0.0 0.255.255.255 area 0

!
end

Unequal Cost Load Balancing Across Multiple TE Tunnels
In this section, we will configure another tunnel via the path PE1-AS1, P3-AS1, and
PE2-AS1 with bandwidth requirements of 50 kbps versus 100 kbps. In every five
packets, load balancing is performed so that two packets are sent on Tunnel 0, two on
Tunnel 1, and one packet on Tunnel 2. In this case, if the source and destination of the
tunnel interfaces are the same, the traffic between the sites performs unequal cost load
balancing among the various tunnels between Routers PE1-AS1 and PE2-AS1. The
configuration on PE1-AS1 (headend router) for another explicit LSP path setup via
the path PE1-AS1, P3-AS1, and PE2-AS1 is shown in Example
Example Unequal Cost Load Balancing Configuration on PE1-AS1
PE1-AS1(config)#interface Tunnel2

PE1-AS1(config-if)# ip unnumbered Loopback0

PE1-AS1(config-if)# tunnel destination 10.10.10.103


BRBRAITT : June-2011                                                                206
                       ―DATA NETWORK‖ FOR JTOs PH-II



PE1-AS1(config-if)# tunnel mode mpls traffic-eng

PE1-AS1(config-if)# tunnel mpls traffic-eng autoroute announce

PE1-AS1(config-if)# tunnel mpls traffic-eng priority 3 3

PE1-AS1(config-if)# tunnel mpls traffic-eng bandwidth 50

PE1-AS1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name LSP2

PE1-AS1(config)#ip explicit-path name LSP2 enable

PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.18

Explicit Path name LSP2:

  1: next-address 10.10.10.18

PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.22

Explicit Path name LSP2:

  1: next-address 10.10.10.18

  2: next-address 10.10.10.22

PE1-AS1(cfg-ip-expl-path)# next-address 10.10.10.103

Explicit Path name LSP2:

  1: next-address 10.10.10.18

  2: next-address 10.10.10.22

  3: next-address 10.10.10.103

PE1-AS1(cfg-ip-expl-path)#end

After the configuration is performed, the output of the routing table entry for
10.10.10.103/32 shows the unequal cost load balancing in effect (see Example).
Example. Verification of Unequal Cost Load Balancing
PE1-AS1#show ip route 10.10.10.103

Routing entry for 10.10.10.103/32

 Known via "ospf 100", distance 110, metric 97, type intra area

 Routing Descriptor Blocks:



BRBRAITT : June-2011                                                           207
                           ―DATA NETWORK‖ FOR JTOs PH-II


 * directly connected, via Tunnel0

   Route metric is 97, traffic share count is 2

  directly connected, via Tunnel1

   Route metric is 97, traffic share count is 2

  directly connected, via Tunnel2

   Route metric is 97, traffic share count is 1

Therefore, the final configuration for PE1-AS1 includes, in addition to Example 9-14,
the configuration shown in Example.
Example . Additional Configuration on PE1-AS1 for Unequal Cost Load
Balancing
interface Tunnel2

ip unnumbered Loopback0

no ip directed-broadcast

tunnel destination 10.10.10.103

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 3 3

tunnel mpls traffic-eng bandwidth 50

tunnel mpls traffic-eng path-option 1 explicit name LSP2

MPLS TE Fast ReRoute Link Protection
Fast ReRoute (FRR) is a procedure used in conjunction with MPLS TE to reroute
around a link in the case of link failure. Protection in networks can be provided by
SONET, optical protection, or, more recently, MPLS FRR. With MPLS FRR, we can
implement both link and node protection. In addition, different protection policies can
be applied to different classes of traffic traversing the MPLS backbone. In FRR
operation, a backup tunnel is configured to be used if the primary tunnel LSP fails.
The backup tunnel must be configured so that the LSP can get to the next-hop LSR
downstream without attempting to use the failed link.

The configuration for implementing FRR for link protection is simple to implement.
If you use a subset of the network shown in Figure 9-18 to implement link protection,
as illustrated in Figure 9-19, you can configure a backup tunnel on the LSR P1-AS1.
If the primary tunnel from PE1-AS1 via P1-AS1 to PE2-AS1 fails due to link failure
between P1-AS1 and PE2-AS1, the backup tunnel is used to forward traffic.




BRBRAITT : June-2011                                                               208
                      ―DATA NETWORK‖ FOR JTOs PH-II


Figure MPLS FRR Network Topology, Configuration, and Verification




Configuration of the tunnel (Tunnel0 on PE1-AS1) to be protected from a link failure
includes the tunnel mpls traffic-eng fast-reroute command under the tunnel
interface configuration on the headend router (PE1-AS1) to enable FRR protection on
the tunnel. In addition, a backup tunnel, Tunnel100, is configured on the downstream
LSR (in our case, P1-AS1) to reroute traffic if the link between P1-AS1 and PE2-AS1
fails. Configuration is performed following the procedure shown in the earlier
sections with an explicit path from P1-AS1 to PE2-AS1 via P3-AS1. Finally, this
tunnel (Tunnel100) on P1-AS1 is associated to the link to be protected by using the
command mpls traffic-eng backup-path tunnel tunnel100 under the interface to be
protected (Serial 4/0 on P1-AS1).

Verification of FRR capabilities can be performed by issuing the show mpls traffic-
eng fast-reroute database detail command on the downstream LSR configured with
a backup tunnel, as shown in Figure .
Implementing MPLS VPNs over MPLS TE
MPLS was initially adopted due to its inherent properties to deliver VPNs. However,
in recent years, MPLS TE has gained popularity due to the robust TE capabilities it
provides. In this section, we will discuss the configurations involved in the
implementation of MPLS VPN over TE tunnels. TE tunnels can be configured
between PE to PE routers as well as from PE to provider core or P routers. The
configurations involved in both of these implementations of MPLS TE in the provider



BRBRAITT : June-2011                                                            209
                      ―DATA NETWORK‖ FOR JTOs PH-II


core are introduced. The network used to implement MPLS VPN over TE tunnels is
shown in Figure
MPLS VPN Over TE Network Topology/Configuration




For simplicity, the OSPF PE-CE connectivity implementation is used on both PE
Routers PE1-AS1 and PE2-AS1 in Figure. For this section, the IGP used in the core is
OSPF with process-id 100. The process-id for the PE to CE connections is configured
under OSPF 1. All networks are in area 0.

The configurations on Routers P1-AS1, CE1-A, and CE2-A are illustrated in Figure
9-20. Configurations for PE1-AS1 and PE2-AS1 are illustrated in Example 9-19. A
tunnel is already configured with a dynamic path-option between PE1-AS1 and PE2-
AS1.
PE1-AS1 and PE2-AS1 Configuration: MPLS VPN Over TE with PE to PE Tunnels
hostname PE1-AS1

!

ip cef

!

ip vrf VPNoverTE

rd 1:100

route-target export 1:100

route-target import 1:100



BRBRAITT : June-2011                                                            210
                       ―DATA NETWORK‖ FOR JTOs PH-II


!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.101 255.255.255.255

!

interface Tunnel0

ip unnumbered Loopback0

tunnel destination 10.10.10.103

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 1 1

tunnel mpls traffic-eng bandwidth 100

tunnel mpls traffic-eng path-option 1 dynamic

!

interface Serial2/0

ip vrf forwarding VPNoverTE

ip address 172.16.1.1 255.255.255.252

!

interface Serial3/0

ip address 10.10.10.1 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 256 256

!



BRBRAITT : June-2011                                   211
                       ―DATA NETWORK‖ FOR JTOs PH-II


router ospf 1 vrf VPNoverTE

redistribute bgp 100 metric 10 subnets

network 172.16.1.0 0.0.0.3 area 0

!

router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.10.10.0 0.0.0.3 area 0

network 10.10.10.101 0.0.0.0 area 0

!

router bgp 100

bgp router-id 10.10.10.101

neighbor 10.10.10.103 remote-as 100

neighbor 10.10.10.103 update-source Loopback0

no auto-summary

!

address-family vpnv4

neighbor 10.10.10.103 activate

neighbor 10.10.10.103 send-community extended

exit-address-family

!

address-family ipv4 vrf VPNoverTE

redistribute ospf 1 vrf VPNoverTE metric 2

exit-address-family

!



BRBRAITT : June-2011                                   212
                       ―DATA NETWORK‖ FOR JTOs PH-II


end

hostname PE2-AS1

!

ip cef

!

ip vrf VPNoverTE

rd 1:100

route-target export 1:100

route-target import 1:100

!

mpls traffic-eng tunnels

!

interface Loopback0

ip address 10.10.10.103 255.255.255.255

!

interface Serial3/0

ip address 10.10.10.6 255.255.255.252

mpls traffic-eng tunnels

mpls ip

ip rsvp bandwidth 256 256

!

interface Serial4/0

ip vrf forwarding VPNoverTE

ip address 172.16.2.1 255.255.255.252

!



BRBRAITT : June-2011                                   213
                       ―DATA NETWORK‖ FOR JTOs PH-II


router ospf 1 vrf VPNoverTE

redistribute bgp 100 metric 2 subnets

network 172.16.2.0 0.0.0.3 area 0

!

router ospf 100

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

network 10.10.10.4 0.0.0.3 area 0

network 10.10.10.103 0.0.0.0 area 0

!

router bgp 100

bgp router-id 10.10.10.103

neighbor 10.10.10.101 remote-as 100

neighbor 10.10.10.101 update-source Loopback0

!

address-family vpnv4

neighbor 10.10.10.101 activate

neighbor 10.10.10.101 send-community extended

exit-address-family

!

address-family ipv4 vrf VPNoverTE

redistribute ospf 1 vrf VPNoverTE metric 2

exit-address-family

!

end



BRBRAITT : June-2011                                   214
                       ―DATA NETWORK‖ FOR JTOs PH-II


Verification of MPLS VPN over TE with PE to PE Tunnels
Outlines the various verification steps for identifying the operation of MPLS VPNs
over TE with PE to PE tunnels.
MPLS VPN over TE Verification—PE to PE Tunnels




Figure illustrates the routing tables on CE routers in which the CE routers learn the
routes from the remote CEs via the MPLS backbone and place them in their local
routing tables as OSPF IA routes, though all CE routes are in area 0 because sham-
links are not configured.

Figure also shows the routing table on the respective PE routers for the VRF
VPNoverTE to check for route propagation in the MPLS VPN domain. As can be
derived from the output, the appropriate VPN routes obtained from the remote CEs
are learned from the next hop that maps to the remote PE loopback.
A closer look at the prefix 172.16.1.102 (loopback0 on CE2-A), learned across the
MPLS domain one PE1-AS1, indicates a next-hop address of the remote PE loopback
10.10.10.103 (lo0 on PE2-AS1). In the global routing table, if this VPN forwards
traffic over the MPLS TE tunnel configured on PE1-AS1, the next-hop address of
10.10.10.103 must point to the tunnel interface (Tunnel0) as shown in Figure 9-21 by
the output of show ip route 10.10.10.103 on PE1-AS1. In addition, note that in the
label-stack imposed on the packets in the MPLS domain when implementing MPLS
VPN over TE (one label for MPLS VPN and the top label for TE), the top label maps
to the label assigned by RSVP for the traffic engineered LSP path. Therefore, the out-
label value in the output of show MPLS traffic-eng tunnels tunnel0 (16) maps to the



BRBRAITT : June-2011                                                              215
                       ―DATA NETWORK‖ FOR JTOs PH-II


top label in the label stack, as highlighted in the output of show ip cef vrf
VPNoverTE 172.16.1.102 in Figure
For final verification of connectivity, an extended ping is performed between
loopback interfaces on CE routers, as shown in Figure .
Configuration of MPLS VPN over TE with PE to P Tunnels
In the preceding section, MPLS VPN was configured over TE tunnels in which the
TE tunnel was configured between the two PE routers in the MPLS domain. Another
possibility that might arise while deploying MPLS VPN over a TE enabled domain is
a tunnel existing between a PE router and a provider core router. In our existing setup,
the tunnel interface, Tunnel 0, configured on the PE Router PE1, is changed so that
the destination of the tunnel is the loopback address on P1 or 10.10.10.102/32 (see
Example ). This configuration might be used in conjunction with FRR to enable link
protection in the SP backbone for MPLS forwarded traffic belonging to a customer.
Example Configuration on PE1-AS1: Tunnel Destination Changed to
10.10.10.102/32
PE1-AS1(config)#interface tunnel 0

PE1-AS1(config-if)# tunnel destination 10.10.10.102
If no other changes in configuration are made on any router, the CE routers no longer
have connectivity to one another because the LSP is broken, as shown in Example
Example CE1-AS1 Cannot Reach CE2 Because LSP Is Broken
CE1-AS1#ping 172.16.1.102 source 172.16.1.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.102, timeout is 2 seconds:
Success rate is 0 percent (0/5)
To enable a complete LSP, MPLS is enabled on the tunnel interface on PE1-AS1.
Also, P1-AS1 is configured to accept directed hellos, as shown in Example
Example Enabling MPLS on the Tunnel Interface and Configuring Directed-
Hello Accept on P1-AS1
PE1-AS1(config)#interface tunnel 0
PE1-AS1(config-if)#mpls ip
P1-AS1(config)#mpls ldp discovery targeted-hello accept
Because the P1-AS1 router can accept directed hellos from neighbors who are not
directly connected, the LSP is now established using the tunnel. This is shown in
Figure where the next hop for the remote CE loopback interfaces point to the interface
tunnel 0 on PE1-AS1.




BRBRAITT : June-2011                                                                216
                       ―DATA NETWORK‖ FOR JTOs PH-II


MPLS VPN Over TE Verification—PE to P Tunnels




Connectivity between CE routers is verified using extended pings between loopback
interfaces on CE routers, as shown in Figure

Command Reference

Command                                      Description

Router(config)#mpls traffic-eng tunnels      Configures TE support on router in
                                             the global configuration mode.

Router(config-if)#mpls traffic-eng tunnels   Configures MPLS TE support per
                                             interface.

Router(config-if)# ip   rsvp   bandwidth Configures RSVP bandwidth on the
{reservable bandwidth 1-10000000 kbps} interface-reserved bandwidth with the
{maximum reservable bandwidth per flow 1- largest reservable bandwidth/flow.
1000000 kbps}

Router(config)#interface tunnel {number}     Configures tunnel interface.

Router(config-if)#ip unnumbered loopback Configures the loopback interface IP
{number}                                 address to be associated with the
                                         tunnel interface under tunnel interface
                                         configuration.




BRBRAITT : June-2011                                                         217
                        ―DATA NETWORK‖ FOR JTOs PH-II


Command                                          Description

Router(config-if)#tunnel mode mpls traffic- Configures the tunnel mode to be an
eng                                         MPLS traffic-engineered tunnel.

Router(config-if)#tunnel destination        {IP Configures the MPLS traffic-
address of remote loopback}                     engineered tunnel's destination or end-
                                                point.

Router(config-if)#tunnel mpls traffic-eng        Configures the LSP path setup to be
path-option {priority} dynamic [bandwidth        done by IGP and CSPF (dynamic LSP
{override bandwidth config value} | attributes   tunnel creation). The tunnels can be
{lsp attribute list name} | lockdown]            configured with the associated priority
                                                 and attributes.

Router(config)#    ip      explicit-path   name Configures an explicit path to be
{name} enable                                   associated with a TE tunnel.

or

Router(config)# ip explicit-path identifier
{number} enable

Router(cfg-ip-expl-path)#next-address       {ip- Configures the IP next-hop addresses
address}                                         for the explicit MPLS traffic
                                                 engineered tunnel.
Router(cfg-ip-expl-path)#exit

Router(config-if)#tunnel mpls traffic-eng Defines the priority of the tunnel
priority {setup priority-value} {hold-priority (used in load balancing).
value}

Router(config-if)#tunnel      mpls    traffic-eng Configures tunnel interface to be
autoroute announce                                announced into IGP routing table
                                                  (configured under tunnel interface
                                                  configuration).

Router(config-router)#mpls traffic-eng area Enables OSPF for TE (under router
number                                      OSPF configuration).

Router(config-router)#mpls            traffic-eng Configures the router ID for the TE
router-id interface number                        process under OSPF or IS-IS.

Router(config-router)#mpls traffic-eng level Configures    IS-IS         Level1/Level2
[1 | 2]                                      domains for TE.



BRBRAITT : June-2011                                                                218
                      ―DATA NETWORK‖ FOR JTOs PH-II


Command                                    Description

Router(config-router)#metric-style wide    Configures IS-IS to accept and use
                                           enhanced TLVs (wide metrics).

Router(config-if)# tunnel mpls traffic-eng Enables the MPLS tunnel for FRR
fast-reroute                               protection.

Router(config-if)# mpls traffic-eng backup- Configures the backup tunnel to be
path tunnel {interface-number}              used during interface failure.




BRBRAITT : June-2011                                                      219
                       ―DATA NETWORK‖ FOR JTOs PH-II



                        LAYER 3 VPN SERVICES

Layer 3 VPN Services

Layer 3 VPN is without doubt the MPLS application that has caused the most ink to
flow. RFC 2547 proposes a peer architecture in which customer edge (CE) routers
exchange routes with service provider edge routers (universally called PE, for
provider edge). Unlike a Frame Relay or ATM VPN service, there are no point-to-
point connections between customer sites.

Figure shows an MPLS-VPN reference architecture, with two different VPNs.
Customer sites have a CE router that connects to service provider PE routers. PE
devices are connected by LSRs. A single PE can peer with CEs that belong to
different customers, as is the case for PE A. To provide backup routes, a CE can also
peer with different PEs that belong to the same, or even to different, service providers.
Sites in a VPN can communicate only with other sites in the same VPN. Standard IP
traffic runs over the CE-PE link, so this link cannot be shared with other customer
traffic. (By the way, that is a very important point: The CE and PE do not exchange
labels, or labeled packets.) This is identical to existing Layer 2 VPN networks, so an
MPLS-VPN service requires no architecture change to the customer's network.

MPLS-VPN Reference Architecture




Even though each site has just one link into the service provider cloud, thanks to the
MPLS-VPN architecture, there can be a full-mesh connectivity between the sites. In
fact, the intersite IP topology can be of arbitrary complexity. MPLS-VPN
implementations default to full mesh and must be constrained to provide a more
hierarchical connectivity model, such as hub and spoke.

The MPLS-VPN model makes it easier to route between CEs, compared to the costly
approach of using dedicated WAN connections between sites and the relative



BRBRAITT : June-2011                                                                 220
                       ―DATA NETWORK‖ FOR JTOs PH-II


difficulty of routing effectively over such point-to-point networks.

For CEs to communicate, the service provider needs to exchange (private and
possibly overlapping) customer IP routes and carry packets to those routes across its
network. MPLS provides a solution that supports customer address-space
independence using a forwarding mechanism that uses a two-label hierarchy in which
the inner label identifies the VPN and the outer label identifies the destination PE
device. RFC 2547 mandates the use of the Border Gateway Protocol (BGP) to
exchange prefixes and labels between PE devices and introduces some new attributes
to provide this functionality.

Speaking of BGP, how are customer routes advertised in an MPLS-VPN network?
Figure 4-13 shows that several different routing protocols are used. The following
sequence explains the operation behind Figure

Routing in an MPLS VPN Network




CE red1 advertises the 192.168.4.0/24 prefix to PE A. A CE can use static or dynamic
routing (RIP, eBGP, or OSPF) to exchange routes with a PE. CE red1 runs eBGP. CE
green2 uses RIPv2.

PE A imports the prefixes announced by the CE into the route table for this VPN. If
other interfaces on the same PE belong to the same VPN, routes are announced to the
local peers. Each VPN has its own routing table.

PE A uses iBGP to announce reachability for each of its attached customer sites. In
Figure PE A has one iBGP session with PE C for the red VPN and another with PE D
for the green VPN. PE C imports the routes into the routing table used for the red
VPN, and PE D imports the routes for the green VPN. The PEs are in a full iBGP
mesh and each can run many different VPNs.

PE C announces the 192.168.4.0 route to CE red2 using RIPv2. A show ip route



BRBRAITT : June-2011                                                             221
                       ―DATA NETWORK‖ FOR JTOs PH-II


command on CE red2 will show 192.168.4.0/24 with a next hop of 192.168.2.1,
which is the address of PE C. Similarly, CE red1 has an entry for 192.168.3.0 with a
next hop of 192.168.1.2. PE A's routing table for the red VPN has an entry for
192.168.4.0 through 192.168.1.1 and another entry for 191.168.3.0 with a next hop
that points to PE C. This is where the MPLS-VPN magic occurs. PE C announces
itself as the next hop for the 192.168.3.0 route. Because this is a BGP route, PE A will
use another lookup to find the route and, this time, the next hop will be 10.0.0.2,
which is the LSR.

When traffic must go between sites, the CE forwards IP packets to the PE as it would
to any other router. Figure shows a packet going from CE green1 to CE green2,
following this sequence:

PE A identifies the next hop (PE D) for this packet as a BGP neighbor.

PE A first imposes a label, 22, that will identify the VPN routing table to PE D. This
label was advertised by the neighbor, PE D, during the exchange of BGP prefixes,
which happened some time before the preceding step.

The packet must now travel across the MPLS network, so PE A imposes another
label, 96, that identifies the next-hop LSR on the IGP path to PE D. This label was
advertised by the downstream LSR (LSR B) from 10.0.0.2.

Each LSR in the core swaps labels and forwards the packet as normal toward PE D.
The penultimate hop pops the outer label. In Figure 4-14, there is only one hop to the
egress LSR, so LSR B removes the outer label.

PE D uses the remaining label, 22, to identify which VPN routing table to use for the
packet, and then pops the label from the packet.

PE D does an IP lookup in the VPN routing table to find the outgoing interface and
then forwards the IP packet to CE green2, which will route it to its destination.

Packet Flow in MPLS-VPN Network




BRBRAITT : June-2011                                                                222
                         ―DATA NETWORK‖ FOR JTOs PH-II


It is very important to understand that the LSRs have no visibility of the VPN traffic.
They forward labeled traffic along LSPs established by whatever routing protocol is
running in the service provider core. Of course, this IGP can be completely different
from the IGPs running on the CE-PE links.

MPLS-VPN Attributes

Defining an MPLS VPN is harder than you might expect. For the longest time, the
Cisco IOS implementation had no single number or string that would define a VPN in
a network. Fortunately, a VPN ID has since been introduced to address this problem.

Note that every VPN on a Cisco router has the following attributes:

Dedicated interfaces, which can be logical or physical

Dedicated routing table

A local name and, optionally, a numeric ID

Rules that determine how VPN routes are advertised to peer routers

Route reachability within an MPLS VPN is established through the selective import
of BGP routes. Several new extended attributes have been added to BGP in
accordance with the specifications in RFC 2547. Figure shows how PEs exchange
these attributes.

iBGP Attribute Exchange

[View full size image]




The following are the most important BGP attributes:



BRBRAITT : June-2011                                                               223
                        ―DATA NETWORK‖ FOR JTOs PH-II


route-target Each PE defines a numeric value, called a route-target, that is associated
to all the routes it exports to its BGP peers. PEs also define another value used to filter
incoming routes. In order for a route to be accepted, the route-target export value must
match the import value at the receiving device. Note that the import and export values
do not have to match, which allows topologies other than full mesh to be defined. The
route-targets are carried in BGP updates. In Figure, PE A uses 100:1 for both export
and import route-targets. PE C uses the same values, so routes from the red VPN sites
will be exchanged between these two routers.

route-distinguisher A BGP attribute that is appended to private routes to make them
globally unique. Consider a case in which two networks each use the 10.0.0.0/24
prefix and connect to the same service provider PE. The PE uses different virtual
routing tables because the prefixes belong to different customers, so there is no
conflict in address space when importing the routes into the service provider network.
Now every PE that connects to a CE in the customer's VPN must receive reachability
information for the 10.0.0.0/24 prefix. The PE announces the route to all its PE peers,
but only those with the same VPN and matching route-target import it. The route-
distinguisher (RD) is included in the routing exchange to make sure that each BGP
peer treats the prefixes as belonging to different networks. Returning to Figure , the
red VPN uses an RD of 100:1; the green VPN is configured for 200:1. Although not
necessary, having the same RD throughout a VPN is better, for operational simplicity.

MPLS-VPNs require private routing tables in each VPN so that they can peer with the
CEs in the different domains. In Cisco jargon, these are called VRFs, as shown in
Figure , and the standard routing table is called the global routing table. In the
example given that described the operation of Figure, the VPN routing tables
referenced in the text are VRFs.

VRFs




VRFs are populated by routing processes associated with each VPN. Note that in


BRBRAITT : June-2011                                                                   224
                          ―DATA NETWORK‖ FOR JTOs PH-II


other implementations, separate processes run in each VPN, but Cisco IOS does a mix
of both. BGP, for example, is a single process across the whole router, but there are
independent OSPF processes for each VPN. LFIBs are populated using information
from VRFs.

Even though each VPN on a PE router has its very own VRF, no VRFs are required
on CE routers. (There is an optional exception to this called, rather unimaginatively,
multi-VRF CE, but the basic RFC 2547 scenario requires no such thing.)

MPLS-VPN Cisco IOS Configuration

This section gives the extracts necessary to deploy a simple MPLS VPN. Example is
the configuration of a PE. The underlying network topology is the same as used in the
examples in Chapter .

Example 4-3. MPLS-VPN PE Configuration

! Define a VRF for the VPN with route-target and r-ds

! R-T 101:1 is used for both import and export

ip vrf RED

rd 101:1

route-target both 101:1

interface Loopback0

ip address 12.0.0.3 255.255.255.255

no ip directed-broadcast



! Add each CE-PE link to the VRF

! Remember the IP address must be added after the VRF name

interface Ethernet1/0/0

ip vrf forwarding RED

ip address 11.1.4.1 255.255.255.255

no ip directed-broadcast

! Core facing links

interface FastEthernet0/0/0

ip address 192.168.1.3 255.255.255.0



BRBRAITT : June-2011                                                              225
                         ―DATA NETWORK‖ FOR JTOs PH-II


tag-switching ip

no ip directed-broadcast

full-duplex

no cdp enable



! Configure iBGP to the 2 remote PEs

router bgp 101

neighbor 12.0.0.1 remote-as 101

neighbor 12.0.0.1 update-source Loopback0

neighbor 12.0.0.2 remote-as 101

neighbor 12.0.0.2 update-source Loopback0

!

address-family ipv4 vrf RED

redistribute connected

redistribute static

no auto-summary

no synchronization

exit-address-family

!

address-family vpnv4

neighbor 12.0.0.1 activate

neighbor 12.0.0.1 send-community extended

neighbor 12.0.0.2 activate

neighbor 12.0.0.2 send-community extended

exit-address-family

!




BRBRAITT : June-2011                                     226
                          ―DATA NETWORK‖ FOR JTOs PH-II


Example shows the first PE configuration. There are three basic sections. The first
global command sets up a VRF for the VPN, with some name, route-distinguisher,
and route-target values. Then, every CE-PE link needs to be added to the VRF. There
is no VRF on core-facing links, which simply do label switching. The final section is
iBGP, which in this example established two sessions to peers at 12.0.0.1 and
12.0.0.2. Each VPN has its own address-family configuration, where you can
configure which networks to announce and so forth. The VPNv4 address-family
establishes the peers as being MPLS-VPN savvy, so BGP peers understand the
necessary extended communities.

Example gives the LSR configuration, which, as you can see, is very straightforward.

Example MPLS LSR Configuration

! Core facing links

interface FastEthernet1/0/1

ip address 192.168.1.4 255.255.255.0

tag-switching ip

no ip directed-broadcast

full-duplex

no cdp enable

interface FastEthernet2/0/1

ip address 192.168.4.2 255.255.255.0

tag-switching ip

no ip directed-broadcast

full-duplex

no cdp enable

Example gives the PE Configuration at the other side of the network.

Example MPLS-VPN Egress PE Configuration

! Route-target and RD values must match. VRF names don't have to

! but better if it does

ip vrf RED

rd 101:1




BRBRAITT : June-2011                                                             227
                          ―DATA NETWORK‖ FOR JTOs PH-II


route-target both 101:1

interface Loopback0

ip address 12.0.0.1 255.255.255.255

no ip directed-broadcast

! egress CE-PE link

interface Ethernet1/0/0

ip vrf forwarding RED

ip address 11.2.4.1 255.255.255.255

no ip directed-broadcast

! Core facing links

interface FastEthernet0/0/0

ip address 192.168.4.1 255.255.255.0

tag-switching ip

no ip directed-broadcast

full-duplex

no cdp enable

router bgp 101

neighbor 12.0.0.2 remote-as 101

neighbor 12.0.0.2 update-source Loopback0

neighbor 12.0.0.3 remote-as 101

neighbor 12.0.0.3 update-source Loopback0

!

address-family ipv4 vrf RED

redistribute connected

redistribute static

no auto-summary

no synchronization


BRBRAITT : June-2011                                      228
                       ―DATA NETWORK‖ FOR JTOs PH-II


exit-address-family

!

address-family vpnv4

neighbor 12.0.0.2 activate

neighbor 12.0.0.2 send-community extended

neighbor 12.0.0.3 activate

neighbor 12.0.0.3 send-community extended

exit-address-family

!




Note

ping, telnet, and traceroute have VRF options so that they can be used between PEs.
Why don't the standard commands work? Remember that a VRF represents an
entirely private routing space. Commands issued from the Cisco IOS command line
use the global routing table. On a PE, this means that all the LSRs are reachable, but
no device in a VPN address space is. Therefore, these commands need a new
parameter to tell the router which VPN to originate a ping in, for example. Of course,
a ping within a VRF, or from any CE, will not see any LSR, because those are in a
different address space. This makes sense enough in theory, but can take some getting
used to in practice.

MPLS-VPN architecture provides full-mesh configuration by default. In other words,
a PE forwards traffic directly to its destination. It turns out that some enterprise
networks need to change this behavior. A common reason is a security policy that
requires all sites in a certain area to forward traffic through a regional hub, which
might have some expensive virus-checking package for e-mail, or perhaps needs to do
NAT on traffic between sites. Whatever the reason, MPLS VPNs can be deployed as
hub-and-spoke topologies by using route-targets.

If a spoke imports routes only from a hub, then traffic will in turn flow through the
hub to get somewhere else. (Remember, PEs forward to BGP next hops.) Because a
hub must know all the routes, it imports from all spokes. Spokes must never import
from each other. This scenario is shown in Figure, with correct use of route-targets.

Figure Hub-and-Spoke Topology




BRBRAITT : June-2011                                                              229
                          ―DATA NETWORK‖ FOR JTOs PH-II




Examples through show how to configure the route-targets to match the figure.

Example PE A Hub

!Hub imports from Spokes

vrf green

rd 200:1

route-target both 200:1

route-target import 100:1

Example PE B Spoke

!All spokes import from Hub

vrf greenrd 100:1route-target import 200:1route-target export 100:1

Example PE C Spoke

!And export to Hub

vrf greenrd 100:1route-target import 200:1route-target export 100:1

Although the details will not be provided here, route-targets are also used to build
extranets. An extranet is a VPN with limited reachability of destinations inside other
VPNs.




BRBRAITT : June-2011                                                              230
                  ―DATA NETWORK‖ FOR JTOs PH-II




BRBRAITT : June-2011                              231
                  ―DATA NETWORK‖ FOR JTOs PH-II




      NMS, EMS , OSS / BS , QOS IN NIB II PROJECT-3




BRBRAITT : June-2011                                  232
                       ―DATA NETWORK‖ FOR JTOs PH-II


        NMS, EMS , OSS / BS , QOS IN NIB II PROJECT-3

GENERAL

BSNL has planned to setup NIB-II to provide world class infrastructure to offer
various value added services to a broader customer base county-wide that will help to
accelerate the Internet revolution in India. Moreover the NIB-II will create a platform,
which enables e-governance, e-banking, e-learning, etc. with the key point of Service
Level Agreements & Guarantee in tune with Global standards and customer
expectations.

NIB-II has been grouped into following three major projects.

      Project 1: - MPLS based IP Network infrastructure covering 71 cities along
       with associated NMS, PMS, Firewall and Caching platforms.
      Project 2.1: Access Gateway platform using Dialup comprising of narrow
       band RAS and DSL equipment.
      Project 2.2: Access Gateway platform comprising of Broadband RAS and
       DSL equipment.
      Project 3:     Messaging and Storage platform and Provisioning, Billing and
       Customer care and Enterprise management system.

The network shall seamlessly integrate with the already existing network
infrastructure comprising of the TCP/IP based NIB-I and MPLS VPN network. The
NIB-II project comprises of Technology solutions from different product
manufacturers with the provision for future expansion.
Project
[Messaging and Storage Service Platform, Provisioning, Billing & Customer care,
Enterprise Management System (EMS) and Security System.]


The Core messaging system shall be the heart of NIB-II that will enable BSNL to add
users across varied value added services. This shall envisage design and up gradation
of the current messaging system to grow from the existing infrastructure in NIB-I
supporting 650,000 users to support the increasing user base. The messaging systems
and associated Storage will be implemented in phases, in accordance with phased
induction of Access equipment.

The system shall be an integrated provisioning, billing, customer care and accounting
platform and shall support billing for the complete range of IP based services
mentioned and meet next-generation requirements as well.




The salient aspects of the projects are summarized as follows:




BRBRAITT : June-2011                                                                233
                       ―DATA NETWORK‖ FOR JTOs PH-II


   (i)  Setting up proven, robust, scalable Messaging Solution with best in class
        security components.
  (ii)  Roll out across the country supported by 5 Messaging & associated storage
        systems at Delhi, Mumbai, Bangalore, Chennai and Kolkata.
  (iii) Designed with High Availability architecture with no single point of
        failure.
Components of the Solution:
The proposed solution shall consist of the following components with the items of
functionality listed below:
              (i) Messaging
                   a) DNS, AAA
                   b) MMP
                   c) LDAP (Consumer, Replicator Hub, Primary and Secondary)
                   d) SMTP IN & OUT
                   e) Messaging Servers
                   f) Address Book Servers, etc.
              (ii) Storage
                   a) SAN Switch & SAN Storage
                   b) Tape Library
                   c) Staging Servers, etc.
Storage platform

Various Applications servers placed at the 5 Messaging Storage locations like LDAP,
AAA, EMS, Messaging, UMS & Billing etc. would require Data storage capacities
for storing User‘s mailboxes, Billing data etc. Such huge storage requirements need to
be met with the Fast, Reliable & Scalable storage devices that would be deployed as
―End to End High Performance Switched Architecture Fiber Channel SAN (Storage
Area Networks) providing No Single Point of Failure‖.

Such storage device should be compatible with all the Servers of major companies
such as HP, IBM, SUN, Dell etc. so that choice of Application Servers Platform
remains independent of the storage device.
System Dimensioning:
The user base will be serviced through 5 Messaging and associated Storage systems
that will be set up in the 5 cities. Each of the cities will be connected through the IP
Backbone. Since the proposed user base is envisaged to increase in a phased manner,
the associated messaging system is also proposed to be upgraded in phases
correspondingly.
The system should be designed to support:
    On-line services such as Internet, pay-per-view TV and video on demand or a
      combination of all or some of the above.
    Periodic charges, such as telephone line and cable TV rental.
    One-time costs, such as connection fees.
    Events, such as telephone calls, data service usage, pay-per-view TV
      selections, home shopping purchases, utility metered usage – such as
      electricity supply (live site example)
    Financial services ASP services.
    Telephony services.


BRBRAITT : June-2011                                                                234
                       ―DATA NETWORK‖ FOR JTOs PH-II


      Enterprise Backup Systems.

The billing system shall be capable of
    Providing electronic versions of bills to customers over the Internet.
    Creation/modification of service.
    Processing Service requests in real time and non-real time and accounting in
       real time.
    Producing flexible billing depending upon the use of service.

Security Systems
These include the following.
      Load Balancers
      Firewall Appliances
      Intrusion Detection System
      Antivirus system, etc.

Network Operation Center (NOC)
The NOC shall provide facility for centralized Network Management and end-to-end
Provisioning of multiple services, giving a single view of the entire network services
being delivered countywide. The servers for the NOC shall be connected through a
Gigabit Ethernet link from Core router with three zones of firewall within the Centre.

The network shall be centrally managed from Network Operation Centre (NOC)
located at two sites, one of them being master and the other the disaster recovery site.
The main NOC is at Bangalore with Disaster Recovery is at Pune. Interface to the
NMS back-office facility shall be provided along with Firewall security in the Data
Centre. All customer databases shall reside centrally at NOC.

The NMS of NIB-II project 1 is the comprehensive NMS for entire NIB-II including
NIB-I, MPLS VPN, Project 2.1, Project 2.2, which will support entire F (Fault), C
(Configuration), A (Accounting including Access/Inventory), P (Performance) and S
(Security functionality). The conceptual view of eMS, NMS OSS/BSS for NIB-II is
given in figure 4 and the connectivity Architecture of NOC at Bangalore is shown in
figure .




BRBRAITT : June-2011                                                                235
                   ―DATA NETWORK‖ FOR JTOs PH-II




           Conceptual view of eMS, NMS, EMS OSS/BSS for NIB-II




                 Bangalore NOC Connectivity Architecture.




BRBRAITT : June-2011                                             236
                       ―DATA NETWORK‖ FOR JTOs PH-II


Service Level Agreement (SLA):
It shall be possible to support SLA i.e. the level of service that the customer can
expect together with any penalties to be levied by the service provider for failure to
deliver. It should be possible to provide at least 4 classes of services. The SLA
parameters shall include measurements of service delivery, availability, latency,
throughput and restoration time etc. It should be possible to generate management
reports providing information on customer node configuration and charges, faults and
achievement against the SLAs. It shall be possible to deliver network management
reports via a secure Website.

Implementation of OSS, Messaging, Storage, Billing, EMS & Security Solutions
Messaging
   Messaging Solution of NIB-II will provide the SMTP, POP3, IMAP4,
      WEBMAIL, WAPMAIL and Notifications services as a Class Of Service to
      all the customers of NIB-II and NIB-I
   Will support for Country wide roaming for dial up and message store access
      through any data center.
   The Messaging Server will support Wireless messaging and Directory services
      to WAP enabled phones and laptop users
   Message store will be content aware to support different types of services to
      be created by BSNL ranging from text email to multi-media messaging service
   Will provide Family Mailbox where the head of the family can manage
      options for Family members. Options will include setting of allowed and block
      senders and recipients and control of Anti-SPAM settings.
   Messaging solution shall provide flexible control of message aging to define
      the conditions under which messages are automatically erased
   Web mail interface will support multimedia message types for voice and fax
      mail, providing unified messaging interface in future
   Message Transfer Agent (MTA) will be designed to handle peak loads without
      service degradation or message loss
   MTAs will be designed to handle large message queues. There will be
      capability available to analyze and manage large message queues generated
      due to unreachability of message store (internal) and mail exchangers of other
      ISPs (external) or SPAM

Web Hosting
   Web space (Data Storage) on servers based on UNIX and Microsoft for
     hosting HTML pages with browser
   Ftp access for uploading and downloading pages as per the plan. Restriction
     on simultaneous ftp sessions
   FrontPage etc. access for Web-publishing
   Multiple Email Ids per domain with flexible email quota, as per the plan
   Web Interface for centralized administration by user and administrators for
     services, usage reports, invoice and other reports
   It will provide access to customers for analyzing the Web-site performance
     through analysis tools
   Interface for online registration of domain name




BRBRAITT : June-2011                                                              237
                       ―DATA NETWORK‖ FOR JTOs PH-II


Web Collocation
   Necessary Security measures will be implemented both from customer and
     BSNL‘s perspective
   Billing for this will be done on the basis of usage
   One of the service differentiator will be bandwidth on which the server is
     collocated.

Security Solution
    Anti-Virus solution: It will provide a mechanism to detect unknown virus. The
       solution will protect any Gateway and SMTP traffic from virus
    Notification: For mails containing repeated complaints regarding abuse from
       the same IP address, mail will be sent automatically to the technical contact of
       the assignee of that IP address
    Network Intrusion detection System: The NIDS will detect unauthorized
       internal/external intrusion attempts into the data centers of NIB-II and will
       enable to apply appropriate policies on the firewall so as to prevent such
       attacks in real time. Suitable alarms will also be sent to the Security Control
       Console
    Anti Control System: It is provided for Database servers, Messaging Stores,
       Web-Hosting Servers and NIDS
    Self-protection: Must be able to prevent hackers with root/administrator access
       from circumventing or shutting down the security engine
    Resource protection: Must allow controlling of access to all system resources
       including data files, devices, processes/services and audit files
    Rights delegation: Must provide the ability to designate specific users as
       administrators, auditors and password managers etc with appropriate rights
    Program Controls: Must provide protection against Back Doors and Trojan
       Horses
Enterprise Management System
    Objective of EMS is to provide a snap-shot graphical view of the health of
       NIB-II IT infrastructure as a whole including networking equipment, servers
       and services (business and process view)
    Reporting system will be able to generate customized reports such as event-
       level, performance -level and service-level reports grouped by specific data
       fields such as time period, location, customer, series type, device type etc
    Security Management will display alarm and events specified by the criteria
       such as alarm type, vendor, service, location, source of attack, type of attack
       and impacted services
    Event Management will capture all the events that are being generated across
       the complete IT infrastructure, correlates them and initiate corrective actions
       automatically, as defined
    System& Application Management will measure the availability and
       performance of heterogeneous host systems on a 24x7x365 basis and initiate
       preventive and corrective actions automatically
    System& Application Management will monitor and manage multiple
       attributes (such as status, memory usage, size and resident size, process time,
       threads, response time, average throughput and CPU utilization etc) of a
       running process and problems and perform restart when processes go down. It
       will generate reports on QOS and capacity planning



BRBRAITT : June-2011                                                               238
                       ―DATA NETWORK‖ FOR JTOs PH-II


     Database Management will be able to manage tables including database, table
      space, buffer pool, processes and session summaries. It will be able to look at
      thresholds of objects like free space, process page faults, transaction rates and
      average wait time
   Service Management will be able to measure Availability /response time of
      applications (Basic services, Email services, Web services, Mission critical
      applications). It will be possible to specify SLA for the applications and
      monitor them
   EMS will have tool to monitor SLA .It will provide alerts for SLA violations
      and violation trends, for proactively correcting service level problems
   Asset Management will store hardware and software inventory information of
      all the servers and desktops& creating, tracking and maintaining records for
      the assets and components
Objective of Operation Support System (OSS)
   OSS will allow BSNL to carryout automation of majority of the processes
      needed in service definition & provisioning, service activation, authentication,
      authorization and accounting, mediation, rating, billing and invoicing etc.
      including service assurance and customer care
   OSS shall provide an integrated view of all customers and services across the
      network for Customer life cycle management
   This includes a customizable web-based GUI client tools for configuration and
      setup




BRBRAITT : June-2011                                                               239
                                                                                          ―DATA NETWORK‖ FOR JTOs PH-II



OSS ARCHITECTURE


                                                                                    WEB SELF CARE PORTAL/IVRS (CTI)



                     Database                                                                                       DB
                                                                                                                                                                                    Rating

                                                                                                                                                                   Billing &                                      Wholesale
                                                                                                                                                                   Remittance                                     settlement
                                               OM work Flow




                                                                                                             ticketing/Help desk




                                                                                                                                                                                       DB
   management




                                                                                                                                                                   Payment                                        Reporting
                                                                                   Provisioning
                                                                                   Subscriber




                                                                                                                                                                   Accounting
                                                                                                             Trouble
   Order




                                                                                                                                                                                    GL &
                                                                                                                                                                                    others




                                                   MIDDLEWARE-ENTERPRISE APPLICATION INTEGRATION (EAI)
                      Performance Management




                                                                                                                                                                                                                         Enterprise Management
                                                                                                  Database




                                                                                                                                                                                             Voucher Management
  Fault Management




                                                              Service Activation




                                                                                                                                   Network Inventory



                                                                                                                                                       Mediation




                                                                                                                                                                         Database




                                                                                                                                                                                                                         system
                                                                                                                                                                                             system




NIB-II Network Infrastructure (NE&NEManagers)                                                                                                                          All NIB-II Servers (Networking and
procured in project 1,2.1,2.2                                                                                                                                          Security Appliances and their Element
                                                                                                                                                                       Managers)




Web Portal
   Web Portal will be the gateway for customer and CSR based on their
     authorizations for accessing various system, services etc
   Portal will have an integration, with NMS, EMS and OSS for providing
     services to the BSNL‘s customer service representatives (direct, indirect,
     helpdesk, supervisor) and account managers
   Portal services Ranging from business, process, network, customer specific
     maps/views, trouble-ticketing, pre-sales query, post-sales order-booking, order
     tracking, trouble –shooting etc
   Portal will integrate with components like Service Provisioning, Order
     Management, Billing, Customer Care, EMS and Messaging etc. to provide a




BRBRAITT : June-2011                                                                                                                                                                                                      240
                       ―DATA NETWORK‖ FOR JTOs PH-II


       unified view of the network and services to the customers and CSRs for all the
       front office functions and some back office functions
    Order status and history provide both subscribers and the customer service
       representatives with sufficient data to fully manage and monitor the service
       selection and delivery process
    It will be possible to provide a user friendly interface for customers to plan
       and schedule their bandwidth for Band width on Demand services
Services provided by portal to the customers
    Customer registration services for both pre-paid and post-paid customer
    Self-registration for getting information about products and services
    Self-registration for availing services such as post-paid dialup service based on
       telephone number authentication
    Shopping cart for procuring services
    Access to services such as messaging, web-hosting, storage and content-
       services etc. This will include on demand services like video on demand and
       online gaming etc
    Booking an order for services. Allow the user to submit, and track service
       requests online at any time
    View current bill status in real time including billed, unbilled and pre-billed
       services, payment-details and other related information
    Reporting a problem by opening a fault docket and tracking its solution
    View the status of related network and services subscribed
    View the status of SLA compliance, SLA resolution and rebates applied
       through integration with billing and NMS

ORDER MANAGEMENT
OM will have
   Customer Interface Management
   Order Entry and Validation
     Workflow Management

Customer Interface Management &Order Entry and Validation:


      Order will be entered through Web-portal by CSR or Customer directly
      CSR will accept the order after completion of signed order form by the
       customer. He will scan it and attach it with the online order form
      All orders will be checked against the feasibility from the RMS For all
       committed orders, check will be made for customers credit worthiness/default
       and the billing system will generate a unique ID for the customer
      It will be possible to query the status of order, service, billing etc. on the basis
       of unique ID
      OM will track the order status
      OM will inform the billing system of successful provisioning or else it will
       roll back all the steps
      Record all the transactions between OM and customer
      Record the details of the services provisioned for the customer
      Purge customer data from RDBMS and LDAP databases based on pre-defined
       and configurable policies when the customer surrenders service



BRBRAITT : June-2011                                                                  241
                       ―DATA NETWORK‖ FOR JTOs PH-II


Work Flow Management:
Work Flow Management will automate the process that controls and monitors the
execution of an order according to the customer requirements. This involves the steps
of qualification, reservation, configuration and verification of a service fulfillment
instance

Work Flow Management will integrate OM and provisioning Management systems
(PMS) being procured under project-1, project –2.2 and Whole-sale Dial Application
being procured under project-2.1

Subscriber Provisioning Management System (SPMS)

SPMS will cover the provisioning of following services under project 2.1 and project
3 through configurations in files. Subscriber Provisioning will be fully flexible to
support all the requirements of services
      Dial up Internet Access with different variants
      Messaging with different Variants
      Web Hosting
      Web Collocation
      Domain Hosting
      Broadband Internet Access with Content delivery through SSSC.

Mediation
Billing mediation will be responsible for collecting usage and other charging data
from the various network nodes, normalize the data into a consistent format and
distribute it to other applications and billing system for processing this information
      System will collect different parameters from different sources to provide
       Cflow and Netflow based collection and mediation for usage based billing of
       different services including MPLS-VPN, Web-hosting, Message-Hosting etc
      Parameters are
      Bandwidth
      Volume
      Time of day/ day of week/ month (Peak/off peak)
      Application (WWW, Email (POP3/IMAP4), Video, E-commerce etc )
      Destination
      Type of Service (Gold, Silver, Bronze/best efforts) etc

DATABASE
   Latest Oracle RDBMS will be used with all applications
   RDBMS will work in fail over mode over geographical locations
   RDBMS will work in a distributed mode across multiple servers
   RDBMS will work in a cluster mode
   Provisioning will be made for data replication to or from databases of project
    1,2.1 and 2.2




BRBRAITT : June-2011                                                              242
                          ―DATA NETWORK‖ FOR JTOs PH-II


HELP DESK AND TROUBLE TICKETING
   Whenever a customer reports a problem, a unique trouble ticket-ID will be
     generated by the system. This will be intimated to the customer, so that he can
     track the status on the basis of this ID
   It will be possible for customers to submit and check the status of reported
     problems through web interface
   System will automatically track, log and escalate user interactions and
     requests
   CSRs will be able to view, change the status of the calls, reassign/ transfer the
     trouble tickets to others CSRs or technical specialist through the web interface
   Will be able to generate various customized Service Level Reports e.g. Open
     Call Reports, closed Call Reports, problem area/ Location Specific Reports
   Will have the capability for accepting queries through various sources
     including Telephone, email or Web interface
   System will check for tickets status and escalation and notify the management
     or next level of support staff based on predefined Service Level Agreement
     (SLA) which will include criteria like Service application, Severity and
     customer etc
   It will have bulletin board to allow CSRs, Managers and Customers to post
     and review messages about critical issues
   It will be possible to track the time spent on specific case
   It will be possible to generate work orders for field staff or technicians for
     fault repair
   Trouble ticketing system will interface with SLA and performance
     management systems to account for the period of network or service
     unavailability
   Trouble ticketing system will be able to extract all incidents, resolution
     progress reports and all affected services via its interface with the inventory
     system
   The trouble tickets will be attached to a work-flow where ever there are
     multiple steps required for resolution
   It will be possible to include information about the equipment, circuit built up
     details etc in the trouble ticket automatically after obtaining the same from
     inventory
   Will integrate with web-portal for report trouble ticket status
   System will allow CSR to check the network fault status as part of problem
     investigation

Billing

         Billing engine will cater to all the billing requirements of BSNL include Retail
          Billing (Prepaid and Postpaid), Wholesale and third party billing, Inter connect
          and content billing, Dealers and Agents Commissions etc
         Billing system will support the preparation of detailed bill, Differential tariff,
          Cross product discounting, Sponsored/split billing. Bundled accounting, Hot
          billing/On-demand billing, Hierarchy/ Corporate billing, Discounts &
          Promotions, Taxes, Notification system, Dealers and Agent commissions,
          Content Billing
         Billing system will allow customers the option of receiving complete event
          details along with their invoice or view them online through the Web portal.



BRBRAITT : June-2011                                                                    243
                       ―DATA NETWORK‖ FOR JTOs PH-II


       Provision will also be available for the customer to print the event-details from
       the Web portal in a printable format
      Content Billing

      System will provide BSNL subscribers to access services provided by external
       content providers and be able to handle the revenue sharing with the content
       provider within the single billing platform
      System will allow content providers who do not have their own customer care
       and billing system to use the billing system of BSNL

Authentication, Authorization and Accounting
    Irrespective of mode of access (such as Dial-up Internet access, outsourced
      remote access, managed VPNs, Broadband etc), it will manage the
      Authentication of all users/customers- both locally and via proxy RADIUS-
      and deliver the appropriate level of service to each customer
    It will enable defining access schemes by time-of days, days-of-week, call
      type (PSTN, ISDN and DSL etc.), calling number and called number etc
    It will be capable of authenticating through CLI, DNIS, Voucher number, pin
      code etc
    Radius server will be able to handle at least 10,000 concurrent sessions per
      second
    It will integrate with Billing server for providing real time pre-paid balance
      management and session management across multiple sessions of multiple
      services of a user.




BRBRAITT : June-2011                                                                244
                  ―DATA NETWORK‖ FOR JTOs PH-II




                   NGN, WIMAX, VOIP, IMS




BRBRAITT : June-2011                              245
                        ―DATA NETWORK‖ FOR JTOs PH-II



Next Generation Network

Objectives
The objective of this chapter is to: -
    To understand the concept of the Next Generation Network
    To understand the technological features of the NGN
    To understand the Evolution of the NGN
    To understand the role of the NGN
    To understand the Architecture of the Next Generation Network
INTRODUCTION
NGN, or Next Generation Network, is new communication network architecture. The
principle is to use packet mode transmission technologies, reserved up till now for
data, to transport all the various types of telecommunication services. In addition,
interfaces are separated from the different layers of the communication network
(transmission, control and applications) to allow for a greater evolution of the
network. Finally, NGN uses the new packet technologies to offer broadband services.

The objective of NGN is to have a single network for all the services. The next-
generation network seamlessly blends the public switched telephone network (PSTN)
and the public switched data network (PSDN), creating a single multi service
network. Convergence is the process of interconnection of traditional switched circuit
networks (PSTN and mobile networks) and packet-switched networks based on the
Internet Protocol (IP) for routing. Convergence introduces new requirements.
NGN definition
   User perspective
   NGN enables users to get the information content they want in any
     media/format, over any facilities, anytime, anywhere and in any volume.
   Operator-provider perspective
   NGN enables simpler, more competitive creation, operation and provisioning
     of services of different nature and requirements over a convergent transport
     network independently on the access network. [ETSI]
   NGN is a model for future telecommunication networks
   NGN is not a new network to be build




BRBRAITT : June-2011                                                              246
                       ―DATA NETWORK‖ FOR JTOs PH-II


Concept of Next Generation Network (NGN)
Next Generation Network is a packet-based network able to provide
telecommunication services and able to make use of multiple broadband, QoS-
enabled transport technologies and in which service-related functions are independent
from underlying transport-related technologies. It enables unfettered access for users
to networks and to competing service providers and/or services of their choice. It
supports generalized mobility which will allow consistent and ubiquitous provision of
services to users.

Recommendation #1: The ETSI GA is invited to note the following definition of
NGN:

NGN is a concept for defining and deploying networks, which, due to their formal
separation into different layers and planes and use of open interfaces, offers service
providers and operators a platform which can evolve in a step-by-step manner to
create, deploy and manage innovative services

Key characteristics of the NGN: -
      Architecture based on decoupling of services and networks with multiple
       layers and planes defined
      Provides capabilities to make the creation, deployment and management of all
       kinds of services possible
      Has functional entities that may be distributed over the infrastructure with
       communication via open interfaces
      Supports both existing and "NGN aware" End Terminal Devices

Vision of NGN
The vision of the Next Generation Network (NGN) is captured in the following
features:
      Packet network transport with adequate Quality of Service is used for real-
       time services such as packet telephony and videoconferencing
      Internet Protocol (IP) is used as the dominant network layer protocol,
       particularly as presented at the network edge and as seen by the end user
       (Other protocols such as ATM may be used for backbone transport but will be
       transparent to the user)
      Voice over IP (VoIP) telephony is seen to be the first service to be
       implemented in the NGN with other services following over time
      IP access at the customer premises is made available through a standardised
       gateway
      Intelligence is distributed across the network (initially supported by signalling
       interworking rather than a full distributed processing environment);
      The NGN must interwork with Switched Circuit Networks (SCN) via media,
       trunking and signalling gateways with gateway controllers
      Efficient offloading of dial-up data traffic from the PSTN will be achieved by
       access servers closely coupled to end exchanges
      Because the NGN is basically a packet network and has no intelligence in the
       routers, service platforms such as IP telephony servers and billing servers will
       be provided as computing nodes in the IP network



BRBRAITT : June-2011                                                                247
                       ―DATA NETWORK‖ FOR JTOs PH-II


      VoIP users of the NGN must have access to value added services at least
       similar to those available in the PSTN (free phone, call forwarding, call
       waiting). Value-added services may be provided by access to classical IN
       service platforms in the PSTN or to specialised platforms in the IP network
      Full Operations System Support (OSS) is essential to the effective operation of
       the NGN
      Comprehensive accounting facilities in the network supporting flexible billing.
Standards for NGN is spread over a wide range of different technical committees both
inside and outside ETSI.
      Resulting in duplicate work, conflicting requirements and lack of clear
       definition of both the nature and scope of the remaining issues that still require
       standardization
      Situation recognized by many other SDOs and for a
      Clear need for consolidation but subject is too huge to be covered by a single
       global forum
ETSI should take a leading role in pushing for global consolidation of NGN
standardization. Most useful approach for ETSI is to push for a number of related, but
independent, initiatives. ETSI should become involved in a set of related, but
independent, initiatives covering the field of NGN standards.

The following technical areas require specific action:
     Architecture and protocols
     End to end QoS
     Service platforms
     Network management for NGN
     Lawful interception
     Security
Motivation for NGN
   Dedicated networks for specific services
   Orientation towards information (knowledge) society
   E-government, E-learning, E-medicine, E-commerce
   New combined telecom/IT, fixed/mobile applications
   Liberalisation of telecom market
   Horizontal and vertical
   New player and new revenues
   Access providers -> Network resources providers -> Service providers (virtual
      operators, 3rd parties) -> Content providers -> Users
   Dynamic IT development strategy in telecom domain
   Dedicated networks for specific services
   Circuit switched network
   Quality guaranteed real-time communication
   Fixed (PSTN) and mobile (GSM) transmission media
   Dedicated communication channel
   Synchronous communication
   Signalling
   Creation, modification and termination of connections
   Resources reservation
   Packet switched network



BRBRAITT : June-2011                                                                 248
                       ―DATA NETWORK‖ FOR JTOs PH-II


     Best effort, non-real time communication in burst
     Fixed (IP ever Ethernet Tx) and mobile (GPRS) transmission media
     Independently routed packets
     Asynchronous communication
     No need for signalling
     Convergence efforts
     –Data services delivered over PSTN circuit-switched network
     ISDN - dedicated limited bandwidth, time based billing
     –PSTN services delivered over data packet-switched network
     ―IP telephony‖ - QoS guaranteed only in separate domains
     -Virtual circuits – combination of circuit & packet switched approach
     -ATM – expensive and high requirements on network management
     Technology development
     –Broadband access and transport (xDSL, SDH, …)
     –Higher speed routing and QoS guaranties (IPv6, MPLS, …)
     –Standardized signalling protocols for IP (SIP, RSVP, H.323, …)
     –Service platforms for telecom and IT integration
Technology Evolution of NGN
Telecommunication technologies were evolving from analog to digital, and are
evolving from circuit to packet, connection oriented packet to connectionless packet,
and from narrow band application to broadband application - broadband converged IP
based services network.

The NGN is seen as evolving in a number of ways:
      Initially the growth of the PSTN will be capped and, over time, voice band
       service will migrate to VoIP in the NGN.
      The NGN will evolve to become a multimedia, multi-service network by
       addition of specialist servers, thus increasing range of services available.
      Networks will be federated to provide services and services will also be
       federated to provide more advanced services.
      The transport network will evolve toward a full QoS guaranteed network,
       probably based on label switching.
      Current work indicates that networks and intelligence on customer premises
       will interwork increasingly with provider networks to deliver advanced
       services.
      Distributed intelligence will be applied in a consistent way across the network.
Several independent networks are available for end-to-end communication of various
kinds of telecommunication applications. The technology as a whole is structured
around a reference module consists of series of layered elements. Technology
evolutions to a simplified one network for the convergences of all applications need to
combine these elements: -

Applications          Voice, Voice + Data, Voice + Data + Multimedia

Signaling             R2, SS7/IN, SIGTRAN/Megaco

Transport             TDM, TDM/ATM, IP/ATM

Transmission          SDH, SONET/SDH/WDM/OXC/Gbe



BRBRAITT : June-2011                                                               249
                      ―DATA NETWORK‖ FOR JTOs PH-II


Access Link          2W loop, 2W Loop/Dialup, 2W Loop/xDSL

Following diagram describes the convergence of these element in technology
evolution of NGN.
                                        ,




NGN provides converged services based on the open common service platform,
Common IP core network combines various access networks and user services.

Legacy service networks were dedicated and isolated network with service specific
signaling and routing for service connection. NGN service networks have common IP
core network and provide a nomadically accessible common IP application regardless
of a specific access link and user devices.




BRBRAITT : June-2011                                                          250
                        ―DATA NETWORK‖ FOR JTOs PH-II


NGN architecture
Next Generation network is designed in layered architecture. It has an Open standard
interfaces. It is consists of the following layers: -
Service layer
    Rapid and simple service creation, implementation and provisioning
    Secure access to the network capabilities from un-trusted domain
    Open access to the network capabilities to large developers community
    Basic building blocks of services capabilities
    Transparency to the underlying network technology
    Possible integration of telecom, IT, enterprise applications
    Access to external resources (DB, presence, media servers, …)
Control layer
    Signalling for real-time services
    Control of other layers
Transport network

High speed backbone with packet switching

Support of services with different requirements (delay, jitter, packet loss, ... )

Independent on the access network (gateways)




BRBRAITT : June-2011                                                                 251
                       ―DATA NETWORK‖ FOR JTOs PH-II




How can the Next Generation Network serve the underserved?
The next generation network is an approach of new entrant and incumbent telcos to
roll out cost effective infrastructure in order to capture market share. The question
naturally arises: what is the role of next generation network technology in providing
universal telecommunications and information service and universal access to
services to underserved communities and in developing countries in general.

The rationale for using an IP based transport network is the reduced cost of switching
relative to PSTN exchanges. Also, core network transmission, already inexpensive in
relation to switching in the PSTN, offers greater capacities in future due to
exploitation of the wide bandwidth available on optic fiber and more efficient
methods of carrying packetised traffic. Access is at present the major cost component
in providing PSTN services. Access technologies for the Next Generation Network
include Asynchronous Digital Subscriber Loops (ADSL) and digital radio loop
systems. Fiber based access for low traffic users are a long way in the future. ADSL
uses existing copper subscriber loops. While providing greater bandwidth to the end
user, ADSL is subject to the operational problems of the current copper loop access.
The cost trends of access to the Next Generation Network are not clear and cost is
likely to continue to be a factor in providing services to underserved communities.
Further research is clearly needed in the access area.


In the next section, we take as an example of the Next Generation Network in the
service of underserved communities, namely a proposal for the Next Generation
Telecentre being researched at CeTAS [4].



BRBRAITT : June-2011                                                              252
                       ―DATA NETWORK‖ FOR JTOs PH-II


Softswitch Architecture
In softswitch architecture, the service provider replaces the Class 5 switch with a
softswitch, media gateway, and application server such as BroadWorks. The
Softswitch provides trunking, SS7 networking, translations, routing and network
services, such as local number portability. BroadWorks acts as a peer to a softswitch,
using the SIP connection between the two as an "IP Inter Machine Trunk".

Unlike the class 5 switch, the softswitch and BroadWorks are not involved in the
transport or switching of the packetized voice stream. However, the softswitch does
communicate with BroadWorks for access to the IP Centrex/Hosted PBX features.
Also, if the terminating party is part of the IP Centrex/Hosted PBX group, then the
softswitch instructs the originating and terminating party to establish communications,
and keeps the entire call on the network, and as VoIP. If the terminating party resides
outside the IP Centrex/Hosted PBX group, the softswitch interacts via a network
gateway, with the Public Switched Telephone Network (PSTN). On the PSTN, a
Class 4 or Class 5 switch will handle the transport and switching of voice calls.
Class 5 Extension Architecture
A Class 5 Extension architecture allows service providers to continue to use their
existing voice network, while still offering their customers the advantages of VoIP
and IP Centrex/Hosted PBX. In this architecture, BroadWorks provides dial tone,
calling features, unified messaging, and other features provided by IP Centrex/Hosted
PBX applications. The Class 5 switch provides the network functionality such as 911,
number portability, billing, and SS7 interconnection.

BroadWorks provides the flexibility to introduce IP voice services without the need to
invest softswitch infrastructure. In this architecture, a single BroadWorks system can
leverage existing voice infrastructure, and support multiple points of presence (POP).
Providers seeking a region-by-region rollout can launch service one POP at a time,
starting with smaller capacity gateways as needed.

For financial planning, the Class 5 Extension offers a cost-effective migration to IP
voice. BroadWorks allows incremental investments in IP voice assets that limits risk
and reduces upfront outlay. BroadWorks not only interconnects with TDM
infrastructure but also extends capacity. By moving business customers to IP voice,
providers increase capacity as part of a "cap-and-grow" migration.
NGN Drivers
A key driver for implementing or migrating to a NGN is cost. It is impossible to
generalise on the extent of cost savings since business specific issues such as service
strategy, legacy infrastructure, operational model, and scale all play a part in this
complex equation. For many businesses however the potential capital and operational
cost savings of running multiple services on a single infrastructure are too good to
ignore.

Another important driver is service differentiation. The initial focus of many NGNs is
to support traditional data/voice services, but today, there are service providers
building complete business strategies around new converged service platforms. They
are taking advantage of the benefits convergence provides them today and investing in



BRBRAITT : June-2011                                                               253
                      ―DATA NETWORK‖ FOR JTOs PH-II


future proven technology that they believe shall provide a platform for application
growth.
NGN Equipment Types
Along with traditional voice and data equipment the NGN architecture contains
converged network equipment types such as Call Agents (e.g. Media Gateway
Controller - MGC, Gatekeeper - GK, SIP Server and Softswitch - SS), Media
Gateways (MG), Signalling Gateways (SG), Feature Servers, Application Servers,
Media Servers and provides Management, Provisioning and Billing interfaces.
The Softswitch
Softswitches are a software-based call control device that plays one of the most
significant parts in the NGN. The Softswitch provides call control interworking
between NGN protocols such as MGCP, H.248 / Megaco, SIP, H.323, and Sigtran as
well as more traditional telephony protocols such as CAS, ISDN, SS7, TCAP, and
INAP. The Softswitch can contain multiple call agent functions (e.g. MGC, SIP
Server & GK) and in some cases a SG function.

One of the many roles of a Softswitch is interfacing to the PSTN (Public Switched
Telephony Network). It does this by interworking signalling systems via SGs and the
voice circuits via MGs from PSTN switches and Intelligent Network platforms.

The choice of softswitch today is large and is influenced by factors such as target
market, scale of deployment, required functionality, available budget and service
strategy.
Who are implementing NGNs
Traditional carriers with traditional legacy equipment and services must carefully
address how they migrate to a NGN. They must decide whether to replace current
operational infrastructures, cap investment & grow organically or implement a new
parallel platform & migrate over time. Whatever the decision the scale of network
infrastructure involved will lead to significant costs and protracted timescales for
migration activities.

New operators with less legacy infrastructure and greenfield networks can plan for,
design and implement the NGN more readily. Their IP network can be designed to
provide some level of quality, a vendor can be chosen to provide an end-to-end
solution and interconnects to the PSTN and Internet can be put in place. Advances
Operational Support Systems can be utilised effectively to monitor, control, police
and bill with less integration than with traditional operators.

ISPs are looking at a potential change in their business model. Converged services
will allow the ISP to differentiate themselves while entering into a new
telecommunications market without the capital outlay of traditional networks.
Bandwidth increases brought about by DSL to the home will play a major part and so
ISPs can offer more bandwidth hungry services without the constraints of slower
speed access.




BRBRAITT : June-2011                                                            254
                       ―DATA NETWORK‖ FOR JTOs PH-II


WiMAX
WiMAX is a single wireless technology that can:
      Bridge the digital divide by delivering broadband in low-density areas,
      Connect enterprises and residential users in urban and suburban environments
       where access to copper plant is difficult,
      Make portable Internet a reality by extending public WLAN hotspots to city
       hotzones,
      Further expand hotzones to metropolitan area coverage for mobile data-centric
       service delivery.
WiMAX is state-of-the-art radio technology, offers Broadband wireless access at data
rates of several tens of Mbit/s (up to 75 Mbit/s per base station) and within a range of
several tens of kilometers (up to 50 km). This same radio technology offers high-
speed data services to all nomadic terminals (laptops, PDAs, etc.) at a better cost :
performance ratio than 3G, given an optimized trade off between throughput and
mobility. Finally, WiMAX incorporates Quality of Service elements to offer
multimedia services, including voice. Given its huge benefits, WiMAX will develop
as a self-standing radio access solution in the global network architecture. WiMAX
will also enable end-users to benefit from an "Always Best Connected" experience
when accessing their applications via the best available network, at home, on the
pause, or on the move. A technology with such enormous potential is destined for a
bright future.
Introduction
Broadband Wireless Access (BWA) has been serving enterprises and operators for
years, to the great satisfaction of its users. However, the new IP-based standard
developed by the IEEE 802.16 is likely to accelerate adoption of the technology. It
will expand the scope of usage thanks to: the possibility of operating in unlicensed
frequency bands, unique performance under Non-Line-of-Sight (NLOS) conditions,
Quality of Service (QoS) awareness, extension to mobility, and more. In parallel, the
WiMAX forum, backed by industry leaders, will encourage the widespread adoption
of broadband wireless access by establishing a brand for the technology and pushing
interoperability between products. The purpose of this White Paper is to highlight and
assess the value of WiMAX as the right solution to:
      Bridge the digital divide in low-density areas where technical and economic
       factors make broadband deployment very challenging,
      Offer fixed broadband access in urban and suburban areas where copper
       quality is poor or unbundling difficult,
      Extend the currently limited coverage of public WLAN (hotspots) to citywide
       coverage (hotzones) – the same technology being usable at home and on the
       move,
      Blanket metropolitan areas for mobile data-centric service delivery.
In addition to these uses, it has other potential applications, such as telephony or an
effective point-to-multipoint backhauling solution for operators or enterprises.




BRBRAITT : June-2011                                                                255
                       ―DATA NETWORK‖ FOR JTOs PH-II


Standards associated to WiMAX
Worldwide Interoperability for Microwave Access (WiMAX) is the common name
associated to the IEEE 802.16a/REVd/e standards. These standards are issued by the
IEEE 802.16 subgroup that originally covered the Wireless Local Loop (WLL)
technologies with radio spectrum from 10 to 66 GHz. Recently, these specifications
were extended below 10 GHz:
      In January 2003, the IEEE approved 802.16a as an amendment to IEEE
       802.16- 2001, defining (Near) Line-Of- Sight capability,
      Mid-2004, IEEE 802.16REVd, which should be published under the name
       IEEE 802.16-2004, will introduce support for indoor CPE (NLOS) and
       nomadicity through additional radio capabilities such as antenna beam
       forming and OFDM sub-channeling,
      Early 2005, an IEEE 802.16e variant will introduce support for mobility.
See Figure for the applications associated with each of these standards.




The WiMAX Forum intends to do for 802.16 what the Wi-Fi Alliance did for 802.11:
      Harmonize standards and certify interoperability between equipment from
       different vendors. Standardized interoperable solutions will result in mass
       volume and bring down costs,
      Promote and establish a brand for the technology.
WiMAX offers broadband wireless access at data rates of several tens of Mbit/s (up to
75 Mbit/s per base station) and within a range of several tens of kilometers (up to 50
km). However,

75 Mbit/s is achievable with a 20 MHz channel. Regulators will often allow only
smaller channels (10 MHz or less) reducing the maximum bandwidth,




BRBRAITT : June-2011                                                              256
                       ―DATA NETWORK‖ FOR JTOs PH-II


50 km is achievable only under optimal conditions and with a reduced data rate (a few
Mbit/s). Typical coverage will be around 5 km with indoor CPE (NLOS) and around
15 km with a CPE connected to an external antenna (LOS),
   Mobility will target only urban usage, with up to 60 km/h vehicle speed to
    maintain optimum throughput performance.
WiMAX product availability
Mass deployment of WiMAX products is planned in two main steps:
      mid-2005, availability of the 802.16REVd chipset, allowing the development
       of cost optimized CPE operating indoors (NLOS),
      in 2006, availability of 802.16e chipsets embedded in laptops and later on in
       other mobile devices, enabling mobility (portable Internet).
Current pre-WiMAX products and initial 802.16a WiMAX products available in early
2005, operating similarly to current proprietary equipment (LOS, not cost-optimized
CPE) and at similar cost, will not be widely deployed.
Market for WiMAX
WiMAX will boost today‘s highly fragmented BWA market thanks to standardization
and interoperability, state-of-the-art radio efficiency with NLOS capability, and
strong support from the radio equipment manufacturers and chipset industries.
WiMAX will also target the mobility market with the introduction of low power-
consumption chipsets. The strong support from some of the most important chipsets
manufacturers such as Intel or Fujitsu is a key enabler for the success of WiMAX,
since it will lead to wide availability of affordable WiMAX-enabled terminals (e.g.,
laptops, PDAs, etc.).

WiMAX and its three main markets

WiMAX will open up three main markets – see Figure This will happen in three
waves:
      It will bridge the digital divide in low-density areas where technical and
       economic factors inhibit cost effective broadband deployments. The prime
       markets are in Western Europe, North America, and some Asia-Pacific
       countries. This will be the first market to take off - in 2005.
      It will offer high-speed Internet and voice access in urban and suburban areas
       where access to the copper plant is difficult. It will also support nomadic usage
       for operators wishing to stand out from competition (the same subscription
       could be used throughout a city). This market will also start in 2005, with
       WiMAX progressively replacing current proprietary products.
      It will then introduce the portable Internet application by providing broadband
       access on the move, extending the currently limited coverage of public
       WLANs to city-wide coverage (hotzones). Later expansion will be to
       Metropolitan areas, providing high-speed data services under mobility
       conditions. This market will first emerge in North America, followed by most
       of the developed and developing countries. It will take off with the availability
       of WiMAX-enabled laptops in 2006.




BRBRAITT : June-2011                                                                257
                       ―DATA NETWORK‖ FOR JTOs PH-II


WiMAX, a complement to fixed and mobile access
WiMAX integrates perfectly into existing fixed and mobile networks, complementing
them when needed.

This section gives a more detailed analysis of WiMAX integration into fixed and the
mobile markets.




WiMAX for fixed wireless access
Nationwide broadband access has become a priority in many countries. In most
developed countries, the average broadband coverage will reach 90% in the coming
years. Still, in some rural areas of such countries, broadband coverage will not exceed
50%.

The service gap can be categorized by two characteristics: the type of area (rural or
urban) and the level of national development. See Table 1. In developed countries,
DSL service deployment has been massive in urban and sub-urban deployments,
whereas coverage of remote areas -smaller towns and rural areas - is lagging behind.
Hurdles to overcome are the poor line quality of the installed copper base, the large
distances to the central offices or cabinets, or the low population density. In this
context, WiMAX, with its QoS support, longer reach, and data rates similar to DSL, is
naturally positioned as a viable last mile option to offer broadband access to
residential users.

In emerging countries, the main focus of broadband deployment is on urban and sub-
urban areas, and will remain so in the near future. The low POTS penetration and the
low quality of the copper pair prevent mass scale DSL deployment and foster the need
for alternate broadband technologies. In this context, WiMAX is positioned as an
excellent option. Moreover, the possibility of offering broadband services in
combination with voice services will gradually lead to narrowband WLL substitution.



BRBRAITT : June-2011                                                               258
                       ―DATA NETWORK‖ FOR JTOs PH-II




In addition to WiMAX, alternate technologies available to cover urban and rural
markets in developed and developing countries are remote DSL solutions, satellite
combined with Wi-Fi for the last mile, Fiber to the User (FTTU), and possibly Power
Line Communications (PLC).

Parameters such as availability of the copper, distance to the remote unit/central
office, backhauling costs, and teledensity will drive the choice for one or other of
these solutions. For further details, refer to the article ―Providing Always-on
Broadband Access to Under-served Areas‖ in the Alcatel Telecommunication Review
(Q4 2003).
The WiMAX CPE
In most case, a simple plug and play terminal, similar to a DSL modem, provides
connectivity. See Figure. For customers located several kilometers from the WiMAX
base station, a self-install outdoor antenna may be required to improve transmission
quality. To serve isolated customers, a directive antenna pointing to the WiMAX base
station may be required. For customers requesting voice in addition to broadband
services, specific CPE will allow the connection of standard or VoIP phones.
Deployment topologies
Several topology and backhauling options are to be supported on the WiMAX base
stations: wire line backhauling (typically over Ethernet), microwave Point to- Point
connection, as well as WiMAX backhaul. See Figure. With the latter option, the base
station has the capability to backhaul itself. This can be achieved by reserving part of
the bandwidth normally used for the end-user traffic and using it for backhauling
purposes.
Operator’s business case
WiMAX is of interest for incumbent, alternate, and mobile operators. Some possible
business cases:
      The incumbent operators can use the wireless technology as a complement to
       DSL, allowing them to offer DSL-like services in remote, low-density areas
       that cannot be served with DSL.
      For alternate operators, the wireless technology is the solution for a
       competitive high-speed Internet and voice offering bypassing the landline
       facilities, with applicability in urban or sub-urban areas.
      In the long term, mobile operators may also take market share from fixed
       operators due to substitution of fixed broadband access by wireless broadband
       access, giving access to users on the move but also at home.



BRBRAITT : June-2011                                                                259
                      ―DATA NETWORK‖ FOR JTOs PH-II


WiMAX for limited mobility access
WiMAX, the natural complement to Wi-Fi and mobile networks

Mobile networks offer mobility, ubiquitous coverage, and voice support, but at the
expense of limited data rates. WiMAX can be positioned as a complementary solution
by offering high bandwidth when required, in particular in dense urban areas.

Public WLAN, while offering clear benefits, is limited in coverage and mobility
capabilities. WiMAX bypasses these limitations and offers broadband connectivity in
larger areas (hotzones). Wi-Fi and WiMAX solutions are also complementary, with
Wi-Fi being more adapted for short-range, indoor connections (in particular in the
enterprise and at home) and WiMAX for long- range outdoor connections.
From nomadicity to full mobility
While nomadicity offers mobility within the coverage area of a single base station,
limited mobility access implies session continuity throughout the network possibly
with between base stations.




BRBRAITT : June-2011                                                           260
                       ―DATA NETWORK‖ FOR JTOs PH-II




A new generation of networks with multi-access (3G, Wi-Fi, WiMAX, DSL, FTTU,
etc.) enables end-users to enjoy an ―Always Best Connected‖ experience when
accessing their applications via the best available network at home, on the pause, or
on the move. See Figure WiMAX becomes an additional radio access solution in the
global network architecture.
WiMAX, the obvious choice for operators
By integrating WiMAX into their networks, mobile operators can boost their service
with high bandwidth, when necessary, the same applications (messaging, agenda,
location-based services) being offered on both networks with a single billing.

Mobile operators can also reuse existing radio sites and backhauling equipment to
facilitate the deployment of WiMAX.

Fixed operators, incumbent or alternate, will offer nomadic and mobile usage as an
addition to their fixed access offering to complement their DSL and Wi-Fi bundle. For
those having deployed WiMAX for fixed access, this is also a natural evolution of
their offering.
WiMAX Technology Challenge WiMAX, more flexibility and security
Unlike WLAN, WiMAX provides a media access control (MAC) layer that uses a
grant-request mechanism to authorize the exchange of data. This feature allows better
exploitation of the radio resources, in particular with smart antennas, and independent
management of the traffic of every user. This simplifies the support of real-time and
voice applications.

One of the inhibitors to widespread deployment of WLAN was the poor security
feature of the first releases. WiMAX proposes the full range of security features to
ensure secured data exchange:
      Terminal authentication by exchanging certificates to prevent rogue devices,
      User authentication using the Extensible Authentication Protocol (EAP),



BRBRAITT : June-2011                                                               261
                      ―DATA NETWORK‖ FOR JTOs PH-II


      Data encryption using the Data Encryption Standard (DES) or Advanced
       Encryption Standard (AES), both much more robust than the Wireless
       Equivalent Privacy (WEP) initially used by WLAN. Furthermore, each service
       is encrypted with its own security association and private keys.

WiMAX, a very efficient radio solution
WiMAX must be able to provide a reliable service over long distances to customers
using indoor terminals or PC cards (like today‘s WLAN cards). These requirements,
with limited transmit power to comply with health requirements, will limit the link
budget. Subchannelling in uplink and smart antennas at the base station have to
overcome these constraints.

The WiMAX system relies on a new radio physical (PHY) layer and appropriate
MAC layer to support all demands driven by the target applications.

The PHY layer modulation is based on OFDM, in combination with a centralized
MAC layer for optimized resource allocation and support of QoS for different types
of services (VoIP, real-time and non real-time services, best effort). The OFDM PHY
layer is well adapted to the NLOS propagation environment in the 2 – 11 GHz
frequency range. It is inherently robust when it comes to handling the significant
delay spread caused by the typical NLOS reflections. Together with adaptive
modulation, which is applied to each subscriber individually according to the radio
channel capability, OFDM can provide a high spectral efficiency of about 3 – 4
bit/s/Hz.

However, in contrast to single carrier modulation, the OFDM signal has an increased
peak: average ratio and increased frequency accuracy requirements. Therefore,
selection of appropriate power amplifiers and frequency recovery concepts are
crucial.

WiMAX provides flexibility in terms of channelization, carrier frequency, and duplex
mode (TDD and FDD) to meet a variety of requirements for available spectrum
resources and targeted services.

An important and very challenging function of the WiMAX system is the support of
various advanced antenna techniques, which are essential to provide high spectral
efficiency, capacity, system performance, and reliability:
      Beam forming using smart antennas provides additional gain to bridge long
       distances or to increase indoor coverage; it reduces inter-cell interference and
       improves frequency reuse,
      Transmit diversity and MIMO techniques using multiple antennas take
       advantage of multipath reflections to improve reliability and capacity.




BRBRAITT : June-2011                                                               262
                           ―DATA NETWORK‖ FOR JTOs PH-II


System performance
Table gives typical cell size and throughput at 3.5 GHz in various configuration and environments.




WiMAX Spectrum and Regulation Issues

WiMAX-compliant equipment will be allowed to operate in both licensed and
unlicensed bands. The minimum channel bandwidth for WiMAX usage is 1.75 MHz
per channel, while 10 MHz is considered as an optimum.

Although 2.4 GHz and 5 GHz non-licensed bands are largely available, their usage
could be limited to trials because of the risks of interference preventing QoS
commitments.

The 2.5 and 3.5 GHz licensed bands will be the most common bands for WiMAX
applications. It should be noted that the 5 GHz band is also partially licensed in some
countries.

Most countries have already allocated licensed spectrum, generally to alternate
operators. Nevertheless large quantities of spectrum are still in process of allocation,
and some countries have not even defined any WiMAX licensed bands yet.

WiMAX is designed to accommodate either Frequency Division Duplexing (FDD),
which is more suited to enterprise traffic, or Time Division Duplexing (TDD), which
is more adapted to asymmetrical traffic. Cohabitation of FDD and TDD techniques is
possible within the same bands, provided guard bands are implemented.
Conclusion
The latest developments in the IEEE 802.16 group are driving a broadband wireless
access (r)evolution thanks to a standard with unique technical characteristics. In
parallel, the WiMAX forum, backed by industry leaders, helps the widespread
adoption of broadband wireless access by establishing a brand for the technology.
Initially, WiMAX will bridge the digital divide. Then, thanks to competitive
equipment prices, the scope of WiMAX deployment will broaden to cover markets
where the low POTS penetration, high DSL unbundling costs, or poor copper quality
have acted as a brake on extensive high-speed Internet and voice over broadband.
WiMAX will reach its peak by making portable Internet a reality. When WiMAX


BRBRAITT : June-2011                                                                             263
                      ―DATA NETWORK‖ FOR JTOs PH-II


chipsets are integrated into laptops and other portable devices, it will provide high
speed data services on the move, extending today‘s limited coverage of public WLAN
to metropolitan areas. Integrated into new generation networks with seamless roaming
between various accesses, it will enable end users to enjoy an ―Always Best
Connected‖ experience. The combination of these capabilities makes WiMAX
attractive for a wide diversity of people: fixed operators, mobile operators, and
wireless ISPs, but also for many vertical markets and local authorities. Alcatel, the
worldwide broadband market leader with a market share in excess of 37%, is
committed to offer complete support across the entire investment and operational
cycle required for successful deployment of WiMAX services.




BRBRAITT : June-2011                                                             264
                       ―DATA NETWORK‖ FOR JTOs PH-II


VOIP Introduction

Voice communication has traditionally been carried over dedicated Telephone
networks operated by Telecommunication service providers such as the BSNL and
MTNL in India or AT&T in USA. These telephone networks have progressively
evolved from the initial analog circuits to the current digital networks with bandwidth
in excess of 1 Gbps. For reasons of varying bandwidth and networking requirements,
different services were provided on separate networks. For example, Telegraph
networks, Telex networks, Telephone networks, Facsimile networks, Cable networks
and Data networks support different services, as their names would suggest.


These networks possessed characteristics that satisfied the peculiar requirements of
the service they provided. For example, the voice network would support bandwidths
of 64 Kbps for voice communication and would ensure telco-grade voice
communication with little jitter and echo cancellation. Likewise, the cable networks
would provide even higher bandwidth and improved quality of service (QoS) for
video transmission. On the other hand, the data communication network‘s bandwidth
and QoS requirements are highly flexible. This means that the data communication
requirements could be a Telnet application, requiring minimal data pipe, but
reasonably fast network response times. Or it could be a batch transmission
application that required a higher throughput, but can tolerate larger inter packet
deliver delays. For most types of data communication applications, reliability is
critical, which means that the delivery protocols would implement mechanisms for
error checking, acknowledgment, re-transmission and sequencing. On the other hand,
for real-time applications such as voice communications, it would make little sense to
retransmit a lost packet for play back at the receiving end, if it is out of sequence and
is considerably delayed. Essentially, the main point to be nodded is that these
networks have been designed differently in terms of their underlying architecture and
communication protocols.


In the late eighties and early nineties it was realized that integrating these networks
into a single integrated network, such that all services would use common facilities,
would result in efficiency and cost savings. This was the new mantra that made
possible the creation and deployment of ISDN and similar networks, bringing data
and voice communication together. However, nearly all these networks were built and
operated by major telecommunication equipment manufacturers and service
providers. Although, the major international standards bodies such as ITU-T
(formerly CCITT), or the ETSI defined a relevant set of standards for implementation
and to assure inter-operability between products from different telecom equipment
manufacturers, these standards were still inadequate to reduce the proprietary nature
of most implementations. It meant that even if the standards assured inter-operability
among equipment and networks for existing communication services (which number
only in dozens), they fell woefully short, on account of proprietary implementations,
for being able to spawn and envisage even greater types of potential communication
services. Consider what the Internet has done for conceiving and spawning
innumerable types of web-based applications at progressively lower costs.

Subsequently, from the mid-nineties onwards, the Internet has proved to be the major
all-encompassing network that demonstrated its prowess in delivering all types of


BRBRAITT : June-2011                                                                 265
                       ―DATA NETWORK‖ FOR JTOs PH-II


media (data, voice and video) at lowest cost. Data communication equipment
manufacturing companies, such as Cisco, have also been instrumental in driving up
the reach of the Internet and Internet protocols. Internet protocols became the
preferred protocol for delivering communication payload for all types of networks,
mainly for their open and widely accepted interface implementations. Contrast this
with ATM, which somehow has been left behind.


However, a major shortcoming in the Internet protocols – TCP, UDP over IP has been
their inability to transfer real-time application data such as voice and video. The major
issues were jitter, network latency, echo cancellation, quality of service and security.
To overcome this shortcoming, newer implementations of IP (e.g. IP version 6) and a
flurry of associated protocol specifications (e.g. H.323 or SIP) were defined to plug
the gap between the Internet protocols and other telecom application-oriented
protocols. These activities of developing and implementing new IP-based protocol
definitions for multimedia communications; their underlying network architecture and
also integration with existing networks are collectively termed as Voice over IP or
VoIP in short.

         ISDN
        PSTN


         TEL
         EX
        TELEGRA                                      INTERNET
            PH

ACCESS
ACCESS         TRANSMISI          SWITCHIN           GATEWAY        ROTERS        LAN

                  ON                 G


  TTTTTTTTTTELCOS                             DATA NETWORKIG COMPNAIES




                     TELCO EQIPMENT               DATA SERVICE           DATA EQIPMENT
 TELCO               MANUFACTURERS                 PROVIDERS            MANUFACTURERS
SERVICE
PROVIDERS


              Communication Market Stake Holders


The effort to integrate all communication services over IP is a transition effort on two
major fronts. First, the Telecommunication equipment manufacturers were interested


BRBRAITT : June-2011                                                                 266
                       ―DATA NETWORK‖ FOR JTOs PH-II


in integrating the currently deployed services and network protocols to IP. Second, the
Data communication equipment manufacturers, who were already using IP for data
communication services were moving upward to provide voice and multimedia
services over data networks.


The culmination of the above efforts and various standards making bodies is supposed
to achieve the objectives of service portability, network convergence and secured
network access. It is hoped that with the transition of voice (multimedia) over to
Internet protocols would open the doors to the conceptualisation and implementation
of numbers services in thousands from the current dozens.
Issues in voice communication over networks
As the IP network was primarily designed to carry data, it does not provide real-time
guarantees but only provides best effort services, which is inadequate for voice
communication. Upper layer protocols were designed to provide such guarantees.
Further, as there are several vendors in the market implementing these protocols,
conformance to standards and interoperability issues have become important. The
major issues governing transfer of a voice stream over the Internet or using Internet
protocols are listed below.
Bandwidth requirement
In the analog world, the voice transmission frequency spectrum requirement is 0-3.4
KHz in the base band, and is nominally called a 4 KHz voice channel for
convenience. For digital telecommunication, the signal is sampled at twice the rate.
The minimum-sampling rate required is thus 8 KHz. If each sample contains 8 bits,
the digital bandwidth required works out to be 64 Kbps.

Telco quality voice requires sampling at 8 KHz. The bandwidth then depends on the
level of quantization. With linear quantization at 8 bits/sample or at 16 bits/sample,
the bandwidth is either 64 Kbps or 128 Kbps. Further, the quantization (e.g. PCM) is
modified by using an A-law or µ-law companding curve.

In order to communicate telco-grade voice (or similarly, other real-time applications
such as moving video) two different approaches can be attempted. To transmit
information of the highest quality over unrestricted bandwidth or to reduce the
bandwidth required for transmitting information (voice) of a given quality. Stated
differently, decisions are required regarding what information should be transmitted
and how it should be transmitted.

Compression and decompression (CODEC) of digital signals is a means of reducing
the required bandwidth or transmission bit rate. Certain source data are highly
redundant, particularly digitised images such as video and facsimile. If, for example, a
digital signal contains a string of zeroes, it will be economical to transmit a code
indicating that a string of zero follows along with the length of the string. Many
different algorithms for compression and decompression of digital codes have been
constructed.

Pulse code modulation (PCM) and adaptive differential PCM (ADPCM) are examples
of ―waveform‖ CODEC techniques. Waveform CODECs are compression techniques
that exploit the redundant characteristics of the waveform itself. In addition to


BRBRAITT : June-2011                                                                267
                      ―DATA NETWORK‖ FOR JTOs PH-II


waveform CODECs, there are source CODECs that compress speech by sending only
simplified parametric information about voice transmission; these CODECs require
less bandwidth.

Source CODECs include linear predictive coding (LPC), code-excited linear
prediction (CELP) and multipulse-multilevel quantization (MP-MLQ).
Coding techniques for telephony and voice packet are standardized by the ITU-T in
its G-series recommendations.
Some algorithms for voice compression and decompression are given in the table
below.


Table-Coding Algorithms
Input Range                                  Transmission Rate      Standard

Liner Predictive Coding algorithm            64 Kbps                LPC-10

                                                                    G.711

Code Excited Liner Prediction (CELP)         8 Kbps                 G.729

                                                                    G.729 A

32 Kbps Adaptive Differential Pulse Code 32 Kbps                    G.721
Modulation (ADPCM)


Mean Opinion Score (MOS)
Each CODEC provides a certain quality of speech. The quality of transmitted speech
is a subjective response of the listener. A common benchmark used to determine the
quality of sound produced by specific CODECs is the mean opinion score (MOS).
With MOS, a wide range of listeners judge the quality of a voice sample
(corresponding to a particular CODEC) on a scale of 1 (bad) to 5 (excellent). The
scores are averaged to provide the MOS for that sample. The table below shows the
below shows the relationship between CODECs and MOS scores.
Table-Compression Methods and MOS Scores

Compression Method         Bit Rate (Kbps)      Framing Size (ms)    MOS Score

G.711 PCM                  64                   1.25                 4.1

G.729 CS-ACELP             8                    10                   3.92

G.729x2 Encoding           8                    10                   3.27

G.729x3 Encoding           8                    10                   2.68

G.729a CS-ACELP            8                    10                   3.7



BRBRAITT : June-2011                                                           268
                        ―DATA NETWORK‖ FOR JTOs PH-II


Although it might seem logical from a resource usage standpoint to convert all calls to
low bit-rate CODECs to save on infrastructure costs, there are drawbacks to
compressing voice. One of the main drawbacks is signal distortion due to multiple
encodings (called tandem encodings). For example, when a G.729 voice signal is
tandem-encoded three times, the MOS score drops from 3.92 (very good) to 2.68
(unacceptable.
Telco-grade voice refers to MOS scores of 4 or above.
Delay
A very important design consideration in implementing voice communications
networks is minizing one-way, end-to-end delay. Voice traffic is real-time traffic and
if there is too long a delay in voice packet delivery, speech will be unrecognisable. An
acceptable delay is less than 200 milliseconds. Delay is inherent in voice networking
and is caused by a number of different factors.

There are basically two kinds of delay inherent in today‘s telephony networks:
      Propagation delay – caused by the characteristics of the speed of light
       traveling via a fiber-optic-based or copper-based medium of the underlying
       network.

      Handling delay (also called serialization delay) – caused by the devices that
       handle voice information and have a signicant impact on voice quality in a
       packet network. This delay includes the time it takes to generate a voice
       packet. DSPs may take 5ms to 20ms to generate a frame and usually one or
       more frames are placed in a voice packet. Another component of this delay is
       the time taken to move the packet to the output queue. Some devices expedite
       this process by determining packet destination and getting the packet to output
       queue quickly. The actual delay at the output queue, in terms of time spent in
       the queue before being serviced, is yet another component of this handling
       delay and is normally around 10ms. A CODEC-induced delay is considered a
       handling delay. The table below shows the delay introduced by different
       CODECs.

Table CODEC-Induced Delays
CODEC                          Bit Rate (Kbps)            Compression Delay (ms)
G.711 PCM                      64                         5
G.729 CS-ACELP                 8                          15
G.729a CS-ACELP                8                          15


Serialization delay
Serialization delay is the amount of time a router takes to place a packet on a wire for
transmission. Fragmentation helps to eliminate serialization delay, but fragmentation,
such as FRF.12, doesn‘t help without a queuing mechanism in place. For example, if a
1000-byte packet enters a router‘s queue and is fragmented into ten 100-byte packets,
without a queuing mechanism in place, a router will still send all 1000-bytes before it
starts to send another packet. Conversely, if there is a queuing mechanism in place,
but no fragmentation, voice traffic can still fail. If a router receives a 1000-byte packet


BRBRAITT : June-2011                                                                   269
                        ―DATA NETWORK‖ FOR JTOs PH-II


in its queue and begins sending this packet in an instant before it receives a voice
packet, the voice packet will have to wait until all 1000 bytes are sent across the wire,
before entering the queue, because once a router starts sending a packet, it will
continue to do so until the full packet is processed. Therefore, it is essential that there
is a method for a router to break large data packets into smaller ones, and a queuing
strategy in place to help voice packets jump to the front of a queue ahead of data
packets for transmission.
End-to-End delay
End-to-end delay depends on the end-to-end signal paths/data paths, the CODEC, and
the payload size of the packets.
Jitter
Jitter is variation in the delay of arrivals of voice packets at the receiver. This causes a
discontinuity of the voice stream. It is usually compensated for by using a play-out
buffer for playing out the voice smoothly. Play-out control can be exercised both in
adaptive or non-adaptive play-out delay mode.
Echo Cancellation
Echo is hearing your own voice in the telephone receiver while you are talking. When
timed properly, echo is reassuring to the speaker. If the echo exceeds approximately
25ms, it can be distracting and cause breaks in the conversation. In a traditional
telephony network, echo is normally caused by a mismatch in impedance from the
four-wire network switch conversion to the two-wire local loop and is controlled by
echo cancellers.

In voice over packet-based networks or VoIP, echo cancellers are built into the low
bit-rate CODECs and are operated on echo DSP. Echo cancellers are limited by
design by the total amount of time they will wait for the reflected speech to be
received, which is known as an echo trail. The echo trail is normally 32ms.
Reliability
Traditional data communication strives to provide reliable end-to-end communication
between two peers. They use checksum and sequence numbering for error control and
some form of negative acknowledgement with a packet retransmission handshake for
error recovery. The negative acknowledgement with subsequent re-transmission
handshake adds more than a round trip delay to transmission. For time-critical data,
the retransmitted message/packet might therefore be entirely useless. Thus, VoIP
networks should leave the proper error control and error recovery scheme to higher
communication layers. They can thus provide the level of reliability required, taking
into account the impact of the delay characteristics. Therefore, UDP is the transport
level protocol of choice for voice and like communications. Reliability is built into
higher layers.

Audio data is delay-sensitive and requires the transmitted voice packets to reach the
destination with minimum delay and minimum delay jitter. Although TCP/IP provides
reliable connection, it is at the cost of packet delay or higher network latency. On the
other hand, UDP is faster compared to TCP. However, as packet sequencing and some
degree of reliability are required over UDP/IP, RTP over UDP/IP is usually used for
voice and video communication.



BRBRAITT : June-2011                                                                   270
                       ―DATA NETWORK‖ FOR JTOs PH-II


Interoperability
In a public network environment, in order for products from different vendors to inter-
operate with each other, they need to conform to standards. These standards are being
devised by the ITU-T and the IETF. H.323 from ITU-T is by far the more popular
standard. However, SIP/MGCP standards from IETF are rapidly gaining more
acceptance as relatively light weight and easily scalable protocols.
Security
On the Internet, since anybody can capture packets meant for someone else, security
of voice communication becomes an important issue. Some measure of security can
be provided by using encryption and tunneling. Usually, the common tunneling
protocol used is Layer 2 Tunneling protocol, and the common encryption mechanism
used is Secure Sockets Layer (SSL).
Integration with PSTN and ISDN
IP Telephony needs to co-exist with traditional PSTN for still some more time. It
means that both PSTN and IP telephony networks should appear as a single network
to users. This is achieved through the use of gateways between the Internet on the one
hand and PSTN or ISDN on the other.
Scalability
As succeeding VoIP products strive to provide Telco-grade voice quality over IP as is
true for PSTN, but at a progressively lower cost, there is a potential for high growth
rates in VoIP systems. in such a scenario, it is essential that these systems be flexible
enough to grow into large user markets.
Typical voice call handling in a VoIP application
It is useful to understand what happens at an application level when a call is placed
using VoIP. The diagram below describes the general flow of a two-party voice call
using VoIP.




BRBRAITT : June-2011                                                                 271
                           ―DATA NETWORK‖ FOR JTOs PH-II




                                           IP                      PSTN
                                        Network




        Handset        VoIP                                           PBX
                     Application                Gateway
  Step 1                                                                               Phone
 Off Hook




  Step 2
 Dial Tone                          Step 4-IP Address
                                        resolution




   Step 3                                                                   Step 5-PSTN Call
Dialed Digits                                   Step 5-Call                 signaling to phone
                                                 Request
                                                 using H.323/SIP
                                                                               Step 5-Call
                                                                            signaling to PHX



                                                                                                 Ringin
                                                                                                 g
                                                                              Step 5- Off Hook
                                              Step 5-Call
                                               Request
                                   CODEC       using H.323/SIP
Talk-
Audio
                              Step 6-Audio
                               Transport                Step 7
                                 using                  DTMF

                               RTP/RTCP




                  Step 8
                   Bye




                               Typical VoIP Call Handling



  BRBRAITT : June-2011                                                                     272
                     ―DATA NETWORK‖ FOR JTOs PH-II


Table-Typical VoIP Call Handling

Step       Action
Step1.     The use picks up the handset; this signals an off-hook condition to the
           signaling application part of VoIP.
Step2.     The session application part of VoIP issues a dial tone and waits of the
           user to dial a telephone number.
Step3.     The user dials the telephone number; those numbers are accumulated and
           stored by the session application.
Step4.     After enough digits are accumulated to match a configured destination
           pattern, the telephone number is mapped to an IP host via the dial-plan
           mapper. The IP host has a direct connection t either the destination
           telephone number or a PBX that is responsible for completing the call tot
           the configured destination pattern.
Step5.     The session application then runs the session protocol (H.323 or
           SIP/MGCP) to establish a transmission and a reception channel for each
           direction over the IP network. If the call is being handled by a Private
           Branch Exchange (PBX), the PBX forwards the call to the destination
           telephony. If Resource Reservation Protocol (RSVP) has been
           configured, the RSVP reservations are put into effect to achieve the
           desired QoS over the IP network.
Step6.     The coder-decoder compression schemes (CODECs) are enabled for both
           ends of the connection and the conversation proceeds using Real-time
           Transport Protocol/User Datagram Protocol/Internet Protocol
           (RTP/UDP/IP) as the protocol stack.
Step7.     Any call-progress indications (or other signals that can be carried inband)
           are cut through the voice path as soon as an end-to-end audio channel is
           established. Signaling that can be detected by the voice ports (for
           example, inband dual-tone multifrequency (DTMF) digits after the call
           setup is complete) is also trapped by the session application at either end
           of the connection. It is carried over the IP network, encapsulated in the
           Real-time Transport Control Protocol (RTCP) using the RTCP
           application-defined (APP) extension mechanism.
Step8.     When either end of the call hangs up, the RSVP reservations are torn
           down (if RSVP is used) and the session ends. Each end becomes idle,
           waiting for the next off-hook condition to trigger another call setup.




BRBRAITT : June-2011                                                              273
                       ―DATA NETWORK‖ FOR JTOs PH-II


An Introduction To World-wide Inter-operability for Microwave
Access (Wi –MAX)

Scope:

The Wi-MAX certification mark is given to product that pass conformity and
interoperability test for the IEEE 802-16 standard which caters for the Air interface
standard for point-to-multipoint broad-band Internet access over a wireless
connection.

General details of Wi-MAX:

Wi-MAX is an acronym that stands for World-wide Interoperability for Microwave
Access. It is an ideal method for ISP to deliver high speed broadband to locations
where wired connections would be difficult or costly. Wi-MAX delivers a point-to-
multipoint architecture. It doesn't require a direct line of sight between the source and
endpoint and it has a service range of 50 Kms. It provides a shared data rate of up to
70 Mbps, which is enough to service up to a thousand homes with high-speed access.

The main advantages of Wi-MAX are:

High speed of broadband service upto 70 Mbps.

Wireless rather than wired access, so that it would be a lot less expensive than cable
or Digital Subscriber Line (DSL) and much easier to extend to suburban and rural
areas.

Broad coverage like the cell phone network instead of small Wi-Fi hotspots , 50 Kms.

There are following, two corresponding Wi-MAX standards:

IEEE 802.16-2004 is for fixed point-to-point and point-to-multipoint wireless access.
It is akin to a faster, airborne version of Digital Subscriber Line (DSL) or cable-
modem services, It is also called first Non Line of Sight (NLOS), Broad-Band
Wireless access (BWA) standard.

IEEE 802.16e is for mobile wireless access from laptops and hand held. It is
analogous to a faster version of third-generation (3G) telecommunications technology.
(Wi-Max proponent Intel Corp. has promised 802.16e-enabled laptops by early 2007)

True roaming cell-like wireless broadband , is IEEE standard          802.20, which is
compatible with Wi-MAX.

Working of Wi-MAX:

Wi-MAX operates similar to Wi-Fi but at higher speeds, over greater distances and
for a greater number of users. It consists of following two parts:




BRBRAITT : June-2011                                                                 274
                       ―DATA NETWORK‖ FOR JTOs PH-II


A Wi-MAX tower, similar in concept to a cell-phone tower, and which can provide
coverage to a very large area as big as 3,000 square miles (~8,000 square km).

A Wi-MAX receiver, and antenna could be like a PCMCIA (Personal Computer
Memory Card International Association) card, or they could be built into a laptop
similar to Wi-Fi access.

It can provide two forms of wireless service:

The non-line-of-sight, Wi-Fi sort of service, where a small antenna on your computer
connects to the tower. In this mode, Wi-MAX uses a lower frequency range - 2 GHz
to 11 GHz (similar to Wi-Fi). As lower-wavelength transmissions are not as easily
disrupted by physical obstructions they provided non line of sight coverage.

The line-of-sight service, where a fixed dish antenna points straight at the Wi-MAX
tower from a rooftop or pole. The line-of-sight connection is stronger and more stable,
so it is able to send a lot of data with fewer errors. Line-of-sight transmissions use
higher frequencies, with ranges reaching a possible 66 GHz. At higher frequencies,
there is less interference and lots more bandwidth as shown in Figure.




Wi-MAX operates on the same general principles as Wi-Fi. A typical Wi-MAX
network sends data from one computer to another via radio signals. A computer
(either a desktop or a laptop) equipped with Wi-MAX would receive data from the
Wi-MAX transmitting station, using encrypted data keys to prevent unauthorized
users from stealing access. The fastest Wi-Fi connection can transmit up to 54
megabits per second under optimal conditions. Wi-MAX should be able to handle up
to 70 megabits per second. Even once those 70 megabits is split up between several
dozen businesses or a few hundred home users, it will provide at least the equivalent
of cable-modem transfer rates to each user.




BRBRAITT : June-2011                                                               275
                        ―DATA NETWORK‖ FOR JTOs PH-II


The Wi-MAX protocol is a way of networking computers together Wi-MAX does not
conflict with Wi-Fi. It is designed to interoperate with Wi-Fi and may indeed
complement it. This complementarity to Wi-Fi also extends to all flavors of wired
Ethernet (IEEE 802.3), token ring (IEEE 802.5) and non-IEEE standards that use the
same Logical Link Control (LLC) including Fiber Distribution Data Interface (FDDI)
and cable modem Data Over Cable Service Interface Specification (DOCSIS).
Technical Advantage of Wi-MAX:
IEEE 802.16 networks use the same Logical Link Controller (standardized by IEEE
802.2) as other LANs and WANs. It can be both bridged and routed to them. Wi-
MAX is a wireless Metropolitan Area Network (MAN) technology that can connect
IEEE 802.2 (Wi-Fi) hotspots to the Internet and provide a wireless extension to cable
and DSL for last mile (last km) broadband access. IEEE 802.16 provides up to 50 kms
(31 miles) of linear service area range and allows users connectivity without a direct
line of sight to a base station. Note that this should not be taken to mean that users 50
kms (31 miles) away without line of sight will have connectivity. The technology also
provides shared data rates up to 70 Mbps, which, according to Wi-MAX proponents,
is enough bandwidth to simultaneously support more than 60 businesses with T1-type
connectivity and well over a thousand homes at 1Mbps DSL-level connectivity.

An important aspect of the IEEE 802.16 is that it defines a MAC layer that supports
multiple Physical Layer (PHY) specifications .The MAC is significantly different
from that of Wi-Fi (and Ethernet from which Wi-Fi is derived).

In Wi-Fi, the Ethernet uses contention access: all subscriber stations wishing to pass
data through an access point are competing for the Access Points (AP's), attention on
a random basis. This can cause distant nodes from the Access Point (AP) to be
repeatedly interrupted by less sensitive, closer nodes, greatly reducing their
throughput. By contrast, the 802.16 MAC is a scheduling MAC where the subscriber
station only has to compete once (for initial entry into the network). After that it is
allocated a time slot by the base station. The time slot can enlarge and constrict, but it
remains assigned to the subscriber station meaning that other subscribers are not
supposed to use it but take their turn. This scheduling algorithm is stable under
overload and over subscription (unlike 802.11). It is also much more bandwidth
efficient. The scheduling algorithm also allows the base station to control Quality of
Service (QoS) by balancing the assignments among the needs of the subscriber
stations.

The Wi-MAX outdistances Wi-Fi by miles. Wi-Fi's range is about 100 feet (30
metres). Wi-MAX will blanket a radius of 30 miles (50 kms) with wireless access.

The increased range is due to the frequencies used and the power of the transmitter.

Wi-MAX is both faster and has a longer range than Wi-Fi. However, Wi-MAX does
not necessarily conflict with Wi-Fi but is designed to interoperate with it and may
indeed complement it.
Wi-MAX (IEEE 802.16) Specifications:
    Range: 30 miles (50-kms) radius from base station.
    Speed: 70 Mbps.
    Line-of-sight not needed between user and base station.



BRBRAITT : June-2011                                                                  276
                       ―DATA NETWORK‖ FOR JTOs PH-II


      Frequency bands: 2 to 11 GHz and 10 to 66 GHz (licensed and unlicensed
       bands).
      Defines both the MAC and PHY layers and allows multiple PHY-layer
       specifications.

Network Scale:
The smallest-scale network is a Personal Area Network (PAN). A PAN allows
devices to communicate with each other over short distances. Bluetooth is the best
example of a PAN.

The next step up is a Local Area Network (LAN). A LAN allows devices to share
information, but is limited to a fairly small central area, such as a company's
headquarters, a coffee shop or your house. E.g. Wi-Fi to connect the network
wirelessly.

Wi-MAX is the wireless solution for the next step up in scale, the Metropolitan Area
Network (MAN). A MAN allows areas the size of cities to be connected. (Figure )




                            The Network Scale.Standards

The current 802.16 standard is IEEE Std 802.16-2004. It renders the previous (and
1st) version 802.16-2001 obsolete, along with its amendments 802.16a and
802.16c.IEEE Std 802.16-2004 addresses only fixed systems.
      802.16-2004: IEEE Standard for Local and Metropolitan Area Networks Part
       16 -- Air Interface for Fixed Broadband Wireless Access Systems
      802.16.2-2004: IEEE Recommended Practice for Local and Metropolitan Area
       Networks -- Coexistence of Fixed Broadband Wireless Access Systems.
      802.16-2001 obsolete by 802.16-2004.
      802.16a amendment, obsolete by 802.16-2004.
      802.16c amendment, obsolete by 802.16-2004.
      802.16e in progress, adds mobility to the standard.

An amendment to the standards, 802.16e, and addressing mobility was concluded in
2005. This is some times called ―Mobile Wi-MAX‖, and should not be confused with
802.20, the planned standards for ―Mobile Broadband Wireless Access (MBWA)‖
itself probably some years away.
The Wi-MAX Difference:
Wi-MAX promises to provide high-speed wireless connectivity more simply and cost-
effectively than current cellular technologies, and it offers the scalability to deliver
affordable broadband access across India. Because its wireless infrastructure can be



BRBRAITT : June-2011                                                                277
                      ―DATA NETWORK‖ FOR JTOs PH-II


extended to provide portable and mobile device support in the future, Wi-MAX has
additional advantages for developing economies such as that of India, that don‘t have
widespread broadband infrastructure already in place. By leapfrogging to the latest
technology, they gain not only the best broadband connectivity when in a fixed
environment, but also the potential to easily add fully mobile high-speed data
connectivity in the future.




BRBRAITT : June-2011                                                             278
                                ―DATA NETWORK‖ FOR JTOs PH-II

     Because Wi-MAX is standards-based, it can enable economies of scale that will bring down the cost
     of broadband access and ensure interoperability while increasing ease of implementation. Without
     standards, proprietary equipment manufacturers provide the entire stack of hardware and software
     building blocks, and restrictive licensing can drive up costs. For the service provider, standards-based
     products with fewer variants and larger volume production will drive the cost of equipment down.
     Competition among vendors will also lower equipment costs, because service providers will be able
     to buy from many sources and shop for the best price. For consumers, wireless products will be
     differentiated by the service, not the technology, and thus the consumer will benefit from a variety of
     competitive and cost-effective solutions that match their communication needs. Table 1 depicts the
     throughput comparison between other cellular technologies and Wi-MAX. Wi-MAX delivers greater
     throughput and greater scalability to meet consumer‘s needs.

     Table1. Comparison of cellular technologies and Wi-MAX:

                  Cellular                                    Wi-MAX
Metric            Edge                HSPDA       1xEVDO      802.16-2004                         802.16e
Technology        TDMA GMSK           WCDMA (5    CDMA2K QPSK OFDM/OFDMA                          Scalable
Family            and 8-PSK           MHz) QPSK & & 16 QAM    QPSK, 16 QAM &                      OFDMA
and Modulation                        16 QAM                  64 QAM                              QPSK, 16AM
                                                                                                  & 64 QAM
Peak Data Rate    473 Kbps            10.8 Mbps         2.4 Mbps           75 Mbps (20 MHz        75 Mbps (Max)
                                                                           channel) 18 Mbps (5
                                                                           MHz channel)

Average User      T-put < 130         < 750 kbps        < 140 Kbps         1–3 Mbps               80% pfmc
Throughput        Kbps                initially                                                   of fixed usage
                                                                                                  model
Range Outdoor     2–10 kms            2–10 kms          2–10 kms           2–10 kms               2–7 kms
(Avg Cell)
Channel BW        200 KHz             5 MHz             1.25 MHz           Scalable 1.5–20        Scalable 1.5–20
                                                                           MHz                    MHz


     Wi-MAX suits India‘s broadband requirement because, there is no comprehensive
     wired communications infrastructure in place today. Wired broadband technologies
     like Digital Subscriber Line (DSL) connectivity can reach only about 5 Kms (~ 3
     miles) from the central office switches, making them an expensive and unrealistic
     option to reach the rural and remote areas of India. Planning and expanding the wired
     ―last-mile‖ solution is a challenge in these areas. In new localities, it is a challenge for
     telecommunications operators to estimate physical wiring infrastructure needed for
     future growth, and maintenance and upgrading may necessitate excavating the earth to
     lay many Kms/miles of extra cables. Both add significant operational costs.

    Cable broadband service is another wired last-mile solution. Most cable
    broadband services in India offer just 64 Kbps of connectivity. This is not
    significantly faster than a dial-up connection and does little to improve the
    Internet user experience. There is also no consistent infrastructure quality or
    organization and local Internet service providers, so Internet users don‘t
    experience consistent Quality of Service.




    BRBRAITT : June-2011                                                                                 279
                           ―DATA NETWORK‖ FOR JTOs PH-II


9.0 Evolution of Wi-MAX:
    The first phase of Wi-MAX technology (based on IEEE 802.16-2004) is
    providing fixed wireless connections via outdoor antennae from the first half of
    2005. In the second half of 2005, Wi-MAX is available for indoor installation,
    with smaller antennae similar to a Wi-Fi access point today. In this fixed indoor
    model, Wi-MAX is available for use in wide consumer residential broadband
    deployments, as these devices become "user installable," lowering installation
    costs for carriers. By 2006, the technology will be integrated into mobile
    computers to support roaming between Wi-MAX service areas. Figure 3 depicts
    the evolution of Wi-MAX.




                          Figure -3: Evolution of Wi-MAX.

10.0 Advantages of Wi-MAX:
   The broad band Internet access has biggest limitation of last mile solution and higher
   data rate. The presently available technologies like Wi-Fi does not provides sufficient
   band width coverage is very limited roaming , backhaul, interference and security
   are also its limitations. Wi-MAX has been evolved takes care all these limitations.
   The coverage area of one site is very large the coverage radius is 50Kms as compare
   to Wi-Fi which requires 650 access points to cover 10 Sq Km area. The bandwidth of
   70 Mbps is good enough to cater hundreds of home users. Roaming and mobility is
   available, security features are better that Wi-Fi.
   The Wi-MAX standard offers a great deal of design flexibility including support for
   licensed and license-exempted frequency bands, channel widths ranging from 1.5
   MHz to 20 MHz, per-connection Quality of Service (QoS) and strong security
   primitives. 802.16 is optimized to deliver high, bursty data rates to the subscriber but
   the sophisticated Medium Access Control (MAC) architecture can simultaneously
   support real-time multimedia and isochronous applications such as Voice over IP as




   BRBRAITT : June-2011                                                                 280
                           ―DATA NETWORK‖ FOR JTOs PH-II


   well. This means that Wi-MAX is uniquely positioned to support applications
   requiring advanced QOS, such as Internet telephony & streaming video.
11.0 Indian Scenario of Wi-MAX Role out:
   In India, WebSky has created a joint venture with World-Wide Wireless India
   (WWWI) to design, build and run a network that could address 75m people. WebSky
   will provide the funding and will construct the system while WWWI will contribute
   its licensed frequencies in 3.5GHz spectrum, which cover nine large cities, including
   Mumbai (Bombay), Delhi, Calcutta, Chennai (Madras), Bangalore and Hyderabad.
   The first build-out will occur in the city of Ludhiana, in the Punjab.
   Also in India, telecom giant Bharat Sanchar Nigam Limited (BSNL) has announced
   plans to roll out Wi-MAX and Wi-Fi services in 10 major cities, including
   Hyderabad, Pune, Ahemdabad and Bangalore.The installation and commissioning of
   Wi-Fi and Wi-MAX certified equipment of BSNL is under progress and will be rolled
   out shortly.
    It will build 400 to 500 Wi-Fi hotspots, in the first phase, at public locations such as
   airports, hotels, universities and hospitals, and will use Wi-MAX for backhaul and for
   some last mile services, complementing its existing fixed, mobile and internet
   services across India.
   On trial basis BSNL has deployed Cambridge Broadband‘s Vectastar Equipment in
   Gurgoan near Delhi. Its CPEs are multi frequency and multi sector. Vectastar‘s
   technology product is used for both access and transmission with the network
   combining IP based access services with the backhaul of traffic from GSM, 3G, Wi-Fi
   and Wi-MAX base stations.
   French telecom major Alcatel has joined hands in an agreement with the Centre for
   Development of Telematics (CDoT) to set up a global research and development
   centre in India for broadband wireless products. The joint venture facility, to be
   established in Chennai, will employ 1,000 people and initially work on Wi-MAX
   technology. Alcatel believes that broadband wireless and particularly Wi-MAX is
   appropriate technology for India keeping in mind the requirements of the rural sector.
   Tokyo is having the first major deployment of a Wi-MAX Metropolitan Area
   Network (MAN) in the world . The Yozan MetroZone will deliver high speed IP
   connectivity with support for voice, video and broadband data services. Airspan
   Networks and partner Yozan has commenced trials in the second quarter of 2005 and
   the commercial rollout has begun from the fourth quarter of the year. The contract is
   valued in excess of $12 million. This is a just a sample of how big the market for Wi-
   MAX technologies can be in India.
12.0 Abbreviations:
                   1. LAN:                         Local Area Network.
                   2. AP:                  Access Point.
                   3. EP:                  Extension Point .
                   4. ISM:                         Industrial Scientific & Medical
                   5. MAC:                 Media Access Control.
                   6. CSMA/CA:                     Carrier Sense Multiple Access with
        Collision Avoidance.
                   7. DSL:                         Digital Subscriber Line .
                   8. IEEE:                Institute of Electrical & Electronics Engineers
                   9. OSI:                         Open systems Interconnect.
                   10. PCMCIA:             Personal Computer Memory Card International
        Association.
                   11. NLOS:               Non Line of Sight .


   BRBRAITT : June-2011                                                                 281
                           ―DATA NETWORK‖ FOR JTOs PH-II


                   12. BWA:             Broadband Wireless access
                   13.C-DoT:            Centre for Development of Telematics.
                   14.LLC:                     Logical Link Control.
                   15. DOCSIS:          Data over Cable Service Interface Specification.
                   16. PAN:             Personel Area Network.
                   17. WWWI:            Worl-Wide Wireless India.
13.0 References:
                   1. Article in PC Quest Magazine July 2004 issue.
                   2. Article in Telecommunications Nov-Dec 2005 issue.
                   3. Technical article at internet site: http://www.Wi-MAXforum.org.
                   4. Technical article at internet site: www.proxim.com.




   BRBRAITT : June-2011                                                                 282
                  ―DATA NETWORK‖ FOR JTOs PH-II




BRBRAITT : June-2011                              283