Mobile Backhaul Solutions Guide - Juniper Networks

Mobile Backhaul SolutionConfiguration Guide

Release 1.01

Juniper Networks, Inc.

1194 North Mathilda Avenue

Sunnyvale, CA 94089

USA

408-745-2000

www.juniper.net

Part Number: 530-029625-01 Revision 1.01

II

This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997, Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part of them is in the public domain.

This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.

This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright © 1979, 1980,1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.

GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through release3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD software copyright © 1988,Regents of the University of California. All rights reserved. Portions of the GateD software copyright © 1991, D. L. S. Associates.

This product includes software developed by Maker Communications, Inc., Copyright © 1996, 1997, Maker Communications, Inc.

Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen Technologies, the NetScreen logo, NetScreen-Global Pro, ScreenOS, and GigaScreen are registered trademarks of Juniper Networks, Inc. in the United States and other countries.The following are trademarks of Juniper Networks, Inc.: ERX, ESP, E Series, Instant Virtual Extranet, Internet Processor, J2300, J4300, J6300, J-Protect, J Series, J-Web, JUNOS, JUNOScope, JUNOScript, JUNOSe, M5, M7i, M10, M10i, M20, M40, M40e, M160, M320, M Series, MMD, NetScreen-5GT,NetScreen-5XP, NetScreen-5XT, NetScreen-25, NetScreen-50, NetScreen-204, NetScreen-208, NetScreen-500, NetScreen-5200, NetScreen-5400,NetScreen-IDP 10, NetScreen-IDP 100, NetScreen-IDP 500, NetScreen-Remote Security Client, NetScreen-Remote VPN Client, NetScreen-SA 1000 Series, NetScreen-SA 3000 Series, NetScreen-SA 5000 Series, NetScreen-SA Central Manager, NetScreen Secure Access, NetScreen-SM 3000, NetScreen-Security Manager, NMC-RX, SDX, Stateful Signature, T320, T640, T Series, and TX Matrix. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. All specifications are subject to change without notice.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

Copyright © 2009 Juniper Networks, Inc. All rights reserved.

BX7000 Multi-Access Gateway Mobile Backhaul Configuration GuideCopyright © 2009 Juniper Networks, Inc.All rights reserved. Printed in USA.

Writing: Writers Works, Inc.Editing: Writers Works, Inc.Illustration: Writers Works, Inc.Cover Design: Edmonds Design

Revision History

June, 2009—First Official Release

The information in this document is current as of the date listed in the revision history.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice.

Products made or sold by Juniper Networks (including the ERX-310, ERX-705, ERX-710, ERX-1410, ERX-1440, M5, M7i, M10, M10i, M20, M40, M40e,M160, M320, and T320 routers, T640 routing node, and the JUNOS and SDX-300 software) or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479,6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. The JUNOS software has no known time-related limitations through the year2038. However, the NTP application is known to have some difficulty in the year 2036.

End User License Agreement

READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE. BY DOWNLOADING,INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU (AS CUSTOMEROR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THESOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS.

1. The Parties. The parties to this Agreement are Juniper Networks, Inc. and its subsidiaries (collectively “Juniper”), and the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use of the Software (“Customer”) (collectively, the “Parties”).

2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, and updates and releases of such software, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller.

3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer anon-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use restrictions:

a. Customer shall use the Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from Juniper or an authorized Juniper reseller, unless the applicable Juniper documentation expressly permits installation on non-Juniper equipment.

b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which Customer has paid the applicable license fees.

c. Other Juniper documentation for the Software (such as product purchase documents, documents accompanying the product, the Software user manual(s), Juniper’s website for the Software, or messages displayed by the Software) may specify limits to Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, concurrent users, sessions, subscribers, nodes, or transactions, or require the purchase of separate licenses to use particular features, functionalities, or capabilities, or provide temporal or geographical limits.Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.

The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the applicable license(s) for the Software from Juniper or an authorized Juniper reseller.

4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as necessary for backup purposes); (c) rent, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d) remove any proprietary notices, labels, or marks on or in any copy of the Software; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any ‘locked’ or key-restricted feature, function, or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i) use the Software on non-Juniper equipment where the Juniper documentation does not expressly permit installation on non-Juniper equipment; (j) use the Software (or make it available for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper reseller; or (k) use the Software in any manner other than as expressly provided herein.

5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall furnish such records to Juniper and certify its compliance with this Agreement.

6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customer shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum includes restricting access to the Software to Customer employees and contractors having a need to use the Software.

7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software.

8. Warranty, Limitation of Liability, Disclaimer of Warranty. If the Software is distributed on physical media (such as CD), Juniper warrants for 90 days from delivery that the media on which the Software is delivered will be free of defects in material and workmanship under normal use. This limited warranty extends only to the Customer. Except as may be expressly provided in separate documentation from Juniper, no other warranties apply to the Software, and the Software is otherwise provided AS IS. Customer assumes all risks arising from use of the Software. Customer’s sole remedy and Juniper’s entire liability under this limited warranty is that Juniper, at its option, will repair or replace the media containing the Software, or provide a refund, provided that Customer makes a proper warranty claim to Juniper, in writing, within the warranty period. Nothing in this Agreement shall give rise to any obligation to support the Software. Any such support shall be governed by a separate, written agreement. To the maximum extent permitted by law, Juniper shall not be liable for any liability for lost profits, loss of data or costs or procurement of substitute goods or services, or for any special, indirect, or consequential damages arising out of this Agreement, the Software, or any Juniper or Juniper-supplied software. In no event shall Juniper be liable for damages arising from unauthorized or improper use of any Juniper or Juniper-supplied software.

EXCEPT AS EXPRESSLY PROVIDED HEREIN OR IN SEPARATE DOCUMENTATION PROVIDED FROM JUNIPER AND TO THE EXTENT PERMITTED BYLAW, JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE),INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR ORINTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK.

9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the

license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer’s possession or control.

10. Taxes. All license fees for the Software are exclusive of taxes, withholdings, duties, or levies (collectively “Taxes”). Customer shall be responsible for paying Taxes arising from the purchase of the license, or importation or use of the Software.

11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to you may contain encryption or other capabilities restricting your ability to export the Software without an export license.

12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS 227.7201 through 227.7202-4,FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.

13. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. For any disputes arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity of the remainder of this Agreement.

If you have any questions about this agreement, contact Juniper Networks at the following address:

Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, CA 94089USAAttn: Contracts Administrator

III

IV

Table of Contents

Chapter 1 Introduction 1

Overview .........................................................................................................1Components ....................................................................................................2

BX7000 Multi-Access Gateway...................................................................3Aggregation Site Gateway (M Series Router with CES PICs) .......................3Ethernet Services Routers for Metro Backhaul Transport ...........................3JUNOScope IP Service Manager with Extensions for Mobile Backhaul .......4

Pseudowires.....................................................................................................5Why Juniper Networks?....................................................................................6

Financial Benefits of the Juniper Networks Mobile Backhaul Solution ........6Technical Benefits of the Juniper Networks Mobile Backhaul Solution .......7

Chapter 2 Provisioning the Service 9

SAToP Pseudowire Configuration...................................................................10BX7000 Gateway to BX7000 Gateway Provisioning.................................10BX7000 Gateway to M10i Router Provisioning ........................................14M10i Router to M10i Router SAToP Pseudowire Configuration................18BX7000 to M10i SAToP Pseudowire over GRE Tunnel Provisioning.........23BX7000 to M10i (with CHOC3/STM1 Circuit Emulation PIC) SAToP

Pseudowire Configuration with Bypass Tunnel Configuration ...........27ATM Pseudowire Topology and Configuration................................................36

BX7000 Gateway to BX7000 Gateway Provisioning.................................36M10i Router to M10i Router ATM Pseudowire Provisioning.....................40Router Configuration ...............................................................................41BX7000 Gateway to M10i ATM Pseudowire Provisioning ........................48ATM-IMA Configuration Between Two BX7000 Multi-Access Gateways with

RSVP and GRE Tunnels .....................................................................52

Chapter 3 Monitoring and Troubleshooting 63

Monitoring the BX7000 Multi-Access Gateway ...............................................63Checking the Protocol-Enabled Interfaces................................................63Checking the Protocol Working Condition ...............................................64Checking the Pseudowire Status ..............................................................64

Monitoring the M10i Router ...........................................................................66

Chapter 4 Zero-Touch Configuration 69

Zero-Touch Functionality ...............................................................................69Infrastructure Mode .......................................................................................72Manual Mode .................................................................................................74Standalone Mode ...........................................................................................74Zero-Touch Topology .....................................................................................76

Enabling or Disabling Zero-Touch............................................................76

Table of Contents V

VI

Mobile Backhaul Solution Configuration Guide V1.01

Enabling or Disabling Manual Mode ........................................................76Showing Zero-Touch or Manual Mode......................................................76

Automatic Configuration Server .....................................................................77DHCP Server Configuration for Zero-Touch .............................................77Configuration Server Configuration .........................................................78

Chapter 5 JUNOScope IP Backhaul Manager 79

Overview .......................................................................................................79Pseudowire Provisioning................................................................................81

Prerequisites for Pseudowire Provisioning...............................................81Configuring LSP Paths....................................................................................82Configuring Protocols on Interfaces ...............................................................84MPLS/GRE Tunnel Provisioning ......................................................................86

Step 1: Choose the Devices to be Used as Endpoints ...............................87Step 2: Adding, Editing, or Deleting Tunnels............................................89Step 3: Confirming the Operation............................................................92Step 4: Provisioning the Tunnels .............................................................93

Pseudowire Provisioning Workflow................................................................95Creating the Pseudowire Templates.........................................................95Provisioning the Pseudowires ..................................................................97Step 1: Choosing the Devices to be Used as Endpoints ............................98Step 2: Adding, Editing, or Deleting Pseudowires ..................................100Step 3: Confirming the Operation..........................................................102Step 4: Provisioning the Pseudowires ....................................................103Filtering and Testing the Pseudowires ...................................................104

JUNOScope IP Backhaul Manager Image Management Summary ................108Image Management...............................................................................108Inventory Management .........................................................................110

Chapter 6 Upgrading the Software 111

CLI-Based Software Upgrade Procedure for the BX7000 Gateway ................111Software Upgrade Procedure for the M Series Router...................................115

Table of Contents

List of Figures

Figure 1: Juniper Networks Mobile Backhaul Solution Example Circuit ...........2Figure 2: Normal Backhaul Configuration .......................................................9Figure 3: SAToP Pseudowire Topology for BX7000 Gateway to

BX7000 Gateway ...........................................................................10Figure 4: SAToP Pseudowire Topology for BX7000 Gateway to M10i Router 14Figure 5: SAToP Pseudowire Topology for M10i Router to M10i Router........18Figure 6: SAToP Pseudowire Topology for BX7000 Router to the

M10i Router...................................................................................23Figure 7: BX7000 to the M10i SAToP Pseudowire Configuration with Bypass Tunnel Configuration27Figure 8: ATM Pseudowire Topology for BX7000 Gateway to

BX7000 Gateway ...........................................................................36Figure 9: ATM Pseudowire Topology for M10i Router to M10i Router

using ATM2-IQ PIC.........................................................................40Figure 10:ATM Pseudowire Topology for BX7000 Gateway to M10i Router ...48Figure 11:ATM-IMA Configuration Between Two

BX7000 Multi-Access Gateways with RSVP and GRE Tunnels ........52Figure 12:Zero-Touch Configuration Flow Chart ............................................71Figure 13: Infrastructure Mode Configuration Diagram...................................72Figure 14:Standalone Mode Configuration Diagram ......................................74Figure 15:Zero Touch Topology .....................................................................76Figure 16:Current Mobile Architecture...........................................................79Figure 17: Juniper Networks IP-Based Mobile Backhaul Solution.....................80Figure 18:Configure LSP Paths Wizard...........................................................82Figure 19:Configure Protocols on Interfaces ..................................................84Figure 20:Steps for Tunnel Provisioning ........................................................86Figure 21:MPLS/GRE Tunnel Provisioning......................................................87Figure 22:MPLS/GRE Tunnel Provisioning......................................................89Figure 23:MPLS/GRE Tunnel Provisioning......................................................92Figure 24:MPLS/GRE Tunnel Provisioning......................................................93Figure 25:Add Schedule Menu .......................................................................94Figure 26:Pseudowire Template ....................................................................95Figure 27:Steps for Pseudowire Provisioning .................................................97Figure 28:Pseudowire Provisioning................................................................98Figure 29:Pseudowire Provisioning Endpoint Details ...................................100Figure 30:Pseudowire Provisioning Confirmation ........................................102Figure 31:Pseudowire Provisioning Scheduling............................................103Figure 32:Filter and Test Pseudowires .........................................................104Figure 33:Pseudowire Filter Results .............................................................105Figure 34:Pseudowire Circuit Details ...........................................................106Figure 35:Show l2circuit connections Test Result ........................................107Figure 36:Software Management .................................................................108Figure 37:Software Manager Installation Options ........................................109Figure 38: Inventory Management................................................................110

VII

List of Tables

Table 1: Pseudowire Template Parameters..................................................96

List of Tables VIII

Introduction

Chapter 1

Introduction

This guide provides a high-level, end-to-end overview of the configuration process for a creating a mobile backhaul pseudowire (virtual circuit) over a packet-switched network in a laboratory situation. While each individual component has (or will have) its own technical documentation, this configuration guide is designed to be a standalone guide to the overall process.

Overview on page 1

Components on page 2

Pseudowires on page 5

Why Juniper Networks? on page 6

Overview

Mobile carrier consumers are demanding more wireless services—especially bandwidth-hungry data services. New value-added services such as push-to-talk, interactive gaming, multimedia messaging, mobile VPNs, and video streaming offer mobile carriers avenues to grow subscriber bases and revenues.

Realizing the potential gains requires upgrading the mobile infrastructure, in particular, the mobile backhaul. Limitations of the existing mobile backhaul include:

Cost—For mobile backhaul today, mobile operators use copper or microwave time-division multiplexing (TDM) links, often leased from other service providers. The cost is high: $24.6 billion worldwide in 2007, expected to rise to $34 billion in 2008—representing up to 30 percent of all OPEX expenditures. Unlike infrastructure costs, this expense is ongoing, draining profits and impacting competitiveness. Any cost savings realized in backhaul go straight to the bottom line.

Scalability—A typical cell site requires two or three leased T1/E1 lines, repre-senting 4 to 6 Mbps of bandwidth. New data-intensive mobile services could double this requirement, and more. Adding this much capacity via TDM lines is time consuming and economically prohibitive. Carriers need the ability to add capacity on demand to respond to changing customer needs.

Flexibility—As mobile networks evolve from 2G to 3G and beyond, cell sites must support multiple transport technologies such as TDM, Asynchronous Transfer Mode (ATM), and IP/Ethernet. Carriers have substantial investments in 2G technology, so a rip-and-replace strategy is not feasible. The next generation of backhaul components must support the multiple coexistent technologies at the cell site.

Overview 1


2

Efficiency—Because each T1/E1 line is dedicated, excess capacity cannot be shared. The current method of providing backhaul capacity invariably involves a substantial amount of unused and expensive bandwidth in the mobile backhaul.

The IP-based mobile backhaul solution shown in this guide is an alternative that can pay off in a large way for mobile operators. It allows mobile operators to leverage the cost-effective, scalable, efficient IP/MPLS-based technology that is already in use in many mobile packet cores across the entire mobile infrastructure.

Components

Juniper Networks has leveraged its expertise in IP/MPLS technology and mobile packet backbone networks to develop an end-to-end mobile backhaul solution featuring the BX7000 Multi-Access Gateway, and the Juniper Networks Aggregation Site Gateway, with metro Ethernet aggregation provided by Juniper Networks proven MX Series routers (see Figure 1 on page 2). The components of Juniper Networks mobile backhaul solution are:

