Junos® OS Designing and Implementing a Junos Node Unifier … · 2015-02-27 · Junos® OS Designing and Implementing a Junos Node Unifier Network ... Inc

Junos®OS

Designing and Implementing a JunosNodeUnifierNetwork

Release

1.4J1

Published: 2015-02-26

Copyright © 2015, Juniper Networks, Inc.

Juniper Networks, Inc.1133 InnovationWaySunnyvale, California 94089USA408-745-2000www.juniper.net

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.

Junos®OS Designing and Implementing Junos Node Unifier

Release 1.4J1Copyright © 2015, Juniper Networks, Inc.All rights reserved.

Revision HistoryJanuary 2015—J1 Junos Node Unifier 1.4

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 © 2015, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Initializing JNU Mode on the MX Series Controller . . . . . . . . . . . . . . . . . . . . . . . . . 32

Initializing the JNU Controller Without NAT Services . . . . . . . . . . . . . . . . . . . . . . . 36

iiiCopyright © 2015, Juniper Networks, Inc.

Initializing JNU Mode on the Satellite Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Avoiding Satellite Initialization Failures With EX4300 Switches . . . . . . . . . . . . . . 40

Adding a Satellite Device on the JNU Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Deleting a Satellite Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Replacing a Satellite Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Sample Initial Configuration on an MX Series Controller After Satellite

Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Sample Initial Configuration on an EX Series Ethernet Switch After Satellite

Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Deleting Configurations Related to a Specific Satellite Device from the JNU

Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Adding Hardware to a Functioning JNU System . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Modifying the Hostname of a Satellite After Initialization . . . . . . . . . . . . . . . . . . . 47

Chapter 8 JNU Port Extender Mode With Junos OS CLI Interface . . . . . . . . . . . . . . . . . . 51

JNU Port Extender Mode Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Configuring JNU Port-Extender By Using the Junos OS CLI Settings . . . . . . . 52

Configuring the Port Extender Interface Settings from the Junos OS CLI . . . . . . . 52

Generating the Configuration on the Controller and Satellites by Using the

Interface Alias Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

RestrictionsWhile Configuring a Satellite Interface to be Extended on a

Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Committing Configurations with Port-Extender Interfaces . . . . . . . . . . . . . . . . . . 56

Diagnosing Connectivity Failure Between the Controller and Satellites . . . . . . . . 56

Using SNMP and System Logs for Satellite Extended Interfaces . . . . . . . . . . . . . . 57

Assigning Aggregated Ethernet Interfaces Dynamically to Be Extended from

Satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

CoS Features on the Logical Interface Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 58

VLAN-ID List Support on Port-Extender Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 58

RSTP and VSTP Support on Port-Extender Interfaces . . . . . . . . . . . . . . . . . . . . . 58

RSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

VSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

SNMP Scaling Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Processing of High Capacity Counters by JNU SNMP Scripts . . . . . . . . . . . . . 62

Configuring the Proxy SNMP Agent on JNU Satellites . . . . . . . . . . . . . . . . . . . . . . 62

Optimizing Configuration Commits on Satellites . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Logging JNU Trace Messages to a Dedicated File . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Event Script Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Restricting the Number of Downlink Interfaces on the Controller . . . . . . . . . . . . . 66

Specifying Aggregated Ethernet Interface Ranges for Controller Downlinks . . . . . 67

Disabling of Automatic Deletion of Satellites from a Controller Due to

Unreachability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Restoring the Initial Connectivity Settings for the Replaced Satellite . . . . . . . 71

Mechanism to Propagate Generic Configuration Settings to Satellites . . . . . . . . . 72

Copyright © 2015, Juniper Networks, Inc.iv

JNU Release 1.4J1 Design and Implementation Guide

input-vlan-map and output-vlan-map Configuration on Port-Extender

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Configuring Port-Extender Functionalities and Protocols . . . . . . . . . . . . . . . . . . . 74

Using Q-in-Q Tunneling and S-VLAN IDs for Satellite Extended

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

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

Configuring Layer 3 Features on Port-Extender Interfaces . . . . . . . . . . . . . . . 78

Configuring Layer 2 Bridge Domains on Port-Extender Interfaces . . . . . . . . . 79

Configuring Port Extender Interface Features Directly on the Satellites . . . . . . . . 79

CoS Features on Logical Interface Extension . . . . . . . . . . . . . . . . . . . . . . . . . 80

CoS Features on Physical Interface Extension . . . . . . . . . . . . . . . . . . . . . . . . 80

Firewall Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

MTU Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Service VLAN ID Removal for Layer 2 VPNs and Circuits . . . . . . . . . . . . . . . . 82

CoS Rewrite Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Operations of the Commit Script with Port Extender Interfaces from the Junos

OS CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Monitoring the Satellite Interfaces Extended on the Controller . . . . . . . . . . . . . . . 84

Chapter 9 JNUOperational Mode Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

show chassis hardware jnu device all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

show interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

show port-extenders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

show satellites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

show version jnu device all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

request-jnu-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Part 4 Upgrading Software in the JNU Network

Chapter 10 Upgrading Software in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Upgrading Junos OS on Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Upgrading Junos OS on Satellite Devices From the Controller . . . . . . . . . . . . . . . 102

Upgrading JNU Software on Satellite Devices From the Controller . . . . . . . . . . . 106

Upgrading Junos OS on the JNU Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Upgrading JNU Software on Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Upgrading JNU Software on Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Part 5 Monitoring and Troubleshooting in the JNU Network

Chapter 11 Monitoring in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

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

SNMP Community Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Collecting Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

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

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

System Logging in the JNU Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

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

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

vCopyright © 2015, Juniper Networks, Inc.

Table of Contents

Copyright © 2015, 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 © 2015, Juniper Networks, Inc.

Copyright © 2015, 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•





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 (JunosOS), such as EXSeries Ethernet switches and

QFXSeries devices. See “PlatformConsiderations for the JNUController” on page 15 and

“Supported Platforms for JNU Satellite Devices” on page 15 for a list of devices that JNU

Release 1.4J1 supports as controllers and satellites respectively.

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.

• 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 MX Series Controller on page 32

• Initializing JNUMode on the Satellite Device on page 37

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

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 the MX240, MX480, and MX960MX2010, and MX2020 3D Universal Edge

Router as the JNU controller. The MX Series 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 MX480 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.4J1 supports the following satellite devices:

• EX3200 Ethernet Switch






• QFX 3500 devices

• QFX 5100 devices



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

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


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.


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

• JNU Port Extender ModeWith Junos OS CLI Interface on page 51

• JNU Operational Mode Commands on page 89




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 31


• Initializing the JNU Controller Without NAT Services on page 36


• Avoiding Satellite Initialization FailuresWith EX4300 Switches on page 40

• Adding a Satellite Device on the JNU Controller on page 40

• Deleting a Satellite Device on page 41

• Replacing a Satellite Device on page 41

• Sample Initial Configuration on an MX Series Controller After Satellite

Initialization on page 42

• Sample Initial Configuration on an EX Series Ethernet Switch After Satellite

Initialization on page 44

• Deleting Configurations Related to a Specific Satellite Device from the JNU

Controller on page 46

• Adding Hardware to a Functioning JNU System on page 47

• Modifying the Hostname of a Satellite After Initialization on page 47

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.4J1.7-signed.tgzInstalling package '/var/tmp/jnu-1.4J1.7-signed.tgz' ...Verified jnu-1.4J1.7.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.4J1.7-signed.tgz ...Saving state for rollback ...



Initializing JNUMode on the MX Series Controller on page 32•





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.4J1.7-signed.tgzInstalling package '/var/tmp/jnu-1.4J1.7-signed.tgz' ...Verified jnu-1.4J1.7.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.4J1.7-signed.tgz ...Saving state for rollback ...


Installing the JNU Software on the Controller on page 29•




Chapter 7: Getting Started with the JNU Software

Initializing JNUMode on theMX Series Controller

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 includes interfaces, internal routing-instances, virtual

switch bridging, SNMP, system logs, and NTP in the main instance of the configuration.

You can configure NAT when required.

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 by using the jnuadmin user account.

To initially configure the controller:

1. Enter the request jnu controller command.

user@jnu1-ctrlr> request jnu controllerInitializing Controller...

JNU Controller configuration completed

JNUmode is enabled on the device, which starts to function as the controller. The

following is anexampleof theconfigurationcreatedon thecontroller asa result of running

the controller initialization process.

groups {jnu-controller-mgmt {apply-macro pem;chassis {aggregated-devices {ethernet {device-count 255;

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

}}

}}services {nat {pool controller-management-ip {address 192.168.164.164/32;



}}

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

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

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

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

}}unit 0 {family inet {address 192.168.0.1/24;

}}

}xe-0/0/0 {encapsulation ethernet-bridge;unit 0;

}xe-0/0/1 {encapsulation ethernet-bridge;unit 0;

}...xe-0/2/0 {encapsulation ethernet-bridge;unit 0;

}ge-1/0/0 {encapsulation ethernet-bridge;unit 0;

}ge-1/0/1 {encapsulation ethernet-bridge;unit 0;

}event-options {max-policies 20;generate-event {event-script-timer time-interval 300;lldp-script-timer time-interval 130;



}policy jnu-satellite-connectivity {events event-script-timer;then {event-script monitor-satellites.slax;

}}policy JNU-LLDP-Connectivity {events lldp-script-timer;then {event-script monitor-lldp-script.slax;

}}event-script {file monitor-satellites.slax;file monitor-lldp-script.slax;

}}protocols {lldp {interface all;

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

}}routing-instances {jnu-vrf {instance-type vrf;system {services {dhcp-local-server {group dhcp {interface irb.0;

}}

}}access {address-assignment {pool jnu_v4_pool {family inet {network 192.169.0.0/24;range 1 {low 192.169.0.2;high 192.169.0.254;

}}

}}

}interface si-1/0/0.1;interface irb.16385;route-distinguisher 192.168.0.1:0;



vrf-import reject-all;vrf-export reject-all;

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

}jnu1 {vlan-id none;interface xe-0/0/0.0;interface xe-0/0/1.0;...interface xe-0/2/0.0interface ge-1/0/0.0;interface ge-1/0/1.0;routing-interface irb.0;

}}

}}

}jnu-module {system {scripts {commit {allow-transients;file config-port-extender-commit.slax;

}op {file jnu-show-port-extender.slax;file jnu-port-extender-command.slax;file jnu-add-delete-downlink.slax;file config-free-form-pem.slax {command config-free-form;

}file jnu-initialize-controller.slax;file jnu-show-satellites.slax;file jnu-show-configuration.slax;file jnu-remote.slax;file jnu-rollback.slax;file jnu-order-satellites.slax;file jnu-add-delete-satellites.slax;file config-free-form-precommit.slax;file jnu-delete-satellite.slax;

}snmp jnu-snmp.slax {oid .1.3.6.1.4.1.2636.3.1.13.1.89;

}}

}}

}}




request-jnu-controller on page 98•

• Installing the JNU Software on the Controller on page 29


Initializing the JNU ControllerWithout NAT Services

A network address translation (NAT) configuration set up by the controller initialization

process is used to translate the source address of the traffic sent to the SNMP or system

logging server so thatall networkmanagement traffic fromthesatellitedevicesoriginates

from a source address on the controller. On devices where inline-services NAT cannot

be used, you can specify that NAT is not needed for JNU deployment with the following

command:

user@jnu-ctrlr> request jnu controller no-nat

When no-nat is enabled, the source address of the traffic sent to the SNMP or syslog

server originates directly on the satellite.

NOTE: When you initialize the controller with the no-nat option, you need to

ensure that theconfiguredsyslogserver is reachable through theVPNroutingand forwarding (VRF) routing instance.

The services using NAT are system logging applications and SNMP traps, and only in the

direction from the satellites (routed through the controller) to the syslog and SNMP trap

servers. When you specify that NAT is not is not enabled, the syslog server and SNMP

traps must use controller source address to originate directly on the satellite. (For JNU

1.3Jx releases, SNMP traps are achieved by using a satellite event-script that sends the

SNMP traps directly on the controller; therefore, the SNMP traps functionality is not

needed for the 1.3Jx releases.)

The following is the effective configuration generated on the satellite:

system { syslog { source-address <mgmt-addr-of-controller>; }}

Themanagement address of the controller is determined using the following sequence:

1. If the source address is defined in the syslog settings on the controller, the specified

source address must be used in the corresponding service on the satellite.

2. If the source address is not defined on the controller and if the address of the

management interface, fxp0.0, is configured, the IP address of the fxp0.0 interface

is used.

3. If the address of the fxp0.0 interface is not configured, the IP address of the loopback

interface. lo0.0, is used.



The rest of the configurations at the [edit system syslog] level are duplicated from the

controller to the satellites. Because NAT is not needed, the following configurations are

not required to be initialized in the jnu-controller-mgmt group:

• Inline services (si-) interfaces services service-set

• Services and service sets associated with NAT

• Parameters at the [edit chassis fpc slot-number inline-services] hierarchy level.

Initializing JNUMode on the Satellite Device

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.

To initialize a satellite device:

1. Enter the following command on the satellite device.

user@jnu-satellite1> request jnu satelliteInitializing Satellite...

Commit Completed

JNU Satellite configuration completed

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

running the satellite initialization process.

