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
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
JNU Release 1.4J1 Design and Implementation Guide
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
JNU Release 1.4J1 Design and Implementation Guide
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•
• Basic Architecture of a JNU Network on page 5
• Terms Used in the JNU Documentation on page 5
• JNUManagement Plane Overview on page 7
3Copyright © 2015, Juniper Networks, Inc.
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.
RelatedDocumentation
Basic Architecture of a JNU Network on page 5•
• Terms Used in the JNU Documentation on page 5
• JNUManagement Plane Overview on page 7
Copyright © 2015, Juniper Networks, Inc.4
JNU Release 1.4J1 Design and Implementation Guide
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
RelatedDocumentation
Junos Node Unifier Overview on page 4•
• Terms Used in the JNU Documentation on page 5
• JNUManagement Plane Overview on page 7
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
5Copyright © 2015, Juniper Networks, Inc.
Chapter 1: Introduction to Junos Node Unifier
RelatedDocumentation
• Junos Node Unifier Overview on page 4
• Basic Architecture of a JNU Network on page 5
• JNUManagement Plane Overview on page 7
Copyright © 2015, Juniper Networks, Inc.6
JNU Release 1.4J1 Design and Implementation Guide
CHAPTER 2
Understanding the JNU Architecture
• JNUManagement Plane Overview on page 7
• 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
RelatedDocumentation
JNUManagement Network on page 8•
• JNU Data Plane Overview on page 10
• Junos Node Unifier Overview on page 4
7Copyright © 2015, Juniper Networks, Inc.
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)
Copyright © 2015, Juniper Networks, Inc.8
JNU Release 1.4J1 Design and Implementation Guide
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.
9Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Understanding the JNU Architecture
RelatedDocumentation
JNUManagement Plane Overview on page 7•
• JNU Data Plane Overview on page 10
• 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
Copyright © 2015, Juniper Networks, Inc.10
JNU Release 1.4J1 Design and Implementation Guide
RelatedDocumentation
• JNUManagement Plane Overview on page 7
• JNUManagement Network on page 8
11Copyright © 2015, Juniper Networks, Inc.
Chapter 2: Understanding the JNU Architecture
Copyright © 2015, Juniper Networks, Inc.12
JNU Release 1.4J1 Design and Implementation Guide
PART 2
Planning a JNU Implementation
• Planning Overview on page 15
• Designs for JNU Implementations on page 17
• Use Cases on page 21
13Copyright © 2015, Juniper Networks, Inc.
Copyright © 2015, Juniper Networks, Inc.14
JNU Release 1.4J1 Design and Implementation Guide
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.
RelatedDocumentation
Supported Platforms for JNU Satellite Devices on page 15•
• Junos Node Unifier Overview on page 4
Supported Platforms for JNU Satellite Devices
JNU 1.4J1 supports the following satellite devices:
• EX3200 Ethernet Switch
• EX3300 Ethernet Switch
• EX4200 Ethernet Switch
• EX4300 Ethernet Switch
• EX4500 Ethernet Switch
• EX4550 Ethernet Switch
• QFX 3500 devices
• QFX 5100 devices
15Copyright © 2015, Juniper Networks, Inc.
RelatedDocumentation
• Platform Considerations for the JNU Controller on page 15
• Junos Node Unifier Overview on page 4
Copyright © 2015, Juniper Networks, Inc.16
JNU Release 1.4J1 Design and Implementation Guide
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
RelatedDocumentation
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
17Copyright © 2015, Juniper Networks, Inc.
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.
RelatedDocumentation
Design 1: One Controller with Satellites in a Star Configuration on page 17•
• Design 3 V topology: Distributed Layer 2 and Layer 3 Mode on page 19
Copyright © 2015, Juniper Networks, Inc.18
JNU Release 1.4J1 Design and Implementation Guide
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.
RelatedDocumentation
• 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
19Copyright © 2015, Juniper Networks, Inc.
Chapter 4: Designs for JNU Implementations
Copyright © 2015, Juniper Networks, Inc.20
JNU Release 1.4J1 Design and Implementation Guide
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.
RelatedDocumentation
Service Provider Edge: Fiber to the Building (FTTB) on page 21•
• Video Streaming on page 22
• Mobile Backhaul on page 22
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
21Copyright © 2015, Juniper Networks, Inc.
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.
RelatedDocumentation
Server Farm: Ethernet Port Fan-Out on page 21•
• Video Streaming on page 22
• Mobile Backhaul on page 22
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.
RelatedDocumentation
Server Farm: Ethernet Port Fan-Out on page 21•
• Service Provider Edge: Fiber to the Building (FTTB) on page 21
• Mobile Backhaul on page 22
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
Copyright © 2015, Juniper Networks, Inc.22
JNU Release 1.4J1 Design and Implementation Guide
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).
RelatedDocumentation
• 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
23Copyright © 2015, Juniper Networks, Inc.
Chapter 5: Use Cases
Copyright © 2015, Juniper Networks, Inc.24
JNU Release 1.4J1 Design and Implementation Guide
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
25Copyright © 2015, Juniper Networks, Inc.
Copyright © 2015, Juniper Networks, Inc.26
JNU Release 1.4J1 Design and Implementation Guide
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.
27Copyright © 2015, Juniper Networks, Inc.
Copyright © 2015, Juniper Networks, Inc.28
JNU Release 1.4J1 Design and Implementation Guide
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 JNUMode on the MX Series Controller on page 32
• Initializing the JNU Controller Without NAT Services on page 36
• Initializing JNUMode on the Satellite Device on page 37
• 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 ...
29Copyright © 2015, Juniper Networks, Inc.
RelatedDocumentation
Initializing JNUMode on the MX Series Controller on page 32•
• Initializing JNUMode on the Satellite Device on page 37
• Installing the JNU Software on Satellite Devices on page 31
Copyright © 2015, Juniper Networks, Inc.30
JNU Release 1.4J1 Design and Implementation Guide
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 ...
RelatedDocumentation
Installing the JNU Software on the Controller on page 29•
• Initializing JNUMode on the Satellite Device on page 37
• Initializing JNUMode on the MX Series Controller on page 32
31Copyright © 2015, Juniper Networks, Inc.
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;
Copyright © 2015, Juniper Networks, Inc.32
JNU Release 1.4J1 Design and Implementation Guide
}}
}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;
33Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
}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;
Copyright © 2015, Juniper Networks, Inc.34
JNU Release 1.4J1 Design and Implementation Guide
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;
}}
}}
}}
35Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
RelatedDocumentation
request-jnu-controller on page 98•
• Installing the JNU Software on the Controller on page 29
• Initializing JNUMode on the Satellite Device on page 37
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.
Copyright © 2015, Juniper Networks, Inc.36
JNU Release 1.4J1 Design and Implementation Guide
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
37Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
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 {
Copyright © 2015, Juniper Networks, Inc.38
JNU Release 1.4J1 Design and Implementation Guide
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.
39Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
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.
user@jnu1-ctrlr> request jnu controllerInitializing Controller...
JNU Controller configuration completed
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.
Copyright © 2015, Juniper Networks, Inc.40
JNU Release 1.4J1 Design and Implementation Guide
user@jnu-satellite1> request jnu satelliteInitializing Satellite...
Commit Completed
JNU Satellite configuration completed
RelatedDocumentation
Initializing JNUMode on the MX Series Controller on page 32•
• Initializing JNUMode on the Satellite Device on page 37
• Installing the JNU Software on Satellite Devices on page 31
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
RelatedDocumentation
Initializing JNUMode on the MX Series Controller on page 32•
• Initializing JNUMode on the Satellite Device on page 37
• Installing the JNU Software on Satellite Devices on page 31
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
41Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
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;
}}
}}
}}
}security {ssh-known-hosts {host 192.168.0.2 {ecdsa-sha2-nistp256-key
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNn6OCxqurMlNxK3G08pCfHEEYMK7k6IBO4csN0M58yow06u+TBk3QtRkjKNzj18Py1Mx48Ml7GcfrC0mAjoTrc=;
}}
}
Copyright © 2015, Juniper Networks, Inc.42
JNU Release 1.4J1 Design and Implementation Guide
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;
}}
}security {ssh-known-hosts {host 192.169.0.2 {ecdsa-sha2-nistp256-key
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNn6OCxqurMlNxK3G08pCfHEEYMK7k6IBO4csN0M58yow06u+TBk3QtRkjKNzj18Py1Mx48Ml7GcfrC0mAjoTrc=;
}}
}
43Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
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
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNn6OCxqurMlNxK3G08pCfHEEYMK7k6IBO4csN0M58yow06u+TBk3QtRkjKNzj18Py1Mx48Ml7GcfrC0mAjoTrc=;
}}
}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;
}}
}}
Copyright © 2015, Juniper Networks, Inc.44
JNU Release 1.4J1 Design and Implementation Guide
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;
}
45Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
}}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;
}....}
}}
RelatedDocumentation
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
Copyright © 2015, Juniper Networks, Inc.46
JNU Release 1.4J1 Design and Implementation Guide
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.
RelatedDocumentation
Initializing JNUMode on the MX Series Controller on page 32•
• Initializing JNUMode on the Satellite Device on page 37
• Installing the JNU Software on Satellite Devices on page 31
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
47Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
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
Copyright © 2015, Juniper Networks, Inc.48
JNU Release 1.4J1 Design and Implementation Guide
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
49Copyright © 2015, Juniper Networks, Inc.
Chapter 7: Getting Started with the JNU Software
Copyright © 2015, Juniper Networks, Inc.50
JNU Release 1.4J1 Design and Implementation Guide
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
51Copyright © 2015, Juniper Networks, Inc.
• 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.
RelatedDocumentation
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.
Copyright © 2015, Juniper Networks, Inc.52
JNU Release 1.4J1 Design and Implementation Guide
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 {
53Copyright © 2015, Juniper Networks, Inc.
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
RelatedDocumentation
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.
Copyright © 2015, Juniper Networks, Inc.54
JNU Release 1.4J1 Design and Implementation Guide
• 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:
55Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
• 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;
Copyright © 2015, Juniper Networks, Inc.56
JNU Release 1.4J1 Design and Implementation Guide
}}
}}
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.
57Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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
Copyright © 2015, Juniper Networks, Inc.58
JNU Release 1.4J1 Design and Implementation Guide
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;
59Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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;}
}
The effective configuration on the sat2 satellite device is:
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;
Copyright © 2015, Juniper Networks, Inc.60
JNU Release 1.4J1 Design and Implementation Guide
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;
}
The effective configuration on the sat1 satellite device is:
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
61Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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.
Copyright © 2015, Juniper Networks, Inc.62
JNU Release 1.4J1 Design and Implementation Guide
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;}
63Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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,
sat2, through the controller:
[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
Copyright © 2015, Juniper Networks, Inc.64
JNU Release 1.4J1 Design and Implementation Guide
The following is an example of an SNMPwalk on all the systemMIBs on the satellite,
sat1, through the controller:
[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,
sat2, through the controller:
[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.
65Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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
Copyright © 2015, Juniper Networks, Inc.66
JNU Release 1.4J1 Design and Implementation Guide
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
67Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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.
Copyright © 2015, Juniper Networks, Inc.68
JNU Release 1.4J1 Design and Implementation Guide
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 {##
69Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
## '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.
Copyright © 2015, Juniper Networks, Inc.70
JNU Release 1.4J1 Design and Implementation Guide
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:
71Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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
Copyright © 2015, Juniper Networks, Inc.72
JNU Release 1.4J1 Design and Implementation Guide
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
73Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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
RelatedDocumentation
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
Copyright © 2015, Juniper Networks, Inc.74
JNU Release 1.4J1 Design and Implementation Guide
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; } }
75Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
}
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 {
Copyright © 2015, Juniper Networks, Inc.76
JNU Release 1.4J1 Design and Implementation Guide
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; }}
77Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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; } }}
Copyright © 2015, Juniper Networks, Inc.78
JNU Release 1.4J1 Design and Implementation Guide
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.
79Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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;
Copyright © 2015, Juniper Networks, Inc.80
JNU Release 1.4J1 Design and Implementation Guide
} }}
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.
81Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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 {
Copyright © 2015, Juniper Networks, Inc.82
JNU Release 1.4J1 Design and Implementation Guide
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.
83Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
• 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.
Copyright © 2015, Juniper Networks, Inc.84
JNU Release 1.4J1 Design and Implementation Guide
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
85Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
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.
Copyright © 2015, Juniper Networks, Inc.86
JNU Release 1.4J1 Design and Implementation Guide
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 ...
87Copyright © 2015, Juniper Networks, Inc.
Chapter 8: JNU Port Extender ModeWith Junos OS CLI Interface
Copyright © 2015, Juniper Networks, Inc.88
JNU Release 1.4J1 Design and Implementation Guide
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
89Copyright © 2015, Juniper Networks, Inc.
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
Copyright © 2015, Juniper Networks, Inc.90
JNU Release 1.4J1 Design and Implementation Guide
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
91Copyright © 2015, Juniper Networks, Inc.
Chapter 9: JNU Operational Mode Commands
show interfaces
Syntax show interfaces jnu[devicedevice-name] [interface-name] (brief | extensive | terse |detail)]
Release Information Command introduced in JNU 1.3.
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.
Required PrivilegeLevel
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
Copyright © 2015, Juniper Networks, Inc.92
JNU Release 1.4J1 Design and Implementation Guide
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 .....
93Copyright © 2015, Juniper Networks, Inc.
Chapter 9: JNU Operational Mode Commands
show port-extenders
Syntax show port-extenders
Release Information Command introduced in JNU 1.3.
Description Display the mapping between a satellite interface that is extended to a controller and
the logical interfaceon thecontroller thathostsoranchors theextendedsatellite interface.
Required PrivilegeLevel
view
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
Copyright © 2015, Juniper Networks, Inc.94
JNU Release 1.4J1 Design and Implementation Guide
show satellites
Syntax show satellites
Release Information Command introduced in JNU 1.3.
Description Displays the state of each satellite to determine if the satellite is up and connected to
the controller.
Required PrivilegeLevel
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
95Copyright © 2015, Juniper Networks, Inc.
Chapter 9: JNU Operational Mode Commands
show version jnu device all
Syntax show version jnu device all
Release Information Command introduced in JNU 1.3.
Description Displays the current software release along with other version details about the JNU
device.
Required PrivilegeLevel
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:
Copyright © 2015, Juniper Networks, Inc.96
JNU Release 1.4J1 Design and Implementation Guide
--------------------------------------------------------------------------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]
97Copyright © 2015, Juniper Networks, Inc.
Chapter 9: JNU Operational Mode Commands
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.
RelatedDocumentation
Initializing JNUMode on the MX Series Controller on page 32•
Sample Output
user@jnu1-ctrlr> request jnu controllerInitializing Controller...
JNU Controller configuration completed
Copyright © 2015, Juniper Networks, Inc.98
JNU Release 1.4J1 Design and Implementation Guide
PART 4
Upgrading Software in the JNU Network
• Upgrading Software in the JNU Network on page 101
99Copyright © 2015, Juniper Networks, Inc.
Copyright © 2015, Juniper Networks, Inc.100
JNU Release 1.4J1 Design and Implementation Guide
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.
2. Commit the changes.
101Copyright © 2015, Juniper Networks, Inc.
[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.
6. Commit the changes.
[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.
Copyright © 2015, Juniper Networks, Inc.102
JNU Release 1.4J1 Design and Implementation Guide
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
103Copyright © 2015, Juniper Networks, Inc.
Chapter 10: Upgrading Software in the JNU Network
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.
Copyright © 2015, Juniper Networks, Inc.104
JNU Release 1.4J1 Design and Implementation Guide
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----------------------------------
105Copyright © 2015, Juniper Networks, Inc.
Chapter 10: Upgrading Software in the JNU Network
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.
Copyright © 2015, Juniper Networks, Inc.106
JNU Release 1.4J1 Design and Implementation Guide
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
107Copyright © 2015, Juniper Networks, Inc.
Chapter 10: Upgrading Software in the JNU Network
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
Copyright © 2015, Juniper Networks, Inc.108
JNU Release 1.4J1 Design and Implementation Guide
PART 5
MonitoringandTroubleshooting in the JNUNetwork
• Monitoring in the JNU Network on page 111
109Copyright © 2015, Juniper Networks, Inc.
Copyright © 2015, Juniper Networks, Inc.110
JNU Release 1.4J1 Design and Implementation Guide
CHAPTER 11
Monitoring in the JNU Network
• Centralized Collection of SNMP Statistics and Log Messages Overview on page 111
• 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.
111Copyright © 2015, Juniper Networks, Inc.
This process means that all logging traffic originates from one source address on the
controller.
RelatedDocumentation
Configuring the JNU Controller as an SNMP Proxy Agent on page 117•
• 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
Copyright © 2015, Juniper Networks, Inc.112
JNU Release 1.4J1 Design and Implementation Guide
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.
RelatedDocumentation
Centralized Collection of SNMP Statistics and Log Messages Overview on page 111•
• Configuring the JNU Controller as an SNMP Proxy Agent on page 117
• SNMP Trap Process in the JNU Network on page 114
113Copyright © 2015, Juniper Networks, Inc.
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.
RelatedDocumentation
Centralized Collection of SNMP Statistics and Log Messages Overview on page 111•
• Configuring the JNU Controller as an SNMP Proxy Agent on page 117
• SNMP Get Process in the JNU Network on page 113
• System Logging in the JNU Network on page 115
Copyright © 2015, Juniper Networks, Inc.114
JNU Release 1.4J1 Design and Implementation Guide
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.
RelatedDocumentation
Centralized Collection of SNMP Statistics and Log Messages Overview on page 111•
• SNMP Get Process in the JNU Network on page 113
• SNMP Trap Process in the JNU Network on page 114
115Copyright © 2015, Juniper Networks, Inc.
Chapter 11: Monitoring in the JNU Network
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.
Copyright © 2015, Juniper Networks, Inc.116
JNU Release 1.4J1 Design and Implementation Guide
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.
117Copyright © 2015, Juniper Networks, Inc.
Chapter 11: Monitoring in the JNU Network
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.
RelatedDocumentation
• Centralized Collection of SNMP Statistics and Log Messages Overview on page 111
• SNMP Get Process in the JNU Network on page 113
• SNMP Trap Process in the JNU Network on page 114
Copyright © 2015, Juniper Networks, Inc.118
JNU Release 1.4J1 Design and Implementation Guide