Gateways—BX7000 Multi-Access Gateway.

Backhaul routers—Although these can be a number of Juniper Networks devices, the test bed uses the MX Series routers.

Aggregation Site Gateway—This is an M Series router with Circuit Emulation Service (CES) Physical Interface Cards (PICs).

JUNOScope—This is Juniper Networks standard JUNOScope software adapted for use in the mobile backhaul space.

The interconnections between these components is shown in Figure 1 on page 2, and a detailed description of each of the components follows.

Figure 1: Juniper Networks Mobile Backhaul Solution Example Circuit

Aggregation Site

3G

2G

4G

Cell Site

TDM

ATM

IP/Ethernet

MX480MX240

Metro Backhaul Network

BX7000 M Series

RNC

RNC

BSCTDM

ATM

IP/Ethernet

JUNOScope

g017

328

Components

Introduction

BX7000 Multi-Access GatewayThe BX7000 Multi-Access Gateway interfaces with 2G (TDM) and 3G (ATM) cell sites, and will support 4G technologies (IP/Ethernet) as they are deployed. The BX7000 gateway combines these inputs, allowing them to be transported over a packet-based IP/MPLS infrastructure using Pseudowire Emulation (PWE) technology. With the BX7000 gateway, carriers can retain their existing investment in 2G and 3G cell sites while reaping the benefits of IP/MPLS-based transport. The BX7000 gateway can be adapted to any new emerging 3G or 4G technology with the simple addition of an interface card.

Aggregation Site Gateway (M Series Router with CES PICs)At the other end of the backhaul network, the Aggregation Site Gateway terminates the pseudowires, routing TDM traffic to the Base Station Controller (BSC), and ATM and IP traffic to the Radio Network Controller (RNC). The Aggregation Site Gateway also routes native IP traffic directly to the public Internet and other IP networks

The Aggregation Site Gateway is based on the M Series router architecture. To adapt this platform to the specific requirements of mobile backhaul, Juniper Networks has developed two Circuit Emulation Service (CES) Physical Interface Cards (PICs) specifically for the Aggregation Site Gateway.

12-Port T1/E1 CES PICs

4-Port ChOC3/STM1 CES PICs

Ethernet Services Routers for Metro Backhaul TransportThe M Series and MX Series routers are ideal for IP/MPLS-based backhaul transport. They offer all the benefits of IP/MPLS:

Fast reroute

Resiliency

Reliability

Operation, Administration, and Management (OAM)

The M Series and MX Series implement both Layer 2 and Layer 3 VPNs.

While the Juniper Networks solution is fully interoperable with a wide range of metro aggregation architectures and components, there are a number of advantages to using MX Series routers, including:

Pseudowire VPLS interworking—The Juniper Networks solution with MX Series routers supports pseudowire interworking with VPLS, in which an access pseudowire from the BX7000 Multi-Access Gateway is cross-connected with a point-to-point VPLS instance in the metro backhaul network. This feature allows mobile operators to address a number of technical requirements, including multihoming, control plane scaling, and multicasting, as well as segmentation issues that can arise when backhaul components reside in different administrative domains.

Components 3


4

Comprehensive network management—The JUNOScope IP Service Manager allows network operators to manage the full end-to-end mobile backhaul network from a central location, as described in “JUNOScope IP Service Manager with Extensions for Mobile Backhaul” on page 4.

JUNOScope IP Service Manager with Extensions for Mobile BackhaulJUNOScope is a suite of comprehensive Web-based tools for operational management and administration of Juniper Networks routers, including the BX7000 gateway, M Series, and MX Series. JUNOScope has been extended with powerful new features designed to address the demanding requirements of mobile backhaul.

Using JUNOScope, network managers can provision services, manage device configurations, track inventory, diagnose faults, and monitor the backhaul infrastructure from a central location. JUNOScope can push software upgrades to all the components in the Juniper Networks mobile backhaul solution, minimizing the need for costly site visits. As a result, JUNOScope reduces operating costs and improves operational efficiency.

Components

Introduction

Pseudowires

A pseudowire is a way to carry Layer 1 and Layer 2 information over an IP/MPLS network infrastructure. Emulation is required in this application because the native information being transported (ATM, Frame Relay, and TDM) is connection-oriented whereas the IP-based infrastructure is not. Therefore, pseudowire emulation (PWE) must provide the same timing and deliver mechanisms as the native protocol. Ideally, PWE is transparent, that is, the transport looks exactly the same as if it were happening in the native protocol. In practice, PWE is considered effective if it meets the key performance criteria of the native protocol.

A typical issue in PWE is synchronization, which is essential for TDM-based communications. The TDM receiving device must be synchronized with the sending device so that it can accurately read data from time slots. TDM networks accomplish this synchronization by sending clocking information along with the data on dedicated circuits.

IP networks have no corresponding built-in timing mechanism. Therefore, transmitting TDM over IP requires the receiving device to derive the clock from information in the incoming packet stream. Juniper Networks proven circuit-to-packet technology ensures that TDM transmissions are as reliable as native TDM.

Pseudowires 5


6

Why Juniper Networks?

Juniper Networks has been helping service providers evolve to a secure, converged IP infrastructure for many years. Our products for mobile operators feature industry-leading IP/MPLS expertise; comprehensive and proven security, authorization and authentication; and open and scalable solutions to enable a flexible IP/MPLS core. Now this expertise comes to the radio access network (RAN) with an end-to-end solution that addresses the current needs of the mobile carrier, and provides a scalable and flexible platform for growth and expansion in the years to come.

Financial Benefits of the Juniper Networks Mobile Backhaul SolutionMobile carriers are beginning to view the mobile backhaul as not just an out-of-pocket expense but a strategic asset, key to their success in tomorrow's highly competitive and bandwidth-intensive marketplace. The Juniper Networks end-to-end mobile backhaul solution offers carriers solid advantages, including reduced operating expenses, improved scalability, high reliability, streamlined administration, and investment protection.

Reduced operational expenditures—Extending IP/MPLS (a proven and familiar technology for most mobile operators) into backhaul can offer substantial reductions in cost-per-bit for backhaul transport. For example, replacing three T1 lines with carrier Ethernet results in savings of up to 70 percent or more for each cell site. The comprehensive network management features of the Juniper Networks solution greatly reduce ongoing operational expenses and increase operational efficiency. The Juniper Networks solution virtually eliminates site visits except for hardware upgrades.

Enable new revenue streams—With Juniper Networks’ IP/MPLS mobile backhaul solution, operators can create new revenue streams by enforcing Quality of Service (QoS), prioritizing certain traffic (for example, real-time services) in the Aggregation Site Gateway backhaul, and charging a premium from the content service providers on one hand and from the end users on the other side. Juniper Networks offers a complete solution for mobile backhaul, allowing mobile operators to leverage our core competencies of QoS differentiation, security, and reliability to not only reduce their OPEX, but also create new revenue streams by building new end services using our end-to-end capabilities.

Improved Scalability—Juniper Networks IP/MPLS-based mobile backhaul solution scales much more easily than other solutions, since operators can purchase incremental bandwidth as needed from fixed-line operators. Using packet-based backhaul avoids the problem of unused bandwidth that is common with TDM leased-line backhaul. Operators can also consolidate all traffic on a single cost-efficient and high-speed Ethernet uplink as opposed to multiple groups of slow and expensive TDM circuits. In addition, because of carrier Ethernet’s option of fine-grained bandwidth, mobile operators can “pay as they grow,” dialing up bandwidth as subscriber traffic increases.

Investment protection—The BX7000 gateway interfaces with 2G cell sites, making it an easy addition to existing infrastructures. At the same time, the Juniper Networks solution supports 3G and evolving 4G technology to future-proof investments in cell site installations. Juniper Networks comprehensive mobile backhaul solution allows mobile operators to use an


Introduction

end-to-end common IP/MPLS transport network that can support L1/L2 backhaul as well as business and residential services.

Technical Benefits of the Juniper Networks Mobile Backhaul SolutionFollowing are the technical benefits of Juniper Networks mobile backhaul solution.

High reliability—When moving to IP-based backhaul, mobile carriers are assured that the network performance will be up to the standards of TDM transport.

Streamlined administration

Zero-touch provisioning, MPLS plug-and-play.

Carrier investments in training for IP/MPLS are leveraged by using IP/MPLS in the backhaul network.

Clock synchronization—Timing and synchronization are critical elements in a radio access network for maintaining the quality of real-time traffic (like voice) and increasing the capacity of the radio network by eliminating interference. Juniper Networks mobile backhaul solution incorporates sophisticated clocking and synchronization mechanisms to ensure the voice traffic quality stays high and the high capacity that the radio networks dictate is available. Our mobile backhaul complies with the IEEE 1588v2 specification.

Comprehensive radio access network backhaul solution—Juniper Networks IP/MPLS mobile backhaul solution is an end-to-end complete solution comprised of the BX7000 Multi-Access Gateway, the Aggregation Site Gateway, and the MX Series portfolio for backhaul aggregation.

Support for Multiple backhaul technologies—Juniper Networks comprehensive mobile backhaul solution allows mobile operators to have a common IP/MPLS Aggregation Site Gateway backbone that can support multiple types of L1/L2 backhauls such as TDM, ATM, DSL, and Ethernet. This allows the co-existence and leveraging of legacy, current, and future backhaul mechanisms based on a common MPLS backbone.

Services closer to the end subscriber—Juniper Networks proven IP expertise and MPLS leadership with associated strengths in the areas of QoS and routing, allow operators to have the ability to host location-based and push services at the cell site router or at the edge of the aggregation site gateway where it is operationally feasible to do so.

Leadership in MPLS—Juniper Networks believes that MPLS is the best-suited technology for Aggregation Site Gateway backhaul and provides the most scalability, flexibility, performance, and reliability to the operators. To this end, Juniper Networks is leading the effort in the standards bodies to promote MPLS as the best solution for mobile backhaul.

Why Juniper Networks? 7


8

Chapter 2

Provisioning the Service

Figure 2 on page 9 shows how the BX7000 Multi-Access Gateway and the M10i router are used in a normal operational situation. In this configuration, the T1/E1 link between the base transceiver station (BTS) and the base station controller (BSC) is replaced by a pseudowire running on a BX7000 Multi-Access Gateway at the cell site, and an M10i router at the aggregation site. These devices communicate over an MPLS-enabled Ethernet backhaul network.

Figure 2: Normal Backhaul Configuration

This chapter shows the network topology that is used when configuring this pseudowire in the laboratory. The BTS and BSC are replaced with a broadband test system to evaluate the performance of the link. The configuration information is shown for four different use cases.

SAToP (TDM) pseudowire configuration

ATM pseudowire configuration

The instructions in this chapter assume that you have equipment that has been updated to at least these revisions:

JUNOS version: 9.5 or later

BX7000 gateway image: bxos-install-3.0R2

NOTE: If your equipment does not meet these specifications, follow the instructions in “Upgrading the Software” on page 111 to bring your equipment up to specification.

This chapter contains the following sections:

SAToP Pseudowire Configuration on page 10

ATM Pseudowire Topology and Configuration on page 36

PE2PE1

g017

329

BX7000 Multi-Access Gateway M10i router

T1/E1 T1/E1Gigabit Ethernet

MPLS-Enabled Ethernet Backhaul Network

BaseTransciever

Station

BaseStation

Controller

9


10

SAToP Pseudowire Configuration

This section provides samples for provisioning the network in a SAToP pseudowire configuration. Commands for provisioning each of the links are shown in the following:

BX7000 Gateway to BX7000 Gateway Provisioning on page 10

BX7000 Gateway to M10i Router Provisioning on page 14

M10i Router to M10i Router SAToP Pseudowire Configuration on page 18

BX7000 Gateway to BX7000 Gateway ProvisioningFigure 3 on page 10 shows the SAToP pseudowire topology that is used in this example.

Figure 3: SAToP Pseudowire Topology for BX7000 Gateway to BX7000 Gateway

In this diagram, Gateway 1 and Gateway 2 are BX7000 Multi-Access Gateways that are connected together by Gigabit Ethernet ge-1/0/1. The Gateway 1 and Gateway 2 BX7000 Multi-Access Gateways are connected to the traffic tool over a T1 line.

Use the following commands to provision the BX7000 gateways.

Gateway 1To provision Gateway 1, type these commands:

bx7000@CLI# edit interface lo0 set admin-state enableedit unit 0 set family inet address 80.0.0.1/32topcommit

edit interface ge-1/0/1set admin-state enableedit unit 0set family inet address 11.11.11.1/24topcommit

g017

333

Gateway 1

BX7000 Multi-Access Gateway

Gigabit EthernetGateway 2


Traffic Tool

T1 line T1 line

t1-0/0/0 t1-0/0/0

ge-1/0/1 ge-1/0/1



edit protocol ospfset admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveupedit interface ge-1/0/1set admin-state enableset priority 3topcommit

edit protocol rsvpset admin-state enedit interface ge-1/0/1set admin-state entopcommit

edit protocol mplsedit interface ge-1/0/1set admin-state entopcommit

edit protocol ldpset admin-state enableedit interface ge-1/0/1set admin-state enabletopcommit

edit protocol mplsedit label-switch-path t1set from-address 11.11.11.1set to-address 11.11.11.2topcommit

set framer-mode t1commit

edit interface t1-0/0/0set encapsulation transset framing unframeset admin-state enableupcommit

edit protocol ldpedit l2circuit p1edit neighbor-address 11.11.11.2set tunnel t1edit interface t1-0/0/0set remote-vc-id 1set payload 96set jitter-buffer 5000set lossy-state-entry 12set idle-pattern 255

SAToP Pseudowire Configuration 11


12

set dummy-pattern 170topcommitbx7000@CLI#

Gateway 2To provision Gateway 2, type these commands:



edit protocol ospfset admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveupedit interface ge-1/0/1set admin-state enableset priority 3topcommit


edit protocol mplsedit interface ge-1/0/1set admin-state entopcommit edit protocol ldpset admin-state enableedit interface ge-1/0/1set admin-state enabletopcommit

edit protocol mplsedit label-switch-path t1set from-address 11.11.11.2set to-address 11.11.11.1top



commit


edit interface t1-0/0/0set encapsulation transset framing unframeset admin-state enableupcommit

edit protocol ldpedit l2circuit p1edit neighbor-address 11.11.11.1set tunnel t1edit interface t1-0/0/0set remote-vc-id 1set payload 96set jitter-buffer 5000set lossy-state-entry 12set idle-pattern 255set dummy-pattern 170topcommitbx7000@CLI#



14

BX7000 Gateway to M10i Router ProvisioningFigure 4 on page 14 shows the topology for the BX7000 Gateway A to the M10i router Gateway B link.

Figure 4: SAToP Pseudowire Topology for BX7000 Gateway to M10i Router

In this example, Gateway B is an M10i router with a 12-port CES PIC in FPC 1, PIC slot 1; and t1-1/1/1 is a port on the CES PIC.

BX7000 Gateway A ConfigurationThis section shows the configuration commands that need to be entered into the BX7000 gateway. Enter these commands in configuration mode:

bx7000@CLI# edit interface lo0set admin-state enedit unit 0 set family inet address 80.0.0.2/32topcommit


edit protocol ospfset admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveupedit interface ge-1/0/2set admin-state enabletopcommit

edit protocol rsvpset admin-state enedit interface ge-1/0/2set admin-state entop

g017

334

Gateway A


Gigabit EthernetGateway B

M10i router

Traffic Tool

T1 line T1 line

t1-0/0/0 t1-1/1/1

ge-1/0/2 ge-1/2/0



commit



edit protocol mplsedit label-switch-path t1set from-address 80.0.0.2set to-address 80.0.0.99upcommit

