Designing and Implementing a Junos Node Unifier Network · 2013-07-17 · user@jnu1-ctrlr> opurl/var/db/scripts/op/jnu-initialize-controller.slax Controller initializations:

Junos®OS

Designing and Implementing a JunosNodeUnifierNetwork

Release

1.3

Published: 2013-07-17

Copyright © 2013, Juniper Networks, Inc.

Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, California 94089USA408-745-2000www.juniper.net

This product includes the Envoy SNMPEngine, developed by Epilogue Technology, an IntegratedSystemsCompany. Copyright© 1986-1997,Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no partof 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 documentationand 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 throughrelease 3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’sHELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateDsoftware 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, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the UnitedStates and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All othertrademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

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 or components thereof might be covered by one or more of the following patents that areowned 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.

Junos® OS Designing and Implementing Junos Node Unifier

Release 1.3Copyright © 2013, Juniper Networks, Inc.All rights reserved.

Revision HistoryJune 2013—R1 Junos Node Unifier 1.3

The information in this document is current as of the date on the title page.

ENDUSER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networkssoftware. Use of such software is subject to the terms and conditions of the End User License Agreement (“EULA”) posted athttp://www.juniper.net/support/eula.html. By downloading, installing or using such software, you agree to the terms and conditions ofthat EULA.

Copyright © 2013, Juniper Networks, Inc.ii

http://www.juniper.net/support/eula.html

Table of Contents

Part 1 Introduction to Junos Node Unifier

Chapter 1 Introduction to Junos Node Unifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Audience for Junos Node Unifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Junos Node Unifier Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Basic Architecture of a JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Terms Used in the JNU Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Chapter 2 Understanding the JNU Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

JNU Management Plane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

JNU Management Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Network Management in the Management Plane . . . . . . . . . . . . . . . . . . . . . . 9

JNU Data Plane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Part 2 Planning a JNU Implementation

Chapter 3 Planning Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Platform Considerations for the JNU Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Supported Platforms for JNU Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 4 Designs for JNU Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Design 1: One Controller with Satellites in a Star Configuration . . . . . . . . . . . . . . . 17

Design 2: Two Controllers Each With Satellites in a Star Configuration . . . . . . . . . 18

Design 3: Ring Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Design 4 V topology: Distributed Layer 2 and Layer 3 Mode . . . . . . . . . . . . . . . . . . 19

Chapter 5 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Server Farm: Ethernet Port Fan-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Service Provider Edge: Fiber to the Building (FTTB) . . . . . . . . . . . . . . . . . . . . . . . . 21

Video Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Part 3 Implementing JNU

Chapter 6 Best Practices for Configuring JNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Naming Your JNU Controller and Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . 27

Junos OS Releases on the JNU Controller and Satellites . . . . . . . . . . . . . . . . . . . . 27

Chapter 7 Getting Started with the JNU Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Installing the JNU Software on the Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Installing the JNU Software on Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 30

iiiCopyright © 2013, Juniper Networks, Inc.

Initializing JNU Mode on the Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Initializing JNU Mode on Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Running the Satellite Initialization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Sample Initial Configuration for an EX Series Switch . . . . . . . . . . . . . . . . . . . 40

Sample Initial Configuration on an ACX Universal Access Router . . . . . . . . . 42

Sample Initial Configuration on an EX3300 Ethernet Switch . . . . . . . . . . . . . 44

Chapter 8 Configuring Junos OS Features with JNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Configuring Junos Features with JNU Configuration Templates . . . . . . . . . . . . . . 49

Displaying a List of Configuration Templates . . . . . . . . . . . . . . . . . . . . . . . . . 49

Displaying the Configuration Parameters in a Template . . . . . . . . . . . . . . . . . 50

Configuring the Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Committing the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Configuring Junos Features with JNU Free Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 9 Committing Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Commit Process for Satellites Already Connected to the Controller . . . . . . . . . . . 53

Commit Process for Satellite Devices That Come Online After the Commit

Process on the Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Returning to a Previously Committed Junos OS Configuration . . . . . . . . . . . . . . . 55

Chapter 10 JNU Operational Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Using Operational Mode Commands with JNU Overview . . . . . . . . . . . . . . . . . . . 57

config-free-form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

config-template-name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

jnu-add-delete-satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

jnu-commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

jnu-initialize-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

jnu-order-satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

jnu-port-extender-command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

jnu-show-port-extender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

jnu-remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

jnu-rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

jnu-show-satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

jnu-show-configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

op . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapter 11 Setting Up a Basic JNU Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Example: Setting Up a Basic JNU Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 83

Chapter 12 JNU Port Extender Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Extending a Satellite Interface to a Controller Overview . . . . . . . . . . . . . . . . . . . . 95

Initializing JNU Port-Extender Mode on the Controller and Satellite Devices . . . . 97

Initializing the JNU Port-Extender Mode on the Controller . . . . . . . . . . . . . . . 97

Initializing JNU Port-Extender Mode on Satellite Devices . . . . . . . . . . . . . . . . 98

Monitoring the Extended Satellite Interfaces Anchored on the Controller . . . . . . 99

Configuring the Port Extender on the Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Format and Processing of the config-interfaces Command . . . . . . . . . . . . . 101

Configuring a Physical Interface Extension to a Controller . . . . . . . . . . . . . . 102

Configuring a Logical Interface Extension to a Controller . . . . . . . . . . . . . . . 103

Configuring a Satellite Aggregated Ethernet Port-Extender . . . . . . . . . . . . . 104

Copyright © 2013, Juniper Networks, Inc.iv

JNU 1.3 Design and Implementation Guide

Configuring VLAN IDs for Satellite Interface Extension . . . . . . . . . . . . . . . . . 104

Configuring an Anchor Interface on a Controller . . . . . . . . . . . . . . . . . . . . . . 108

Configuring Multichassis Aggregated Ethernet Interfaces in JNU Port Extender

Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Configuration on EX1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Configuration on MX1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Configuration on MX2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Configuration on EX2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Processing of Configuration Templates in JNU Port-Extender Mode . . . . . . . . . . . 117

Layer 2 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Layer 3 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

System-Level Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Firewall Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

CoS Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Processing of Free-Form Settings in JNU Port-Extender Mode . . . . . . . . . . . . . . . 122

Part 4 Monitoring and Troubleshooting in the JNU Network

Chapter 13 Monitoring in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Centralized Collection of SNMP Statistics and Log Messages Overview . . . . . . . 125

SNMP Community Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Collecting Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

SNMP Get Process in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

SNMP Trap Process in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

System Logging in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Network Time Protocol (NTP) in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . 130

Configuring the JNU Controller as an SNMP Proxy Agent . . . . . . . . . . . . . . . . . . . 131

Chapter 14 Using the Junos OS CLI to Monitor and Manage Satellite Devices . . . . . . . 133

Using the Junos OS CLI to Monitor and Manage Satellite Devices . . . . . . . . . . . . 133

Displaying Active Satellite Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Displaying the Committed Satellite Configuration . . . . . . . . . . . . . . . . . . . . . 133

Changing the Order of Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Part 5 Upgrading Software in the JNU Network

Chapter 15 Upgrading Software in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Upgrading Junos OS on Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Upgrading JNU Software on Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Upgrading JNU Software on Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

vCopyright © 2013, Juniper Networks, Inc.

Table of Contents

Copyright © 2013, Juniper Networks, Inc.vi


PART 1

Introduction to Junos Node Unifier

• Introduction to Junos Node Unifier on page 3

• Understanding the JNU Architecture on page 7

1Copyright © 2013, Juniper Networks, Inc.

Copyright © 2013, Juniper Networks, Inc.2


CHAPTER 1

Introduction to Junos Node Unifier

• Audience for Junos Node Unifier on page 3

• Junos Node Unifier Overview on page 4

• Basic Architecture of a JNU Network on page 5

• Terms Used in the JNU Documentation on page 5

Audience for Junos Node Unifier

This guide is intended to assist service providers to design and plan an implementation

for Junos Node Unifier (JNU). We intend the guide to be used by the following:

• Network architects—Responsible for creating the overall design and architecture of

the dual-stack network.

• Network planners—Responsible for planning the implementation from a network

perspective, including equipment.

• Network operations engineer—Responsible for creating the configuration that

implements the overall design. Also responsible for deploying the implementation and

actively monitoring the network.

• Sales engineers—Responsible for working with architects, planners, and operations

engineers to design and implement the network solution.

RelatedDocumentation

Junos Node Unifier Overview on page 4•



• JNUManagement Plane Overview on page 7


Junos Node Unifier Overview

Junos Node Unifier (JNU) allows you to configure andmanagemany Juniper Networks

platforms running Junos OS from one MX Series router. You can use JNU tomanage

thousandsof 1-Gigabit and 10-Gigabit Ethernet ports in a single site or that aredistributed

across multiple sites from a single point. Starting with JNU Release 1.3, you can also

configure an EX9000 Ethernet Switch as a controller.

JNUprovides single-touchprovisioning fromoneMXSeries routeroranEX9000Ethernet

Switch acting as a controller. It provides a single point of:

• Configuration andmanagement

• Running operational mode commands

• SNMP polling and SNMP traps

• Collecting logging information

The JNU software answers the following needs:

• Ethernet port fanout or port multiplexer to control thousands of Ethernet ports from

one MX Series router.

• Layer 2 switching onmanaged devices tomeet Data Center needs, such as server port

aggregation.

• Layer 3 MPLS routing onmanaged devices to provide business access andmobile

backhaul applications.


Basic Architecture of a JNU Network on page 5•



• Example: Setting Up a Basic JNU Implementation on page 83



Basic Architecture of a JNUNetwork

Thebasic architectureof a JNU implementation is a star configurationwithoneMXSeries

router acting as a hub to the connected satellite devices. The satellite devices are devices

running the Junos operating system (Junos OS), such as EX Series Ethernet switches,

QFX Series devices, and ACX Series Universal Access routers. Starting with JNU Release

1.3, you can also configure an EX9000 Ethernet Switch as a controller.

Figure 1: Basic JNU Architecture

g041

392

Satellites

Controller


Junos Node Unifier Overview on page 4•




Terms Used in the JNU Documentation

Table 1 on page 5 defines terms used in the JNU documentation.

Table 1: JNU Terms

DefinitionTerm

AnMX Series router that is used to manage and configure satellite devices. Starting with JNURelease 1.3, you can also configure an EX9000 Ethernet Switch as a controller.

Controller

Junos Node Unifier.JNU

Platforms that are managed by the controller.Satellite


Chapter 1: Introduction to Junos Node Unifier







CHAPTER 2

Understanding the JNU Architecture


• JNUManagement Network on page 8

• JNU Data Plane Overview on page 10

JNUManagement Plane Overview

The JNU software uses a private management plane on the MX Series controller to

manage satellite devices as follows. Startingwith JNURelease 1.3, you can also configure

an EX9000 Ethernet Switch as a controller.

• Provision satellite devices

• Operate satellite devices

• Perform SNMP polling and trap collection

• Collect logs


JNUManagement Network on page 8•




JNUManagement Network

The JNUarchitecture provides a privatemanagement plane for JNU that is separate from

the control plane and the data plane. This design provides maximum performance and

reliability and the ability to efficiently scale the JNU network. Figure 2 on page 8 shows

a basic JNUmanagement network. This network is created during the JNU initialization

process.

Figure 2: JNUManagement Network

g041

394

Controller

NMS, Syslog, NTP

Private IP subnetPrivate VLAN

Private Management Plane forJNU on private routing instance

Satellites

Secure session between controllerand satellites (NETCONF SSH)



The JNUmanagement network is created during the JNU initialization process. The

process creates a private network for in-bandmanagement, and the configuration is

placed in a configuration group on the controller and on each satellite device.

Themanagement network has the following characteristics:

• Ethernet interfacesareused for theconnectionbetween thecontroller and thesatellites

and between the controller and network management systems (NMSs). A private

VLAN between the controller and the satellite devices is used to separate JNU

management traffic from data plane traffic.

During the initialization process, you specify the physical interfaces, VLAN IDs, and IP

addresses to be used in the management network for the downlink connection from

the controller to the satellites, and for the uplink connection from the satellites to the

controller.

By default the software places the Ethernet interfaces into an aggregated Ethernet

bundle. If you specify only one physical interface during initialization, you have the

option to not use aggregated Ethernet.

• The following private routing instances are created on the controller during the

initializationprocess. These routing instancesarenot visibleoutsideof the JNUNetwork.

• A private VPN routing and forwarding (VRF) routing instance to provide address for

Layer 3 VPNs. The VRF routing instancemakes it possible to reuse themanagement

network IP addresses in the data plane.

• A private virtual-switch routing instance is created on the controller for the Layer 2

VPN. The virtual-switch routing instances makes it possible to reuse the VLAN IDs

in the data plane.

An integrated routing and bridging (IRB) interface is created that is used to provide

IP addresses to the virtual switch.

• If supported, a routing instance is created on the satellite device that contains the

uplink configuration from the satellite to the controller.

• A secure NETCONF-over-SSH connection is created between the controller and the

satellite device.

NetworkManagement in theManagement Plane

During thecontroller initializationprocess, youhave theoptionof settingupSNMP, system

logging, andNTP. If you choose to set up these features, the initialization process creates

a network configuration over an Ethernet interface to theNMS servers. The configuration

includes static routes to these servers in the VPN routing and forwarding (VRF) routing

instance on the controller.

The initialization process creates a Network Address Translation (NAT) configuration

that is used to translate the source address of the traffic sent to the SNMP or syslog

server so that all network management traffic from the satellite devices originates from

a source address on the controller.

You do not need a license to use NATwith the JNUmanagement plane.


Chapter 2: Understanding the JNU Architecture


JNUManagement Plane Overview on page 7•


• Initializing JNUMode on the Controller on page 30

• Running the Satellite Initialization Process on page 38

• Centralized Collection of SNMP Statistics and Log Messages Overview on page 125

JNU Data Plane Overview

The data plane of the controller and satellite devices, which is responsible for forwarding

user data, is separate from themanagement plane. If your satellite device supports

routing instances, themanagement configuration is placed in a routing instance, and you

can reuse IP addresses that were used for JNUmanagement.

For load balancing and fast recovery, you can use link aggregation of both the

management interfaces and data plane instances.

Figure 3: JNU Architecture with Data Plane

g041

395

Controller

NMS, Syslog, NTP

Management Plane

Satellites

User Data Plane traffic designedto work with different Control Plane





• JNUManagement Network on page 8


Chapter 2: Understanding the JNU Architecture



PART 2

Planning a JNU Implementation

• Planning Overview on page 15

• Designs for JNU Implementations on page 17

• Use Cases on page 21




CHAPTER 3

Planning Overview

• Platform Considerations for the JNU Controller on page 15

• Supported Platforms for JNU Satellite Devices on page 15

Platform Considerations for the JNU Controller

You can use anyMXSeries 3DUniversal EdgeRouter as the JNUcontroller. TheMXSeries

router uses Modular Port Concentrators (MPCs) to connect to the satellites.

Youmust use anMX Series router as the controller, and youmust use MPCs (not DPCs).

We recommend that you allocatemore than one interface for interconnect betweenMX

Series routers and satellites. These interfaces will be placed into link aggregation (LAG)

configuration for fast recovery, with traffic spreading across member links.

AnMXSeries router canmanage one satellite on each of its Ethernet ports. For example,

the MX960 router supports up to 176 10-Gigabit Ethernet interfaces. It can therefore

manage up to 176 satellite devices on the 10-Gigabit Ethernet interfaces.


Supported Platforms for JNU Satellite Devices on page 15•


Supported Platforms for JNU Satellite Devices

JNU 1.3 supports the following satellite devices:

• ACX1000 Universal Access Router

• ACX2000 Universal Access Router

• EX3200 Ethernet Switch







• QFX 3500 devices

• MX5, MX10, MX40, and MX80 Universal Edge routers


• Platform Considerations for the JNU Controller on page 15




CHAPTER 4

Designs for JNU Implementations

Youcanconfigure the satellite andcontroller devices ina JNUgroup indifferent topologies

or designs, depending on your network needs and deployment requirements.

• Design 1: One Controller with Satellites in a Star Configuration on page 17

• Design 2: Two Controllers EachWith Satellites in a Star Configuration on page 18

• Design 3: Ring Topology on page 19

• Design 4 V topology: Distributed Layer 2 and Layer 3 Mode on page 19

Design 1: One Controller with Satellites in a Star Configuration

This topology is a simple star topology with one JNU controller connected to a group of

satellite devices.

Figure 4: Controller with Satellites in a Star Configuration

g041

392

Satellites

Controller


Design 2: Two Controllers EachWith Satellites in a Star Configuration on page 18•

• Design 3 Ring Topology on page 19



Design 2: Two Controllers EachWith Satellites in a Star Configuration

This star topology is characterized by two groups of satellite devices each connected to

their own hub device, or controller. There is no connection between the satellites in one

hub to the group of satellites in the other hub. One controller can control all of the

associated satellite devices.

Figure 5: Two Controllers EachWith Satellites in a Star Configuration

Satellites

Controller 2

g041

393

Servers dual attached to verticallyintegrated network stacks

Satellites

Controller 1

In this design, you deploy one JNU controller in active forwarding mode and the second

JNU controller in standby forwarding mode. If the active JNU controller or its satellites

fail, there is a switchover to the second controller.

The servers choose the active JNU controller by activating a set of interfaces connected

to that controller. In case of a failure, the JNU takes down the server connection port(s)

and switches to the second JNU controller by activating the interface set configured on

that controller. The controllers can use theMXSeriesmultichassis link aggregation group

(MC-LAG) active-active functionality to provide a smooth switchover from one JNU

controller to the other.

This model provides two independent JNU silos for resiliency, and use only one at a time

through the control of the servers. This model has the advantage of simplicity, but only

50 percent of equipment is likely to be in use at any time.


Design 1: One Controller with Satellites in a Star Configuration on page 17•





Design 3: Ring Topology

This topology comprisesMXSeries routers in aVirtualChassis configuration, that function

as controllers, connected to the satellites in a JNU group in a ring or a circular fashion.

The control plane uses MPLS in this JNU deployment. Here the traffic flows in a circular

manner across the network. Each controller in the Virtual Chassis group is connected to

the satellites that are at the top of the ring on either side of the circle. Therefore, a

controller is connected to two satellites in the ring, which in turn are connected to other

satellites in a circular pattern. In a ring topology, if a connection is lost, each device

maintains connectivity to the other neighboring devices. In this network model, extra

cabling is required to close the loop. Network resiliency is low for the network can recover

from the loss of a single connection. Multiple paths reduce the possibilities for

oversubscription and bottlenecks. In the cable plants floor layout, there is increased

flexibility and reduced complexity.


Design 1: One Controller with Satellites in a Star Configuration on page 17•



Design 4 V topology: Distributed Layer 2 and Layer 3Mode

This topology comprisesMXSeries routers in aVirtualChassis configuration, that function

as controllers, connected to each of the satellites in a JNU group. If the one of the JNU

controllers in the Virtual Chassis cluster fails, there is a switchover to another controller

to manage the satellites. JNU is designed to work with the control plane option of VLAN

tagging in this type of deployment. A Virtual Chassis configuration enables a collection

ofmember routers to functionasa single virtual router, andextends the featuresavailable

on a single router to the member routers in the Virtual Chassis. The interconnected

member routers in a Virtual Chassis are managed as a single network element that

appears to the network administrator as a single chassis with additional line card slots,

and to the access network as a single system.


• Design 1: One Controller with Satellites in a Star Configuration on page 17




Chapter 4: Designs for JNU Implementations



CHAPTER 5

Use Cases

JNU enables the deployment of rich services on the satellite devices bymaintaining their

full individual device feature set while in the cluster mode, including Layer 2 switching

on satellite for server port aggregation, and Layer 3 or MPLS routing on satellites for

business access andmobile backhaul.

• Server Farm: Ethernet Port Fan-Out on page 21

• Service Provider Edge: Fiber to the Building (FTTB) on page 21

• Video Streaming on page 22