groups {jnu-satellite-mgmt {system {ntp {server 192.168.0.1;

}}chassis {aggregated-devices {ethernet {device-count 31;

}}

}security {ssh-known-hosts {host 192.169.0.1 {ecdsa-sha2-nistp256-key

"AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNn6OCxqurMlNxK3G08p



CfHEEYMK7k6IBO4csN0M58yo\nw06u+TBk3QtRkjKNzj18Py1Mx48Ml7GcfrC0mAjoTrc=";

}}

}interfaces {ae0 {aggregated-ether-options {lacp {active;

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

}}

}}

}protocols {lldp {port-id-subtype interface-name;interface all;

}}ethernet-switching-options {dot1q-tunneling {ether-type 0x8100;

}}vlans {jnu {vlan-id 4094;

}}

}jnu-module {system {scripts {commit {allow-transients;

}op {file jnu-initialize-satellite.slax;file config-free-form-precommit.slax;

}}

}}

}apply-groups [ jnu-module jnu-satellite-mgmt ];system {autoinstallation {



traceoptions {file autod;level all;flag {all;

}}interfaces {ge-* {bootp;

}xe-* {bootp;

}}

}ports {console log-out-on-disconnect;

}root-authentication {encrypted-password "$1$CSJA9A09$sdnsPhaXKxChqcgPB4HUT0"; ##

SECRET-DATA}login {user jnuadmin {uid 928;class super-user;shell csh;authentication {encrypted-password "$1$a7DYfEN0$huf8FDLIshFB5v6zb2WMz0"; ##

SECRET-DATA}

}}services {ftp;ssh;telnet;

}}interfaces {me0 { /* satellite management interface */unit 0 {family inet {address /* satellite management address */

}}

}}

After satellite initialization, LLDPneighborship is establishedbetween thesatellitedevice

and the controller. The connected interfaces are automatically added to bring up an

active aggregated Ethernet link across the satellite device and the controller.



Avoiding Satellite Initialization FailuresWith EX4300 Switches

Starting with JNU 1.3J4, youmust perform the following steps on EX4300 switches that

are configured as satellites and connected to a controller to prevent initialization failures:

1. Verify if any uncommitted configuration changes exist on the EX4300 satellite. If so,

ensure that all pending changes are committed.

2. Make sure that one or more links are connected to the controller from the EX4300

switch that is a satellite.

3. Make sure that a valid JunosOS software image and the latest JNU software package

are installed on the EX4300 switch.

4. Enter the request jnu satellite operationalmode command to enable the JNU satellite

mode.

5. After approximately 4-5 minutes, the uplink connection from the satellite to the

controller is added to the aggregated Ethernet interface and is committed along with

the related configuration configured by the LLDP scripts from the controller. In the

satellite configuration downloaded from the controller, LLDP is enabled on all the

interfaces. The JNUapplication inspects theLLDPneighborsand identifies thephysical

links connecting to the controller. These links are grouped into an AE bundle as the

uplink interface from the satellite to the controller and the AE interface is set up as

soon as the satellite is initialized.

Adding a Satellite Device on the JNU Controller

To add a satellite device on the controller:

1. Initialize the JNU controller.



2. Load the JNU software on the satellite device to be added.

user@jnu-satellite1> request system software add jnu-1.4J1.7-signed.tgzInstalling package '/var/tmp/jnu-1.4J1.7-signed.tgz' ...Verified jnu-1.4J1.7.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.4J1.7-signed.tgz ...Saving state for rollback ...

3. Initialize the satellite device.



user@jnu-satellite1> request jnu satelliteInitializing Satellite...

Commit Completed

JNU Satellite configuration completed





Deleting a Satellite Device

To delete a satellite device on the JNU controller:

• Enter the following command on the JNU controller:

user@jnu1-ctrlr> request jnu delete satellite Satellite1





Replacing a Satellite Device

You can replace a satellite device on the JNU controller with a new satellite device. The

new satellite device should have the same name as the satellite device to be replaced.

To replace a satellite device:

1. Enter the following command on the new satellite device:

user@jnu-satellite1> request jnu satellite restore uplink uplink-to-controller addressjnu-satellite-management-address

You can specify a list of comma-separated uplink interface names of a satellite with

the request jnu satellitel restore uplink command. For example, to replace a set of

uplink interfaces of a satellite, you can use the following command:

user@jnu-satellite1> request jnu satellite restore uplinkxe-0/2/0,xe-0/2/1,xe-0/2/2,xe-0/2/3 address 192.168.55.53

2. Enter the following command on the JNU controller to synchronize the configuration

from the controller, after the satellite is restored with the uplink interfaces and JNU

management IP address:

user@jnu-ctrlr> request jnu commit-synchronize satellite satellite1



Sample Initial Configuration on anMX Series Controller After Satellite Initialization

The following is an example of the configuration that is configured MX series controller

during the satellite initialization process.

groups {jnu-controller-mgmt {apply-macro pem;apply-macro satellite-link-details {jnu-satellite1:xe-0/1/0 xe-0/1/0;

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

}}nat {pool jnu-jnu-satellite1 {address 192.168.164.164/32;

}allow-overlapping-nat-pools;rule jnu-use-controller {match-direction input;term term-jnu-satellite1 {from {source-address {192.168.0.2/32;

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

}}

}}

}}


AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNn6OCxqurMlNxK3G08pCfHEEYMK7k6IBO4csN0M58yow06u+TBk3QtRkjKNzj18Py1Mx48Ml7GcfrC0mAjoTrc=;

}}

}



interfaces {xe-0/1/0 {description "Connected to Satellite - jnu-satellite1";gigether-options {802.3ad ae0;

}}ae0 {flexible-vlan-tagging;encapsulation flexible-ethernet-services;aggregated-ether-options {lacp {active;

}}unit 16385 {encapsulation vlan-bridge;vlan-id 4094;

}}

}routing-instances {jnu-vs {bridge-domains {jnu {interface ae0.16385;

}}

}}

}jnu-satellites {system {static-host-mapping {jnu-satellite1 inet 192.168.0.2;

}}

}jnu-satellite1 {apply-macro pe-svlans {ssvlan 1;ssvlan-single 1;

}}



}}

}



Sample InitialConfigurationonanEXSeriesEthernetSwitchAfterSatellite Initialization

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

EX Series Ethernet Switch satellite device during the initialization process.

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

}}

}security {

host 192.168.0.1 {ecdsa-sha2-nistp256-key


}}

}interfaces {xe-0/1/0 {ether-options {802.3ad ae0;

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

}}

}lo0 {unit 0 {family inet {address 192.168.0.2/32;

}}

}}event-options {policy monitor-port-extenders {events [ snmp_trap_link_up snmp_trap_link_down ];then {event-script monitor-port-extenders-ex4200.slax {arguments {cntrlr-ip 192.168.0.1;

}}

}}



event-script {file monitor-port-extenders-ex4200.slax;

}}routing-options {static {rib-group ntp;

}rib-groups {ntp {import-rib [ inet.0 jnu.inet.0 ];import-policy jnu-mgmt;

}JNU {import-rib [ jnu.inet.0 inet.0 ];import-policy jnu-rib;

}}

}policy-options {policy-statement jnu-mgmt {from protocol static;then accept;

}policy-statement reject-all {then reject;

}policy-statement jnu-rib {term direct-local {from protocol [ direct local ];then accept;

}}

}routing-instances {jnu {instance-type vrf;interface vlan.4094;route-distinguisher 192.168.0.2:0;vrf-import reject-all;vrf-export reject-all;routing-options {interface-routes {rib-group inet JNU;

}static {rib-group JNU;route 0.0.0.0/0 next-hop 192.168.0.1;

}}

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

}



}}jnu-module {system {scripts {commit {file config-master-pem-commit-ex4200.slax;

}}

}}

}system {autoinstallation {interfaces {xe-0/1/2 {bootp;

}ge-0/0/0 {bootp;

}ge-0/0/1 {bootp;

}ge-0/0/2 {bootp;

}....}

}}


Sample Initial Configuration on an ACX Universal Access Router•

• Sample Initial Configuration for an EX Series Switch

Deleting Configurations Related to a Specific Satellite Device from the JNUController

When you remove a specific satellite device from the JNU controller, manually deleting

all configurations related to that satellite device from the JNU controller is a tedious

process. You can use the jnu-delete-satellite.slax op script to delete all satellite

device–specific configuration from the JNU controller. For example:

• This example shows how to delete a single configuration related to a satellite device

from the JNU controller:

user@jnu1-ctrlr> op jnu-delete-satellite satellite sat01

• This example shows how to deletemultiple configurations related to a satellite device

from the JNU controller:

user@jnu1-ctrlr> op jnu-delete-satellite satellite sat01 downlink xe-0/1/0,xe-0/0/1



NOTE: Starting with JNU Release 1.3J3, you need to explicitly commit theconfiguration change after you delete all configurations related to a specificsatellite device from the JNU controller.





Adding Hardware to a Functioning JNU System

When you add hardware, such as an interface or an FPC, to a JNU system that is in

operation, the JNU system does not recognize the newly added device by default. To

enable the JNU system to recognize and use the new hardware, use the

jnu-add-delete-downlink.slax op script.

• This example shows how to add a single interface to a JNU system:

user@jnu1-ctrlr> op jnu-add-delete-downlink action set downlinks ge-0/0/0

• This example shows how to addmultiple interfaces to a JNU system:

user@jnu1-ctrlr> op jnu-add-delete-downlink action set downlinksge-0/0/0,ge-0/0/1,ge-0/0/2

• This example shows how to add an FPC to a JNU system:

user@jnu1-ctrlr> op jnu-add-delete-downlink action set fpc 1

Modifying the Hostname of a Satellite After Initialization

In certain network environments, youmight require the hostnames of satellites that are

initializedandconnectedwithacontroller tobemodified.Achangeofasatellitehostname

might be necessary for its easy and effective identification in the logging messages,

output of commands, and configuration scripts.

To change the hostname of a satellite, perform the following steps:

1. Disable the communicationbetween the controller and the satellitewhosehostname

you want to modify. You need to enter this statement only on the controller.

user@jnu-ctrlr# set groups jnu-controller-mgmt interfaces aeX disable

Youcanuse theoutputof the showlldpneighborscommandto identify theAE interface

that is usedas thedownlink interface from the controller to the satellite. The following

is a sample output of the show command:

user@jnu-ctrlr# run show lldp neighbors

Local Interface Parent Interface Chassis Id Port info System Namexe-0/3/3 - 00:19:e2:54:2e:40 xe-0/1/0 CE1-SAT2 xe-1/3/3 - 00:19:e2:54:2e:40 xe-0/1/1 CE1-SAT2 xe-0/2/2 ae150 4c:96:14:f0:c6:60 xe-0/2/0 ce1-sat1 xe-0/3/2 ae150 4c:96:14:f0:c6:60 xe-0/2/1 ce1-sat1



xe-1/0/3 ae150 4c:96:14:f0:c6:60 xe-0/2/2 ce1-sat1 xe-1/3/2 ae150 4c:96:14:f0:c6:60 xe-0/2/3 ce1-sat1

In this example, ae150 is the downlink interface to the satellite. In this case, youmust

enter the following statement to disable the communication between the satellite

and the controller.

user@jnu-ctrlr# set groups jnu-controller-mgmt interfaces ae150 disable

2. Commit the changes.

user@jnu-ctlr# commitMessage from syslogd@user@jnu-ctrlr at Feb 9 19:32:45 ...user@jnu-ctrlr cscript: ce1-sat1:

Message from syslogd@user@jnu-ctrlr at Feb 9 19:32:45 ...user@jnu-ctrlr cscript: No changes in the Configuration group. So, not pushing itre0:configuration check succeedsre1:commit completere0:commit complete

3. Verify the state of the satellite.

user@jnu-ctrlr# run show satellitesSatellite-System State Address Model Version Downlinks

ce1-sat1 Down 192.168.232.123 ex4300-48t 13.2X51-D27.2

4. Replace the old hostname of the satellite with the new hostname. Youmust enter

this command on both the controller and the satellite. You canmake global changes

to variables and identifiers in a Junos configuration by using the replace configuration

mode command. This command replaces a pattern in a configuration with another

pattern. For example, you can use this command to find and replace all occurrences

of hostname.

user@host# replace pattern pattern1with pattern2

where pattern1 is a text string or regular expression that defines the identifiers and

values you want to replace in the configuration and pattern2 is a text string or regular

expression that replaces the identifiers and values located with pattern1.

In this example, you are replacing the hostname, ce1-sat1, as ce2-sat1, and committing

the changes on both the controller and satellite.

user@jnu-ctlr# replace pattern ce1-sat1 with ce2-sat1user@jnu-ctlr# commitMessage from syslogd@user@jnu-ctrlr at Feb 9 19:34:58 ...user@jnu-ctrlr cscript: ce1-sat1:

Message from syslogd@user@jnu-ctrlr at Feb 9 19:34:58 ...user@jnu-ctrlr cscript: Deleting the JNU Configuration

Message from syslogd@user@jnu-ctrlr at Feb 9 19:34:58 ...user@jnu-ctrlr cscript: Ping Failure: Satellite Box not reachable



Message from syslogd@user@jnu-ctrlr at Feb 9 19:34:59 ...user@jnu-ctrlr cscript: ce2-sat1:

Message from syslogd@user@jnu-ctrlr at Feb 9 19:34:59 ...user@jnu-ctrlr cscript: Ping Failure: Satellite not reachable

Message from syslogd@user@jnu-ctrlr at Feb 9 19:34:59 ...user@jnu-ctrlr cscript: Ping Failure: Satellite 'ce2-sat1' not reachablere0:configuration check succeedsre1:commit completere0:commit complete

5. Reestablish the communication between the controller and the satellite by entering

the following statement on the controller.

user@jnu-ctrlr@ delete groups jnu-controller-mgmt interfaces aeX disableuser@jnu-ctrlr@ commit

In this example, ae150 is the downlink interface that needs to be established for

communication with the satellite.

user@jnu-ctrlr# delete groups jnu-controller-mgmt interfaces ae150 disableuser@jnu-ctrlr# commitMessage from syslogd@jnu-ctrlr at Feb 9 19:35:42 ...jnu-ctrlr cscript: ce2-sat1:

Message from syslogd@jnu-ctrlr at Feb 9 19:35:42 ...jnu-ctrlr cscript: Ping Failure: Satellite not reachable

Message from syslogd@jnu-ctrlr at Feb 9 19:35:42 ...jnu-ctrlr cscript: Ping Failure: Satellite 'ce2-sat1' not reachablere0:configuration check succeedsre1:commit completere0:commit complete

6. You can use the show satellites command to display the state of each satellite to

determine if the satellite is up and connected to the controller.

user@jnu-ctrlr# run show satellitesSatellite-System State Address Model Version Downlinks