edit protocol ldpset mpls ldp targeted-hello send 80.0.0.99;top commit


edit interface t1-0/0/0 set encapsulation transset framing unframeset admin-state enableset admin-state enabletopcommit

edit protocol ldpedit l2circuit satop1edit neighbor-address 80.0.0.99set tunnel t1edit interface t1-0/0/0set remote-vc-id 111set payload 192set jitter-buffer 5000set lossy-state-entry 12set idle-pattern 255set dummy-pattern 170topcommitbx7000@CLI#



16

M10i Router Gateway B ConfigurationThis section shows a list of the relevant configuration information after provisioning the router.

root@gatewayB> show configuration interfaces ct1-1/1/1 { no-partition interface-type t1;}t1-1/1/1 { encapsulation satop; unit 0;}ge-1/2/0 { description "connected to BX7000 (gatewayA) ge-1/0/2"; unit 0 { family inet { address 99.1.1.1/24; } family mpls; }}lo0 { unit 0 { family inet { address 80.0.0.99/32; } }} root@gatewayB>

root@gatewayB> show configuration protocols rsvp { interface ge-1/2/0.0;}mpls { label-switched-path to_gatewayA { to 80.0.0.2; } interface ge-1/2/0.0;}isis { disable; interface all { level 1 disable; level 2 metric 10; } interface fxp0.0 { disable; }}ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } }}ldp {



traceoptions { file ldp; flag periodic; } interface all;}l2circuit { traceoptions { file l2ckt size 10m; flag all; } neighbor 80.0.0.2 { interface t1-1/1/1.0 { virtual-circuit-id 111; } }}

root@gatewayB>



18

M10i Router to M10i Router SAToP Pseudowire ConfigurationFigure 5 on page 18 shows the topology for the M10i router Gateway C to the M10i router Gateway D link.

Figure 5: SAToP Pseudowire Topology for M10i Router to M10i Router

In this example, both gateways are M10i routers with a 12-port CES PIC in FPC 1, PIC slot 1. Interface t1-0/0/0 is a port on the CES PIC. Both gateways are connected via SONET interface 0/2/0.

M10i Router Gateway C ConfigurationThis section lists the relevant configuration information after provisioning the Gateway C router.

groups { re0 { system { host-name gatewayC; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.236/26; } } } } } global { system { .... }

Interfaces { lo0 { unit 0 { family inet { address 10.255.243.101/32; address 127.0.0.1/32; } } } }

g017

335

Gigabit EthernetGateway D

M10i router

Traffic Tool

T1 line T1 line

t1-0/0/0 t1-0/0/0

so-0/2/0 so-0/2/0Gateway C

M10i router



... } re1;}apply-groups [ global re0 re1 ];system {... services { ftp; rlogin; rsh; telnet; }}

...interfaces { ct1-0/0/0 { no-partition interface-type t1; } t1-0/0/0 { encapsulation satop; unit 0; } ct1-0/0/6 { no-partition interface-type t1; } t1-0/0/6 { encapsulation satop; unit 0; } coc3-0/2/0 { no-partition interface-type so; } so-0/2/0 { unit 0 { family inet { address 10.20.30.2/24; } family mpls; } }}protocols { rsvp { interface so-0/2/0.0; } mpls { interface so-0/2/0.0; } isis { disable; interface all { level 1 disable; level 2 metric 10; } interface fxp0.0 { disable; } } ospf { reference-bandwidth 4g; area 0.0.0.0 {



20

interface all; interface fxp0.0 { disable; } } } ldp { interface all; } l2circuit { traceoptions { file l2ckt size 10m; flag all; } neighbor 10.255.243.102 { interface t1-0/0/0.0 { virtual-circuit-id 200; } } }}

M10i Router Gateway D ConfigurationThis section lists the relevant configuration information after provisioning the Gateway D router.

groups { re0 { system { host-name gatewayD; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.242/26; } } } } } re1 { system { host-name gatewayD1; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.243/26; } } } } } global { system { .... }



interfaces { lo0 { unit 0 { family inet { address 10.255.243.102/32 { primary; } address 127.0.0.1/32; } family iso { address 47.0005.80ff.f800.0000.0108.0001.0102.5504.9242.00; } family inet6 { address abcd::10:255:49:242/128 { primary; } } } } } ...}apply-groups [ global re0 re1 ];...

interfaces { ct1-0/0/0 { no-partition interface-type t1; } t1-0/0/0 { encapsulation satop; unit 0; } ct1-0/0/6 { no-partition interface-type t1; } t1-0/0/6 { encapsulation satop; unit 0; } coc3-0/2/0 { no-partition interface-type so; } so-0/2/0 { unit 0 { family inet { address 10.20.30.1/24; } family mpls; } }}protocols { rsvp { interface so-0/2/0.0; } mpls { interface so-0/2/0.0; } isis { disable; interface all {



22

level 1 disable; level 2 metric 10; } interface fxp0.0 { disable; } } ospf { reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } ldp { interface all; } l2circuit { traceoptions { file l2ckt size 10m; flag all; } neighbor 10.255.243.101 { interface t1-0/0/0.0 { virtual-circuit-id 200; } } }}



BX7000 to M10i SAToP Pseudowire over GRE Tunnel ProvisioningFigure 6 on page 23 shows the topology for the BX7000 to the M10i router Gateway K link.

Figure 6: SAToP Pseudowire Topology for BX7000 Router to the M10i Router

In this example, Gateway K is an M10i router that has a 10xCT1/E1 PIC connected to the traffic tool. The BX7000 router is connected to the traffic tool through a T1 port. The BX7000 and Gateway K are connected back-to-back through the ge-1/0/1 and fe-0/0/3, respectively.

BX7000 Gateway ConfigurationTo provision the BX7000 Gateway, type the following commands:



edit interface gr-t1edit unit 0set admin-state enableset family inet address 10.10.10.1/24set clear-dont-fragment-bit enableset mtu 1500edit tunnelset source-address 80.0.0.3set destination 80.0.0.99set ttl 64set topcommit

edit protocol ospf

g017

336

Gigabit EthernetGateway K

M10i router

Traffic Tool

T1 line T1 line

t1-0/0/2 t1-1/1/0

ge-1/0/1 fe-0/0/3




24

set admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveupedit interface ge-1/0/1set admin-state enableset priority 0topcommit

edit protocol mplsedit interface ge-1/0/1set admin-state enupedit interface gr-t1set admin-state enabletopcommit

edit protocol ldpset admin-state enabletopcommit

edit protocol ldp set mpls ldp targeted-hello send 80.0.0.99top commit

set tdm-mode t1commit

edit interface t1-0/0/2 set encapsulation transset framing unframedset admin-state enableupcommit

edit protocol ldpedit l2circuit l2c1edit neighbor-address 80.0.0.99set tunnel gr-t1edit interface t1-0/0/2set payload 192set jitter-buffer 5000set idle-pattern 255set dummy-pattern 170set lossy-state-entry 12set remote-vc-id 1001topcommitbx7000@CLI#



Provisioning Gateway KThis section lists the relevant configuration information after provisioning the gateway.

NOTE: The inet.3 static route is needed on the M10i router, which is shown at the end of this configuration.

interfaces {...

lo0 { unit 0 { family inet { address 80.0.0.99/32; } }}…fe-0/0/3 { unit 0 { family inet { address 97.1.1.1/24; } family mpls; }}…ct1-1/1/0 { clocking external; no-partition interface-type t1;}t1-1/1/0 { clocking external; encapsulation satop; unit 0;}…gr-0/2/0 { unit 0 { tunnel { source 80.0.0.99; destination 80.0.0.3; } family inet { address 10.10.10.2/24; } family mpls; }}

…protocols{mpls {

label-switched-path to_bx7000 { to 80.0.0.3;

}interface fe-0/0/3.0;



26

interface gr-0/2/0.0;}ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; }

interface fe-0/0/3.0 { bfd-liveness-detection { minimum-interval 3; } }}ldp {

interface all;}

l2circuit { neighbor 80.0.0.3 { interface t1-1/1/0.0 { virtual-circuit-id 1001; } } }

Under routing-options, configure the following:

rib inet.3 { static { route 80.0.0.3/32 next-hop gr-0/2/0.0; <=== inet.3 static route entry is needed. }}



BX7000 to M10i (with CHOC3/STM1 Circuit Emulation PIC) SAToP Pseudowire Configuration with Bypass Tunnel Configuration

Figure 7 on page 27 shows the BX7000 to the M10i router (with CHOC3/STM1 Circuit Emulation PIC) SAToP pseudowire configuration with a bypass tunnel configuration.

Figure 7: BX7000 to the M10i SAToP Pseudowire Configuration with Bypass Tunnel Configuration

In the topology shown in this example, a CHOC3/STM1 Circuit Emulation PIC is used at FPC slot 0 and PIC slot 2.

BX7000 Multi-Access Gateway ConfigurationThis section lists the relevant configuration information after provisioning the BX7000 gateway.

userid@BX7000# show

system { framer-mode T1;}interfaces { ge-1/0/0 { admin-state enable; unit 0 { family inet address 172.17.49.178/24; } } ge-1/0/1 { admin-state enable; unit 0 { family inet address 95.1.1.1/24; } } ge-1/0/2 { admin-state enable; unit 0 { family inet address 94.1.1.1/24; } } lo0 { admin-state enable; unit 0 { family inet address 80.0.0.3/32; } }

PE2PE1 CE2CE1

g017

330


T1-0/0/0 T1-0/2/0:1:1.0ge-1/0/1

ge-1/0/2

ge-0/0/1

ge-0/0/2



28

t1-0/0/0 { admin-state enable; encapsulation trans; framing unframed; }}protocols { ospf { admin-state enable; spf-delay 200; area 0.0.0.0 { interface lo0 { admin-state enable; interface-type loopback; mode passive; } interface ge-1/0/1 { admin-state enable; } interface ge-1/0/2 { admin-state enable; } } } ldp { admin-state enable; mpls ldp targeted-hello send 10.255.49.163; l2circuit l2c1 { neighbor-address 10.255.49.163 { tunnel t1; interface t1-0/0/0 { payload 192; jitter-buffer 5000; idle-pattern 255; dummy-pattern 170; lossy-state-entry 12; remote-vc-id 1001; } } } } rsvp { admin-state enable; interface ge-1/0/1 { admin-state enable; } interface ge-1/0/2 { admin-state enable; } } mpls { label-switched-path t1 { to-address 10.255.49.163; from-address 80.0.0.3; link-protection enable; primary t1 { setup-priority 7; reservation-priority 0; } path 95.1.1.1 strict; path 95.1.1.2 strict; }



interface ge-1/0/1 { admin-state enable; } interface ge-1/0/2 { admin-state enable; } bypass by1 { path 94.1.1.1 path-option strict; path 94.1.1.2 path-option strict; priority 7 0; from-address 94.1.1.1; to-address 94.1.1.2; protect ge-1/0/1; } bypass by2 { path 95.1.1.1 path-option strict; path 95.1.1.2 path-option strict; priority 7 0; from-address 95.1.1.1; to-address 95.1.1.2; protect ge-1/0/2; } } static-route { route 0.0.0.0/0 { next-hop 172.17.49.129; } route 172.0.0.0/8 { next-hop 172.17.49.129; } }}

The following are examples of the show command output after configuration.

userid@BX7000# show interface

Physical interface :ge-1/0/0, Enabled, Physical Link : Up Logical interface :ge-1/0/0.0, Interface index:3 Link-level type: Ethernet, MTU: 1500 Operational state : Enabled Speed :100 Mbps, Loopback : Disabled Mode : Full-duplex, Flowcontrol : Disabled Vlan Tagging : Disabled Auto negotiation : Enabled , Source filtering : Disabled Local address : 172.17.49.178 Network address : 172.17.49.0 Prefix length : 24 Physical Address : 00:1f:12:80:2f:80 Description :




30


Loopback Interface : lo0 , Enabled Operational state : Enabled Interface index:6 Local address: 80.0.0.3 Prefix length:32

ISO Address [0]: ISO Address [1]: ISO Address [2]:

Physical interface :t1-0/0/0, Enabled, Physical Link : Up Interface index:61441 MTU : 0, Speed :1544000, Loopback: Disabled Operational state : Enabled, Encapsulation : Trans Encoding : b8zs, Framing : unframe, Build-out : 0-132 Clock source : master Description :

[edit]userid@BX7000# show ospf neighbor

Address Interface State ID Priority94.1.1.2 ge-1/0/2 Full 10.255.49.163 12895.1.1.2 ge-1/0/1 Full 10.255.49.163 128

userid@BX7000# show mpls tunnelIngress LSP: 3 sessions To From State LSPname Labelin Labelout 10.255.49.163 80.0.0.3 Up t1 - - 94.1.1.2 94.1.1.1 Up by1 - - 95.1.1.2 95.1.1.1 Up by2 - -

Total 3 displayed, Up 3, Down 0

Egress LSP: 2 sessions To From State LSPname Labelin Labelout 80.0.0.3 10.255.49.163 Up t2 - - 80.0.0.3 10.255.49.163 Up Bypass->95.1.1.1 - -

Total 2 displayed, Up 2, Down 0



[edit]userid@BX7000# show l2circuit l2c1 extensive

PW FEC ID : 1001 Neighbour address : 10.255.49.163 Prefered path : t1 Type : RSVP Group VC FEC : 0 VC type and control word bit : 18 Control Word : Enabled Pseudowire Type : satop Number of attached Interfaces : 1 Attached Interface : t1-0/0/0 Payload : 192 bytes Bit-rate : 24 Jitter buffer : 5000 micro seconds Sequence window : 0 Alarm set time: 2 milli-seconds, clear time: 10 milli-seconds Idle pattern : 255 Packet loss threshold : 12 Packet sequence threshold: 0 Replacement policy : 170 Setup sync packets : 0, sync time : 0 RTP : Disabled

Admin status : Up Operational status : Up SATOP pseudo-wire statistics: MPLS in-label : 16 MPLS out-label : 299776 PSN to TDM Direction -------------------- Forwarded packets : 2706361 Free buffer drops : 0 Under-run drops : 0 Stray packets : 0 Malformed packets : 0 Duplicate packets : 0 Error drops : 0 Denied packets : 0 Reordered packets : 0 Transit packets : 2706275 Dummy transit packets : 0 Idle transit packets : 1689 Out-of-sequence packets : 0 Sequence window switchover: 0 Buffer over-run events : 0 Buffer under-run events : 6

TDM to PSN Direction -------------------- Rx Valid packets : 2707137 Forwarded packets : 2707137 Free buffer events : 0 Free buffer drops : 0 MTU drops : 0 Congestion drops : 0

[edit]userid@BX7000#



32

M10i Router ConfigurationThis section lists the relevant configuration information after provisioning the M10i router.

[edit]userid@m10i# show interfacesge-0/0/1 { unit 0 { family inet { address 95.1.1.2/24; } family mpls; }}ge-0/0/2 { unit 0 { family inet { address 94.1.1.2/24; } family mpls; }}coc3-0/2/0 { clocking external; partition 1 oc-slice 1 interface-type coc1;}coc1-0/2/0:1 { partition 1 interface-type t1;}t1-0/2/0:1:1 { satop-options idle-pattern 64; clocking external; encapsulation satop; unit 0;}lo0 { unit 0 { family inet { address 10.255.49.163/32; } }}

[edit]userid@m10i # show protocolsrsvp { interface ge-0/0/1.0 { link-protection; } interface ge-0/0/2.0;}mpls { label-switched-path t2 { from 10.255.49.163; to 80.0.0.3; link-protection; primary p2; } path p2 { 95.1.1.1 strict; }