• Mobile Backhaul on page 22

Server Farm: Ethernet Port Fan-Out

In a topology in which an MX Series device that works as a controller andmanages EX

Series switches and QFX Series switches that are satellites in a JNU group, the satellites

might be in turn connected to other external servers in the manner of a farm. In such a

scenario, you canuse JNU toenable thousandsof Ethernet ports tobeadministered from

one MX Series device. The network services are positioned in the most cost-effective

location and a single touch-point from the controller can enable many services to be

managed. The EX Series switches enable many Gigabit Ethernet ports to be used to

connect to external legacy servers by deriving the advantages of optimal infrastructure

costs and providing Layer 2, CoS, and filtering capabilities. The QFX Series switches

enable many 10-Gigabit Ethernet ports to be used to connect to advanced, new servers

by deriving the advantages of optimal infrastructure costs and providing Layer 2, CoS,

and filtering capabilities. You can also perform local switching for the servers from the

EX Series devices without having to modify the settings from the controller.


Service Provider Edge: Fiber to the Building (FTTB) on page 21•



Service Provider Edge: Fiber to the Building (FTTB)

A typical service provider edge fiber to the home (FTTH) use case is a network that

contains an MX Series router that functions as a controller governs andmanages two

satellite devices, such as an EX Series switch that is capable of Layer 2 and Layer 3


functionalities and an MX Series device that is used for subscriber services. In a network

without the JNU solution, each network element has to be provisioned, configured,

managed, and debugged separately. This proves to be a huge operational expense and

nightmare for service providers.With the JNU solution, a singlemanagement and control

plane is created on the MX Series controller device. Many services can bemanaged and

provisioned from a single touch-point on this controller, thus reducing the time to deploy

new services significantly. Moreover, the devices acting in satellite mode retain their rich

Layer 2 and Layer 3 features, class of service (CoS), filtering, and alsoMPLS on the edge.

Moreover, the solution uses standard protocol and allows packet replication and group

membership, all of which are highly desirable for video streaming applications. With the

JNUsolution, thenuancesof the satellitedevicesarehidden fromtheoperator. A standard

provisioning stanza is shared across the controller and the satellite devices, which allows

the network to grow seamlessly, with each additional satellite device acting as a

plug-and-play device.


Server Farm: Ethernet Port Fan-Out on page 21•



Video Streaming

Withmulticasting, servers can send a single stream to a group of recipients instead of

sending multiple unicast streams. While the use of streaming video technology was

previously limited to occasional company presentations, multicasting has provided a

boost to the technology resulting in a constant stream of movies, real-time data, news

clips, and amateur videos flowing nonstop to computers, TVs, tablets, and phones.

However, all of these streams quickly overwhelmed the capacity of network hardware

and increased bandwidth demands leading to unacceptable blips and stutters in

transmission.

Consider a network environment in which the controller that manages satellites is used

for streamingof videoandmultimedia toend-usersor subscribers.Videostreamleverages

the functional capabilities of the satellite and enables snooping, groupmembership, and

packet replication to be implemented. Each stream from the controller is multiplied by

the satellites corresponding to the recipients. The advantage is minimized bandwidth

between the controller and the satellites, thereby reducing administrative costs and

compatibility with standard protocols for streaming.


Server Farm: Ethernet Port Fan-Out on page 21•



Mobile Backhaul

A commonmobile backhaul use case represents MX Series routers in a Virtual Chassis

configuration that acts a controller and ACX Series routers that function as satellites.



With JNU, connecting each port of the MX Series with the satellite and enabling the port

to run in JNUmodecan increaseport density. Thesedevices canbe configured,managed,

and provisioned from the controller. Moreover, the satellites also have a sophisticated

feature set, which allows them to perform technologies such as MPLS on the satellites.

In the mobile backhaul scenario, the ACX Series router is primarily used in the access

layer as the cell site router and the MX Series router is used as the edge and aggregation

router. As the cell site router, the ACX Series router connects the base station (BS) to

the packet network. Several cell site routers canbe connected in a ring or hub-and-spoke

fashion to the upstream preaggregation and aggregation routers (MX Series routers).


• Server Farm: Ethernet Port Fan-Out on page 21




Chapter 5: Use Cases



PART 3

Implementing JNU

• Best Practices for Configuring JNU on page 27

• Getting Started with the JNU Software on page 29

• Configuring Junos OS Features with JNU on page 49

• Committing Configurations on page 53

• JNU Operational Mode Commands on page 57

• Setting Up a Basic JNU Implementation on page 83

• JNU Port Extender Mode on page 95




CHAPTER 6

Best Practices for Configuring JNU

• Naming Your JNU Controller and Satellite Devices on page 27

• Junos OS Releases on the JNU Controller and Satellites on page 27

Naming Your JNU Controller and Satellite Devices

It is important to plan the naming of controller and satellite devices in a JNU group so

that you can easily identify the satellites that belong to the same group. The hostname

of satellites is used in SNMP community strings and system log prefixes to identify the

satellite associated with the SNMPmessage or system logmessage.

A naming structure like the following is recommended:

• jnu1-ctrl as the controller hostname

• jnu1-sat1, jun1-sat2, jun1-sat3, and so on as the satellite hostnames

Junos OS Releases on the JNU Controller and Satellites

We recommend that you run the same Junos OS release on the controller and on the

satellite devices.




CHAPTER 7

Getting Started with the JNU Software

• Installing the JNU Software on the Controller on page 29

• Installing the JNU Software on Satellite Devices on page 30


• Initializing JNUMode on Satellite Devices on page 38

Installing the JNU Software on the Controller

To load the JNU package onto the controller:

• Enter the following command on the MX Series controller. For example:

user@jnu1-ctrlr> request system software add jnu-1.2R1.2-signed.tgzInstalling package '/var/tmp/jnu-1.2R1.2-signed.tgz' ...Verified jnu-1.2R1.2.tgz signed by PackageProduction_11_4_0 Adding jnu...Available space: 556676 require: 3220NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-installMounted jnu package on /dev/md10...Restarting bslockd ...mgd: commit completeSaving package file in /var/sw/pkg/jnu-1.2R1.2-signed.tgz ...Saving state for rollback ...


Initializing JNUMode on the Controller on page 30•



Installing the JNU Software on Satellite Devices

To load the JNU package onto the satellite device:

• Enter the following command on the satellite device. For example:

user@jnu-satellite1> request system software add jnu-1.2R1.2-signed.tgzInstalling package '/var/tmp/jnu-1.2R1.2-signed.tgz' ...Verified jnu-1.2R1.2.tgz signed by PackageProduction_11_4_0 Adding jnu...Available space: 556676 require: 3220NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-installMounted jnu package on /dev/md10...Restarting bslockd ...mgd: commit completeSaving package file in /var/sw/pkg/jnu-1.2R1.2-signed.tgz ...Saving state for rollback ...


Running the Satellite Initialization Process on page 38•



Initializing JNUMode on the Controller

NOTE: In this guide, all the instances of JNUmode refer to both the JNUfeature-rich and port-extender modes, unless explicitly stated otherwise.



After you install the JNU software, you need to initially configure and initialize the MX

Seriescontroller. The initializationprocesscreatesa JNUmanagementplaneconfiguration

on the controller and places it in a configuration group called jnu-controller-mgmt. The

management plane configuration involves interfaces, internal routing-instance,

virtual-switch bridging, SNMP, system logs, NTP, and NAT in the main instance of the

configuration.

As part of the initialization process, the JNU configuration is committed on the controller.

When you initialize the controller and the satellite devices, youmust be logged in to the

controller or satellite as the root user. The initialization process creates a user account

called jnuadmin,which the controller uses to log in to the satellites. After the initialization

process is complete, log in to the controller using the jnuadmin user account.

The first time you initialize the controller, you must enter the full command op url

/var/db/scripts/op/jnu-initialize-controller.slax. Thereafter, you can reinitialize the

controller using the op jnu-initialize-controller command.

For a description of the fields used to initialize the controller, see jnu-initialize-controller.

This example configures the controller, adds two satellite devices to the controller

configuration.

To initially configure the controller:


Chapter 7: Getting Started with the JNU Software

1. Enter the jnu-initialize-controller command and follow the prompts.

user@jnu1-ctrlr> op url /var/db/scripts/op/jnu-initialize-controller.slaxController initializations: Please select the JNU mode: 1. Feature-rich mode The controller and satellite features are supported. Configurations are forwarded to the satellites when the target device is a satellite managed by this controller. 2. Port Extender mode Interfaces on the satellites are extended to the satellites. Features are configured on the extended ports.

JNU mode (1/2)? 2 Please enter hostname [jnu-controller]: Please enter management IP address: 137.34.1.1 Please enter JNU downlink IP prefix [192.168.0.1/24]: Please enter JNU VLAN id [4094]: Do you want to configure any satellites now [n]: y Please enter the number of satellites [1]: 2 Satellite 1 Please enter the hostname of the satellite: jnu-sat1 Please enter satellite management IP address: 10.0.0.1 Please enter the uplink IP address of the satellite: 192.168.0.2 Please enter downlink interfaces to satellite: ge-0/0/0 Do you want to use aggregated-ethernet for the downlink [y]: y Please enter downlink aggregate name [ae31]: Satellite 2 Please enter the hostname of the satellite: jnu-sat2 Please enter satellite management IP address: 10.0.0.2 Please enter the uplink IP address of the satellite: 192.168.0.3 Please enter downlink interfaces for satellite: ge-0/0/1,ge-0/0/2 Do you want to configure SNMP [n]: y Do you want to enter a read-only community string (y|n)? y SNMP read-only community string: public Do you want to enter a read-write community string (y|n)? y SNMP read-write community string: private Do you want to enter SNMP trap parameters (y|n)? y SNMP trap target address: 169.37.0.1 Do you want to enter SNMP trap categories (y|n)? y Please enter SNMP trap group name: public Do you want to enable SNMP trap for 'otn-alarms' (y|n)? y Available alarms: 'oc-lof', 'oc-lom', 'oc-los', 'odu-ais', 'odu-bbe-threshold', 'odu-bdi', 'odu-es-threshold', 'odu-lck', 'odu-oci', 'odu-rx-aps-change', 'odu-sd', 'odu-ses-threshold', 'odu-sf', 'odu-ttim', 'odu-uas-threshold', 'opu-ptm', 'otu-ais', 'otu-bbe-threshold', 'otu-bdi', 'otu-es-threshold', 'otu-fec-deg', 'otu-fec-exe', 'otu-iae', 'otu-sd', 'otu-ses-threshold', 'otu-sf', 'otu-ttim', 'otu-usa-threshold', 'wavelength-lock' Please enter otn-alarms: oc-lof,oc-lom Do you want to enable SNMP trap for 'sonet-alarms' (y|n)? y Available alarms: 'ber-defect', 'ber-fault', 'line-ais', 'line-remote-defect-indication',

'loss-of-cell', 'loss-of-frame', 'loss-of-light', 'loss-of-pointer', 'loss-of-signal', 'path-ais', 'path-mismatch', 'path-remote-defect-indication', 'pll-lock', 'remote-error-indication',

'severely-errored-frame', 'unequipped', 'vt-ais', vt-label-mismatch',



'vt-loss-of-cell', 'vt-loss-of-pointer', 'vt-remote-defect-indication',

'vt-unequipped' Please enter sonet-alarms: path-ais Other categories: 'authentication', 'chassis', 'configuration', 'link', 'remote-operations', 'rmon-alarm', 'routing', 'services', 'startup', 'vrrp-events' Do you want to enter other SNMP trap categories (y|n)? y Please enter SNMP trap categories: vrrp-events Do you want to configure Syslog server [n]: y Syslog host address? 167.37.0.1 port number [123]: Syslog facility 'all' [n]: Syslog facilities: 'authorization', 'change-log', 'conflict-log', 'daemon', 'dfc', 'explicit-priority', 'external', 'firewall', 'ftp', 'interactive-commands', 'kernel', 'log-prefix', 'ntp', 'pfe', 'security', 'user' Syslog severities: 'alert', 'any', 'criticial', 'emergency', 'error', 'info', 'none', 'notice', 'warning' Please enter syslog facility name: change-log Please enter severity: info Do you want to enter more syslog facilities [n]? Do you want to configure NTP [n]: y NTP server address: 188.88.0.1

JNU controller configuration completed

The following is an example of the configuration created on the controller as a result of

running the controller initialization process.

groups {jnu-controller-mgmt {chassis {aggregated-devices {ethernet {device-count 480;

}}/* Slot of the Trio FPC */fpc 5 {pic 0 {inline-services {bandwidth 1g;

}}

}}system {ntp {/* The server is in themain routing-instance, *//* the server parameters will not be propagated to the satellites */server 188.88.0.1; /* external server */

}syslog {



host 169.37.0.2 {security info;change-log info;/* All the syslog parameters are propagated to satellite *//* except source-address. The source address used by *//* the satellites are themgmt address on satellite */source-address 137.34.1.1;

}file messages {any any;

}}services {ssh;

}}snmp {/* community is configured by user, satellite community string is *//* <controller_community_string>:<satellite-name> */community public {authorization read-only;

}community private {authorization read-write;

}trap-options {source-address lo0;

}trap-group public {/* categories are configured by user, propagate to satellite */categories {authentication;routing;

}/* targets are configured by user, propagate to satellite */targets {169.37.0.1;

}}/* Need SNMP proxy configuration */proxy jnu-sat1 {device-name 192.168.0.2;version-v2c {snmp-community public:jnu-sat1;

}routing-instance jnu-vrf;

}proxy jnu-sat2 {device-name 192.168.0.3;version-v2c {snmp-community public:jnu-sat2;


}}interfaces {



/* All the interfaces connecting to satellites */ge-0/0/0 {gigether-options {802.3ad ae479;

}}si-5/0/0 {unit 0 {family inet;family inet6;

}unit 1 {family inet;service-domain inside;

}unit 2 {family inet;service-domain outside;

}}ae479 {/* Using aggregate-ethernet interface because there can be *//*multiple physical downlinks */aggregated-ethernet-options {lacp {active;

}}vlan-tagging;encapsulation flexible-ethernet-services;unit 16385 {encapsulation vlan-bridge;vlan-id 4094;

}}irb {unit 16385 {family inet {address 192.168.0.1/24;

}}

}}policy-options {policy-statement reject-all {then reject;

}}routing-instances {jnu-vrf {instance-type vrf;interface irb.16385;interface si-5/0/0.1;route-distinguisher 192.168.0.1:0;vrf-import reject-all;vrf-export reject-all;



routing-options {static {/* Static route to SNMP trap server via si-interface */route 169.37.0.1/32 next-hop si-5/0/0.1;/* Static route to syslog server via si-interface */route 169.37.0.2/32 next-hop si-5/0/0.1;

}}

}jnu-vs {instance-type virtual-switch;bridge-domains {jnu {vlan-id 4094;interface ae479.16385;routing-interface irb.16385;

}}

}}services {service-set ss-nat {nat-rules jnu-use-controller;next-hop-service {inside-service-interface si-5/0/0.1;outside-service-interface si-5/0/0.2;

}}nat {/* There needs to be 1 NAT pool (with the same address) per satellite */pool jnu-sat1 {/* Use Management IP address */address 137.34.0.1/32;

}pool jnu-sat2 {/* Use Management IP address */address 137.34.0.1/32;

}allow-overlapping-nat-pools;rule jnu-use-controller {match-direction input;term jnu-sat1 {/* Each satellite connection will use 1 term on its own */from {source-address {/* 1st satellite */10.0.0.1/32;

}}then {translated {source-pool jnu-sat1;translation-type {basic-nat44;

}}



}}term jnu-sat2 {/* Each satellite connection will use 1 term on its own */from {source-address {/* 2nd satellite */10.0.0.2/32;

}}then {translated {source-pool jnu-sat2;translation-type {basic-nat44;

}}

}}

}}

}}

}


jnu-initialize-controller on page 62•


• Initializing JNUMode on Satellite Devices on page 38



Initializing JNUMode on Satellite Devices


• Sample Initial Configuration for an EX Series Switch on page 40

• Sample Initial Configuration on an ACX Universal Access Router on page 42

• Sample Initial Configuration on an EX3300 Ethernet Switch on page 44

Running the Satellite Initialization Process

Whenyou initialize the satellite device, the software createsamanagement configuration

on the device that allows the controller to configure andmanage the satellite.

When you run the satellite initialization process, the controller connects to the satellite

and copies JNU code elements that are based on scripting technology to the satellite.

Before you initialize the satellite device, youmust configure a root (superuser) password

by including the root-authentication statement at the [edit system] hierarchy level.When

you initialize the satellite devices, youmust be logged in to the satellite as the root user.

The satellite initialization process creates a configuration as follows:

• Creates a user account called jnuadmin, which the controller uses to log in to the

satellites. After the initialization process is complete, log in to the controller using the

jnuadmin user account.

• Loads an SSH public key onto the satellite device and sets up a NETCONF-over-SSH

connection for use between the controller and the satellite device.

• Creates a configuration group called jnu-satellite-mgmt. The configuration includes

both the configuration resulting from parameters that you specify during the satellite

initialization process and the configuration that is propagated from the controller.

Table 2 on page 39 describes the fields in the satellite initialization process.



Table 2: JNU Satellite Initialization Fields

DescriptionField

JNUmode in which the satellite device in a JNU groupmust function. Two JNUmodes available are:

• 1. Feature-richmode—Thismode is also called non-port-extender mode. In this mode, the interfaces of thesatellites are not expanded on the controller; they behave as separate physical interfaces. Youmodify andcommit configuration changes for satellite devices only on the controller and commit the configurations tothe satellites.

• 2. Port Extendermode—In this mode, a JNU group that consists of the controller and a number of satellitesis regarded as a single, unified network entity, with the controller owning all the interface resources, includingthose residing on the satellites (remote line-cards) as extended ports. A satellite interface functions as thesatellite port that is extended to the controller. In this mode, when an interface that resides on the satelliteis enabled within the JNU group, a service VLAN (S-VLAN) ID or tag is used to transmit the data traffic fromthe remote interface of the satellite to the controller.

NOTE: Port-extender mode is supported in JNU Release 1.3 and later. It is necessary to select the samemode—feature-rich or port-extender— on the controller and the satellites. The JNUmanagement planeconfigurations that are enabled in both themodes are identical. If you select a differentmode on the controllerfrom theoneon the satellites, the controllermight still communicatewith the satellites, but the JNUoperationsmay fail.

Enter 1 to enable feature-rich mode. Enter 2 to enable port-extender mode.

Please selecttheJNUmode

Hostname for the satellite.

We recommend planning the names of a JNU group so that it is easy to identifywhich satellites and controllers belong to a group.

Please enter hostname

Source address the satellite uses when it sends SNMP or system logmessagesto the controller. This address must match the satellite management IP addressthat you configured for the satellite during the controller initialization process.

Please enter management IP address

IP address of the satellite used in the JNUmanagement network for uplinkconnections to the controller.

Please enter uplink IP prefix(192.168.0.2-254/24)

IDof the interfaceused in the JNUmanagementnetwork for theuplinkconnectionto the controller.

Enter multiple interfaces in a comma-separated list. The JNU software placesmultiple interfaces into an aggregated Ethernet bundle.

Please enter uplink interface name

If you enter only a single uplink interface ID, you have the option of not usingaggregatedEthernet. If your satellitedevicedoesnot support aggregatedEthernet,enter n.

Do you want to use aggregated-ethernetfor the uplink

If you are using aggregated Ethernet, enter a name for the bundle.Please enter uplink aggregate name

VLAN ID used on themanagement network.Please entermanagementVLAN id [4094]

IPaddressof thecontroller usedon themanagementnetwork for communicationwith the satellite.

Please enter controller downlink IP address[192.168.0.1]



To initialize a satellite device:

1. Enter the following command on the satellite device, and follow the prompts.

user@jnu-satellite1> op url /var/db/scripts/op/jnu-initialize-satellite.slaxSatellite initializations: Please select the JNU mode: 1. Feature-rich mode The controller and satellite features are supported. Configurations are forwarded to the satellites when the target device is a satellite managed by this controller. 2. Port Extender mode Interfaces on the satellites are extended to the satellites. Features are configured on the extended ports.

JNU mode (1/2)? 2 Please enter hostname [jnu-satellite1]: jnu1-sat-ex1 Please enter management IP address: 10.0.0.1 Please enter uplink IP prefix (192.168.0.2-254/24): 192.168.0.2/24 Please enter uplink interface name: ge-0/0/0 Do you want to use aggregated-ethernet for the uplink [n]: y Please enter uplink aggregate name [ae31] 63 Please enter management VLAN id [4094]: Please enter controller downlink IP address [192.168.0.1]:

Sample Initial Configuration for an EX Series Switch

The following is an example of the configuration that is configured and committed on

the satellite device during the initialize process.

groups {jnu-satellite-mgmt {chassis {aggregated-devices {ethernet-devices {device-count 63;

}}

}system {syslog {/ * syslog parameters propagated from controller except source address */host 169.37.0.1 {security info;change-log info;source-address 10.0.0.1;


}}ntp {/ * Using controller mgmt IP address */server 192.168.0.1;

}services {ssh;



}}snmp {/ * Other snmp parameters propagated from controller */community public:jnu-satellite1 {read-only;

}/ * Other snmp parameters propagated from controller */community private:jnu-satellite1 {read-only;

}trap-options {source-address 10.0.0.1;

}trap-group public:jnu-satellite1 {version v2;/ * categories are configured by user, propagate from satellite */categories {authentication;routing;

}targets {169.37.0.1;

}}

}interfaces {ge-0/0/0 {/ * Using aggregate ethernet since there can bemore than 1 uplink */gigether-options {802.3ad ae63;

}}ae63 {/ * Aggregated ethernet interface uplink connection to controller */aggregated-ethernet-options {lacp {active;

}}unit 16385 {family ethernet-switching {port-mode trunk;vlan {members all;

}}

}}vlan {unit 4094 {family inet {address 192.168.0.2/24;

}}

}



}vlans {jnu {vlan-id 4094;l3-interface vlan.4094;

}}policy-options {policy-statement jnu-management {/ * Routes that are to be leaked from jnu-vrf to main instance */from {route-filter 169.37.0.1/32 exact;route-filter 132.0.1.1/32 exact;protocol static;

}then accept;

}policy-statement reject-all {then reject;

}}routing-options {/ * These configurations to leak routes from jnu-vrf to main instance */rib-groups jnu {import-rib [ jnu.inet.0 inet.0 ];import-policy jnu-management;

}}routing-instances {jnu-vrf {/ * Routing-instance containing uplink to controller */instance-type vrf;interface vlan.4094;route-distinguisher 192.168.0.2:1;vrf-import reject-all;vrf-export reject-all;routing-options {routing-options {static {rib-group jnu;route 169.37.0.1/32 next-hop 192.168.0.1;route 132.0.1.1/32 next-hop 192.168.0.1;

}}

}}

}}

}

Sample Initial Configuration on an ACXUniversal Access Router

The following is an example of the configuration that is configured and committed on

the satellite device during the initialization process.

groups {



jnu-satellite-mgmt {system {syslog {/* syslog parameters propagated from controller except source address */host 169.37.0.1 {security info;change-log info;source-address 10.0.0.1;


}}ntp {/* Using controller mgmt IP address */server 192.168.0.1;

}services {ssh;

}}snmp {/* Other snmp parameters propagated from controller */community public:jnu-satellite1 {read-only;

}/* Other snmp parameters propagated from controller */community private:jnu-satellite1 {read-only;


}trap-group public:jnu-satellite1 {version v2;/* categories are configured by user, propagate from satellite */categories {authentication;routing;

}targets {169.37.0.1;

}}

}interfaces {ge-0/0/0 {/* Not using AE interface on ACX */vlan-tagging;unit 16385 {vlan-id 4094;family inet {address 192.168.0.2/24;

}}

}



}policy-options {policy-statement jnu-management {/* Routes that are to be leaked from jnu-vrf tomain instance */from {route-filter 169.37.0.1/32 exact;route-filter 132.0.1.1/32 exact;protocol static;

}then accept;


}}routing-options {/* These configurations to leak routes fromjnu-vrf to main instance */rib-groups jnu {import-rib [ jnu.inet.0 inet.0 ];import-policy jnu-management;

}}routing-instances {jnu-vrf {/* Routing-instance containinguplink to controller */instance-type vrf;interface ge-0/0/0.16385;route-distinguisher 192.168.0.2:1;vrf-import reject-all;vrf-export reject-all;routing-options {routing-options {static {rib-group jnu;route 169.37.0.1/32 next-hop192.168.0.1;route 132.0.1.1/32 next-hop192.168.0.1;

}}

}}

}}

}

Sample Initial Configuration on an EX3300 Ethernet Switch

The following is an example of the configuration that is configured and committed an

EX3300 Ethernet Switch satellite device during the initialization process. There is no

routing instance configured, because the EX3300 switch does not support routing

instances.



groups {jnu-satellite-mgmt {chassis {aggregated-devices {ethernet {device-count 32;

}}

}system {host-name jnu-ex3300-1;login {/* For JNU scripts to use from controller */user jnuadmin {uid 2002;class super-user;authentication {encrypted-password "$1$PlNup5Bb1TDx/"; ## SECRET-DATA

}}

}syslog {/* syslog parameters propagated from controller except source address */host 169.37.0.1 {security info;change-log info;source-address 10.0.0.2;


}}ntp {/* NTP server is MX address */server 192.168.0.1;

}services {ssh;

}}snmp {/* Community string is propagated from controller and append with *//* of ":_hostname-of-satellite_", other parameters are propagated *//* from controller */community public:jnu-ex3300-1 {read-only;

}/* Community string is propagated from controller and append with *//* of ":_hostname-of-satellite_", other parameters are propagated *//* from controller */community private:jnu-ex3300-1 {read-write;


}



/* trap-group name is propagated from controller appended with *//* ":_satellite_host_name_" */trap-group public:jnu-ex3300-1 {version v2;targets {169.37.0.2;

}}

}security {ssh-known-hosts {/* Controller downlink IP address */host 192.168.0.1 {ecdsa-sha2-nistp256-key AAAAE2VjZHNhLXNoYTItbmlzdHAyNT;

}}

}interfaces {ge-0/0/0 {/* Using aggregate ethernet since there can bemore than 1 uplink */ether-options {802.3ad ae31;

}}ae31 {aggregated-ether-options {lacp {active;


}}


}}

}}vlans {jnu {vlan-id 4094;l3-interface vlan.4094;

}}routing-options {static {/* Static route for the Syslog server via controller */



route 169.37.0.1/32 next-hop 192.168.0.1;/* Static route for the SNMP trap server via controller */route 169.37.0.2/32 next-hop 192.168.0.1;

}}event-options {generate-event {event-script-timer time-interval 300;

}policy jnu-controller-connectivity {events event-script-timer;then {event-script monitor-controller-qfx3500.slax {arguments {cntrlr-ip 192.168.0.1;

}}

}}event-script {file monitor-controller-ex3300.slax;

}}

}}