ce2-sat1 Up 192.168.232.123 ex4300-48t 13.2X51-D27.2xe-0/2/2

xe-0/3/2

xe-1/0/3

xe-1/3/2





CHAPTER 8

JNU Port Extender ModeWith Junos OSCLI Interface

• JNU Port Extender Mode Overview on page 52

• Configuring the Port Extender Interface Settings from the Junos OS CLI on page 52

• Generating the Configuration on the Controller and Satellites by Using the Interface

Alias Name on page 54

• Committing Configurations with Port-Extender Interfaces on page 56

• Diagnosing Connectivity Failure Between the Controller and Satellites on page 56

• Using SNMP and System Logs for Satellite Extended Interfaces on page 57

• Assigning Aggregated Ethernet Interfaces Dynamically to Be Extended from

Satellites on page 58

• CoS Features on the Logical Interface Extension on page 58

• VLAN-ID List Support on Port-Extender Interfaces on page 58

• RSTP and VSTP Support on Port-Extender Interfaces on page 58

• SNMP Scaling Enhancements on page 61

• Configuring the Proxy SNMP Agent on JNU Satellites on page 62

• Optimizing Configuration Commits on Satellites on page 65

• Logging JNU Trace Messages to a Dedicated File on page 66

• Event Script Optimization on page 66

• Restricting the Number of Downlink Interfaces on the Controller on page 66

• Specifying Aggregated Ethernet Interface Ranges for Controller Downlinks on page 67

• Disabling of Automatic Deletion of Satellites from a Controller Due to

Unreachability on page 71

• Mechanism to Propagate Generic Configuration Settings to Satellites on page 72

• input-vlan-map and output-vlan-map Configuration on Port-Extender

Interfaces on page 73

• Configuring Port-Extender Functionalities and Protocols on page 74

• Configuring Port Extender Interface Features Directly on the Satellites on page 79


• Operations of the Commit Script with Port Extender Interfaces from the Junos OS

CLI on page 83

• Monitoring the Satellite Interfaces Extended on the Controller on page 84

JNU Port Extender Mode Overview

To provide a robust, cohesive method of managing satellites, the JNU controller and

satellite devices operate in 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.

Configuring JNU Port-Extender By Using the Junos OS CLI Settings

Startingwith JNURelease 1.3J1, youcanuse theembedded, in-built JunosOSCLI interface

as the mechanism to enable the JNU application on controller and satellites, and also

to activate port-extender mode on these devices. By using the Junos OS configuration

statementsat thecorrespondinghierarchy levels, youcanconfigureport-extender features

and interfaces in the samemanner in which you configure other types of interfaces or

applications on a device running Junos OS. In this release, only the port-extender mode

ofoperation is supportedandthe feature-richornon-port-extendermode isnotsupported.


Configuring the Port Extender Interface Settings from the Junos OS CLI on page 52•

Configuring the Port Extender Interface Settings from the Junos OS CLI

You can configure a satellite interface to function as the extended interface and host it

on a controller by using the port-extender statement at the [edit interfaces] hierarchy

level. You can also define the attributes of the satellite extended interface by using the

options available at the [edit interfaces port-extender interface-name] hierarchy level.

NOTE: Youmust not disable the downlink connection to the satellite fromthe controller by using the set interfaces port-extender

satellite-name:interface-name disable statement. Otherwise, the controller

loses the ability to control, manage, and provision settings on the satellite.



The following configuration illustrates the attributes and settings that you can configure

at the [edit interfaces] hierarchy level for port-extender interfaces:

interfaces {port-extender {sat1:ge-0/0/10 {description "JNU port extender";disable;traps;hold-time up 1000 down 1000;no-gratuitous-arp-reply;no-gratuitous-arp-request;optics-options {alarm low-light-alarm {syslog;

}}ether-options {loopback;auto-negotiation;flow-control;link-mode automatic;

speed {1g;

}}mtu 4000;vlan-tagging;unit 0 {vlan-id 101; /* vlan-id 0means untagged */family inet {address 10.10.0.2/30;

}}

}}

}

The following configuration illustrates the attributes and settings that you can configure

at the [edit interfaces] hierarchy level for aggregated Ethernet port-extender interfaces:

interfaces {port-extender {sat1:ge-0/0/0 {ether-options {802.1ad ae1;

}}

sat1:ge-0/0/1 {ether-options {802.1ad ae1;

}}sat1:ae1 {aggregated-ether-options {lacp {


Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface

active;}}vlan-tagging;unit 0 {vlan-id 2001;family inet {address 137.0.0.1/30;

}}

}}

}

For JNU Release 1.4J1, only the following physical interface statements or options are

supported for the satellite interfaces that are extended on the controller:

• disable

• ether-options (for EX Series switches and QFX Series devices)

• aggregated-ether-options (for EX Series Switches and QFX series devices)

• mtu <mtu>

• description

• gratuitous-arp-reply

• hold-time

• no-gratuitous-arp-reply

• no-gratuitous-arp-request

• no-traps optics-options

• traps


JNU Port Extender Mode Overview on page 52•

Generating the Configuration on the Controller and Satellites by Using the InterfaceAlias Name

The JNU application expands the port-extender configuration on both the controller and

satellite devices. The JNU application identifies the interface-alias configuration and

creates the effective configuration on the controller and satellite, which involves the

following operations:

• Create the 802.1q-tunneling configuration for the satellite by assigning the service

VLAN for port-extension.

• Create the port-extender name in the

satellite-name:physical-interface-name.logical-unit-number format as the

interface-alias name.



• Configure the logical interfaceon thecontroller downlinkaggregatedEthernet interface

to contain the port-extender interface.

• Transfer the port-extender configurations to the logical interface on the controller that

hosts the satellite extended interface.

• The port-extender physical interface configurations are forwarded from the controller

to the physical interface of the satellite.

The following is an example of the configuration generated on a controller:

interfaces {ae479 {flexible-vlan-tagging;unit 21 {interface-alias "sat1:ge-0/0/0.88";vlan-tags outer 1001 inner 100;family inet {address 1.1.1.1/30;

}}

}}

The following is an example of the configuration generated on a satellite:

ethernet-switching-options {dot1q-tunneling {ether-type 0x8100;

}}interfaces {ge-0/0/0 {unit 0 {family ethernet-switching;

}}vlans {jnu-port-extender-vlan1001 {vlan-id 1001;interface {ge-0/0/0.0;

}dot1q-tunneling {customer-vlans 100;

}}

}}

RestrictionsWhile Configuring a Satellite Interface to be Extended on a Controller

The following limitations and conditions apply, when you configure a satellite interface

to be extended and residing on a controller:



• Because flexible VLAN tagging and service VLAN ID parameters are generated by the

JNU process, you cannotmodify those configurations on the downlink interface to the

satellite.

• You cannot configure vlan-tagging or stacked-vlan-tagging statements on the physical

interface.

• You cannot modify the VLAN tags for the port extender logical interface on the

controller.

• The outer tags used to perform tunneling for the satellite ports are uniquewithin a JNU

group (a number in the range 1 - 4093) regardless of the satellites.

• The outer S-VLAN tags used for tunneling traffic for the satellite ports can be reused

in other bridge-domains on the controller for interfaces that are not connected or

related to the extended satellite ports.

Committing Configurations with Port-Extender Interfaces

The JNU application performs a validation of the defined settings when you attempt to

commit a configuration with port-extender attributes. For example, the system verifies

whether the interface-alias name follows the format that is defined for theport-extender

interface name syntax, such as <satellite-name>:<physical-interface>.<vlan-id>. The

JNU process on the controller generates controller and satellite configurations. The JNU

process propagates the satellite-specific configuration to the corresponding satellite

device after performing a commit check operation.

If all the satellites approve the new configuration, the JNU process examines the result

of the commit-check operation on the controller. If the controller and all satellites mark

the newconfiguration as valid, the newconfiguration is activated.Otherwise, the commit

process is canceled. The controller forwards only the portion of the configuration that

has beenmodified from the previously committed configuration to the satellites.

Diagnosing Connectivity Failure Between the Controller and Satellites

On the satellite, when at least one port is extended from the satellite to the controller,

protocolsuplink-failure-detection is automatically configuredon the JNUdevice tomonitor

the JNU link between the controller and the satellite. If the link fails, all the extended

ports are disabled by uplink-failure-detection.

For example, if ports ge-0/0/0 and ge-0/0/2 are extended from the satellite to the

controller, and the uplink on the satellite is ae0, the uplink-failure-detection effective on

the satellite:

protocols {uplink-failure-detection {group jnu-port-extender {link-to-monitor {ae0;

}link-to-disable {ge-0/0/9;



}}

}}

Using SNMP and System Logs for Satellite Extended Interfaces

After the satellite interfacesare extended fromthe satellites to the controller, thenetwork

management system (NMS) can query the interface statistics of the satellite

port-extender by querying the controller, because the port-extender interface is now

anchored on the controller and becomes a first-class logical interface on the controller.

The SNMP functionality on the controller is augmented to store information about the

satellites. This is achieved by implementing JNU SNMPOIDs in the Juniper Networks

Enterprise MIB (1.3.6.1.4.1.2636). The additional information available in the newMIBs:

satellite-specific information:

- satellite name- satellite OS version- satellite JNU IP address- satellite JNU management IP address

In addition, the normal MIBs are managed by SNMP servers.

satellite: chassis environment information physical interface statistics

NMS> snmpwalk -v2 -community public -host controller-fxp0 -oid enterprise.jnu1.3.6.1.4.1.2636.3.1.13.1.89.1.1.192.168.0.2 = 192.168.0.21.3.6.1.4.1.2636.3.1.13.1.89.1.1.192.168.0.3 = 192.168.0.31.3.6.1.4.1.2636.3.1.13.1.89.1.2.192.168.0.2 = sat-ex4200-11.3.6.1.4.1.2636.3.1.13.1.89.1.2.192.168.0.3 = sat-qfx3500-11.3.6.1.4.1.2636.3.1.13.1.89.1.3.192.168.0.2 = ex4200-24f1.3.6.1.4.1.2636.3.1.13.1.89.1.3.192.168.0.3 = qfx3500 ....

Only the values that are contained in the actual Junos OS Chassis MIB and InterfaceMIB

are populated because those are the values regularlymanaged by NMS that administers

devices running Junos OS.

An event script runs on the satellite and each satellite configures the event-options

settings to monitor the SNMP trap events that are sent for chassis and interface events.

The satellite uses the enterprise-specific MIB tables by using the JNUmanagement IP

address (chassis traps) and the combination of the service VLAN ID and SNMP ifindex

(interface traps) as the instance ID.

Because the satellite interfaces are extended from the satellites to the controller and

anchored on logical-interfaces on the controller, when there are interface-related syslog

messages or syslog messages that are generated by the features acting on these port

extenders anchored on the controller, the controller originates these syslog messages

directly.



AssigningAggregatedEthernet InterfacesDynamically toBeExtended fromSatellites

You can configure an aggregated Ethernet 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.

CoS Features on the Logical Interface Extension

Class-of-service (CoS) settings on logical interfaces that are of the port-extender type

are not propagated to the satellites and they are enabled directly on the controller. These

attributes include the following:

• rewrite-rules

• classifiers

The following example shows a CoS logical interface configuration:

class-of-service {interfaces {<ifd> {/* Existing configurations */

}port-extender {<satellite>:<ifd> {/*Port-extender configurations *//* All satellite ifd class-of-service configurations */unit <n> {/* All port-extender ifl class-of-service configurations */

}}

}}

}

VLAN-ID List Support on Port-Extender Interfaces

You can configure a list of VLAN IDs on port-extender interfaces by including the

vlan-id-list statement and specifying the VLAN IDs. You can configure a list of VLAN IDs

on port-extender interfaces by using the following statement:

vlan-id-list [number number-number];

You can specify individual VLAN IDs with a space separating the ID numbers, a range of

VLAN IDs with a dash separating the ID numbers, or a combination of individual VLAN

IDs and a range of VLAN IDs.

RSTP and VSTP Support on Port-Extender Interfaces

Port-extender interfaces provide Layer 2 loop prevention through Rapid Spanning Tree

Protocol (RSTP) and VLAN Spanning Tree Protocol (VSTP). While configuring RSTP or



VSTP, you should configure the controller as the root bridge or configure the root bridge

northbound to the controller. This configuration prevents the controller–satellite device

link from going into blocking state.

The following example shows the RSTP and VSTP configuration on a port-extender

interface:

protocols {rstp {interface <interface-name> {/* STP interface configurations */

}port-extender {interface <port-extender-interface-name> {/* STP interface configurations */

}}

}vstp {interface <interface-name> {/* STP interface configurations */

}port-extender {interface <port-extender-interface-name> {/* STP interface configurations */

}}

}}

RSTP

When RSTP is configured on a port-extender interface, the entire RSTP configuration is

configured on the controller. Only the interfaces are configured on the corresponding

satellite devices.

For example, consider the following configuration:

protocols {rstp {interface ge-0/0/0;interface ge-0/0/1;port-extender {interface sat1:ge-0/0/0;interface sat2:xe-0/1/0;

}max-age 40;

}}

The effective configuration on the controller is:

protocols {rstp {interface ge-0/0/0;



interface ge-0/0/1;interface ae0; /* downlink to satellite sat1 */interface ae1; /* downlink to satellite sat2 */max-age 40;

}

The effective configuration on the sat1 satellite device is:

protocols {rstp {bridge-priority 60kinterface ge-0/0/0 {no-root-port;}interface ae0{bpdu-timeout-action {alarm}

}/* uplink to controller */max-age 40;}

}


protocols {rstp {bridge-priority 60kinterface Xe-0/1/0 {no-root-port;}interface ae0{bpdu-timeout-action {alarm}

}/* uplink to controller */max-age 40;}

}

VSTP

When a port-extender interface is configured for VSTP, JNU the different access ports

that use the same VLAN ID in the same VLAN on the satellite device and extends the

VLAN to the MX Series controller. The MX Series controller uses one logical interface to

host the bridged VLAN. VSTP, on both the controller and the satellite device, runs on the

customer VLAN (C-VLAN) directly. For example, consider the following configuration:

protocols {vstp {interface ge-0/0/0;interface ge-0/0/1;port-extender {interface sat1:ge-0/0/10;



interface sat1:ge-0/0/11;interface sat2:xe-0/1/0;

}vlan 100;

}}

The effective configuration on the controller is:

protocols {vstp {interface ge-0/0/0;interface ge-0/0/1;interface ae0; /* downlink to satellite sat1 */interface ae1; /* downlink to satellite sat2 */vlan 100;

}


protocols {vstp {bridge-priority 60kinterface ge-0/0/10 {no-root-port;}interface ge-0/0/11 0 {no-root-port;}interface ae0 { /* uplink to controller */bpdu-timeout-action {alarm}

van 100;}

}vlans {jnu-port-extender-vlan100 {vlan-id 100;interface ae0.0;interface ge-0/0/10.0;interface ge-0/0/11.0;

}}

NOTE: VSTP cannot be configured on provider edge logical interfaces thathave a vlan-id-list defined under them. If VSTP is configured, you receive acommit error.

SNMPScaling Enhancements

Until JNU 1.3J4, SNMPwalk operations of satellite MIBs issue multiple SNMPwalks on

the satellite to obtain the chassis, ifTable, and ifXTable data. An event script runs on the



satellite and each satellite configures the event-options settings to monitor the SNMP

trap events that are sent for chassis and interface events. Shell scripts are used to run

multiple op scripts to connect to satellites to retrieve data concurrently, starting with

JNU 1.4J1.

Processing of High Capacity Counters by JNU SNMPScripts

JunosOSsupports thehighcapacity (HC)SNMPcounters (ifXtable).The ifXTableprovides

similar64-bit counters, alsocalledhighcapacity (HC)counters, for inboundandoutbound

octets (ifHCInOctets/ifHCOutOctets) and inboundpackets (ifHCInUcastPkts). It is always

good touse64-bit countersbecause theycontain statistics for both lowandhighcapacity

components. The ifXTable counters on the satellites are supported by the JNU SNMP

proxy script.

Configuring the Proxy SNMPAgent on JNU Satellites

The JNU port-extender mode extends the interface resources from the satellites to the

controller and the controller anchors these extended interfaces as its own, embedded

interfaces. The interfaces extended from the satellites to the controller are considered

as logical interfaces by the controller. Such interfaces are created andmanaged by the

controller in the samemanner as the logical interfaces configured on native physical

interfaces of the controller are maintained and administered. The statistical details and

counters of the port-extender interfaces are stored on these logical-interfaces locally

on the controller. When you perform an SNMPwalk of the Juniper Networks

enterprise-specific Interface MIB (IF MIB) on the controller, all the interface statistics on

the controller, including the JNU port-extender logical interfaces, are retrieved.

Because the satellite devices run Junos OS, the chassis and physical interface statistics

are also tracked locally on the satellite devices additionally. JNU enables these statistics,

which reside on the satellites, to also be hosted on the controller using a table under the

Enterprise mib. Until JNU Release 1.3J4, when a network management system (NMS) is

used to perform an SNMPGet, Get Next, Bulk Get, or an SNMPwalk is performed on the

Enterprise MIB table extensions for JNU, a passthrough JNUmodule returns the values

from the satellites. The passthrough script mechanism, using Junos automation scripts,

has a drawback of low performance (even with prepopulated MIB values, the response

time for each SNMP object ID takes about 0.4 seconds).

Starting with JNU Release 1.4J1, the SNMP proxy capability is supported, which enables

an NMS to query all the MIB objects on the controller and the satellites that it manages

through the controller itself. This functionality offers improved and optimized response

times for SNMP queries (Get, Get Next, Bulk Get, and walk). You can assign the satellite

devices in the network as proxy SNMP agents through which the NMS can query other

devices in the network.When you configure aproxy, you can specify the namesof devices

to bemanaged through the proxy SNMP agent. When the NMS queries the proxy SNMP

agent, theNMSspecifies the community name(for SNMPv1 andSNMPv2)or the context

and security name (for SNMPv3) associated with the device fromwhich it requires the

information.



JNU creates the SNMP proxy configuration for each of the satellites on the controller.

The followingexample illustrates theSNMPcommunity-stringconfigurationonasatellite:

snmp { community public.<satellite-name> { authorization read-only; }}

The following configuration statements at the [edit snmp] hierarchy level describe thesettings to define an proxy SNMP agent and devices to bemanaged by the proxy SNMPagent:

proxy proxy-name{device-name device-name;routing-instance routing-instance;<version-v1 | version-v2c> {snmp-community community-name;no-default-comm-to-v3-config;

}version-v3 {security-name security-name;context context-name;

}}

• The proxy statement enables you to specify a unique name for the proxy configuration.

• The version-v1, version-v2c, and version-v3 statements enable you to specify theSNMP

version.

• The no-default-comm-to-v3-config statement is an optional statement at the [edit

snmp proxy proxy-name <version-v1 | version-v2c>] hierarchy level that when included

in the configuration requires you to manually configure the statements at the [edit

snmpv3snmp-communitycommunity-name] and [edit snmpv3vacm] hierarchy levels.

If the no-default-comm-to-v3-config statement is not included at the [edit snmpproxy

proxy-name <version-v1 | version-v2c>] hierarchy level, the [edit snmp v3

snmp-community community-name] and [edit snmp v3 vacm] hierarchy level

configurations are automatically initialized.

• The and routing-instance statement is an optional statement that enables you to

specify routing instance names if you want to create proxies for logical systems or

routing instances on the device.

For each of the satellites, the proxy configuration is added by JNU on the controller as

follows:

user@jnu-ctrlr# show groups jnu-controller-mgmt snmpproxy sat1-ce1 { device-name 192.168.115.53; version-v2c { snmp-community public.sat1-ce1; } routing-instance jnu-vrf;}



With the aforementioned configuration, when NMS queries the controller using the

controller community string, the controller responds with the MIB values that reside on

the controller. When the NMS queries the controller using a proxy community string, the

controller replies to the request to the corresponding satellite, and the satellite responds

with the MIB values on the satellite using the controller to the NMS.

The following example displays the SNMP proxy configuration for a satellite, sat1 on a

controller

snmp { proxy { sat1 { device-name sat1; routing-instance jnu-vrf; version-v2c { snmp-community public.sat1; no-default-comm-to-v3-config; } } }}

The following SNMP Get operation retrieves the sysDescr.0 value on the controller:

[NMS]$ snmpget -c public controller-ip sysDescr.0sysDescr.0 = Juniper Networks, Inc. mx480 internet router, kernel JUNOS 14.1R1.2, Build date: 2014-06-27 09:22:08 UTC Copyright (c) 1996-2014 Juniper Networks, Inc.

The following SNMP Get operation retrieves the sysDescr.0 value from the satellite syst,

sat1, through the controller:

[NMS]$ snmpget -c public.sat1 controller-ip sysDescr.0sysDescr.0 = Juniper Networks, Inc. ex4200-24t Ethernet Switch, kernel JUNOS 12.3R8.6, Build date: 2014-09-12 08:56:44 UTC Copyright (c) 1996-2014 Juniper Networks, Inc.

The following SNMP Get operation retrieves the sysDescr.0 value from the satellite syst,


[NMS]$ snmpget -c public.sat2 controller-ip sysDescr.0sysDescr.0 = Juniper Networks, Inc. qfx3500s Ethernet Switch, kernel JUNOS 12.3X50-D35, Build date: 2013-10-22 08:51:05 UTC Copyright (c) 1996-2013 Juniper Networks,

The following is an example of an SNMPwalk on all the systemMIBs on the controller:

[NMS]$ snmpwalk -c public controller-ip systemsysDescr.0 = Juniper Networks, Inc. mx480 internet router, kernel JUNOS 14.1R1.2, Build date: 2014-06-27 09:22:08 UTC Copyright (c) 1996-2014 Juniper Networks, Inc.sysObjectID.0 = jnxProductNameMX480sysUpTime.0 = 40712478sysContact.0 = IT DepartmentsysName.0 = controllersysLocation.0 = JNU labsysServices.0 = 6



The following is an example of an SNMPwalk on all the systemMIBs on the satellite,


[NMS]$ snmpwalk -c public.sat1 controller-ip systemsysDescr.0 = Juniper Networks, Inc. ex4200-24t Ethernet Switch, kernel JUNOS 12.3R8.6, Build date: 2014-09-12 08:56:44 UTC Copyright (c) 1996-2014 Juniper Networks, Inc.sysObjectID.0 = jnxProductNameEX4200sysUpTime.0 = 151811729sysContact.0 sysName.0 = sat1sysLocation.0sysServices.0 = 6

The following is an example of an SNMPwalk on all the systemMIBs on the satellite,


[NMS]$ snmpwalk -c public.sat2 controller-ip systemsysDescr.0 = Juniper Networks, Inc. qfx3500s Ethernet Switch, kernel JUNOS 12.3X50-D35, Build date: 2013-10-22 08:51:05 UTC Copyright (c) 1996-2013 Juniper Networks, Inc.sysObjectID.0 = jnxProductQFX3500ssysUpTime.0 = 1395544196sysContact.0 sysName.0 = sat2sysLocation.0sysServices.0 = 6

Optimizing Configuration Commits on Satellites

Starting with JNU Release 1.4J1, a configuration commit operation for port-extender

interfaces performs the following sequence of events:

1. Determines the satellites for which configurations are modified

2. For those satellites that have configuration changes, propagate configurations from

the controller to the satellites

3. Perform a commit on all the satellites

4. If the commit operation on all satellites succeeds, the commit on the controller

proceeds; otherwise, a rollback of the committed configuration is performed on the

satellites but not on the controller

5. If the commit on the controller fails, you must analyze the configuration, modify the

discrepant setting, and recommit the configuration

Starting with JNU 1.4J1, the commit operation on the satellites in a JNU group occurs in

parallel andnot in a sequentialway.Concurrent commit on satellites significantly reduces

the commit time and optimizes the process.



Logging JNU TraceMessages to a Dedicated File

Until JNURelease 1.3J4, JNU records all tracingmessages, for example, the periodic LLDP

neighbor outputs in the /var/log/messages file. Starting with JNU 1.4J1, all of the JNU

tracemessages that are saved in the /var/log/messages file are transferred to a different

file, the /var/log/jnud file. For important state information (and not only tracing

information), however, for example, satellite downor satellite discoveredandconnected,

is continued tobe logged in the /var/log/messages file. The JNUsystem loggingmessages

with various severity levels that are stored in the /var/log/messages file denote the

messages are triggered for JNU events or operations.

Event Script Optimization

You can track and analyze the states of the satellite interfaces that are extended to the

controller and are anchored on a logical interface on the controller. This mechanism to

examine and diagnose the working of extended satellite interfaces, an event script is

supported in the Stylesheet Language Alternative Syntax (SLAX) application on the

satellite tomonitor all theextended interfacesor ports. JunosOSevent scripts are located

in the /var/db/scripts/event directory.

The event script in the SLAXmodule performs the following tasks:

• If an satellite interface goes down, the event SLAXmodule connects to the controller

to administratively disable extended interface, which is a logical interface on the

controller.

• When thesatellite interface recovers, theeventSLAXmodule connects to thecontroller

to adminstratively enable the extended interface.

Starting with JNU Release 1.4J1, event scripts on the controller aremerged into one event

script per event to reduce the number of event script instances per cycle. This reduction

reduces the probability of the maximum number of event policies from being reached.

Restricting the Number of Downlink Interfaces on the Controller

In your network deployment, youmight not require all the unconfigured interfaces on the

controller to be enabledwith LLDP. You can configure the interfaces thatmust be eligible

and processed for being a downlink interface to the satellite. By default, the request jnu

controller [management-address] operationalmode command,which you use to enable

the JNU controller mode, places all interfaces that do not contain any configuration

settings in the routing-instance named jnu-vrf and contain LLDP enabled on them as

downlink interfaces. This behavior enables satellites to be detected and to connect on

any interface to receive DHCP requests and LLDP to discover the remote interfaces on

the satellite.

You can now use the no-auto-discovery option with the request jnu controller command

to disable the configuration of interfaces into the jnu-controller-mgmt configuration

group and to not automatically enable LLDP on any interfaces.

user@controller> request jnu controller no-auto-discovery



After you configure the no-auto-discovery option, you can define the interfaces explicitly

on the controller that must be used for downlink connection with satellites as follows:

chassis { jnu-management { downlinks { interface physical-interface-name to physical-interface-name; } }}

The following example enables xe-0/0/0, xe-1/0/0, xe-1/0/1, xe-1/0/2, xe-1/0/3 in the

configuration group named jnu-controller-mgmt and LLDP on these interfaces only.

chassis { jnu-management { downlinks { interface xe-0/0/0; interface xe-1/0/0 to xe-1/0/3; } }}

When you specify the interface range as interface physical-interface-name to

physical-interface-name, the starting and ending interfaces must contain the same FPC

slot and PIC slot. For example, interface xe-0/0/0 to xe-0/0/3 is a valid range, whereas

interface xe-1/0/0 to xe-2/0/0 and interface xe-0/0/3 to xe-0/1/0 are invalid ranges.

Specifying Aggregated Ethernet Interface Ranges for Controller Downlinks

JNU supports interface ranges on port-extender interfaces. You can use interface ranges

to group interfaces of the same type that share a common configuration profile. This

capability helps you to reduce the time and effort in configuring interfaces. The

configurations common to all the interfaces can be included in the interface range

definition.

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.

To configure an interface range, include the interface-range statement at the [edit

interfaces] hierarchy level. Interfaces can be grouped either as a range of interfaces or

using a number range under the interface-range statement definition. Interfaces in an

interface-range definition can be added as part of a member range or as individual

members or multiple members using a number range. To specify a member range, use

themember-range statement at the [edit interfaces port-extender interface-range name]

hierarchy level. To specify interfaces in lexical order, use themember-range start-range

to end-range statement.

An interface-range definition can contain bothmember andmember-range statements

within it. There is nomaximum limit on the number ofmember ormember-range



statements within an interface-range. However, at least onemember ormember-range

statement must exist within an interface-range definition.

The following configuration settings canbeenabled for a rangeof interfaces that function

as satellite extended interfaces on a controller:

interfaces {port-extender {interface-range <name> {[member <satellite>:<ifd> ];[ member-range <satellite> to <end-range> ];disable;mtu <n>;

hold-time up <n>;ether-options {flow-control;

speed {<speed>;

}}

}unit <n> {....;

}}

Observe the following guidelines while configuring port-extender interface ranges:

• Wildcards used in themember andmember-range statements are not supported.

• After you define the interface ranges under port-extender, the port-extender

interface-range in regular Junos OS features can be used only for logical

interface-related features. This condition occurs because the port-extender interfaces

arehostedon thecontroller as logical interfaces (IFL)andnotphysical interfaces (IFD).

• When you use themember-range option, the JNU software examines whether the

member interfaces are anchored from the same satellite and the interface prefixes

are the same. For example:

• member-range satellite1:ge-0/0/0 to satellite1:ge-0/0/24 is valid

• member-range satellite1:ge-0/0/0 to satellite10:ge-0/0/0 is not valid

• member-range satellite1:ge-0/0/0 to satellite1:xe-1/1/1 is not valid

• member-range satellite1:ae0 to satellite1:xe-1/1/1 is not valid

• Port-extender interface-range settings operate similar to the native interface-range

attributes.Theconfigurations thatarespecifiedunder the interface-rangeareduplicated

under themember interfaces. The physical interface parameters are configured for all

themember interfaces under the physical interface and logical interface- level settings

are configured for all the member interfaces under the logical interface. The

functionalities or parameters that are enabled for configuration on only onemember

interface instance are configured in the firstmember interface instance that is defined.



For example, consider the followingport-extender interface configurationonacontroller:

user@controller> show configurationinterfaces { port-extender { interface-range mytest { member sat2:ge-0/0/0; member sat2:ge-0/0/1; member sat2:ge-0/0/2; vlan-tagging; unit 0 { vlan-id 101; family inet { address 1.1.1.1/30; } } } sat2:ge-0/0/0 { unit 0; } sat2:ge-0/0/1 { unit 0; } sat2:ge-0/0/2 { unit 0; } }}

The following effective configuration is generated as a result of the preceding settings:

user@controller# show | display inheritanceinterfaces {port-extender {interface-rangemytest {member sat2:ge-0/0/0;member sat2:ge-0/0/1;member sat2:ge-0/0/2;vlan-tagging;unit 0 {vlan-id 101 {family inet {address 1.1.1.1/30;}

}}

}sat2:ge-0/0/0 {#### 'vlan-tagging' was expanded from interface-range 'mytest'##vlan-tagging;unit 0 {#### '101' was expanded from interface-range 'mytest'##

vlan-id 101 {##



## 'inet' was expanded from interface-range 'mytest'##family inet {#### '1.1.1.1/30' was expanded from interface-range 'mytest'##address 1.1.1.1/30;}

}}

}sat2:ge-0/0/1 {#### 'vlan-tagging' was expanded from interface-range 'mytest'##vlan-tagging;unit 0 {#### '101' was expanded from interface-range 'mytest'##vlan-id 101;#### 'inet' was expanded from interface-range 'mytest'##family inet;

}}

}sat2:ge-0/0/2 {#### 'vlan-tagging' was expanded from interface-range 'mytest'##vlan-tagging;unit 0 {#### '101' was expanded from interface-range 'mytest'##vlan-id 101 {#### 'inet' was expanded from interface-range 'mytest'##family inet;

}}

}}

}