interface ge-0/0/1.0; interface ge-0/0/2.0;}ospf { traffic-engineering; area 0.0.0.0 { interface lo0.0 { passive; } interface ge-0/0/1.0; interface ge-0/0/2.0; }}ldp { interface ge-0/0/1.0; interface ge-0/0/2.0; interface lo0.0;}l2circuit { neighbor 80.0.0.3 { interface t1-0/2/0:1:1.0 { virtual-circuit-id 1001; } }}

[edit]userid@m10i #

The following lists are examples of the run show command output after configuration.

userid@m10i # run show interfaces coc3-0/2/0Physical interface: coc3-0/2/0, Enabled, Physical link is UpInterface index: 140, SNMP ifIndex: 116Link-level type: Controller, Clocking: External, SONET mode, Speed: OC3,Loopback: None, Parent: NoneDevice flags : Present RunningInterface flags: Point-To-Point SNMP-Traps Internal: 0x4000Link flags : NoneCoS queues : 4 supported, 4 maximum usable queuesLast flapped : 2009-01-12 23:11:46 PST (01:21:03 ago)Interface preservation: disabledSONET alarms : NoneSONET defects : None

[edit]userid@m10i # run show interfaces coc1-0/2/0:1Physical interface: coc1-0/2/0:1, Enabled, Physical link is UpInterface index: 142, SNMP ifIndex: 395Link-level type: Controller, Clocking: Internal, SONET mode, Speed:

51840kbps,Loopback: None, Parent: coc3-0/2/0 Interface index 140Device flags : Present RunningInterface flags: Point-To-Point SNMP-Traps Internal: 0x4000Link flags : NoneCoS queues : 4 supported, 4 maximum usable queuesLast flapped : 2009-01-12 23:12:27 PST (01:20:36 ago)SONET alarms : NoneSONET defects : None



34

[edit]userid@m10i # run show interfaces t1-0/2/0:1:1Physical interface: t1-0/2/0:1:1, Enabled, Physical link is UpInterface index: 144, SNMP ifIndex: 396Link-level type: TDM-CCC-SATOP, MTU: 1504, Clocking: External, Speed: T1,Loopback: None, FCS: 16, Framing: ESF,Parent: coc1-0/2/0:1 Interface index 142Device flags : Present RunningInterface flags: Point-To-Point SNMP-Traps Internal: 0x4000CoS queues : 4 supported, 4 maximum usable queuesLast flapped : 2009-01-12 23:12:27 PST (01:20:59 ago)DS1 alarms : NoneDS1 defects : NoneSONET alarms : NoneSONET defects : None

Logical interface t1-0/2/0:1:1.0 (Index 71) (SNMP ifIndex 397)Flags: Point-To-Point SNMP-Traps Encapsulation: TDM-CCC-SATOPProtocol ccc, MTU: 1504Flags: Is-Primary

[edit]userid@m10i # run show ospf neighborAddress Interface State ID Pri Dead95.1.1.1 ge-0/0/1.0 Full 80.0.0.3 1 3994.1.1.1 ge-0/0/2.0 Full 80.0.0.3 1 39

[edit]userid@m10i # run show rsvp sessionIngress RSVP: 2 sessionsTo From State Rt Style Labelin Labelout LSPname80.0.0.3 10.255.49.163 Up 0 1 SE - 3 t280.0.0.3 10.255.49.163 Up 0 1 SE - 3 Bypass->95.1.1.1Total 2 displayed, Up 2, Down 0

Egress RSVP: 3 sessionsTo From State Rt Style Labelin Labelout LSPname10.255.49.163 80.0.0.3 Up 0 1 SE 3 - t194.1.1.2 94.1.1.1 Up 0 1 SE 3 - by195.1.1.2 95.1.1.1 Up 0 1 SE 3 - by2Total 3 displayed, Up 3, Down 0

Transit RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

[edit]userid@m10i # run show l2circuit connections extensiveLayer-2 Circuit Connections:

Legend for connection status (St)EI -- encapsulation invalid NP -- interface h/w not presentMM -- mtu mismatch Dn -- downEM -- encapsulation mismatch VC-Dn -- Virtual circuit DownCM -- control-word mismatch Up -- operationalVM -- vlan id mismatch CF -- Call admission control failureOL -- no outgoing label IB -- TDM incompatible bitrateNC -- intf encaps not CCC/TCC TM -- TDM misconfigurationBK -- Backup Connection ST -- Standby ConnectionCB -- rcvd cell-bundle size bad XX -- unknown



Legend for interface statusUp -- operationalDn -- downNeighbor: 80.0.0.3 Interface Type St Time last up # Up trans t1-0/2/0:1:1.0(vc 1001) rmt Up Jan 12 23:35:08 2009 1 Remote PE: 80.0.0.3, Negotiated control-word: Yes (Non-null) Incoming label: 299776, Outgoing label: 16 Local interface: t1-0/2/0:1:1.0, Status: Up, Encapsulation: SATOP-T1 Connection History: Jan 12 23:35:08 2009 status update timer Jan 12 23:35:08 2009 PE route changed Jan 12 23:35:08 2009 In lbl Update 299776 Jan 12 23:35:08 2009 Out lbl Update 16 Jan 12 23:35:08 2009 In lbl Update 299776 Jan 12 23:35:08 2009 loc intf up t1-0/2/0:1:1.0

[edit]userid@m10i #



36

ATM Pseudowire Topology and Configuration

This section provides samples for provisioning the network in an ATM pseudowire configuration. Commands for provisioning each of the links are shown in the following section:

BX7000 Gateway to BX7000 Gateway Provisioning on page 36

M10i Router to M10i Router ATM Pseudowire Provisioning on page 40

BX7000 Gateway to M10i ATM Pseudowire Provisioning on page 48

BX7000 Gateway to BX7000 Gateway ProvisioningFigure 8 on page 36 shows the ATM pseudowire topology that is used in this example.

Figure 8: ATM Pseudowire Topology for BX7000 Gateway to BX7000 Gateway

In this example, Gateway 1 and Gateway 2 are BX7000 Multi-Access Gateways that are connected together by Gigabit Ethernet ge-1/0/1. The Gateway 1 and Gateway 2 BX7000 Multi-Access Gateways are connected to the traffic tool over a T1 line.

Gateway 1To provision Gateway 1, type the following commands:



edit protocol ospf

g017

337

Gigabit EthernetGateway 2

Traffic Tool

T1 line T1 line

t1-0/0/0 t1-0/0/0

ge-1/0/1 ge-1/0/1


Gateway 1




set admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveupedit interface ge-1/0/1set admin-state enableset priority 0topcommit




edit protocol mplsedit label-switch-path tun1set from-address 10.10.10.2set to-address 10.10.10.1topcommit


edit interface t1-0/0/0 set encapsulation atmset framing esfedit unit 1set vpi 10 vci 100set admin-state enableupset admin-state enableupcommit

edit protocol ldpedit l2circuit pwe1edit neighbor-address 10.10.10.1set tunnel tun1edit interface t1-0/0/0.1set remote-vc-id 1set pw-mode 1-to-1-vcc

ATM Pseudowire Topology and Configuration 37


38

set cell-concat 24 timeout 100set control-word enableset sequence-check enableset sequence-switchover 1topcommitbx7000@CLI#

Gateway 2To provision Gateway 2, type the following commands:



edit protocol ospfset admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveup

edit interface ge-1/0/1set admin-state enableset priority 3topcommit




edit protocol mplsedit label-switch-path tun1



set from-address 10.10.10.1set to-address 10.10.10.2topcommit



edit protocol ldpedit l2circuit pwe1edit neighbor-address 10.10.10.2set tunnel tun1edit interface t1-0/0/0.1set remote-vc-id 1set pw-mode 1-to-1-vccset cell-concat 24 timeout 100set control-word enableset sequence-check enableset sequence-switchover 1topcommitbx7000@CLI#



40

M10i Router to M10i Router ATM Pseudowire ProvisioningFigure 9 on page 40 shows the topology for the ATM pseudowire configuration used in the lab.

Figure 9: ATM Pseudowire Topology for M10i Router to M10i Router using ATM2-IQ PIC

The topology shown in this example is used for the ATM2-IQ based Layer 2 circuit configuration. This section lists the relevant configuration information after provisioning the router.

Gateway F Configurationroot@gatewayF> show 12circuit connections Layer-2 Circuit Connections:

Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failureOL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration CB -- rcvd cell-bundle size bad XX -- unknown

Legend for interface statusUp -- operational Dn -- down Neighbor: 10.255.49.242 Interface Type St Time last up # Up transat-1/3/0.0(vc 11) rmt Up Feb 19 21:35:58 2008 1 Local interface: at-1/3/0.0, Status: Up, Encapsulation: ATM CELL (VC Mode) Remote PE: 10.255.49.242, Negotiated control-word: Yes (Non-null) Incoming label: 299808, Outgoing label: 299808root@gatewayF>

Gateway G Configuration

root@gatewayG> show 12circuit connections Layer-2 Circuit Connections:

Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failureOL -- no outgoing label IB -- TDM incompatible bitrate

PE2PE1 CES2CES1

g017

331

gatewayE gatewayF gatewayG gatewayH

atm-0/3/010.2.2.1/24

atm-1/3/0No IP address

11.1.1.1/24fe-0/0/1

11.1.1.2/24fe-1/3/0

atm-0/3/0No IP address

atm-1/1/010.2.2.2/24

lo0.0 = 10.255.49.240/32 lo0.0 = 10.255.49.242/32



NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration CB -- rcvd cell-bundle size bad XX -- unknown

Legend for interface statusUp -- operational Dn -- down Neighbor: 10.255.49.240 Interface Type St Time last up # Up transat-0/3/0.0(vc 11) rmt Up Feb 19 21:35:57 2008 1 Local interface: at-0/3/0.0, Status: Up, Encapsulation: ATM CELL (VC Mode) Remote PE: 10.255.49.240, Negotiated control-word: Yes (Non-null) Incoming label: 299808, Outgoing label: 299808

root@gatewayG>

Router ConfigurationThis section lists the relevant configuration information after provisioning the router.

Gateway E Configuration

groups { re0 { system { host-name gatewayE; backup-router 172.17.49.193 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.244/26; } } } } }…interfaces { lo0 { unit 0 { family inet { address 10.255.49.244/32 { primary; } } family iso { address 47.0005.80ff.f800.0000.0108.0001.0102.5504.9244.00; } family inet6 { address abcd::10:255:49:244/128 { primary; } } } }



42

}interfaces {at-0/3/0 { description "to gatewayF at-1/3/0"; atm-options { pic-type atm2; vpi 0; } unit 0 { vci 32; family inet { address 10.2.2.1/24; } } }}}routing-options { autonomous-system 69; forwarding-table { export pplb; } }protocols { isis { interface all { level 1 disable; } interface fxp0.0 { disable; } } ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } }}

Gateway F Configurationgroups { re0 { system { host-name gatewayF; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.240/26; } } } } }…



interfaces { lo0 { unit 0 { family inet { address 10.255.49.240/32 { primary; } address 127.0.0.1/32; } family iso { address 47.0005.80ff.f800.0000.0108.0001.0102.5504.9240.00; } family inet6 { address abcd::10:255:49:240/128 { primary; } } } } }….chassis { fpc 1 { pic 3 { atm-l2circuit-mode { cell; } } } images { pic { fpc-slot 0 { pic-slot 2 { inactive: command noboot; file jcano/ce-92.jbf; } } } }}

interfaces {fe-0/0/1 { description "to gatewayD fe-1/3/0"; unit 0 { family inet { address 11.1.1.1/24; } family mpls; } } ce1-1/0/0 { description "to gatewayD e1-1/0/0;"; partition 1 timeslots 1 interface-type ds; } at-1/3/0 { description "to gatewayE at-0/3/0"; encapsulation atm-ccc-cell-relay; atm-options { pic-type atm2; cell-bundle-size 4;



44

vpi 0; } unit 0 { encapsulation atm-ccc-cell-relay; vci 32; cell-bundle-size 10; } }}protocols { mpls { interface fe-0/0/1.0; } isis { disable; interface all { level 1 disable; level 2 metric 10; } interface fxp0.0 { disable; } } ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } ldp { interface fe-0/0/1.0; interface lo0.0; } l2circuit { neighbor 10.255.49.242 { interface at-1/3/0.0 { virtual-circuit-id 11; } } }}

Gateway G Configuration re0 { system { host-name gatewayG; backup-router 172.17.49.193 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.242/26; } } } } }



…chassis { fpc 0 { pic 3 { atm-l2circuit-mode { cell; } } }}interfaces { ct1-0/0/0 { no-partition interface-type t1; } t1-0/0/0 { satop-options { payload-size 20; idle-pattern 47; } } at-0/3/0 { description "to gatewayH at-0/1/0"; encapsulation atm-ccc-cell-relay; atm-options { pic-type atm2; cell-bundle-size 4; vpi 0; } unit 0 { encapsulation atm-ccc-cell-relay; vci 32; cell-bundle-size 10; } }fe-1/3/0 { description "to gatewayF fe-0/0/1"; unit 0 { family inet { address 11.1.1.2/24; } family mpls; } } }

routing-options { autonomous-system 69; forwarding-table { export pplb; }}protocols { mpls { interface fe-1/3/0.0; } isis { interface all { level 1 disable; } interface fxp0.0 { disable; } }



46

ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } } ldp { interface fe-1/3/0.0; interface lo0.0; } l2circuit { neighbor 10.255.49.240 {

interface at-0/3/0.0 { virtual-circuit-id 11; } } }}

Gateway H Configurationgroups { re0 { system { host-name gatewayH; backup-router 172.17.49.193 destination 0.0.0.0/0; } interfaces { fxp0 { unit 0 { family inet { address 172.17.49.232/26; } } } } }…interfaces { at-0/1/0 { description "to gatewayG 0/3/0"; atm-options { pic-type atm2; vpi 0; } unit 0 { vci 32; family inet { address 10.2.2.2/24; } } } t1-0/1/1 { unit 0; }}routing-options { autonomous-system 69;



forwarding-table { export pplb; }}protocols { isis { interface all { level 1 disable; } interface fxp0.0 { disable; } } ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; } } }}



48

BX7000 Gateway to M10i ATM Pseudowire ProvisioningFigure 10 on page 48 shows the ATM pseudowire topology that is used in this example.

Figure 10: ATM Pseudowire Topology for BX7000 Gateway to M10i Router

In this example, Gateway J is an M10i router that has an ATM2 PIC connected to the traffic tool. The BX7000 gateway router is connected to the traffic tool over a T1 line. The BX7000 gateway router and Gateway J are connected back to back by Gigabit Ethernet ge-1/0/2 and ge-1/2/0, respectively.

NOTE: On the BX7000 gateway, configure the ATM pseudowire mode as 'n-to-1 vcc'. This is required to make it interoperate with the ATM2 PIC on the M10i router side via ATM pseudowire emulation.

BX7000 GatewayTo provision the BX7000 gateway, type the following commands:



edit protocol ospfset admin-state enableedit area 0.0.0.0edit interface lo0set admin-state enableset mode passiveupedit interface ge-1/0/2

g017

338

Gigabit EthernetGatewayJ

Traffic Tool

T1 line ATM connection

t1-0/0/14 at1-1/3/0

ge-1/0/2 ge-1/2/0




set admin-state enableset priority 0topcommit




edit protocol mplsedit label-switch-path t1set from-address 80.0.0.2set to-address 80.0.0.99topcommit

edit protocol ldp set mpls ldp targeted-hello send 80.0.0.99top commit

set tdm-mode t1commit


edit protocol ldpedit l2circuit atmpw1edit neighbor-address 80.0.0.99set tunnel t1edit interface t1-0/0/14.1set pw-mode n-to-1-vccset remote-vc-id 9111set cell-concat 24 timeout 100set control-word enable



50

set sequence-check enableset sequence-switchover 1topcommit