• jnu-add-delete-satellites on page 60






CHAPTER 8

Configuring Junos OS Features with JNU

• Configuring Junos Features with JNU Configuration Templates on page 49

• Configuring Junos Features with JNU Free Form on page 51

Configuring Junos Features with JNU Configuration Templates

The JNU software comes with configuration templates that you can use to configure

JunosOS features. Each template contains parameters that correspond to a set of Junos

OS configuration statements. You configure these parameterswith the same values that

you would use for the corresponding set statement in configuration mode of the Junos

OSCLI.After youhave finishedconfiguring the templates, run theop jnu-commitcommand

to commit the new configuration on the specified satellite devices.

Displaying a List of Configuration Templates

To see a list of templates, enter op config-? In operational mode. For example:

user@jnu1-ctrlr> op config-?Possible completions:

<script> config-analyzer config-cos-classifiers config-cos-code-point-alias config-cos-congestion-notification-profile config-cos-drop-profiles

. . .

config-system-internet-options config-system-login config-system-syslog config-vlan config-vrrp config-vstp


Displaying the Configuration Parameters in a Template

You can display a list of parameters in a template. If there is a range of accepted values

or a particular value accepted for a parameter, these are included in parenthesis. To

display a list of parameters in a template, enter the name of the template with a ? . For

example:

user@jnu1-ctrlr> op config-cos-drop-profiles ?Possible completions:

action Action to be performed ('set', 'delete') apply-groups Groups from which to inherit configuration data apply-groups-except Don't inherit configuration data from these groups detail Display detailed output device Controller/Satellite Name drop-profile.name Random Early Drop (RED) data point map fill-level Fill-level value of data point (0 .. 100 percent) fill-level.drop-probability Probability packet will be dropped group Configuration group name interpolate.drop-probability Data points for packet drop probability (0 .. 100 percent) interpolate.fill-level Data points for queue full percentage (0 .. 100 percent)

| Pipe through a command

Configuring the Template

To configure a template:

• Include the device command, which specifies the satellite device on which you want

to commit the configuration. You can configure only one satellite device at a time using

the configuration templates.

• Include the action command, which specifies whether you are creating a configuration

or deleting a configuration.

• Add parameters and values on one line in any order. The software does not validate

values, but it notifies you if youmiss a required parameter.

For example, to create a droppolicy called best-effort on the jnu1-sat-ex1 satellite device:

user@jnu1-ctrlr> op config-cos-drop-profiles drop-profile.name best-effortinterpolate.fill-level 30 fill-level 50 fill-level.drop-probability 0interpolate.drop-probability 80 device jnu1-sat-ex1 action set

Committing the Configuration

After you have finished configuring the templates, run the jnu-commit command to

commit the new configuration on the specified satellite devices.


config-template-name on page 59•





Configuring Junos Features with JNU Free Form

You can use the config-free-form command to configure Junos OS set statements on

satellite devices. You can configure any set statement that is supported on the satellite

device.

To use the config-free-form command to configure Junos OS set statements:

• Include the action command, which specifies whether you are adding a statement or

deleting a statement.

• Include the device command, which specifies one or more satellite devices on which

you want to commit the configuration. Enter multiple satellite devices in a

comma-separated list.

• Add statements and values on one line in any order. The software does not validate

values, but it notifies you if youmiss a required parameter.

For example, to configure an interface:

user@jnu1-ctrlr> op config-free-form action add device jnu1-sat-ex1 command "setinterfaces ge-1/0/0 unit 0 vlan-id 1044 family inet address 10.10.1.1"

To configure routing options:

user@jnu1-ctrlr> op config-free-form action add device jnu1-sat-ex1 command "setrouting-options static route 172.16.0.0 next-hop 192.168.167.254 retain no-readvertise"


• config-free-form on page 58




Chapter 8: Configuring Junos OS Features with JNU



CHAPTER 9

Committing Configurations

• Commit Process for Satellites Already Connected to the Controller on page 53

• Commit Process for Satellite Devices That Come Online After the Commit Process on

the Controller on page 54

• Returning to a Previously Committed Junos OS Configuration on page 55

Commit Process for Satellites Already Connected to the Controller

JNU uses commit scripts to automate the commit process on the controller and satellite

devices. You commit configurations for the satellite devices from the controller. You

should modify and commit configuration changes for satellite devices only on the

controller.

When you commit a configuration on the controller, the flow of the commit process on

the controller is as follows:

1. Enter the following command on the controller:

user@jnu-ctrlr> op jnu-commit

2. The controller polls each satellite device to verify that the device is reachable.

3. The controller sends the new satellite configuration to each satellite device by using

the NETCONF XMLmanagement protocol.

4. Thecontroller runs the remoteprocedure call (RPC) validateprocessoneach satellite

device to validate the new configuration.

5. If all the satellite devices successfully validate the new configuration, the controller

runs the commit script, which runs the RPC commit process on all satellite devices.

When the process is complete, the controller displays the following message:

jnu1-sat-ex1:Configuration check succeedsjnu1-sat-qfx2:Configuration check succeeds

If the new configuration is not successfully validated on all satellite devices in the JNU

network, the commit process stops and the controller displays an error message.



Commit Process for Satellite Devices That Come Online After the Commit Process on


•


Commit Process for Satellite Devices That ComeOnline After the Commit Process onthe Controller

If a satellite device is not connected to the controller when you perform the commit

process, it receives its configuration from the controller when it comes online.

The commit process for satellite devices that come online after the commit process is

complete is as follows:

1. The satellite device comes online, and the satellite and the controller discover each

other.

2. Amanagement connection is made between the controller and the satellite device

by means of Junos OS automation features.

3. If the controller has a new configuration for the satellite device, the controller sends

the new configuration to the satellite device.

4. The satellite device validates the configuration, and if the validation succeeds, the

configuration is committed on the satellite.

The configuration on the satellite is now synchronized with the rest of the JNU group.

If the commit process fails or if the controller does not have a new configuration for the

satellite device, the controller removesany servicespreviously committedon the satellite

device because the configuration will not be synchronized the rest of the JNU group. The

controller restores the configuration that the satellite device had in discovery mode.

Because the satellite device has an openmanagement channel to the controller, it will

participate in subsequent configuration commits that the controller sends.


jnu-commit on page 61•





Returning to a Previously Committed Junos OS Configuration

To return to a configuration prior to the most recently committed one:

1. (Optional) In configurationmodeon the JNUcontroller, displaypreviousconfigurations,

including the configuration number, date, and time, the name of the user who

committed changes; and themethod of commit.

user@jnu-ctrlr1# rollback ?

<[Enter]> Execute this command 0 2012-10-01 07:55:02 PDT by jnuadmin via cli 1 2012-10-01 07:50:22 PDT by jnuadmin via cli 2 2012-10-01 07:48:00 PDT by jnuadmin via cli 3 2012-10-01 06:57:15 PDT by jnuadmin via junoscript 4 2012-10-01 05:23:55 PDT by jnuadmin via cli ... 48 2012-09-28 04:23:15 PDT by jnuadmin via cli 49 2012-09-27 06:51:52 PDT by jnuadmin via junoscript

2. Specify the configuration number, 0 through 49, to which you want to return. The

most recently saved configuration is number 0 (which is the default configuration to

which the system returns), and the oldest saved configuration is number 49.

user@jnu1-ctrlr> op jnu-rollback 0

In this example, configuration 0 is now the candidate configuration.

3. In operational mode on the JNU controller, commit the new candidate configuration.

user@jnu1-ctrlr> op jnu-commit


• jnu-rollback on page 75


Chapter 9: Committing Configurations



CHAPTER 10

JNU Operational Mode Commands

• Using Operational Mode Commands with JNU Overview on page 57

Using Operational Mode Commandswith JNUOverview

Operational mode commands used with JNU are at the user@host> prompt under the

op command. You run operational mode commands on the JNU controller.

There are two types of op commands for JNU.

• Commands that begin with jnu- are directly related to operating the JNU or to sending

Junos OS operational mode commands to satellite devices.

• Commands that begin with config- are related to configuring Junos OS features on

satellite devices.

• Theconfig-free-formcommandallowsyou tosend setcommands tosatellitedevices.

• All other commands that begin with config- are configuration templates that you

configure and send to satellite devices.


op on page 81•




config-free-form

Syntax opconfig-free-formdevice device-nameaction (add | delete)“set statement-name value”

Release Information Command introduced in JNU 1.0.

Description Configure Junos OS set statements on the satellite device. You can use config-free-form

to configure any set statement that is supported on the satellite device. You can enter

the statements in any order on the same line.

Options devicedevice-name—Satellite device towhich youwant to add or remove the statement.

action (add | delete)—Action to be taken on the set statements. You can add the

statement to the configuration of the satellite device or remove the set statement

from the configuration of the satellite device.

“setstatement-namevalue”—A set statementandvalue thatare supportedon thesatellite

device. Youmust enclose the set statement and values in quotationmarks. You can

enter multiple set statements on the same line. The JNU software does not validate

the value that you enter for the statement. The value is validated during the commit

process.


Configuring Junos Features with JNU Free Form on page 51•



config-template-name

Syntax opconfig-template-namedevice device-nameaction (set | delete)parameter parameter-value


Description Configure Junos OS features using templates. Each template contains parameters that

correspond to a set of Junos OS configuration statements. To see a list of templates,

enter op config-? in operational mode.

Options template-name—Name of the configuration template that you wish to configure.

device device-name—Device to which you want to add or remove the statement.

action (set | delete)—Action to be taken on the set statements. You can add the set

statement to the configuration of the satellite device or remove the set statement

from the configuration of the satellite device.

parameter parameter-value—Parameters and values that you configure in the template.

Parameters correspond to Junos OS configuration statements. To display a list of

parameters in a template, enter op config-template-name ?. For example, opconfig-interface ?.


Configuring Junos Features with JNU Configuration Templates on page 49•


Chapter 10: JNU Operational Mode Commands

jnu-add-delete-satellites

Syntax opjnu-add-delete-satellitesaction set | deleteae-id id-valuedownlink interface-idieee-802.3ad disableinet ip-addresssat-mgmt-ip ip-addresssatellite satellite-name


Description Create and configure satellite devices in the controller configuration or remove satellite

devices from the configuration.

Options actionset |delete—Use set tocreateandconfigureasatellitedevice.Usedelete to remove

a satellite device configuration.

ae-id id-value—ID of the aggregated Ethernet interface in the range 0–479.

downlink interface-id—IDof the interfaceused for thedownlink connection to the satellite

device.

802.3ad disable—Disable the use of an aggregated ethernet interface to bundle the

downlink interfaces to the satellite.

inet ip-address—IPaddress that the JNUcontroller uses tocommunicatewith thesatellite

device.

sat-mgmt-ip ip-address—IP address that the satellite uses to send syslog and SNMP

messages.

satellite satellite-name—Name of the satellite device to be added or deleted.


Using Operational Mode Commands with JNU Overview on page 57•



jnu-commit

Syntax opjnu-commit


Description Commit the configuration on the controller and on the satellite devices.


Commit Process for Satellites Already Connected to the Controller on page 53•

• Commit Process for Satellite Devices That Come Online After the Commit Process on





jnu-initialize-controller

Syntax opjnu-initialize-controller


Description The first time you initialize JNU on the controller, you must run the op url

/var/db/scripts/op/jnu-initialize-controller operational mode command. Thereafter, to

change the JNUconfiguration on the controller, you can run the op jnu-initialize-controller

command.


Initializing JNUMode on the Controller on page 30•


Output Fields Table 3 on page 62 describes the fields that you fill in when you run the op

jnu-initialize-controller command.

Table 3: jnu-initialize-controller Output Fields

DescriptionField

JNUmode in which the controller device in a JNU groupmust function. Two JNUmodes available are:

• 1. Feature-richmode—Thismode is also called non-port-extendermode. In thismode, the interfaces of the satellites are not expanded on the controller; theybehave as separate physical interfaces. Youmodify and commit configurationchanges for satellitedevicesonlyon thecontroller andcommit theconfigurationsto the satellites.

• 2.PortExtendermode—In thismode, a JNUgroup that consists of the controllerand a number of satellites is regarded as a single, unified network entity, withthe controller owning all the interface resources, including those residing on thesatellites (remote line-cards) as extended ports. A satellite interface functionsas the satellite port that is extended to the controller. In this mode, when aninterface that resides on the satellite is enabled within the JNU group, a serviceVLAN (S-VLAN) ID or tag is used to transmit the data traffic from the remoteinterface of the satellite to the controller.

NOTE: Port-extendermode is supported in JNURelease 1.3 and later. It is necessaryto select the samemode—feature-rich or port-extender— on the controller andthe satellites. The JNUmanagement plane configurations that are enabled in boththe modes are identical. If you select a different mode on the controller from theone on the satellites, the controller might still communicate with the satellites,but the JNU operations may fail.

Enter 1 to enable feature-rich mode. Enter 2 to enable port-extender mode.