Therefore,whenan interface range is configured, the JNUapplicationcreates the transient

configuration to duplicate the configurations under the interface-range hierarchy level

to the port-extender interface configuration. However, properties that cannot exist on

multiple instances (for example, inet address or inet6 address) inherit the configuration

on the first instance only.



You can use the device-range start-id to end-id statement at the [edit chassis

jnu-management downlinks] hierarchy level on the controller to determine the range of

aggregatedEthernet (AE) interface identifiers thatmustbeused fordownlink connection

to satellites. The start-idandend-id valuesdenote theunique identifiers of theaggregated

Ethernet interface in the range 0–479.

user@controller# showchassis {jnu-management {downlinks {device-range start-id to end-id;

}}}

JNU uses the aggregated Ethernet interface IDs within the range (inclusive) for downlink

AE interface IDs.

Disabling of Automatic Deletion of Satellites from a Controller Due to Unreachability

If a satellite goes down or unreachable, it is maintained in the down state and the

configuration settings are retained without any expiration. When the device comes back

up and is online, for example, after a day or aweek, the controller recgonizes the satellite

and it can be brought back into the network environment. If the satellite is deemed dead

and an Return Materials Authorization (RMA) is requested, when the replacing device is

obtained, the controller recognizes a new satellite with the same name that has been

plugged in and all of the initialization and port-extender configurations are applied to

the new satellite device automatically.

The prerequisite to achieve the benefit of effective administration of seamless

replacement of a failed satellite with a new satellite is for the hostname and root

password on the replacement satellite to be properly configured and for the hostname

tobe thesameas thedevice thatwas removed.Thismethod is similar to the replacement

of a line card. An automatic deletion of a satellite configuration from a controller after

30minutes of unreachability to the satellite is not performed.

Restoring the Initial Connectivity Settings for the Replaced Satellite

When the satellite hardware needs to be replaced (RMA), it is essential that the

replacementunit assumes the JNUparameterspreviously assignedby the JNUcontroller.

To achieve this behavior, you must perform the following steps:

• The new unit must be configured with the same satellite hostname as the device you

are replacing.

• After adding the JNU package on the satellite, the satellite needs to be initiated with

the JNU assignedmanagement address and the uplink interfaces.

To restore the uplink interface and themanagement IP address of the satellite, enter the

following command on the satellite:



user@satellite> request jnu satellite restore uplink <uplink-interfaces> address<jnu-management-address-of-satellite>

For example:

user@satellite> request jnusatellite restoreuplinkxe-0/0/0,xe-0/0/1address 192.168.0.2

Theuplink interfacesandaddress information canbe verifiedbyusing the showsatellites

command on the controller. After the satellite is restored with the uplink interfaces and

JNUmanagement IP address, you also need to synchronize the configuration from the

controller by using the following command:

user@controller> request jnu commit-synchronize satellite satellite-name

Mechanism to Propagate Generic Configuration Settings to Satellites

Typically, all the JNU operations are done on the controller, but there are scenarios when

certain operations are needed on the satellites. Normally, to add satellite configurations

to thecontroller, it requires changes in the JNUpackage.But if theconfiguration is identical

between thecontroller and thesatellites, the special configurationgroup,all-jnu-satellites,

can be used.

You can configure a group that can propagate all the configuration attributes common

to all the satellites in a JNU group from a controller. You can define the jnu-all- satellites

statementat the [editgroups]hierarchy level for this transmissionofgeneric,wide-ranging

settings from a controller that are applicable for all the satellites. You can define the

jnu-all-satellites group on the controller to enable the settings to be transmitted on the

controller. The following is an example of the configuration on the controller to create a

configuration group:

groups { all-jnu-satellites { system { login { satellite-operator { class jnu-satellites; authentication { encrypted-password "$9$915jziv808"; } } class jnu-satellites { permissions [ maintenance config ]; } } } }}

With the aforementioned definition of a group, all the configurations in this group are

propagated to the satellites and applied. If the configuration syntax is not supported on

the satellites, the configuration commit is continued to be rejected on the satellites until

the unsupportedor invalidated configurations are removed from the configuration group.

Youcandefine theall-jnu-satellites grouponsatellites,which contains the configurations



transmitted from the controller. You can use the apply-groups statement that is available

at all the hierarchy levels in the Junos OS to apply the previously-defined configuration

group to a specific hierarchy level in a configuration and to have a configuration inherit

the statements in the configuration group.

The following is an example of the configuration on satellites to create a configuration

group:

groups { all-jnu-satellites { /* configs propagated from controller */ } } apply-groups [ jnu-satellite-mgmt jnu-module ... jnu-all-satellites ];

This functionality enables you todefine theconfigurationparameters similar to free-form

settings. The requirement for applying the free-form settings is that the configuration

syntax must be common between the controller and satellite devices.

input-vlan-map and output-vlan-map Configuration on Port-Extender Interfaces

For Layer 2 VPNs, the remote Layer 2 VPN segment might use VLAN IDs different from

the VLAN IDs on the local segment. Users canmake adjustments to the VLAN IDs using

input-vlan-map and output-vlan-map' configurations.

NOTE: JNU Release 1.3J1 supports only one VLAN-tag on satelliteaccess-ports. Operations allowing access-ports with Q-in-Q traffic are notsupported.

The followingconfiguration illustrates input-vlan-mapandoutput-vlan-mapconfiguration

on port-extender interfaces:

interfaces { port-extender { <satellite>:<ifd> { unit <n> { input-vlan-map { ( push | swap | pop ); vlan-id <vlan-id>; } } } }}

Table 2 on page 73 lists the port-extender input-vlan-map and output-vlan-map

configuration and their corresponding effective operation.

Table 2: input-vlan-map and output-vlan-map Configuration

Effective input-vlan-mapOperationPort-Extender input-vlan-map

swap JNU SVLAN-ID with user-specified VLAN-IDpush



Table2: input-vlan-mapandoutput-vlan-mapConfiguration (continued)

Effective input-vlan-mapOperationPort-Extender input-vlan-map

pop JNU SVLAN-ID and then swap with user-specifiedVLAN

swap

pop-poppop

Effective output-vlan-mapOperationPort-Extender output-vlan-map

access-port has no vlan-id (traffic only has S-VLAN IDbut no C-VLAN ID)

pop

swap inner VLAN-ID (C-VLAN) with user-specifiedVLAN-ID and then push JNU SVLAN-ID

swap

Not supportedpush


Configuring the Port Extender Interface Settings from the Junos OS CLI on page 52•

• JNU Port Extender Mode Overview on page 52

Configuring Port-Extender Functionalities and Protocols

You can define and apply the configuration parameters in JNU 1.3J1 port-extender mode

from the Junos CLI configuration mode. Port-extender mode signifies that when you

configure an interface that resides physically on a satellite, the same physical interface

can be extended 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. After you

extend and host a satellite interface to the controller, you can use the controller device

to manage andmonitor these extended interfaces, which are treated as the controller's

own, logical interfaces.

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

This section contains the following topics that describe the various functionalities and

capabilities that you can configure on the satellite extended interfaces from the Junos

OS CLI configuration statements of a controller.

• Using Q-in-Q Tunneling and S-VLAN IDs for Satellite Extended Interfaces on page 75

• Configuring a Satellite Aggregated-Ethernet Port Extender on page 76

• Configuring Layer 3 Features on Port-Extender Interfaces on page 78

• Configuring Layer 2 Bridge Domains on Port-Extender Interfaces on page 79



Using Q-in-Q Tunneling and S-VLAN IDs for Satellite Extended Interfaces

You can use Q-in-Q tunneling and VLAN translation to isolate customer traffic within a

single site or enable customer traffic flows between devices in different geographic

locations. Q-in-Q tunneling adds a service VLAN tag before the 802.1Q VLAN tags of the

customer. The port-extender mode in the JNU group of devices uses Q-in-Q services.

This mechanism 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 reaches from each customer VLAN (C-VLAN) of each

satellite port terminatesonadifferent logical interface in thedownlink fromthecontroller

to the satellite. To uniquely differentiate the traffic from the different extended ports,

the outer VLAN tags must be unique within the JNU group (one VLAN tag for each

extendedsatelliteport).TheouterVLANtag isdifferent fromthe JNUmanagementplane

VLAN ID and is not manually configured; instead, it is assigned automatically by the

system.

Consider a sample scenario in which a logical AE interface, ae0.101 on a satellite is

extended and hosted on the logical AE interface, ae.101 of a controller. Similarly, another

logical AE interface, ae0.102, is connected from the satellite and hosted on the interface,

ae0.102, of the controller. The controller and the satellite are connected using a

managementVLAnwith theVLAN IDof4094.TwoGigabit Ethernet interfaces, ge-0/0/0

and ge-0/0/1, are the output interfaces of the satellite that are part of a different VLAN.

Because of all the configurations being done on the controller, the controller tracks all

of the Q-in-Q tags already assigned.

The following is an example of the configuration created on the satellite, jnu-satellite1:

ethernet-switching-options { dot1q-tunneling { ether-type 0x8100; }}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; } }



}

To extend a satellite interface on a controller with a VLAN ID and to process single-tag

frames with 802.1Q VLAN tags:

1. Configurea the satellite interface to receiveand forward single-tag frameswith802.1Q

VLAN tags

user@controller# set interfaces port-extender sat1:ge-0/0/0 vlan-tagging

2. Specify the interface that you want to extend from the satellite with the VLAN ID

user@controller# set interfaces port-extender sat1:ge-0/0/0 unit 88 vlan-id 100

3. Specify the INET family and address for the interface

user@controller#set interfacesport-extender sat1:ge-0/0/0unit88 family inetaddress1.1.1.1/30

After the port-extender is configured, the Port-extender logical interface name can be

used by other features on the controller. Only the port-extender logical interface can be

used in conjunctionwith other functionalities on the controller; you cannot use any other

interface on the controller to configure settings for devices in a JNU group.

Configure a global value for the tag protocol identifier (EtherType) of the service VLAN

tags (outer tags) in Q-in-Q tunneling for the satellite interface to be extended to the

controller. It specifies theprotocolbeing transported in theEthernet frame.OnlyEthertype

0x8100 is supported for port-extender mode.

Because the flexible-vlan-tagging setting and the service VLAN ID are generated by the

JNU process, you cannot change those configurations on the controller downlink. You

cannot configure VLAN tagging or stacked VLAN tagging on the physical interface and

you cannot configure VLAN tags for the port extender logical interface on the controller

The outer tags used to tunnel the satellite ports are uniquewithin a JNU group (1–4093),