M10i Router Gateway J ConfigurationThis section lists the relevant configuration information after provisioning the router.

chassis { fpc 1 { pic 3 { atm-l2circuit-mode { cell; } } }}

interfaces {... ge-1/2/0 { description "connected to BX7000's ge-1/0/2"; unit 0 { family inet { address 99.1.1.1/24; } family mpls; } at-1/3/0 { encapsulation atm-ccc-cell-relay; atm-options { pic-type atm2; cell-bundle-size 24; promiscuous-mode; vpi 100; } unit 0 { vci 100.1001; cell-bundle-size 24; } }…lo0 { unit 0 { family inet { address 80.0.0.99/32; } } }}protocols{rsvp {interface ge-1/2/0.0;}mpls {

label-switched-path to_bx7000 { to 80.0.0.2; }

interface ge-1/2/0.0;



}ospf { traffic-engineering; reference-bandwidth 4g; area 0.0.0.0 { interface all; interface fxp0.0 { disable; }

interface ge-1/2/0.0 { bfd-liveness-detection { minimum-interval 3; } }}ldp {

interface all;}l2circuit { neighbor 80.0.0.2 { interface at-1/3/0.0 { virtual-circuit-id 9111; } } }



52

ATM-IMA Configuration Between Two BX7000 Multi-Access Gateways with RSVP and GRE Tunnels

Figure 11 on page 52 shows the ATM-IMA configuration between two BX7000 gateways with RSVP and GRE tunnels.

Figure 11: ATM-IMA Configuration Between Two BX7000 Multi-Access Gateways with RSVP and GRE Tunnels

BX7000 Multi-Access Gateway PE1 ConfigurationThis section lists the relevant configuration information after provisioning BX7000 gateway PE1.

userid@PE1# show configuration system { host-name PE1; ntp server 172.17.49.167; ntp date 172.17.49.167; framer-mode T1;} interfaces { ge-1/0/0 { admin-state enable; unit 0 { family inet address 172.17.49.245/26; } } ge-1/0/1 { admin-state enable; unit 0 { family inet address 190.3.12.1/24; } } ge-1/0/2 { admin-state enable; unit 0 { admin-state enable; family inet address 190.3.10.1/24; vlan-id 10; } vlan-tagging enable; } gr-gre1 { unit 1 { admin-state enable; family inet address 30.30.30.20/32; tunnel { clear-dont-fragment-bit enable; ttl 60; source-address 20.20.20.20; destination 80.0.0.2;

PE2PE1 CE2CE1

g017

332

BX7000 Multi-Access Gateway BX7000 Multi-Access Gateway

T1-0/0/2

T1-0/0/14

T1-0/0/2

T1-0/0/14

ge-1/0/1

ge-1/0/2

ge-0/0/1

ge-0/0/2



mtu 1500; } } } im-ima1 { admin-state enable; unit 1 { admin-state enable; vpi 10; vci 100; } unit 2 { admin-state enable; vpi 10; vci 101; } unit 5 { admin-state enable; vpi 30; } unit 10 { admin-state enable; vpi 40; vci 100; } atm-ima { version 1.1; min-active-links 1; group 1; clock-mode common; frame-size 128; } } im-ima2 { admin-state enable; unit 5 { admin-state enable; vpi 20; } atm-ima { version 1.1; min-active-links 1; group 2; clock-mode common; frame-size 128; } } lo0 { admin-state enable; unit 0 { family inet address 20.20.20.20/32; } } t1-0/0/14 { admin-state enable; encapsulation atm-ima; clock-source loop; ima-options { ima-group im-ima1; link 2; } } t1-0/0/2 {



54

admin-state enable; encapsulation atm-ima; framing esf; clock-source loop; ima-options { ima-group im-ima2; link 1; } }}protocols { ospf { admin-state enable; spf-delay 200; area 0.0.0.0 { interface ge-1/0/2.0 { admin-state enable; } interface lo0 { admin-state enable; mode passive; } interface ge-1/0/1 { admin-state enable; } } } ldp { admin-state enable; interface ge-1/0/2.0 { admin-state enable; } interface ge-1/0/1 { admin-state enable; } mpls ldp targeted-hello send 20.255.49.240; l2circuit satop1 { admin-state enable; neighbor-address 80.0.0.2 { tunnel PE1toPE2; interface im-ima1.1 interface im-ima1.2 { pw-mode n-to-1-vcc; control-word enable; sequence-check disable; cell-concat 24 timeout 100; remote-vc-id 10100; } } } l2circuit satop2 { admin-state enable; neighbor-address 80.0.0.2 { tunnel PE1toPE2; interface im-ima1.5 interface im-ima2.5 { pw-mode n-to-1-vpc; control-word enable; sequence-check disable; cell-concat 24 timeout 100; remote-vc-id 10500; } }



} l2circuit gre { admin-state enable; neighbor-address 80.0.0.2 { tunnel gr-gre1; interface im-ima1.10 { pw-mode n-to-1-vcc; control-word enable; sequence-check disable; cell-concat 24 timeout 100; remote-vc-id 11000; } } } } rsvp { admin-state enable; interface ge-1/0/2.0 { admin-state enable; } interface ge-1/0/1 { admin-state enable; } } mpls { label-switch-path PE1toPE2 { to-address 80.0.0.2; from-address 20.20.20.20; primary PE1toPE2 { priority 7 0; } } interface ge-1/0/2.0 { admin-state enable; } interface ge-1/0/1 { admin-state enable; } } static-route { route 172.0.0.0/8 { next-hop 172.17.49.193; } }}


userid@PE1# show interface im-ima1

Logical Interface :im-ima1 , Enabled , Operational state : Enabled Interface Description: Clock mode: CTC Symmetry mode: Sym OP + Sym Conf Minimum Active Member links: 1 Active Tx Member links: 1 Active Rx Member links: 1 Differential Delay : 0 Frame size : 128 Total Tx Bandwidth : 1.54 Mbps



56

Total Rx Bandwidth : 1.54 Mbps

Logical Interface :im-ima1.1, Enabled Operational state : Enabled VPI : 10, VCI : 100




Physical interface :t1-0/0/14, Enabled, Physical Link : Up Interface index:61445 Speed :1544000, Loopback: Disabled Tx state : Enabled, Rx state : Enabled, Encapsulation : ATM-IMA Encoding : b8zs, Framing : esf, Build-out : 0-132 Cell scramble : disabled Clock source : loop Description :

[edit]userid@PE1# show interface im-ima2

Logical Interface :im-ima2 , Enabled , Operational state : Enabled Interface Description: Clock mode: CTC Symmetry mode: Sym OP + Sym Conf Minimum Active Member links: 1 Active Tx Member links: 1 Active Rx Member links: 1 Differential Delay : 0 Frame size : 128 Total Tx Bandwidth : 1.54 Mbps Total Rx Bandwidth : 1.54 Mbps



[edit]userid@PE1# show l2circuit satop1

Remote VC ID : 10100



Neighbor address : 80.0.0.2 Prefered path : PE1toPE2 Type : RSVP VC type and control word bit : 9 Control Word : Enabled Admin status : Up Operational status : Up


Remote VC ID : 10500 Neighbor address : 80.0.0.2 Prefered path : PE1toPE2 Type : RSVP VC type and control word bit : 10 Control Word : Enabled Admin status : Up Operational status : Up

[edit]userid@PE1# show l2circuit gre

Remote VC ID : 11000 Neighbor address : 80.0.0.2 Prefered path : gr-gre1 Type : GRE VC type and control word bit : 9 Control Word : Enabled Admin status : Up Operational status : Up

[edit]userid@PE1#

BX7000 Multi-Access Gateway PE2 ConfigurationThis section lists the relevant configuration information after provisioning BX7000 gateway PE2.

userid@PE2# show configuration system { host-name PE2; snmp { contact juniper; location sunnyvale; description gateway1; } framer-mode T1;} interfaces { ge-1/0/0 { admin-state enable; unit 0 { family inet address 172.17.49.174/24; } } ge-1/0/1 { admin-state enable; unit 0 {



58

admin-state enable; family inet address 95.1.1.1/24; vlan-id 10; } vlan-tagging enable; } ge-1/0/2 { admin-state enable; unit 0 { admin-state enable; family inet address 190.3.10.3/24; vlan-id 10; } vlan-tagging enable; } gr-gre1 { unit 1 { admin-state enable; family inet address 30.30.30.2/32; tunnel { clear-dont-fragment-bit enable; ttl 60; source-address 80.0.0.2; destination 20.20.20.20; mtu 1500; } } } im-ima1 { admin-state enable; unit 1 { admin-state enable; vpi 10; vci 100; } unit 2 { admin-state enable; vpi 10; vci 101; } unit 5 { admin-state enable; vpi 30; } unit 10 { admin-state enable; vpi 40; vci 100; } atm-ima { version 1.1; min-active-links 1; group 1; clock-mode common; frame-size 128; } } im-ima2 { admin-state enable; unit 5 { admin-state enable; vpi 20; }



atm-ima { version 1.1; min-active-links 1; group 2; clock-mode common; frame-size 128; } } lo0 { admin-state enable; unit 0 { family inet address 80.0.0.2/32; } } t1-0/0/14 { admin-state enable; encapsulation atm-ima; clock-source loop; ima-options { ima-group im-ima1; link 1; } } t1-0/0/2 { admin-state enable; encapsulation atm-ima; framing esf; clock-source loop; ima-options { ima-group im-ima2; link 1; } }}protocols { ospf { admin-state enable; spf-delay 200; area 0.0.0.0 { interface ge-1/0/1.0 { admin-state enable; } interface ge-1/0/2.0 { admin-state enable; } interface lo0 { admin-state enable; mode passive; } } } ldp { admin-state enable; interface ge-1/0/1.0 { admin-state enable; } interface ge-1/0/2.0 { admin-state enable; } l2circuit satop1 { admin-state enable; neighbor-address 20.20.20.20 { tunnel PE2toPE1;



60

interface im-ima1.1 interface im-ima1.2 { pw-mode n-to-1-vcc; control-word enable; sequence-check disable; cell-concat 24 timeout 100; remote-vc-id 10100; } } } l2circuit satop2 { admin-state enable; neighbor-address 20.20.20.20 { tunnel PE2toPE1; interface im-ima1.5 interface im-ima2.5 { pw-mode n-to-1-vpc; control-word enable; sequence-check disable; cell-concat 24 timeout 100; remote-vc-id 10500; } } } l2circuit gre { admin-state enable; neighbor-address 20.20.20.20 { tunnel gr-gre1; interface im-ima1.10 { pw-mode n-to-1-vcc; control-word enable; sequence-check disable; cell-concat 24 timeout 100; remote-vc-id 11000; } } } } rsvp { admin-state enable; interface ge-1/0/1.0 { admin-state enable; } interface ge-1/0/2.0 { admin-state enable; } } mpls { label-switch-path PE2toPE1 { to-address 20.20.20.20; from-address 80.0.0.3; primary PE2toPE1 { priority 7 0; } } interface ge-1/0/1.0 { admin-state enable; } interface ge-1/0/2.0 { admin-state enable; } } static-route {



route 0.0.0.0/0 { next-hop 172.17.49.129; } route 172.0.0.0/8 { next-hop 172.17.49.129; } }}


userid@PE2# show interface im-ima1

Logical Interface :im-ima1 , Enabled , Operational state : Enabled Interface Description: Clock mode: CTC Symmetry mode: Sym OP + Sym Conf Minimum Active Member links: 1 Active Tx Member links: 1 Active Rx Member links: 1 Differential Delay : 0 Frame size : 128 Total Tx Bandwidth : 1.54 Mbps Total Rx Bandwidth : 1.54 Mbps






[edit]userid@PE2# show interface im-ima2

Logical Interface :im-ima2 , Enabled , Operational state : Enabled Interface Description: Clock mode: CTC Symmetry mode: Sym OP + Sym Conf Minimum Active Member links: 1 Active Tx Member links: 1



62

Active Rx Member links: 1 Differential Delay : 0 Frame size : 128 Total Tx Bandwidth : 1.54 Mbps Total Rx Bandwidth : 1.54 Mbps







[edit]userid@PE2# show l2circuit gre

Remote VC ID : 11000 Neighbor address : 20.20.20.20 Prefered path : gr-gre1 Type : GRE VC type and control word bit : 9 Control Word : Enabled Admin status : Up Operational status : Up

[edit]userid@PE2#


Chapter 3

Monitoring and Troubleshooting

This chapter lists the commands used to monitor and troubleshoot the configuration.

Monitoring the BX7000 Multi-Access Gateway on page 63

Monitoring the M10i Router on page 66

Monitoring the BX7000 Multi-Access Gateway

Checking the Protocol-Enabled InterfacesUse the following commands to check the protocol-enabled interfaces on the BX7000 gateway:

bx7000@CLI> show ospf interface briefInterface State Area DR ID BDR IDlo0 LoopBack 0. 0. 0. 0 0. 0. 0. 0 0. 0. 0. 0ge-1/0/2 DR 0. 0. 0. 0 99. 1. 1. 2 0. 0. 0. 0

bx7000@CLI>

bx7000@CLI> show rsvp interface

Physical Interface : ge-1/0/2 Index : 5 Operational state : Enabled Available Bandwidth : 1000.00 Mbps Reserved Bandwidth : 0 bps Number of tunnels running on this interface : 0

bx7000@CLI>

bx7000@CLI> show ldp interface

Interface

Interface name : ge-1/0/2 Index : 5 Hold time : 15, Local hello interval : 9 Transport address : 80.0.0.2

bx7000@CLI>

Monitoring the BX7000 Multi-Access Gateway 63


64

bx7000@CLI> show mpls tunnel t1 Tunnel Name is :t1, LSP ID:1, Tunnel ID: 1 Ingress IP Address:80.0.0.2, Egress IP Address:80.0.0.99 Tunnel if index:7 Setup priority:0 Holding priority:0 Instance index of the primary instance :1, Instance priority :0 Aggregate up time :15633 sec Total UP time :15633 sec, Total active time :14175 sec SysUpTime :33 sec Number actual path instance :0 Last actual path instance:0, is_persistent flag is SET Unprotected Tunnel Tunnel Storage type is volatile The switching type:0 Link Protection Flag:0 Fast reroute protection is Disabled Setup priority for backup tunnel :0 Holding priority for backup tunnel:0 Estimated bandwidth required for backup tunnels:0 Maximum number of extra hops :255 Unique in-segment logical port UNI-N:0 Unique out-segment logical port UNI-N:0 "t1" Tunnel operational status is UP

bx7000@CLI>

Checking the Protocol Working ConditionUse the following command to check the protocol working condition on the BX7000 gateway.

bx7000@CLI> show ospf neighbor detail

Address Interface State ID Pri99.1.1.1 ge-1/0/2 Full 80.0.0.99 128area 0.0.0.0 opt 0x42 Link state retransmission queue length = 0

bx7000@CLI>

Checking the Pseudowire Status Use the following commands to check the status of the pseudowire.

bx7000@CLI> show statistics pseudowire satop1

Pseudo-Wire Statistics :

PSN to TDM Direction Forwarded Packets : 2338482 Free Buffer drops : 0 Under-run drops : 0 Stray Packets : 0 Malformed Packets : 0 Duplicate Packets : 0 Error Drops : 0 Denied Packets : 0 Reordered Packets : 0 Transit Packets : 2338468

Monitoring the BX7000 Multi-Access Gateway


Dummy Transit Packets : 0 Idle Transit Packets : 27052 Out-of-sequence packets : 0 Sequence Window switchover: 0 Buffer over-run events : 0 Buffer under-run events : 0

TDM to PSN Direction Rx Valid packets : 1301082 Forwarded packets : 1301082 Free buffer events : 0 Free buffer drops : 0 MTU drops : 0 Congestion drops : 0