Please select the JNUmode

Hostname for the controller.Please enter hostname



Table 3: jnu-initialize-controller Output Fields (continued)

DescriptionField

Source address used when the controller sends SNMPmessages or system logsto a network management system (NMS).

When the controller receives SNMPmessages or system logs from the satellites,it usesNAT toconvert the satellitemanagementaddress to this address. Therefore,all network management traffic in the JNU group uses the same source address.

In addition, the controller uses this address as the source address when it sendsits own network management traffic to the NMS.

Please enter management IP address

IP address of the controller used in the JNUmanagement network for downlinkconnections to satellite devices.

Please enter JNU downlink prefix[192.168.0.1/24]

VLAN ID used on themanagement network.Please enter JNU VLAN id [4094]

Enter y to add satellite devices to the configuration.Do you want to configure any satellitesnow

Number of satellite devices that you want to add to the configuration.Please enter the number of satellites

Name for the satellite.Please enter the hostname of the satellite

IP address for the satellite used as the source address for SNMP or system logmessages. This address must match the satellite management IP address thatyou configured for the satellite in the satellite initialization process.

Please enter satellite management IPaddress

IP address of the satellite used in the JNUmanagement network for the uplinkconnection to the controller.

Please enter the uplink IP address of thesatellite

ID of Interface used in the JNUmanagement network for the downlink connectionto the satellite.

Enter multiple interfaces in a comma-separated list. The JNU software placesmultiple interfaces into an aggregated Ethernet bundle.

Please enter downlink interfaces tosatellite

If you enter only a single downlink interface ID, you have the option of not usingaggregatedEthernet. If your satellite devicedoesnot support aggregatedEthernet,enter n.

Do you want to use aggregated-ethernetfor the downlink [y]

If you are using aggregated Ethernet, enter a name for the bundle.Please enter downlink aggregate name[ae31] 63

Enter y to configure SNMP on the controller.Do you want to configure SNMP [n]

Enter y to configure a read-only community string for the controller, and then enterthe community string.

Repeat this process to enter a second community string.

Do you want to enter a read-onlycommunity string (y | n)




DescriptionField

Enter y to configure a read-write community string for the controller, and thenenter the community string.

Repeat this process to enter a second community string.

Do you want to enter a read-writecommunity string (y|n)?

Enter y to configure SNMP traps.Do you want to enter SNMP trapparameters (y | n)?

If you entered y to configure SNMP traps, specify the address to which traps aresent.

SNMP trap target address:

Enter y to specify trap categories.Do you want to enter SNMP trapcategories (y | n)?

Enter y to specify Optical Transport Network (OTN) alarm categories.

A list of available alarms displays.

Enter alarms in a comma-separated list.

Do you want to enable SNMP trap for'otn-alarms' (y | n)?

Enter y to specify SONET/SDH alarm categories.

A list of available alarms displays.

Enter alarms in a comma-separated list.

Do you want to enable SNMP trap for'sonet-alarms' (y | n)?

A list of additional trap categories that you can add to the trap configurationdisplays.

Other categories:

Enter y to add other trap categories to your configuration.Do you want to enter other SNMP trapcategories (y | n)?

Comma-separated list of additional trap categories that you want to add to yourconfiguration.

Please enter SNMP trap categories:

Enter y to configure a server to which system logmessages are sent.Doyouwant toconfigureSyslog server [n]:

IP address of the system log server.Syslog host address?

Port number of the system log server.port number [123]:

Class of messages to log. Enter y to enable all facilities; enter n to display a list offacilities that you can add to the configuration.

Sylog facility 'all' [n]:

List of facilities that you can add to the configuration.Syslog facilities:

List of message severities.Syslog severities:

Name of the facilitiy that you want to add to the configuration.Please enter syslog facility name:




DescriptionField

Specify the severity of the messages that belong to the facility. Messages withseverities of the specified level and higher are logged.

Please enter severity:

Enter y to configure additional facilities.Do youwant to entermore syslog facilities[n]?

Enter y to configure an NTP server.Do you want to configure NTP [n]:

IP address of the NTP server.NTP server address:



Sample Output

user@jnu1-ctrlr> op jnu-initialize-controllerController initializations:Please enter hostname [jnu-controller]:Please enter management IP address: 137.34.1.1Please enter JNU downlink IP prefix [192.168.0.1/24]:Please enter JNU VLAN id [4094]: Do you want to configure any satellites now [n]: y

Please enter the number of satellites [1]: 2 Satellite 1 Please enter the hostname of the satellite: jnu-sat1 Please enter satellite management IP address: 10.0.0.1 Please enter the uplink IP address of the satellite: 192.168.0.2 Please enter downlink interfaces to satellite: ge-0/0/0 Do you want to use aggregated-ethernet for the downlink [y]: y Please enter downlink aggregate name [ae31]: Satellite 2 Please enter the hostname of the satellite: jnu-sat2 Please enter satellite management IP address: 10.0.0.2 Please enter the uplink IP address of the satellite: 192.168.0.3 Please enter downlink interfaces for satellite: ge-0/0/1,ge-0/0/2Do you want to configure SNMP [n]: y Do you want to enter a read-only community string (y|n)? y SNMP read-only community string: public Do you want to enter a read-write community string (y|n)? y SNMP read-only community string: private Do you want to enter SNMP trap parameters (y|n)? y SNMP trap target address: 169.37.0.1 Do you want to enter SNMP trap categories (y|n)? y Do you want to enable SNMP trap for 'otn-alarms' (y|n)? y Available alarms: 'oc-lof', 'oc-lom', 'oc-los', 'odu-ais', 'odu-bbe-threshold', 'odu-bdi', 'odu-es-threshold', 'odu-lck', 'odu-oci', 'odu-rx-aps-change', 'odu-sd', 'odu-ses-threshold', 'odu-sf', 'odu-ttim', 'odu-uas-threshold', 'opu-ptm', 'otu-ais', 'otu-bbe-threshold', 'otu-bdi', 'otu-es-threshold', 'otu-fec-deg', 'otu-fec-exe', 'otu-iae', 'otu-sd', 'otu-ses-threshold', 'otu-sf', 'otu-ttim', 'otu-usa-threshold', 'wavelength-lock' Please enter otn-alarms: oc-lof,oc-lom Do you want to enable SNMP trap for 'sonet-alarms' (y|n)? y Available alarms: 'ber-defect', 'ber-fault', 'line-ais', 'line-remote-defect-indication', 'loss-of-cell', 'loss-of-frame', 'loss-of-light', 'loss-of-pointer', 'loss-of-signal', 'path-ais', 'path-mismatch', 'path-remote-defect-indication', 'pll-lock', 'remote-error-indication', 'severely-errored-frame', 'unequipped', 'vt-ais', vt-label-mismatch', 'vt-loss-of-cell', 'vt-loss-of-pointer', 'vt-remote-defect-indication', 'vt-unequipped' Please enter sonet-alarms: path-ais Other categories: 'authentication', 'chassis', 'configuration', 'link', 'remote-operations', 'rmon-alarm', 'routing', 'services', 'startup', 'vrrp-events' Do you want to enter other SNMP trap categories (y|n)? y Please enter SNMP trap categories: vrrp-events Do you want to configure Syslog server [n]: ySyslog host address? 167.37.0.1



port number [123]: Sylog facility 'all' [n]: Syslog facilities: 'authorization', 'change-log', 'conflict-log', 'daemon', 'dfc', 'explicit-priority', 'external', 'firewall', 'ftp', 'interactive-commands', 'kernel', 'log-prefix', 'ntp', 'pfe', 'security', 'user' Syslog severities: 'alert', 'any', 'criticial', 'emergency', 'error', 'info', 'none', 'notice', 'warning' Please enter syslog facility name: change-log Please enter severity: warning Do you want to enter more syslog facilities [n]? Do you want to configure NTP [n]: y NTP server address: 168.37.0.1




jnu-order-satellites

Syntax opjnu-order-satellitesinsert device-name-1 (before | after ) device-name-2)


Description Change the order in which the software displays satellite devices when you run show

commands. If you have a large number of satellites, youmay want to organize them by

platform or by other sort criteria.

Options device-name-1—Name of the satellite device to be inserted.

before—(Optional) Insert device-name-1 before device-name-2.

after—(Optional) Insert device-name-1 after device-name-2.

device-name-2—Name of the satellite device before or after which device-name-1 is

inserted.





jnu-port-extender-command

Syntax opjnu-port-extender-command


Description Run operational mode commands related to a satellite interface that is extended to a

controller in port-extender mode.

When you configure the port-extender interface format as

satellite-name:physical-interface-name.vlan-id, the interface is reported using this format

instead of the actual interface namewhen you issue the jnu-port-extender-command

command. For example, the name of the satellite interface that is extended such as

jnu-sat1:ge-0/0/0 indisplayed insteadof theanchoring logical interface for the extended

interface, namely ae479.101.

In addition, the jnu-port-extender-command command differentiates whether the

command that you enter along with it to be run on the extended satellite interface is a

Layer 2 or Layer 3 command configuration. This distinction is performed by processing

thesecondkeywordspecified in thecommand field.The followingare the fields validated

by the systemwhen you enter the jnu-port-extender-command command:

Controller features Satellite only features System features

accounting vlans systemas-path analyzer poebfd captive-portal snmpbgp diagnosticsbridge dot1xconnections ethernet-switchingdhcp oamdhcpv6diameterdvmrpdynamic-tunnelsesisforwarding-optionshelperhfrriccpigmpikeilmiingress-replicationinterfacesipsecipv6isisl2circuitl2cpdl2vpnlacpldplink-managementmobile-ipmpls



msdpmulticastmvpnmvrpnetwork-accessntpospfospf3pfepgmpimppppppoeprotection-groupptpripripngroutersvpsapsecuritystatic-subscriberssubscriberstasktedvalidationvplsvrrp

For Layer 3 features, the jnu-port-extender-command command issues the command

on thecontroller because the feature runson theanchor interfaceon thecontroller.When

the system retrieves the results, it replaces the anchor interface names in the output,

ae479.101, with the port-extender interface name, jnu-sat1:ge-0/0/0.1000. For Layer 3

features, the interface-name formatmustbe satellite-name:physical-interface-name.vlan-id

because this format corresponds to the logical interface on the controller that anchors

the extended port.

For Layer2 features, the jnu-port-extender-commandcommandexamines theparameters

specified in the command to determine whether an interface name is specified. If an

interface name is found, the system extracts the satellite name and the interface name

from the command and runs the command on the satellite using the actual interface

name. For Layer 2 features, the interface-name format must be

satellite-name:physical-interface-namewithout the .vlan-id string because this format

corresponds to the physical interface on the satellite.

Forsystemfeatures, the jnu-port-extender-commandcommandmightcontain theoptional

device parameter. If the device parameter is not specified, the command is run on the

controller. If the device parameter is specified, the command is run on the specified

satellite. For example, if you include the show ethernet-switching interface

jnu-sat1:ge-0/0/10 command with the jnu-port-extender-command, the command is

forwarded from the controller and is run on the satellite, jnu-sat1, in the form of show

ethernet-switching interface ge-0/0/10 . The output, in the CLI-rendered text format, is

displayed in the controller CLI.



If an interface name is not specified in the command for a Layer 2 feature, the command

is run on all the satellites. Substitutions of port-extender interface names with anchor

interface names on the controller are not performed in the command output. The show

interfaces command is considered as a Layer 3 command because after the satellite

ports are extended to the controller, the command displays information about the

extended ports. Therefore, the interface-name format is

satellite:physical-interface-name.vlan-id.


Extending a Satellite Interface to a Controller Overview on page 95•

• Initializing the JNUPort-ExtenderMode on Controller and Satellite Devices on page 97

• Configuring the Port Extender on the Controller on page 100

• Monitoring the Extended Satellite Interfaces Anchored on the Controller on page 99

• Processing of Configuration Templates in JNU Port-Extender Mode on page 117

• Processing of Free Form Settings in JNU Port-Extender Mode on page 122

• jnu-show-port-extender on page 72



jnu-show-port-extender

Syntax opjnu-show-port-extender


Description Display the mapping between a satellite interface that is extended to a controller and

the logical interfaceon thecontroller thathostsoranchors theextendedsatellite interface.

Required PrivilegeLevel

view








Output Fields Table 4 on page 72 lists the output fields for the jnu-show-port-extender command.

Output fields are listed in the approximate order in which they appear.

Table 4: jnu-show-port-extender Output Fields

Level of OutputField DescriptionField Name

noneName of the interface that is extended from the satellite to the controller inthe uplink connection to the controller

Port ExtenderInterface

noneNameof the logical interfaceon thecontroller thathostsor anchors the satelliteinterface that is extended to the controller

Controller IFL

noneService VLAN tag of the VLAN on the extended satellite interface that isautomatically assigned by the controller to satellites in a JNU group

S-VLAN

noneCustomer VLAN tag of theVLANconfigured on the extended satellite interfaceC-VLAN

jnu-show-port-extender

user@jnu1-ctrlr> jnu-show-port-extenderPort Extender Interface Controller IFL S-VLAN C-VLANjnu-sat1:ge-0/0/0.1001 ae479.101 101 1001jnu-sat1:ge-0/0/0.1002 ae479.102 101 1002jnu-sat1:ge-0/0/1.333 ae479.103 102 333jnu-sat2:ae0.1001 ae478.101 103 1002



jnu-remote

Syntax opjnu-remotecommand “operational-mode-command”device device-name


Description Forward the specified Junos OS operational mode command to the satellite device, and

display the results on the controller.

Options command“operational-mode-command”—Nameof theoperationalmodecommandthat

you want to send to the satellite device.

devicedevice-name—Nameof thesatellitedevice towhichyouwant tosent thecommand.

Enter multiple satellite devices in a comma-separated list.





Sample Output

jnu-remote The following example runs the show chassis hardware command on satellite devices

jnu-sat-ex1 and jnu1-sat-qfx2.

user@jnu1-ctrlr> op jnu-remote device jnu-sat-ex1,jnu1-sat-qfx2 command "show chassishardware"Device: jnu-sat-ex1----------------------------------

Hardware inventory:Item Version Part number Serial number DescriptionChassis BM0211313979 EX4200-24TRouting Engine 0 REV 13 750-033065 BM0211313979 EX4200-24T, 8 POEFPC 0 REV 13 750-033065 BM0211313979 EX4200-24T, 8 POE CPU BUILTIN BUILTIN FPC CPU PIC 0 BUILTIN BUILTIN 24x 10/100/1000 Base-T PIC 1 REV 05 711-026017 CH0211328603 2x 10GE SFP+ Xcvr 0 REV 01 740-030658 AD0951A01GC SFP+-10G-USRPower Supply 0 REV 05 740-020957 AT0511253210 PS 320W ACFan Tray Fan TrayDevice: jnu1-sat-qfx2----------------------------------

Hardware inventory:Item Version Part number Serial number DescriptionChassis P1959 QFX3500Routing Engine 0 BUILTIN BUILTIN QFX Routing EngineFPC 0 REV 15 750-036931 P1959-C QFX 48x10G 4x40G Switch

CPU BUILTIN BUILTIN FPC CPU PIC 0 BUILTIN BUILTIN 48x 10G-SFP+ Xcvr 1 REV 01 740-021308 ZT521101981 SFP+-10G-SR Xcvr 10 REV 01 740-013111 9057111 SFP-T PIC 1 BUILTIN BUILTIN 15x 10G-SFP+ MGMT BRD REV 09 750-036946 BBAR8776 QFX3500-MBPower Supply 0 Rev 04 740-032091 VE07482 QFX PS 650W ACPower Supply 1 Rev 04 740-032091 VE06647 QFX PS 650W ACFan Tray 0 QFX Fan TrayFan Tray 1 QFX Fan TrayFan Tray 2 QFX Fan Tray



jnu-rollback

Syntax opjnu-rollbacknumber <number>


Description Return toapreviously committedconfiguration.Thesoftwaresaves the last50committed

configurations. After running the op jnu-rollback command, you need to run the op

jun-commit command to activate the candidate configuration.

Options number number—(Optional) Configuration to return to. The range of values is from 0

through49. Themost recently saved configuration is number0, and theoldest saved

configuration is number 49. The default is 0.


Returning to a Previously Committed Junos OS Configuration on page 55•



jnu-show-satellites

Syntax opjnu-show-satellites<detail>


Description Display the state of each satellite to determine if the satellite is up and connected to the

controller. You can also use this command to test and run the op script on the satellite

devices.

Options detail—(Optional) Tests and runs the op script on the satellite devices.


view

Output Fields Table 5 on page 76 lists the output fields for the jnu-show-satellites command. Output

fields are listed in the approximate order in which they appear.

Table 5: jnu-show-satellites Output Fields

Level of OutputField DescriptionField Name

level-of-output noneName of the satellite deviceSatellite System

level-of-output noneStatus of the satellite device.

• Up—Satellite device is up and connected to the controller.

• Down—Satellite device is not connected to the controller.

State



jnu-show-satellites

user@jnu1-ctrlr> jnu-show-satellitesSatellite-System Statejnu1-sat-ex1 Up jnu1-sat-qfx2 Up

jnu-show-satellites detail

user@jnu1-ctrlr> jnu-show-satellites detail2012-07-15 23:10:30 OMST: reading op script input details2012-07-15 23:10:30 OMST: testing op details2012-07-15 23:10:30 OMST: running op script 'jnu-show-satellites.slax'2012-07-15 23:10:30 OMST: opening op script '/var/db/scripts/op/jnu-show-satellites.slax'2012-07-15 23:10:30 OMST: reading op script 'jnu-show-satellites.slax'Satellite-System Statejnu1-sat-ex1 Up jnu1-sat-qfx2 Up 2012-07-15 23:10:35 OMST: inspecting op output 'jnu-show-satellites.slax'2012-07-15 23:10:35 OMST: finished op script 'jnu-show-satellites.slax'



jnu-show-configuration

Syntax opjnu-show-configurationdevice device-namesource candidate | committed<detail><display commit-script>


Description Display the configuration of the satellite.

Options device device-name—Name of the satellite device for which you want to display the

configuration.

source candidate | committed—Source of the configuration to be displayed, either the

candidate configuration or the committed configuration.

detail—(Optional) Display the specified level of output.

display commit-script—(Optional) Displays the commit script for the satellite


view


Running the Satellite Initialization Process on page 38•

Sample Output

jnu-show-configuration user@jnu1-ctrlr> op jnu-show-configuration device jnu1-sat-ex1 source committedDevice: jnu1-sat-ex1----------------------------------

## Last commit: 2012-07-13 18:25:06 PDT by jnuadminversion 11.4R4;

groups {jnu-satellite-mgmt {system {syslog {/* syslog parameters propagated from controller except source address */host 169.37.0.1 {security info;change-log info;source-address 10.0.0.1;


}}ntp {/* Using controller mgmt IP address */



server 192.168.0.1;}services {ssh;

}}snmp {/* Other snmp parameters propagated from controller */community public:jnu-satellite1 {read-only;

}/* Other snmp parameters propagated from controller */community private:jnu-satellite1 {read-only;


}trap-group public:jnu-satellite1 {version v2;/* categories are configured by user, propagate from satellite */categories {authentication;routing;

}targets {169.37.0.1;

}}

}interfaces {ge-0/0/0 {/* Not using AE interface on ACX */vlan-tagging;unit 16385 {vlan-id 4094;family inet {address 192.168.0.2/24;

}}

}}policy-options {policy-statement jnu-management {/* Routes that are to be leaked from jnu-vrf tomain instance */from {route-filter 169.37.0.1/32 exact;route-filter 132.0.1.1/32 exact;protocol static;

}then accept;


}



}routing-options {/* These configurations to leak routes fromjnu-vrf to main instance */rib-groups jnu {import-rib [ jnu.inet.0 inet.0 ];import-policy jnu-management;

}}routing-instances {jnu-vrf {/* Routing-instance containinguplink to controller */instance-type vrf;interface ge-0/0/0.16385;route-distinguisher 192.168.0.2:1;vrf-import reject-all;vrf-export reject-all;routing-options {routing-options {static {rib-group jnu;route 169.37.0.1/32 next-hop192.168.0.1;route 132.0.1.1/32 next-hop192.168.0.1;

}}

}}

}}

}