regardless of the satellites. The outer tags used for tunneling the satellite ports can be

reused in other bridge-domains on the controller for interfaces unrelated to the extended

satellite ports.

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

satellite-name:physical-interface-name.logical-unit-numberstatementat the [edit interfaces

port-extender] hierarchy to extend it to the controller. Each AE bundle can contain only

physical interfaces from the same satellite.

The followingexample illustratesanAE interface, sat1:ae1, on the satellite that is extended

to the controller. LACP is configured as active in the link between the satellite and the

controller, VLAN tagging is enabled, and VLAN ID is configured on the AE interface.

interfaces { port-extender {



sat1:ge-0/0/0 { ether-options { 802.1ad ae1; } } sat1:ge-0/0/1 { ether-options { 802.1ad ae1; } } sat1:ae1 { aggregated-ether-options { lacp { active; } } vlan-tagging; unit 0 { vlan-id 2001; family inet { address 137.0.0.1/30; } } } }}

The following configuration is generated on the controller as a result of the preceding

settings:

interfaces { ae479 { flexible-vlan-tagging; unit 999 { interface-alias "sat1:ae1.0"; vlan-tags outer 888 inner 2001; family inet { address 137.0.0.1/30; } } }}

The following configuration is generated on the satellite as a result of the preceding

settings:

chassis { aggregated-devices { ethernet-devices { device-count 63; } }}ethernet-switching-options { dot1q-tunneling { ether-type 0x8100; }}



interfaces { ge-0/0/0 { ether-options { 802.3ad ae1; } } ge-0/0/1 { ether-options { 802.3ad ae1; } } ae1 { aggregated-ethernet-options { lacp { active; } } unit 0 { family ethernet-switching; } }}vlans { jnu-port-extender-vlan888 { vlan-id 888; interface { ae1; } dot1q-tunneling { customer-vlans 2001; } }}

Configuring Layer 3 Features on Port-Extender Interfaces

After you define the port-extender interface, you can specify Layer 3 functionalities on

the extended interface, depending on your topology needs, in the samemanner in which

you define Layer 3 capabilities on other non-port-extender or logical interfaces on the

controller device. For example, you can enable and configure a port-extender interface

with OSPF.

The following show commands display the portion of the configuration of an extended

satellite interface defined with OSPF settings:

user@controller# showprotocols { ospf { area 0.0.0.0 { interface sat1:ae1.0; interface lo0.0; } }}



user@controller> show ospf interfaceInterface State Area DR ID BDR ID Nbrssat1:ae1.0 DR 0.0.0.0 137.0.0.1 0.0.0.0 0lo0.0 Waiting 0.0.0.0 0.0.0.0 0.0.0.0 0

user@controller> show ospf interface sat1:ae1.0Interface State Area DR ID BDR ID Nbrssat1:ae1.0 DR 0.0.0.0 137.0.0.1 0.0.0.0 0

Because the port-extender interface is an embedded, complete logical interface on the

controller, when you specify the "interface all" option, it denotes all the logical interfaces

including the port-extender interfaces.

Configuring Layer 2 Bridge Domains on Port-Extender Interfaces

After you define the port-extender interface, you can specify Layer 2 functionalities on

the extended interface, depending on your topology needs, in the samemanner in which

you define Layer 2 capabilities on other non-port-extender or logical interfaces on the

controller device. For example, you can enable and configure a port-extender interface

as trunk interfaces, with spanning trees, and in bridge domains.

The following show command displays the portion of the configuration of an extended

satellite interface configured in a bridge domain:

user@controller# showbridge-domains { vlan1 { vlan-id 1; interface sat1:ae1.0; }}

The following show commands display the portion of the configuration of an extended

satellite interface enabled with VLAN spanning tree protocol (VSTP):

user@controller# showprotocols { vstp { interface sat1:ge-0/0/0.100; }}

Because the port-extender interface is an embedded, complete logical interface on the

controller, when you specify the "interface all" option, it denotes all the logical interfaces

including the port-extender interfaces.

Configuring Port Extender Interface Features Directly on the Satellites

Although a satellite interface that is extended to the controller can be accessed and

managed as the controller's own interface, a few functionalities require explicit

configuration on the satellites directly.



This section contains the following topics that describe the working behavior of such

attributesandcomponents that requireaseparate, individual configurationon thesatellite

interfaces that function as extended interfaces:

• CoS Features on Logical Interface Extension on page 80

• CoS Features on Physical Interface Extension on page 80

• Firewall Features on page 81

• MTU Settings on page 82

• Service VLAN ID Removal for Layer 2 VPNs and Circuits on page 82

• CoS Rewrite Rules on page 83

CoS Features on Logical Interface Extension

Class-of-service (CoS) settings on logical interfaces that are of port-extender type are

not propagated to the satellites and they are enabled directly on the controller. These

attributes include the following:

• rewrite-rules

• classifiers

The following example shows a CoS logical interface configuration:

class-of-service { interfaces { ge-0/0/0 { unit 0 { rewrite-rules { dscp default; } } } }}

CoS Features on Physical Interface Extension

CoS functionalities on physical interfaces must be on the satellites. Only the CoS

parameters or characteristics that are common to both the MX Series controllers, and

EXSeries switches or QFXSeries devices that are satellites are supported in the JNU 1.3J1

Release. The following are the supported CoS features:

• scheduler-map

• shaping-rate

The following show command displays a sample CoS physical interface configuration:

user@controller# showclass-of-service { interfaces { sat1:ge-0/0/0 { scheduler-map gold;



} }}

When you specify an interface at the [edit class-of-service] hierarchy level, the JNU

commit module treats the configuration to be applicable for the satellite instead of the

controller. The JNUcommitmodule in turndeactivates this configurationon thecontroller

and creates the satellite configuration to be propagated to the satellite.

The following example displays a physical interface configuration generated on the

controller:

groups { sat1 { class-of-service { interfaces { ge-0/0/0 { scheduler-map gold; } } } }}class-of-service { interfaces { sat1:ge-0/0/0 { inactive: scheduler-map gold; } }}

The following example displays a physical interface configuration generated on the

satellite, sat1:

groups { sat1 { class-of-service { interfaces { ge-0/0/0 { scheduler-map gold; } } } }}apply-groups sat1;

Class-of-service configuration profiles that are referenced at the [edit class-of-service

interfaces] hierarchy level are replicated on all satellites. Scheduler map is an attribute

that is of such a type.

Firewall Features

Only the controller-related firewall features are supported in JNU 1.3J Release 1.3J. You

cannot configure the satellite-related firewall settings such as family ethernet-switching

firewalls on the MX Series controllers. Therefore, configuration of firewall settings for

satellites is not supported in the JNU 1.3J release.



MTUSettings

If you set the maximum transmission (MTU) size for an extended port from the satellite

to the controler, the config-interfaces command validates that the pathMTU is sufficient

to handle the configured port MTU.

Service VLAN ID Removal for Layer 2 VPNs and Circuits

With 802.1q-tunneling as the port-extender mechanism, and with the controller

terminating the port-extender interfaces directly on the controller AE logical interfaces,

the service VLAN IDs assigned to the port-extender interface do not impact the Layer 3

traffic if the port-extender interface is a Layer 3 interface (configured with inet, inet6, or

MPLS family).

For layer 2 VPNs and layer 2 circuits, the satellite data is encapsulated using the service

VLAN ID when the packets are transmitted to the controller. The satellite data contains

twoVLANtagswhen it reaches thecontroller on theaggregatedEthernet logical interface.

Because only one VLAN tag is configured normally on the satellite ports, for layer 2 VPNs

and layer 2 circuits, it is expected that the data that arrives at the layer 2 VPNs or circuits

might contain only the user-configured VLAN tag (without the service VLAN tag). JNU

application removes the service VLAN tag on the port-extender logical interface the

controller.

The following showcommanddisplaysasampleconfigurationgeneratedon thecontroller

for layer 2 circuits and VPNs:

user@controller# showinterfaces { port-extender { /* This section is not used by the routing process */ sat1:ge-0/0/0 { encapsulation vlan-ccc; vlan-tagging; unit 0 { encapsulation vlan-ccc; vlan-id 512; } } } ae0 { /* This section is generated by JNU and used by routing process for the l2vpn */ flexible-vlan-tagging; encapsulation flexible-vlan-services; unit 0 { alias "sat1:ge-0/0/0.0"; encapsulation vlan-ccc; /* The remote PE only expects non-stacked VLAN tag of 512 */ vlan-tags outer 1000 inner 512; input-vlan-map { pop; } } }}routing-instances {



sat1_ge_0_0_0_l2vpn { instance-type l2vpn; interface sat1:ge-0/0/0.0; .... protocols { l2vpn { site 1 { interface sat1:ge-0/0/0.0 { remote-site-id 2; community target:512:1; } } } } }}

CoS Rewrite Rules

The JNU application examines the CoS rewrite rules to ensure that the correct header

(dscp, dscp-ipv6, exp, ieee-802.1, ieee-802.1adm, inet-precedence) is being rewritten.

Rewrite rules set the value of the CoS bits within the packet’s header. Each rewrite rule

reads the current forwarding class and loss priority associated with the packet, locates

the chosen CoS value from a table, andwrites this CoS value into the packet header. For

rewrites to occur, rewrite rules must be explicitly assigned to an interface. Only tagged

Layer 3 interfaces and tagged routed VLAN interfaces (RVIs) automatically rewrite

packets by using the default IEEE 802.1p rewrite rule.

Operations of the Commit Script with Port Extender Interfaces from the Junos OS CLI

Because themanagement process (mgd) locks the Junos configuration before running

thecommit script, thecontroller commit script cannotusea remoteprocedurecall (RPC)

to perform a commit check on the configuration of the controller. The commit script

performs the following operations:

• Themgd process locks the configuration database and then starts the commit script

• The commit script handles the following tasks:

• Generates theapply-macrosstatements forbothcontroller andsatellitesas transient

configuration data (the ones generated for the controller are only user

troubleshooting, if needed)

• For the apply-macros of the controller, saves the settings in one or more variables.

• Instead of using the apply-macros in the controller configurations to expand to the

actual configuration for the controller, uses the apply-macros saved in the variables

described in the preceding step to expand to the configuration for the controller

• At this point in time, all the controller and satellites configurations are generated

• Examines and validates the changed settings at the [edit interfaces port-extender]