bx7000@CLI> show 12circuit satop1 detailbx7000@CLI>

Pw fec id is: 111 L2circuit LSR Index: 1 L2Circuit MiB Index:1 L2circuit Neighbour Addrs:80.0.0.99 L2circuit Dest addrss prefix len:32 L2circuit route is not dependent on input interface Pw VC Type and control word bit: 18 Pw group VC FEC : 0 Length of VC FEC interface parameters field: 0 Pw next_hop_list_index : 0 The L2circuit Output inet address which should be used to reach the next hop is 0.0.0.0 L2circuit Next hop inet address 80.0.0.99 The LDP Peer ID of the remote peer with whom the VC is being set up is 0.0.0.0 VC setup is signaled with C=1 (Control Word present) and VC setup fails if the remote LDP peer signals C=0 *****User Data on the Pseudo wires attachment interfaces****** Pseudo Wire Type type is satop Number of attached Interfaces:1 Interface Name:t1-0/0/0 and its index is :61441 "satop1" L2cicuit admin status is Enabled.

<<<<<<<< SATOP PSW statistics having FEC id:111>>>>>>>>

TDM to PSN Direction Rx Valid packets : 2853881 Forwarded packets : 2853881 Free buffer events : 0 Free buffer drops : 0 MTU drops : 0 Congestion drops : 0

PSN to TDM Direction Forwarded Packets : 3891284 Free Buffer drops : 0 Under-run drops : 0 Stray Packets : 0 Malformed Packets : 0 Duplicate Packets : 0 Error Drops : 0 Denied Packets : 0 Reordered Packets : 0 Transit Packets : 3891257 Dummy Transit Packets : 0

Monitoring the BX7000 Multi-Access Gateway 65


66

Idle Transit Packets : 27070 Out-of-sequence packets : 0 Sequence Window switchover: 0 Buffer over-run events : 0 Buffer under-run events : 0

bx7000@CLI>

Monitoring the M10i Router

Use the following commands to check the status of the M10i router:

root@host> show ospf neighborAddress Interface State ID Pri Dead99.1.1.2 ge-1/2/0.0 Full 80.0.0.2 1 30

root@host>

root@host> show ldp neighborAddress Interface Label space ID Hold time80.0.0.2 lo0.0 80.0.0.2:0 4099.1.1.2 ge-1/2/0.0 80.0.0.2:0 10

root@host>

root@host> show ldp databaseInput label database, 80.0.0.99:0--80.0.0.2:0Label Prefix

16 L2CKT CtrlWord SATOP-T1 VC 111

Output label database, 80.0.0.99:0--80.0.0.2:0Label Prefix

3 80.0.0.99/32 299776 L2CKT CtrlWord SATOP-T1 VC 111

root@host>

root@host> show 12circuit connectionsLayer-2 Circuit Connections:

Legend for connection status (St)EI -- encapsulation invalid NP -- interface h/w not presentMM -- mtu mismatch Dn -- downEM -- encapsulation mismatch VC-Dn -- Virtual circuit DownCM -- control-word mismatch Up -- operationalVM -- vlan id mismatch CF -- Call admission control failureOL -- no outgoing label IB -- TDM incompatible bitrateNC -- intf encaps not CCC/TCC TM -- TDM misconfigurationBK -- Backup Connection ST -- Standby ConnectionCB -- rcvd cell-bundle size bad XX -- unknown Legend for interface statusUp -- operational Dn -- downNeighbor: 80.0.0.2 Interface Type St Time last up # Up trans



t1-1/1/1.0(vc 111) rmt Up May 15 23:08:12 2008 3 Local interface: t1-1/1/1.0, Status: Up, Encapsulation: SATOP-T1 Remote PE: 80.0.0.2, Negotiated control-word: Yes (Non-null) Incoming label: 299776, Outgoing label: 16

root@host>

Monitoring the M10i Router 67


68

Chapter 4

Zero-Touch Configuration

The BX7000 Multi-Access Gateway has a zero-touch facility that allows the BX7000 gateway to configure itself out-of-the-box with no manual intervention, using the configuration available either on the network, locally through a removable media, or a combination of both.

Zero-touch configuration delivers the following benefits:

The BX7000 Multi-Access Gateway can be sent from the warehouse to the deployment site without any pre-configuration steps.

The procedure required to deploy the device at the cell site is simplified, resulting in reduced operational expenses.

You can roll out large numbers of these devices in a very short time.

This chapter contains the following sections:

Zero-Touch Functionality on page 69

Infrastructure Mode on page 72

Manual Mode on page 74

Standalone Mode on page 74

Zero-Touch Topology on page 76

Automatic Configuration Server on page 77

Zero-Touch Functionality

Zero-touch is the mechanism by which the BX7000 Multi-Access Gateway down loads its configuration file from a remote server and configures itself as per the configuration commands in the config file. A USB drive can also be used in place of a config server. The BX7000 gateway can also configure itself by using the config file stored in the USB drive. The configuration commands are stored in XML format. deployment-specific config files can be placed in a server or a USB drive to create a deployment-specific configuration.

The BX7000 gateway can be deployed in three different modes:

Zero-Touch Functionality 69


70

Infrastructure mode—The operator already has DHCP servers as a part of their infrastructure. Vendor-specific attributes can be passed to the BX7000 gateway by these DHCP servers.

Standalone mode—The operator has DHCP servers as a part of their infrastructure. Vendor-specific attributes cannot be passed to the BX7000 gateway by these DHCP servers.

Manual mode—Zero-touch is not available.

The BX7000 gateway uses a manual mode bit in the config register (NVRAM) that decides whether the BX7000 gateway is deployed in manual mode. When this bit is enabled (manual mode), the BX7000 gateway does not send out DHCP requests. In manual mode, if a USB drive with a config file (config.xml) is present, the BX7000 gateway reads the file and configures itself. If the config server’s URL (cfgsvrdetails.xml file) is available, along with the config file in the USB drive, the BX7000 gateway retrieves the file from that URL and also applies it on top of the existing configuration. If a USB drive is not found, the BX7000 gateway can be configured using the command-line interface (CLI).

When the manual mode bit is not enabled (no manual mode), the BX7000 gateway checks for the zero-touch bit in the config register. If this bit is enabled and a USB drive with a config file is not detected, the BX7000 gateway sends out DHCP requests. If the BX7000 gateway gets vendor-specific attributes as part of the DHCP response, the gateway switches to infrastructure mode. If the BX7000 gateway does not receive vendor-specific attributes as part of the DHCP response, it switches to standalone mode.

If the zero-touch bit is enabled and there is a USB drive with a config file (config.xml), the BX7000 gateway uses this file for configuration and a DHCP request is not sent. If config server’s URL (cfgsvrdetails.xml file) is present along with a config file in the USB drive, the BX7000 gateway retrieves the file from that URL and also applies it on top of the existing configuration. If the zero-touch bit is not enabled, the BX7000 gateway looks for a /config/startup.cfg file. If this file is not present, the BX7000 gateway looks for a /BX7000cfg/default.cfg file.

NOTE: The factory default setting is manual-mode disabled and zero-touch enabled. Once the operator makes the first configuration to the BX7000 gateway, there are two options:

The zero-touch configuration can be disabled (Config -> edit system -> set zero-touch config disable -> top -> commit). This way, the saved configuration (/config/startup.cfg) is used the next time the system reboots.

Alternatively, if the BX7000 gateway must get the configuration from the server each time the system reboot occurs, zero-touch configuration should not be changed.

Figure 12 on page 71 shows a flow diagram of the zero-touch feature. The sections that follow describe each deployment scenario in detail.

Zero-Touch Functionality


Figure 12: Zero-Touch Configuration Flow Chart

NoDownload config file using

and applyURL in cfgsvrdetails.xml

Apply config.xml

Yes

startup.cfg available?

No

No

Yes

Configure using default.cfg

NoYes

Yes

No

Yes

YesNo

Manual Mode

Standalone Mode Infrastructure Mode

Yes

No

Yes

No

Zero-touchenabled?

Configurethrough CLI

Download config file using

and applyURL in cfgsvrdetails.xml

Read config register

Start

Apply config.xml

USB present?

Download config file

Read server detailfrom Vendor attrib

Download config file

Read server detailfrom cfgsvrdetails.xml

file

USB withcfgsvrdetails.xml?

Manual mode bit enabled?

End

USB present?

Response withvendor attrib?

Response fromDHCP server?

Send DHCP request

End

Configure usingdownloaded file

Configure usingdownloaded file

Configure using default.xml

Configure using default.cfg

Configure using startup.cfg

g017339

Zero-Touch Functionality 71


72

Infrastructure Mode