op

Syntax opconfig-free-formdevice device-nameaction (add | delete)“set statement-name value”

config-free-form-precommitconfig-template-namedevice device-nameaction (set | delete)parameter-name parameter-value

jnu-add-delete-satellitesaction set | deleteae-id id-valuedownlink interface-idieee-802.3ad disableinet ip-addresssat-mgmt-ip ip-addresssatellite satellite-name

jnu-commitjnu-initialize-controllerjnu-order-satellitesinsert device-name-1 (before | after ) device-name-2)

jnu-remotecommand “operational-mode-command”device device-name

jnu-rollbacknumber <number>

jnu-show-satellites<detail>

jnu-show-configurationdevice device-namesource candidate | committed<detail><display commit-script>

<script><url url>

Description Run operational commands on the controller.

Options config-free-form-precommit—Donot run thiscommand. It isan internal systemcommand.

script—(Optional) Runs the specified op script in the /var/db/scripts/op directory.

url url—(Optional) Runs the op script specified in the URL.

The remaining commands are described separately.


• Using Operational Mode Commands with JNU Overview on page 57





CHAPTER 11

Setting Up a Basic JNU Implementation


Example: Setting Up a Basic JNU Implementation

This example shows how to set up a basic JNU implementation.

• Requirements on page 83

• Overview on page 84

• Configuration on page 85

• Verification on page 93

Requirements

This example uses the following hardware and software components:

• OneMX Series router that acts as the controller

• One EX4200 switch that acts as a satellite device

• One QFX3500 device that acts as a satellite device

• Junos OS Release 11.4R4-S1 or later

• JNU 1.0 or later


Overview

Topology

Figure 6: Basic JNU Configuration

g041

391

MX Series controllerjnu1-ctrl

192.168.0.1/24

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

ge-0/1/0

192.168.0.2/24

EX4200 SatelliteJnu-sat-ex1

QFX3500 SatelliteJnu1-sat-qfx2

ge-0/0/1

192.168.0.3/24

Table 6 on page 84 describes the configuration components used in this example.

Table 6: Configuration Components Used in the Basic JNU Configuration

PurposeComponent NameConfigurationComponent

Hostname of the controllerjnu1-ctrlrMX Seriescontroller

Controller management address used for communication withsatellites

192.168.0.1/24

Downlink interface to jnu1-sat-ex1 satellitexe-0/0/0

Downlink interface to jnu1-sat-qfx2 satellitexe-0/1/1

Hostname of the satellitejnu1-sat-ex1EX4200 satellite

Satellite management address used for communication with thecontroller

192.168.0.2/24

Uplink interface to the controllerxe-0/1/0



Table 6: Configuration Components Used in the Basic JNU Configuration (continued)

PurposeComponent NameConfigurationComponent

Hostname of the satellitejnu1-sat-qfx2QFX3500 satellite

Satellite management address used for communication with thecontroller

192.168.0.3/24

Uplink interface to the controllerxe-0/0/1

NOTE: Beforeyoubegin, youmustsetup IPaddresseson thesatellitedevicesthat are used for the connection to the controller.

Configuration

• Load the JNU Software on page 86

• Initialize the Controller on page 86

• Initialize the EX4200 Satellite on page 88

• Initialize the QFX3500 Satellite on page 91

• Commit the Configuration on page 93


Chapter 11: Setting Up a Basic JNU Implementation

Load the JNU Software

Step-by-StepProcedure

To load the JNU package onto the controller:

1. Enter the followingcommandon theMXSeriescontroller. Startingwith JNURelease

1.3, you can also configure an EX9000 Ethernet Switch as a controller.

user@jnu1-ctrlr> request system software add jnu-1.2R1.0-signed.tgzInstalling package '/var/tmp/jnu-1.2R1-signed.tgz' ...Verified jnu-1.0R1.tgz signed by PackageProduction_11_4_0 Adding jnu...Available space: 556676 require: 3220NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-installMounted jnu package on /dev/md10...Restarting bslockd ...mgd: commit completeSaving package file in /var/sw/pkg/jnu-1.2R1-signed.tgz ...Saving state for rollback ...


To load the JNU package onto the satellite device:

1. Enter the following command on the satellite device.

user@jnu-satellite1> request system software add jnu-1.2R1.0-signed.tgzInstalling package '/var/tmp/jnu-1.2R1-signed.tgz' ...Verified jnu-1.0R1.tgz signed by PackageProduction_11_4_0 Adding jnu...Available space: 556676 require: 3220NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-installMounted jnu package on /dev/md10...Restarting bslockd ...mgd: commit completeSaving package file in /var/sw/pkg/jnu-1.2R1-signed.tgz ...Saving state for rollback ...

Initialize the Controller


After you install the JNU software, you need to initially configure and initialize the MX

Series controller. This example configures the controller, adds two satellite devices to

the controller configuration, and configures SNMP system logging and NTP on the

controller.

To initially configure the controller:



1. Enter the followingcommandand follow theprompts. For adescriptionof the fields

used to initialize the controller, see jnu-initialize-controller.

user@jnu1-ctrlr> op url /var/db/scripts/op/jnu-initialize-controller.slaxController initializations: Please enter hostname [jnu-controller]: Please enter management IP address: 137.34.1.1 Please enter JNU downlink IP prefix [192.168.0.1/24]: Please enter JNU VLAN id [4094]: Do you want to configure any satellites now [n]: y Please enter the number of satellites [1]: 2 Satellite 1 Please enter the hostname of the satellite: jnu-sat1 Please enter satellite management IP address: 10.0.0.1 Please enter the uplink IP address of the satellite: 192.168.0.2 Please enter downlink interfaces to satellite: ge-0/0/0 Do you want to use aggregated-ethernet for the downlink [y]: y Please enter downlink aggregate name [ae31]: Satellite 2 Please enter the hostname of the satellite: jnu-sat2 Please enter satellite management IP address: 10.0.0.2 Please enter the uplink IP address of the satellite: 192.168.0.3 Please enter downlink interfaces for satellite: ge-0/0/1 Do you want to use aggregated-ethernet for the downlink [y]: y Please enter downlink aggregate name [ae31]: Do you want to configure SNMP [n]: y Do you want to enter a read-only community string (y|n)? y SNMP read-only community string: public Do you want to enter a read-only community string (y|n)? y SNMP read-only community string: private Do you want to enter SNMP trap parameters (y|n)? y SNMP trap target address: 169.37.0.1 Do you want to enter SNMP trap categories (y|n)? y Do you want to enable SNMP trap for 'otn-alarms' (y|n)? y Available alarms: 'oc-lof', 'oc-lom', 'oc-los', 'odu-ais', 'odu-bbe-threshold', 'odu-bdi', 'odu-es-threshold', 'odu-lck', 'odu-oci', 'odu-rx-aps-change', 'odu-sd', 'odu-ses-threshold', 'odu-sf', 'odu-ttim', 'odu-uas-threshold', 'opu-ptm', 'otu-ais', 'otu-bbe-threshold', 'otu-bdi', 'otu-es-threshold', 'otu-fec-deg', 'otu-fec-exe', 'otu-iae', 'otu-sd', 'otu-ses-threshold', 'otu-sf', 'otu-ttim', 'otu-usa-threshold', 'wavelength-lock' Please enter otn-alarms: oc-lof,oc-lom Do you want to enable SNMP trap for 'sonet-alarms' (y|n)? y Available alarms: 'ber-defect', 'ber-fault', 'line-ais', 'line-remote-defect-indication', 'loss-of-cell', 'loss-of-frame', 'loss-of-light', 'loss-of-pointer',

'loss-of-signal', 'path-ais', 'path-mismatch', 'path-remote-defect-indication', 'pll-lock', 'remote-error-indication', 'severely-errored-frame', 'unequipped', 'vt-ais', vt-label-mismatch',

'vt-loss-of-cell', 'vt-loss-of-pointer', 'vt-remote-defect-indication', 'vt-unequipped' Please enter sonet-alarms: path-ais



Other categories: 'authentication', 'chassis', 'configuration', 'link', 'remote-operations', 'rmon-alarm', 'routing', 'services', 'startup', 'vrrp-events' Do you want to enter other SNMP trap categories (y|n)? y Please enter SNMP trap categories: vrrp-events Do you want to configure Syslog server [n]: ySyslog host address? 167.37.0.1 port number [123]: Sylog facility 'all' [n]: Syslog facilities: 'authorization', 'change-log', 'conflict-log', 'daemon', 'dfc', 'explicit-priority', 'external', 'firewall', 'ftp', 'interactive-commands', 'kernel', 'log-prefix', 'ntp', 'pfe', 'security', 'user' Syslog severities: 'alert', 'any', 'criticial', 'emergency', 'error', 'info', 'none', 'notice', 'warning' Please enter syslog facility name: change-log Please enter severity: warning Do you want to enter more syslog facilities [n]? Do you want to configure NTP [n]: y NTP server address: 168.37.0.1


Results The following is an example of the configuration that is initialized on the controller.

Initialize the EX4200 Satellite


To initialize the EX4200 satellite:


user@jnu-satellite1> op url /var/db/scripts/op/jnu-initialize-satellite.slaxSatellite initializations: Please enter hostname [jnu-satellite1]: jnu1-sat-ex1

Please enter management IP address: 10.0.0.1 Please enter uplink IP prefix (192.168.0.2-254/24): 192.168.0.2/24 Please enter uplink interface name: ge-0/0/0 Do you want to use aggregated-ethernet for the uplink [n]: y Please enter uplink aggregate name [ae31] 63 Please enter management VLAN id [4094]: Please enter controller downlink IP address [192.168.0.1]:

Results The following is an example of the configuration that is configured and committed on

the satellite device during the initialize process.

groups {jnu-satellite-mgmt {chassis {aggregated-devices {ethernet-devices {device-count 63;

}



}}system {syslog {/ * syslog parameters propagated from controller except source address */host 169.37.0.1 {security info;change-log info;source-address 10.0.0.1;


}}ntp {/ * Using controller mgmt IP address */server 192.168.0.1;

}services {ssh;

}}snmp {/ * Other snmp parameters propagated from controller */community public:jnu-satellite1 {read-only;

}/ * Other snmp parameters propagated from controller */community private:jnu-satellite1 {read-only;


}trap-group public:jnu-satellite1 {version v2;/ * categories are configured by user, propagate from satellite */categories {authentication;routing;

}targets {169.37.0.1;

}}

}interfaces {ge-0/0/0 {/ * Using aggregate ethernet since there can bemore than 1 uplink */gigether-options {802.3ad ae63;

}}ae63 {/ * Aggregated ethernet interface uplink connection to controller */aggregated-ethernet-options {



lacp {active;


}}


}}

}}vlans {jnu {vlan-id 4094;l3-interface vlan.4094;

}}policy-options {policy-statement jnu-management {/ * Routes that are to be leaked from jnu-vrf to main instance */from {route-filter 169.37.0.1/32 exact;route-filter 132.0.1.1/32 exact;protocol static;

}then accept;


}}routing-options {/ * These configurations to leak routes from jnu-vrf to main instance */rib-groups jnu {import-rib [ jnu.inet.0 inet.0 ];import-policy jnu-management;

}}routing-instances {jnu-vrf {/ * Routing-instance containing uplink to controller */instance-type vrf;interface vlan.4094;route-distinguisher 192.168.0.2:1;vrf-import reject-all;vrf-export reject-all;



routing-options {routing-options {static {rib-group jnu;route 169.37.0.1/32 next-hop 192.168.0.1;route 132.0.1.1/32 next-hop 192.168.0.1;

}}

}}

}}

}

Initialize the QFX3500 Satellite


To initialize the QFX3500 satellite:


user@jnu-satellite> op url /var/db/scripts/op/jnu-initialize-satellite.slaxSatellite initializations: Please enter hostname [jnu-satellite1]: jnu1-sat-qfx2

Please enter management IP address: 10.0.0.1 Please enter uplink IP prefix (192.168.0.2-254/24): 192.168.0.3/24 Please enter uplink interface name: ge-0/1/1 Please enter uplink aggregate name [ae62]: ae0 Please enter management VLAN id [4094]: Please enter controller downlink IP address [192.168.0.1]:

Results The following is an example of the configuration that is initialized on the satellite device.

Todisplay this configuration fromtheMXSeries controller, enter the following command:

user@jnu1-ctrlr> op jnu-show-configuration device jnu1-sat-qfx2 source candidatechassis {aggregated-devices {ethernet-devices {device-count 63;

}}

}system {syslog {/* syslog parameters propagated from controller except source address */host 169.37.0.1 {security info;change-log info;source-address 192.168.0.3;


}}ntp {server 132.0.1.1;



}}snmp {/* Other snmp parameters propagated from controller */community public.hyde {read-only;


}trap-group eas {version v2;targets {169.37.0.1;

}}

}interfaces {ge-0/1/1 {/* Using aggregate ethernet since there can bemore than 1 uplink */gigether-options {802.3ad ae63;

}}ae63 {/* Aggregated ethernet interface uplink connection to controller */aggregated-ethernet-options {lacp {active;

}}vlan-tagging;unit 16385 {vlan-id 4094;family inet {address 192.168.0.3/24;

}}

}}policy-options {policy-statement jnu-management {/* Routes that are to be leaked from jnu-vrf to main instance */from {route-filter 169.37.0.1/32 exact;route-filter 132.0.1.1/32 exact;protocol static;

}then accept;


}}routing-options {/* These configurations leak routes from jnu-vrf to main instance */



rib-groups jnu {import-rib [ jnu-vrf.inet.0 inet.0 ];import-policy jnu-management;

}}routing-instances {jnu-vrf {/* Routing-instance containing uplink to controller */instance-type vrf;interface ae63.16385;route-distinguisher 192.168.0.3:1;vrf-import reject-all;vrf-export reject-all;routing-options {routing-options {static {rib-group jnu;route 169.37.0.1/32 next-hop 192.168.0.1;route 132.0.1.1/32 next-hop 192.168.0.1;

}}

}}

}

Commit the Configuration


JNU uses commit scripts to automate the commit process on the controller and satellite

devices. You commit a configuration for the satellite devices from the controller. Each

satellite device inspects the candidate configuration for errors.

Modify and commit configuration changes only on the controller. When you commit a

configuration on the controller, the flow of the commit process on the controller is as

follows:

1. To commit the new configuration on the controller and on all satellite devices:

user@jnu1-ctrlr> op jnu-commit

The new configuration is validated on each satellite device.

2. If all the satellite devices successfully validate the new configuration, the controller

runs the commit script and displays the following message:

jnu1-sat-ex1:Configuration check succeedsjnu1-sat-qfx2:Configuration check succeeds

Verification

• Verifying That Satellite Devices Are Active on page 93

Verifying That Satellite Devices Are Active

Purpose Verify that satellite devices are active.



Action From operational mode, enter the op jnu-show-satellites command.

user@host>op jnu-show-satellites

user@controller> op jnu-show-satellitesSatellite-system Statejnu-sat-ex1 Upjnu-sat-qfx2 Up

Meaning The display shows that the two satellites are Up.










CHAPTER 12

JNU Port Extender Mode

• Extending a Satellite Interface to a Controller Overview on page 95

• Initializing JNUPort-ExtenderMode on the Controller and Satellite Devices on page 97



• Configuring Multichassis Aggregated Ethernet Interfaces in JNU Port Extender

Mode on page 108


• Processing of Free-Form Settings in JNU Port-Extender Mode on page 122

Extending a Satellite Interface to a Controller Overview

In certainnetworkenvironments, itmightbenecessary toconfigureandadministermany,

different Juniper Networks platforms running Junos OS from one MX Series router. This

MXSeries router that functionsasa JunosNodeUnifier (JNU)controller enableseffective

and easy management andmaintenance of the different platforms, which operate as

satellite devices. The satellite devices, such as EX Series Ethernet switches, QFX Series

devices, and ACX Series Universal Access routers, appear as a single cluster of devices

that are closely interconnected from the controller end.

Although thecontroller canbeconnected to satellitedevices inahub-and-spokemanner,

mesh topology, or a ring topology, critical and severe network failures or outages can

occur in your environment at times. In sucha case, the links between the controller,which

is thedevice that functionsas thesinglemanagement interface for thecluster of satellites,

and the satellites might be disrupted or go down. Until the links are restored, you cannot

virtually perform configuration changes or execute operational commands to gather the

state and statistics information for the satellite devices from the controller.

Under such catastrophic network conditions (except during physical link failures, such

as a cable tear or a defective hardware), youmust log on to a satellite system from a

controller byusingaspecifiedport (suchas theconsoleport or themanagementEthernet

port, if available) to make temporary configuration changes, or run any troubleshooting

operational commands on the satellite systems.

You can configure the JNU controller and satellite devices to operate in port-extender

mode. In this mode, because both the controller and the satellites are managed on the

controller as a single unit, the satellites are considered to be similar to the line-card


chassis on the controller. Port-extender mode signifies that when you configure an

interface that residesphysically onasatellite, the samephysical interfacecanbeextended

to the controller by using a service VLAN (S-VLAN) tag with a logical interface created

to anchor the extended satellite interface on the controller. The advantage of

port-extender mode is that all the interfaces in the JNU group of devices now reside on

the controller.

Until JNU Release 1.2, the only mode of operation of the controller and satellites was

feature-richmode. Thismode is also called non-port-extendermode. In thismode, it was

not possible to configure andmanage the satellites during network disturbances and

circuit failures from the controller. The network fault had tobe correctedbefore you could

manage the satellites fromthecontroller. Theonlymethodof configuring satellitesduring

times of network discrepancies was to manually, individually configure the satellites.

When the satellites were geographically dispersed in different locations, such amethod

of separately configuring themwas ineffective, time-consuming, and difficult.

To provide a robust, cohesive method of managing satellites, starting with JNU Release

1.3, you can enable port-extender mode. In this mode, a JNU group that consists of the

controller and a number of satellites is regarded as a single, unified network entity, with

the controller owning all the interface resources, including those residing on the satellites

(remote line-cards) as extended ports. A satellite interface functions as the satellite port

that is extended to the controller. In this mode, when an interface that resides on the

satellite is enabled within the JNU group, a service VLAN (S-VLAN) ID or tag is used to

transmit the data traffic from the remote interface of the satellite to the controller.

Multiple VLANs can traverse the same satellite interface. All the customer VLANs

(C-VLANs) are encapsulated using the same S-VLAN ID and are extended to the

controller. Each C-VLAN is assigned a logical interface on the controller.

The satellite interface that is extended on to a controller behaves as a logical interface

and appears native to the controller. This capability enables the controller to manage

the satellite interfaces as though theywere the controller's own, in-built interfaces. Each

extended satellite port is a sharedmedium to the controller, and you can configure

multiple VLANs on each port. Each VLAN is hosted on the controller on an individual

interface.

You can select the mode in which the satellites and controller must work—feature-rich

or port-extender—during the initialization of these devices. For the controller and the

satellites to be enabled in JNU port-extendermode, the JNU initialization commands are

used. When you initialize the controller and the satellite devices, youmust be logged in

to the controller or satellite as the root user.

Youcanuse the jnu-show-port-extenderoperationalmodecommandtoviewthemapping

between thesatelliteport and the logical interfaceon thecontroller thathosts the satellite

interface to function as an anchoring interface. You can use the

jnu-port-extender-command command to run operational mode commands related to

a satellite interface that is extended to a controller in port-extender mode.


Initializing the JNUPort-ExtenderMode on Controller and Satellite Devices on page 97•







•

Initializing JNU Port-Extender Mode on the Controller and Satellite Devices

You can select the mode in which the satellites and controller must work—feature-rich

or port-extender—during the initialization of these devices. For the controller and the

satellites to be enabled in JNU port-extendermode, the JNU initialization commands are