and the [edit class-of-services] hierarchy levels (if configuration change is detected

tobe sent to the satellites, the script propagates satellite configurations to satellites,

a commit check occurs on all the satellites.



• If at least one of the satellite fails "commit check", commit process aborts, and

generates an error message - If all satellites successfully clear the commit check

process, the commit script completes and proceeds with the regular controller

commit process. At the end of controller commit check, mgd releases the lock on

the configuration.

• If the controller commit check fails, a commit check error message is received on

the controller.

• If controller commit check succeeds, controller accepts the new configuration, and

the commit is completed.

• An event script is implemented on the controller for this "commit complete" event. If

the "commit complete" state or action occurs, a commit on all the satellites is

performed toactivate thenewconfiguration. (If "port-extender" and "class-of-service"

change-bits are not set, it denotes that modified or new configuration is not present

and therefore, no commit is done on satellites). If commit fails on any of the satellites,

a system logging message to signify the failure on the controller is generated.

• The controller propagates only the configuration settings that are modified to the

satellites and does not transmit the complete configuration set.

Monitoring the Satellite Interfaces Extended on the Controller

If you configure interface alias names on your devices in a JNU environment, the

management process (mgd) displays the interface alias names instead of the interface

names in the output of all of the show and operational mode commands. For

port-extender interfaces, because of the interface name denoting a combination of the

satellite name and the interface specifier, viewing interface alias names in the outputs

of the show commands enables easy, simplified identification of such interfaces. When

a port-extender interface namemapping can be found, the original interface name is

associated with the interface-alias name.

When you want to refer to a port-extender interface, you can use either the interface

name or the alias name in operational commands, but the output always displays the

port-extender interface name if a mapping interface alias name is identified for a

port-extender interface.

The following example shows the port-extender interface name displayed in the output

of the show command:

user@controller show interfaces sat1:ge-0/0/0.100 terseInterface Admin Link Proto Local Remotesat1:ge-0/0/0.100 up up inet 10.255.164.164

The existing show commands in the Junos CLI interface have been enhanced to include

the jnu device option in the syntax to denote that statistical details and configuration

parameterspertaining to thedevices ina JNUtopologyneed tobe retrievedanddisplayed.

Although you can specify the name of the satellite or controller device to display the

details specific to that particular device, by default, the all keyword indicates that the

configuration settings of all the satellite and controller devices must be displayed.



You can use the show version jnu device all command to display the hostnames and

version information. You can use the show chassis hardware jnu device all command to

display a list of all Flexible PIC Concentrators (FPCs) and PICs installed in the router or

switch chassis, including the hardware version level and serial number. You can use show

log jnu[devicedevice-name] command to list log files, display log file contents, or display

information about userswhohave logged in to the router or switch.With the jnu keyword,

the log file refers to the file located on the controller. Using the jnu keyword, you can

specifya log fileon thespecifiedsatelliteby including thedevicedevice-nameparameter.

You can use the request system software add jnu device device-name url command to

install a software package or bundle on the router or switch. If you want the image to be

installed onmultiple JNU satellites, you can specifymore than one satellite in the devices

list.

If you specify the interface-alias namewith the show interfaces command, the interface

is considered to be the one that resides on the controller and youmust not include the

device device-name parameter with the show command in such a case. Because the

Junos OS show interfaces command supports a number of parameters, if you enter the

command without the jnu keyword on the controller, all of the parameters or options

that are available with the command are supported.

The followingare thevariousways inwhichyoucanspecify the showinterfacescommand:

• The show interfaces command displays the information of all the interfaces on the

controller only.

• The show interfaces physical-interface-name command displays the interface

information of the particular physical interface on the controller.

• The show interfaces physical-interface-name.logical-unit-number command displays

the interface information of the particular logical interface on the controller.

• If you include the jnu keywordwith the show interfaces command, the command is run

on both the controller and all the satellites by default. If the argument 'device' is used,

the command is run only on the specified device.

• If you enter the show interfaces statistics command, you can specify only the detail

parameter to display detailed, comprehensive statistical information. You cannot use

the brief, terse, or detail options. Also, if you include the description keyword with the

show interfaces command, you cannot specify any of the levels of output, such as

brief, terse, detail, or extensive.

• The show interfaces jnu command denotes the device all parameter, distributes the

"show interfaces" command to both the controller and all the satellites, and returns

the interface information on all the devices in the JNU group. The output of this

command is identical as the output of the JNU feature-rich mode of op jnu-remote

deviceall command"showinterfaces"command.The following sampleoutputdisplays

the interface details of all devices in a JNU group:

user@controller show interfaces jnu Device: controller ---------------------------------- Interface Admin Link Proto Local Remote



lc-0/0/0 up up lc-0/0/0.32769 up up vpls pfe-0/0/0 up up pfe-0/0/0.16383 up up inet inet6 pfh-0/0/0 up up pfh-0/0/0.16383 up up inet si-0/0/0 up up si-0/0/0.0 up up inet inet6 fe80::2a0:a500:7b:e74f/64 si-0/0/0.1 up up inet si-0/0/0.2 up up inet xe-0/0/0 up down xe-0/0/1 up down xe-0/0/2 up down xe-0/0/3 up down ..... Device: sat-ex4200-1 ---------------------------------- Interface Admin Link Proto Local Remote ge-0/0/1 up up ge-0/0/2 up down ge-0/0/3 up down ge-0/0/4 up down ge-0/0/5 up down ..... Device: sat-ex4200-2 ---------------------------------- Interface Admin Link Proto Local Remote ge-0/0/1 up up .....

The show interfaces jnu physical-interface-name command denotes the 'device all'

parameter, displays the interface information of the named interfaces on all the devices

in the JNU group, such as the controller and all satellites. The physical interface format

is the sameas that of other physical interfaces in the Junos CLI, such as ge-0/0/0 or ae0.

The show interfaces jnu physical-inteface-name.logical-unit-number command denotes

the 'device all' parameter, displays the interface information of the named interfaces on

all the devices in the JNU group, such as the controller and all satellites.

The logical interface format is the same as the naming convention of other logical

interfaces in the Junos CLI, such as ge-0/0/0.1 or ae0.0. If the 'jnu' keyword is used, the

command is run on the satellites; therefore, only the native logical interface format is

supported because the interfaces reside on the satellites and not the port-extender

interfaces (which reside on the controller).

The show interfaces jnu device controller-or-satellite-name command displays the

information of all the interfaces on the specified satellite.

The show interfaces jnu device controller-or-satellite-name physical-interface-name

command displays the information of the specified IFD on the specified satellite.

The show interfaces jnu device controller-or-satellite-name

physical-interface-name.logical-unit command displays the information of the specified

IFL on the specified satellite.



The showinterfacesqueue jnu[devicecontroller-or-satellite-name][(both-ingress-egress

| egress | ingress ) ] [ forwarding-class ] [ l2-statistics ] [ ( ifd | ifl ) ] command displays

the informationof the interfacequeues. If the 'device'option isnot specified, thecommand

is executed on all the devices in the JNU group.

When a port is extended from the satellite to the controller on a logical interface, the

feature on the controller utilizes the logical interface resources. Operational commands

are run only on the controller using the command formats specified on the controller.

You can use the following commands that you could enter using the op scripts until JNU

Release 1.3R2 fromthe JunosCLI interface inexactly thesamemannerasotherembedded,

in-built Junos OS commands.

• You can use the show satellites command to 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.

• The show port-extender operational mode command displays the mapping between

the satellite port and the logical interface that hosts this satellite extended port on the

controller.

The following examples display the output of these commands when they are run from

the Junos CLI interface:

user@controller show satellites Satellite State jnu-sat1 Up jnu-sat2 Down jnu-sat3 Up

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





CHAPTER 9

JNU Operational Mode Commands

Operational mode commands used with JNU are at the user@host> prompt. You run

operational mode commands on the JNU controller.

• show chassis hardware jnu device all

• show interfaces

• show port-extenders

• show satellites

• show version jnu device all

• request-jnu-controller


show chassis hardware jnu device all

Syntax show chassis hardware jnu device all

Release Information Command introduced in JNU 1.3.

Description Display a list of all devices in the JNU group including the hardware version level and

serial number.

Required PrivilegeLevel

view

Sample Output

show chassis hardware jnu device all

user@jnu1-ctrlr> show chassis hardware jnu device allDevice: jnu-sat1----------------------------------Hardware inventory:Item Version Part number Serial number DescriptionChassis JN122E469AFC MX240Midplane REV 07 760-021404 ACRB4299 MX240 BackplaneFPM Board REV 05 760-021392 CABZ0480 Front Panel DisplayPEM 0 Rev 07 740-017343 QCS1128A03C DC Power Entry ModuleRouting Engine 0 REV 18 740-015113 9009163234 RE-S-1300Routing Engine 1 REV 07 740-015113 1000741877 RE-S-1300CB 0 REV 15 710-021523 CABZ7189 MX SCBCB 1 REV 09 710-021523 ABBH2384 MX SCBFPC 1 REV 10 750-044444 CACB3249 MPCE Type 2 3D P CPU REV 06 711-038484 CACH7125 MPCE PMB 2G MIC 0 REV 27 750-028392 CABZ8382 3D 20x 1GE(LAN) SFP PIC 0 BUILTIN BUILTIN 10x 1GE(LAN) SFP Xcvr 0 REV 01 740-038291 AN1310YLV3 SFP-T Xcvr 1 REV 01 740-038291 AN1310YLVQ SFP-T Xcvr 2 REV 01 740-031851 PND6XTW SFP-SX Xcvr 4 REV 01 740-038291 AN1310YKXU SFP-T PIC 1 BUILTIN BUILTIN 10x 1GE(LAN) SFP Xcvr 0 REV 02 740-011613 PQN1056 SFP-SX Xcvr 1 REV 02 740-011613 PQN10CP SFP-SX Xcvr 2 REV 02 740-011613 PQN10BD SFP-SX Xcvr 3 REV 02 740-011613 PQN10GN SFP-SX Xcvr 4 REV 02 740-011613 PQN0MSL SFP-SX Xcvr 5 REV 02 740-011613 PQN11BU SFP-SX Xcvr 6 REV 02 740-011613 PQN108H SFP-SX Xcvr 7 REV 02 740-011613 PQN0MSM SFP-SX Xcvr 8 REV 02 740-011613 PQN0MST SFP-SX Xcvr 9 REV 02 740-011613 PQN0MQE SFP-SX MIC 1 REV 26 750-028392 CAAP9050 3D 20x 1GE(LAN) SFP PIC 2 BUILTIN BUILTIN 10x 1GE(LAN) SFP Xcvr 0 REV 02 740-011613 PQN0MYD SFP-SX Xcvr 1 REV 02 740-011613 PQN11B4 SFP-SX Xcvr 2 REV 02 740-011613 PQN0MYQ SFP-SX Xcvr 3 REV 02 740-011613 PQN10N8 SFP-SX Xcvr 4 REV 02 740-011613 PQN0MY9 SFP-SX Xcvr 5 REV 02 740-011613 PQN11BK SFP-SX Xcvr 6 REV 02 740-011613 PQN10HF SFP-SX Xcvr 7 REV 02 740-011613 PQN0MZ2 SFP-SX



PIC 3 BUILTIN BUILTIN 10x 1GE(LAN) SFP Xcvr 0 REV 01 740-031851 PLB25FK SFP-SX Xcvr 1 REV 01 740-031851 PM20BBX SFP-SX Xcvr 2 REV 01 740-031851 AM1122SUP7T SFP-SX Xcvr 3 REV 02 740-011613 PP72VBE SFP-SX Xcvr 9 REV 02 740-011613 PH25HCQ SFP-SX QXM 0 REV 06 711-028408 CACH0613 MPC QXM QXM 1 REV 06 711-028408 CACH0321 MPC QXMFan Tray 0 REV 01 710-030216 CABV1747 Enhanced Fan Tray

Device: jnu-sat2----------------------------------Hardware inventory:Item Version Part number Serial number DescriptionChassis GG0211086275 EX4500-40FRouting Engine 0 REV 10 750-035700 GG0211086275 EX4500-40FFPC 0 REV 10 750-035700 GG0211086275 EX4500-40F CPU BUILTIN BUILTIN FPC CPU PIC 0 BUILTIN BUILTIN 40x 1/10GE Xcvr 0 REV 02 740-011613 PH25HCP SFP-SX Xcvr 1 REV 01 740-038291 AN1310YLWR SFP-T Xcvr 2 REV 02 740-011613 PQN0MZ9 SFP-SX Xcvr 3 REV 02 740-011613 PQN0MQD SFP-SX Xcvr 4 REV 02 740-011613 PHE2JB0 SFP-SX Xcvr 5 REV 01 740-031851 PNB539S SFP-SX Xcvr 6 REV 01 740-031851 PM307TN SFP-SX Xcvr 7 REV 01 740-011783 PAG40S1 SFP-LX10 Xcvr 10 REV 01 740-011613 PDK32NH SFP-SX Xcvr 11 REV 01 740-031851 PM15CHX SFP-SX PIC 3 REV 01 711-031050 EC0210118389 2x 32GE Virtual Chassis ModulePower Supply 1 REV 02 740-029654 EK0711033453 PS 1000W AC FORWARD AIR FLOW CONTROLFan Tray Fan Tray, Front to back Airflow


Chapter 9: JNU Operational Mode Commands

show interfaces

Syntax show interfaces jnu[devicedevice-name] [interface-name] (brief | extensive | terse |detail)]


Description Displays the specified level of interface information for one or all interfaces on the JNU

controller and satellite devices.

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

display the information.

interface-name—Name of the interface you want to view, such as sat1:ge-0/0/0.100. To

view information for all interfaces in the JNU group, omit the interface name.

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

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

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

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


view

Sample Output

show interfaces jnu

user@jnu1-ctrlr> show interfaces jnuDevice: controller ---------------------------------- Interface Admin Link Proto Local Remote lc-0/0/0 up up lc-0/0/0.32769 up up vpls pfe-0/0/0 up up pfe-0/0/0.16383 up up inet inet6 pfh-0/0/0 up up pfh-0/0/0.16383 up up inet si-0/0/0 up up si-0/0/0.0 up up inet inet6 fe80::2a0:a500:7b:e74f/64 si-0/0/0.1 up up inet si-0/0/0.2 up up inet xe-0/0/0 up down xe-0/0/1 up down xe-0/0/2 up down xe-0/0/3 up down ..... Device: sat-ex4200-1 ---------------------------------- Interface Admin Link Proto Local Remote ge-0/0/1 up up ge-0/0/2 up down



ge-0/0/3 up down ge-0/0/4 up down ge-0/0/5 up down ..... Device: sat-ex4200-2 ---------------------------------- Interface Admin Link Proto Local Remote ge-0/0/1 up up .....



show port-extenders

Syntax show port-extenders


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

the logical interfaceon thecontroller thathostsoranchors theextendedsatellite interface.


view

Sample Output

show port-extenders

user@jnu1-ctrlr> show port-extenders

Port Extender Interface Controller IFL S-VLAN C-VLANjnu-sat1:ge-0/0/10.10 ae0.16384 11 10jnu-sat1:ge-0/0/7.10 ae0.16383 8 10



show satellites

Syntax show satellites


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

the controller.


view

Sample Output

show satellites

user@jnu1-ctrlr> show satellitesSatellite-System State Address Model Version Downlinks

jnu-sat1 Up 192.168.0.2 ex4500-40f 12.3R5.7 ge-1/0/1,ge-1/2/2



show version jnu device all

Syntax show version jnu device all


Description Displays the current software release along with other version details about the JNU

device.


view

Sample Output

show version jnu device all

user@jnu1-ctrlr> show version jnu device allDevice: jnu-sat1----------------------------------Hostname: jnu-sat1Model: mx240Junos: 13.3-20140603.0JUNOS Base OS boot [13.3-20140603.0]JUNOS Base OS Software Suite [13.3-20140603.0]JUNOS Kernel Software Suite [13.3-20140603.0]JUNOS Crypto Software Suite [13.3-20140603.0]JUNOS Packet Forwarding Engine Support (M/T/EX Common) [13.3-20140603.0]JUNOS Packet Forwarding Engine Support (MX Common) [13.3-20140603.0]JUNOS Online Documentation [13.3-20140603.0]JUNOS Services AACL Container package [13.3-20140603.0]JUNOS Services Application Level Gateways [13.3-20140603.0]JUNOS AppId Services [13.3-20140603.0]JUNOS Border Gateway Function package [13.3-20140603.0]JUNOS Services Captive Portal and Content Delivery Container package [13.3-20140603.0]JUNOS Services HTTP Content Management package [13.3-20140603.0]JUNOS IDP Services [13.3-20140603.0]JUNOS Services Jflow Container package [13.3-20140603.0]JUNOS Services LL-PDF Container package [13.3-20140603.0]JUNOS Services MobileNext Software package [13.3-20140603.0]JUNOS Services Mobile Subscriber Service Container package [13.3-20140603.0]JUNOS Services NAT [13.3-20140603.0]JUNOS Services PTSP Container package [13.3-20140603.0]JUNOS Services RPM [13.3-20140603.0]JUNOS Services Stateful Firewall [13.3-20140603.0]JUNOS Voice Services Container package [13.3-20140603.0]JUNOS Services Crypto [13.3-20140603.0]JUNOS Services SSL [13.3-20140603.0]JUNOS Services IPSec [13.3-20140603.0]JUNOS platform Software Suite [13.3-20140603.0]JUNOS Routing Software Suite [13.3-20140603.0]JUNOS Runtime Software Suite [13.3-20140603.0]JUNOS py-base-i386 [13.3-20140603.0]JUNOS Node Unifier Package [1.3J2.4-mx_13.3]