In infrastructure mode, the operator has a DHCP server as a part of the infrastructure. Once the BX7000 gateway boots, it sends out a DHCP request for the IP address. The DHCP response packet includes the details of the configuration server (for example, a URL such as protocolname://username:password@ hostname/filename# and a MD5 fingerprint of server’s self-signed certificate (fingerprint only for HTTPS)). A DHCP request is sent through all interfaces and the first response received on any interface is used to configure that interface. Other responses, if any, are ignored.

To download the config file, zero-touch uses the URL information to contact the configuration server. Zero-touch on the BX7000 gateway supports HTTP, HTTPS, FTP, and TFTP protocols to download the configuration file from the config server. The information related to the protocol in the URL is used to decide on the protocol to be used for the session.

Figure 13: Infrastructure Mode Configuration Diagram

The following sequence of events takes place as shown in Figure 13 on page 72:

1. A DHCP request is sent from the BX7000 gateway. The zero-touch DHCP client within the gateway sends the vendor ID as jnpr BX7000 bxos.

2. The DHCP server replies with the vendor attributes.:

The configuration server URL—Protocolname://username:password@hostname/filename# and the MD5 fingerprint of the server’s self-signed certificate (fingerprint only for HTTPS).

A list of notification host IP addresses (a maximum of four)

3. The BX7000 gateway sends the following data as a name-value pair via HTTP/HTTPS POST to the config server.

Serial number

BX7000 Gateway DHCP Server Configuration Server

DHCP request

DHCP response(BX7000 Gateway IP and Server IP)

HTTP/HTTPS session (POST and GET)

Notification Hosts

Notification via SNMP TRAP or INFORM

Downloads the device configuration file using HTTP/HTTPS

g017

342

Infrastructure Mode


Model number

IP address

Software version

Hostname (if already configured)

4. The configuration server sends back the filename as the response to the POST request. This unique serial number sent can also be used to validate the BX7000 gateway’s request and to send the respective filename to the BX7000 gateway.

5. The BX7000 gateway uses the filename received as a response to the POST request, and sends an HTTP/HTTPS GET request to download the configuration file from the server. The server sends the requested configuration file back to the BX7000 gateway.

Note the following:

If the filename sent by the config server is different from the filename that the BX7000 gateway received as the part of the vendor attribute from the DHCP server, the gateway uses the filename sent by the config server as the file to download. If there is no filename in the DHCP vendor attribute, the BX7000 gateway uses the filename from the response for the POST message.

The BX7000 gateway uses TFTP/FTP when the URL contains the protocol field as TFTP/FTP. Only username and password-based authentication are performed for FTP/TFTP. No information related to the BX7000 gateway such as the serial number, and so on are sent to the config server in this case.

HTTP uses the digest mechanism for authentication with the username and password are passed by the DHCP server as vendor attributes.

HTTPS uses the fingerprint of the server’s public key from vendor attributes against the one received from config server to validate the config server, and uses the username and password from the URL for authentication.

The BX7000 gateway configures itself according to the commands in the configuration file.

6. After a successful configuration, the BX7000 gateway sends an SNMP TRAP or INFORM to the list of hosts specified by the DHCP server as part of the vendor attributes.

Error ConditionsPossible error conditions are as follows:

When zero-touch is unable to find the server, it will exponentially back off to try and reach the configuration server.

If the server is not reached within the predetermined time, zero-touch will boot with the factory default configuration (default.cfg file).

Infrastructure Mode 73


74

Manual Mode

Zero-touch does not occur when the config register bit has zero-touch functionality disabled. In this case, the BX7000 gateway must be configured manually using the command-line interface (CLI) or NETCONF.

If a USB drive is present in manual mode, the BX7000 gateway checks for the config.xml file on the disk. If present, the file is applied to the box. If the cfgsvrdetails.xml is also present, then the URL is used to download the config file and apply it to the box on top of the existing configuration.

Standalone Mode

In standalone mode, the operator has a DHCP server as a part of the infrastructure. However, the DHCP server cannot send vendor--specific attributes to the BX7000 gateway. In this case, the BX7000 gateway can be configured by a USB drive plugged into the BX7000 gateway’s USB port. The USB disk drive must have the following files:

Usbdisk/Config.xml—When present on the USB disk, the BX7000 gateway uses this file to configure itself. If the cfgsvrdetails.xml. file is also present, then the URL in the file is used to download the config file from config server. The downloaded file is applied to the box on the top of the existing configuration.

Usbdisk/cfgsvrdetails.xml—This file has the details URL for the file server.

Figure 14 on page 74 shows the sequence of events that takes place during this process.

Figure 14: Standalone Mode Configuration Diagram

A BX7000 gateway in standalone mode checks for the presence of a USB disk drive. The gateway reads the URL of the config server from the disk and uses this URL to download the file from the config server.

As per the protocol specified in the URL, zero-touch uses HTTP or HTTPS to download the configuration file, as follows:

BX 7000 Gateway Configuration Server

HTTP/HTTPS session (POST using details from USB disk)

Notification Servers

Notification via SNMP TRAP or INFORM

Downloads the device configuration file using HTTP/HTTPS

g017

343

Manual Mode


1. Zero-touch sends an HTTP/HTTPS POST message using details from USB disk with the following details to the configuration server:

Serial number

Model number

IP address

Software version

Hostname (if already configured)

2. The configuration server sends back the filename as a response to the POST request. The unique serial number sent can also be used to validate the BX7000 gateway’s request and to send the respective filename to the gateway.

3. The BX7000 gateway uses the filename from the response for the POST message to download the device config file. After a successful download, zero-touch configures the BX7000 gateway according to the commands in the configuration file.

HTTP uses the digest mechanism for authentication with the username and password.

HTTPS verifies the MD5 fingerprint in the cfgsvrdetails.xml file against the one generated on the self-signed certificate received from the config server to validate the config server, and uses the user name and password from the URL for authentication.

4. After a successful configuration, the BX7000 gateway sends an SNMP TRAP or INFORM to the list of hosts specified in the cfgsvrdetails.xml file of the USB disk drive.

5. In cases where there is no USB disk drive, the BX7000 gateway uses the factory default configuration file, part of the software image loaded on the box.

Standalone Mode 75


76

Zero-Touch Topology

The topology used when manually configuring zero-touch is shown in Figure 15 on page 76.

Figure 15: Zero Touch Topology

Enabling or Disabling Zero-Touch Use the following CLI commands to enable or disable zero-touch:

user@host# edit system user@host# set zerotouch config <enable/disable>

Enabling or Disabling Manual ModeUse the following CLI commands to enable or disable manual mode:

user@host# edit system user@host# set manual-mode config <enable/disable>

Showing Zero-Touch or Manual ModeUse the following CLI commands to verify whether zero-touch and manual mode are enabled or disabled:

user@host# show zerotouchZerotouch mode: disabled

user@host# show manual-mode Manual mode: disabled

BX7000 Gateway

Configuration Server/DHCP

g017

344

BX7000 Gateway

Zero-Touch Topology


Automatic Configuration Server

The Automatic Configuration Server (ACS) hosts the initial configuration on the network. Based on the ACS URL, the transport can be HTTP, HTTPS, FTP, or TFTP. The ACS can also be a JUNOScope system.

The ACS can serve the configuration when any of the following device attributes are available to it when the BX7000 gateway makes an HTTP/HTTPS request to retrieve the initial configuration.

Device serial number

Model number

MAC address

Operating system version

Hostname

ACS can also ignore all the above information and supply a predetermined configuration to devices.

DHCP Server Configuration for Zero-TouchThe commands that follow are used to configure a DHCP server for zero-touch operation.

To add the option space in the DHCP config file (for example, /etc/dhcpd.conf):

Example option space:

option space BX7000;option BX7000.config-server code 2= text;option BX7000.ser1 code 3= ip-address;option BX7000.ser2 code 4= ip-address;

To add the vendor class:

class "vendor-classes" { match option vendor-class-identifier;}subclass "vendor-classes" "Juniper-BX7000-BXOS" {vendor-option-space BX7000;

#option BX7000.config-server "tftp://uname:[email protected]:69/ BX7000_config ";#option BX7000.config-server "https://uname:[email protected]:80/BX7000_config#CE:9B:32:75:F9:B4:30:53:99:B6:66:C1:64:C5:5B:56";#option BX7000.config-server "http://uname:[email protected]:80/BX7000_config";

#option BX7000.config-server "ftp://uname:[email protected]:21/ BX7000_config ";option BX7000.ser1 22.22.22.22;option BX7000.ser2 33.33.33.33;}

Automatic Configuration Server 77


78

Options can be mentioned anywhere in the dhcpd.conf file (for example, inside a specific subnet or host).

To configure either a subnet range or a specific individual host:

subnet 192.168.1.0 netmask 255.255.255.0 {range 192.168.1.120 192.168.1.125;

}

host BX70001 {hardware ethernet 00:00:00:94:00:02;fixed-address 192.168.1.125; }

6. To restart the DHCP daemon using the service dhcp restart or dhcp eth1 -d commands.

Configuration Server ConfigurationIf the protocol is HTTP or HTTPS, follow these steps to configure the config server.

1. Create a file with the name BX7000_config as given in the HTTPS URL in the dhcpd.conf file), and place it in the download directory (for example, /var/www/html).

2. Open the file and add the BX7000 gateway configuration to be included.

If the protocol is FTP, follow these steps to configure the config server:

1. Create a file with the name BX7000_config (as given in the HTTPS URL in the dhcpd.conf file), and place it in the home directory

2. Open the file and add the BX7000 configurations to be included.

If the protocol is TFTP, follow these steps to configure the config server.:

1. Create a file with the name BX7000_config (as given in the HTTPS URL in the dhcpd.conf file), and place it in the /tftpboot directory.

2. Open the file and add the BX7000 configurations to be included.

Automatic Configuration Server

Chapter 5

JUNOScope IP Backhaul Manager

JUNOScope is an element management application that provides tools for managing IP services for configured devices on the network, such as the BX7000 Multi-Access Gateway, and J Series, M Series, MX Series, and T Series routing platforms.

This chapter contains these sections:

Overview on page 79

Pseudowire Provisioning on page 81

JUNOScope IP Backhaul Manager Image Management Summary on page 108

Overview

Pseudowire is the emulation of native services such as TDM and ATM over packet-switched networks (IP/MPLS). Pseudowire provisioning occurs between the BX7000 gateway (cell site router) and the backhaul aggregation router (with a Circuit Emulation PIC).

For mobile backhaul, mobile operators use copper or microwave time-division multiplexing (TDM) links (see Figure 16 on page 79). A typical cell site requires two or three leased T1/E1 lines, representing 4 to 6 Mbps of bandwidth. New data-intensive mobile services could easily double this requirement.

Figure 16: Current Mobile Architecture

Air interfaceBTS

Node B

Cell site Concentration site

Core network

Air interface

Cell site Concentration site

Core network

2G GSM RAN

3G UMTS RAN

n x E1/T1

A bis (TDM)

n x E1/T1

lub (ATM)

BSC

RNC

g017

340

Overview 79


80

The BX7000 Multi-Access Gateway is an alternative IP-based mobile backhaul solution that allows mobile operators to leverage the cost-effective, scalable, efficient IP/MPLS-based technology that is already in use in many mobile packet cores across the entire mobile infrastructure.

The Juniper Networks solution (see Figure 17 on page 80) converges multiple technologies over pseudowire and IP/MPLS in the Radio Access Network (RAN). Pseudowire is the emulation of native services (TDM and ATM) over packet-switched networks (IP/MPLS). The Juniper Networks solution consists of a BX7000 Multi-Access Gateway and a backhaul aggregation router. The backhaul aggregation router is typically an M Series box with specialized Circuit Emulation PICs (ATM/TDM/Ethernet).

Figure 17: Juniper Networks IP-Based Mobile Backhaul Solution

NOTE: This chapter provides an overview of the configuration process. For complete details, refer to the JUNOScope Software User Guide.

Metro Regional Site

BSC

RNC

g017

341

sportkhaul

MSCPSTN

M Series

SGSN/PDSN

GGSN/HA

TDM

ATM

RANAggregation

Router

AAA and VLR/HLR Terminate Pseudowire,ATM, TDM, Ethernet

Overview


Pseudowire Provisioning

This section discusses the provisioning of pseudowires between the following:

BX7000 gateway and the Circuit Emulation PIC

Circuit Emulation PIC and another Circuit Emulation PIC

BX7000 gateway and another BX7000 gateway device

The following pseudowires are supported:

TDM-SAToP (BX7000 to Circuit Emulation PIC, Circuit Emulation PIC to Circuit Emulation PIC, BX7000 to BX7000)

ATM ( JUNOS ATM-II PIC to JUNOS ATM-II PIC, JUNOS ATM-II PIC to BX7000, BX7000 to BX 7000)

Ethernet (Circuit Emulation PIC to Circuit Emulation PIC)

The two workflows are as follows:

MPLS/GRE tunnel provisioning

Pseudowire provisioning:

Prerequisites for Pseudowire ProvisioningThe following are the prerequisites for pseudowire provisioning:

Select the IP Backhaul Manager licensable module during JUNOScope installation. In other words, you should answer ‘yes’ when the following question is asked during JUNOScope installation

Do you want to install IP Backhaul Manager (yes,no)

For JUNOS systems, enable NETCONF on devices. The CLI command for enabling NETCONF is:

set system services netconf ssh

For provisioning, configure IP address for lo0.0

Add devices to be managed using the NETCONF over SSH access method.

The tasks for the MPLS/GRE tunnel provisioning workflow are shown in these sections:

Configuring LSP Paths on page 82

Configuring Protocols on Interfaces on page 84

MPLS/GRE Tunnel Provisioning on page 86

Pseudowire Provisioning 81


82

Configuring LSP Paths

Label-switched paths (LSP) can be configured statically as a ordered set of nodes. To configure static LSP paths, the Provisioning > MPLS/GRE Tunnels > Configure LSP Paths wizard can be used. See Figure 18 on page 82.

NOTE: This is an optional step and required only you want to configure static paths for LSPs.

Figure 18: Configure LSP Paths Wizard

To configure the LSP path:

1. Open the Configure LSP Paths wizard.

2. Enter a name to the path, a device to which the path will be applied, and a comment.

3. Enter the IP address of the node and select whether the node in the LSP path is strict or loose:

Strict—Indicates that the next hop must be adjacent.

Loose—Indicates that the next hop is not necessarily adjacent.

4. Click Add to add the new node in the path.

Configuring LSP Paths


5. Click Remove or Remove All to remove nodes from the path, or click Move Up or Move Down to reorder nodes in the path.

6. Click Save to save the path for use during MPLS/GRE tunnel provisioning.

Configuring LSP Paths 83


84

Configuring Protocols on Interfaces

Figure 19 on page 84 shows the Configure Protocols wizard. Click Configure Protocols under MPLS/GRE Tunnels. The Configure Protocols dialog box appears.

Figure 19: Configure Protocols on Interfaces

To configure the protocols on an interface:

1. From the Device Name list, select the name of the device on which you want to configure the protocols.

2. From the Protocols list, select one of the following: ISIS, MPLS, LDP, RSVP, OSPF, or INET.

3. Click Open. Depending on the protocol selected, parameters specific to the protocol appear. Refer to the JUNOScope Software User Guide for details on the parameters.

4. Click Add to add the logical interface to the Details of Protocol on Interface list.

5. Click Remove or Remove All to remove one or more logical interfaces from the Details of Protocol on Interface list.

6. Click Save to save the protocols on the interfaces.

Configuring Protocols on Interfaces


NOTE: When you click Save, the protocol information is saved to the JUNOScope database. Actual configuration will be pushed to device only during provisioning of MPLS/GRE tunnels.

Use the Export/Import wizard to configure protocols in bulk. Using the Export button, you can export the protocols to be configured on interfaces. The protocols are saved in XML format. Use the import button to import a previously saved set of protocols.

Configuring Protocols on Interfaces 85


86

MPLS/GRE Tunnel Provisioning

This section contains the following tasks for tunnel provisioning:

Step 1: Choose the Devices to be Used as Endpoints on page 87

Step 2: Adding, Editing, or Deleting Tunnels on page 89

Step 3: Confirming the Operation on page 92

Step 4: Provisioning the Tunnels on page 93

This is a four-step, iterative process as shown in Figure 20 on page 86. Repeat this process for every tunnel that you want to add, edit, or delete.

Figure 20: Steps for Tunnel Provisioning

g017

345

Choose devices for endpoints1

Add/Edit/Delete tunnels2Confirm operations3

Provision tunnels4



Step 1: Choose the Devices to be Used as EndpointsThe first step consists of choosing the devices to be used as the source and destination endpoints, as shown in Figure 21 on page 87.

Figure 21: MPLS/GRE Tunnel Provisioning

The Select Device Source wizard gives you the option of selecting either a single device or selecting a device group. To choose the devices:

1. Click either Select Device(s) Directly to Select from all the available devices, or Select a Device Group to select a device group. If you choose to select devices directly, you can search for devices on the following criteria:

From the Select a Field list, select one of the following options: Device Name, Device Hostname, Model, Location, or Comment.

From the Select an Operator list, select one of the following options: Contains, Does not Contain, Starts With, Ends with, or Equals.

Type a string and click View to display a list of devices that meet the criteria specified in the preceding steps.

For example, to list devices that have device names starting with J, select Device Name from the Select Field list, select Starts With from the Select an Operator list, enter J into the text box, and click View. All devices that have device names starting with J will be listed in the Select Devices list.

MPLS/GRE Tunnel Provisioning 87


88

2. If selecting a device group, select the group from the list. Device groups can be created by grouping devices dynamically based on one of the following filtering criteria: location, name, model, or hostname. Alternatively, devices can be grouped using static labels. When you have selected a device group, all the devices in that group are listed in the Select Devices list.

3. Select at least two Devices and click Next to proceed to “Step 2: Adding, Editing, or Deleting Tunnels” on page 89.



Step 2: Adding, Editing, or Deleting TunnelsThe second step consists of adding, editing, or deleting tunnels. Three types of tunnel are supported: MPLS-RSVP, MPLS-LDP, and GRE. The wizard used to add tunnels is shown in Figure 22 on page 89.


To add, edit, or delete a tunnel:

1. From the Tunnel Type list, select a tunnel type. The available values are: MPLS-RSVP, MPLS-LDP, or GRE.

2. From the Source Device and Destination Device lists, select the source and device names.

3. Specify the provide source endpoint detail section:

1. Type an LSP name and bandwidth.

NOTE: An LSP name is mandatory for the MPLS-RSVP tunnel type.



90

2. If you want the LSP name specified in Step 1 to use a static LSP path, select an LSP path to be used as the primary path. This field is required only if the tunnel type selected is MPLS-RSVP. For MPLS-LDP and GRE tunnel types, this field is disabled.

3. If you want the LSP name specified in Step 1 to use a static LSP path, select an LSP path to be used as the secondary path. This should be different from the primary LSP path.

This field is required only if the tunnel type selected is MPLS-RSVP. For MPLS-LDP and GRE tunnel types, this field is disabled.

NOTE: The LSP primary path and the secondary path cannot be the same.

4. From the respective list, select the Setup Priority, Reservation Priority, and the QoS Priority. These fields are available only when the selected tunnel type is MPLS-RSVP. For MPLS-LDP and GRE tunnel types, these lists are disabled.

5. Select the Enable Fast Reroute check box to enable fast reroute. This field is used only if the tunnel type selected is MPLS-RSVP. Otherwise, this field is disabled.

6. Specify the bandwidth reserved for reroute. This field is enabled only if the tunnel type is MPLS-RSVP and the Enable Fast Reroute check box is selected. Otherwise this field is disabled.

7. Specify the hop limit, which is the maximum number of hops. This field is enabled only if the tunnel type is MPLS-RSVP and the Enable Fast Reroute check box is selected. Otherwise this field is disabled.

8. Select the corresponding check boxes to enable node link protection and enable link protection. These check boxes are available only if the tunnel type is MPLS-RSVP.

9. Select the GRE interface if the tunnel type is GRE.

10. Specify the logical unit for the tunnel interface or software tunnel interface. This field is required only when he ttunnel type selected is GRE. For MPLS-RSVP and MPLS-LDP, this field is disabled.

4. Repeat Step 3 and all the substeps for the device endpoint, under Provide Destination Endpoint Details. Alternatively, click Copy Source Endpoint Details to use the the source endpoint settings for the destination endpoint.

5. Click Add Entry to add a record in the list area. For newly created records, the state is shown as New, for edited records the state is shown as Modified.

6. Do one of the following:

To add a new record, click Add.

To edit an existing record, elect a record and click Edit.



To copy an existing record, select a record and click Copy.

To delete an existing record, select record and click Delete.

To modify a record even though no changes have been made, select a record and click Force Deploy. You can use this option to push the configuration details to the devices, without making modifications, if you are editing the configuration.

7. Click Next to go to “Step 3: Confirming the Operation” on page 92.



92

Step 3: Confirming the OperationThe third step involves confirming the creation, deletion, or modification of the tunnel parameters that you selected in Step 2. A list of each change to be made is provided as shown in Figure 23 on page 92.


1. To confirm the operation, check each item in the list carefully to ensure that it is accurate.

2. If the list is correct, click Confirm to proceed to “Step 4: Provisioning the Tunnels” on page 93.

3. If problems are found with any of the tunnels, click Previous to return to “Step 2: Adding, Editing, or Deleting Tunnels” on page 89.



Step 4: Provisioning the TunnelsIn this step configurations are generated for MPLS/GRE tunnels and are pushed to devices. The wizard is shown in Figure 24 on page 93. Using this wizard, you can set the changes to occur immediately, save the changes for implementation at a later date, or specify that they occur on a specific schedule.


To provision the MPLS/GRE tunnel:

1. To have the changes occur immediately, click the Now button.

2. To save the changes for implementation at a later date, click Save Operation a and type a name for the changes.

3. To have the changes occur on a specific schedule, click Select Schedule and fill in the schedule. The configurations will be implemented at the scheduled time.

NOTE: The schedule can be chosen from those defined in Settings. See Figure 25 on page 94.

4. Click OK to set the selection.

New schedules can be configured by Settings > Schedules wizard as shown in Figure 25 on page 94. You have to enter a unique Schedule Name, Start Date, Start Time, Time Interval and Comment and then click OK to save the schedule. The comment is optional.



94

Figure 25: Add Schedule Menu



Pseudowire Provisioning Workflow

The workflow for pseudowire provisioning involves the following three steps:

Creating the Pseudowire Templates on page 95

Provisioning the Pseudowires on page 97

Filtering and Testing the Pseudowires on page 104

Creating the Pseudowire TemplatesYou must first create templates for the pseudowires. This template defines some of the common parameters, such as bandwidth, MTU and so on that can be reused across pseudowires.

Each template must have a unique name. Three type of templates are supported:

ATM

Ethernet

SAToP

The pseudowire template wizard is shown in Figure 26.

Figure 26: Pseudowire Template

Pseudowire Provisioning Workflow 95


96

To create a pseudowire template:

1. From Pseudowires, click Templates.

2. Select a pseudowire type and click Add.

3. Edit the parameters listed in Table 1 on page 96.

4. Click Save to save the template or Cancel to delete it.

Table 1: Pseudowire Template Parameters

Parameter Description

Common Parameters

Name A unique label for the pseudowire template.

Type Type of pseudowires. The following three types are supported: TDM (SAToP), ATM, and Ethernet.

Comment Optional comment field.

Control Word check box Add a control word to the Layer 2 encapsulation for the pseudowire.

Parameters for ATM and Ethernet

Encapsulation Available values for ATM are atm-ccc-cell-relay and atm-ccc-vc-mux.

Available values for Ethernet are ethernet-ccc, vlan-ccc, and extended-vlan-ccc.

Bandwidth Bandwidth available for the pseudowire.

Parameters for SAToP

Payload size Allowed range is 1 to 1024.

Idle pattern Allowed range is 0 to 255.

Excessive packet loss threshold

Allowed range is 1 to 100.

Excessive packet loss sample period

Allowed range is 1000 to 65535 milliseconds.

Excessive packet loss sample period

Specified in milliseconds.

Parameters for ATM

Mode Allowed options are 1–to-1–vcc, n–to-1-vcc, 1–to-1–vpc, n-to-1-vpc, aal5–pdu, and aal5–sdu.

Maximum Cell Concatenation The maximum number of ATM cells that can be concatenated before the packet switched network (PSN) packet is sent out.

Timeout The maximum time that the device should wait for the specified number of ATM cells to arrive for concatenation.

If the specified number of ATM cells have not arrived in the specified time period, the device concatenates the ATM cells that have arrived and sends out the PSN packet.

Sequence Number Check Allowed values are enable and disable.

Sequence Number Switchover Allowed values are enable and disable.



Provisioning the PseudowiresPseudowire provisioning is the process of creating, modifying, or deleting pseudowires between endpoints and pushing the configurations corresponding to the pseudowire to the devices. The steps for pseudowire provisioning are shown in Figure 27 on page 97.

Figure 27: Steps for Pseudowire Provisioning

g017

346

Choose devices for endpoints1

Add/Edit/Delete Pseudowires2Confirm operations3

Provision pseudowires4



98

Step 1: Choosing the Devices to be Used as EndpointsThe first step consists of choosing the source and destination devices to be used as endpoints as shown in Figure 28 on page 98.

Figure 28: Pseudowire Provisioning

You can select one of the device groups from a list of device groups already created or you can create device groups by grouping devices dynamically based on one of the following filtering criteria: location, name, hostname, or model.

You can also directly select devices that are already added to JUNOScope. In this case, all devices that are added to JUNOScope are listed in the Select Devices list.

To select source and destination devices:

1. Click the Select Devices Directly or Select a Device Group option button.

2. If you choose to select devices directly, you can either select the devices from the Select Devices list or filter the list of devices to generate a subset of devices based on the criterion of your choice. To filter the list of devices:

1. From the Select a Field list, select one of the following options: Device Name, Device Hostname, Model, Location, or Comment.

2. From the Select an Operator list, select one of the following options: Contains, Does not contain, Starts With, Ends With, or Equals.



3. Type a string and click View to display a list of devices that meet the criteria specified in the preceding substeps.

For example, to list devices that have device names starting with J, select Device Name from the Select Field list. From the Select an Operator list, enter J in the text box, and click View. All devices that have device names starting with J will be listed in the Select Devices list.

3. Click Next to proceed to Step 2: Adding, Editing, or Deleting Pseudowires on page 100.



100

Step 2: Adding, Editing, or Deleting PseudowiresThe second step consists of adding, editing, or deleting pseudowires. The wizard used to do this is shown in Figure 29 on page 100.

Figure 29: Pseudowire Provisioning Endpoint Details

Pseudowires already provisioned or newly created for provisioning for the devices are shown at the bottom of wizard. You can select a pseudowire from the list and modify, delete, or redeploy the configuration without making any changes to the configuration.

To add or modify a pseudowire:

1. Select the Source Device Name and Destination Device Name from the respective lists.

2. Select the pseudowire type. The options are: TDM (SAToP), ATM, and Ethernet.

3. Select a template and tunnel from the respective lists. The templates displayed depend on the pseudowire type selected. The options for Select Tunnel are: MPLS-RSVP, MPLS-LDP, or GRE.

4. (Optional) Specify the virtual circuit ID and, optionally, type a description.



If the virtual circuit ID is not specified, one is automatically generated for the pseudowire.

5. If the template type is ATM II, specify the VCI and VPI . These will be the same for both endpoints. If the interface type is not ATM, these fields are disabled.

6. If the interface type is Ethernet, specify the VLAN ID. The VLAN ID is the same for both endpoints. If the interface type is not Ethernet, this field is disabled.

7. For the source endpoint and destination endpoint, specify the following:

1. Device name

2. LSP name from the list of all LSPs configured on the endpoint devices that you have specified. The LSP name is mandatory if the selected endpoint is a BXOS device. The LSP name is optional if the endpoint is a JUNOS device.

3. Logical unit (number); the default value is 0. If you do not specify the logical unit, the system automatically assigns a unique number based on the pseudowires that have already been provisioned.

4. If the pseudowire will be provisioned over a GRE tunnel, select a GRE interface and a logical unit for the interface.

8. Click Add Entry. The pseudowire is listed at the bottom of the wizard.



102

Step 3: Confirming the OperationIn this step you confirm the addition, modification, or deletion of the pseudowire. A list of each change to be made is provided as shown in Figure 30 on page 102.

Figure 30: Pseudowire Provisioning Confirmation

To confirm the operation:

1. Check each item in the list carefully to ensure that it is accurate.

2. If the list is correct, click Confirm.

3. If problems are found with any of the pseudowires, click Previous to return to the previous step.



Step 4: Provisioning the PseudowiresThe final step is to set a time when the changes will be implemented. The wizard for this is shown in Figure 31 on page 103. Using this wizard, you can set the changes to occur immediately, save the changes for implementation at a later date, or to occur on a specific schedule.

Figure 31: Pseudowire Provisioning Scheduling

Configurations can be pushed either immediately or scheduled for a later time. Alternatively, you can save the configuration as a named operation.

To provision the pseudowires configured to the devices:

1. Select the Now option to push the configuration to the devices immediately.

2. Select the Save Operation as option and type a name for the operation. The configuration can be saved as a named operation.

3. Select the Schedule option to select a schedule. The configurations will be pushed at the scheduled time.

The schedules are configured by the Settings > Schedules wizard as shown in Figure 25 on page 94. You have to enter a unique Schedule Name, Start Date, Start Time, Time Interval and Comment and then click OK to save the schedule. The comment is optional.



104

Filtering and Testing the PseudowiresYou can use filtering criteria to monitor pseudowires that are already provisioned. Users with read-only, read-write, and superuser privileges have access to the filtering wizard. The filtering wizard is shown in Figure 32 on page 104.

Figure 32: Filter and Test Pseudowires

To filter and test pseudowires:

1. Click Filter and Test l2circuit Pseudowires.

2. Select one of the filter options. The following filtering criteria are supported:

All Pseudowires—View all the pseudowires provisioned by JUNOScope.

Select Device Group(s)—Select this option button and select one or multiple device groups to view all the pseudowires that are provisioned on devices in the selected groups.

Select Devices—Select devices from the list to view pseudowires provisioned on those devices.

Select Pseudowire Endpoints—Select from the lists the device names for endpoints to view pseudowires provisioned between these endpoints.

Select Virtual Circuit ID—Specify a virtual circuit ID to view all the pseudowires having that virtual circuit ID.



3. Click OK. The pseudowires are filtered according to the criteria you specified and displayed in a list. See Figure 33 on page 105.

Figure 33: Pseudowire Filter Results



106

4. Select a pseudowire and click View to display the details of the pseudowire, as shown in Figure 34 on page 106.

Figure 34: Pseudowire Circuit Details



5. Click Test to send the show l2circuit connections command to each endpoint of the pseudowire, and to show the results. See Figure 35 on page 107.

Figure 35: Show l2circuit connections Test Result



108

JUNOScope IP Backhaul Manager Image Management Summary

Image management is used for the upgrade or installation of a BXOS image on a BX7000 Multi-Access Gateway and the JUNOS image on an Aggregation Site Gateway (with a Circuit Emulation PIC). The software manager for the Circuit Emulation PIC is already supported in JUNOScope and is the same as installation on any JUNOS devices. The software manager for the BX7000 gateway supports installing or upgrading of both the BXOS software and the boot loader image on BX7000 gateway devices.

Image ManagementThe two protocols supported are HTTP and HTTPS. BX7000 gateway images are identified by the following naming conventions:

Software image: bxos-install-m.nIx.y

Boot loader image: bxboot-install-m.nIx.y

The following installation options are supported:

Create snapshot of primary image—Copy the primary image to secondary before installation.

Persist running configuration—Copy the running configuration to startup before installation.

Figure 36 on page 108 and Figure 37 on page 109 show examples of using the software manager.

Figure 36: Software Management



Figure 37: Software Manager Installation Options

JUNOScope IP Backhaul Manager Image Management Summary 109


110

Inventory ManagementScanning of BX7000 gateway devices is supported, however only software inventory and events inventory reports are available for BX7000 gateway devices. The software inventory report contains the device, model, version, and package name (primary image or boot loader). The JUNOS Version column has been renamed to Version to take into account both the BX7000 gateway and the JUNOS version. See Figure 38 on page 110.

Figure 38: Inventory Management


Chapter 6

Upgrading the Software

Your BX7000 Multi-Access Gateway comes with the software pre-installed. This guide assumes that the software for your BX7000 gateway is at least the following revision:

JUNOS version: 9.5 or later

BX7000 gateway image: bxos-install-3.0R2 or later

If you need to upgrade the software for any reason, follow the instructions in this section.

CLI-Based Software Upgrade Procedure for the BX7000 Gateway on page 111

Software Upgrade Procedure for the M Series Router on page 115

CLI-Based Software Upgrade Procedure for the BX7000 Gateway

Before starting the upgrade process, ensure that the following conditions are met:

1. You must have a connection to an FTP, HTTP, TFTP, or HTTPS server. This server is referred to as the service server.

2. The software package required for the flash memory upgrade is installed on one of the servers.

3. The network is configured in the BXOS and the service server is reachable from the unit that you are upgrading.

To execute the flash upgrade:

1. Boot the system.

2. Log in as user to display the CLI prompt.

3. Take a snapshot of the existing software image from CLI mode by typing:

request system snapshot

This is an example of the screen output:

bx7000@CLI# request system snapshotSystem snapshot in progress...

CLI-Based Software Upgrade Procedure for the BX7000 Gateway 111


112

Primary image name : bxos-install-3.0I18.4Primary image size : 34951301

Updating version information...Performing Flash Erase of length 262144 at offset 0x0 done

Erasing backup partition...Erase Total 134 UnitsPerforming Flash Erase of length 262144 at offset 0x2140000 done

Programming backup image...34133+0 records in34133+0 records out

bx7000@CLI#

4. Enter [edit system] by typing the following command:

bx7000@cli# edit system[edit system]bx7000@cli#

5. Execute the following software upgrade commands:

[edit system]bx7000@cli# set software-upgrade <protocol>://user:password@<hostname>:<port no>/filepath

For example:

[edit system]bx7000@cli# set software-upgrade ftp://test:[email protected]:21/bxos-install-3.0I13.8

NOTE: This step will take several minutes to complete.

6. After the successful upgrade, exit [edit system]:

[edit system]bx7000@cli# up

7. Request a system reboot:

bx7000@cli# request system reboot

After the reboot, the system will come up with the new version of the system component. The following is an example of the screen output from a successful upgrade session:

bx7000@CLI# edit system

[edit system]bx7000@CLI# set software-upgrade ftp://userid:[email protected]:21/bxos-install-3.0I18.4Software upgrade in progress....File downloaded in RAM. Updating the FLASH progress....



Upgrading BX-7000 OS image bxos-install-3.0I18.4...

Verifying image integrity...

Valid CRC foundFile size in bytes : 34952325

Updating image version information...Performing Flash Erase of length 262144 at offset 0x0 done

Preparing flash for image upgrade...Erase Total 134 UnitsPerforming Flash Erase of length 262144 at offset 0x2140000 done

Programming the image in flash...34132+1 records in34132+1 records out

Image upgrade successful. Please restart the system...

[edit system]bx7000@CLI# up

bx7000@CLI# request system rebootReboot the system ? (yes or no)yesRestarting system.

<truncated blank lines>

**************************************************************************** JUNIPER-BX7000****************************************************************************

Application memory test: Passed

SIDX version 3.0 release 5

Build date 30 Mar 2008All rights reserved (c) 2007-2008 Juniper Networks

Flash: AMD S29GL01GCore: WinPath2 847-Rev-A0 Wintegra mips24k Rev 101Board Id: WinPath2 1Board Rev: 2Serial No: 105CPLD VERSION ID: 2FCPLD2 VERSION ID: 2EFPGA ID: 55ee0000Framer0 ID: IDT82P2288Framer1 ID: IDT82P2288GigE Switch Id: BroadCom5396EPHY 0 Device ID: Broadcom BCM5482SEPHY 1 Device ID: Broadcom BCM5482SUSB Host Chip ID: ISP11760SFP 0 ID: NOT DETECTEDSFP 1 ID: FTLFCLOCK CARD: NOT DETECTEDDAUGHTER CARD: NOT DETECTED

CLI-Based Software Upgrade Procedure for the BX7000 Gateway 113


114

Board parameters: PLL: 798.1MhzInternal: 0x30600000, 32 Kbytes @ 266.0MhzParameter: 0x48000000, 128 Mbytes @ 199.500MhzPacket: 0x50000000, 128 Mbytes @ 199.500MhzApplication: 0x00000000, 256 Mbytes @ 199.500Mhz

MAC addresses: [eth0] 00:1F:12:80:03:00 [eth1] 00:1F:12:80:03:01 [eth2] 00:1F:12:80:03:02

IP address: 10.10.10.4Subnet mask: 255.255.255.0Default gateway: 10.10.10.1

Press ESC Key to enter into Field diagnosticsActive BXOS ...

Starting BXOS...

Starting application/routing stack...........................................Application/routing stack startup complete.Applying configuration.........................................Configuration complete.

bx7000 login:



Software Upgrade Procedure for the M Series Router

The M10i router is delivered with the JUNOS software pre-installed. To upgrade the software, you use CLI commands to copy a set of software images over the network to memory storage on the Routing Engine. The JUNOS software set consists of several images provided in individual packages or as a bundle. You normally upgrade all packages simultaneously. For further information about installing and upgrading JUNOS software, see the JUNOS Software Installation and Upgrade Guide.

To install the JUNOS software bundle:

1. Download the software to your local host.

2. Copy the software to the router (or to your internal software distribution site).

3. Install the new package on the router. Type the following command:

user@host> request system software add path/<JUNOS image name>

For example, name jinstall-5.7R4.3-domestic-signed.tgz for customers in the U.S. or jinstall-5.7R4.3-export-signed.tgz for all other customers, where path is the full pathname to the bundle.

4. Reboot the router to load the JUNOS software by typing the command:

user@host> request system reboot Reboot the system ? [yes,no] (no) yes Shutdown NOW!

Software Upgrade Procedure for the M Series Router 115


116
Software Upgrade Procedure for the M Series Router

Documents

Mobile Backhaul Solutions Guide - Juniper Networks