used. When you initialize the controller and the satellite devices, youmust be logged in

to the controller or satellite as the root user.

Similar to JNU feature-rich or non-port-extender mode that you can specify using the

JNU initialization command, jnu-initialize-controller.slax, to enable a Junos OS controller

to run in JNUmode, you can enable the device to run in port-extender mode during

initialization.

NOTE: The first time you initialize JNU on the controller, youmust run the op

url /var/db/scripts/op/jnu-initialize-controller operational mode command.

Thereafter, to change the JNU configuration on the controller, you can runthe op jnu-initialize-controller command.

• Initializing the JNU Port-Extender Mode on the Controller on page 97

• Initializing JNU Port-Extender Mode on Satellite Devices on page 98

Initializing the JNU Port-Extender Mode on the Controller

If you select port-extender mode, the JNU port-extender configuration templates and

commands are activated on the controller. In addition, the SNMP, system log, and NTP

settings can be configured in port-extender mode in exactly the samemanner in which

these settings are enabled in feature-rich mode. You can configure these features by

using the jnu-initialize-controller.slax command is the same, regardless of the JNUmode

that you select. This initialization commandalsocreates theNetworkAddressTranslation

(NAT) configuration, regardless of the mode you select.

The following example shows how to configure the controller in port-extender mode,

and add two satellite devices to the controller configuration. The initialization process

creates a JNUmanagement plane configuration in a configuration group called

jnu-controller-mgmt on the controller.

user@jnu-controller> op url /var/db/scripts/op/jnu-initialize-controller.slaxController initializations: Please select the JNU mode: 1. Feature-rich mode The controller and satellite features are supported. Configurations are forwarded to the satellites when the target device is a satellite managed by this controller.


Chapter 12: JNU Port Extender Mode

2. Port Extender mode Interfaces on the satellites are extended to the satellites. Features are configured on the extended ports.

JNU mode (1/2)? 2

NOTE: Only the portion of the initialization process up to the selection of theJNUmode is shown in the preceding example. The remaining settings toconfigure the controller and add satellite devices are the same for bothport-extender and feature-richmodes. See “Initializing JNUMode on theController” on page 30 for details on initializing a controller in feature-richmode.

It is necessary to select the samemode—feature-richor port-extender—on thecontroller

and the satellites. The JNUmanagement plane configurations that are enabled in both

themodes are identical. If you select a different mode on the controller from the one on

the satellites, the controller might still communicate with the satellites, but the JNU

operations may fail.

After you configure the controller in port-extender mode, you need to also configure the

satellites in this mode. Use the JNU initialization command, jnu-initialize-satellite.slax,

to enable a Junos OS device in JNU port-extender satellite mode.

Initializing JNU Port-Extender Mode on Satellite Devices

To initialize a satellite device in port-extender mode, enter the following command on

the satellite device, and follow the prompts:

user@satellite> op url /var/db/scripts/op/jnu-initialize-satellite.slaxSatellite initializations: Please select the JNU mode: 1. Feature-rich mode The controller and satellite features are supported. Configurations are forwarded to the satellites when the target device is a satellite managed by this controller. 2. Port Extender mode Interfaces on the satellites are extended to the satellites. Features are configured on the extended ports.

JNU mode (1/2)? 2

NOTE: Only the portion of the initialization process up to the selection of theJNUmode is shown in the preceding example. The remaining settings toconfigure the satellite devices are the same for both port-extender andfeature-richmodes. See “Initializing JNUMode on Satellite Devices” onpage 38 for details on initializing a controller in feature-richmode.

As part of the initialization process on a satellite, youmust also configure a global value

for the tag protocol identifier (EtherType) of the serviceVLAN tags (outer tags) inQ-in-Q

tunneling for the satellite interface tobeextended to thecontroller, suchasanaggregated



Ethernet interface. Youmust include the ether-type 0x8100 statement at the [edit

ethernet-switching-options dot1q-tunneling] hierarchy level to denote the EtherType

value that appears in the Ethernet type field of the packet. The EtherType value specifies

theprotocolbeing transported in theEthernet frame.OnlyEtherType0x8100 is supported

for port-extender mode.







• jnu-port-extender-command on page 69


Monitoring the Extended Satellite Interfaces Anchored on the Controller

You can track and analyze the states of the satellite interfaces that are extended to the

controller andanchoredona logical interface on the controller. To examine anddiagnose

theworkingof extendedsatellite interfaces, anevent script is supported in theStylesheet

Language Alternative Syntax (SLAX) application on the satellite. Junos OS event scripts

are located in the /var/db/scripts/event directory.

The event script in the SLAXmodule performs the following tasks:

1. If a satellite interface goes down, the event SLAXmodule connects to the controller

to administratively disable the extended interface, which is a logical interface on the

controller.

2. Whenthesatellite interface recovers, theeventSLAXmoduleconnects to thecontroller

to administratively enable the extended interface.

3. If the connectivity between the controller and the satellite is disruptedwhen theevent

script is run, the event SLAXmodule saves the interface state. When the connectivity

between the controller and the satellite is reestablished, the administrative state of

the controller extended interface is analyzed correctly.

Uplink failure detection allows a switch to detect link failure on uplink interfaces and

to propagate this information to the downlink interfaces, so that servers connected

to thosedownlinkscanswitchover tosecondary interfaces.Theuplink-failure-detection

statement must be configured at the [edit protocols] hierarchy level on the satellites

that are managed by the controllers in port-extender mode. The uplink aggregated

Ethernet (ae-) interface that is extended from the satellite to the controller is the

interface configured by using link-to-monitor interface-name statement at the [edit

protocolsuplink-failure-detectiongroupgroup-name]hierarchy level and theanchoring

interface on the controller that contains the extended interfaces is the interface

configured by using link-to-disable interface-name statement at the [edit protocols

uplink-failure-detection group group-name] hierarchy level (when you enter the



config-interfaces command to extend a satellite interface to the controller, it is also

added as a disabled downlink interface.

Consider a sample scenario inwhichanaggregatedEthernet interface, ae0, is thephysical

interfaceon the controller that connects the satellite in thedownlinkdirection. Theuplink

failure detection mechanismmust be configured when you extend the first satellite

interface to the controller in port-extender mode. Assume that ge-0/0/0 is the physical

interface that is extended from the satellite to the controller. In such a topology, to

configure uplink failure detection, do the following:

1. Specify a name for an uplink failure detection group.

[edit protocols]user@switch# set uplink-failure-detection group jnu-mgmt

2. Add an uplink interface to the group.

[edit protocols]user@switch# set uplink-failure-detection group jnu-mgmt link-to-monitor ae0

3. Add a downlink interface to the group.

[edit protocols]user@switch#setuplink-failure-detectiongroupgroup-namelink-to-disablege-0/0/0

When the last interface that is extended to the controller is removed the satellite, you

must remove the uplink failure detection configuration.









Configuring the Port Extender on the Controller

You can configure a physical or a logical interface of a satellite device that is part of a

JNUgroup tobeextendedandaccessible for accessandmanagement fromthecontroller.

This topic contains the following sections that describe the behavior of the

config-interfaces command and how to configure a satellite interface to be extended to

the controller. The satellite extended interface functions as the port extender to enable

the interface of the satellite device to be configured from the controller as though it is

the native interface of the controller, without needing to separately access the satellites

and configure parameters.

• Format and Processing of the config-interfaces Command on page 101

• Configuring a Physical Interface Extension to a Controller on page 102



• Configuring a Logical Interface Extension to a Controller on page 103

• Configuring a Satellite Aggregated Ethernet Port-Extender on page 104

• Configuring VLAN IDs for Satellite Interface Extension on page 104

• Configuring an Anchor Interface on a Controller on page 108

Format and Processing of the config-interfaces Command

The config-interfaces command (the config-interfaces.slax configuration template) is

used to extend physical ports from a satellite to the controller in port-extender mode.

To trigger satellite port-extension, you need to specify a satellite interface name and a

VLAN ID.

user@controller> op config-interfaces action ( set | delete ) interface interface-namevlan-id vlan-id [ options ]

In this command, interface-name is satellite-name:physical-interface-name (the colon, ':',

is thedelimiter). The formatof thephysical interfacemustbeeither interface-prefix-n/n/n

or interface-prefix-n. If you do not specify the interface format in the prescribed way, the

configuration template fails with an error message.

The following command shows how to configure an extended satellite interface on the

controller with a VLAN ID for the interface:

user@controller>opconfig-interfacesactionset interface jnu-satellite1:ge-0/0/0vlan-id1001

If you do not specify the satellite-name option in the op config-interfaces command, the

system references the interface on the controller and the port-extender mechanism is

not configured.

Whenaport on the satellite is specifiedusing the config-interfacescommand, the satellite

VLAN is automatically established between the controller and the satellite on the link

between the two devices. The config-interfaces command contains the same list of

parameters or options as the interface configuration template in feature-richmode.With

theport-extendermode, thephysical interface isextended fromthesatelliteandanchored

with a logical interface on the controller.

Because the satellite port can support multiple VLANs, after you configure the

port-extender, youmust enter the extended satellite interface in other configuration

commands in the following format: satellite-name:interface-name.vlan-id. Because the

extended satellite interface is hosted on the controller on a logical interface, this format

of specification is identical with the standard logical interface format. However, with

extended satellite interfaces, the unit parameter of the standard logical interface syntax

signifies the VLAN ID of the satellite interface.

When you enter the config-interfaces.slax command on a controller with the value of the

interface parameter consisting of the satellite name followed by a physical interface

namewith a colon (:) as the delimiter between the two strings and VLAN ID specified,

the config-interfaces.slax command performs the following operations:



• Examines whether the satellite interface and the VLAN ID are already extended to the

controller. If the interfacehasbeenpreviously extended, theport-extender configuration

is left unchanged.

• If the satellite interface is being extended for the first time, the port-extender

configuration is created on the controller. The port-extender on the controller is set up

by assigning an idle service VLAN tag (S-VLAN tag, which is the outer VLAN tag). A

logical interface on the controller is allocated to operate as the downlink connection

to the satellite to host the extended interface.

• The port-extender configuration is set up on the satellite. The same S-VLAN tag that

is allocated by the controller to be used as the outer tag of the VLAN in the downlink

connection is used by the satellite to create the dot1Q-tunneling configuration.

To create the trunk between the satellite and the controller, the config-interfaces.slax

configuration template generates the apply-macro statement configurations for the

controller and the satellite from the op script. Macros work by locating apply-macro

statements that you include in thecandidateconfigurationandusing thevalues specified

in the apply-macro statement as parameters to a set of instructions (themacro) defined

in a commit script. The commit script alters your configuration from one that contains

custom syntax into a full configuration containing standard Junos OS statements.

In effect, your custom configuration syntax serves a dual purpose. The syntax allows you

to simplify your configuration tasks, and it provides data (or hooks) that are used by a

commit script macros. The outer tags used to create a trunk with the satellite ports are

unique within a JNU group (a number in the range 1–4093) regardless of the satellites.

The outer tags used to create a trunkwith the satellite ports canbe reused in other bridge

domains on the controller for interfaces that are not configured as extended satellite

interfaces.

Configuring a Physical Interface Extension to a Controller

An extended satellite interface can be a physical interface, such as a Gigabit Ethernet

(ge), 10-Gigabit Ethernet (xe), or an aggregated Ethernet (ae) interface. The syntax of

the name of the extended port or interface is satellite-name:physical-interface-name. For

example, you can name an extended interface as jnu-satellite1:ge-0/0/0, which signifies

the combination of the satellite name and the physical interface name.

The config-interfaces command can be used to configure the physical interface or the

logical interface features. For physical interfaces on satellites to be used as extended

interfaces from the satellite to the controller, you must configure the port-extender

interfaces on the native ports on the satellites. If you specify the controller interfacewith

the config-interfaces command, the configuration is expanded on the physical interface

of the controller. If you specify the satellite interfacewith this command, the configuration

is expanded on the physical interface on the satellite. The optional unit parameter in the

config-interfaces command differentiates between a physical and a logical interface

configuration session.

To configure a physical interface of a satellite to be used as the extension interface to

the controller and to enable gratuitous ARP replies to be sent to the broadcast MAC

address with the target IP address set to be the same as the sender's IP address:



user@controller> op config-interfaces action set interface jnu-sat1:ge-0/0/0gratuitous-arp-reply enable

The following configuration is generated on the satellite as a result of the preceding

command:

## Satellite jnu-sat1 configurationinterfaces { ge-0/0/0 { gratuitous-arp-reply; }}

BEST PRACTICE: We recommend that you configure the attributes of thephysical and logical interfaces separately and not in the same step, althoughthe config-interfaces command can be used to configure both physical and

logical interface functionalities.

Configuring a Logical Interface Extension to a Controller

Unlike a physical interface that is configured to be extended to the controller from a

satellite, when you enter the config-interfaces command to configure logical interface

features for a satellite interface, the configurations are expanded on the extended

interface on the controller.

Because the port extended from the satellite is anchored on a controller logical interface,

the config-interfaces.slax command performs the following validations:

• The interface parameter can specify an interface on the controller (format

interface-name$) or an interface on the satellite (format

satellite-name:interface-name.vlan-id$).

• If the logical interface settings are specified for an interface on the controller, for

example, xe-0/0/1, the optional unit parameter is required.

• If the logical interface settings are specified for an interface on the satellite—for

example, "jnu-sat1:ge-0/0/10.101"—you need not specify the unit parameter. The

resulting configuration, however, is saved on the aggregated Ethernet interface bundle

on the controller that hosts the extended satellite port. The interface name uses the

.vlan-idpart of the configuration to correctly identify the controller anchoring the logical

interface.

To configure a logical interface of a satellite to be used as the extension interface to the

controller:

user@controller> op config-interfaces action set interface jnu-sat1:ge-0/0/0.1001 familyinet inet.address 199.1.1.1/30



The following show command displays the configuration that is generated on the

controller as a result of the preceding settings to configure a logical interface as the

extended satellite interface:

user@controller> show configuration | display commit-scriptinterfaces { ae0 { /* Port Extender for jnu-sat1:ge-0/0/0 */ unit 1001 { vlan-tags outer 101 inner 1001; family inet { address 199.1.1.1/30; } } }}

If you set the maximum transmission unit (MTU) size for an extended port from the

satellite to the controller, the config-interfaces command validates that the path MTU

is sufficient to handle the configured port MTU.

Configuring a Satellite Aggregated Ethernet Port-Extender

You can configure an aggregated Ethernet (ae) interface to be used as the extended

satellite interface to the controller. To extend an aggregated Ethernet interface from the

satellite, you need to specify the physical interfaces to be linkmembers in an aggregated

Ethernet interface, and then use the port-extender configuration template,

config-interfaces, to extend it to the controller.

To extend a satellite interface, jnu-sat1 ae0, as an aggregated Ethernet interface that

includes the member interfaces of the aggregated Ethernet bundle, ge-0/0/0 and

ge-0/0/1:

1. Configure the first member interface of the aggregated Ethernet logical interface.

user@controller> op config-interfaces action set interface jnu-satellite1:ge-0/0/0802.3ad ae0

2. Configure the other member interface of the aggregated Ethernet logical interface.

user@controller> op config-interfaces action set interface jnu-satellite1:ge-0/0/1802.3ad ae0

3. Configure the VLAN ID of the aggregated Ethernet logical interface.

user@controller> op config-interfaces action set interface jnu-satellite1:ae0 vlan-id1001

Configuring VLAN IDs for Satellite Interface Extension

Q-in-Q tunnelingandVLANtranslationallowserviceproviders tocreateaLayer 2Ethernet

connection between two customer sites. Providers can segregate VLAN traffic from

different customers on a link (for example, if the customers use overlapping VLAN IDs)

or bundle different customer VLANs into a single service VLAN. You can use Q-in-Q



tunneling and VLAN translation to isolate customer traffic within a single site or enable

customer traffic flowsbetweendevices indifferentgeographic locations.Q-in-Q tunneling

adds a service VLAN tag before the 802.1Q VLAN tags of the customer.

Theport-extendermode in the JNUgroupofdevicesusesQ-in-Qservices.Thismechanism

causes the outer VLAN tag (service VLAN tag) to be automatically assigned by the

config-interfaces command. When a port on the satellite is extended to the controller,

regardless of the C-VLAN tag (inner VLAN tag) that is used, the same outer tag is added

to all the traffic that arrives at the ingress interface and is forwarded to the controller in

the uplink direction using 802.1Q (dot1Q) VLAN tunneling.

On the controller, the traffic that arrives from each C-VLAN of each satellite port

terminates on a different logical interface in the downlink direction from the controller

to the satellite. To uniquely differentiate the traffic from various ports extended from the

satellites to the controller, the outer tags must be unique within the JNU group (that is,

one VLAN tag for each extended satellite port). The outer tag is different from the JNU

managementplaneVLAN IDandautomaticallyassignedby thesystem; it is notmanually

configured.

Because of all the configurations being done on the controller, the controller tracks all

of the Q-in-Q tags already assigned.When you configure the port extension by using the

config-interfaces command, an idle outer tag is assigned to each extender port (for

example, 101, as shown in the following configuration).

To extend a satellite interface to the controller, enter the following command on the

controller:

user@controller>opconfig-interfacesactionset interface jnu-satellite1:ge-0/0/0vlan-id101

This interface name is used by all other configuration templates in JNU port-extender

mode. If you configure a second VLAN for the same satellite port on the controller, the

same outer tag (in this case, 101) is used. The satellite uses dot1Q tunneling to extend

the physical interface to the controller.

The following is an example of the configuration created on the satellite, jnu-satellite1,

as a result of the controller configuration:

interfaces { /* Physical port to be extended to controller */ ge-0/0/0 { unit 0 { family ethernet-switching; } }}vlans { /* JNU port extender VLAN for ge-0/0/0 */ jnu-port-extender-101 { vlan-id 101; interface { ge-0/0/0.0; } dot1q-tunneling { customer-vlans 1001;



} }}

For extended ports from the satellite, after the ports are set up, they are anchored on the

controller. You can enter the config-vlan command to assign a satellite extended port

to a VLAN on the controller. When you enter this command, the following operations are

performed:

• When a VLAN is created using the config-vlan command, a bridge domain is created

on the MX Series device that functions as the controller.

• When you specify a satellite port, satellite-name:physical-interface-name, in the

config-vlan command, the anchoring port on the controller is assigned to the bridge

domain created by the config-vlan command.

• The config-vlan command does not support the device device-name option because

the generated configuration resides on the controller.

To enable the satellite extended port in a bridge-domain VLANwith VLAN ID 101 on the

controller:

1. Specify the interface that you want to extend from the satellite with the VLAN ID.

user@controller> op config-interfaces action set interface sat1:ge-0/0/0 vlan-id 101

2. Enable Ethernet VLAN bridge encapsulation on the logical interface.

user@controller> op config-interfaces action set interface sat1:ge-0/0/0.101 familyvlan-bridge

3. Assign the satellite extended port on the controller to the bridge domain.

user@controller> op config-vlan action set vlan vlan101 vlan-id 101 interfacejnu-sat1:ge-0/0/0

The jnu-show-port-extenderoperationalmodecommanddisplays themappingbetween

the satellite port and the logical interface that hosts this satellite extended port on the

controller:

user@controller> op jnu-show-port-extenderPort Extender Interface Controller IFL S-VLAN C-VLANjnu-sat1:ge-0/0/0.101 ae479.101 1001 101

The following configuration is generated on the controller:

interfaces { ae479 { unit 101 { encapsulation vlan-bridge; vlan-tags outer 1001 inner 101; } }}bridge-domains { vlan101 { vlan-id 101; interface ae479.101;



}}

The following showcommanddisplays thebridge-domainconfigurationon thecontroller:

user@controller> show bridge domain vlan101Routing instance Bridge domain VLAN ID Interfacesdefault-switch vlan101 101 ae479.101

Youmust configure Layer 2 and Layer 3 features after the satellite ports are extended

to the controller. Because these features are handled by the MX Series controller, you

mustuse theconfigurationsyntaxof theMXSeriesdevices for thesesettings. For example,

bridge domains aree used for configuring VLANs. For example, to configure two satellite

extended interfaces in a bridge domain, enter the following commands on the controller:

user@controller> op config-vlans action set vlan vlan-4093 vlan-id 4093user@controller>opconfig-vlansaction set vlanvlan-4093 interfaceex-3300-1:ae30.33user@controller> op config-vlans action set vlan vlan-4093 interface ex-3300-1:ae4.33

The jnu-show-port-extenderoperationalmodecommanddisplays themappingbetween

the satellite port and the logical interface that hosts this satellite extended port on the

controller:

user@controller> op jnu-show-port-extenderPort Extender Interface Controller IFL S-VLAN C-VLAN ex-3300-1:ae30.33 ae0.16384 4092 33 ex-3300-1:ae4.33 ae0.16383 4091 33

The following configuration is generated on the controller:

interfaces { ae0 { flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 16383 { encapsulation vlan-bridge; vlan-tags outer 4091 inner 33; } unit 16384 { encapsulation vlan-bridge; vlan-tags outer 4092 inner 33; } }}bridge-domains { vlan-4093 { vlan-id 4093; interface ae0.16383; interface ae0.16384; }}

The following showcommanddisplays thebridge-domainconfigurationon thecontroller:

user@controller> show bridge domainRouting instance Bridge domain VLAN ID Interfacesdefault-switch vlan-4093 4093



ae0.16383 ae0.16384

Configuring an Anchor Interface on a Controller

The controller uses one logical interface in the downlink direction from the controller to

the satellite to anchor each extended VLAN from the satellite. These anchor interfaces

serve as the underlying, base interface.

ToconfigureanaggregatedEthernet interfaceasananchor interface in JNUport-extender

mode in the downlink connection of the controller:

1. Specify the aggregated Ethernet interface that you want to configure.

[edit]user@controller# edit interfaces ae479

2. Configure the logical unit of the interface. This interface is the port-extender

configuration for jnu-satellite1:ge-0/0/0

[edit interfaces ae479]user@controller# edit unit 101

3. Define the VLAN tags for the interface.

[edit interfaces ae479 unit 101]user@controller# set vlan-tags outer 101 inner 1001

ConfiguringMultichassis Aggregated Ethernet Interfaces in JNU Port Extender Mode

Multichassis link aggregation groups (MC-LAGs) enable a client device to form a logical

LAG interface between twoMC-LAGpeers or devices). AnMC-LAGprovides redundancy