Device: jnu-sat2---------------------------------- fpc0:



--------------------------------------------------------------------------Hostname: jnu-sat2Model: ex4500-40fJUNOS Base OS boot [12.3R5.7]JUNOS Base OS Software Suite [12.3R5.7]JUNOS Kernel Software Suite [12.3R5.7]JUNOS Crypto Software Suite [12.3R5.7]JUNOS Online Documentation [12.3R5.7]JUNOS Enterprise Software Suite [12.3R5.7]JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R5.7]JUNOS Routing Software Suite [12.3R5.7]JUNOS Web Management [12.3R5.7]JUNOS FIPS mode utilities [12.3R5.7]JUNOS Node Unifier Package [1.3J2.3-ex_12.3]



request-jnu-controller

Syntax request jnu controller

Release Information Command introduced in JNU 1.3J1.

Description The first time you initialize JNU on the controller, you must run the request jnu controller

command.



Sample Output





PART 4

Upgrading Software in the JNU Network

• Upgrading Software in the JNU Network on page 101




CHAPTER 10

Upgrading Software in the JNU Network

• Upgrading Junos OS on Satellite Devices on page 101

• Upgrading Junos OS on Satellite Devices From the Controller on page 102

• Upgrading JNU Software on Satellite Devices From the Controller on page 106

• Upgrading Junos OS on the JNU Controller on page 107

• Upgrading JNU Software on Satellite Devices on page 108

• Upgrading JNU Software on Controllers on page 108

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# delete apply-groups jnu-moduleuser@jnu-satellite1# deactivate groups jnu-module

If you are using JNU Release 1.2, 1.3R1, 1.3R2, 1.3Jx, or later, deactivate the

jnu-satellite-mgmt group:

[edit]user@jnu-satellite1# delete apply-groups jnu-satellite-mgmtuser@jnu-satellite1# deactivate groups jnu-satellite-mgmt

If you are using JNU Release 1.3Jx or later, you need not deactivate and reactivate the

JNU groups during the upgrade of the Junos OS image and the installation of the JNU

package on the satellite from the controller. Deactivating jnu-satellite-mgmt group

causes the satellite tobecome inaccessible fromthecontroller. Youneed todeactivate

and reactivate the JNU group only if you are directly installing Junos OS and JNU

applications on the satellite. This prerequisite arises because the event-script, which

is not present after the Junos OS upgrade, is deactivated.



[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, 1.3R1, 1.3R2, 1.3Jx, or later, reactivate 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

If you are using JNU Release 1.3Jx or later, you need not deactivate and reactivate the

JNU groups during the upgrade of the Junos OS image and the installation of the JNU

package on the satellite from the controller. Deactivating jnu-satellite-mgmt group

causes the satellite tobecome inaccessible fromthecontroller. Youneed todeactivate

and reactivate the JNU group only if you are directly installing Junos OS and JNU

applications on the satellite. This prerequisite arises because the event-script, which

is not present after the Junos OS upgrade, is deactivated.


[edit]user@host# commit

Upgrading Junos OS on Satellite Devices From the Controller

Download the software package you need from the Juniper Networks Support Web site

at http://www.juniper.net/support/, and place the package on a local system. You can

then transfer the downloaded package to the device using either the router or switch

command-line interface, or the local system command-line interface.



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

NOTE: To access the download section, youmust have a service contractand an access account. If you need help obtaining an account, complete theregistration form at the Juniper NetworksWeb site:https://www.juniper.net/registration/Register.jsp.

Before you transfer the software package, ensure that the FTP service is enabled on the

device.

Enable the FTP service using the set system services ftp command:

user@host# set system services ftp

Insteadof installing JunosOSand JNU imagepackagesonsatellitesby individually logging

in to the satellites and initiating the installation, you can perform the installation on

satellites from the controller that manages them. This method of installation enables

effectiveandeasymanagementandmaintenanceof thedifferentplatforms that function

as satellites. Youmust ensure that the connection between the satellites and the

controller exists before the installation. Also, you need to transfer the Junos OS image

and JNU package from the server or the host, where the images are available, to the

satellites, before you can install them on satellites from the controller.

To transfer the software package using the device command-line interface:

1. From the router or switch command line, initiate an FTP sessionwith the local system

(host) where the package is located using the ftp command:

user@host> ftp host

host is the Hostname or address of the local system.

2. Log in with your customer support–supplied username and password:

User Name: username331 Password required for username.Password: password

Once your credentials have been validated, the FTP session opens.

3. Navigate to the software package location on the local system, and transfer the

package using the get command:

user@host> get installation-package

Following is an example of an installation-package name:

jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz

4. Close the FTP session using the bye command:

user@host> byeGoodbye

To transfer the package using the local system command-line interface:

1. From the local system command line, initiate an FTP session with the device using

the ftp command:

user@host> ftp host


Chapter 10: Upgrading Software in the JNU Network

https://www.juniper.net/registration/Register.jsp

host is the Hostname or address of the router or switch.

2. Log in with your customer support–supplied username and password:

User Name: username331 Password required for username.Password: password

Once your credentials have been validated, the FTP session opens.

3. Navigate to the software package location on the local system, and transfer the

package using the put command:

user@host> put installation-package

Following is an example of an installation-package name:

jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz

4. Close the FTP session using the bye command:

user@host> byeGoodbye

To upgrade the Junos OS and install the JNU package on your satellite devices from the

controller, perform the following steps:

NOTE: Youmusthaveaconnection running fromthecontroller to thesatellite.

1. Transfer the Junos OS image of the appropriate release from an external server or

host to the satellite.

user@jnu-ctrlr> ftp routing-instance jnu-vrf hostname or ip-addressuser@jnu-ctrlr> put junos-installation-package

user@jnu-ctlr# run ftp routing-instance jnu-vrf 192.168.204.65 Connected to 192.168.204.65.220 headcharge FTP server (Version 6.00LS) ready.Name (192.168.204.65:regress): jnuadmin331 Password required for jnuadmin.Password:230 User jnuadmin logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> cd /var/tmp250 CWD command successful.ftp> put /var/tmp/jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgzlocal: /var/tmp/jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz remote: /var/tmp/jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz200 PORT command successful.150 Opening BINARY mode data connection for '/var/tmp/jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz'.100% |*********************************************************************************************************************| 150 MB 00:00 ETA226 Transfer complete.157989668 bytes sent in 19.50 seconds (7.73 MB/s)ftp> bye221 Goodbye.



2. Install the Junos OS image of the appropriate release on the satellite device from the

controller.

user@jnu-ctrlr> request system software add jnu device deviceftp://hostname/pathname/junos-os-package-name

user@jnu-ctlr# run request system software add jnu device headcharge /var/tmp/jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz

Device: headcharge----------------------------------NOTICE: Validating configuration against jinstall-ex-4300-13.2X51-D27.2-domestic-signed.tgz.NOTICE: Use the 'no-validate' option to skip this if desired.Verify the signature of the new packageVerified jinstall-ex-4300-13.2X51-D27.2-domestic.tgz signed by PackageProduction_13_2_0WARNING: A reboot is required to install the softwareWARNING: Use the 'request system reboot' command immediatelySatellite going down in 1 minute...

3. Transfer the JNU package of the appropriate release from an external server or host

to the satellite.

user@jnu-ctrlr> ftp routing-instance jnu-vrf hostname or ip-addressuser@jnu-ctrlr> put jnu-installation-package

user@jnu-ctlr# run ftp routing-instance jnu-vrf 192.168.204.65

Connected to 192.168.204.65.220 headcharge FTP server (Version 6.00LS) ready.Name (192.168.204.65:regress): jnuadmin331 Password required for jnuadmin.Password:230 User jnuadmin logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> cd /var/tmp250 CWD command successful.ftp> put /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgzlocal: /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz remote: /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz200 PORT command successful.150 Opening BINARY mode data connection for '/var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz'.100% |*********************************************************************************************************************| 959 KB 00:00 ETA226 Transfer complete.982697 bytes sent in 0.09 seconds (10.03 MB/s)ftp> bye221 Goodbye.

4. Install the JNU package on the satellite device from the controller.

user@jnu-ctrlr> request system software add jnu device deviceftp://hostname/pathname/jnu-package-name

user@jnu-ctlr# run request system software add jnu device headcharge /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz

Device: headcharge----------------------------------



WARNING: The software that is being installed has limited support.WARNING: Run 'file show /etc/notices/unsupported.txt' for details.Available space: 124416 require: 2058NOTICE: Validating configuration against jnu-1.4J1.6-ex_ppc_13.2-signed.tgz.NOTICE: Use the 'no-validate' option to skip this if desired.Verified jnu-1.4J1.6-ex_ppc_13.2.tgz signed by PackageDevelopment_13_2_0Adding jnu...WARNING: The software that is being installed has limited support.WARNING: Run 'file show /etc/notices/unsupported.txt' for details.Available space: 124414 require: 3236Mounted jnu package on /dev/md19...Verified manifest signed by PackageDevelopment_13_2_0Verified jnu-1.4J1.6-ex_ppc_13.2 signed by PackageDevelopment_13_2_0Reloading /config/juniper.conf.gz ...Activating /config/juniper.conf.gz ...mgd: configuration check succeedsmgd: commit completeRestarting mgd ...Registering jnu as unsupportedSaving package file in /var/sw/pkg/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz ...Saving state for rollback ...

Upgrading JNU Software on Satellite Devices From the Controller

To upgrade the JNU package on your satellite devices from the controller, perform the

following steps:

NOTE: Youmusthaveaconnection running fromthecontroller to thesatellite.

1. Transfer the JNU package of the appropriate release from an external server or host

to the satellite.

user@jnu-ctrlr> ftp routing-instance jnu-vrf hostname or ip-addressuser@jnu-ctrlr> put jnu-installation-package

user@jnu-ctlr# run ftp routing-instance jnu-vrf 192.168.204.65

Connected to 192.168.204.65.220 headcharge FTP server (Version 6.00LS) ready.Name (192.168.204.65:regress): jnuadmin331 Password required for jnuadmin.Password:230 User jnuadmin logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp> cd /var/tmp250 CWD command successful.ftp> put /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgzlocal: /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz remote: /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz200 PORT command successful.150 Opening BINARY mode data connection for '/var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz'.100% |*********************************************************************************************************************| 959 KB 00:00 ETA226 Transfer complete.



982697 bytes sent in 0.09 seconds (10.03 MB/s)ftp> bye221 Goodbye.

2. Install the JNU package on the satellite device from the controller.

user@jnu-ctrlr> request system software add jnu device deviceftp://hostname/pathname/jnu-package-name

user@jnu-ctlr# run request system software add jnu device headcharge /var/tmp/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz

Device: headcharge----------------------------------WARNING: The software that is being installed has limited support.WARNING: Run 'file show /etc/notices/unsupported.txt' for details.Available space: 124416 require: 2058NOTICE: Validating configuration against jnu-1.4J1.6-ex_ppc_13.2-signed.tgz.NOTICE: Use the 'no-validate' option to skip this if desired.Verified jnu-1.4J1.6-ex_ppc_13.2.tgz signed by PackageDevelopment_13_2_0Adding jnu...WARNING: The software that is being installed has limited support.WARNING: Run 'file show /etc/notices/unsupported.txt' for details.Available space: 124414 require: 3236Mounted jnu package on /dev/md19...Verified manifest signed by PackageDevelopment_13_2_0Verified jnu-1.4J1.6-ex_ppc_13.2 signed by PackageDevelopment_13_2_0Reloading /config/juniper.conf.gz ...Activating /config/juniper.conf.gz ...mgd: configuration check succeedsmgd: commit completeRestarting mgd ...Registering jnu as unsupportedSaving package file in /var/sw/pkg/jnu-1.4J1.6-ex_ppc_13.2-signed.tgz ...Saving state for rollback ...

Upgrading Junos OS on the JNU Controller

To upgrade Junos OS on the JNU controller:

1. Prepare the JNU controller to install the Junos OS image and reboot the controller.

user@jnu-ctrlr> request jnu junos-pre-upgrade hostname/pathname/package-name

2. Reinstall JNU.

user@jnu1-ctrlr> request system software add jnu-1.4J1.4-signed.tgz

Installing package '/var/tmp/jnu-1.4J1.4-signed.tgz' ...Verified jnu-1.4J1.4.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.4J1.4-signed.tgz ...Saving state for rollback ...

3. Reactivate the JNU configuration.

user@jnu-ctrlr> request jnu junos-post-upgrade



Upgrading JNU Software on Satellite Devices

To upgrade the JNU software on satellite devices from the controller:

1. Copy the software package to the satellite device. For example, you can use FTP to

copy the software package:

user@jnu-ctrlr> request system software add jnu device deviceftp://hostname/pathname/package-name

Upgrading JNU Software on Controllers

To upgrade the JNU software on the controller:

1. Copy the software package to the controller. For example, you can use FTP to copy

the software package:

user@jnu-ctrlr> request system software addftp://hostname/pathname/package-name



PART 5

MonitoringandTroubleshooting in the JNUNetwork

• Monitoring in the JNU Network on page 111




CHAPTER 11

Monitoring in the JNU Network


• SNMP Get Process in the JNU Network on page 113

• SNMP Trap Process in the JNU Network on page 114

• System Logging in the JNU Network on page 115

• Network Time Protocol (NTP) in the JNU Network on page 116

• Configuring the JNU Controller as an SNMP Proxy Agent on page 117

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






SNMPGet Process in the JNUNetwork

Figure 6 on page 113 shows the SNMP Get process in the JNU network.

Figure 6: 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 111•




Chapter 11: Monitoring in the JNU Network

SNMP Trap Process in the JNUNetwork

Figure 7 on page 114 shows the SNMP trap process in the JNU network.

Figure 7: 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 8 on page 115 shows how logmessages are processed for JNU satellites.

Figure 8: 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;

}routing-instance jnu-vrf;

}

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.







Documents

Junos® OS Designing and Implementing a Junos Node Unifier … · 2015-02-27 · Junos® OS Designing and Implementing a Junos Node Unifier Network ... Inc