and loadbalancingbetween the twoMC-LAGpeers,multihomingsupport, anda loop-free

Layer 2 network without running the Spanning Tree Protocol (STP). You can configure

the multichassis aggregated Ethernet (MC-AE) interfaces on the MX Series routers that

operate as controllers in a JNUgroup to support the satellite interfaces or ports extended

to the controllers. The port-extender mode supports dual-homed servers that are

connected to the satellites in a JNU group without using MC-AE interfaces. To enable

the JNU port-extender mode to support MC-AE interfaces in the the links between two

controllers in two different JNU groups, the following requirements must bemet:

• The service VLAN IDs assigned for the extended satellite interfaces in the two JNU

groups are unique (the groups that contain MX1 that manages EX1 in one group and

MX2 that manages EX2 in the other group). This condition is required because the

synchronization of information on the MC-AE interfaces using ICCP is based on the

logical interface settings. If a VLAN ID is reused and is not unique for the extended

interfaces and if the remote endpoint of the ae- interface is not the same server

(singly-homed servers), connectivity problems for this server can occur.

• The serviceVLANassigned to the twocontrollers for theextended satellite ae interface

must be identical for the MC-AE extended interfaces from the satellite.

• Server-to-server connectivity is maintained.



• Two linksmust be used to connect the twoMXSeries routers, MX1 andMX2, that work

as controllers. One of the linksmust be configured for ICCP and the other linkmust be

configured for interchassis link-protection link (ICL- PL). Although you can configure

only one link betweenMX1 andMX2, we recommend that you configure separate links

for ICCP and ICL-PL.

• For eachMC-AE logical interface, a logical interface on the ICL-PL linkmust be present

in the same bridge domain as the controllers.

• AmixedVirtualChassiscomposedofanycombinationofEX4200andEX4500switches

is not supported.

Consider a sample topology in which twoMX Series controllers, MX1 and MX2, manage

twosatellite devices,whichareEXSeries switchesEX1andEX2, respectively.Multichassis

link aggregation groups (MC-LAGs) are used between MX1 and MX2 to form a logical

LAG interface between the two controllers. The MC-LAG devices use the Interchassis

Control Protocol (ICCP) to exchange the control information between twoMC-LAG

devices. The peers in anMC-LAGuse an interchassis control link-protection link (ICL-PL)

to replicate forwarding information across the peers. Additionally, ICCP propagates the

operational state of MC-LAGmembers through the ICL-PL. The two peers that host a

givenmultichassis link aggregation group (MC-LAG)must have the samemultichassis

aggregated Ethernet ID. MC-LAG is enabled on the AE interface, ae0, on both MX1 and

MX2. The two EX Series devices, EX1 and EX2, are configured with an AE interface each,

ae0. The AE interface, ae2, of EX1 is configured with a VLAN ID and connected to an

external server, SVR1. Similarly, the AE interface, ae2, of EX2 is connected to the external

server, SVR1. The interfaces, ae1, of both EX1 and EX2 are extended and hosted on the

interfaces, ae0, of MX1 and MX2, respectively. These interfaces are MC-AE interfaces

that are in port-extender mode because MC-LAG is enabled on these links. The logical

units of these interfaces, ae0, of bothEX1andEX2areextendedandhostedon the logical

unitsof the interfaces, ae0, ofMX1andMX2, respectively. These interfacesarenon-MC-AE

interfaces with MC-LAG not configured on these links.

Connection between EX1 and SVR1 is through two interfaces—ae2 fromEX1 to SVR1, and

the extended ae0 interface with a logical unit configured to connect between EX1 and

SVR1. The extended logical satellite interface, ae0, also connects EX1 with another

external server, SVR2. Connection between EX2 andSVR1 is through two interfaces—ae2

fromEX2 toSVR1, and theextendedae0 interfacewitha logical unit configured toconnect

between EX2 and SVR1. The extended logical satellite interface, ae0, also connects EX2

with another external server, SVR2.

Configure LACP as active between the interfaces on the MX Series controller and the EX

Series satellite device in the uplink and downlink directions. LACP is not configured

between the satellites and the external server. Also, MC -LAG and ICCP are configured

on the controllers in the interfaces that connect them.

To enable the MC-LAG functionality in the port-extender mode for satellite interfaces

extended to the controller, an event script is implemented on the satellite tomonitor the

following characteristics:

• The connection from the satellite to the server. On the satellite, if the connectivity to

a server is lost, it disables the extended satellite logical interface on the controller. For



example, the external server, SVR1, is connected to EX1 using the ae2 interface on EX1

and it is also connected to EX2 using the ae2 interface on EX2. LACP is not enabled on

this aggregated Ethernet link. 802.1Q (dot1Q) VLAN tunneling is used to tunnel the

server traffic from the satellites to the MX Series controllers on the ae0 interface. On

the interface ae0 on the MX Series devices, a logical interface, ae0.1000, hosts the

tunneled traffic from the connected satellites for the server. If the connection between

EX1 and SVR1 goes down, this logical interface, ae0.1000, is disabled to redirect all the

traffic transmitted to SVR1 through EX2. When the connection between EX1 and SVR1

recovers, the event script reenables the ae0.1000 interface. MC-AE is configured on

MX1 and MX2 to group and bundle the ae0 interfaces between these two devices.

• The uplink connection from the satellites to the controller. If the satellite uplink to the

controller is disabled, all the satellite ports are disabled.

• If port-extension for the dual-homed servers is connected in a bridge domain between

the two controllers, an STP needs to be configured to ensure that the link between the

two controllers is blocked.

The following conditions apply to the sample topology discussed in this topic:

• Only one MC-AE interface for each controller-satellite pair is configured. The external

servers that are connected to the satellites using MC-AE interfaces must connect to

the same corresponding satellites in the JNU group (that is, SVR1 connects to EX1 and

EX2, andSVR2also connects toEX1 andEX2andnot to another satellite, suchasEX3).

• The configuration templates for port-extender modemust bemodified to ensure that

the service VLAN IDs of the extended satellite interfaces are unique between the two

JNUgroups (the groups that containMX1 thatmanages EX1 in one group andMX2 that

manages EX2 in the other group).

• Uplink failure detection allows a switch to detect link failure on uplink interfaces and

to propagate this information to the downlink interfaces, so that servers connected to

those downlinks can switch over to secondary interfaces. The uplink-failure-detection

statement must be configured at the [edit protocols] hierarchy level on the EX Series

switches, EX1 andEX2, that aremanagedby the controllers,MX1 andMX2, respectively.

This functionality is used to monitor the uplink connection from the satellites to the

controller. If the uplink connection to the controller goes down, all the satellite servers

ports will be disabled.

For the JNU port-extender mode to retrieve the same service VLAN ID in both the JNU

groups to implement the Q-in-Q tunneling functionality, the following assumptions and

limitations apply to the JNU scripts:

• Each satellite device can contain a maximum of 48 ports.

• For the dual-homed servers, youmust connect the server to the same ports on both

the satellites.

• For the two JNU groups that contain MC-AE interface connections, the service VLAN

tags assigned to the dual-homed server must be the same in the two JNU groups and

the service VLAN tags assigned to the servers that are not dual- homed are unique

within the two JNU groups to enable MC-AE operations to happen correctly.



In the connection between the external server and the satellite, either of the following

twomethods can be implemented:

• Using static LAG—Enable the servers to connect to the two EX Series satellites in the

two JNU groups using ae- interfaces, LACP is not run between the satellites and the

dual-homed servers. The event script on the satellite ensures that the logical interface

path between the controller and the server is disabled if any connectivity problems

between the server and the MX Series controller occur.

• Using LACPwith normalized system ID on the two satellites—Enable LACP between

the two EX Series satellites to connect to the same server, and configure the LACP

system identifier by using system-id system-id statement at the [edit interfaces aeX

aggregated-ether-options lacp] hierarchy level on the two satellites to be the same

value so that the same system identifier is advertised to the server.

• Configuration on EX1 on page 111

• Configuration on MX1 on page 112

• Configuration on MX2 on page 113

• Configuration on EX2 on page 114

Configuration on EX1

To configure the AE interfaces on EX1 to be extended to the controller, MX1, for both

MC-LAG and non-MC-LAG links:

1. Configure Link Aggregation Control Protocol (LACP) on the AE interface. If you do not

specify LACP as either active or passive, LACP remains passive.

user@satellite# set interfaces ae0 aggregated-ether-options lacp active

2. Configure the Ethernet switching settings and the port mode as trunk.

user@satellite# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk

3. For trunk interfaces, configure theVLANs forwhich the interface can carry traffic. Also,

the aggregated Ethernet logical interface is the non-MC-AE interface that is extended

from the satellite to the controller, MX1.

user@satellite# set interfaces ae0 unit 0 family ethernet-switching vlanmembers all

4. Configure another aggregated Ethernet interface to serve as uplink connection to the

controller, which is the extended satellite interface for MC-LAG. Configure LACP on

ths interface, which is extended to the controller, MX1, with MC-LAG configured on

the extended interface.


5. Define the LACP system identifier at the aggregated Ethernet interface level

user@satellite# set interfaces ae2 aggregated-ether-options system-id 1:2:3:4:5:6




the aggregatedEthernet logical interface is theMC-AE interface that is extended from



the satellite to the controller, MX1. The forwarding of traffic to the controller in the

uplink direction occurs using 802.1Q (dot1Q) VLAN tunneling.

user@satellite# set interfaces ae2 unit 0 family ethernet-switching vlanmembers 33

8. Configureaglobal value for the tagprotocol identifier (EtherType)of theserviceVLAN

tags (outer tags) in Q-in-Q tunneling for the satellite interface to be extended to the

controller. It specifies the protocol being transported in the Ethernet frame. Only

Ethertype 0x8100 is supported for port-extender mode. The port-extender service

VLANEthertype is common for both theMC-AE and non-MC-AE extended interfaces.

user@satellite# set ethernet-switching-options dot1q-tunneling ether-type 0x8100

9. Configure the VLAN on the satellite interface to be extended to the controller. The

service VLAN needs to match between MX1-EX1 and MX2-EX2.

user@satellite# set vlans jnu-port-extender-1000 vlan-id 1000user@satellite# set vlans jnu-port-extender-1000 interface ae2.0user@satellite# set vlans jnu-port-extender-1000 dot1q-tunneling customer-vlans33

Configuration onMX1

To configure the AE interfaces onMX1 to host the extended satellite interfaces from EX1:



user@controller# set interfaces ae0 aggregated-ether-options lacp active

2. Configure an administrative key for LACP.

user@controller# set interfaces ae0 aggregated-ether-options lacp admin-key 33

3. Configure the LACP system identifier for aggregated Ethernet interfaces.

user@controller# set interfaces ae0 aggregated-ether-options lacp system-id0:0:0:0:0:1

4. Specify the samemultichassis aggregated Ethernet identification number for the

MC-LAG that the aggregated Ethernet interface belongs to on each switch.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-aemc-ae-id 33

5. Specify a unique chassis ID for the MC-LAG that the aggregated Ethernet interface

belongs to on each switch.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-ae chassis-id 0

6. Specify the mode of the MC-LAG the aggregated Ethernet interface belongs to.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-aemode active-active

7. Specify the redundancygroup identificationnumber. ICCPuses the redundancygroup

ID to associate the routing or switching devices contained in a redundancy group.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-aeredundancy-group 33



8. Specify whether the aggregated Ethernet interface participating in the MC-LAG is

primary or secondary. Primary is MX1, which is active, and secondary is MX2, which is

standby.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-ae status-controlactive

9. Configure the extended interface for the connection between EX1 and SVR1.

user@controller# set interfaces ae0 unit 1000 vlan-tags outer 1000 inner 33



11. Configure ICCP by configuring the local IP address, the peers hosting the MC-LAG.

Specify the redundancy groups between two ICCP peers. Optionally, configure the

minimum interval at which the switchmust receive a reply from the other switchwith

which it has established a Bidirectional Forwarding Detection (BFD) session.

user@controller# set protocols iccp local-ip-addr 192.168.164.164user@controller# set protocols iccp peer 192.168.164.77 redundancy-group-id-list 33user@controller# set protocols iccp peer 192.168.164.77 liveness-detectionminimum-receive-interval 60

Configuration onMX2

To configure the AE interfaces onMX2 to host the extended satellite interfaces fromEX2:



user@controller# set interfaces ae0 aggregated-ether-options lacp active

2. Configure an administrative key for LACP.

user@controller# set interfaces ae0 aggregated-ether-options lacp admin-key 33

3. Configure the LACP system identifier for aggregated Ethernet interfaces.

user@controller# set interfaces ae0 aggregated-ether-options lacp system-id0:0:0:0:0:1

4. Specify the samemultichassis aggregated Ethernet identification number for the

MC-LAG that the aggregated Ethernet interface belongs to on each switch.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-aemc-ae-id 33

5. Specify a unique chassis ID for the MC-LAG that the aggregated Ethernet interface

belongs to on each switch.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-ae chassis-id 0

6. Specify the mode of the MC-LAG the aggregated Ethernet interface belongs to.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-aemode active-active

7. Specify the redundancygroup identificationnumber. ICCPuses the redundancygroup

ID to associate the routing or switching devices contained in a redundancy group.



user@controller# set interfaces ae0 aggregated-ether-optionsmc-aeredundancy-group 33

8. Specify whether the aggregated Ethernet interface participating in the MC-LAG is

primary or secondary. Primary is MX1, which is active, and secondary is MX2, which is

standby.

user@controller# set interfaces ae0 aggregated-ether-optionsmc-ae status-controlstandby





11. Configure ICCP by configuring the local IP address, the peers hosting the MC-LAG.

Specify the redundancy groups between two ICCP peers. Optionally, configure the

minimum interval at which the switchmust receive a reply from the other switchwith

which it has established a Bidirectional Forwarding Detection (BFD) session.

user@controller# set protocols iccp local-ip-addr 192.168.164.164user@controller# set protocols iccp peer 192.168.164.77 redundancy-group-id-list 33user@controller# set protocols iccp peer 192.168.164.77 liveness-detectionminimum-receive-interval 60

Configuration on EX2

To configure the AE interfaces on EX2 to be extended to the controller, MX2, for both

MC-LAG and non-MC-LAG links:







the aggregated Ethernet logical interface is the non-MC-AE interface that is extended

from the satellite to the controller, MX1.

user@satellite# set interfaces ae0 unit 0 family ethernet-switching vlanmembers all

4. Configure another aggregated Ethernet interface to serve as uplink connection to the

controller, which is the extended satellite interface for MC-LAG. Configure LACP on

ths interface, which is extended to the controller, MX1, with MC-LAG configured on

the extended interface.


5. Define the LACP system identifier at the aggregated Ethernet interface level

user@satellite# set interfaces ae2 aggregated-ether-options system-id 1:2:3:4:5:6






the aggregatedEthernet logical interface is theMC-AE interface that is extended from

the satellite to the controller, MX1. The forwarding of traffic to the controller in the

uplink direction occurs using 802.1Q (dot1Q) VLAN tunneling.

user@satellite# set interfaces ae2 unit 0 family ethernet-switching vlanmembers 33

8. Configureaglobal value for the tagprotocol identifier (EtherType)of theserviceVLAN

tags (outer tags) in Q-in-Q tunneling for the satellite interface to be extended to the

controller. It specifies the protocol being transported in the Ethernet frame. Only

Ethertype 0x8100 is supported for port-extender mode. The port-extender service

VLANEthertype is common for both theMC-AE and non-MC-AE extended interfaces.

user@satellite# set ethernet-switching-options dot1q-tunneling ether-type 0x8100

9. Configure the VLAN on the satellite interface to be extended to the controller. The

service VLAN needs to match between MX1-EX1 and MX2-EX2.

user@satellite# set vlans jnu-port-extender-1000 vlan-id 1000user@satellite# set vlans jnu-port-extender-1000 interface ae2.0user@satellite# set vlans jnu-port-extender-1000 dot1q-tunneling customer-vlans33

The config-interfaces command performs the following operations to assign a service

VLAN ID for the satellite interface that is extended to the controller:

• For each satellite pair in the two JNU groups, 96 VLAN IDs are allocated. This behavior

occurs to ensure that enough VLAN IDs to be assigned are available when all the ports

are connected to singly-homed servers.

• When you enable a satellite in the JNU port-extender mode, you specify the starting

service VLAN ID range for the satellites and also the starting service VLAN ID range for

singly-tagged servers. For example, in this sample topology, when you initialize the EX1

and EX2 satellites in port-extender mode, the JNU initialization script uses the default

of the range of the subsequent 96 VLAN IDs.

• 0–95

• 96–191

• 192–287

• 288–383

• 384–479

• 480–575

• 576–671

• 672–767

• 768–863

• 864–959

• 960–1055



• 1056–1151

• 1152–1247

• 1248–1343

• 1344–1439

• 1440–1535

• 1536–1631

• 1632–1727

• 1728–1823

• 1824–1919

• 1920–2015

• 2016–2111

• 2112–2207

• 2208–2303

• 2304–2399

• 2400–2495

• 2496–2591

• 2592–2687

• 2688–2783

• 2784–2879

• 2880–2975

• 2976–3071

• 3072–3167

• 3168–3263

• 3264–3359

• 3360–3455

• 3456–3551

• 3552–3647

• 3648–3743

• 3744–3839

• 3840–3935

• 3936–4031

Youmust then indicate the startingVLAN IDof the singly-taggedVLAN IDs. The starting

VLAN ID on EX1 of the singly-tagged VLAN ID is 0, the starting VLAN ID on the EX2 of



the singly-taggedVLAN ID is 48. Thedual-homed satellites always use the lower range

of the VLAN ID.

• The service VLAN ID assigned to each port is deterministic. As a result, port 0/0/0

(such as ge-0/0/0 or xe- 0/0/0) uses the first VLAN ID (0); port 0/0/1 (ge-0/0/1 or

xe-0/0/1) uses the second VLAN ID (1).

• To extend a satellite ae- interface, the service VLAN ID assigned to the hosting or

anchoring controller interface is the VLAN ID of the lowest interface in the aggregated

Ethernet bundle.

• Youcanoverride theserviceVLAN ID for theport-extendermode if theserver connection

is not symmetric between the two JNU groups.


Configuring the Port Extender on the Controller on page 100•

Processing of Configuration Templates in JNU Port-Extender Mode

If you enable the port-extendermode for satellites and the controller in a JNU group, you

need not specify the device parameter with the config-template-name command for

satellite interfaces that are extended to the controller. For such extended interfaces,

because of the format of the interface being satellite-name:physical-interface-name, the

system processes the attributes that you want to configure on such extended interfaces

correctly, even if you do not specify the device parameter.

This topic contains the following sections that describe the usage guidelines regarding

the different configuration templates. For JNU configuration templates other than the

ones specifically described in the following sections, the device parameter is not needed

for the satellite ports that are extended to the controller.

• Layer 2 Templates on page 117

• Layer 3 Templates on page 119

• System-Level Templates on page 120

• Firewall Templates on page 121

• CoS Templates on page 121

Layer 2 Templates

JNU Layer 2 configuration templates can be used to configure Layer 2 settings on either

the physical interface of the satellite or on the extended satellite interface on the

controller. Although by default, if you do not specify the device parameter with the Layer

2 template, the attributes are set up on the extended satellite port on the controller, you

canchange theseLayer 2attributes tobeenabledon thephysical interfaceon the satellite

directly.

Theseconfiguration templatescontain theoptionaldeviceparameterand if theparameter

is not specified, the configurations are considered to be for the controller. If you specify



the device parameter to denote the satellite device for which you want to configure

settings, the configurations are forwarded and expanded on the specified satellite.

Table 7 on page 118 shows the Layer 2 templates supported in JNU port-extender mode:

Table 7: Packet Fields for Reflection Test Mode

Whether Template IsSupported on EX Series andQFX Series Satellites

Whether Template IsSupported onMX SeriesControllersTemplate Name

BothBothconfig-access

DefaultNot supportedconfig-analyzer

BothBothconfig-dot1x

DefaultNot supportedconfig-ethsw-bpdu

DefaultNot supportedconfig-ethsw-options

DefaultNot supportedconfig-ethsw-redundant-trunk-group

DefaultNot supportedconfig-ethsw-secure-access-port

DefaultNot supportedconfig-ethsw-storm-control

SupportedDefaultconfig-l2-learning

Not supportedDefaultconfig-layer2-control

SupportedDefaultconfig-mstp

Both (EX Series only)Bothconfig-poe-interface

SupportedDefaultconfig-rstp

DefaultNot supportedconfig-stp

SupportedDefaultconfig-vstp

If the controller does not support a certain Layer 2 feature, the interface parameter that

you enter is not considered if you enter the interface value in any format other than

satellite-name:interface-name.vlan-id$. For Layer 2 templates in the preceding table that

are denoted as supported by default, the you do not nee the optional parameter is

optional. If you do not specify the device parameter to denote the satellite device and if

the interface value is of the format satellite-name:physical-interface-name.vlan-id or all,

the configuration is applied on the specified controller or satellite device. For Layer 2

templates in the preceding table that are denoted as supported by both the controller

and satellites, the config-access and config-dot1x templates operate together. The

config-access command specifies the access profile configurations. The config-dot1x



command references these access profiles. When an access profile is specified, the

profile configuration is applied to both the controller and satellites. When an interface

is specified in the config-dot1x, if all is specified, the configuration is applied to both the

controller and thesatellite; otherwise, the interfacevalue is examine todeterminewhether

the configuration is applicable to the controller or the satellite

(satellite-name:physical-interface-name.vlan-id implies that theconfiguration is expanded

on the satellite). The config.dt1x template is used to specify an authentication profile for

user or client authentication and configure the Ethernet interface for 802.1x protocol

operation.

Layer 3 Templates

After a satellite port is extended to the controller as a logical interface, you can use a

JNU configuration template command related to Layer 3 features and specify the

extendedsatelliteport, for example, jnu-sat1:ge-0/0/0. In suchacase, theLayer 3 features

are configured on the port-extender logical interface on the controller and not on the

satellite. The processes associated with the specific Layer 3 protocol or module on the

controller and not the satellite handle these Layer 3 features.

In port-extender mode, the following configuration templates do not contain the device

parameter because the configurations always reside on the controller:

• config-bgp

• config-connections

• config-dvmrp

• config-igmp-snooping

• config-igmp

• config-isis

• config-l2circuit

• config-l2vpn

• config-ldp

• config-link-management

• config-lldp-med

• config-lldp

• config-mpls

• config-mpls-lsp

• config-mpls-path

• config-mpls-static-lsp

• config-mvpn

• config-ospf

• config-pim-interface



• config-pim-rp

• config-pim

• config-policy-options

• config-policy-options-as-path

• config-policy-options-community

• config-policy-options-condition

• config-policy-options-damping

• config-policy-options-prefix-list

• config-policy-statement

• config-routing-instances

• config-routing-options

• config-routing-options-access-internal

• config-routing-options-access

• config-routing-options-aggregate

• config-routing-options-flow

• config-routing-options-generate

• config-routing-options-martians

• config-routing-options-rib-groups

• config-routing-options-rib

• config-routing-options-static

• config-sflow

• config-vpls

• config-rsvp

• config-vrrp

System-Level Templates

System-level configuration templates canbeappliedeither on thecontroller or satellites.

Inmost cases, because youmight treat the satellites as remote line-card chassis devices,

youmight need to configure the system-level configurations for the controller.

Theseconfiguration templatescontain theoptionaldeviceparameterand if theparameter

is not specified, the configurations are considered to be for the controller. If you specify

the device parameter to denote the satellite device for which you want to configure

settings, the configurations are forwarded and expanded on the specified satellite.

The following are the system-level templates supported in JNU port-extender mode:

• config-system-*



• config-poe

Firewall Templates

All Layer 3 firewall configurations are set up and expanded on the controller and the

Layer 2 firewall configurations are set up and expanded on the satellites. These

configuration templates do not contain the device parameter because if you configure

a Layer 3 firewall characteristic or attribute, the configuration is applied on the extended

aggregated Ethernet logical interface on the controller. Similarly, if you configure a Layer

2 firewall characteristic or attribute, the configuration is applied on the physical interface

on the satellite.

The following configuration templates pertain to Layer 2 and Layer 3 firewalls in JNU

port-extender mode:

• config-firewall-family

• config-firewall-filter

• config-firewall-hierarchical-policer

• config-firewall-interface-set

• config-firewall-policer

• config-firewall-three-color-policer

CoS Templates

All Layer3class-of-service (CoS)configurationsaresetupandexpandedon thecontroller

and the Layer 2 CoS configurations are set up and expanded on the satellites. These

configuration templates do not contain the device parameter because if you configure

a Layer 3 CoS characteristic or attribute, the configuration is applied on the extended

aggregated Ethernet logical interface on the controller. Similarly, if you configure a Layer

2 CoS characteristic or attribute, the configuration is applied on the physical interface

on the satellite.

The following configuration templates pertain to Layer 2 and Layer 3 CoS applications

in JNU port-extender mode:

• config-cos-classifiers

• config-cos-code-point-alias

• config-cos-congestion-notification-profile

• config-cos-drop-profiles

• config-cos-forwarding-class

• config-cos-fragmentation-maps

• config-cos-host-outbound-traffic

• config-cos-interfaces

• config-cos-loss-priority



• config-cos-restricted-queues

• config-cos-rewrite-rules

• config-cos-routing-instance

• config-cos-scheduler-maps

• config-cos-schedulers

• config-cos-traffic-control-profiles

• config-cos-translation-table









Processing of Free-Form Settings in JNU Port-Extender Mode

The config-free-form configuration template enables you to configure Junos OS set

statementson the satellitedevice. This template contains theoptionaldeviceparameter.

If youdonot specify thisparameterwith the config-free-formcommand, theconfiguration

is considered to be for the controller. If you specify the device parameter to denote the

satellitedevice forwhichyouwant toconfigure settings, theconfigurationsare forwarded

and expanded on the specified satellite.

The following example shows how to configure an attribute for a satellite, jnu-sat1, using

the config-free-form command with the device parameter specified:

user@controller> op config-free-form device jnu-sat1 command "setredundant-power-systemmember 0 priority 0"


• Extending a Satellite Interface to a Controller Overview on page 95









PART 4

MonitoringandTroubleshooting in the JNUNetwork

• Monitoring in the JNU Network on page 125

• Using the Junos OS CLI to Monitor and Manage Satellite Devices on page 133




CHAPTER 13

Monitoring in the JNU Network


• SNMP Get Process in the JNU Network on page 127

• SNMP Trap Process in the JNU Network on page 128

• System Logging in the JNU Network on page 129

• Network Time Protocol (NTP) in the JNU Network on page 130

• Configuring the JNU Controller as an SNMP Proxy Agent on page 131

Centralized Collection of SNMPStatistics and LogMessages Overview

The JNUsoftwareprovidesa singlepoint of collectingSNMPstatistics andsendingSNMP

traps to the SNMP server. You use the Junos OS SNMP proxy feature to set up the

controller asaproxySNMPagent throughwhich thenetworkmanagementsystem(NMS)

can query satellite devices.

The NMS polls the controller for SNMP statistics on both the controller and the satellite

devices. SNMP statistics from the satellite devices are routed through the controller. A

Network Address Translation (NAT) configuration set up by the controller initialization

process is used to translate the source address of the satellite devices to the source

address of the controller for traffic sent to the SNMP server. This process means that all

SNMP traffic originates from one source address on the controller.

SNMPCommunity Strings

Each satellite in the JNU group uses a different community string that is based on the

hostname assigned to the satellite during the initialization process. The format of the

string is controller-community-string.satellite-host-name. For example, if you configure

the read-only community string to be public, and the satellite hostname to be sat1, the

community string for the satellite is public:sat1.

Collecting LogMessages

The JNU software provides a single point of collecting logging messages and sending

them to the system log server. The controller sends all system logmessages for the JNU

group of satellites and controller to the server. The NAT configuration set up by the

controller initialization process is used to translate the source address of the satellite

devices to the source address of the controller for traffic sent to the system log server.


This process means that all logging traffic originates from one source address on the

controller.


Configuring the JNU Controller as an SNMP Proxy Agent on page 131•






SNMPGet Process in the JNUNetwork

Figure 7 on page 127 shows the SNMP Get process in the JNU network.

Figure 7: SNMPGet Process

g041

396

15

4

3 2

Controller acts asSNMP Proxy

NMS (SNMP server,SNMP trap server)

Management Plane

Satellites

Network interface

4—1— The controller receives the Get reply andprocesses it as an SNMP client.

SNMP server sends a Get request messageto the controller with the community stringfor a satellite.

5—2— Acting as an SNMP server, the controllerthen sends the Get reply message to theSNMP server.

The controller, acting as SNMP proxy,terminates the Get request from the SNMPserver. It then acts as an SNMP client, andsends the request to the appropriatesatellite.

3—The satellite sends a Get reply message tothe controller.


Centralized Collection of SNMP Statistics and Log Messages Overview on page 125•




Chapter 13: Monitoring in the JNU Network

SNMP Trap Process in the JNUNetwork

Figure 8 on page 128 shows the SNMP trap process in the JNU network.

Figure 8: SNMP Trap Process

g041

397

43

2

1 5

NMS(SNMP trap server)

Management Plane

Satellites

NAT isapplied

Network interface

4—1— For SNMPv3, the server responds to theinform request with an acknowledgmentthat it sends to the controller.

The satellite sends an SNMP trapnotification or inform request to thecontroller.

5—2— The controller sends the acknowledgmentto the satellite.

The controller applies NAT to the trapmessage so that themessage source is themanagement IP address of the controller.

3—The controller sends the trapmessage tothe SNMP server.








System Logging in the JNUNetwork

Each device in the JNU group, including the controller, originates its own system log

messages (called syslog messages). The hostname in messages sent from satellites

and the controller is the hostname configured during the JNU initialization process. The

syslog server uses the hostname to identify the JNU device that originated themessage.

Figure 9 on page 129 shows how logmessages are processed for JNU satellites.

Figure 9: System Logging Collection Process

g041

398

3

2

1

Syslog server

Management Plane

Satellites

NAT isapplied

Network interface

3—1— The controller sends the logmessage to thesyslog server.

The satellite sends a syslogmessage to thecontroller.

2—The controller applies NAT to the syslogmessage so that themessage source is themanagement IP address of the controller.







Network Time Protocol (NTP) in the JNUNetwork

When you initialize the controller, you can specify the address of an NTP server. If you do

so, the controller synchronizes its time to the external NTP server, and the controller then

acts as the NTP server for all the satellites in the JNU group. During satellite initialization,

JNU creates an NTP configuration that sets the NTP server address to the controller

downlink IP address.



Configuring the JNU Controller as an SNMPProxy Agent

You use the JunosOSSNMPproxy feature to set up the controller as a proxy SNMPagent

through which the network management system (NMS) can query satellite devices.

When the JNU controller acts as the proxy SNMPagent for the satellite devices, the NMS

specifies the community name (for SNMPv1 and SNMPv2) or the context and security

name (for SNMPv3) of the satellite fromwhich it requires the information. If you have

configured authentication and privacy methods and passwords for SNMPv3, those

parameters are also specified in the query for SNMPv3 information.

The community and security configuration for the proxy shouldmatch the corresponding

configuration on the satellite device that is to bemanaged.

If youconfigureSNMPwhenyou run thecontroller initializationprocess, the JNUsoftware

creates an SNMP proxy configuration with SNMPv2 support. For example:

proxy jnu-sat1 {device-name 192.168.0.2;version-v2c {snmp-community public:jnu-sat1;


}

Use this procedure if you need to add SNMPv3 support.

To configure the controller as an SNMP proxy agent:

1. Create a proxy configuration, and assign a name to the configuration.

user@jnu1-ctrlr# edit snmp proxy proxy-ctrlr

2. Assign the proxy configuration to a satellite device.

[edit snmp proxy proxy-ctrlr]user@jnu1-ctrlr# set device-name jnu-sat-1

3. (Optional)ConfigureSNMPversion3.Specifyasecuritynametobeused formessaging

security anduser access control. Specify the IDof theSNMPcontext that is accessible

to the SNMP proxy.

[edit snmp proxy proxy-ctrlr]user@jnu1-ctrlr# edit version-v3[edit snmp proxy proxy-ctrlr version-v3]user@jnu1-ctrlr# set security-name jnu-useruser@jnu1-ctrlr# set context jnu

NOTE: This security namemust match the security name configured atthe [edit snmp v3 target-parameters target-parameters-name parameters]

hierarchy level when you configure traps.



You can use the show snmp proxy operational mode command to view proxy details on

a device. The showsnmpproxy command returns the proxy names, device names, SNMP

version, community and security, and context information.







CHAPTER 14

Using the Junos OS CLI to Monitor andManage Satellite Devices

• Using the Junos OS CLI to Monitor and Manage Satellite Devices on page 133

• Changing the Order of Satellite Devices on page 133

Using the Junos OS CLI to Monitor andManage Satellite Devices

You can use Junos OS CLI set statements and commands, such as show, request, and

commit.

Displaying Active Satellite Configurations

op remote.op devices jnu1-sat1,jnu1-sat2 command “show configuration”

Displaying the Committed Satellite Configuration

op remote.op devices jnu1-sat1,jnu1-sat2 command “show configuration | displaycommit-scripts”

Changing the Order of Satellite Devices




PART 5

Upgrading Software in the JNU Network

• Upgrading Software in the JNU Network on page 137




CHAPTER 15

Upgrading Software in the JNU Network

• Upgrading Junos OS on Satellite Devices on page 137

• Upgrading JNU Software on Satellite Devices on page 138

• Upgrading JNU Software on Controllers on page 138

Upgrading Junos OS on Satellite Devices

You can upgrade the Junos OS on your satellite devices from the controller. Youmust

have a connection running from the controller to the satellite.

You need to upgrade the Junos OS directly on the satellite device. The procedure is as

follows:

1. Deactivate the JNU configuration.

If you are using JNU Release 1.1 or earlier, deactivate the jnu-module apply-group and

group:

[edit]user@jnu-satellite1# deactivate apply-groups jnu-moduleuser@jnu-satellite1# deactivate groups jnu-module

If you are using JNU Release 1.2, deactivate the jnu-satellite-mgmt group:

[edit]user@jnu-satellite1# deactivate apply-groups jnu-satellite-mgmtuser@jnu-satellite1# deactivate groups jnu-satellite-mgmt

2. Commit the changes.

[edit]user@jnu-satellite1# commit

3. Perform the Junos OS upgrade as you normally would.

4. Reinstall JNU.

user@jnu-satellite1> request system software add jnu-1.2R1.2-signed.tgz

Installing package '/var/tmp/jnu-1.2R1.2-signed.tgz' ...Verified jnu-1.2R1.2.tgz signed by PackageProduction_11_4_0 Adding jnu...Available space: 556676 require: 3220NOTICE: uncommitted changes have been saved in/var/db/config/juniper.conf.pre-installMounted jnu package on /dev/md10...


Restarting bslockd ...mgd: commit completeSaving package file in /var/sw/pkg/jnu-1.2R1.2-signed.tgz ...Saving state for rollback ...

5. Reactivate the JNU configuration.

If you are using JNU Release 1.1 or earlier, reactivate the jnu-module apply-group and

group:

[edit]user@jnu-satellite1# activate apply-groups jnu-moduleuser@jnu-satellite1# activate groups jnu-module

If you are using JNU Release 1.2, activate the jnu-satellite-mgmt apply-group and

group:

[edit]user@jnu-satellite1# activate apply-groups jnu-satellite-mgmtuser@jnu-satellite1# activate groups jnu-satellite-mgmt

6. Commit the changes.

[edit]user@host# commit

Upgrading JNU Software on Satellite Devices

Youmust remove the JNU configuration group before you attempt to upgrade the JNU

softwareonsatellitedevices.Also, youmusthaveaconnection running fromthecontroller

to the satellite.

To upgrade the JNU software on satellite devices from the controller:

1. Delete the JNU group from the satellite device onwhich youwant to upgrade the JNU

software

user@jnu-ctrlr> op jnu-remote device jnu1-sat3 command “request system deletejnu-satellite-mgmt”

2. Copy thesoftwarepackage to thesatellitedevice, and reboot thesatellite. For example,

you can use FTP to copy the software package:

user@jnu-ctrlr> op jnu-remote device jnu1-sat3 command “request system softwareadd ftp://hostname/pathname/package-name reboot”

software package has to be copied to satellite

Could use ftp:

request system delete jnu

op request system software add ftp://hostname/pathname/package-name

Upgrading JNU Software on Controllers

Youmust remove the JNU configuration group before you attempt to upgrade the JNU

software on the controller.



To upgrade the JNU software on the controller:

1. Delete the JNU group from the controller on which you want to upgrade the JNU

software

user@jnu-ctrlr> request system delete jnu-controller-mgmt

2. Copy the software package to the controller device, and reboot the controller. For

example, you can use FTP to copy the software package:

user@jnu-ctrlr> request system software addftp://hostname/pathname/package-name reboot


Chapter 15: Upgrading Software in the JNU Network



Documents

Designing and Implementing a Junos Node Unifier Network · 2013-07-17 · user@jnu1-ctrlr> opurl/var/db/scripts/op/jnu-initialize-controller.slax Controller initializations: