Config Guide PSD

®
Junos OS
Protected System Domain Configuration Guide
Release
11.1
Published: 2011-01-20
Copyright © 2011, Juniper Networks, Inc.

Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
This product includes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997,
Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part
of them is in the public domain.
This product includes memory allocation software developed by Mark Moraes, copyright © 1988, 1989, 1993, University of Toronto.
This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation
and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright ©
1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.
GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through
release 3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s
HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD
software copyright © 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright © 1991, D.
L. S. Associates.
This product includes software developed by Maker Communications, Inc., copyright © 1996, 1997, Maker Communications, Inc.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other
trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,
6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
®
Junos OS Protected System Domain Configuration Guide
Release 11.1
Copyright © 2011, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History
January 2011— R 1 Junos OS 11.1
The information in this document is current as of the date listed in the revision history.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. The Junos OS has no known time-related limitations through
the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
ii Copyright © 2011, Juniper Networks, Inc.

END USER LICENSE AGREEMENT
READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE.
BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS
CONTAINED HEREIN, YOU (AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO
BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED
HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS
REGARDING LICENSE TERMS.
1. The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or
Juniper Networks (Cayman) Limited (if the Customer’s principal office is located outside the Americas) (such applicable entity being referred
to herein as “Juniper”), and (ii) the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable
license(s) for use of the Software (“Customer”) (collectively, the “Parties”).
2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for
which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by
Juniper in equipment which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades
and new releases of such software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper
equipment and any updates, upgrades, additions or replacements which are subsequently embedded in or loaded onto the equipment.
3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer
a non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the
following use restrictions:
a. Customer shall use Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by
Customer from Juniper or an authorized Juniper reseller.
b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units
for which Customer has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access
Client software only, Customer shall use such Software on a single computer containing a single physical random access memory space
and containing any number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines
(e.g., Solaris zones) requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single
chassis.
c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may
specify limits to Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, concurrent
users, sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of
separate licenses to use particular features, functionalities, services, applications, operations, or capabilities, or provide throughput,
performance, configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use
of the Software to managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software.
Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.
d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the
Software. Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not
extend or create an additional trial period by re-installing the Software after the 30-day trial period.
e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s
enterprise network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the
Steel-Belted Radius software to support any commercial network access services.
The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase
the applicable license(s) for the Software from Juniper or an authorized Juniper reseller.
4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees
not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized
copies of the Software (except as necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the
Software, in any form, to any third party; (d) remove any proprietary notices, labels, or marks on or in any copy of the Software or any product
in which the Software is embedded; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper
equipment sold in the secondhand market; (f) use any ‘locked’ or key-restricted feature, function, service, application, operation, or capability
without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, service, application,
operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the
Copyright © 2011, Juniper Networks, Inc. iii

Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i)
use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that
the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking
of the Software to any third party without the prior written consent of Juniper; or (l) use the Software in any manner other than as expressly
provided herein.
5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper,
Customer shall furnish such records to Juniper and certify its compliance with this Agreement.
6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper.
As such, Customer shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence,
which at a minimum includes restricting access to the Software to Customer employees and contractors having a need to use the Software
for Customer’s internal business purposes.
7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to
the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance
of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies
of the Software.
8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty
statement that accompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support
the Software. Support services may be purchased separately. Any such support shall be governed by a separate, written support services
agreement. TO THE MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA,
OR COSTS OR PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER
BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE.
EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY
AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES
JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT
ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’
or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid
by Customer for the Software that gave rise to the claim, or if the Software is embedded in another Juniper product, the price paid by
Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered into this Agreement in
reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between
the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same
form an essential basis of the bargain between the Parties.
9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination
of the license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related
documentation in Customer’s possession or control.
10. Taxes. All license fees payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from
the purchase of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction
shall be provided to Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All
payments made by Customer shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in
connection with such withholding taxes by promptly: providing Juniper with valid tax receipts and other required documentation showing
Customer’s payment of any withholding taxes; completing appropriate applications that would reduce the amount of withholding tax to
be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder. Customer shall comply with
all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related to any
liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under
this Section shall survive termination or expiration of this Agreement.
11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any
applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such
restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the
Software supplied to Customer may contain encryption or other capabilities restricting Customer’s ability to export the Software without
an export license.
iv Copyright © 2011, Juniper Networks, Inc.

12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use,
duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS
227.7201 through 227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.
13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer
with the interface information needed to achieve interoperability between the Software and another independently created program, on
payment of applicable fee, if any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use
such information in compliance with any applicable terms and conditions upon which Juniper makes such information available.
14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products
or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement,
and such licensor or vendor shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party
software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent
portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such
portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper
will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three
years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA
94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL
at http://www.gnu.org/licenses/lgpl.html .
15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws
principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes
arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal
courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer
with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written
(including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an
authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained
herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing
by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity
of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the
Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de
même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that
this Agreement and all related documentation is and will be in the English language)).
Copyright © 2011, Juniper Networks, Inc. v

vi Copyright © 2011, Juniper Networks, Inc.
Abbreviated Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Part 1 Product Overview

Chapter 1 JCS1200 Chassis and T Series Routers as a Single Platform . . . . . . . . . . . . . 3
Chapter 2 JCS1200 and T Series Platform Software Views . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 3 JCS1200 Platform Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Part 2 Configuration Overview

Chapter 4 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 5 Configuration Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Part 3 Configuring the JCS1200 Platform

Chapter 6 Configuring Basic System Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 7 Configuring the Routing Engines on the JCS1200 Platform . . . . . . . . . . . . . 49
Chapter 8 Summary of JCS Management Module Configuration Commands . . . . . . . 53
Part 4 Configuring the Junos OS

Chapter 9 Configuring an RSD and Creating PSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Chapter 10 Configuring Basic System Properties on a New PSD . . . . . . . . . . . . . . . . . . . 87
Chapter 11 Configuring Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Chapter 12 Configuring Inter-PSD Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Chapter 13 Summary of Junos Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 113
Part 5 Configuration Examples

Chapter 14 Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Part 6 Managing the JCS1200 Platform

Chapter 15 Managing the JCS1200 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Chapter 16 Summary of JCS Management Module Monitoring Commands . . . . . . . . 209
Part 7 Managing RSDs and PSDs

Chapter 17 Managing the Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Part 8 Appendix
Appendix A Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Copyright © 2011, Juniper Networks, Inc. vii

JUNOS OS 11.1 Protected System Domain Configuration Guide
Part 9 Indexes
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
viii Copyright © 2011, Juniper Networks, Inc.

Table of Contents
JUNOS Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Supported Routing Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Using the Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii
Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
JCS1200 Chassis and T Series Core Routers as a Single Platform . . . . . . . . . . 3
Root System Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Protected System Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Inter-PSD Forwarding Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Route Reflection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Connections Between JCS1200 and T Series Chassis . . . . . . . . . . . . . . . . . . . 11
Benefits of JCS1200 and T Series as a Single Platform . . . . . . . . . . . . . . . . . . 13
Network Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Enhanced Security and Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Cost Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Faster Deployment of New Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Chapter 2 JCS1200 and T Series Platform Software Views . . . . . . . . . . . . . . . . . . . . . . . 17
Software Views Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
JCS Administration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Types of JCS Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
How Command Targets and User Permissions Impact Views . . . . . . . . . . . . . 18
RSD Administration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Access Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Copyright © 2011, Juniper Networks, Inc. ix

PSD Administration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Access Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
JCS1200 Platform Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Default Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Routing Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Management Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Switch Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Media Tray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Power Supply Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Fan Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
JCS1200 Software Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
JCS Management Module CLI Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Logging In to the JCS Management Module CLI . . . . . . . . . . . . . . . . . . . . . . . 24
Getting Help on JCS Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Setting the JCS Management Module Command Target . . . . . . . . . . . . . . . . 25
JCS Switch Module Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
JCS1200 Platform Graceful Routing Engine (GRES) Switchover . . . . . . . . . . . . . . 27
Graceful Routing Engine Switchover Overview . . . . . . . . . . . . . . . . . . . . . . . . 27
Graceful Routing Engine Switchover PIC Support . . . . . . . . . . . . . . . . . . . . . . 27
Part 2 Configuration Overview

Chapter 4 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Verifying the FPC BootROM Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Keeping the JCS Management Module Default SNMP Setting . . . . . . . . . . . . . . . 32
Chapter 5 Configuration Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Configuration Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Step One: Configure the JCS1200 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Step Two: Configure the T Series Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Step Three: Configure Basic System Properties on a New PSD . . . . . . . . . . . 34
Step Four: Configure Shared Interfaces (Optional) . . . . . . . . . . . . . . . . . . . . . 35

Chapter 6 Configuring Basic System Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Configuring JCS Management Module Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Restoring the Default JCS Management Module Configuration . . . . . . . . . . . 40
Configuring the JCS Management Module Ethernet Interface . . . . . . . . . . . . 40
Configuring the Switch Module Ethernet Interface . . . . . . . . . . . . . . . . . . . . . 41
Configuring User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Configuring the NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Configuring the Time Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
x Copyright © 2011, Juniper Networks, Inc.

Table of Contents
Configuring the System Name and Contact Information . . . . . . . . . . . . . . . . 43

Configuring SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Configuring the SNMP Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Configuring Alert Entries for SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Configuring Monitored Alerts for SNMP Traps . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring SSH Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Generating the Host Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Adding the User Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring the JCS Switch Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Upgrading a JCS1200 Route Reflector to 64-Bit Junos OS . . . . . . . . . . . . . . . . . . 49
Downloading 64-Bit Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Installing 64-Bit Junos OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Configuring the Routing Engine Parameters (Blade Bay Data) . . . . . . . . . . . . . . . 51
Configuring the Routing Engine (Blade) Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
alertentries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
baydata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
env . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
ifconfig (JCS Management Module) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
ifconfig (JCS Switch Module) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
monalerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
mt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
ntp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
snmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
sshcfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Chapter 9 Configuring an RSD and Creating PSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
System Domains Configuration Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Configuring an RSD and Creating PSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Chapter 10 Configuring Basic System Properties on a New PSD . . . . . . . . . . . . . . . . . . . 87
Configuring a PSD with a Single Routing Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring a PSD with Redundant Routing Engines . . . . . . . . . . . . . . . . . . . . . . . 89
Chapter 11 Configuring Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Interfaces Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Configuring Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Before You Configure Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Configuring Shared Interfaces on the RSD . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Configuring Shared Interfaces on a PSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Copyright © 2011, Juniper Networks, Inc. xi

Configuring Firewall Filters on Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . 102

Configuring CoS Features on Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . 104
Interface Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Configuring Inter-PSD Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Before You Configure Inter-PSD Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring Inter-PSD Forwarding on a PSD . . . . . . . . . . . . . . . . . . . . . . . . . 108
Chapter 13 Summary of Junos Configuration Statements . . . . . . . . . . . . . . . . . . . . . . . . 113
control-plane-bandwidth-percent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
control-slot-numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
control-system-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
fpcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
interface-shared-with . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
peer-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
peer-psd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
protected-system-domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
root-domain-id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
shared-interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
system-domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Example: Configuring a JCS1200 Platform and a Single T Series Router . . . . . . . 123
Example: Configuring a JCS1200 Platform and Multiple T Series Routers . . . . . . 128
Example: Configuring Shared Interfaces (SONET) . . . . . . . . . . . . . . . . . . . . . . . . 136
Example: Configuring Shared Interfaces (Ethernet) . . . . . . . . . . . . . . . . . . . . . . . 147
Example: Configuring Route Reflection—Roadmap . . . . . . . . . . . . . . . . . . . . . . . 157
Example: Configuring the JCS1200 Platform as a Route Reflector . . . . . . . . . . . . 157
Example: Configuring Client-to-Client Reflection (OSPF) . . . . . . . . . . . . . . . . . . 166
Example: Consolidating a Layer 2 VPN Network . . . . . . . . . . . . . . . . . . . . . . . . . . 177

JCS Management Module Verification Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Displaying Vital Product Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Clearing the Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Displaying the Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Displaying Power Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Displaying System Component Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Displaying a List of Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Displaying Temperature Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Displaying Voltage Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
clearlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
xii Copyright © 2011, Juniper Networks, Inc.

Table of Contents
displaylog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
fuelg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
volts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Logging In to a PSD from the RSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Junos OS Verification Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Displaying Hardware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Displaying Configured PSDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Displaying Routing Engine Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Displaying Ethernet Switch Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Displaying Shared Interface Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Displaying Inter-PSD Forwarding Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Part 8 Appendix
Appendix A Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Troubleshooting a Routing Engine on the JCS1200 Platform . . . . . . . . . . . . . . . . 253
Restarting a Routing Engine on the JCS1200 Platform . . . . . . . . . . . . . . . . . . . . 254
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Part 9 Indexes
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Index of Statements and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Copyright © 2011, Juniper Networks, Inc. xiii

xiv Copyright © 2011, Juniper Networks, Inc.

List of Figures
Figure 1: Protected System Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2: Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 3: Typical Network of Route Reflectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 4: Route Reflectors on the JCS1200 Platform . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 5: Route Reflector Partitioning on the JCS1200 Platform . . . . . . . . . . . . . . 10
Figure 6: Route Reflector Interfaces and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 7: JCS Switch Module Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 8: Connections Between JCS1200 and T Series Platforms . . . . . . . . . . . . . 12
Figure 9: Network Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 10: JCS Management Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 11: JCS Media Tray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 12: Example: Inter-PSD Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Figure 13: Example: Shared Interfaces (SONET) . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Figure 14: Example: Shared Interfaces (Gigabit Ethernet) . . . . . . . . . . . . . . . . . . 148
Figure 15: Example: Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Figure 16: Example: Configuring Client-to-Client Reflection (OSPF) . . . . . . . . . . 167
Figure 17: Typical Layer 2 VPN Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 18: Consolidated Layer 2 VPN Network Topology . . . . . . . . . . . . . . . . . . . . 178
Copyright © 2011, Juniper Networks, Inc. xv

xvi Copyright © 2011, Juniper Networks, Inc.

List of Tables
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Table 2: PICs Supporting Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 3: Syntax Conventions for JCS Management Module CLI Help . . . . . . . . . . 25
Table 4: Target Paths for JCS Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Table 5: Format Requirements for Blade Bay Data . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 6: alertentries Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 7: baydata Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 8: config Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 9: ifconfig Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 10: ifconfig Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table 11: monalerts Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Table 12: ntp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Table 13: snmp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Table 14: sshcfg Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Table 15: users Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Table 16: Example: Inter-PSD Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Table 17: JCS Chassis Routing Engine Assignments . . . . . . . . . . . . . . . . . . . . . . . 129
Table 18: T320 Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Table 19: T640 Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Table 20: T1600 Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Table 21: Chassis Parameters for Route Reflection . . . . . . . . . . . . . . . . . . . . . . . . 158
Copyright © 2011, Juniper Networks, Inc. xvii

Table 22: Chassis Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Table 23: Summary of Commonly Used JCS Management Module Verification
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Table 24: displaylog Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Table 25: fuelg Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Table 26: info Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Table 27: temps Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Table 28: volts Output Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

Table 29: Commands Used to Verify PSD and RSD Status . . . . . . . . . . . . . . . . . 238
xviii Copyright © 2011, Juniper Networks, Inc.

About This Guide
®
This preface provides the following guidelines for using the Junos OS Protected System
Domain Configuration Guide:
• JUNOS Documentation and Release Notes on page xix

• Objectives on page xx
• Audience on page xx
• Supported Routing Platforms on page xxi
• Using the Indexes on page xxi
• Using the Examples in This Manual on page xxi
• Documentation Conventions on page xxiii
• Documentation Feedback on page xxiii
• Requesting Technical Support on page xxiii
JUNOS Documentation and Release Notes
For a list of related JUNOS documentation, see

http://www.juniper.net/techpubs/software/junos/ .
If the information in the latest release notes differs from the information in the
documentation, follow the JUNOS Release Notes.
®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
Juniper Networks supports a technical book program to publish books by Juniper Networks
engineers and subject matter experts with book publishers around the world. These
books go beyond the technical documentation to explore the nuances of network
architecture, deployment, and administration using the Junos operating system (Junos
OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library,
published in conjunction with O'Reilly Media, explores improving network security,
reliability, and availability using Junos OS configuration techniques. All the books are for
sale at technical bookstores and book outlets around the world. The current list can be
viewed at http://www.juniper.net/books .
Copyright © 2011, Juniper Networks, Inc. xix

Objectives
This guide is designed to provide an overview of the Juniper Networks JCS1200 Control
System and the concept of Protected System Domains (PSDs). The JCS1200 platform,
which contains up to 12 Routing Engines (or 6 redundant Routing Engine pairs) running
Junos OS, is connected to up to three T Series routers , including any combination of
T320 Core Routers, T640 Core Routers, and T1600 Core Routers.
The Junos OS running on a pair of redundant Routing Engines on a T Series router is

considered a Root System Domain (RSD). In the RSD configuration, you create a PSD
by assigning one or more Flexible PIC Concentrators (FPCs) on a T Series router to a
Routing Engine (or redundant Routing Engine pair) on the JCS1200 platform. Each PSD
has the same capabilities and functionality as a physical router, with its own control
plane, forwarding plane, and administration.
RSDs and PSDs can run different versions of Junos OS. Each RSD and PSD must be
running Junos OS Release 9.4 or later.
Different PSDs can share interfaces on a single Physical Interface Card (PIC) owned by
the RSD. The RSD and PSDs must be running Junos OS Release 9.3 or later.
NOTE: This guide documents Release 11.1 of the Junos OS. For additional
information about the Junos OS—either corrections to or information that
might have been omitted from this guide—see the software release notes at
http://www.juniper.net/.
Audience
This guide is designed for network administrators who are configuring and monitoring a
Juniper Networks T Series router and JCS1200 platform.
To use this guide, you need a broad understanding of networks in general, the Internet
in particular, networking principles, and network configuration. You must also be familiar
with one or more of the following Internet routing protocols:
• Border Gateway Protocol (BGP)
• Distance Vector Multicast Routing Protocol (DVMRP)
• Intermediate System-to-Intermediate System (IS-IS)
• Internet Control Message Protocol (ICMP) router discovery
• Internet Group Management Protocol (IGMP)
• Multiprotocol Label Switching (MPLS)
• Open Shortest Path First (OSPF)
• Protocol-Independent Multicast (PIM)
• Resource Reservation Protocol (RSVP)
xx Copyright © 2011, Juniper Networks, Inc.

About This Guide
• Routing Information Protocol (RIP)
• Simple Network Management Protocol (SNMP)
Personnel operating the equipment must be trained and competent; must not conduct
themselves in a careless, willfully negligent, or hostile manner; and must abide by the
instructions provided by the documentation.
Supported Routing Platforms
For the features described in this manual, the Junos OS currently supports the following
routing platforms:
• T320 Core Routers, T640 Core Routers, and T1600 Core Routers
• Juniper Networks JCS1200 Control System
Using the Indexes
This guide contains two indexes: a complete index of all index entries, and an index of
statements and commands only.
The complete index points to pages in the statement summary chapters. The index entry
for each configuration statement contains at least two entries:
• The first entry points to the statement summary section.
• The second entry, usage guidelines, points to the section in a configuration guidelines
chapter that describes how to use the statement.
Using the Examples in This Manual
If you want to use the examples in this manual, you can use the load merge or the load
merge relative command. These commands cause the software to merge the incoming
configuration into the current candidate configuration. If the example configuration
contains the top level of the hierarchy (or multiple hierarchies), the example is a full
example. In this case, use the load merge command.
If the example configuration does not start at the top level of the hierarchy, the example
is a snippet. In this case, use the load merge relative command. These procedures are
described in the following sections.
Merging a Full Example

To merge a full example, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration example into a
text file, save the file with a name, and copy the file to a directory on your routing
platform.
For example, copy the following configuration to a file and name the file ex-script.conf.
Copy the ex-script.conf file to the /var/tmp directory on your routing platform.
Copyright © 2011, Juniper Networks, Inc. xxi

system {
scripts {
commit {
file ex-script.xsl;
}
}
}
interfaces {
fxp0 {
disable;
unit 0 {
family inet {
address 10.0.0.1/24;
}
}
}
}
2. Merge the contents of the file into your routing platform configuration by issuing the
load merge configuration mode command:
[edit]
user@host# load merge /var/tmp/ex-script.conf
load complete
Merging a Snippet
To merge a snippet, follow these steps:
1. From the HTML or PDF version of the manual, copy a configuration snippet into a text
file, save the file with a name, and copy the file to a directory on your routing platform.
For example, copy the following snippet to a file and name the file
ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory
on your routing platform.
commit {
file ex-script-snippet.xsl; }
2. Move to the hierarchy level that is relevant for this snippet by issuing the following
configuration mode command:
[edit]
user@host# edit system scripts
[edit system scripts]
3. Merge the contents of the file into your routing platform configuration by issuing the
load merge relative configuration mode command:
[edit system scripts]

user@host# load merge relative /var/tmp/ex-script-snippet.conf
load complete
For more information about the load command, see the Junos OS CLI User Guide.
xxii Copyright © 2011, Juniper Networks, Inc.

About This Guide
Documentation Conventions
Table 1 on page xxiii defines notice icons used in this guide.
Table 1: Notice Icons

Icon Meaning Description
Informational note Indicates important features or instructions.
Caution Indicates a situation that might result in loss of data or hardware damage.
Warning Alerts you to the risk of personal injury or death.
Laser warning Alerts you to the risk of personal injury from a laser.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can

improve the documentation. You can send your comments to
techpubs-comments@juniper.net, or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include
the following information with your comments:
• Document or topic name
• URL or page number
• Software release version (if applicable)
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
or are covered under warranty, and need post-sales technical support, you can access
our tools and resources online or open a case with JTAC.
• JTAC policies—For a complete understanding of our JTAC procedures and policies,

review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf .
• Product warranties—For product warranty information, visit

http://www.juniper.net/support/warranty/ .
Copyright © 2011, Juniper Networks, Inc. xxiii

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
• Find CSC offerings: http://www.juniper.net/customers/support/
• Search for known bugs: http://www2.juniper.net/kb/
• Find product documentation: http://www.juniper.net/techpubs/
• Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
• Download the latest versions of software and review release notes:

http://www.juniper.net/customers/csc/software/
• Search technical bulletins for relevant hardware and software notifications:

https://www.juniper.net/alerts/
• Join and participate in the Juniper Networks Community Forum:

http://www.juniper.net/company/communities/
• Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.
• Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see

http://www.juniper.net/support/requesting-support.html .
xxiv Copyright © 2011, Juniper Networks, Inc.

PART 1
Product Overview
• JCS1200 Chassis and T Series Routers as a Single Platform on page 3
• JCS1200 and T Series Platform Software Views on page 17
• JCS1200 Platform Components on page 21
Copyright © 2011, Juniper Networks, Inc. 1

2 Copyright © 2011, Juniper Networks, Inc.

CHAPTER 1
JCS1200 Chassis and T Series Routers as

a Single Platform
• Product Overview on page 3
Product Overview
The JCS1200 chassis and T Series routers as a single platform include the following
components and product benefits:
• JCS1200 Chassis and T Series Core Routers as a Single Platform on page 3

• Root System Domains on page 4
• Protected System Domains on page 4
• Shared Interfaces on page 5
• Inter-PSD Forwarding Overview on page 8
• Route Reflection Overview on page 8
• Connections Between JCS1200 and T Series Chassis on page 11
• Benefits of JCS1200 and T Series as a Single Platform on page 13
JCS1200 Chassis and T Series Core Routers as a Single Platform

The Juniper Networks JCS1200 Control System (JCS) chassis interconnected with up to
three T Series routing chassis enables the control plane (route processing) and forwarding
plane (packet forwarding) to be scaled independently within a single platform. The
JCS1200 chassis houses up to 6 redundant Routing Engine pairs or up to 12 single Routing
Engines running Junos OS. Matched with one or more Flexible PIC Concentrators (FPCs)
on a T Series router, the selected Routing Engine pair (or single Routing Engine) forms a
secure, virtual hardware router, or Protected System Domain (PSD). A PSD has the same
capabilities as a separate, physical router with its own control plane, configuration file,
routing tables, interfaces, and secure access.
Existing Juniper Networks technology already separates the tasks of the Routing Engine
from the Packet Forwarding Engine on a single routing platform. Each component
performs its primary tasks independently, while constantly communicating through a
high-speed internal link. This arrangement provides streamlined forwarding and routing
control and the capability to run Internet-scale networks at high speeds. Now, with
Routing Engines located in a separate chassis, the JCS1200 platform provides a greatly

expanded control plane capacity without sacrificing any forwarding slots in the T Series
router. All memory-intensive processing occurs on the Routing Engines on the JCS chassis,
whereas the FPCs on the T Series router are dedicated to efficient high-speed forwarding.
Related • Root System Domains on page 4

Documentation
Root System Domains

The Root System Domain (RSD) is the Junos OS running on a pair of redundant Routing
Engines on a T Series router connected to the switch fabric on the JCS1200 platform.
The configuration on these Routing Engines provides:
• The RSD identifier
• The parameters used to create Protected System Domains (PSDs) under the RSD,
namely:
• Which Routing Engine or redundant Routing Engine pair on the JCS1200 platform is
assigned to the PSD.
• Which Flexible PIC Concentrator (FPC) or FPCs on the T Series router are assigned
to the PSD.
Because you can connect up to three T Series routers to the JCS1200 chassis, you can
configure up to three RSDs. The PSD identifiers must be unique for each RSD. That is,
PSD1 can only belong to RSD1, and not to RSD2 or RSD3.
Related • JCS1200 Chassis and T Series Core Routers as a Single Platform on page 3
Documentation
Protected System Domains

A Protected System Domain (PSD) is a redundant Routing Engine pair (or single Routing
Engine) on the JCS1200 platform matched with one or more Flexible PIC Concentrators
(FPCs) on a T Series router. In Figure 1 on page 5, FPC1 and FPC2 and the Routing Engines
in slots 1 and 2 belong to PSD1. In contrast, PSD2 is made up of the FPCs in slots 3 and 4
on the T Series router and the Routing Engines in slots 3 and 4 on the JCS1200 chassis.

Chapter 1: JCS1200 Chassis and T Series Routers as a Single Platform
Figure 1: Protected System Domain
Any number of FPCs can be assigned to a PSD. Only one redundant Routing Engine pair
(or single Routing Engine) can be assigned to a PSD.
NOTE: When an FPC is not assigned to a PSD, it belongs to the Root System
Domain (RSD) by default. A Physical Interface Card (PIC) on an FPC owned
by the RSD can be configured as an interface that is shared by multiple PSDs.
For more information, see “Shared Interfaces” on page 5.
You create each PSD under the RSD configuration through the Junos OS running on the
Routing Engines on the T Series router. Once a PSD is configured, you access it as you
would any separate physical router by connecting to the console port on the master
Routing Engine on the JCS1200 chassis for the PSD you want to configure. Using the
Junos OS, configure basis system properties, such as hostname, domain name, Ethernet
management IP address, and so on. You can also download a configuration file to the
PSD.
A PSD detects and manages only its own Routing Engines in the JCS1200 chassis and
the assigned FPCs and PICs in the T Series router. In addition, failures on one PSD do not
affect other PSDs.

Documentation
Shared Interfaces
A single Physical Interface Card (PIC) can host a physical interface that is shared by
different Protected System Domains (PSDs). The Flexible PIC Concentrator (FPC) and

the physical shared interface are owned by the Root System Domain (RSD). However,
the logical interfaces configured under the shared interface are assigned to and owned
by different PSDs. By sharing a single interface among multiple PSDs, the cost of traffic
forwarding is reduced and resources can be allocated flexibly at a more granular level.
Any FPC that has not been assigned to a specific PSD can be used to host shared
interfaces. On the RSD, multiple logical interfaces are configured on the physical interface
and each individual logical interface is assigned to a different PSD. On the PSD, each
assigned logical interface is configured and peered with an uplink tunnel interface
(ut-fpc/pic/slot), which transports packets between the PSD and the shared interface
on the RSD. See Figure 2 on page 6.
Figure 2: Shared Interfaces

Protected System Domain 1
logical
interface 1 Tunnel PIC
Root System Domain
OC192
Protected System Domain 2
logical
interface 2
Tunnel PIC
logical Shared physical interface

interface 3
Logical interfaces g016952
Cross-connect
NOTE:
When applied to shared interfaces:
• Junos features that are configured under logical interfaces, such as

class-of-service (CoS) classifiers and rewrites, firewall filters, and policers,
are configured on the PSD.
• Junos features that are configured under physical interfaces, such as drop
profiles and schedule maps, are configured on the RSD.
The packets belonging to a shared interface pass between the Packet Forwarding Engine
on the PIC in the RSD and the Packet Forwarding Engine on the uplink tunnel PIC in the
PSD through a cross-connect in the forwarding fabric.

Traffic flow from the PSD to the RSD over a shared interface is as follows:
1. A packet destined for the shared PIC at the RSD is received on an interface at the PSD
and sent to the Packet Forwarding Engine on the PSD’s tunnel PIC. (The tunnel PIC
is configured to peer with the shared PIC at the RSD.)
2. The packet is sent out of the tunnel interface.
3. The tunnel PIC loops the packet back to the input side of its Packet Forwarding Engine
and the packet is sent over the switch fabric to the Packet Forwarding Engine on the
shared PIC at the RSD.
4. The packet is then sent out the shared interface.
Traffic flow from the RSD to the PSD is as follows:
1. The Packet Forwarding Engine on the shared PIC at the RSD determines on which
logical interface the packet arrived.
2. Based on the RSD configuration, the PSD that is associated with this logical interface
is known and the packet is sent over the switch fabric to the tunnel PIC at that PSD.
3. The packet is sent out the tunnel interface.
4. The tunnel PIC loops the packet back to the input side of its Packet Forwarding Engine
and the packet is then handled as if it had arrived on a directly-connected PIC.
Table 2 on page 7 lists the PICs that support shared interfaces:
Table 2: PICs Supporting Shared Interfaces

First Junos OS
PIC Name PIC Model Number Release
Ethernet
1-port 10-Gigabit Ethernet DWDM PC-1XGE-DWDM-CBAND 9.4
1-port 10-Gigabit XENPAK PC-1XGE-XENPAK 9.4
4-port 10-Gigabit Ethernet LAN/WAN, PD-4XGE-XFP 9.6

XFP
10-port 1-Gigabit SFP PC-10GE-SFP 9.4
SONET/SDH
4-port OC48 SONET, SFP PC-4OC48-SON-SFP 9.3
1-port OC192 SONET, XFP PC-10C192-SON-SFP 9.3
4-port OC192 SONET, XFP PD-4OC192-SON-XFP 9.3
1-port OC768 SONET, SR PD-1OC768-SON-SR 9.3

NOTE: Only SONET PICs that are installed on an Enhanced Services (ES)
FPC on a T320 router or on a T1600 router can support shared interfaces.
Related • JCS1200 Chassis and T Series Core Routers as a Single Platform on page 3
Documentation
• Root System Domains on page 4
Inter-PSD Forwarding Overview

Inter-PSD forwarding enables PSDs on the JCS1200 platform to communicate on a
peer-to-peer basis without requiring external links. Previously, PSDs could communicate
with each other only through an external link.
Inter-PSD forwarding is achieved by using tunnel PICs that reside on the PSD. Each PSD
you configure for inter-PSD forwarding must have a tunnel PIC available to the PSD. The
PSDs communicate over logical interfaces configured on the tunnel PICs. Multiple logical
interfaces can be configured on each tunnel PIC, allowing the PSD to communicate with
multiple PSDs over the same tunnel PIC.
Currently, only Frame Relay encapsulation is supported for inter-PSD forwarding.

Documentation
Route Reflection Overview

To decrease BGP control traffic and minimize the number of update messages, a BGP
route reflector is used in many networks to distribute BGP routes within the AS. Routing
Engines on the JCS1200 platform can be configured to act as BGP route reflectors.
Because of large memory and 64-bit processor capacity, JCS1200 Routing Engines provide
ideal support for route reflection.
Typically, route reflection is performed by a dedicated router. The router is not in the
forwarding path (does not forward IP packets) but is equipped with a large memory and
a good CPU.
The number of route reflectors in an IP network is much smaller than the number of
routers. A network with 30 or more routers might have one route reflector (or possibly
two for redundancy). Larger networks with hundreds of routers, might have 20 router
reflectors.
Figure 3 on page 9 shows a typical network with route reflectors. These route reflectors
are not in the forwarding path.

Figure 3: Typical Network of Route Reflectors
PE RR 1 RR 3 PE
PE
g017292
PE RR 2 RR 4 PE
Figure 4 on page 9 shows the JCS1200 platform providing four distinct route reflectors
and preserving the current network architecture.
Figure 4: Route Reflectors on the JCS1200 Platform
PE PE
RR1 RR3
PE
RR2 RR4
g017293
PE PE
Figure 5 on page 10 shows an example of route reflector partitioning on the JCS1200

platform. Each JCS1200 chassis can hold up to 12 Routing Engines. You can get route
scalability up to 12x as you incrementally add Routing Engines to the JCS1200 chassis
and configure them for route reflection. You do not need to buy a new router to increase
route reflector capacity.

Figure 5: Route Reflector Partitioning on the JCS1200 Platform

JCS1200 Platform JCS1200 Platform
POP1 RR1 RR2 RR3 RR4 RR5 RR5 RR6 RR6 POP2 RR1 RR1 RR2 RR2 RR3 RR3 RR4 RR4
M B M B M B M B M B M B
PE PE
g017294
VPN 1-100 VPN 101-200 VPN 201-300 VPN 301-400
NOTE: Support for dual Routing Engines (master and backup) is currently
not available, but is planned for a future release.
As shown in Figure 6 on page 11, each of the 12 Routing Engines can be configured as a
standalone route reflector. The 12 Routing Engines on the JCS1200 platform are connected
to the JCS switch modules in a dual-star configuration. Each Routing Engine has access
to two interfaces (fxp0 and fxp1), one on each switch. These interfaces are used for
protocol peerings.
Each JCS switch module has 6 Gigabit Ethernet ports to connect to the outside world
for a total of 12 ports. One port on each JCS switch module is used as a management
port, three of the remaining ports on each JCS switch module can be used to connect to
the network. (The remaining two ports are reserved.) Each Gigabit Ethernet port represents
a separate LAN.
Multiple route reflectors can be configured to share the same port and hence be part of
the same LAN. Port sharing enables JCS1200 route reflectors to conserve Gigabit Ethernet
ports and reduce the cost of adding additional line cards for connectivity to the network.
The result is a cost-effective solution for networks where multiple route reflectors are
deployed.

Figure 6: Route Reflector Interfaces and Ports
RE1 RR1
RE2 RR2
RE3 RR3
RE4 RR4
Six GE ports fxp0
RE5
Switch Module 1
RE6
RE7
Switch Module 2
Six GE ports RE8
fxp1
RE9
RE10
JCS1200 Platform RE11

Internal LAN
g017295
RE12

Documentation
• Example: Configuring the JCS1200 Platform as a Route Reflector on page 157
• Example: Configuring Client-to-Client Reflection (OSPF) on page 166
Connections Between JCS1200 and T Series Chassis

The JCS1200 and T Series routers are connected through standard Ethernet links between
one or more JCS switch modules and one or more T Series Control Boards (T-CBs). The
JCS switch module has six ports. Port 1 is connected to Root System Domain 1 (RSD1),
port 2 to RSD2, and port 3 to RSD3. Port 6 connects to the management ports on all
Routing Engines in the JCS chassis. Port 4 and port 5 are reserved.
In Figure 7 on page 12, Ethernet port 1 (RSD1) on JCS switch module 1 is connected to the
T Series Connector Interface Panel (CIP) port on T-CB-0, whereas Ethernet port 1 (RSD1)
on JCS switch module 2 is connected to the CIP port on T-CB-1.
When there are two JCS switch modules, each Routing Engine can be configured with
two Ethernet management ports. One port (fxp0.0) is connected to port 6 on the JCS
switch module in bay 1, whereas the other port (fxp1.0) is connected to port 6 on the JCS
switch module in bay 2. Each connection is a dedicated 1000-Mbps link.

Figure 7: JCS Switch Module Ports
When you first access a PSD through the console port on the Routing Engine, you configure
the IP address for one or both of these management ports.
Figure 8 on page 12 provides a more detailed look at the connections between the two
platforms. RE m indicates a master Routing Engine on the JCS1200 platform, whereas
RE b represents a backup Routing Engine.
Figure 8: Connections Between JCS1200 and T Series Platforms

Related • Configuring a PSD with a Single Routing Engine on page 87

Documentation
• Configuring a PSD with Redundant Routing Engines on page 89
• Connecting the JCS1200 Platform to a T Series Core Router
Benefits of JCS1200 and T Series as a Single Platform

The benefits of the JCS1200 and T Series routers as a single platform are:
• Increased efficiency and investment protection—A single T Series router used with the
JCS1200 platform supports up to eight Protected System Domains (PSDs). With
multiple (up to 3) T Series chassis connected to the JCS1200 chassis, 12 PSDs can be
supported. Instead of purchasing 12 physical routers, a service provider can configure
12 PSDs using a single interconnected platform. In addition, operations and
administration are simplified through consolidation of resources.
• Maximum scaling and flexibility—A highly scalable control plane chassis preserves
slots in the router chassis that can be used for revenue-generating, high-speed
forwarding of Internet traffic. Service providers can assign control processors and
memory space on the Routing Engines in the JCS chassis to achieve the most efficient
use of resources, while delivering outstanding performance. In addition, different PSDs
can share interfaces on a single Physical Interface Card (PIC), reducing capital
expenditure and enabling you to allocate resources with finer granularity.
• Rapid service rollout—New services can be planned, tested, and deployed more quickly
with fewer resources. Each PSD provides a secure administration domain, where new
features can be tested, while other PSDs continue to provide tested software to
customers. Through fault isolation and streamlined administration domains, service
providers achieve faster revenue and accommodate rapid customer growth. In addition,
RSDs and PSDs can run different version of Junos OS; however, the supported Junos
OS Release version must be one release up, or one release down, from the current
Junos OS Release version. For example, if RSD is running Junos OS Release 10.1, then
PSD can run Junos OS Release 10.0 or 10.2, however, it cannot run Junos OS Release
9.6 or 10.3. Each RSD and PSD must be running Junos Release 9.4 or later.
The following sections discuss some of these benefits:
• Network Consolidation on page 13

• Enhanced Security and Administration on page 14
• Cost Efficiency on page 15
• Faster Deployment of New Services on page 15
Network Consolidation
Many carriers operate separate IP networks for public and private services. Others have
application-specific IP networks (voice and video, for example). PSDs enable carriers to
consolidate and simplify network architecture. Rather than adding more routing at the
edge to support individual services, a single platform provides service-specific virtualization
in the core of the network.

In Figure 9 on page 14, three separate networks (IPTV, enterprise VPN, and public IP) are
consolidated into one network. Instead of three core routers, only the JCS 1200 platform
interconnected with a single T640 router is required to support all three services.
Figure 9: Network Consolidation
Enhanced Security and Administration
By delineating fault and administrative domains on a single system, PSDs enable network
administrators to decrease the number of nodes and fiber interconnections between
routers, reducing the cost and complexity of existing point of presence (PoP) architectures.
Because each PSD maintains its own routing and processes in separate partitions, security
is enhanced. With fault isolation, network anomalies in one PSD do not affect another
PSD. Streamlined boundaries allow operational domains to be isolated logically, providing
more control over router administration.

Cost Efficiency
With PSDs, forwarding resources are allocated to where they are most needed. This
flexibility ensures that the most bandwidth-intensive services receive the resources
needed to guarantee service license agreements. By consolidating network equipment
and functions and streamlining management and administrative tasks, the utilization of
resources is maximized. Shared interfaces enable you to assign expensive forwarding
resources with more granularity to specific routing domains. RSDs and PSDs can run
different versions of Junos OS; howeve, the supported Junos OS Release version must
be one release up, or one release down, from the current Junos OS Release version. For
example, if RSD is running Junos OS Release 10.1, then PSD can run Junos Release 10.0
or 10.2; however, it cannot run Junos OS Release 9.6 or 10.3. To configure shared interfaces,
each RSD and PSD must be running Junos OS Release 9.3 or later.
Faster Deployment of New Services
Service providers can use a separate partition for testing and activating new services
without having to deploy a new system. Software upgrades can occur without affecting
software versions used for existing services. Carriers can begin generating revenue more
quickly and minimize the cost of introducing new services. RSDs and PSDs can run different
versions of Junos OS; however, the supported Junos OS Release version must be one
release up, or one release down, from the current Junos OS Release version. For example,
if RSD is running Junos OS Release 10.1, then PSD can run Junos OS Release 10.0 or 10.2;
however, it cannot run Junos OS Release 9.6 or 10.3. Each RSD and PSD must be running
Junos Release 9.4 or later.
Related • Example: Configuring a JCS1200 Platform and a Single T Series Router on page 123
Documentation
• Example: Configuring a JCS1200 Platform and Multiple T Series Routers on page 128
• Example: Configuring Shared Interfaces (Ethernet) on page 147
• Example: Consolidating a Layer 2 VPN Network on page 177


CHAPTER 2
JCS1200 and T Series Platform Software

Views
• Software Views Overview on page 17

• JCS Administration View on page 17
• RSD Administration View on page 18
• PSD Administration View on page 19
Software Views Overview
Configuring and managing the Juniper Networks JCS1200 control system and connected
T Series routers requires three separate control points (views). Each view provides a
different access to different parts of the system:
• Through the JCS management module command-line interface (CLI), a JCS

administration view enables you to configure and manage JCS1200 platform
components, including the JCS switch module and blade (or Routing Engine)
parameters.
• Through the Junos OS running on the Routing Engine pair in the T Series router (called
the Root System Domain), the RSD administration view enables you to create the
Protected System Domains (PSDs) and to manage all the hardware in the T Series
chassis.
• Through the Junos OS running on a Routing Engine (or Routing Engine pair) in the JCS
chassis, the PSD administration view enables you to configure and manage the hardware
that is assigned to the PSD.
Related • JCS Administration View on page 17

Documentation
JCS Administration View
The JCS administration view is controlled by JCS supervisors and operators who have
access to configuration and settings associated with the hardware and software that

reside on the JCS1200 platform. This includes JCS management modules, JCS switch
modules, the JCS Routing Engines (blades), JCS media trays, power supplies, and so on.
JCS administration view considerations include:
• Types of JCS Users on page 18

• How Command Targets and User Permissions Impact Views on page 18
Types of JCS Users

Users are authenticated by the JCS management module before they can issue JCS
commands. Login account configuration determines which commands are available.
Two types of Juniper Networks-specific login accounts are available on the JCS:
• Supervisor—Login accounts configured with supervisor privileges enable you to view

and enter JCS management module configuration commands such as users and write.
You can also view and enter JCS management module monitoring commands.
• Operator—Login accounts configured with operator privileges enable you to view and
enter JCS management module operational commands such as info and health. JCS
management module configuration commands are not available for operator logins
How Command Targets and User Permissions Impact Views

Views available to JCS users are based on a combination of user login permissions and
the target set for a command. For example:
• You can set the command target of the info command to selectively display information
about a specific Routing Engine in the JCS chassis, all Routing Engines in the chassis,
and so on.
• JCS operators can use the ifconf command to display network interface settings for
the JCS Ethernet interfaces. In addition, JCS supervisors can use the ifconf command
to change network interface settings.
Related • RSD Administration View on page 18

Documentation
• JCS1200 Software Components on page 23
• Configuring User Accounts on page 42
RSD Administration View
The Root System Domain (RSD) view is controlled by the administrators and users of
the Junos OS running on the Routing Engines on the T Series router. RSD administration
view considerations include:
• Access Privileges on page 19

• System Information on page 19
• Management Tasks on page 19

Chapter 2: JCS1200 and T Series Platform Software Views
Access Privileges
The RSD administrator creates the PSDs through the Junos OS running on the Routing
Engines in the T Series chassis. With the correct user privileges and authentication, an
RSD administrator can log in to a PSD from the RSD.
System Information
The RSD administrator can use the show chassis psd command to view which PSDs are
configured within the RSD. Otherwise, when issuing show commands on the RSD, the
administrator views all hardware on the T Series router.
By default, system log files are stored in the /var/log/message directory on the router. If
a system log message on an RSD originates from an FPC that is assigned to a PSD, the
system message is logged locally at the RSD and is also forwarded to that particular
PSD. If a system log message originates from a hardware resource that is shared between
and RSD and PSDs, the message is logged locally at the RSD and is also forwarded to
all PSDs associated with the RSD.
Management Tasks
The RSD administrator manages all hardware on the T Series router, including the Routing
Engines, FPCs, Switch Interface Boards (SIBs), the Switch Processor Mezzanine Board
(SPMB), Power Entry Modules (PEMs), and fans. The RSD administrator can issue show,
request, clear, and test commands for any hardware on the T Series router and for any
FPCs that are part of a PSD.
NOTE: A switchover between Routing Engines on the T Series router (the

RSD) does not affect PSDs. However, when an RSD reboots or goes offline,
the FPCs assigned to PSDs will reboot or go offline.

Documentation
• Logging In to a PSD from the RSD on page 237
• Junos OS Verification Tasks on page 238
PSD Administration View
The Protected System Domain (PSD) view is controlled by the administrators and users
of the Junos OS running on the Routing Engines in the JCS chassis that belong to a
particular PSD. Topics in this section include:
• Access Privileges on page 20

• System Information on page 20
• Management Tasks on page 20

Access Privileges
Each PSD is independent of all other PSDs and requires login authentication. When you
initially configure a PSD, you set its root authentication parameters. Authentication is
enforced when a user attempts to log in to a PSD directly or from the RSD.
System Information
The PSD administrator can display information about the Routing Engines, FPCs, and
PICs that are assigned to the PSD. The administrator can also display information about
shared T Series hardware, such as SIBs, the SPMB, PEMs, and fans. When a show
command is issued on a PSD, a field heading such as psd1-re0: precedes the set of
information that pertains only to the PSD, whereas a field heading such as rsd-re0:
precedes the set of information that pertains to the shared hardware.
System log messages originating from an FPC that is assigned to a PSD are logged locally
at the RSD and forwarded to the PSD. If a system log message originates from a hardware
resource that is shared between and RSD and PSDs, the message is logged locally at
the RSD and is forwarded to all PSDs associated with the RSD. Again, you can determine
the origin of a system message by labels such as psd1-re0: and rsd-re0:.
Management Tasks
The PSD administrator controls and manages Routing Engines and FPCs assigned to
that PSD. For example, the PSD administrator can issue request, clear, and test commands
for the FPCs and PICs that are part of the PSD. The PSD administrator has view-only
access to shared T Series hardware, such as SIBs, the SPMB, PEMs, and fans.
NOTE: A switchover between Routing Engines on the JCS1200 platform that

are assigned to a PSD does not affect the RSD or other PSDs. However, when
the master Routing Engine in a PSD reboots or goes offline, the FPCs assigned
to that particular PSD will reboot or go offline.

Documentation

CHAPTER 3
JCS1200 Platform Components
• JCS1200 Platform Hardware Components on page 21

• JCS1200 Software Components on page 23
• JCS1200 Platform Graceful Routing Engine (GRES) Switchover on page 27
JCS1200 Platform Hardware Components
JCS1200 platform hardware components include:
• Default Hardware Configuration on page 21

• Routing Engines on page 21
• Management Module on page 22
• Switch Module on page 22
• Media Tray on page 22
• Power Supply Modules on page 22
• Fan Modules on page 23
Default Hardware Configuration

The default configuration for the JCS1200 platform includes:
• One JCS management module
• One JCS switch module
• Four power supplies
• One media tray
Routing Engines
The JCS chassis provides 12 slots (bays) for Routing Engines. A Routing Engine is a
hot-swappable, independent server with its own processors, memory, storage, network
controllers, operating system, and applications. The Routing Engine is installed in a slot
in the JCS chassis and shares power, fans, switches, and ports with other Routing Engines.
Routing Engines in the JCS1200 platform have the latest Junos OS preinstalled on them.

Management Module
The JCS management module is a hot-swappable module that you use to configure and
manage JCS components. The JCS chassis comes with one hot-swappable management
module in management module slot 1. To provide redundancy, you can add a second
management module in management module slot 2. Only one management module is
active. The other is a backup in case of failure. Each JCS management module has a
separate internal link to each JCS switch module. See Figure 10 on page 22.
Figure 10: JCS Management Module
You can access the JCS management module CLI through a local connection to the serial
port on the JCS management module. Or, you can access the CLI from a remote network
management station on the network through the console (Ethernet) connector.
Switch Module
The JCS switch module connects Routing Engines on the JCS1200 platform to a T Series
router and controls traffic between the two devices. The JCS chassis comes with one
hot-swappable switch module in switch module slot 1. To provide redundancy, you can
add a second switch module in switch module slot 2.
Media Tray
The media tray is a hot-swappable module that provides two USB connectors for use
by the Routing Engines, error LEDs, an ambient air temperature sensor and a pressure
sensor for use by the JCS management module, and two CompactFlash card slots. Junos
OS is preloaded onto each Routing Engine. The media tray USB ports are used to copy
new Junos OS packages onto Routing Engines. See Figure 11 on page 22. The JCS chassis
comes with one hot-swappable media tray in media tray slot 1. To provide redundancy,
you can add a second media tray in media tray slot 2.
Figure 11: JCS Media Tray
Power Supply Modules

The JCS chassis is configured with four hot-swappable power supply modules. The power
supply modules in slots 1 and 2 supply power to Routing Engine slots 1 through 6, media
trays 1 and 2, management module slots 1 and 2, and switch module slots 1 and 2. Power
supply modules in slots 3 and 4 supply power to Routing Engine slots 7 through 12.

Chapter 3: JCS1200 Platform Components
Each pair of power modules operates as a redundant pair. If either power module fails,
the remaining power module continues to supply power, but there is no redundancy.
Replace a failed power module as soon as possible.
Fan Modules
The JCS1200 platform comes with four hot-swappable fan modules for cooling
redundancy. The fan module speeds vary depending on the ambient air temperature
within the JCS1200 platform.
If the ambient temperature is 25°C (77°F) or below, the JCS1200 platform fan modules
will run at their minimum rotational speed. If the ambient temperature is above 25°C
(77°F), the fan modules will run faster, increasing their speed as required to control
internal JCS1200 platform temperature.
Each fan module contains two fans operating as a pair in a series. If one fan fails, the
remaining fan will run at full speed and continue to cool the JCS1200 platform. To maintain
cooling redundancy, replace a failed fan module as soon as possible.
Related • JCS1200 Software Components on page 23

Documentation
JCS1200 Software Components
The JCS1200 software includes the following concepts and components:
• JCS Management Module CLI Overview on page 23

• Logging In to the JCS Management Module CLI on page 24
• Getting Help on JCS Commands on page 24
• Setting the JCS Management Module Command Target on page 25
• JCS Switch Module Script on page 26
JCS Management Module CLI Overview

The JCS management module command-line interface (CLI) is the software interface
you use to access and configure the Juniper Networks Control System (JCS). You can
access the JCS management module CLI through a local connection to the serial port
on the JCS management module. Or, you can access the CLI from a remote network
management station on the network through the console (Ethernet) connector.
The JCS management module CLI is a straightforward command interface. You type
commands on a single line, and commands are executed when you press the Enter key.
The CLI provides command help and command history.
Unlike the Junos OS CLI, in which configuration commands you enter are stored in a
candidate configuration and the changes you add are not activated until you commit the
configuration, configuration commands you enter with the JCS management module
CLI are activated as soon as you enter the command.
General information about JCS CLI commands includes:

• All JCS CLI commands have the following basic structure:
command -option parameter
An option is a single-letter code or word that refines the behavior of a command in

some predetermined way. A parameter, also known as a command-line argument, is
a filename or other data that is provided to a command. Some commands do not
require options, and some commands do not require parameters.
• All commands, command options, and predefined parameters are case-sensitive.
• Command options are indicated by a dash (-).
• Strings that contain spaces are enclosed in quotation marks. For example:
snmp -cn “John Markham”
• Depending on which command options you enter, you can use the same JCS CLI
command to display configuration information or to change a configuration. For
example, compare the following:
mt -T system
Displays the Routing Engine (blade) that currently controls (owns) the media tray.
mt -T system –b 6
Configures the Routing Engine (blade) in slot 6 to control the media tray.
Logging In to the JCS Management Module CLI

To log in to the JCS management module for the first time, use the default username
and password:
Username: USERID
Password: PASSW0RD
The 0 in PASSW0RD is a zero, not the letter O.
When you have created user accounts, you can log in as a specific user.
Getting Help on JCS Commands

The JCS management module CLI includes a help command you can use to get a list of
available commands or to get help on individual commands.
• For a list of available commands, enter the help command. For example:
system> help
? – Display commands
accseccfg — View/edit account security config
advfailover — View/edit advanced failover mode
alarm — Manage Telco System Management alarm(s)
alertcfg — Displays/Configures the global remote alert systems
alertentries — View/edit remote alarm recipients
baydata — View/edit Blade Bay Data string
...
• For help on individual commands, enter command -help, where command is the name
of the command for which you want help. For example:

system> clock -help
usage:
clock [-options]
options:
-d - date (mm/dd/yyyy)
-t - time (hh:mm:ss)
-g - GMT offset
-dst - daylight savings time (on|off|special case)
For a GMT offset of +2:00, use one of the following values for dst:
ee - Eastern Europe
gtb - Great Britain
egt - Egypt
fle - Finland
off
For a GMT offset of +10:00, use one of the following values for dst:
ea - Eastern Australia
tas - Tasmania
vlad - Vladivostok
off
For a GMT offset in set {-9:00, -8:00, -7:00, -6:00, -5:00}, use one of
the
following values for dst:
uc - USA and Canada
other - Other locations
off
For a GMT offset of -4:00, use one of the following values for dst:
can - Canada
other - Other locations
off
• You can also use the ? or -h shortcuts to get help. For example:
system> clock -h
system> clock ?
Table 3 on page 25 shows syntax conventions used in help command output.
Table 3: Syntax Conventions for JCS Management Module CLI Help

Item Description
[] Used for indexing (by slot (bay) number)
<> Denotes a variable
{} Denotes an optional argument
| Denotes a choice
Setting the JCS Management Module Command Target

You can use the JCS management module CLI to direct commands to the management
module or other devices installed in the JCS chassis. The device where the command
takes effect is called the command target. By default, the command target is system
(the JCS chassis).

• Use the env command to change the command target. For example:
• The following command changes the command target from system to JCS
management module 1 (mm[1]):
system> env -T mm[1]
OK
system:mm[1]>
The command prompt changes to system:mm[1] to indicate the command target.

Unless otherwise directed, all commands you enter apply to the target shown by
the prompt.
• To return the command target to the top level of the hierarchy, type the following:
system:mm[1]: env -T system
OK
system>
• Use the -T option to temporarily override the active command target for individual
commands. For example, to include the following command option to redirect a
command to the JCS management module in slot (bay 1), type:
-T system:mm[1]
Table 4 on page 26 lists command targets you typically use to configure and monitor the
JCS1200 platform.
Table 4: Target Paths for JCS Modules

Item Target Path Description
JCS1200 platform system –
JCS management module system:mm[x] x is the management module number (1

or 2)
Routing Engine (blade server) system:blade[x] x is the blade slot number (1 through 12)
JCS switch module system:switch[x] x is the switch number (1 or 2)
NOTE: Additional target paths are available in the JCS management module
CLI.
JCS Switch Module Script

The JCS switch module includes a menu-based interface that runs on the JCS1200
platform. However, instead of using menus to configure the switch, Juniper Networks
provides a script you can use for configuring the switch.

Related • JCS1200 Platform Hardware Components on page 21

Documentation
JCS1200 Platform Graceful Routing Engine (GRES) Switchover
• Graceful Routing Engine Switchover Overview on page 27

• Graceful Routing Engine Switchover PIC Support on page 27
Graceful Routing Engine Switchover Overview

The Graceful Routing Engine switchover (GRES) feature in the Junos OS enables a routing
platform with redundant Routing Engines to continue forwarding packets even if one
Routing Engine fails. GRES preserves interface and kernel information. Traffic is not
interrupted. For more information, on GRES, see the Junos High Availability Configuration
Guide.
• To configure GRES on the JCS1200 platform, include the graceful-switchover statement

at the [edit chassis redundancy routing-engine] hierarchy level on the PSD.
• Configure the graceful-switchover statement for all PSDs on the JCS1200 platform
that include redundant Routing Engines.
Graceful Routing Engine Switchover PIC Support

Junos OS Release 10.0 or higher supports GRES for PICs running on the JCS1200 platform,
including IQ2 PICs. IQ2 PICs supported on the JCS1200 platform include 1-, 4-, and 8-port
Gigabit Ethernet IQ2 PICs and 1-port 10-Gigabit Ethernet IQ2 PICs.
Related • Junos High Availability Configuration Guide

Documentation


PART 2
Configuration Overview
• Before You Begin on page 31
• Configuration Roadmap on page 33


CHAPTER 4
Before You Begin
• Verifying the FPC BootROM Version on page 31

• Keeping the JCS Management Module Default SNMP Setting on page 32
Verifying the FPC BootROM Version
Before connecting the JCS1200 platform to any T Series router, ensure that the bootROM
version for all FPCs on the T Series chassis is ROM Monitor Version 6.4 or later. If an FPC
bootROM version is earlier than Version 6.4, the FPC will not come online. To upgrade
the firmware, you must contact your Juniper Networks customer support representative.
To determine if you need to upgrade the FPC firmware, display the version of the firmware
on all FPCs by issuing the show chassis firmware command:
user@host> show chassis firmware
Part Type Version

FPC 0 ROM Juniper ROM Monitor Version 7.5b4
O/S Version 9.1-20080222.0 by builder on 2008-0
SPMB 0 ROM Juniper ROM Monitor Version 6.4b18
SPMB 1 ROM Juniper ROM Monitor Version 6.4b18
Related • Keeping the JCS Management Module Default SNMP Setting on page 32
Documentation

Keeping the JCS Management Module Default SNMP Setting
CAUTION: By default, SNMP is enabled on the JCS management module.

Do not disable SNMP. If you disable SNMP, your system might not function
correctly. Also, do not erase or change the SNMP default c1 community.
Related • Verifying the FPC BootROM Version on page 31

Documentation
• Configuring SNMP Traps on page 43

CHAPTER 5
Configuration Roadmap
Configuration Roadmap
Complete the following tasks to configure the JCS1200 platform and T Series routers:
• Step One: Configure the JCS1200 Platform on page 33

• Step Two: Configure the T Series Router on page 34
• Step Three: Configure Basic System Properties on a New PSD on page 34
• Step Four: Configure Shared Interfaces (Optional) on page 35
Step One: Configure the JCS1200 Platform

To configure the JCS1200 platform, log in to the JCS management module command-line
interface (CLI) and:
1. Configure basic system parameters:
• Restore the default configuration on the JCS management module.
• Configure the JCS management module Ethernet management interface.
• Configure the JCS switch module Ethernet management interface.
• Create user accounts.
• Configure the NTP server.
• Configure the time zone.
• Configure the system name and contact information.
• Configure Secure Shell (SSH) access.
• Configure Simple Network Management Protocol (SNMP) traps.
• Configure the JCS switch module.
2. Configure the Routing Engines (blades) on the JCS1200 platform:

• Configure Routing Engine (blade) bay data to assign a single Routing Engine (or
redundant pair) to a Root System Domain (RSD) and to a unique Protected System
Domain (PSD).
• Configure Routing Engine (blade) names.
Step Two: Configure the T Series Router

Log in to the master Routing Engine on the T Series router to configure it as a Root System
Domain (RSD) and to create Protected System Domains (PSDs) under the RSD. Through
the Junos OS CLI or through the J-Web user interface:
1. Assign an ID number to the RSD.
This ID number must match the ID number set through the JCS management module
baydata command.
2. Configure a PSD and assign it an ID number.
3. Provide a description of the PSD.
4. Assign one or more FPCs to the PSD.
NOTE: Any FPC that is not assigned to a PSD belongs to the RSD. For
information about how to configure shared interfaces on a SONET PIC in
an unassigned FPC, see “Step Four: Configure Shared Interfaces
(Optional)” on page 35.
5. Assign an ID number to the JCS1200 platform.
The ID number must match the ID number set through the JCS management module
baydata command.
6. Assign a Routing Engine (or redundant pair) on the JCS1200 platform to the PSD.
Routing Engine assignments must match the assignments configured through the
JCS management module baydata command.
7. Repeat Step 2 through Step 6 for each PSD to be configured under the RSD.
8. Repeat this entire procedure for each RSD.
Step Three: Configure Basic System Properties on a New PSD

To configure a PSD, connect to the console port on the Routing Engine on the JCS1200
platform for the PSD you want to configure and, using the Junos OS CLI, include the
following information:
• Hostname
• Domain name
• Ethernet management IP addresses
• IP address of a backup router

Chapter 5: Configuration Roadmap
• IP address of one or more DNS name servers on your network
• Password for the root account
Step Four: Configure Shared Interfaces (Optional)

Optionally, configure shared interfaces. Shared interfaces are configured on both the
Root System Domain (RSD) and the Protected System Domain (PSD).
On the Root System Domain (RSD):
1. Configure the physical interface.
2. For SONET interfaces, configure Frame Relay encapsulation. For Ethernet interfaces,
configure virtual LAN (VLAN) tagging.
3. Configure logical interfaces under the physical interface.
4. For each logical interface:
a. Provide an identifier. For a SONET logical interface, configure a data-link connection

identifier (DLCI). For an Ethernet logical interface, configure a virtual LAN (VLAN)
identifier.
b. Specify the Protected System Domain (PSD) that owns the shared interface.
On the Protected System Domain (PSD):
1. Configure the physical interface (as specified in the RSD configuration).
2. For a SONET interface, configure Frame Relay encapsulation on the physical interface
to match the RSD configuration. For an Ethernet interface, configure VLAN tagging
to match the RSD configuration.
3. For a SONET physical interface, configure the maximum transmission unit (MTU) size
to match the RSD configuration. (If the RSD has no MTU size specified, do not include
an MTU size on the PSD.)
4. Identify the physical interface as a shared interface.
5. Configure the logical interfaces that belong to the PSD (as specified in the RSD
configuration).
6. On each logical interface:
a. Configure the same DLCI (for SONET) or VLAN ID (for Ethernet) that has been
specified in the RSD configuration
b. Specify the logical tunnel interface that is peered with the logical SONET or Ethernet
interface.
The logical unit number of the tunnel interface must be the same as the one that
is configured on the SONET or Ethernet interface.
c. Configure the protocol family and IP address of the logical SONET or Ethernet
interface.
7. Configure the physical tunnel interface.

8. Configure the logical tunnel interfaces under the physical interface.
9. For each logical tunnel interface, specify its peer logical SONET or Ethernet interface.
The logical unit number must be the same as the one that is configured on the logical
tunnel interface.
Related • Configuring JCS Management Module Settings on page 39

Documentation
• Configuring the JCS Switch Module on page 47
• Configuring the Routing Engine Parameters (Blade Bay Data) on page 51
• Configuring the Routing Engine (Blade) Name on page 52
• Configuring an RSD and Creating PSDs on page 84
• Configuring a PSD with a Single Routing Engine on page 87
• Configuring Shared Interfaces on the RSD on page 95
• Configuring Shared Interfaces on a PSD on page 97

PART 3
Configuring the JCS1200 Platform

• Configuring Basic System Parameters on page 39
• Configuring the Routing Engines on the JCS1200 Platform on page 49
• Summary of JCS Management Module Configuration Commands on page 53


CHAPTER 6
Configuring Basic System Parameters
• Configuring JCS Management Module Settings on page 39

• Configuring SNMP Traps on page 43
• Configuring SSH Access on page 45
• Configuring the JCS Switch Module on page 47
Configuring JCS Management Module Settings
You use the JCS management module CLI to configure basic system parameters on the
JCS1200 platform:
• Restoring the Default JCS Management Module Configuration on page 40

• Configuring the JCS Management Module Ethernet Interface on page 40
• Configuring the Switch Module Ethernet Interface on page 41
• Configuring User Accounts on page 42
• Configuring the NTP Server on page 42
• Configuring the Time Zone on page 43
• Configuring the System Name and Contact Information on page 43

Restoring the Default JCS Management Module Configuration

Before you configure the JCS management module, we recommend clearing any existing
configurations on the JCS management module and restoring the defaults.
Clearing a configuration results in the following changes:
• Sets the JCS management module to its default state.
This is equivalent to pressing the recessed button on the front panel of the JCS
management module for more than 5 seconds.
• Initializes the serial port to 9600 baud.
• Initializes the internal SNMP community string.
An SNMP community string is a text string that acts as a password. It is used to

authenticate messages that are sent between the management station (the SNMP
manager) and the device (the SNMP agent). The community string is included in every
packet that is transmitted between the SNMP manager and the SNMP agent.
• Disables web access.
To clear an existing JCS management module configuration:
1. Log in to the JCS management module.
If you are logging in for the first time, use the default username and password:
Username: USERID
Password: PASSW0RD
The 0 in PASSW0RD is a zero, not the letter O.
2. Use the env command to set JCS management module 1 (mm[1]) as the configuration
target. For example:
system> env —T mm[1]
3. Use the clear command to clear the configuration. For example:
system:mm[1]> clear —cnfg
This example clears the configuration on mm[1] and returns the JCS management
module to the factory default settings.
Configuring the JCS Management Module Ethernet Interface

To configure the network interface on the JCS management module:
system:mm[1]> env —T mm[1]
3. Use the ifconfig command to configure the interface. For example:

Chapter 6: Configuring Basic System Parameters
system:mm[1]> ifconfig —eth0 —i 192.168.171.96 —g 192.168.171.254 —s 255.255.252.0

—c static
In this example, Ethernet channel 0 is configured for a static IP address of 192.168.171.96

and a gateway address of 192.168.171.254. The subnet mask is 255.255.252.0.
NOTE: You only need to configure the Ethernet interface on the primary
management module. The backup management module will use the IP
address from the primary if it becomes the primary management module.
Configuring the Switch Module Ethernet Interface

You must configure the Ethernet interface for both JCS switch modules (switch[1] and
switch[2]) on the JCS management module.
NOTE: The IP address for the JCS switch modules must be on the same
subnet as the IP address for the JCS management module.
To configure the JCS switch module Ethernet interface on the JCS management module:
2. Use the env command to set JCS switch module 1 (switch[1]) as the configuration
system> env —T switch[1]
system:switch[1]> ifconfig —i 192.168.171.98 —g 192.168.171.254 —s 255.255.252.0

—em enabled —ep enabled
In this example, the Ethernet interface for JCS switch module 1 is configured for an IP
address of 192.168.171.98 and a gateway address of 192.168.171.254. The subnet mask
is 255.255.252.0. The external ports (ep) of the switch module are enabled.
4. Repeat this procedure for JCS switch module 2. Use the env command to set switch
module 2 (switch[2]) as the configuration target. For example:
system> env —T switch[2]
system:switch[2]> ifconfig —i 192.168.171.99 —g 192.168.171.254 —s 255.255.252.0

—em enabled —ep enabled
In this example, the Ethernet interface for JCS switch module 2 is configured for an IP
address of 192.168.171.99 and a gateway address of 192.168.171.254. The subnet mask
is 255.255.252.0. The external ports (ep) of the switch module are enabled.

Configuring User Accounts

You configure user accounts on the JCS management module to control access to the
module. The JCS1200 platform supports the following types of security roles for user
accounts:
• Supervisor—This role has full read and write access to the JCS1200 platform. Users
can configure the JCS management module, the JCS switch module, and Routing
Engines (blades) on the JCS1200 platform. You must configure at least one user to
have a Supervisor role.
• Operator—This role has read-only access to the JCS platform. Users can view the
configuration of the JCS management module, the JCS switch module, and the JCS
Routing Engines. They can monitor JCS operations, but they cannot change the JCS
configuration
You can add up to 12 users to the JCS management module. Each user you add must be
assigned a unique number (1 through 12).
To configure user accounts:
3. Use the users command to configure user accounts. For example:
system:mm[1]> users -2 —n chang —p SPASS1 —a super
system:mm[1]> users —3 —n markham —p OPASS1 —a operator
In these examples, User 2 is configured with a username (chang) and a password

(SPASS1). User 2 has Supervisor access (full read/write). User 3 is configured with a
username (markham) and a password (OPASS1). User 2 has Operator access
(read-only).
Configuring the NTP Server

To synchronize the JCS1200 platform with other servers on the network, you must
configure a Network Time Protocol (NTP) server.
To configure an NTP server:
3. Use the ntp command to configure an NTP server. For example:
system:mm[1]> ntp —i 172.17.28.5 —f 60 —en enabled

In this example, the IP address of the NTP server is 172.17.28.5, the JCS management
module clock is updated by the NTP server every 60 minutes, and NTP is enabled.
Configuring the Time Zone

To configure the time zone on the JCS management module:
3. Use the clock command to configure the time zone. For example:
system:mm[1]> clock —g —8 —dst uc
In this example, the clock is configured for 8 hours earlier than UTC (GMT) (-g -8),
and daylight saving time for the USA and Canada (-dst uc) is set.
Configuring the System Name and Contact Information

JCS management module configuration should include the system name of the JCS 1200
platform (to identify the JCS1200 platform on the network), the physical location of the
JCS1200 platform, and a contact person for the JCS1200 platform. Typically, the contact
is someone who has Supervisor access to the JCS1200 platform.
To configure the system name, location, and contact information for the JCS management
module:
3. Use the config command to configure the system name, location, and contact
information for the JCS. For example:
system:mm[1]> config -name system5 -contact “George Chang email=chang@corp.net

phone=x2368” —loc “Software Lab, Main Campus, Building 12”
In this example, the system name is system5. This name identifies the JCS on the
network, appears in monitoring command output, and so on. The contact information
is for George Chang and the location is Software Lab.
Configuring SNMP Traps
The Simple Network Management Protocol (SNMP) enables the monitoring of network
devices from a central location. This section describes how to configure SNMP traps on
the JCS management module.

Tasks to configure SNMP traps and alerts on the JCS management module are:
• Configuring the SNMP Community on page 44

• Configuring Alert Entries for SNMP Traps on page 44
• Configuring Monitored Alerts for SNMP Traps on page 45
Configuring the SNMP Community

The SNMP community defines the relationship between an SNMP server system and
client systems. To configure the SNMP community, set the community name and type.
Also set the IP address for the community.
To configure the SNMP community:
2. Use the env command to specify mm[1] as the configuration target. For example:
3. Use the snmp command to configure the SNMP community. For example:
system:mm[1]> snmp -c3 trap
system:mm[1]> snmp -c3i1 192.168.171.100 -ca3 trap
In this example, the community 3 name is trap, the IP address of the trap destination
is 192.168.171.100, and the community 3 type is trap.
CAUTION: By default, SNMP is enabled on the JCS management module.

Do not disable SNMP. If you disable SNMP, your system might not function
correctly. Also, do not erase or change the SNMP default c1 community.
Configuring Alert Entries for SNMP Traps

To use SNMP notifications on the JCS management module, you must specify the alert
recipient. These recipients indicate where network registrar notifications are directed.
Alert recipients are numbered from 1 through 12.
To configure the alert recipient:
3. Use the alertentries command to configure the alert recipient. For example:
system:mm[1]> alertentries -1 -n trap -status on -f none -t snmp
In this example, the alert recipient number is 1, the recipient is named trap, the alert
status is on, alert filtering is none (all alerts are received, not just critical alerts), and
the alert type is SNMP.

Configuring Monitored Alerts for SNMP Traps

In addition to specifying alert recipients for SNMP notifications, you can configure
particular enhanced alert categories (monitored alerts), which enable you to selectively
choose alerts.
To configure monitored alerts:
3. Use the monalerts command to configure the monitored alerts. For example:
system:mm[1]> monalerts —ec enabled
system:mm[1]> monalerts —ca enabled, —wa enabled —ia enabled
In this example, the enhanced alert categories are enabled. All critical (ca), warning
(wa), and informational (ia) alerts are enabled.
Related • alertentries on page 54

Documentation
• env on page 62
• monalerts on page 69
• snmp on page 74
Configuring SSH Access
Secure Shell, or SSH, is a network protocol that allows data to be exchanged over a
secure channel between two systems. This section describes how to use JCS commands
to configure SSH access to the JCS1200 platform.
Tasks to configure SSH include:
• Generating the Host Key on page 46

• Adding the User Public Key on page 46

Generating the Host Key

SSH access requires a host key and a user public key.
To generate the host key:
1. Use an existing username and password to connect to the JCS management module
serial port. For example:
tcsh-1:telnet bcgmm1-con
In this example, the serial port is connected to a telnet server port identified as
bcgmm1-con.
3. Use the sshcfg command to generate a host key. For example:
system:mm[1]> sshcfg —hk gen
It takes about 1 minute to generate a host key.
4. You can use the displaylog command to monitor host key generation. For example:
system:mm[1]> displaylog —f
5. Once the host key is generated, use the sshcfg command to enable SSH for the JCS
CLI. For example:
system:mm[1]> sshcfg —cstatus enabled
Adding the User Public Key

To generate a user public key:
1. See the “Generating the Host Key” section to generate a host key.
2. Locate the /.ssh/authorized_keys file and copy your public key from this file.
3. Use the users command to add your public key.
You copy the public key from the authorized_keys file and paste it on the command
line. For example:
system:mm[1]> users —2 —pk —1 —add paste-key-here
4. Issue the users command to verify that the public key has been installed. For example:
system:mm[1]> users —2
- n chang
- a Role:supervisor
...
Number of SSH public keys installed for this user: 1
Last login: 1/28/08 09:26:59
5. Log out, and then use SSH to log back in. For example:

system:mm[1]> exit
tcsh-1 ssh bcgmm1
In this example, the JCS management module Ethernet port is identified as bcgmm1.
Related • displaylog on page 212

Documentation
• env on page 62
• sshcfg on page 76
• users on page 78
Configuring the JCS Switch Module
The JCS switch module in the JCS chassis connects JCS Routing Engines to a T Series
router. For redundancy, the JCS chassis includes two JCS switch modules. The JCS switch
module is preconfigured with defaults, and the configuration should not be changed. A
script is available to complete switch configuration. This script enables you to configure
the following items on the switch module:
• Network Time Protocol (NTP)—The JCS switch module does not have a real-time
clock. You must configure NTP so that the system clock on the JCS switch module has
the correct time. The script sets the IP address for the NTP server, enables the NTP
server, and sets the time zone for the switch module.
• SNMP traps—The script also configures SNMP trap information for the switch module.
This includes setting the SNMP community name and type and specifying alert
recipients.
For more information on the JCS switch configuration script, see the Junos OS Release
Notes.
NOTE: JCS switch module configuration is not replicated across switch

modules. You must run the configuration script on both JCS switch modules.

Documentation


CHAPTER 7
Configuring the Routing Engines on the

JCS1200 Platform
• Upgrading a JCS1200 Route Reflector to 64-Bit Junos OS on page 49

Upgrading a JCS1200 Route Reflector to 64-Bit Junos OS
On a JCS1200 route reflector, you can install 64-bit Junos OS to improve memory and
performance. However, you cannot mix a 32-bit image and a 64-bit image in the same
JCS chassis. This upgrade is available only for route reflector applications. Protected
System Domain is not supported.
NOTE: You can also order a routing engine with 64-bit Junos OS image
preinstalled.
Following are the memory and Junos OS requirements:
• Memory requirements—There are no special memory requirements to use a 64-bit

Junos OS on a JCS1200 route reflector. Your existing hardware configuration is sufficient
for using 64-bit Junos OS.
• Junos OS release requirements—64-bit Junos OS is supported from Junos OS Release

10.3.
This topic includes the following tasks:
• Downloading 64-Bit Junos OS on page 49

• Installing 64-Bit Junos OS on page 50
Downloading 64-Bit Junos OS

To download 64-bit Junos OS:

• Download the 64-bit software package from the Juniper Networks Support website
at http://www.juniper.net/support/. Under Download Software, select either Junos
(US & Canada) or Junos (Worldwide).
To download the software package, you must have a service contract and an access
account. If you need help obtaining an account, complete the registration form at the
Juniper Networks website: https://www.juniper.net/registration/Register.jsp.
Installing 64-Bit Junos OS

To install 64-bit Junos OS:
1. Back up the currently running file system so that you can recover to a known, stable
environment in case something goes wrong with the upgrade:
user@host>request system snapshot
The root file system is backed up to /altroot, and /config is backed up to /altconfig.
The root and /config file systems are on the router’s CompactFlash card, and the
/altroot and /altconfig file systems are on the router’s hard disk.
NOTE: After you issue the request system snapshot command, you cannot
return to the previous version of the software, because the running copy
and the backup copy of the software are identical.
2. Copy the downloaded software package to the /var/tmp directory on the hard disk:
user@host> file copy ftp://username:prompt@ftp.hostname.net/filename /var/tmp
3. Add the new software package:
user@host> request system software add/var/tmp/ installation-package validate
installation-package is the full name of the file copied in the previous step. For 64-bit
Junos OS, the full name would be jinstall64.tgz.
The system might display the following message:

pkg_delete: couldn’t entirely delete package
This message indicates that someone manually deleted or changed an item that was
in a package. You do not need to take any action; the package is still properly deleted.
4. Reboot the router to start the new software:
user@host> request system reboot
5. After you have upgraded the software and are satisfied that the new software is
properly running, issue the request system snapshot command to back up the new
software:
user@host> request system snapshot
The root file system is backed up to /altroot, and /config is backed up to /altconfig. The
root and /config file systems are on the router’s CompactFlash card, and the /altroot and
/altconfig file systems are on the router’s hard disk.

Chapter 7: Configuring the Routing Engines on the JCS1200 Platform
return to the previous version of the software, because the running copy and
backup copy of the software are identical.
Configuring the Routing Engine Parameters (Blade Bay Data)
To pass system configuration information to the Routing Engines on the JCS, you must
configure the blade bay data. Blade bay data is stored as a 60-byte text string that
contains information about how the Routing Engines on the JCS1200 platform are mapped
to PSDs and to the RSD. The blade bay mapping information is passed from the JCS
management module to the appropriate Routing Engine, so that it is available when the
Junos OS boots.
You enter a blade bay data string for each primary and standby Routing Engine on the
JCS chassis.
Blade bay data is entered as a text string with the following format. See Table 5 on
page 51 for details.
Vn-JCSn-SDn-PSDn-REPn-REBn-PRDplatform-type
n is a number. platform-type is the routing platform type (T1600, T640, or T320).
Table 5: Format Requirements for Blade Bay Data

Item Description
V Version number of the blade bay data. The accepted value is 01.
JCS JCS identifier. The range of values is 01 through 04. The value for this parameter must match the
value set by the control-system-id statement configured through the Junos OS CLI.
SD RSD identifier. The range of values is 01 through 03. The value for this parameter must match the
value set by the root-domain-id statement configured in the Junos OS CLI.
PSD PSD identifier. Each identifier must be unique. The value range is 01-31. The value for this parameter
must match the value set by the protected-system-domains statement configured through the
Junos OS CLI.
REP Slot identifier of the primary Routing Engine. The value range is 01 through 12. In the absence of
any Junos OS CLI configuration that affects mastership, the Routing Engine in the slot indicated
by REP will boot as the master, and the Routing Engine in slot REB will boot as the backup. The
value for this parameter must match the value set by the control-slot-numbers statement
configured through the Junos OS CLI.
REB Slot identifier of the backup Routing Engine. Typically, the value range is 01 through 12. Use 00 if
no backup Routing Engine is installed. In the absence of any Junos OS CLI configuration that
affects mastership, the Routing Engine in the slot indicated REB will boot as the backup.
PRD Routing platform type. The accepted values are T1600, T640, T320, or SCE (standalone control
element).

To enter the blade bay data:
2. Use the baydata command to configure the blade bay data. For example:
baydata -b 1 -data “V01–JCS01–SD01–PSD01–REP01–REB02–PRDT640”
baydata -b 2 -data “V01–JCS01–SD01–PSD01–REP01–REB02–PRDT640”
The bay data slots are Routing Engine slots 1 through 12 on the JCS chassis. In this
example, the blade bay data is configured for the Routing Engine in slot 1 and the
Routing Engine in slot 2. Blade 1 is the primary Routing Engine of PSD 1. Blade 2 is the
backup Routing Engine of PSD 1. PSD 1 is connected to RSD 1, and RSD 1 is a T640
router.
3. Repeat this procedure for each Routing Engine on the JCS1200 platform.
Related • Configuring an RSD and Creating PSDs on page 84

Documentation
• baydata on page 56
Configuring the Routing Engine (Blade) Name
JCS configuration should include a name for each Routing Engine (blade) included with
the JCS1200 platform. This name is used to identify each Routing Engine in CLI command
output and so on.
To configure the blade name information:
2. Use the env command to specify the blade you want to configure. For example:
system> env -T blade[1]
3. Use the config command to configure the blade name. For example:
system:blade[1]> config -name BLADE01
In this example, the blade name is BLADE01. This name identifies the JCS Routing
Engine on the network, and it appears in monitoring command output.
Related • env on page 62

Documentation
• config on page 60

CHAPTER 8
Summary of JCS Management Module

Configuration Commands
NOTE: The JCS management module command-line interface (CLI) provides

a large number of commands and command options. This section describes
only the subset of commands and command options that we recommend
for configuring the JCS1200 platform in a Juniper Networks environment.

alertentries
Syntax alertentries -T system:mm[x] -recipient-number <-f filter-type> <-n recipient-name>

<-status (on | off)> <-t snmp>
Release Information Command supported by Junos OS Release 9.1 and later.
Description (JCS management module CLI) Display or configure the recipients of SNMP alerts
generated by the JCS management module.
Options -T system:mm[x]—Specify a JCS management module as the command target. Replace

x with the primary management module number (1 or 2).
-recipient-number—Create or specify an alert recipient. Each alert recipient you create

must have a unique number (1 through 12).
-f filter-type—(Optional) Filter the type of alerts received by the alert recipient. Replace
filter-type with a value of critical (receive critical alerts only) or none (no filtering, receive
all alerts).
-n recipient-name—(Optional) Specify the name of the alert recipient. Recipient names

can be up to 31 characters in length. The name can include any character (including
spaces), except for less than (<) and greater than (>) symbols.
-status (on | off)—(Optional) Set alert status for the specified alert recipient. When the
status is on, the recipient receives alarm notifications. When the status is off, the recipient
does not receive alarm notifications.
-t snmp—(Optional) Sets SNMP as the alert notification method for the specified alert
recipient.
Required Privilege operator (display)

Level supervisor (display or configure)
Related • Configuring SNMP Traps on page 43

Documentation
• snmp on page 74
List of Sample Output alertentries (Display) on page 55

alertentries (Configure) on page 55
Output Fields Table 6 on page 54 lists the output fields for the alertentries command. Output fields are
listed in the approximate order in which they appear.
Table 6: alertentries Output Fields

Field Name Field Description
-status Alert status for the specified recipient. Alert status is on or off.

Chapter 8: Summary of JCS Management Module Configuration Commands
Table 6: alertentries Output Fields (continued)

-n Name of the specified alert recipient.
-f Type of alerts received by the specified alert recipient.
-t Alert notification method.
alertentries (Display) system> alertentries -T system:mm[1] -2

—status on
-n test1
-f critical
-t snmp
alertentries system> alertentries -T system:mm[1] -3 -f none -n trap -status on -t snmp

(Configure) OK

baydata
Syntax baydata <–b n> (-clear | -data “data-definition”)
Description (JCS management module CLI) Display, configure, or remove informational data (blade
bay data) associated with Routing Engine blades.
NOTE: When a blade restarts, the status should change from “BSMP” to
“Supported”. The "Supported" status indicates that the blade has been
restarted since the last baydata change for that blade, and it should have
the proper baydata configuration information. However, if the management
module (MM) is reset, all blades will show a "BSMP" status, because the MM
does not know if the blades have current baydata information after a restart.
As individual blades are restarted, their status should change to "Supported".
Options -b n—(Optional) Specify a specific Routing Engine. Replace n with the Routing Engine
slot number (1 through 12). If a Routing Engine is not specified, the command applies to
all Routing Engines in the JCS chassis.
–clear—Remove the blade bay data definition.
-data “data-definition”—Set the blade bay data. Blade bay data is an ASCII text string
with the following format: Vn-JCSn-SDn-PSDn-REPn-REBn-PRDplatform-type. Enclose
the text string in double quotation marks (” “).
• Vn—Version number of the blade bay data. Replace n with a version number. The
accepted value is 01.
• JCSn—JCS identifier. Replace n with the ID number of the JCS. The range of values is
01 through 04.
• SDn—RSD identifier. Replace n with the ID number of the RSD. The range of values is
01 through 03.
• PSDn—PSD identifier. Replace n with the ID number of the PSD. The range is 01 through
31.
• REPn—Slot number of the primary Routing Engine in a primary, backup Routing Engine
pair. Replace n with the slot number of the Routing Engine. The range is 01 through 12.
• REBn—Slot number of the backup Routing Engine in a primary, backup Routing Engine
pair. Replace n with the slot number of the Routing Engine. The range is 01 through 12.
• PRDplatform-type—Routing platform type. Replace platform-type with one of the

following values: T1600, T640, T320, or SCE (standalone control element).

Required Privilege supervisor

Level
Related • Configuring the Routing Engine Parameters (Blade Bay Data) on page 51
Documentation
• control-slot-numbers on page 114
• control-system-id on page 115
• root-domain-id on page 119
List of Sample Output baydata (Display) on page 57

baydata (Configure a Routing Engine) on page 57
baydata (Clear a Routing Engine) on page 57
baydata (Clear All Routing Engines) on page 57
Output Fields Table 7 on page 57 lists the output fields for the baydata command. Output fields are
Table 7: baydata Output Fields

Bay Slot number of the Routing Engine (blade).
Status Status of the Routing Engine.
Definition Blade bay data (if any) assigned to the Routing Engine.
baydata (Display) system> baydata

Bay Status Definition
1 Unsupported
2 No blade present
3 Supported V01–JCS01–SD01–PSD01–REP03–REB04–PRDT640
7 No blade present
8 No blade present
9 No blade present
10 No blade present
11 No blade present
12 No blade present
baydata (Configure a system> baydata —b 05 —data “V01–JCS01–SD01–PSD01–REP05–REB06–PRDT1600”

Routing Engine) OK
baydata (Clear a system> baydata –b 06 —clear

Routing Engine) OK
baydata (Clear All system> baydata —clear

Routing Engines) OK

clear
Syntax clear -config -T system:mm[x]
Description (JCS management module CLI) Restore the JCS management module configuration to
the default settings.
NOTE: Use this command to clear the JCS management module configuration
only. Do not clear the JCS switch module configuration.
Options -config—Specify the configuration is to be cleared.
-T system:mm[x]—Specify the management module as the target of the command (the

configuration to be cleared). Replace x with a value of 1 or 2.

Level
Related • Restoring the Default JCS Management Module Configuration on page 40

Documentation
• power on page 224
List of Sample Output clear on page 58
Output Fields No results are returned from this command. After the JCS management module resets,
you must start a new CLI session.
clear system> clear —config –T system:mm[1]

clock
Syntax clock <-d date> <-dst dst-mode> <-g offset> <-t time> -T system:mm[x]
Description (JCS management module CLI) Display or configure the JCS management module clock
settings.
Options -d date—(Optional) Current calendar date in mm/dd/yyyy format.
-dst dst-mode—(Optional) Daylight saving mode for the clock. Choices include:
• off—Daylight saving time is off (Standard time)
• uc—United States and Canada
• others—Nonstandard daylight saving time (outside the United States and Canada)
-g offset—(Optional) UTC (GMT) offset, in hours. Replace offset with a value from -12 to
+12.
-t time—(Optional) Current time in 24–hour hh:mm:ss format.
-T system:mm[x]—Specify the JCS management module as the target of the command.

Replace x with a value of 1 or 2.

Related • Configuring the Time Zone on page 43

Documentation
List of Sample Output clock (Display) on page 59

clock (Configure) on page 59
Output Fields When you enter this command, you are provide with feedback on the status of your
request.
clock (Display) system> clock –T system:mm[1]

03/31/2008 16:27:11 GMT+5:00 dst uc
clock (Configure) system> clock -d 04/01/2008 -t 22:12:04 dst uc –T system:mm[1]

OK

config
Syntax config -T target <-contact “contact-name”> <-name name> <-loc “location”>
Description (JCS management module CLI) Display configuration information or configure a device
on the JCS1200 platform.
Options -T target—Specify the target of the command. Command targets include:
• system:mm[x]—JCS management module. Replace x with a value of 1 or 2.
• system:blade[x]—JCS Routing Engine (blade). Replace x with a value of 1 through 12.
-contact “contact-hame”—(Optional) JCS management module only. Specify a contact

name for the primary JCS management module. Contact names must be enclosed in
double quotation marks (“ “) and can be up to 47 characters. Contact names can contain
any character except for less than (<) and greater than (>) symbols.
-name name—(Optional) Specify a device name. The device name can be up to 15

characters.
Routing Engine names can contain any character except for less than (<) and greater
than (>) symbols.
JCS management module names can contain only alphanumeric characters, hyphens
(–), pound signs (#), underscores (_), and periods (.).
NOTE: Unlike the contact name and location, the device name is not enclosed
in quotation marks.
-loc “location”—(Optional) JCS management module only. Specify the location of the
primary JCS management module. The location must be enclosed in double quotation
marks (“ ”) and can be up to 47 characters. A location can contain any character except
for less than (<) and greater than (>) symbols.

Related • Configuring the System Name and Contact Information on page 43

Documentation
List of Sample Output config (Display) on page 61

config (Configure a JCS Management Module) on page 61
config (Configure a Routing Engine) on page 61

Output Fields Table 8 on page 61 lists the output fields for the config command. Output fields are listed
in the approximate order in which they appear.
Table 8: config Output Fields

Name Device name
Contact Contact name for the primary JCS management module
Loc Location of the primary JCS management module
config (Display) system> config –T system:mm[1]

—name QA-Prototype
-contact John Markham
-loc QA Lab
config (Configure a JCS system> config –T system:mm[1] -contact “George Chu x2556” -name SW-MM1 -loc “SW Lab”
Management Module) OK
config (Configure a system> config –T system:blade[2] -name QA-Blade2

Routing Engine) OK

env
Syntax env -T target
Description (JCS management module CLI) Set the persistent environment for commands you enter
in the JCS management module. Commands entered during the remainder of the login
session apply to this target, unless you specify a new command target.
• system—JCS1200 platform. This is the default command target.
• system:switch[x]—JCS switch module. Replace x with a value of 1 or 2.
• system:power[x]—JCS power supply. Replace x with a value of 1 through 4.
• system:blower[x]—JCS fan (blower). Replace x with a value of 1 through 4.
• system:mt[x]—JCS media tray. Replace x with a value of 1 or 2.
Required Privilege operator

Level

Documentation
List of Sample Output env (JCS Management Module) on page 62
Output Fields When you enter this command, you are provided feedback on the status of your request.
The command prompt changes to reflect the new command target.
env (JCS Management system> env –T system:mm[1]

Module) OK
system:mm[1]>

exit
Syntax exit -T system:mm[x]
Description (JCS management module CLI) Terminate the current CLI session.
Options -T system:mm[x]—Specify a JCS management module as the target of the command.


Level

Documentation
List of Sample Output exit on page 63
Output Fields When you enter this command, no feedback is provided. Instead, the user login prompt
appears.
exit system> exit –T system:mm[1]

username:

help
Syntax [help | ?]
<command [–help | -h | ?]>
Description (JCS management module CLI) Display a list of available commands with a brief
description of each command. You can also add a –help, -h, or ? option to a command
to display help for the command.
Options command [-help | -h | ?]—(Optional) Specify help for a specific command.

Level

Documentation
List of Sample Output help on page 64
help system> help

? – Display commands
accseccfg — View/edit account security config
advfailover — View/edit advanced failover mode
alarm — Manage Telco System Management alarm(s)
alertcfg — Displays/Configures the global remote alert systems
alertentries — View/edit remote alarm recipients
baydata — View/edit Blade Bay Data string
...

ifconfig (JCS Management Module)
Syntax ifconfig -T system:mm[x] (-eth0 | -eth1) <enabled | disabled> <-c static>

<-g gateway-address> <-i static-ip-address> <-s subnet-mask>
Description (JCS management module CLI) Configure or display the JCS management module
Ethernet interface.

x with the primary management module number (1 or 2). The JCS management module
is the only valid target available for this command.
-eth0 | -eth1—Specify Ethernet channel 0 or Ethernet channel 1.
enabled | disabled—(Optional) Enable or disable the Ethernet interface on the JCS

management module.
-c static—(Optional) Specify static IP configuration.
-g gateway-address—(Optional) Gateway IP address of the Ethernet interface on the JCS

management module.
-i static-ip-address—(Optional) Static IP address of the Ethernet interface on the JCS

management module.
-s subnet-mask—(Optional) Subnet mask of the Ethernet interface on the JCS

management module.

Related • Configuring the JCS Management Module Ethernet Interface on page 40

Documentation
List of Sample Output ifconfig (Display) on page 66

ifconfig (Configure) on page 66
Output Fields Table 9 on page 65 lists the output fields for the ifconfig command. Output fields are
Table 9: ifconfig Output Fields

-i IP address of the Ethernet interface on the JCS management

module.
-g Gateway IP address of the Ethernet interface on the JCS

management module.

Table 9: ifconfig Output Fields (continued)

-s Subnet mask of the Ethernet interface on the JCS management

module.
-c Configuration method (static) for the Ethernet interface on the JCS

management module.
ifconfig (Display) system> ifconfig -T system:mm[1] -eth0

Enabled
-i 192.168.171.96
-g 192.168.171.254
—s 255.255.252.0
-c static
ifconfig (Configure) system> ifconfig -T system:mm[1] —eth0 -c static —i 157.210.171.96 -g 157.210.171.254 —s

255.255.252.0
OK

ifconfig (JCS Switch Module)
Syntax ifconfig -T system:switch[x] <-c static> <-em (enabled | disabled)> <-ep (enabled |
disabled)> <-g gateway-address> <-i static-ip-address> <-s subnet-mask>
Description (JCS management module CLI) Configure or display the JCS switch module Ethernet
interface.
Options -T system:switch[x]—Specify a JCS switch module as the command target. Replace x

with the primary management module number (1 or 2). The JCS switch module is the
only valid target available for this command.
NOTE: For redundancy, you must configure the Ethernet interface for both
JCS switch modules.
-c static—(Optional) Specify static IP configuration.
-em (enabled | disabled)—(Optional) Enable or disable external management of all ports

on the JCS switch module.
-ep (enabled | disabled)—(Optional) Enable or disable external ports on the JCS switch
module.
-g gateway-address—(Optional) Gateway IP address of the Ethernet interface on the JCS

switch module.
-i static- ip-address—(Optional) Static IP address of the Ethernet interface on the JCS

switch module.
-s subnet-mask—(Optional) Subnet mask of the Ethernet interface on the JCS switch

module.

Related • Configuring the Switch Module Ethernet Interface on page 41

Documentation
List of Sample Output ifconfig (Display) on page 68

ifconfig (Configure) on page 68

Output Fields Table 10 on page 68 lists the output fields for the ifconfig command. Output fields are
Table 10: ifconfig Output Fields

-i IP address of the Ethernet interface on the JCS switch module.
-g Gateway IP address of the Ethernet interface on the JCS switch

module.
-s Subnet mask of the Ethernet interface on the JCS switch module.
-c Configuration method (static) for the Ethernet interface on the JCS

switch module.
ifconfig (Display) system> ifconfig -T system:switch[1]

-i 192.168.171.96
-g 192.168.171.254
—s 255.255.252.0
-c static
ifconfig (Configure) system> ifconfig -T system:switch[1] -c static –em enabled —ep enabled —i 157.210.171.98 -g
157.210.171.254 —s 255.255.252.0
OK

monalerts
Syntax monalerts -T system:mm[x] <-ca (enabled | disabled)> <-ec (enabled | disabled)> <-ia
(enabled | disabled)> <-wa (enabled | disabled)>
Description (JCS management module CLI) Display or configure alerts monitored by the JCS
management module.

-ca (enabled | disabled)—(Optional) Enable or disable monitoring of all critical alerts.
-ec (enabled | disabled)—(Optional) Enable or disable enhanced legacy alert categories.

When enhanced legacy alert categories are enabled, alerts can be configured using the
monalerts command.
NOTE: Make sure enhanced legacy alerts are enabled for the JCS1200
platform.
-ia (enabled | disabled)—(Optional) Enable or disable monitoring of all informational

alerts.
-wa (enabled | disabled)—(Optional) Enable or disable monitoring of all warning alerts.


Documentation
• alertentries on page 54
• snmp on page 74
List of Sample Output monalerts (Display) on page 70

monalerts (Configure) on page 70
Output Fields Table 11 on page 69 lists the output fields for the monalerts command. Output fields are
Table 11: monalerts Output Fields

-ca Status (enabled or disabled) of critical alert monitoring.

Table 11: monalerts Output Fields (continued)

-ec Status (enabled or disabled) of enhanced legacy alert categories.

When enabled, legacy alert categories can be configured with the
monalerts command.
-ia Status (enabled or disabled) of informational alert monitoring.
-wa Status (enabled or disabled) of warning alert monitoring.
monalerts (Display) system> monalerts -T system:mm[1]

-ca enabled
-ec enabled
-ia disabled
-wa disabled
monalerts (Configure) system> monalerts -T system:mm[1] -ia enable -wa enable

OK

mt
Syntax mt -T system <-b n>
Description (JCS management module CLI) Configure or display the Routing Engine (blade) that is
in control of the JCS media tray (mt). You can use the media tray to copy Junos OS from
a USB device to a Routing Engine installed in the JCS chassis.
Options -T system—Display the media tray owner.
-b n—(Optional) Configure which Routing Engine controls (owns) the media tray. Replace
n with a value of 1 through 12 to indicate the slot number of the Routing Engine to which
you want to assign control of the media tray.

Related • Troubleshooting a Routing Engine on the JCS1200 Platform on page 253

Documentation
List of Sample Output mt (Configure) on page 71

mt (Display) on page 71
mt (Configure) system:mm[1]> mt -T system —b 12
OK
mt (Display) system:mm[1]> mt -T system
-b 12

ntp
Syntax ntp -T system:mm[x] <-en (enabled | disabled)> <-i ip-address | hostname> <-f
update-frequency> <-synch>
Description (JCS management module CLI) Configure or display the JCS management module
network time protocol (NTP) settings.

x with the primary management module number (1 or 2). The JCS management module
is the only valid target available for this command.
-en (enabled | disabled)—(Optional) Enable or disable NTP for the JCS management
module.
-i ip-address|hostname—(Optional) IP address or hostname of the NTP server.
-f update-frequency—(Optional) Update frequency (in minutes). The JCS management

module clock is automatically updated at the frequency specified. Replace
update-frequency with a value from 1 through 45000.
-synch—(Optional) Synchronize the JCS management module clock with the NTP server.

Related • Configuring the NTP Server on page 42

Documentation
List of Sample Output ntp (Display) on page 73

ntp (Configure) on page 73
Output Fields Table 12 on page 72 lists the output fields for the ntp command. Output fields are listed
Table 12: ntp Output Fields

-en NTP status (enabled or disabled).
-i IP address or hostname of the NTP server.
-f How often (in minutes) the JCS management module is updated

by the NTP server.
-v3en V3 authentication status (enabled or disabled) between the JCS

management module and the NTP server.

ntp (Display) system> ntp -T system:mm[1]

-en enabled
-i timeserver
-f 5
-v3en disabled
ntp (Configure) system> ntp -T system:mm[1] -en enable -I timeserver2 -f 15

OK

snmp
Syntax snmp -T system:mm[x] <-cax community-type> <-cx community-name> <-cxin (ip-address

| hostname)> <-cn contact-name> <-l location>
Description (JCS1200 platform only) Display or configure SNMP settings on the JCS management
module.
Options -T system:mm[x]—Specify the JCS management module as the target of the command.
-cax community-type—(Optional) Specify an SNMPv3 view type for the community. View
types can be get, set, or trap. Replace x with a value of 1 through 3 to represent the
community number.
-cx community-name—(Optional) Specify a descriptive name for the community. Replace

x with a value of 1 through 3 to represent the community number.
-cxin (ip-address | hostname)—(Optional) Specify an IP address or hostname for the

community. Replace x with a value of 1 through 3 to represent the community number.
Replace n with a value of 1 through 3 to represent the host ranking (first, second, or third).
You can specify up to three hosts for each community.
-cn contact-name—(Optional) Specify a contact name for the SNMP community host
server.
-l location—(Optional) Specify a location for the SNMP community host server.


Documentation
• alertentries on page 54
List of Sample Output snmp (Display) on page 75

snmp (Configure) on page 75
Output Fields Table 13 on page 74 lists the output fields for the snmp command. Output fields are listed
Table 13: snmp Output Fields

a Status of the SNMP agent (enabled or disabled)

Table 13: snmp Output Fields (continued)

t Status of the SNMP traps (enabled or disabled)
cx Descriptive name for the community
cxin IP address and ranking of the community host
cn Contact name for the SNMP community host server
-l Location of the SNMP community host server
snmp (Display) system> snmp -T system:mm[1]

To be provided.
snmp (Configure) system> snmp -T system:mm[1] -ca1 trap -c1 Traps -c3i1 192.168.171.100
OK

sshcfg
Syntax sshcfg -T system:mm[x] <-cstatus (enabled | disabled)> <-hk (rsd | dsa | gen)> <-v1 (on |
off)>
Description (JCS1200 platform only) Display or configure SSH access on the JCS management
module.
-cstatus (enabled | disabled)—(Optional) Enable or disable the SSH server on the JCS
management module.
-hk gen—(Optional) Generate a host key for the JCS management module.
-hk (rsa | dsa)—(Optional) Display RSA or DSA host key information for the JCS
management module.
-v1 (on | off)—(Optional) Enable or disable SSH v1 on the JCS management module. (SSH
v2 is always enabled.)

Related • Configuring SSH Access on page 45

Documentation
List of Sample Output sshcfg (Display) on page 77

sshcfg (Configure) on page 77
Output Fields Table 14 on page 76 lists the output fields for the sshcfg command. Output fields are
Table 14: sshcfg Output Fields

v1 SSH v1 status (On or Off). SSH v2 is always enabled (On).
cstatus Status of the CLI SSH server (enabled or disabled).
CLI SSH port Port number assigned to the CLI SSH server.
sstatus Status of the SMASH (secure mashup) SSH server (enabled or

disabled).
SMASH SSH port Port number assigned to the SMASH SSH server.

Table 14: sshcfg Output Fields (continued)

ssh-dss DSS fingerprint for the SSH server. This fingerprint is used to verify
the authenticity of the server.
ssh-rsa RSA fingerprint for the SSH server. This fingerprint is used to verify
the authenticity of the server.
x SSH public keys Number of SSH public keys installed.
x Locations Number of locations available to store SSH public keys.
sshcfg (Display) system> sshcfg -T system:mm[1]

-v1 off
-cstatus enabled
CLI SSH port 22
-sstatus disabled
SMASH SSH port 50024
ssh-dss 2048 bit fingerprint: 27:ee:bd:a9:27:28:d8:a5:93:03:3d:8e:77:d0:38:2c
ssh-rsa 2048 bit fingerprint: 66:c9:73:4f:18:11:02:10:f3:05:6e:d7:27:05:a5:01
2 SSH public keys installed
10 locations available to store SSH public keys
sshcfg (Configure) system> sshcfg -T system:mm[1] -hk gen -cstatus enabled

OK

users
Syntax users <-user-number> (-n user-name -p user-password -a user-authority | –clear)
Description (JCS1200 platform only) Display, configure, or clear user accounts on the JCS
management module.
Options -user-number—(Optional) Unique number assigned to the user. Replace user-number

with a value from 1 through 12. If a user number is not specified, the command applies to
all users.
-n user-name—Login name of the user: An alphabetic string up to 15 characters long that

can include periods (.) and underscores (_). User names must be unique.
-p user-password—User password: An alphabetic string up to 15 characters long that can

include periods (.) and underscores (_). A password must include at least one alphabetic
character and one non-alphabetic character.
-a user-authority—Command authority assigned to the user. Valid values are super

(supervisor) or operator. A supervisor has full read and write access. An operator has
read access only.
-clear—Remove a user account.

Level
Related • Configuring User Accounts on page 42

Documentation
List of Sample Output users (Display All Users) on page 79

users (Configure a User Account) on page 79
users (Clear a User Account) on page 79
users (Clear All User Accounts) on page 79
Output Fields Table 15 on page 78 lists the output fields for the users command. Output fields are listed
Table 15: users Output Fields

User ID User number and name.
Role Authority level assigned to the user. Users can have either supervisor
or operator authority.
Blades Routing Engines (blades) to which the user has access. By default,
users have access to all Routing Engines.

Table 15: users Output Fields (continued)

Chassis JCS management module to which the user has access.
Switches JCS switch modules to which the user has access. By default, users
have access to all switch modules.
users (Display All system:mm[1]> users

Users)
1. USERID
Role: supervisor
Blades:1|2|3|4|5|6|7|8|9|10|11|12
Chassis:1
Switches:1|2
2. <not used>
3. chang
Role: supervisor
Blades:1|2|3|4|5|6|7|8|9|10|11|12
Chassis:1
Switches:1|2
4. markham
Role: operator
Blades:1|2|3|4|5|6|7|8|9|10|11|12
Chassis:1
Switches:1|2
5. <not used>
6. <not used>
7. <not used>
8. <not used>
9. <not used>
10. <not used>
11. <not used>
12. <not used>
users (Configure a User system:mm[1]> users –5 akbar –p PWD.2 –a super

Account) OK
users (Clear a User system:mm[1]> users –3 -clear

Account) OK
users (Clear All User system:mm[1]> users -clear

Accounts) OK


PART 4
Configuring the Junos OS

• Configuring Basic System Properties on a New PSD on page 87
• Configuring Shared Interfaces on page 93
• Configuring Inter-PSD Forwarding on page 107
• Summary of Junos Configuration Statements on page 113


CHAPTER 9
Configuring an RSD and Creating PSDs
• System Domains Configuration Hierarchy on page 83

System Domains Configuration Hierarchy
Using the Junos OS command-line interface (CLI), you configure Root System Domain
(RSD) and Protected System Domain (PSD) parameters at the [edit chassis
system-domains] hierarchy level:
[edit chassis]
system-domains {
protected-system-domains psdn {
control-plane-bandwidth-percent percent;
control-slot-numbers [ slot-numbers ];
control-system-id control-system-id;
description description;
fpcs [ slot-numbers ];
}
root-domain-id root-domain-id;
}
Related • Protected System Domains on page 4

Documentation

Configuring an RSD and Creating PSDs
To configure a Root System Domain (RSD), create Protected System Domains (PSDs)
under it, and assign FPCs from the T Series router and Routing Engines from the JCS1200
routing platform to each PSD, perform the following steps.
NOTE: Several of the values set through the following Junos configuration
statements must match the values set by the baydata command through
the JCS management module CLI. For the baydata command format, see
baydata.
1. Log in to the master Routing Engine on the T Series router.
2. At the [edit chassis system-domains] hierarchy level, include the root-domain-id

root-domain-id configuration statement. The range of values for root-domain-id is 1
through 3.
This value for this statement must match the SD value set through the baydata
command.
3. At the [edit chassis system-domains] hierarchy level, include the

protected-system-domains psdn configuration statement. The range of values n is 1
to 31.
NOTE: The PSD identifier must be unique for each RSD. For example, if
PSD1 is assigned to RSD1, neither RSD2 nor RSD3 can contain PSD1.
The value for this statement must match the PSD value set through the baydata
command.
4. At the [edit chassis system-domains protected-system-domains psdn] hierarchy level,

include the following statements:
• control-plane-bandwidth-percent percent—Assign the percentage of bandwidth

that exists on the JCS switch modules and the T Series Control Boards (T-CBs) to
the PSD. The range of values is 1 to 100. Allocating bandwidth prevents potential
overutilization by one PSD over another.
• description description—Provide a description for the PSD.
• fpcs [ slot-numbers ]—Assign FPCs to the PSD.
For Junos OS Release 9.4, supported values for slot-numbers are 0 through 7.
• control-system-id control-system-id—Assign an ID to the JCS1200 platform. The

value for control-system-id can be 1 through 4.
The value for this statement must match the JCS value set through the baydata
command.

Chapter 9: Configuring an RSD and Creating PSDs
• control-slot-numbers [ control-slot-numbers ]—Assign a Routing Engine or pair of

redundant Routing Engines on the JCS1200 platform to the PSD.
The value for control-slot-numbers for the primary Routing Engine assigned to the
PSD must match the REP value set through the JCS management module baydata
command. Similarly, the value for control-slot-numbers for the backup Routing
Engine must match the REB value set through the baydata command. In the absence
of any Junos OS CLI configuration that affects mastership, the Routing Engine in
the slot indicated by REP will boot as the master, and the Routing Engine in slot
REB will boot as the backup. See baydata.
Related • Protected System Domains on page 4

Documentation
• System Domains Configuration Hierarchy on page 83
• Example: Configuring a JCS1200 Platform and a Single T Series Router on page 123


CHAPTER 10
Configuring Basic System Properties on a

New PSD

Configuring a PSD with a Single Routing Engine
To initially configure a PSD with a single Routing Engine:
1. Connect to the console port on the Routing Engine that is assigned to the PSD you
want to configure.
2. At the login prompt on the console, log in with the username root.
Initially, the root user account requires no password. You can see that you are the root
user, because the prompt on the routing platform shows the username root@%.
3. Start the Junos OS command-line interface (CLI):
root@% cli
root@>
4. Enter Junos OS configuration mode:
cli> configure
[edit]
root#
5. Configure the name of the routing platform (the routing platform hostname). We do
not recommend spaces in the routing platform name. However, if the name does
include spaces, enclose the entire name in quotation marks (" ").
[edit]
root# set system host-name host-name
6. Configure the routing platform’s domain name:
[edit]
root# set system domain-name domain-name
7. Configure the IP addresses and prefix lengths for one or both of the router management
Ethernet interfaces (fxp0 and fxp1) on each Routing Engine.
[edit]

root# set interfaces fxp0 unit 0 family inet address address/prefix-length
If both interfaces are configured (for JCS switch module redundancy), we recommend
that the IP address for each interface be on a separate subnet. The fxp0 interface
connects to port 6 on the JCS switch module in bay 1, whereas the fxp1 interface
connects to port 6 on the JCS switch module in bay 2.
8. Configure the IP address of a backup or default routing platform.
[edit]
root# set system backup-router address
Choose a router that is directly connected to the local routing platform by way of the
management interface.
9. Configure the IP address of a DNS server. The routing platform uses the DNS name
server to translate hostnames into IP addresses.
[edit]
root# set system name-server address
10. Set the root password, entering a clear-text password that the system will encrypt,
a password that is already encrypted, or an SSH public key string.
Choose one of the following:
• To enter a clear-text password, use the following command:
[edit]
root# set system root-authentication plain-text-password
New password: type password
Retype new password: retype password
• To enter a password that is already encrypted, use the following command:
[edit]
root# set system root-authentication encrypted-password encrypted-password
• To enter an SSH public key, use the following command:
[edit]
root# set system root-authentication ssh-rsa key
11. Commit the configuration, which activates the configuration on the routing platform:
[edit]
root# commit
After committing the configuration, you see the newly configured hostname appear
after the username in the prompt; for example, user@host#.
Junos OS defaults are now set on the routing platform.
If you want to configure additional Junos OS properties at this time, remain in the CLI
configuration mode and add the necessary configuration statements. For more
information about how to configure additional properties, see the Junos System Basics
Configuration Guide. You will need to commit your configuration changes to activate
them on the routing platform.
12. Exit from the Junos OS configuration mode.

Chapter 10: Configuring Basic System Properties on a New PSD
[edit]
root@host-name# exit
root@host-name>
13. Issue the request system snapshot command to back up the configuration to the
/altconfig file system on the hard drive.
If you do not issue the request system snapshot command, the configuration on the
alternate boot device will be out of sync with the configuration on the primary boot
device. The request system snapshot command causes the root file system to be
backed up to /altroot, and /config to be backed up to /altconfig. The root and /config
file systems are on the routing platform’s flash disk, and the /altroot and /altconfig
file systems are on the routing platform’s hard disk.
and the backup copy of the software are identical.
NOTE: The logout-on-disconnect statement at the [edit system ports console]

hierarchy level is not supported for Routing Engines on the JCS1200 platform.
When the cable is unplugged from the Routing Engine, the user is not logged
out of the console session.

Documentation
Configuring a PSD with Redundant Routing Engines
To initially configure a PSD with redundant Routing Engines:
1. Connect to the console port on the Routing Engine that is assigned to the PSD you
want to configure.
2. At the login prompt on the console, log in with the username root.
Initially, the root user account requires no password. You can see that you are the root
user, because the prompt on the routing platform shows the username root@%.
3. Start the Junos OS command-line interface (CLI):
root@% cli
root@>
4. Enter Junos OS configuration mode:
cli> configure
[edit]
root#

5. Configure a hostname and the IP addresses and prefix lengths for one or both of the
router management Ethernet interfaces (fxp0 and fxp1) on each Routing Engine.
If both interfaces are configured (for JCS switch module redundancy), we recommend
that the IP address for each interface be on a separate subnet. The fxp0 interface
connects to port 6 on the JCS switch module in bay 1, whereas the fxp1 interface
connects to port 6 on the JCS switch module in bay 2.
[edit]
root# edit groups
[edit groups]
root# set re0 system host-name router1
root# set re0 interfaces fxp0 unit 0 family inet address 10.10.10.1/24
6. Configure the routing platform’s domain name:
[edit]
root# set system domain-name domain-name
7. Set the loopback interface address for each Routing Engine.
[edit groups]
root# set re0 interfaces lo0 unit 0 family inet address 2.2.2.1/32
root# set re1 interfaces lo0 unit 0 family inet address 2.2.2.2/32
8. Issue the apply-groups statement to reproduce the configuration group information

to the main part of the configuration.
[edit groups]
root# top
[edit]
root# set apply-groups [re0 re1]
9. Configure Routing Engine redundancy:
[edit]
root# set chassis redundancy routing-engine 0 master
root# set chassis redundancy routing-engine 1 backup
root# set chassis redundancy routing-engine graceful-switchover
10. Save the configuration change on both Routing Engines:
[edit]
root# commit synchronize
11. Configure the IP address of a backup or default routing platform.
[edit]
root# set system backup-router address
Choose a router that is directly connected to the local routing platform by way of the
management interface.

Chapter 10: Configuring Basic System Properties on a New PSD
12. Configure the IP address of a DNS server. The routing platform uses the DNS name
server to translate hostnames into IP addresses.
[edit]
root# set system name-server address
13. Set the root password, entering a clear-text password that the system will encrypt,
a password that is already encrypted, or an SSH public key string.
Choose one of the following:
• To enter a clear-text password, use the following command:
[edit]
root# set system root-authentication plain-text-password
New password: type password
Retype new password: retype password
• To enter a password that is already encrypted, use the following command:
[edit]
root# set system root-authentication encrypted-password encrypted-password
• To enter an SSH public key, use the following command:
[edit]
root# set system root-authentication ssh-rsa key
14. After you have installed the new software and are satisfied that it is successfully
running, issue the request system snapshot command to back up the new software
on both master and backup Routing Engines.
{master}
user@host> request system snapshot
The root file system is backed up to /altroot, and /config is backed up to /altconfig.
The root and /config file systems are on the routing platform’s flash disk, and the
/altroot and /altconfig file systems are on the routing platform’s hard disk.
and backup copy of the software are identical.
NOTE: The logout-on-disconnect statement at the [edit system ports console]

hierarchy level is not supported for Routing Engines on the JCS1200 platform.
When the cable is unplugged from the Routing Engine, the user is not logged
out of the console session.

Documentation


CHAPTER 11
Configuring Shared Interfaces
• Interfaces Hierarchy on page 93

• Configuring Shared Interfaces on page 94
Interfaces Hierarchy
To configure shared interfaces, you must be familiar with the [edit interfaces] hierarchy
in the Junos configuration command-line interface (CLI).
Configuration statements that are unique to shared interfaces are:
• shared-interface at the [edit interfaces so-fpc/pic/slot], [edit interfaces ge-fpc/pic/slot],

and [edit interfaces xe-fpc/pic/slot] hierarchy levels
• interface-shared-with at the [edit interfaces so-fpc/pic/slot unit logical unit-number],

[edit interfaces ge-fpc/pic/slot unit logical unit-number], and [edit interfaces
xe-fpc/pic/slot unit logical unit-number] hierarchy levels
For detailed information about all other configuration statements under the [edit
interfaces] hierarchy, see the Junos OS Network Interfaces Configuration Guide.
interfaces {
ge-fpc/pic/slot {
vlan-tagging;
shared-interface;
unit logical-unit-number {
vlan-id number;
peer-interface interface-name;
interface-shared-with psdn;
family family {
address ip-address;
}
}
}
so-fpc/pic/slot {
encapsulation frame-relay;
shared-interface;
dlci dlci-identifier;

family family {
address ip-address;
}
}
}
xe-fpc/pic/slot {
shared-interface;
vlan-id number;
family family {
address ip-address;
}
}
}
ut-fpc/pic/slot {
}
}
}
Related • Shared Interfaces on page 5

Documentation
Configuring Shared Interfaces
• Before You Configure Shared Interfaces on page 94

• Configuring Firewall Filters on Shared Interfaces on page 102
• Configuring CoS Features on Shared Interfaces on page 104
Before You Configure Shared Interfaces

Before you configure shared interfaces, remember that on the Root System Domain
(RSD), you configure the physical interface and then configure and assign each logical
shared interface under it to a specific Protected System Domain (PSD).
On the PSD, you configure the physical interface as well and identify it as a shared
interface. Then configure the assigned logical interfaces under it and bind each one to a
peer interface on the Tunnel PIC owned by the PSD.
When you configure shared interfaces, the values for several parameters configured on
the RSD and the PSD must match:

Chapter 11: Configuring Shared Interfaces
• On the physical SONET interface, Frame Relay encapsulation must be configured in

both the RSD and the PSD. (Point-to-multipoint Frame Relay is not supported.) Frame
Relay encapsulation enables a change in state to be communicated between the RSD
and the PSD. Status is communicated through Local Management Interface (LMI)
packets exchanged on data-link connection identifier (DLCI) 0. LMI packet exchanges
are managed by the RSD.
On the physical Gigabit Ethernet interface, VLAN tagging must be configured in both
the RSD and the PSD.
• On the physical SONET interface, the same maximum transmission unit (MTU) size
must be used in both the RSD and PSD. For example, in both the RSD and PSD, do not
include any MTU configuration to allow the default MTU size to be applied to the
physical interface. Or, in both the RSD and PSD, configure the same MTU size. For
example, in both the RSD and PSD configuration, include the mtu 5000 statement
under the [edit so-0/0/1] hierarchy level.
• The same logical unit number must be specified on the physical shared interface
(so-fpc/pic/slot.logical unit-number, ge-fpc/pic/slot.logical unit-number, or
xe-fpc/pic/slot.logical unit-number) and on the physical uplink tunnel interface
(ut-fpc/pic/slot.logical unit-number) owned by the PSD. For example, in both the RSD
and PSD configuration, specify so-0/0/0.1 as the logical SONET interface. In the PSD
configuration, configure ut-0/0/0.1 as the logical peer tunnel interface.
• On the logical SONET interface, the same DLCI must be configured in both the RSD
and the PSD. For example, at the [edit interfaces so-0/0/0.1] hierarchy level, include
the dcli 101 statement in both the RSD and PSD configuration.
On the logical Ethernet interface, the same virtual LAN (VLAN) identifier must be
configured in both the RSD and the PSD. For example, at the [edit interfaces ge-0/0/0.2]
hierarchy level, include the vlan-id 102 statement in both the RSD and PSD configuration.

Documentation
Configuring Shared Interfaces on the RSD

To configure shared interfaces on the RSD:
1. Configure the physical interface using the so-fpc/pic/slot, ge-fpc/pic/slot, or

xe-fpc/pic/slot statement at the [edit interfaces] hierarchy level.
2. Configure Frame Relay encapsulation or VLAN tagging.
• For Frame Relay encapsulation, use the encapsulation frame-relay statement at

the [edit interfaces so-fpc/pic/slot] hierarchy level.
• For VLAN tagging, use the vlan-tagging statement at one of the following hierarchy
levels: [edit interfaces ge-fpc/pic/slot] or [edit interfaces xe-fpc/pic/slot].

3. Configure logical interfaces under the physical interface using the unit
logical-unit-number statement at the [edit interfaces so-fpc/pic/slot] hierarchy level,
the [edit interfaces ge-fpc/pic/slot] hierarchy level, or the [edit interfaces
xe-fpc/pic/slot] hierarchy level.
NOTE: For Ethernet shared interfaces on the JCS 1200 platform,

gratuitous-arp configuration statements are supported on the Root System
Domain (RSD), but not on the Protected System Domain (PSD). These
statements are configured at the [edit interfaces ge-fpc/pic/slot] hierarchy
level. These statements include: gratuitous-arp-reply,
no-gratuitous-arp-replay, and no-gratuitous-arp-request. Values you
configure for gratuitous-arp statements on the RSD are not passed to the
PSD.
4. For each logical SONET interface, include the following statements at the [edit
interfaces so-fpc/pic/slot.logical-unit-number] hierarchy level:
• dlci dlci-identifier—Assigns a DLCI for the point-to-point Frame Relay connection

between the RSD and the PSD.
• interface-shared-with psdn—Assigns the logical interface to a PSD.
For each logical Gigabit Ethernet interface, include the following statements at one
of the following hierarchy levels: [edit interfaces ge-fpc/pic/slot.logical-unit-number]
or [edit interfaces xe-fpc/pic/slot.logical-unit-number].
• vlan-id number—Binds an 802.1Q VLAN identifier tag to the logical interface.
• interface-shared-with psdn—Assigns the logical interface to a PSD.
In the following example, so-0/0/0.0 and so-0/0/0.1 belong to PSD1, whereas PSD2
owns so-0/0/0.2:
interfaces {
so-0/0/0 {
unit 0 {
dlci 100;
interface-shared-with psd1;
}
unit 1 {
dlci 101;
}
unit 2 {
dlci 102;
}
}
}

In the following example, ge-1/0/0.1 and ge-1/0/0.2 belong to PSD1, whereas PSD2 owns
ge-1/0/0.3:
interfaces {
ge-1/0/0 {
vlan-tagging;
unit 1{
vlan-id 100;
}
unit 2{
vlan-id 101;
}
unit 3{
vlan-id 102;
}
}
}
In the following example, xe-5/0/0.0 and xe-5/0/0.1 belong to PSD4:
interfaces {
xe-5/0/0 {
vlan-tagging;
unit 0{
vlan-id 209;
}
unit 1{
vlan-id 200;
}
}
}

Documentation
• Example: Configuring Shared Interfaces (SONET) on page 136
Configuring Shared Interfaces on a PSD

To configure shared interfaces on a PSD:
1. Configure the physical interface at the [edit interfaces] hierarchy level by doing one
of the following:
• Configure the physical SONET interface using the so-fpc/pic/slot statement.

• Configure the physical Gigabit Ethernet interface using the ge-fpc/pic/slot statement.
• Configure the physical 10-Gigabit Ethernet interface using the xe-fpc/pic/slot

statement.
2. Configure Frame Relay encapsulation or VLAN tagging:
• For Frame Relay encapsulation, use the encapsulation frame-relay statement at

the [edit interfaces so-fpc/pic/slot] hierarchy level.
• For VLAN tagging, use the vlan-tagging statement at one of the following hierarchy
levels: [edit interfaces ge-fpc/pic/slot] or [edit interfaces xe-fpc/pic/slot].
3. Identify the physical interface as a shared interface by including the shared-interface

statement at one of the following hierarchy levels: [edit interfaces so-fpc/pic/slot],
[edit interfaces ge-fpc/pic/slot], or [edit interfaces xe-fpc/pic/slot].
NOTE: For Ethernet shared interfaces on the JCS 1200 platform,

gratuitous-arp configuration statements are supported on the Root System
Domain (RSD), but not on the Protected System Domain (PSD). These
statements are configured at the [edit interfaces ge-fpc/pic/slot] hierarchy
level. These statements include: gratuitous-arp-reply,
no-gratuitous-arp-replay, and no-gratuitous-arp-request. Values you
configure for gratuitous-arp statements on the RSD are not passed to the
PSD.
4. Configure logical interfaces under the physical interface using the unit
logical-unit-number statement at one of the following hierarchy levels: [edit interfaces
so-fpc/pic/slot], or [edit interfaces ge-fpc/pic/slot], or [edit interfaces xe-fpc/pic/slot].
The values for logical-unit-number must match the values set in the RSD configuration.
5. For each logical interface, include the following statements:
• For SONET interfaces, include the dlci dlci-identifier statement at the [edit interfaces
so-fpc/pic/slot unit logical-unit-number] hierarchy level to assign a data-link
connection identifier (DLCI) for the point-to-point Frame Relay connection between
the RSD and the PSD. The value for dlci-identifier must match the value set in the
RSD configuration for the specified logical SONET interface.
• For Gigabit Ethernet interfaces, include the vlan-id number statement at one of the
following hierarchy levels: [edit interfaces ge-fpc/pic/slot unit logical-unit-number]
or [edit interfaces xe-fpc/pic/slot unit logical-unit-number] to bind an 802.1Q VLAN
identifier tag to the logical interface. The value for number must match the value
set in the RSD configuration for the specified logical Gigabit Ethernet interface.
6. For each logical interface, include the peer-interface interface-name statement to

configure the tunnel peer interface that is bound to the logical interface.
7. For each logical interface, include the family family statement to configure the protocol
family for the logical interface.

8. Configure the IP address of the logical interface using the address address statement
at one of the following hierarchy levels: [edit interfaces so-fpc/pic/slot unit
logical-unit-number family family], or [edit interfaces ge-fpc/pic/slot unit
logical-unit-number family family], or [edit interfaces xe-fpc/pic/slot unit
logical-unit-number family family].
9. Configure the physical tunnel interface using the ut-fpc/pic/slot statement at the [edit
interfaces] hierarchy level.
10. Configure the logical tunnel interfaces using the unit logical-unit-number statement
at the [ut-fpc/pic/slot] hierarchy level.
The logical unit number must match the value of the logical unit number for the
physical shared interface. For example, if the shared interface logical unit is 1 (as part
of so-0/0/0.1), configure ut-0/0/0.1 as the logical peer tunnel interface.
11. For each logical tunnel interface, specify the logical peer interface on the SONET,
Gigabit Ethernet, or 10-Gigabit Ethernet PIC using the peer-interface statement at the
[ut-fpc/pic/slot unit logical-unit-number] hierarchy level.
As described in Step 10, the logical unit number for the shared interface and the uplink
tunnel interface must match.
SONET (PSD1) In the following example, logical SONET interface so-0/0/0.0 is peered with logical
tunnel interface ut-1/0/0.0 and so-0/0/0.1 is peered with ut-1/0/0.1.
interfaces {
so-0/0/0 {
shared-interface;
unit 0 {
dlci 100;
peer-interface ut-1/0/0.0;
family inet {
address 10.10.10.1/24;
}
}
unit 1 {
dlci 101;
peer-interface ut-1/0/0.1
family inet {
address 10.10.11.1/24;
}
}
}
ut-1/0/0 {
unit 0 {
peer-interface so-0/0/0.0;
}
unit 1 {
}
}
}

SONET (PSD2) In the following example, logical SONET interface so-0/0/0.2 is peered with logical tunnel
interface ut-2/0/0.2.
interfaces {
so-0/0/0 {
shared-interface;
unit 2 {
dlci 102;
family inet {
address 10.10.12.1/24;
}
}
ut-2/0/0 {
unit 0 {
}
}
}
Ethernet (PSD1) In the following example, logical Gigabit Ethernet interface ge-1/0/0.1 is peered with
logical tunnel interface ut-3/0/0.1, and ge-1/0/0.2 is peered with ut-4/0/0.2.
interfaces {
ge-1/0/0 {
vlan-tagging;
shared-interface;
unit 1{
vlan-id 100;
family inet {
address 10.10.13.1/24;
}
}
unit 2{
vlan-id 101;
family inet {
address 10.10.14.1/24;
}
}
}
ut-3/0/0 {
unit 1{
peer-interface ge-1/0/0.1;
}
unit 2{
}
}
}

Ethernet (PSD2) In the following example, logical Gigabit Ethernet interface ge-1/0/0.3 is peered with
logical tunnel interface ut-4/0/0.3.
interfaces {
ge-1/0/0 {
vlan-tagging;
shared-interface;
unit 3{
vlan-id 102;
family inet {
address 10.10.15.1/24;
}
}
ut-4/0/0 {
unit 3{
}
}
}
10-Gigabit Ethernet In the following example, logical 10-Gigabit Ethernet interface xe-5/0/0.0 is peered with
(PSD4) logical tunnel interface ut-2/0/0.0 and xe-5/0/0.1 is peered with ut-2/0/0.1.
interfaces {
xe-5/0/0 {
vlan-tagging;
shared-interface;
unit 0{
vlan-id 209;
family inet {
address 10.1.1.2/30;
}
family inet6 {
address ::10.1.1.2/126;
}
}
unit 1{
vlan-id 200;
family inet {
address 11.1.1.2/30;
}
family inet6 {
address ::11.1.1.2/126;
}
}
}
ut-2/0/0 {
unit 0{
peer-interface xe-5/0/0.0;
}
unit 1{
peer-interface xe-5/0/0.1;
}

}
}

Documentation
Configuring Firewall Filters on Shared Interfaces

To allow equitable bandwidth sharing between all logical interfaces on a single shared
physical interface, you configure firewall filters on the logical interfaces in the PSD
configuration.
Whereas the RSD controls the physical shared interface and allocates a logical interface
on it to the PSD, the PSD controls the configuration under the logical interface, including
the protocol family. The shared interface on the RSD is not aware of the protocol family
information associated with the logical interface. Therefore, on the PSD, the firewall filter
must be configured under the [edit firewall family any] hierarchy level and the filter applied
to the entire logical interface (as opposed to a protocol family under the interface). With
Junos OS Release 9.4, only output filters are supported.
To configure a firewall filter on the PSD, create the filter conditions and apply the filter
to the logical interfaces:
1. Configure the firewall filter conditions:
a. Include the filter filter-name statement at the [edit firewall family any] hierarchy
level.
b. Include the term term-name statement at the [edit firewall family any filter
filter-name] hierarchy level.
c. Include the from match-conditions statement at the [edit firewall family any filter
filter-name term term-name] hierarchy level.
d. Include the then action statement at the [edit firewall family any filter filter-name
term term-name] hierarchy level.
e. Include the then action-modifiers statement at the [edit firewall family any filter
filter-name term term-name] hierarchy level.
2. Apply the firewall filter to the logical interface on the shared interface by including
the filter output filter-name statement at the [edit interfaces interface-name unit
logical-unit-number] hierarchy level.

Starting with Junos OS Release 10.1, firewall filters on logical interfaces can be configured
on the RSD. Filtering is performed on the PSD, but logical interface filters configured on
the RSD are applied automatically by the PSD.
To configure a logical interface filter on the RSD, apply the firewall filter to the logical
interface on the shared interface by including the filter output filter-name statement at
the [edit interfaces interface-name unit logical-unit-number] hierarchy level on the RSD.
Filters configured on the RSD can co-exist with filters configured on the PSD. Counter
statistics related to PSD filtering are available on the RSD.
In the following example, term 1 and term 2 of the firewall filter-out provide per-class
policing and term 3 provides logical interface-based policing. The filter is applied to the
so-4/5/6.0 logical interface.
firewall family any {

filter filter-out {
term 1 {
from {
forwarding-class voice;
}
then {
policer tx-voice;
next term;
}
}
term 2 {
from {
forwarding-class data;
}
then {
policer tx-data;
next term;
}
}
term 3 {
then policer iflpolicer;
}
}
}
interfaces {
ut-1/2/3 {
unit 0 {
}
}
}
so-4/5/6 {
unit 0 {
filter output filter-out;
family inet {
address 192.168.0.1/24;
}

family inet6 {
address fec0::1/64;
}
}
}
For more information about firewall filters, see the Junos OS Policy Framework
Configuration Guide.

Documentation
• Configuring CoS Features on Shared Interfaces on page 104
Configuring CoS Features on Shared Interfaces

With class-of-service (CoS) features:
• Random early detection (RED) drop profiles and scheduler maps that are bound to
physical shared interfaces must be configured on the RSD.
• Classifiers and rewrite rules that are bound to logical shared interfaces must be
configured on the PSD.
• Tricolor marking policers must be configured on the PSD.
• CoS queues and forwarding classes must be configured identically on both the RSD
and on the PSD that owns the logical shared interfaces.
For example, the following CoS forwarding classes need to be configured on both the
RSD and the PSD:
class-of-service {
forwarding-classes {
queue 0 be priority high;
queue 1 ef priority high;
queue 2 af priority high;
queue 3 nc priority high;
queue 4 fc4 priority high;
}
}
To view queue statistics on a shared interface, you must issue the show interfaces queue
so-fpc/pic/slot command or the show interfaces queue ge-fpc/pic/slot command on the
RSD. If you issue the command on the PSD, the system displays this message: “Egress
queue statistics are not applicable to this interface.”
For more information about CoS features, see the Junos OS Class of Service Configuration
Guide.


Documentation
• Configuring Firewall Filters on Shared Interfaces on page 102


CHAPTER 12
Configuring Inter-PSD Forwarding
• Interface Hierarchy on page 107

• Configuring Inter-PSD Forwarding on page 107
Interface Hierarchy
To configure inter-Protected System Domain (PSD) forwarding, you must be familiar

with the [edit interfaces] hierarchy in the Junos configuration command-line interface
(CLI).
Configuration statements that are unique to inter-PSD forwarding are:
• peer-psd at the [edit interfaces xt-fpc/pic/slot] hierarchy level
For detailed information about all other configuration statements under the [edit
interfaces] hierarchy, see the Junos OS Network Interfaces Configuration Guide.
interfaces {
xt-fpc/pic/slot {
dlci dlci-number;
peer-interfaceinterface-name;
peer-psd psdn;
}
}
}
Related • Inter-PSD Forwarding Overview on page 8

Documentation
• Configuring Inter-PSD Forwarding on a PSD on page 108
Configuring Inter-PSD Forwarding
• Before You Configure Inter-PSD Forwarding on page 108


Before You Configure Inter-PSD Forwarding

Before you configure inter-PSD forwarding, remember that each PSD that uses inter-PSD
forwarding must have a tunnel PIC available to it. To configure the cross-connection
between PSDs, a new interface type, xt, is implemented in Junos OS Release 9.5. All
PSDs configured for inter-PSD forwarding must be running Junos OS Release 9.5 or later.
Currently, only Frame Relay encapsulation is supported for inter-PSD forwarding.

Documentation
Configuring Inter-PSD Forwarding on a PSD

To configure inter-PSD forwarding on a PSD:
1. Use the xt-fpc/pic/slot statement at the [edit interfaces] hierarchy level to configure
cross-connections with the other PSDs.
2. Configure logical interfaces under the cross-connect interface using the unit
logical-unit-number statement at the [edit interfaces xt-fpc/pic/slot] hierarchy level.
The values for logical-unit-number must match values set in the Root System Domain
(RSD) configuration.
3. For each logical interface, include the following statements:
• peer-psd psdn—Configure a peer PSD. The PSD identification is a numeric value

with a range of 1 though 31.
• peer-interface interface-name—Configure the tunnel peer interface that is bound to

the logical interface.
• encapsulation frame-relay—Configure Frame Relay encapsulation. Currently, only

Frame Relay encapsulation is supported for inter-PSD forwarding.
• point-to-point—Configure the interface as a point-to-point interface.
• dlci dlci-number—Configure the data-link connection identifier (DLCI) for the

point-to-point interface.
• family family-name—Configure the protocol family for the interface.
4. Repeat this procedure for each PSD that you want to include in inter-PSD forwarding.
In the example illustrated in Figure 12 on page 109, a cross-connect using a tunnel interface
transports packets between the logical interfaces configured on each PSD.

Chapter 12: Configuring Inter-PSD Forwarding
Figure 12: Example: Inter-PSD Forwarding

PSD 5 PSD 7 PSD 3
xt-4/3/0 xt-3/3/0 xt-2/3/0
xt-3/3/0.1
xt-3/3/0.2
xt-2/3/0.2
xt-2/3/0.1
xt-4/3/0.2
xt-4/3/0.1
g017291
Table 16: Example: Inter-PSD Forwarding
PSD Interfaces
PSD 5 xt-4/3/0.1
10.0.0.2
2121:2121::2/64
xt-4/3/0.2
10.0.1.2
PSD 7 xt-3/3/0.1
10.0.0.1
2121:2121::1/64
xt-3/3/0.2
10.1.1.2
PSD 3 xt-3/3/0.1
10.0.0.1
2121:2121::1/64
xt-2/3/0.2
10.1.1.1
In this example, the [edit interfaces] hierarchy on PSD 5 is configured as follows:
interfaces {
xt-4/3/0 {
unit 1 {
peer-psd psd7;
peer-interface xt-3/3/0.1;
point-to-point;
dlci 1;
family inet {
address 10.0.0.2/32 {
destination 10.0.0.1;
}
}
family inet6 {
address 2121:2121::2/64;
}
}
unit 2 {

peer-psd psd3;
point-to-point;
dlci 2;
family inet {
address 10.0.1.2/32 {
}
}
}
}
}
interfaces {
xt-3/3/0 {
unit 1 {
peer-psd psd5;
point-to-point;
dlci 1;
family inet {
address 10.0.0.1/32 {
}
}
family inet6 {
address 2121:2121::1/64;
}
}
unit 2 {
peer-psd psd3;
point-to-point;
dlci 2;
family inet {
address 10.1.1.1/32 {
}
}
}
}
}
interfaces {
xt-2/3/0 {
unit 1 {
peer-psd psd5;
point-to-point;

Chapter 12: Configuring Inter-PSD Forwarding
dlci 1;
family inet {
address 10.0.1.1/32 {
}
}
}
unit 2 {
peer-psd psd7;
point-to-point;
dlci 2;
family inet {
address 10.1.1.2/32 {
}
}
}
}
}

Documentation
• Interface Hierarchy on page 107
• Before You Configure Inter-PSD Forwarding on page 108


CHAPTER 13
Summary of Junos Configuration

Statements
control-plane-bandwidth-percent
Syntax control-plane-bandwidth-percent percent;
Hierarchy Level [edit chassis system-domains protected-system-domains psdn]
Release Information Statement introduced in Junos OS Release 9.2.
Description Allocate a percentage of the bandwidth that exists on the JCS switch modules and the
T Series Control Boards (T-CBs) to the specified Protected System Domain (PSD).
Allocating bandwidth prevents potential overutilization by one PSD over another.
Options percent—Percentage of bandwidth.

Range: 1 through 100
Required Privilege view-level—To view this statement in the configuration.

Level control-level—To add this statement to the configuration.

Documentation

control-slot-numbers
Syntax control-slot-numbers [ slot-numbers ];
Description Configure the slot numbers for the Routing Engines on the JCS1200 platform that are
part of the specified Protected System Domain (PSD).
Options slot-numbers—Slot numbers for the Routing Engines on the JCS1200 platform to be
assigned to the PSD.
Range: 1 through 12
NOTE: The slot numbers for the Routing Engines for the specified PSD must
match the REP (primary Routing Engine) and REB (backup Routing
Engine) values set through the JCS management module baydata
command. In the absence of any Junos OS CLI configuration that affects
mastership, the Routing Engine in the slot indicated by REP will boot as
the master, and the Routing Engine in slot REB will boot as the backup.
The baydata command assigns the corresponding PSD through the PSD
parameter.


Documentation

Chapter 13: Summary of Junos Configuration Statements
control-system-id
Syntax control-system-id control-system-id;
Description Configure the JCS1200 platform identification.
Options control-system-id—ID value for the JCS1200 platform.

Range: 1 through 4


Documentation
description
Syntax description description;
Description Provide a description for the specified Protected System Domain (PSD).
Options description—Description for the PSD.


Documentation

fpcs
Syntax fpcs [ slot-numbers ];
Description Assign Flexible PIC Concentrators (FPCs) to a Protected System Domain (PSD).
Options slot-numbers—Slot numbers for the FPCs to be assigned to the PSD.

Range: For Junos OS Release 9.4, supported values are 0 through 7.


Documentation
interface-shared-with
Syntax interface-shared-with psdn;
Hierarchy Level [edit interfaces ge-fpc/pic/slot unit logical-unit-number],

[edit interfaces so-fpc/pic/slot unit logical-unit-number],
[edit interfaces xe-fpc/pic/slot unit logical-unit-number]
Description Assign a logical interface under a shared physical interface to a Protected System Domain
(PSD).
Options n—PSD identification as a numeric value.

Range: 1 through 31

Related • Configuring Shared Interfaces on the RSD on page 95.

Documentation
• Configuring Shared Interfaces on a PSD on page 97.
• shared-interface on page 119

peer-interface
Syntax peer-interface logical-interface-name;
Hierarchy Level [edit interfaces xt-fpc/pic/slot unit logical-unit-number]
Description Configure a peer interface on a Protected System Domain (PSD) for PSD-to-PSD
communication over internal tunnel PICs.
Options logical-interface-name—Logical interface used for peer-to-peer communication between

PSDs.

Related • Configuring Inter-PSD Forwarding on a PSD on page 108.

Documentation
• peer-psd on page 117
peer-psd
Syntax peer-psd psdn;
Hierarchy Level [edit interfaces xt-fpc/pic/slot unit logical-unit-number]
Description Configure a peer Protected System Domain (PSD) for inter-PSD forwarding.
Options n—PSD identification as a numeric value.

Range: 1 through 31

Related • Configuring Inter-PSD Forwarding on a PSD on page 108.

Documentation
• peer-interface on page 117

protected-system-domains
Syntax protected-system-domains psdn {

}
Hierarchy Level [edit chassis system-domains]
Description Configure the Protected System Domain (PSD) identification.
Options psdn—PSD identification as a numeric value.

Range: 1 through 31
The remaining statements are described separately.


Documentation

root-domain-id
Syntax root-domain-id root-domain-id;
Hierarchy Level [edit chassis system-domains]
Description Configure the Root System Domain (RSD) ID.
Options root-domain-id—RSD domain ID.

Range: 1 through 3
NOTE: This value must match the value of the SD (Root System Domain)
parameter set using the baydata command.


Documentation
shared-interface
Syntax shared-interface;
Hierarchy Level [edit interfaces ge-fpc/pic/slot],

[edit interfaces so-fpc/pic/slot],
[edit interfaces xe-fpc/pic/slot]
Description Configure a physical interface to be a shared interface. Logical interfaces configured

under the shared physical interface can be assigned to different Protected System
Domains (PSDs).
Options This statement has no options.

Related • Configuring Shared Interfaces on the RSD on page 95.

Documentation
• Configuring Shared Interfaces on a PSD on page 97.
• interface-shared-with on page 116

system-domains
Syntax system-domains {
protected-system-domains psdn {
}
root-domain-id root-domain-id;
}
Hierarchy Level [edit chassis]
Description Configure Root System Domain (RSD) and Protected System Domain (PSD) parameters.
Options All statements are described separately.


Documentation

PART 5
Configuration Examples
• Configuration Examples on page 123


CHAPTER 14
Configuration Examples
• Example: Configuring a JCS1200 Platform and a Single T Series Router on page 123
• Example: Configuring Route Reflection—Roadmap on page 157
• Example: Consolidating a Layer 2 VPN Network on page 177
Example: Configuring a JCS1200 Platform and a Single T Series Router
In this configuration example, the JCS1200 platform is connected to a single T640 router.
The configuration is described in the following sections:
• Requirements on page 123

• Overview on page 124
• Configuration on page 124
• Verification on page 126
Requirements
This configuration example requires the following hardware and software components:
• Junos OS Release 9.1 or later
• JCS1200 platform with Routing Engines in slots 1, 2, 3, and 4
• T640 router with FPCs in slots 0, 1, 2, and 3

Overview
This example configures the JCS1200 platform and one connected T640 router. For this
example, you need to configure a single Root System Domain (RSD), create Protected
System Domains (PSDs), and assign Routing Engines in the JCS chassis and Flexible PIC
Controllers (FPCs) on the T640 router to each PSD as follows:
• PSD1—Routing Engines in slots 1 and 2 on the JCS chassis and FPCs in slots 0, 1, and 2
on the T640 router
• PSD2—Routing Engines in slots 3 and 4 on the JCS chassis and the FPC in slot 3 on the
T640 router
Configuration
First, configure the Routing Engines on the JCS1200 platform using the management
module command-line interface (CLI). Then, configure the T640 router using the Junos
OS CLI.
• JCS1200 Platform Configuration on page 124

• T640 Router Configuration on page 125
JCS1200 Platform Configuration
Step-by-Step To configure the parameters required for the Routing Engines in the JCS chassis:
Procedure
2. Assign the Routing Engines in slots 1 (primary) and 2 (backup) to RSD1 and PSD1:
system> baydata —b 01 —data “V01–JCS01–SD01–PSD01–REP01–REB02–PRDT640”
3. Assign Routing Engines in slots 3 (primary) and 4 (backup) to RSD1 and PSD2:
The baydata command specifies the target as a bay blade (-b), identifies the blade
(Routing Engine) slot, and specifies the following parameters:
• V—Product version.
• JCS—JCS platform identifier.
• SD—RSD identifier.
• PSD—PSD identifier.
• REP—Slot in which the primary (or master) Routing Engine resides.
• REB—Slot in which the backup Routing Engine resides.
• PRD—Juniper Networks router product.

Chapter 14: Configuration Examples
Results Display the results of the configuration:
system> baydata

2 Supported V01-JCS01-SD01-PSD01-REP01-REB02-PRDT640
5 No blade present
6 No blade present
7 No blade present
8 No blade present
9 No blade present
10 No blade present
11 No blade present
12 No blade present
T640 Router Configuration
Step-by-Step To configure the RSD and create the PSDs on the T640 router:
Procedure
1. At the [edit chassis system-domains] hierarchy level of the Junos OS CLI, include
the root-domain-id 1 statement to identify the RSD.

protected-system-domains psd1 statement to create PSD1.
3. At the [edit chassis system-domains protected-system-domains psd1] hierarchy

level:
a. Include the fpcs 0 fpcs 1 fpcs 2 statement to assign the FPCs in slots 0, 1, and 2
to PSD1.
b. Include the control-system-id 1 statement to identify the JCS1200 platform.
c. Include the control-slot-numbers 1 control-slot-numbers 2 statement to assign

the Routing Engines in slots 1 and 2 in the JCS chassis to PSD1.


level:
a. Include the fpcs 3 statement to assign the FPC in slot 3 to PSD2.


system-domains {
root-domain-id 1;
protected-system-domains {
psd1 {
description “psd for customer1”;
fpcs [ 0 1 2 ];
control-system-id 1;
control-slot-numbers [ 1 2 ];
}
psd2 {
fpcs [ 3 ];
}
}
}
Verification
Verify the status of the RSD and PSDs:
• Verifying Configured PSDs on page 126

• Verifying PSD Hardware on page 126
Verifying Configured PSDs
Purpose Verify that the PSDs configured under the RSD are online.
Action On the RSD, issue the show psd command:
user@rsd1> show chassis psd
PSD Description State Uptime

1 psd for customer1 Online 1 hour, 12 minutes, 15 seconds
Meaning PSD1 and PSD2 are configured and online.
Verifying PSD Hardware
Purpose Verify that each PSD has been assigned the correct FPCs on the T640 router and the
appropriate Routing Engines on the JCS1200 platform.
Action Issue the show chassis hardware command:
PSD1 user@psd1> show chassis hardware

rsd-re0:
--------------------------------------------------------------------------
Hardware inventory:
Item Version Part number Serial number Description
Chassis S19068 T1600
Midplane REV 04 710-002726 AX5666 T640 Backplane

CIP REV 05 710-002895 HC0474 T Series CIP

PEM 0 Rev 06 740-017906 TE27806 Power Entry Module 3x80
SCG 0 REV 04 710-003423 HF6042 T640 Sonet Clock Gen.
SCG 1 REV 11 710-003423 HW7765 T640 Sonet Clock Gen.
Routing Engine 0 REV 04 740-014082 1000660098 RE-A-2000
Routing Engine 1 REV 01 740-005022 210865700324 RE-3.0
CB 0 REV 06 710-007655 WE9377 Control Board (CB-T)
FPC 0 REV 07 710-013035 DN5856 FPC Type 3-ES
CPU REV 07 710-016744 DM3593 ST-PMB2
PIC 0 REV 05 750-007141 HG2427 10x 1GE(LAN), 1000 BASE
Xcvr 1 REV 01 740-011613 P9F15ZN SFP-SX

Xcvr 2 REV 01 740-011613 P9F11CC SFP-SX
Xcvr 3 REV 01 740-011613 P9F1AM1 SFP-SX
Xcvr 4 REV 01 740-011613 P9F11X1 SFP-SX
Xcvr 5 REV 01 740-011613 P9F1715 SFP-SX
PIC 1 REV 01 750-004695 HD5978 1x Tunnel
PIC 2 REV 05 750-004695 HT4383 1x Tunnel
MMB 0 REV 04 710-016036 DN6989 ST-MMB2
FPC 1 REV 05 710-010157 HR5838 E-FPC Type 2
CPU REV 01 710-010169 HN3431 FPC CPU-Enhanced
PIC 0 REV 07 750-001900 AT1697 1x OC-48 SONET, SMSR
PIC 1 REV 08 750-009066 NA0423 1x OC-48 SONET SFP
Xcvr 0 REV 01 740-011785 PAQ0Z8C SFP-SR
PIC 2 REV 11 750-003737 NA2450 4x G/E, 1000 BASE-SX
PIC 3 REV 05 750-001850 WD3132 1x Tunnel
MMB 1 REV 01 710-010171 HN6495 MMB-288mbit
FPC 2 REV 04 710-013558 JP3361 E2-FPC Type 2
CPU REV 02 710-013563 JN4128 FPC CPU-Enhanced
PIC 0 REV 07 750-010618 CZ6647 4x G/E SFP, 1000 BASE
Xcvr 0 REV 01 740-011613 P8E2SSM SFP-SX
Xcvr 1 REV 01 740-011782 P8C29XQ SFP-SX
Xcvr 2 REV 01 740-011782 P86218N SFP-SX
Xcvr 3 REV 01 740-011782 PB82CR5 SFP-SX
PIC 2 REV 16 750-008155 NB8516 2x G/E IQ, 1000 BASE
Xcvr 0 REV 01 740-007326 P11WLS9 SFP-SX
Xcvr 1 REV 01 740-011613 PAM2Y9G SFP-SX
PIC 3 REV 16 750-008155 ND7764 2x G/E IQ, 1000 BASE
Xcvr 0 REV 01 740-011782 PBA29H8 SFP-SX
MMB 1 REV 05 710-010171 JP5579 MMB-5M3-288mbit
SPMB 0 REV 10 710-003229 WE9582 T Series Switch CPU
SIB 0 REV 05 710-013074 DB2624 SIB-I8-SF
SIB 1 REV 05 710-013074 DE7881 SIB-I8-SF
SIB 2 REV 05 710-013074 DE7889 SIB-I8-SF
SIB 3 REV 05 710-013074 DE9972 SIB-I8-SF
SIB 4 REV 05 710-013074 DE7937 SIB-I8-SF
Fan Tray 0 Front Top Fan Tray
Fan Tray 1 Front Bottom Fan Tray
Fan Tray 2 Rear Fan Tray
psd1-re0:
--------------------------------------------------------------------------
Hardware inventory:
Chassis 740-023156 SNJCSJCSAC00 JCS1200 AC Chassis
Routing Engine 1 REV 01 740-023157 SNBLJCSAC005 RE-JCS1200-1x2330
PSD2 user@psd2> show chassis hardware

rsd-re0:
--------------------------------------------------------------------------
Hardware inventory:
Chassis S19068 T1600
PEM 0 Rev 06 740-017906 TE27806 Power Entry Module 3x80
FPC 3 REV 01 710-013560 JE4851 E2-FPC Type 3
CPU REV 05 710-010169 HX8637 FPC CPU-Enhanced
MMB 0 REV 04 710-010171 HX7130 MMB-5M3-288mbit
SIB 0 REV 05 710-013074 DB2624 SIB-I8-SF
SIB 1 REV 05 710-013074 DE7881 SIB-I8-SF
SIB 2 REV 05 710-013074 DE7889 SIB-I8-SF
SIB 3 REV 05 710-013074 DE9972 SIB-I8-SF
SIB 4 REV 05 710-013074 DE7937 SIB-I8-SF
psd2-re0:
--------------------------------------------------------------------------
Hardware inventory:
Meaning On PSD1, under the rsd-re0 heading, you can see that PSD1 owns the FPCs in slots 0, 1,
and 2 in the T640 chassis. Under the psd1-re0 output field, the output indicates that the
Routing Engines in slots 1 and 2 in the JCS chassis are assigned to PSD1.
On PSD2, under the rsd-re0 heading, you can see that PSD2 owns the FPC in slot 3 in the
T640 chassis. Under the psd2-re0 output field, the output indicates that the Routing
Engines in slots 3 and 4 in the JCS chassis are assigned to PSD2.

Documentation
Example: Configuring a JCS1200 Platform and Multiple T Series Routers
In this configuration example, the JCS1200 platform is connected to multiple T Series

routers. The configuration is described in the following sections:



Requirements
• JCS1200 platform with Routing Engines in slots 1 through 12
• T320 router with FPCs in slots 0 through 7
Overview
This example configures the JCS1200 platform and three connected T Series routers.
For this example, you need to configure a Root System Domain (RSD) for each connected
T Series router. Within each RSD, create Protected System Domains (PSDs) and assign
Flexible PIC Controllers (FPCs) and Routing Engines to each PSD.
Configuration
module CLI. Then, configure each T Series router using the Junos OS CLI.

Procedure
2. Refer to the data presented in Table 17 on page 129 for Routing Engine assignments.
Table 17: JCS Chassis Routing Engine Assignments

Primary Backup Routing
RSD ID PSD ID Routing Engine Engine Routing Platform
1 1 01 02 T320
2 03 04
2 3 05 06 T640
4 07 08

Table 17: JCS Chassis Routing Engine Assignments (continued)

Primary Backup Routing
RSD ID PSD ID Routing Engine Engine Routing Platform
3 5 09 10 T1600
6 11 12
3. Assign the Routing Engines in slots 1 (primary) and 2 (backup) to RSD1 and PSD1,
which are associated with the T320 router. Assign the Routing Engines in slots 3
(primary) and 4 (backup) to RSD1 and PSD2, which also belong to the T320 router.
(primary) and 8 (backup) to RSD2 and PSD4, which also belong to the T640 router.
(primary) and 12 (backup) to RSD3 and PSD6, which also belong to the T1600
router.
system> baydata


Procedure
1. Log in to the T320 router.
2. Configure RSD1 and the parameters specified in Table 18 on page 131.
Table 18: T320 Router Configuration

PSD FPCs Redundant Routing Engine Slots
1 0, 1, 2, and 3 1 and 2
2 4, 5, 6, and 7 3 and 4


level:
a. Include the fpcs 0 fpcs 1 fpcs 2 fpcs 3 statement to assign the FPCs in slots 0, 1,
2, and 3 to PSD1.



level:
6, and 7 to PSD2.


system-domains {
root-domain-id 1;
psd1 {
fpcs [ 0 1 2 3];
}
psd2 {
fpcs [ 4 5 6 7];
}
}
}
Procedure

3 0, 1, 2, and 3 5 and 6
4 4, 5, 6, and 7 7 and 8


level:
2, and 3 to PSD3.




level:
6, and 7 to PSD4.

Results Display the configuration results:
system-domains {
root-domain-id 2;
psd3 {
fpcs [ 0 1 2 3];
}
psd4 {
fpcs [ 4 5 6 7];
}
}
}
Procedure

5 0, 1, 2, and 3 9 and 10
6 4, 5, 6, and 7 11 and 12



level:
2, and 3 to PSD3.



level:
6, and 7 to PSD4.

Results Display the configuration results:
system-domains {
root-domain-id 3;
psd5 {
fpcs [ 0 1 2 3];
}
psd6 {
fpcs [ 4 5 6 7];
}
}
}
Verification
• Verifying PSD Ownership of FPCs on page 135
• Verifying PSD Ownership of Routing Engines on page 135
Purpose Verify that the PSDs configured under each RSD are online.

Action On each RSD issue the show chassis psd command:
RSD1 user@rsd1> show chassis psd



Meaning RSD1 owns PSD1 and PSD2. RSD2 owns PSD3 and PSD4. RSD3 owns PSD4 and PSD5.
All PSDs are online.
Verifying PSD Ownership of FPCs
Purpose Verify that each PSD is assigned the correct FPCs on the T Series router.
Action For each PSD, issue the show chassis fpc command. For example:
user@psd1> show chassis fpc
rsd-re0:
--------------------------------------------------------------------------
Temp CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt DRAM (MB) Heap Buffer
0 Online 34 3 1 256 12 50
1 Online 52 4 0 2048 3 24
2 Online 34 3 1 256 12 50
3 Online 52 4 0 2048 3 24
Meaning In this example, PSD1 owns the FPCs in slots 0, 1, 2, and 3 on the T Series router.
Verifying PSD Ownership of Routing Engines
Purpose Verify that each PSD owns the correct Routing Engines on the JCS chassis.
Action On each PSD, issue the show chassis routing-engine command. For example:
user@psd2> show chassis routing-engine
Routing Engine status:

Slot 0:
Physical Slot 3
Current state Master
Election priority Master (default)
DRAM 13312 MB
Memory utilization 11 percent

CPU utilization:
User 0 percent
Background 0 percent
Kernel 0 percent
Interrupt 0 percent
Idle 100 percent
Model RE-JCS1200-1x2330
Serial ID SNBLBCD001
Start time 2008-09-03 13:49:00 PDT
Uptime 27 days, 2 hours, 50 minutes, 9 seconds
Last reboot reason 0x49:power cycle/failure power-button hard
power off thermal shutdown
Slot 1:
Physical Slot 4
Current state Backup
Election priority Backup (default)
DRAM 13312 MB
CPU utilization:
User 0 percent
Kernel 0 percent
Interrupt 0 percent
Idle 100 percent
Serial ID SNBLBCD002
Start time 2008-09-24 17:04:01 PDT
Last reboot reason 0x49:power cycle/failure power-button hard
power off thermal shutdown
Load averages: 1 minute 5 minute 15 minute
0.00 0.00 0.00
Meaning In this example, PSD2 owns the Routing Engines in slots 3 and 4 on the JCS chassis as
indicated by the values in the Physical Slot fields. The Routing Engine in slot 3 is the
master, whereas the Routing Engine in slot 4 is the backup.

Documentation
Example: Configuring Shared Interfaces (SONET)
In this configuration example, two Protected System Domains (PSDs) share a single
interface on a Flexible PIC Controller (FPC) that is owned by the Root System Domain
(RSD).


Requirements
• JCS1200 platform with Routing Engines in slots 5, 6, and 7
• Two Tunnel PICs—one installed on the FPC in slot 1 and the other installed on the FPC
in slot 7
• One SONET PIC installed on the FPC in slot 6
Overview
With this example configuration, PSD5 and PSD6 can both transport packets using a
single SONET PIC owned by RSD3.
As illustrated in Figure 13 on page 137, RSD3 owns physical interface (so-6/0/0). PSD5
owns logical interfaces so-6/0/0.0, so-6/0/0.1, and so-6/0/0.2. A cross-connect using
tunnel interface ut-1/0/0 transports packets between the logical interfaces configured
on the PSD and the physical SONET interface on RSD3. Similarly, PSD5 owns logical
interface so-6/0/0.3 and uses ut-7/0/0 to transport packets between so-6/0/0.3 and
the physical interface on RSD3.
Figure 13: Example: Shared Interfaces (SONET)

PSD5 PSD6 RSD3
ut-1/0/0 ut-7/0/0 so-6/0/0
tunnel to so-6/0/0.3
g016951
Configuration
module command-line interface (CLI). Then, configure each T Series router using the
Junos OS CLI.
• JCS1200 Configuration on page 138

• RSD Configuration on page 138
• PSD5 Configuration on page 140

JCS1200 Configuration
Procedure
2. Assign the Routing Engines in slots 5 (primary) and 6 (backup) to RSD3 and PSD1.
Assign the Routing Engine in slot 7 to RSD3 and PSD2.
system> baydata

1 No blade present
2 No blade present
3 No blade present
4 No blade present
8 No blade present
9 No blade present
10 No blade present
11 No blade present
12 No blade present
RSD Configuration
Step-by-Step To configure the RSD:

Procedure


level:
to PSD1.


d. Include the control-plane-bandwidth-percent 50 statement to allocate 50 percent

of the bandwidth on the JCS switch modules and T Series Control Boards (T-CBs)
to PSD1.


level:
6, and 7 to PSD2.


of the bandwidth on the JCS switch modules and T-CBs to PSD2.
7. At the [edit interfaces] hierarchy level, include the so-6/0/0 statement to configure
the physical SONET interface.
8. At the [edit interfaces so-6/0/0] hierarchy level, include the encapsulation

frame-relay statement to configure Frame Relay encapsulation on the physical
interface, and include the unit 0, unit 1, unit 2, and unit 3 statements to configure the
logical interfaces.
9. At the [edit interfaces so-6/0/0 unit n] hierarchy level, include the following
statements:
• interface-shared-with psdn—Assign the logical interface to a PSD:
• For unit 0, the value is 5 (PSD5).
• dlci dlci-identifier—Configure the data-link connection identifier (DLCI) for the

point-to-point Frame Relay connection:
• For unit 0, the value is 16.

system-domains {
root-domain-id 3;
psd5 {
description customerA;
fpcs [ 1 2 3 ];
control-plane-bandwidth-percent 50;
}
psd6 {
description customerB;
fpcs [ 4 5 7 ];
control-slot-numbers 7;
}
}
}
}
interfaces
so-6/0/0 {
no-keepalives;
unit 0 {
dlci 16;
}
unit 1 {
dlci 17;
}
unit 2 {
dlci 18;
}
unit 3 {
dlci 100;
}
}
PSD5 Configuration
Step-by-Step To configure PSD5:

Procedure
1. At the [edit interfaces] hierarchy level, include the ut-1/0/0 statement to configure
the physical tunnel interface.
2. At the [edit interfaces ut-1/0/0] hierarchy level, include the unit 0, unit 1, and unit 2
statements to configure the logical tunnel interfaces.

3. At the [edit interfaces ut-1/0/0 unit n] hierarchy level, include the peer-interface
so-6/0/0.logical-unit-number statement to bind the tunnel and SONET interfaces
together. Use the following logical-unit-number values:

frame-relay statement to match the configuration on the RSD, and the
shared-interface statement to identify the physical interface as the shared interface.
5. At the [edit interfaces so-6/0/0] hierarchy level, include unit 0, unit 1, and unit 2
statements to configure logical interfaces.
6. At the [edit interfaces so-6/0/0 unit n] hierarchy level, include the following
statements:
• peer-interface peer-interface—Bind the SONET and tunnel interface interfaces

together. Use the following peer-interface values:
• For unit 0, the value is ut-1/0/0.0.
• dlci dlci—Configure the DLCI for the point-to-point Frame Relay connection. Use
the following dlci values:
• family inet address address—Configure the IP version 4 (IPv4) suite protocol family
on the logical SONET interface. Use the following address values:
• For unit 0, the value is 10.70.0.1/30.
interfaces {
ut-1/0/0 {
unit 0 {
}
unit 1 {

}
unit 2 {
}
}
so-6/0/0 {
shared-interface;
unit 0 {
dlci 16;
family inet {
address 10.70.0.1/30;
}
}
unit 1 {
dlci 17;
family inet {
address 17.17.17.1/30;
}
}
unit 2 {
dlci 18;
family inet {
address 18.18.18.1/30;
}
}
}
PSD6 Configuration

Procedure
2. At the [edit interfaces ut-7/0/0] hierarchy level, include the unit 0 statement to
configure the logical tunnel interface.
3. At the [edit interfaces ut-1/0/0 unit 0] hierarchy level, include the peer-interface
so-6/0/0.logical-unit-number statement to bind the tunnel and the SONET interfaces
together.

frame-relay statement to match the configuration on the RSD, and the
shared-interface statement to identify the SONET interface as the shared physical
interface.
5. At the [edit interfaces so-6/0/0] hierarchy level, include the unit 3 statement to
configure the logical interface.
6. At the [edit interfaces so-6/0/0 unit 3] hierarchy level, include the following
statements:

• peer-interface ut-7/0/0.0—Bind the SONET and tunnel interfaces together.
• dlci 100—Configure the DLCI for the point-to-point Frame Relay connection.
• family inet address 10.10.10.1/24—Configure the IP version 4 (IPv4) suite protocol

family.
interfaces {
ut-7/0/0 {
unit 0 {
}
}
so-6/0/0 {
shared-interface;
unit 3 {
dlci 100;
family inet {
address 10.10.10.1/24;
}
}
}
Verification
• Verifying Shared Interfaces on RSD3 on page 143
• Verifying Shared Interfaces on PSD5 on page 145
Verifying Shared Interfaces on RSD3
Purpose From RSD3, display the status of shared interfaces.
Action Issue the show interfaces so-6/0/0 command:
user@rsd3> show interfaces so-6/0/0

Physical interface: so-6/0/0, Enabled, Physical link is Up
Interface index: 128, SNMP ifIndex: 109
Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal, SONET mode,
Speed: OC192, Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running Down
Interface flags: Hardware-Down Point-To-Point SNMP-Traps Internal: 0x4000
Shared-interface : Owner
Link flags : No-Keepalives DTE
ANSI LMI settings: n391dte 6, n392dte 3, n393dte 4, t391dte 10 seconds
LMI: Input: 0 (never), Output: 0 (never)
DTE statistics:
Enquiries sent : 0
Full enquiries sent : 0
Enquiry responses received : 0
Full enquiry responses received : 0
DCE statistics:

Enquiries received : 0
Full enquiries received : 0
Enquiry responses sent : 0
Full enquiry responses sent : 0
Common statistics:
Unknown messages received : 0
Asynchronous updates received : 0
Out-of-sequence packets received : 0
Keepalive responses timedout : 0
CoS queues : 8 supported, 8 maximum usable queues
Last flapped : 2008-08-11 10:51:51 PDT (1w1d 04:47 ago)
Input rate : 0 bps (0 pps)
Output rate : 0 bps (0 pps)
SONET alarms : LOL, PLL
SONET defects : LOL, PLL, LOF, SEF, AIS-L, AIS-P
Logical interface so-6/0/0.0 (Index 67) (SNMP ifIndex 117)

Flags: Device-Down Point-To-Point SNMP-Traps 0x4000 Encapsulation: FR-NLPID
Shared interface:
Shared with: psd5
Tunnel token: Rx: 2.517, Tx: 1.517
Input packets : 0
Output packets: 0
DLCI 16
Flags: Active
Total down time: 00:01:09 sec, Last down: 264:48:29 ago
Input packets : 0
Output packets: 0
DLCI statistics:
Active DLCI :1 Inactive DLCI :0

Shared interface:
Shared with: psd5
Input packets : 0
Output packets: 0
DLCI 17
Flags: Active
Input packets : 0
Output packets: 0
DLCI statistics:

Shared interface:
Shared with: psd5
Input packets : 0
Output packets: 0
DLCI 18
Flags: Active
Input packets : 0
Output packets: 0
DLCI statistics:


Shared interface:
Shared with: psd5
Input packets : 0
Output packets: 0
DLCI 100
Flags: Active
Input packets : 0
Output packets: 0
DLCI statistics:
Meaning Under the Physical interface section of the output, the Shared-interface field displays the
value Owner, meaning that RSD owns the physical shared interface so-6/0/0. In the
Shared interface fields for each logical interface, you see that so-6/0/0.0, so-6/0/0.1,
and so-6/0/0.2 are shared with PSD5, whereas logical interface so-6/0/0.3 is shared
with PSD6.
Verifying Shared Interfaces on PSD5
Purpose From PSD5, display the status of shared interfaces.
user@psd5> show interfaces so-6/0/0

Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal, Speed: OC192,
Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps Internal: 0x4000
Shared-interface : Non-Owner
Last flapped : Never

Flags: Point-To-Point SNMP-Traps 0x4000 Encapsulation: FR-NLPID
Shared interface:
Peer interface: ut-1/0/0.0
Input packets : 9
Output packets: 10
Protocol inet, MTU: 4470
Addresses, Flags: Is-Preferred Is-Primary
Destination: 16.16.0.0/30, Local: 16.16.0.1, Broadcast: 16.16.0.3
DLCI 16
Flags: Active
Input packets : 9
Output packets: 10
DLCI statistics:


Shared interface:
Input packets : 9
Output packets: 10
DLCI 17
Flags: Active
Input packets : 9
Output packets: 10
DLCI statistics:

Shared interface:
Input packets : 9
Output packets: 10
DLCI 18
Flags: Active
Input packets : 9
Output packets: 10
DLCI statistics:
Meaning Under the Physical interfaces section of the output, the Shared-interface field displays a
value of Non-owner, indicating that the shared physical interface so-6/0/0 is not owned
by PSD5. The Shared interface field for each logical interface provides the name of its
peer uplink tunnel (ut-) interface. For example, for so-6/0/0.0, the peer interface is
ut-1/0/0.0.




Shared interface:
Input packets : 9
Output packets: 10
DLCI 100
Flags: Active
Input packets : 9
Output packets: 10
DLCI statistics:
value of Non-owner, indicating that the shared physical interface so-6/0/0 is not owned
by PSD6. The Shared interface field for so-6/0/0.3 indicates that its peer interface is
ut-7/0/0.3.
Related • Configuring Shared Interfaces on the RSD on page 95

Documentation
Example: Configuring Shared Interfaces (Ethernet)
In this configuration example, two Protected System Domains (PSDs) share a single
interface on a Flexible PIC Controller (FPC) that is owned by the Root System Domain
(RSD).

Requirements
• JCS1200 platform with Routing Engines in slots 5, 6, and 7

• Two Tunnel PICs—one installed on the FPC in slot 1 and the other installed on the FPC
in slot 7
• One Gigabit Ethernet PIC installed on the FPC in slot 6
Overview
With this example configuration, PSD5 and PSD6 can both transport packets using a
single Gigabit Ethernet PIC owned by RSD3.
As illustrated in Figure 14 on page 148, RSD3 owns physical interface (ge-6/0/0). PSD5
owns logical interfaces ge-6/0/0.0, ge-6/0/0.1, and ge-6/0/0.2. A cross-connect using
tunnel interface ut-1/0/0 transports packets between the logical interfaces configured
on the PSD and the physical Gigabit Ethernet interface on RSD3. Similarly, PSD6 owns
logical interface ge-6/0/0.3 and uses ut-7/0/0 to transport packets between ge-6/0/0.3
and the physical interface on RSD3.
Figure 14: Example: Shared Interfaces (Gigabit Ethernet)

PSD5 PSD6 RSD3
ut-1/0/0 ut-7/0/0 ge-6/0/0
tunnel to ge-6/0/0.3
g016986
Configuration
module command-line interface (CLI). Then, configure each T Series router using the
Junos OS CLI.

Procedure
2. Assign the Routing Engines in slots 5 (primary) and 6 (backup) to RSD3 and PSD1.
Assign the Routing Engine in slot 7 to RSD3 and PSD2.

system> baydata

1 No blade present
2 No blade present
3 No blade present
4 No blade present
8 No blade present
9 No blade present
10 No blade present
11 No blade present
12 No blade present
RSD Configuration

Procedure


level:
to PSD1.


of the bandwidth on the JCS switch modules and T Series Control Boards (T-CBs)
to PSD1.


level:
6, and 7 to PSD2.



of the bandwidth on the JCS switch modules and T-CBs to PSD2.
7. At the [edit interfaces] hierarchy level, include the ge-6/0/0 statement to configure
the physical Gigabit Ethernet interface.
8. At the [edit interfaces ge-6/0/0] hierarchy level:
• Include the vlan-tagging statement to enable the receiving and forwarding of

routed or bridged Ethernet frames with 802.1Q VLAN tags.
• Include the unit 0, unit 1, unit 2, and unit 3 statements to configure the logical
interfaces.
9. At the [edit interfaces ge-6/0/0 unit n] hierarchy level, include the following
statements:
• interface-shared-with psdn—Assign the logical interface to a PSD:
• vlan vlan-id—Configure the virtual LAN (VLAN) identifier to bind the 802.1Q VLAN
tag ID to the logical interface:
system-domains {
root-domain-id 3;
psd5 {
description customerA;
fpcs [ 1 2 3 ];
}
psd6 {
description customerB;
fpcs [ 4 5 7 ];

}
}
}
}
interfaces {
ge-6/0/0 {
vlan-tagging;
unit 0 {
vlan-id 16;
}
unit 1 {
vlan-id 17;
}
unit 2 {
vlan-id 18;
}
unit 3 {
vlan-id 100;
}
}
PSD5 Configuration

Procedure
2. At the [edit interfaces ut-1/0/0] hierarchy level, include the unit 0, unit 1, and unit 2
statements to configure the logical tunnel interfaces.
3. At the [edit interfaces ut-1/0/0 unit n] hierarchy level, include the peer-interface
ge-6/0/0.logical-unit-number statement to bind the tunnel and Gigabit Ethernet
interfaces together. Use the following logical-unit-number values:
4. At the [edit interfaces ge-6/0/0] hierarchy level, include the vlan-tagging statement
to match the configuration on the RSD, and the shared-interface statement to
identify the physical interface as the shared interface.
5. At the [edit interfaces ge-6/0/0] hierarchy level, include unit 0, unit 1, and unit 2
statements to configure logical interfaces.
6. At the [edit interfaces ge-6/0/0 unit n] hierarchy level, include the following
statements:

• peer-interface peer-interface—Bind the Gigabit Ethernet and tunnel interface

interfaces together. Use the following peer-interface values:
• vlan vlan-id—Bind the 802.1Q VLAN tag ID to the logical interface. Use the following
vlan-id values:
• family inet address address—Configure the IP version 4 (IPv4) suite protocol family
on the logical Gigabit Ethernet interface. Use the following address values:
interfaces {
ut-1/0/0 {
unit 0 {
}
unit 1 {
}
unit 2 {
}
}
ge-6/0/0 {
vlan-tagging;
shared-interface;
unit 0 {
vlan-id 16;
family inet {
address 10.70.0.1/30;
}
}
unit 1 {
vlan-id 17;
family inet {
address 17.17.17.1/30;

}
}
unit 2 {
vlan-id 18;
family inet {
address 18.18.18.1/30;
}
}
}
PSD6 Configuration

Procedure
2. At the [edit interfaces ut-7/0/0] hierarchy level, include the unit 0 statement to
configure the logical tunnel interface.
3. At the [edit interfaces ut-1/0/0 unit 0] hierarchy level, include the peer-interface
ge-6/0/0.logical-unit-number statement to bind the tunnel and the Gigabit Ethernet
interfaces together.
4. At the [edit interfaces ge-6/0/0] hierarchy level, include the vlan-tagging statement
to match the configuration on the RSD, and the shared-interface statement to
identify the Gigabit Ethernet interface as the shared physical interface.
5. At the [edit interfaces ge-6/0/0] hierarchy level, include the unit 3 statement to
6. At the [edit interfaces ge-6/0/0 unit 3] hierarchy level, include the following
statements:
• peer-interface ut-7/0/0.0—Bind the Gigabit Ethernet and tunnel interfaces

together.
• vlan-id 100—Bind the 802.1Q VLAN tag ID to the logical interface.
• family inet address 10.10.10.1/24—Configure the IP version 4 (IPv4) suite protocol

family.
interfaces {
ut-7/0/0 {
unit 0 {
}
}
ge-6/0/0 {
vlan-tagging;
unit 3 {
vlan-id 100;

family inet {
address 10.10.10.1/24;
}
}
}
Verification
• Verifying Shared Interfaces on RSD3 on page 154
Verifying Shared Interfaces on RSD3
Purpose From RSD3, display the status of shared interfaces.
Action Issue the show interfaces ge-6/0/0 command:
user@rsd3> show interfaces ge-6/0/0

Physical interface: ge-0/6/0, Enabled, Physical link is Up
Link-level type: Ethernet, MTU: 1518, Speed: 10Gbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
Flow control: Enabled
Interface flags: SNMP-Traps Internal: 0x4000
Current address: 00:17:cb:25:48:7e, Hardware address: 00:17:cb:25:48:7e
Last flapped : 2008-12-08 12:19:25 PST (01:17:11 ago)
Active alarms : None
Active defects : None
Logical interface ge-0/6/0.0 (Index 69) (SNMP ifIndex 236)

Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.10 ] Encapsulation: ENET2
Shared-interface:
Shared with: psd5
Input packets : 0
Output packets: 0
Protocol multiservice, MTU: Unlimited
Flags: None

Shared-interface:
Shared with: psd5
Input packets : 0
Output packets: 0
Flags: None

Shared-interface:
Shared with: psd6


Input packets : 0
Output packets: 0
Flags: None
Meaning Under the Physical interface section of the output, the Shared-interface field displays the
value Owner, meaning that RSD owns the physical shared interface ge-6/0/0. In the
Shared interface fields for each logical interface, you see that ge-6/0/0.0, ge-6/0/0.1,
and ge-6/0/0.2 are shared with PSD5, whereas logical interface ge-6/0/0.3 is shared
with PSD6.
user@psd5> show interfaces ge-6/0/0


Shared-interface:
Input packets : 0
Output packets: 0
Flags: None

Shared-interface:
Peer interface: ut-1/0/0.1 Tunnel token: Rx: 2.530, Tx: 1.520
Input packets : 0
Output packets: 0
Flags: None


Shared-interface:
Peer interface: ut-1/0/0.2 Tunnel token: Rx: 2.530, Tx: 1.520
Input packets : 0
Output packets: 0
Flags: None
value of Non-owner, indicating that the shared physical interface ge-6/0/0 is not owned
by PSD5. The Shared interface field for each logical interface provides the name of its
peer uplink tunnel (ut-) interface. For example, for ge-6/0/0.0, the peer interface is
ut-1/0/0.0.

Physical interface: ge-6/0/0, Enabled, Physical link is Down
Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
Current address: 00:17:cb:25:48:40, Hardware address: 00:17:cb:25:48:40

Flags: Link-Layer-Down Device-Down SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.101 ]
Encapsulation: ENET2
Shared-interface:
Tunnel token: Rx: 14.538
Input packets : 13
Output packets: 7774
Output Filters: filter-safari
Addresses, Flags: Dest-route-down Is-Preferred Is-Primary
Protocol inet6, MTU: 1500

Flags: None

Destination: 1000::173:16:0:0/96, Local: 1000::173:16:254:1

Addresses, Flags: Dest-route-down Is-Preferred
Destination: fe80::/64, Local: fe80::217:cb00:6525:4840
Flags: None
value of Non-owner, indicating that the shared physical interface ge-6/0/0 is not owned
by PSD6. The Shared interface field for ge-6/0/0.3 indicates that its peer interface is
ut-7/0/0.3.

Documentation
Example: Configuring Route Reflection—Roadmap
This section includes examples on how to configure the JCS1200 platform as a standalone
route reflector.
The examples show how to:
• Configure the JCS1200 chassis parameters and interfaces.
• Configure the routing options and protocols.
Related • Example: Configuring the JCS1200 Platform as a Route Reflector on page 157
Documentation
Example: Configuring the JCS1200 Platform as a Route Reflector
In this configuration example, a T640 router and four Routing Engines on the JCS1200
platform are configured for route reflection.

• Overview and Topology on page 158
Requirements
• One JCS1200 platform with Routing Engines in slots 1, 2, 3, and 4
• One T640 router with FPCs in slots 0, 1, and 2

Overview and Topology
Figure 15: Example: Route Reflection
R1
ge-1/1/1 ge-1/1/0
10.12.100.6 10.12.100.10
ge-2/0/2 ge-0/2/3
10.12.100.5 10.12.100.9
ge-2/0/3 ge-0/1/7
10.12.100.1 10.12.100.2
R2 R3
ge-2/0/1 ge-0/1/0
10.12.100.13 10.12.100.17
fxp1.1 fxp0.1
10.12.100.14 10.12.100.18
RR
g017296
Figure 15 on page 158 shows a T640 router (T-route) and four Routing Engines (RR, R1,
R2, and R3) on the JCS1200 chassis (bcg) configured for route reflection.
Each router is configured as a separate PSD. Each PSD has an associated Routing Engine
assigned on the JCS chassis and an associated FPC assigned on the T640 router. Table
21 on page 158 provides the chassis parameters required for the JCS1200 platform and
for the T640 router for each PSD.
Table 21: Chassis Parameters for Route Reflection

JCS 1200 Platform T640 Routing Node
Router PSD (bcg) (T-route)
Route PSD15 Routing Engine in slot 1 (No FPC required)

Reflector (RR) (bcgcpu1)
Router 1 (R1) PSD11 Routing Engine in slot 2 FPC in slot 1 (FPC1)

(bcgcpu2)

(bcgcpu3)

(bcgcpu4)
Configuration
The configuration of route reflection is described in the following sections:


• PSD15 Configuration (Route Reflector) on page 163

• PSD11 Configuration (Router 1) on page 163
Step-by-Step To configure the parameters required for Routing Engines in the JCS chassis:
Procedure
1. Log in to the JCS management module CLI.
2. Configure the Routing Engine that is part of PSD15. This Routing Engine is located
in slot 1 of the JCS chassis and acts as the route reflector.
To configure the Routing Engine in slot 1, issue the following command:
system> baydata -b 01 -data “V01–JCS1–SD2–PSD15–REP01–REB00–PRDSCE”
The baydata command specifies the target as a bay blade (-b), identifies the Routing
Engine (blade) in slot 01, and specifies the following parameters:
• V01—Product version, which is 01.
• JCS1—JCS platform identifier, which is 1.
• SD2—RSD identifier, which is 2.
• PSD15—PSD identifier, which is 15.
• REP01—Slot in which the primary Routing Engine resides, which is 01.
• REB00—Slot in which the backup Routing Engine resides. 00 indicates that there
is no backup Routing Engine.
• PRDSCE—Juniper Networks router product. There is a special product type for

the route reflector: Standalone Control Element (SCE).
3. Configure the Routing Engine that is part of PSD11 This Routing Engine is located in
slot 2 of the JCS chassis and acts as standalone router (not a route reflector).
system> baydata -b 02 -data “V01–JCS1–SD1–PSD11–REP02–REB00–PRDT640”
(Routing Engine) in slot 02, and specifies the following parameters:
• SD1—RSD identifier, which is 1. This router is in SD1, the route reflector is in SD2.

• REB00–Slot in which the backup Routing Engine resides. 00 indicates that there
• PRDT640—Juniper Networks router product, which is the T640 router.
in slot 3 of the JCS chassis and acts as standalone router (not a route reflector).
in slot 4 of the JCS chassis and acts as standalone router (not a route reflector).

system> baydata
1 Supported V01-JCS1-SD2-PSD15-REP01-REB00-PRDSCE
5 No blade present
6 No blade present
7 No blade present
8 No blade present
9 No blade present
10 No blade present
11 No blade present
12 No blade present
RSD Configuration

Procedure
the root-domain-id 1 statement to identify the RSD associated with Router 1, 2, and
3.


level:
a. Include the description “bcgcpu2 SWLab R1” statement to describe the PSD.
b. Include the fpcs 1 statement to assign the FPC in slot 1 to PSD11.
c. Include the control-system-id 1 statement to identify the JCS1200 platform.
d. Include the control-slot-numbers 2 statement to assign the Routing Engine in

slot 2 in the JCS chassis to PSD11.


level:




level:

chassis {
system-domains {
root-domain-id 1;
psd11 {
description "bcgcpu2 SWLab R1";
fpcs 1;
}
psd12 {
fpcs 2;
}
psd13 {
fpcs 0;
}
}
}
}
The RSD configuration on the T640 router does not include a root-domain-id 2 statement
for domain 2 (the route reflector domain) or any protected-system-domains PSD15
statements for the route reflector PSD. This is because the route reflector is self-contained
within the JCS chassis and does not require configuration on the T640 router.

PSD15 Configuration (Route Reflector)
Step-by-Step To configure the route reflector (PSD15):

Procedure
1. At the [edit interfaces] hierarchy level, include the fxp0 statement to configure the
internal Ethernet interface.
2. At the [edit interfaces fxp0] hierarchy level, include the unit 1 statement to configure
3. At the [edit interfaces fxp0 unit 1] hierarchy level, include the family inet address
10.12.100.18/30 statement to configure the IP version 4 (IPv4) suite protocol family.
4. At the [edit interfaces] hierarchy level, include the fxp1 statement to configure the
internal Ethernet interface.
5. At the [edit interfaces fxp1] hierarchy level, include the unit 1 statement to configure
6. At the [edit interfaces fxp1 unit 1] hierarchy level, include the family inet address
10.12.100.14/30 statement to configure the IPv4 suite protocol family.
interfaces {
fxp0 {
unit 1 {
family inet {
address 10.12.100.18/30;
}
}
}
fxp1 {
unit 1 {
family inet {
address 10.12.100.14/30;
}
}
}
}
PSD11 Configuration (Router 1)
Step-by-Step To configure Router 1 (PSD11):

Procedure
the Gigabit Ethernet interface.
3. At the [edit interfaces ge-1/1/0 unit 0] hierarchy level, include the family inet address
the internal Ethernet interface.

interfaces {
ge-1/1/0 {
unit 0 {
family inet {
address 10.12.100.10/30;
}
}
}
ge-1/1/1 {
unit 0 {
family inet {
address 10.12.100.6/30;
}
}
}
}

Procedure

interfaces {
ge-2/0/1 {
unit 0 {
family inet {
address 10.12.100.13/30;
}
}
}
ge-2/0/2 {
unit 0 {
family inet {
address 10.12.100.5/30;
}
}
}
ge-2/0/3 {
unit 0 {
family inet {
address 10.12.100.1/30;
}
}
}
}

Procedure

interfaces {
ge-0/1/7 {
unit 0 {
family inet {
address 10.12.100.2/30;
}
}
}
ge-0/2/3 {
unit 0 {
family inet {
address 10.12.100.9/30;
}
}
}
ge-0/1/0 {
unit 0 {
family inet {
address 10.12.100.17/30;
}
}
}
}
Related • Route Reflection Overview on page 8

Documentation
• Junos Policy Framework Configuration Guide
Example: Configuring Client-to-Client Reflection (OSPF)
Building on the topology shown in “Example: Configuring the JCS1200 Platform as a

Route Reflector” on page 157, this example shows how to configure routers for OSPF
client-to-client route reflection.

Requirements
This example requires the following hardware and software components:
• One JCS1200 platform with Routing Engines in slots 1,2, 3, and 4
• One T640 router with FPCs in slots 0, 1, and 2

Figure 16: Example: Configuring Client-to-Client Reflection (OSPF)

JCS1200 Chassis
R1
10.12.1.2
R2 R3
10.12.1.3 10.12.1.4
g017297
RR
The example configuration shown in Figure 16 on page 167 contains one router reflector
(RR) and three client routers (R1, R2, and R3). The three routers (R1 through R3) and the
route reflector (RR) are configured as PSDs that include Routing Engines on the JCS
chassis.
The routers have the following loopback addresses:
• RR—10.12.1.1
• R1—10.12.1.2
• R2—10.12.1.3
• R3—10.12.1.4
With this configuration example, a route added to client router R1 is propagated to the
route reflector (RR) and to the other client routers (R2, R3). This example uses OSPF as
the IGP and enables BFD for the connections from the route reflector.
Configuration
First, configure protocols for the route reflector (RR), then configure protocols for the
routers (R1, R2, and R3).
• PSD15 Configuration (Route Reflector) on page 168


PSD15 Configuration (Route Reflector)

Procedure
1. At the [edit routing-options] hierarchy level, include the autonomous-system 2
statement to configure the router’s AS number.
2. At the [edit protocols] hierarchy level, include the bgp statement to enable BGP on
the router.
3. At the [edit protocols bgp] hierarchy level, include the group int statement to define
the routing group.
A BGP system must know which routers are its peers (neighbors). You define the
peer relationship explicitly by configuring the neighboring routers that are the peers
of the local BGP system. After peer relationships have been established, the BGP
peers exchange update messages to advertise network reachability information.
4. At the [edit protocols bgp group int] hierarchy level:
a. Include the type internal statement to configure an internal BGP group.
b. Include the local-address 10.12.1.1 statement to specify the address of the local
end of a BGP session. This address is used to accept incoming connections to
the peer and to establish connections to the remote peer.
c. Include the cluster 1.2.3.4 statement to specify the cluster identifier (IPV4 address)
to be used by the route reflector cluster in the internal BGP group.
d. Include the neighbor 10.12.1.2, neighbor 10.12.1.2, and neighbor 10.12.1.4 statements
to specify which routers (Router 1, Router 2, and Router 3) are peers (neighbors)
of the route reflector.
5. At the [edit protocols] hierarchy level, include the ospf statement to enable OSPF
on the router.
6. At the [edit protocols ospf] hierarchy level, include the overload statement to prevent
other routers from attempting to route data traffic through the route reflector. This
option is set in the route reflector (RR), but not in Router 1, 2, and 3.
7. At the [edit protocols ospf] hierarchy level, include the area 0.0.0.0 statement to
specify the area identifier for this router to use when participating in OSPF routing.
All routers in the area must use the same area identifier to establish adjacencies.
8. At the [edit protocols ospf area 0.0.0.0] hierarchy level, include the interface fxp1.1
statement to configure the internal Ethernet interface in the backbone area.
9. At the [edit protocols ospf area 0.0.0.0 fxp1.1] hierarchy level, include the
bfd-liveness-detection statement to specify bidirectional failure detection timers.
10. At the [edit protocols ospf area 0.0.0.0 fxp1.1 bfd-liveness-detection] hierarchy level,
include the minimum-interval 333 statement to specify 333 milliseconds as the
minimum interval at which the local router transmits a hello packet and then expects
to receive a reply from its BFD neighbor.
11. Repeat Steps 7 through 9 for the fxp0.1 internal Ethernet interface:

a. At the [edit protocols ospf area 0.0.0.0] hierarchy level, include the interface
fxp0.1 statement to configure the internal Ethernet interface in the backbone
area.
b. At the [edit protocols ospf area 0.0.0.0 fxp0.1] hierarchy level, include the
bfd-liveness-detection statement to specify bidirectional failure detection timers.
c. At the [edit protocols ospf area 0.0.0.0 fxp0.1 bfd-liveness-detection] hierarchy

level, include the minimum-interval 333 statement to specify 333 milliseconds
as the minimum interval at which the local router transmits a hello packet and
then expects to receive a reply from its BFD neighbor.
routing-options {
autonomous-system 2;
}
protocols {
bgp {
group int {
type internal;
local-address 10.12.1.1;
cluster 1.2.3.4;
neighbor 10.12.1.2;
neighbor 10.12.1.3;
neighbor 10.12.1.4;
}
}
ospf {
overload;
area 0.0.0.0 {
interface fxp1.1 {
bfd-liveness-detection {
minimum-interval 333;
}
}
interface fxp0.1 {
}
}
}
}
}

Procedure
the router.

the routing group.
c. Include the export nh-self statement to apply the nh-self policy to routes being
exported from the routing table into BGP.
d. Include the neighbor 10.12.1.1 statement to specify the route reflector (RR) as
peer (neighbor) of Router 1. You do not need to include neighbor statements for
Router 2 or Router 3.
on the router.
7. At the [edit protocols ospf area 0.0.0.0] hierarchy level, include the interface ge-1/1/1.0
statement to configure the Gigabit Ethernet interface in the backbone area.
8. At the [edit protocols ospf area 0.0.0.0] hierarchy level, include the interface
ge-1/1/0.0 statement to configure the Gigabit Ethernet interface in the backbone
area.
9. At the [edit policy-options] hierarchy level, include the policy-statement nh-self

statement to define the nh-self policy.
A routing policy contains one or more terms. The nh-self policy you are defining
includes three terms (term a, term b, and term c). This policy is applied to routes
10. At the [edit policy-options nh-self] hierarchy level, include the term a statement to
define the first term for the nh-self policy.
11. At the [edit policy-options nh-self term a] hierarchy level, include the following
statements to specify that any static route with destination prefix 0.0.0.0/0 is
rejected:
from {
protocol static;
route-filter 0.0.0.0/0 exact;
}
then reject;
12. At the [edit policy-options nh-self] hierarchy level, include the term b statement to
define the next term for the nh-self policy.
13. At the [edit policy-options nh-self term b] hierarchy level, include the following
statements:

from protocol static;

then {
next-hop self;
accept;
}
These statements specify that for all remaining static routes, the next-hop address
is replaced by the local IP address used for the BGP adjacency. The router is then
accepted with the new, next-hop value.
14. At the [edit policy-options nh-self] hierarchy level, include the term c statement to
15. At the [edit policy-options nh-self term c] hierarchy level, include the then reject
statement to reject all other routes.
routing-options {
}
protocols {
bgp {
group int {
type internal;
export nh-self;
neighbor 10.12.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/1/1.0;
}
}
}
policy-options {
policy-statement nh-self {
term a {
from {
protocol static;
}
then reject;
}
term b {
then {
next-hop self;
accept;
}
}
term c {
then reject;
}

}
}

Procedure
the router.
the routing group.
on the router.
area.
area.
area.
10. At the [edit protocols ospf area 0.0.0.0 interface ge-2/0/1.0] hierarchy level, include
the bfd-liveness-detection statement to specify bidirectional failure detection timers.
11. At the [edit protocols ospf area 0.0.0.0 interface ge-2/0/1.0 bfd-liveness-detection]
hierarchy level, include the minimum-interval 333 statement to specify 333

milliseconds as the minimum interval at which the local router transmits a hello
packet and then expects to receive a reply from its BFD neighbor.
statements to specify that any static route with destination prefix 0.0.0.0/0 or
destination prefix 10.12.1.1/32 is rejected:
from {
protocol static;
}
then reject;
statements:

then {
next-hop self;
accept;
}
routing-options {
}
protocols {
bgp {
group int {
type internal;
export nh-self;

neighbor 10.12.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-2/0/1.0 {
}
}
}
}
}
policy-options {
term a {
from {
protocol static;
}
then reject;
}
term b {
then {
next-hop self;
accept;
}
}
term c {
then reject;
}
}
}

Procedure
the router.
the routing group.

on the router.
area.
area.
area.
10. At the [edit protocols ospf area 0.0.0.0 interface ge-0/1/0.0] hierarchy level, include
the bfd-liveness-detection statement to specify bidirectional failure detection timers.
11. At the [edit protocols ospf area 0.0.0.0 interface ge-0/1/0.0 bfd-liveness-detection]
hierarchy level, include the minimum-interval 333 statement to specify 333
milliseconds as the minimum interval at which the local router transmits a hello
packet and then expects to receive a reply from its BFD neighbor.
statements to specify that any static route with destination prefix 0.0.0.0/0 is
rejected:
from {
protocol static;


}
then reject;
statements:

then {
next-hop self;
accept;
}
routing-options {
}
protocols {
bgp {
group int {
type internal;
export nh-self;
neighbor 10.12.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-0/1/0.0 {
}
}
}
}
}
policy-options {
term a {
from {

protocol static;
}
then reject;
}
term b {
then {
next-hop self;
accept;
}
}
term c {
then reject;
}
}
}
Related • Route Reflection Overview on page 8

Documentation
• Junos Policy Framework Configuration Guide
Example: Consolidating a Layer 2 VPN Network
In this configuration example, a Layer 2 VPN network topology is reduced and simplified
by replacing two M320 routers at the provider edge (PE) of the network with a single
platform. The configuration for the consolidated Layer 2 VPN topology is described in
the following sections:

Requirements
This example requires the following hardware and software components:
• One JCS1200 platform with Routing Engines in slots 4, 5, and 6
• One T640 router with FPCs in slots 4 and 5

In a typical Layer 2 VPN topology, a customer edge (CE) router is located on each
customer site, providing an Ethernet interface between the customer LAN and the provider
core network. Provider (P) routers are located in the core of the provider network, and
provider edge (PE) routers sit at the edge of the network.

Figure 17 on page 178 illustrates a typical Layer 2 VPN topology, with T640 routers as P
routers, M320 routers as PE routers, and MX Series Ethernet Services routers as CE routers.
The service provider uses a separate PE router for each customer.
Figure 17: Typical Layer 2 VPN Network Topology

L2VPN L2VPN
CE CE
MX Series MX Series
router router
POS/T3 POS/T3
PE PE
M320 M320
router I-BGP mesh router
P I-BGP mesh P
g016912
T640 T640
router router
MPLS core
By replacing the two M320 routers with the JCS1200 chassis interconnected with the
T640 router, the service provider simplifies and consolidates the network at the provider
edge. One platform supports both customer networks through the creation of PSDs, as
shown in Figure 18 on page 178.
Figure 18: Consolidated Layer 2 VPN Network Topology
Configuration
Table 22 on page 178 provides the chassis parameters required for the JCS1200 platform
and the T640 router for each PSD.
Table 22: Chassis Parameters

PSD JCS1200 Platform T640 Routing Node
PSD1 Routing Engine in slot 4 FPC in slot 4 (with PICs supporting

Fast Ethernet and SONET interfaces)

Table 22: Chassis Parameters (continued)

PSD JCS1200 Platform T640 Routing Node
PSD2 Routing Engines in slots 5 and 6 FPC in slot 5 (with PICs supporting
Fast Ethernet and SONET interfaces)
The configuration for the consolidated Layer 2 VPN topology is described in the following
sections:

Procedure
1. Log in to the JCS management module CLI.
2. Configure the Routing Engine that is part of PSD1. The Routing Engine in slot 4 of
the JCS chassis is the master Routing Engine. There is no backup Routing Engine.
To configure the Routine Engine in slot 4, issue the following command:
OK
• PSD01–PSD identifier, which is 01.
• REP04—Slot in which the primary (or master) Routing Engine resides, which is
04.
• REB00—Slot in which the backup Routing Engine resides. 00 indicates that there
• PRDT640—Juniper Networks router product, which is a T640 router.
3. Configure the baydata command parameters for the Routing Engines that are part
of PSD2. The Routing Engine in slot 5 is the master, whereas the Routing Engine in
slot 6 is the backup Routing Engine.

a. To configure the Routing Engine in slot 5, issue the following command:
OK
The baydata command specifies the target as a bay blade (-b), identifies the
blade (Routing Engine) in slot 05, and specifies the following parameters:
• V01—Product version. Junos OS Release 9.1 supports only the value of 01.
• JCS01—JCS platform identifier of 01. Junos OS Release 9.1 supports only the
value of 01.
• REP05—Slot in which the primary (or master) Routing Engine resides, which
is 05.
• REB06—Slot in which the backup Routing Engine resides, which is 06.
b. To configure the Routing Engine in slot 6, issue the following command:
OK
The baydata command specifies the target as a bay blade (-b), identifies the
blade (Routing Engine) in slot 06, and specifies the following parameters:
• REP05—Slot in which the primary (or master) Routing Engine resides, which
is 05.
• REB06—Slot in which the backup Routing Engine resides, which is 06.
system> baydata

1 No blade present
2 No blade present
3 No blade present

7 No blade present
8 No blade present
9 No blade present
10 No blade present
11 No blade present
12 No blade present
RSD Configuration
Step-by-Step To configure the RSD and create the PSDs on the master Routing Engine in the T640
Procedure router:


level:
c. Include the control-slot-numbers 4 statement to assign the Routing Engine in



level:

the Routing Engines in slot 5 and slot 6 in the JCS chassis to PSD2.

chassis {
system-domains {
root-domain-id 1;
psd1 {
fpcs 4;
}
psd2 {
fpcs 5;
control-slot-numbers [5 6];
}
}
}
}
PSD1 Configuration
Step-by-Step The configuration for PSD1 is much the same as the configuration that was running on
Procedure the T640 router in the original VPN network topology before the consolidation of two
routers into a single platform.
The key difference is the management configuration. To configure the unique parameters
for PSD1:
1. Configure the following statements at the [edit groups re0 system] hierarchy level:
a. Include the host-name customer-a statement to configure the hostname for

PSD1.
b. Include the backup-router 192.168.71.254 statement to configure a backup router.

The backup router should be directly connected to the local routing platform by
way of the management interface.
c. Include the address 192.168.66.240/21 statement at the [edit interfaces fxp0

unit 0 family inet] hierarchy level to configure the management interface.
re0 {
system {
host-name customer-a;
backup-router 192.168.71.254 destination [ 172.16.0.0/12 192.168.0.0/16
207.17.136.192/32 10.9.0.0/16 10.10.0.0/16 10.13.10.0/23 10.84.0.0/16 10.5.0.0/16
10.6.128.0/17 192.168.102.0/23 207.17.136.0/24 10.209.0.0/16 10.227.0.0/16
10.150.0.0/16 10.157.64.0/19 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {

address 192.168.66.240/21;
}
}
}
}
}
interfaces {
fe-0/2/3 {
unit 0 {
family inet {
address 10.6.1.1/30;
}
family iso;
family mpls;
}
}
so-4/0/3 {
encapsulation frame-relay-ccc;
unit 2 {
dlci 512;
}
}
fe-4/3/0 {
unit 0 {
family inet {
address 10.5.1.2/30;
}
family iso;
family mpls;
}
}
}
routing-options {
confederation 702 members [ 65299 65235 65240 65269 ];
}
protocols {
mpls {
interface all;
}
bgp {
group ibgp {
type internal;
import match-all;
family l2vpn {
signaling;
}
export match-all;
neighbor 10.255.171.125;
}
}
isis {
interface fe-4/2/3.0 {
level 2 metric 10;

level 1 disable;
}
level 2 metric 10;
level 1 disable;
}
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ldp {
interface all;
interface lo0.0;
}
}
policy-options {
policy-statement frame-relay-vpn-export {
term a {
then {
community add frame-relay-vpn-comm;
accept;
}
}
term b {
then reject;
}
}
policy-statement frame-relay-vpn-import {
term a {
from {
protocol bgp;
community frame-relay-vpn-comm;
}
then accept;
}
term b {
then reject;
}
}
policy-statement match-all {
then accept;
}
community frame-relay-vpn-comm members target:65299:400;
}
routing-instances {
frame-relay-vpn {
instance-type l2vpn;
interface so-4/0/3.2;
route-distinguisher 10.255.171.124:4;
vrf-import frame-relay-vpn-import;
vrf-export frame-relay-vpn-export;
protocols {

l2vpn {
encapsulation-type frame-relay;
site 2 {
site-identifier 2;
interface so-4/0/3.2 {
remote-site-id 1;
}
}
}
}
}
}
PSD2 Configuration
Step-by-Step The configuration for PSD2 is much the same as the configuration that was running on
Procedure the T640 router in the original VPN network topology before the consolidation of two
routers into a single platform.
The key difference is the management configuration. To configure the unique parameters
for PSD2:
1. Configure the following statements at the [edit system re0] hierarchy level:
a. Include the host-name customer-b statement to configure the hostname for the
master Routing Engine (re0) on PSD2.

c. Include the address 192.168.66.240/21 statement at the [edit interfaces fxp0 unit
0 family inet] hierarchy level to configure the fxp0 management interface.
2. Configure the backup Routing Engine parameters by including the following

statements at the [edit system re1] hierarchy level:
a. Include the host-name customer-b1 statement to configure the hostname for

the backup Routing Engine (re1) on PSD2.

c. Include the address 192.168.66.242/21 statement at the [edit interfaces fxp0 unit
0 family inet] hierarchy level to configure the fxp0 management interface.
re0 {
system {
host-name customer-b;
207.17.136.192/32 10.9.0.0/16 10.10.0.0/16 10.13.10.0/23 10.84.0.0/16 10.5.0.0/16

10.6.128.0/17 192.168.102.0/23 207.17.136.0/24 10.209.0.0/16 10.227.0.0/16

10.150.0.0/16 10.157.64.0/19 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.66.242/21;
}
}
}
}
}
re1 {
system {
host-name customer-b1;
207.17.136.192/32 10.9.0.0/16 10.10.0.0/16 10.13.10.0/23 10.84.0.0/16 10.5.0.0/16
10.6.128.0/17 192.168.102.0/23 207.17.136.0/24 10.209.0.0/16 10.227.0.0/16
10.150.0.0/16 10.157.64.0/19 10.204.0.0/16 ];
}
interfaces {
fxp0 {
unit 0 {
family inet {
address 192.168.66.241/21;
}
}
}
}
}
interfaces {
fe-5/1/1 {
unit 0 {
family inet {
address 10.5.1.1/30;
}
family iso;
family mpls;
}
}
fe-5/1/2 {
unit 0 {
family inet {
address 10.8.1.1/30;
}
family iso;
family mpls;
}
}
so-5/3/0 {
unit 1 {
dlci 512;
}

}
}
routing-options {
confederation 702 members [ 65299 65235 65240 65269 ];
}
protocols {
mpls {
interface all;
}
bgp {
group ibgp {
type internal;
import match-all;
family l2vpn {
signaling;
}
export match-all;
neighbor 10.255.171.124;
}
}
isis {
level 2 metric 10;
level 1 disable;
}
level 2 metric 10;
level 1 disable;
}
interface all;
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ldp {
interface all;
interface lo0.0;
}
}
policy-options {
policy-statement frame-relay-vpn-export {
term a {
then {
community add frame-relay-vpn-comm;
accept;
}
}
term b {
then reject;
}
}

policy-statement frame-relay-vpn-import {
term a {
from {
protocol bgp;
community frame-relay-vpn-comm;
}
then accept;
}
term b {
then reject;
}
}
policy-statement match-all {
then accept;
}
community frame-relay-vpn-comm members target:65299:400;
}
routing-instances {
frame-relay-vpn {
instance-type l2vpn;
interface so-5/3/0.1;
route-distinguisher 10.255.171.125:4;
vrf-import frame-relay-vpn-import;
vrf-export frame-relay-vpn-export;
protocols {
l2vpn {
encapsulation-type frame-relay;
site 1 {
site-identifier 1;
interface so-5/3/0.1 {
remote-site-id 2;
}
}
}
}
}
}
Verification
Verify that the two PSDs are configured and operating properly:

• Verifying PSD Hardware on page 189
• Verifying PSD Routing Engine Information on page 190
• Verifying PSD Ethernet Switch Statistics on page 191
Purpose Verify that PSD1 and PSD2 are configured and online.
Action On the RSD, issue the show chassis psd command.
{master}

user@host> show chassis psd

1 Online 5 days, 19 hours, 16 minutes, 16 seconds
Meaning The example shows that the PSDs are configured and online.
Verifying PSD Hardware
Purpose Display information about the FPCs and Routing Engines that are part of each PSD.
Action On each PSD, issue the show chassis hardware command.
The following example displays the hardware components belonging to PSD1:
user@psd1> show chassis hardware

rsd-re0:
--------------------------------------------------------------------------
Hardware inventory:
Chassis S19068 T640
FPM GBUS REV 02 710-002901 HE3251 T640 FPM Board
FPM Display REV 02 710-002897 HE7860 FPM Display
PEM 1 Rev 03 740-002595 MH15367 Power Entry Module
FPC 4 REV 02 710-002385 HC0619 FPC Type 2
CPU REV 06 710-001726 HB1916 FPC CPU
MMB 1 REV 03 710-004047 HE3195 MMB-288mbit
ICBM REV 04 710-003384 HC0377 FPC ICBM
PPB 0 REV 02 710-003758 HC0585 PPB Type 2
SIB 0 REV 05 750-005486 HV8445 SIB-I8-F16
SIB 1 REV 05 750-005486 HW2650 SIB-I8-F16
SIB 2 REV 05 750-005486 HW7041 SIB-I8-F16
SIB 3 REV 05 750-005486 HV4274 SIB-I8-F16
SIB 4 REV 05 750-005486 HV8464 SIB-I8-F16
psd1-re0:
--------------------------------------------------------------------------
Hardware inventory:
The following example displays the hardware components belonging to PSD2:

rsd-re0:
--------------------------------------------------------------------------
Hardware inventory:
Chassis S19068 T640
FPC 5 REV 01 710-010233 HM4187 E-FPC Type 1
CPU REV 01 710-010169 HS9939 FPC CPU-Enhanced
MMB 1 REV 01 710-010171 HR0833 MMB-288mbit
SIB 0 REV 05 750-005486 HV8445 SIB-I8-F16
SIB 1 REV 05 750-005486 HW2650 SIB-I8-F16
SIB 2 REV 05 750-005486 HW7041 SIB-I8-F16
SIB 3 REV 05 750-005486 HV4274 SIB-I8-F16
SIB 4 REV 05 750-005486 HV8464 SIB-I8-F16
psd2-re0:
--------------------------------------------------------------------------
Hardware inventory:
Meaning In the command output, the FPC that belongs to the PSD is displayed under the rsd-re0:
field heading. The Routing Engines on the JCS chassis that belong to the PSD are displayed
under the psd2-re0: heading.
Verifying PSD Routing Engine Information
Purpose Display detailed information about the Routing Engines assigned to each PSD.
Action On each PSD, issue the show chassis routing-engine command.
The following example displays detailed information about the Routing Engine assigned
to PSD1.

Slot 0:
Physical Slot 4
DRAM 13312 MB

CPU utilization:
User 0 percent
Kernel 0 percent
Interrupt 0 percent
Idle 100 percent
Serial ID SNBLJCSAC004
Start time 2008-03-30 03:19:49 PDT
Uptime 11 hours, 46 minutes, 24 seconds
0.00 0.00 0.00
The following example displays detailed information about the Routing Engines assigned
to PSD2.

Slot 0:
Physical Slot 6
DRAM 13312 MB
CPU utilization:
User 0 percent
Kernel 0 percent
Interrupt 0 percent
Idle 100 percent
Start time 2008-03-30 03:25:43 PDT
0.00 0.00 0.00
Slot 1:
Physical Slot 5
DRAM 13312 MB
CPU utilization:
User 0 percent
Kernel 0 percent
Interrupt 0 percent
Idle 100 percent
Start time 2008-03-30 03:25:40 PDT
Meaning The Physical Slot field displays the JCS chassis slot number in which each Routing Engine
is installed.
Verifying PSD Ethernet Switch Statistics
Purpose Display the Ethernet switch statistics for each PSD.

Action On each PSD, issue the show chassis ethernet-switch statistics command.
The following example displays information about the Ethernet switch statistics for PSD1:
user@psd1> show chassis ethernet-switch statistics

Statistics for switch[1] port INT4 connected to fpx0:
TX Octets 3295346375
TX Unicast Packets 47634559
TX Multicast Packets 1848912
TX Broadcast Packets 28900124
Tx Discards 0
TX Errors 0
RX Octets 1393157883
RX Unicast Packets 25671001
RX Multicast Packets 453
RX Broadcast Packets 1568098
RX Discards 1539
RX Errors 0
RX Unknown Protocol 0
Link State Changes 209
Statistics for switch[1] port EXT1 connected to RSD 1:
Tx Discards 0
TX Errors 0
RX Discards 8
RX Errors 4
Statistics for switch[1] port EXT6 connected to external management:
Tx Discards 0
TX Errors 0
RX Octets 509146577
RX Discards 18650
RX Errors 6
Tx Discards 0
TX Errors 0

RX Discards 1936
RX Errors 0
Tx Discards 0
TX Errors 0
RX Octets 478994886
RX Discards 12
RX Errors 6
TX Octets 778154
Tx Discards 0
TX Errors 0
RX Octets 723965940
RX Discards 24442638
RX Errors 3331664
The following example displays information about the Ethernet switch statistics for
PSD2:
user@psd2> show chassis ethernet-switch statistics

Tx Discards 0
TX Errors 0
RX Discards 1492
RX Errors 0
Tx Discards 0
TX Errors 0

RX Discards 8
RX Errors 4
Tx Discards 0
TX Errors 0
RX Octets 510609656
RX Discards 18650
RX Errors 6
Tx Discards 0
TX Errors 0
RX Discards 1844
RX Errors 0
Tx Discards 0
TX Errors 0
RX Octets 479053702
RX Discards 12
RX Errors 6
TX Octets 778154
Tx Discards 0
TX Errors 0
RX Octets 732481038


RX Errors 3331666
Meaning In the output for PSD1:
• INT4 provides the internal connection between the Routing Engine in slot 4 and the
JCS switch module.
• EXT1 provides the connection between the JCS switch module and the RSD.
• EXT6 provides the connection between the JCS switch module and the management
ports on each Routing Engine in the JCS chassis.
In the output for PSD2:
• INT6 provides the internal connection between the master Routing Engine in slot 6
and the JCS switch module.
• EXT1 provides the connection between the JCS switch module and the RSD.
• EXT6 provides the connection between the JCS switch module and the management
ports on each Routing Engine in the JCS chassis.

Documentation


PART 6
Managing the JCS1200 Platform

• Managing the JCS1200 Platform on page 199
• Summary of JCS Management Module Monitoring Commands on page 209


CHAPTER 15
Managing the JCS1200 Platform
• JCS Management Module Verification Tasks on page 199

• Displaying Vital Product Data on page 200
• Clearing the Event Log on page 202
• Displaying the Event Log on page 202
• Displaying Power Domain Information on page 203
• Displaying System Component Status on page 204
• Displaying a List of Components on page 205
• Displaying Temperature Information on page 206
• Displaying Voltage Information on page 207
JCS Management Module Verification Tasks
Table 23 on page 199 lists some JCS management module verification tasks useful for
monitoring JCS operations.
Table 23: Summary of Commonly Used JCS Management Module Verification Tasks
Items to Check Description Task
Vital product data Display hardware part numbers, system component “Displaying Vital Product Data” on
counts, and software versions. page 200
Event log Display (or clear) the contents of the event “Clearing the Event Log” on page 202
log—including user access events.
“Displaying the Event Log” on page 202
Power domains Display power domain information. “Displaying Power Domain

Information” on page 203
System component status Display the status of all system components. “Displaying System Component
Status” on page 204
System configuration Display the system configuration list. “Displaying a List of Components” on
page 205
Temperature Display component temperature values and ranges. “Displaying Temperature Information”
on page 206

Table 23: Summary of Commonly Used JCS Management Module Verification Tasks (continued)
Voltage Display voltage information for system components. “Displaying Voltage Information” on
page 207

Documentation
Displaying Vital Product Data

Purpose Display identification and configuration information for the component specified. This
includes hardware part numbers, system component counts, and software versions. You
can use this information to determine whether a particular feature is supported, whether
firmware requires updating, or whether a particular software bug occurs in your version
of the software.
Action Display identification and configuration information using the JCS management module
CLI info command.
The following sample output appears when the info command is targeted for the entire
JCS1200 platform:
system> info
UUID: 597A 6B81 C99F 333 9DE7 A3D4 52F9 95D1
Manufacturer: ZX1234
Manufacturer ID: 20301Product code: System Enclosure/CHAS—BP—JCS1200–S
Serial number: 02Part no.: 740–025747
Component serial no.: ZX001
CLEI: Not Available
AMM slots: 2
Blade slots: 12
I/O Module slots: 10
Power Module slots: 4
Blower slots: 4
Media Tray slots: 2
...
The sample output shows relevant hardware information about the JCS1200 platform,
including the JCS chassis serial number (Manufacturer field) and JCS midplane serial
number (Component Serial No. field). It also includes the number and type of chassis
slots supported.
The following sample output appears when the info command is targeted for the JCS
management module:
system> info –T mm[1]

Name: bcgmm1
UUID: 369C 7EB6 4067 11DC AAAE 0014 5EDF 924E
Manufacturer ID: 20301
Product code: JCS Adv Management Module
Serial number: Not Available
Part no.: 740-023172

Chapter 15: Managing the JCS1200 Platform
Component serial no.: JCS-MM-SN-BCG001

CLEI: Not Available
AMM firmware
Build ID: BPEO34E
File name: CNETCMUS.PKT
Rel date: 11-20-07
Rev: 34
...
The sample output shows relevant hardware information about the JCS management
module including the product code and part number. It also includes the build ID and
release date of the management module firmware.
The following sample output appears when the info command is targeted for the JCS
switch module:
system> info –T switch[1]

UUID: 0018 B11B 8900 0000 0000 0000 0000 0000
Product code: JCS L2/L3 Switch Module
Serial number: Not Available
Part no.: 740-023179
Component serial no.: JCS-SWITCH-SN-BCG001
CLEI: COUCAAGAAA
Unique ID 1: Not Available
Boot ROM
Build ID: WMZ02000
Rel date: 10/15/2007
Rev: 0104
Main Application 1
Build ID: WMZ02000
Rel date: 10/15/2007
Rev: 0104
Main Application 2
Build ID: WMZ02000
Rel date: 10/15/2007
Rev: 0104
MAC Address: 00:18:B1:1B:89:00
...
The following sample output appears when the info command is targeted for a Routing
Engine:
system> info –T blade[1]

Name: bcgcpu1
UUID: 7393 CA1C 00C3 3A97 AC4C 6EE7 608B CA0D
Product code: 4 X86 CPU Blade Server/JCS Routing Engine
Serial number: KQLABC2
Part no.: 740-023157
Component serial no.: JCS-BLADE-SN-BCG001
CLEI: Not Available
MAC Address 1: 00:1A:64:32:E4:D8
MAC Address 2: 00:1A:64:32:E4:DA
BIOS
Build ID: LJE104BUS
Rel date: 12/11/2007
Rev: 1.00
Diagnostics
Build ID: BCYT24AUS
Rel date: 08/27/2007

Rev: 1.04
Blade sys. mgmt. proc.
Build ID: BCBT42B
Rev: 1.11
Local Control
KVM: Yes
Media Tray: Yes
SCOD: Unknown
Power On Time: 5 days 20 hours 35 min 12 secs
Number of Boots: 3

Documentation
• info on page 219
Clearing the Event Log

Purpose The event log stores events that occur on the JCS1200 platform. This includes user login
activity, configuration changes, error conditions, and so on. Periodically, you may wish to
clear the event log to remove exiting events.
Action Clear the event log using the JCS management module CLI clearlog command.
The following sample output appears when the event log for the JCS management
module is cleared:
system> clearlog —T system:mm[1]

OK
The following sample output shows information that is returned if the displaylog command
is run after the event log has been cleared.
system:mm[1]> displaylog -f
1 I SERVPROC 01/28/08 19:50:15 System log cleared.
(There are no more entries in the event log.)
Related • clearlog on page 211

Documentation
• displaylog on page 212
Displaying the Event Log

Purpose The JCS software generates event log messages to record events that occur on the
JCS1200 platform, including the following:
• Routine operations, such as configuration changes and user login activities.
• Failure and error conditions.
• Emergency and critical conditions, such as power-off due to excessive temperature.
You can display the event log to monitor JCS1200 platform operations and to diagnose
and troubleshoot problems.

Action Display the event log using the JCS management module CLI displaylog command:
The following sample output appears when the displaylog command is targeted for the
most recent events:
system> displaylog —T mm[1]

1 I Audit 01/28/08 19:47:01 Remote logoff for 'gdickey' from Serial via COM1
2 I Blade_03 01/28/08 19:46:14 (bcgcpu3) Blade reboot
3 I SERVPROC 01/27/08 19:45:57 Login ID:''USERID' from 192.168.70.231.
4 E SERVPROC 01/27/08 19:42:58 Failure reading I2C device. Check bus 4.
5 I SERVPROC 01/27/08 19:41:54 Login ID:''USERID' from WEB browser at
IP@=192.168.70.231'
The sample output shows the event log for the JCS management module. By default,
the first time the command is executed, the five most recent log entries are displayed.
Each subsequent time the command is issued, the next five log entries are displayed.
The following sample output shows the complete event log for the JCS management
module. All events since the last time the log was cleared are shown.
system:mm[1]> displaylog -a
1 I Audit 01/28/08 19:47:01 Remote logoff successful for user 'gdickey'
3 I SERVPROC 01/27/08 19:45:57 Login ID:''USERID' CLI telnet authenticated.
5 I SERVPROC 01/27/08 19:41:54 Login ID:''USERID' from WEB browser.
6 E SERVPROC 01/27/08 19:41:53 Blower 2 Fault Multiple blower failures.
7 E SERVPROC 01/27/08 19:41:53 Blower 1 Fault Single blower failure.
8 I SERVPROC 01/27/08 19:41:48 Ethernet[1] Link Established at 100Mb.
9 I SERVPROC 01/27/08 19:41:48 Ethernet[1] configured to do 100Mb/Full Duplex.
10 I SERVPROC 01/27/08 19:41:48 Ethernet[1] MAC Address: 0x00-09-6B-CA-0C-81
12 I SERVPROC 01/27/08 19:41:48 Ethernet[0] configured to do Auto Speed/Auto.
14 I SERVPROC 01/27/08 19:41:48 Management Module Network Initialization.
15 I SERVPROC 01/27/08 19:41:46 ENET[1] IP-Cfg:HstName=MM00096BCA0C81.
Related • clearlog on page 211

Documentation
Displaying Power Domain Information

Purpose You can display power domain information to make sure the power domains are operating
properly. The JCS chassis is separated into two power domains. Power domain A supports
all JCS modules and slots (bays) 1 through 6. Power domain A uses power modules 1
and 2. Power domain B supports slots 7 though 14 and uses power modules 3 and 4.
NOTE: To support devices in power domain B, a power-supply option

(consisting of two power modules) must be installed.
Action Display power domain information using the JCS CLI fuelg command.

The following sample output appears when power domain information is displayed:
system> fuelg
Note: All power values are displayed in Watts.
Power Domain 1
--------------
Status: Power domain status is good.
Modules:
Bay 1: 2880
Bay 2: 2880
Power Management Policy: Basic Power Management
Power in Use: 907
Total Power: 4000
Allocated Power (Max): 1921
Remaining Power: 2079
Power Domain 2
--------------
Modules:
Bay 3: 2880
Bay 4: 2880
Power Management Policy: Basic Power Management
Power in Use: 116
Total Power: 4000
Allocated Power (Max): 800
Related • fuelg on page 214

Documentation
Displaying System Component Status

Purpose You can display the current health status for the JCS1200 platform to determine if system
components are operating properly. For each component, health status can be:
• Ok
• Warning
• Critical
Action Display health status for the JCS1200 platform using the JCS management module CLI
health command.

The following sample output appears when health status is displayed for all components
installed in the JCS1200 platform:
system> health —l a
OK
mm[1] : OK
mm[2] : OK
blade[1] : OK
blade[2] : OK
blade[3] : OK
blade[4] : OK
blade[5] : Minor
blade[6] : OK
power[1] : OK
power[2] : OK
power[3] : OK
power[4] : OK
blower[1] : OK
blower[2] : OK
blower[3] : OK
blower[4] : OK
switch[1] : OK
switch[2] : OK
The following sample output appears when health status is displayed for a JCS Routing
Engine:
system> health -l –a T system:blade[5]

system: Minor
blade[5]:Minor
5V over voltage
CPU1 temperature warning
In this example, a minor warning appears for the Routing Engine in slot 5. The voltage
level has risen, causing a temperature increase.
Related • health on page 216

Documentation
Displaying a List of Components

Purpose You can display a list of components included in the JCS chassis. This information is
useful for determining how many Routing Engines and management modules are installed
and which management module is primary.
Action Display a list of components in the JCS chassis using the JCS management module CLI
list command.
The following sample output appears when the list is displayed for all components
installed in the JCS chassis:
system> list —l a
system
mm[1] primary
mm[2] standby
power[1]
power[2]

power[3]
power[4]
blower[1]
blower[2]
blower[3]
blower[4]
switch[1]
switch[2]
blade[1] bcgcpu1
sp
cpu[1]
blade[3] bcgcpu3
sp
cpu[1]
blade[4] bcgcpu4
sp
cpu[1]
blade[5] bcgcpu5
sp
cpu[1]
blade[6] bcgcpu6
sp
cpu[1]
mt[1]
mt[2]
tap
mux[1]
mux[2]
In this example, two management modules (mm) are installed and mm[1] is the primary
management module. There are also four power supplies (power), four fan assemblies
(blowers), and two JCS switch modules (switch). There are six Routing Engines (blade)
and two media trays (mt).

Documentation
• list on page 222
Displaying Temperature Information

Purpose You can display temperature information for components in the JCS chassis. This
information is useful for viewing current temperature values and temperature threshold
settings.
Action Display temperature information (in degrees Fahrenheit) for components in the JCS
chassis using the JCS CLI temps command.
The following sample output appears when temperature information is displayed for a
JCS management module:
system> temps –T mm[1]

Warning
Component Value Warning Reset Hysteresis

---------- ------- ------- ------- ----------

MM Ambient 43.00 60.00 55.00 (5.00)
The following sample output appears when temperature information is displayed for a
JCS Routing Engine:
system> temps –T blade[3]

Warning
Component Value Warning Reset Hysteresis
---------- ------- ------- ------- ----------
CPU 1 38.00 85.00 95.00 (7.00)
Related • temps on page 229

Documentation
Displaying Voltage Information

Purpose You can display voltage information for components in the JCS chassis. This information
is useful for viewing current voltage values and voltage threshold settings.
Action Display voltage information for components in the JCS chassis using the JCS CLI volts
command.
The following sample output appears when voltage information is displayed for a JCS
management module:
system> volts –T mm[1]

Warning
Source Value Warning Reset Hysteresis
------ ------ --------------- -------------- ----------
+5v +4.84 (+4.50,+5.25) (+4.85,+5.15) (+0.35,+0.10)
+3.3v +3.26 (+3.00,+3.47) (+3.20,+3.40) (+0.20,+0.07)
+12v +12.03 (+10.80,+12.60) (+11.64,+12.36) (+0.84,+0.24)
-5v -4.90 (-5.50,-4.75) (-5.15,-4.85) (+0.35,+0.10)
+2.5v +2.48 (+2.25,+2.63) (+2.42,+2.58) (+0.17,+0.05)
+1.8v +1.76 (+1.62,+1.89) (+1.74,+1.86) (+0.12,+0.03)
The following sample output appears when voltage information is displayed for a JCS
Routing Engine:
system> volts –T blade[1]

Source Value Critical
--------------- ------- ----------------
Planar 0.9V +0.88 (+0.40,+1.50)
Planar 12V +12.12 (+10.20,+13.80)
Planar 3.3V +3.30 (+2.78,+3.79)
Planar 5V +4.90 (+4.23,+5.74)
Planar VBAT +3.05 (+2.54,+3.44)
Related • volts on page 231

Documentation


CHAPTER 16
Summary of JCS Management Module

Monitoring Commands
NOTE: The JCS management module CLI provides a large number of

commands and command options. This section describes only the subset of
commands and command options that we recommend for monitoring the
JCS1200 platform in a Juniper Networks environment.

boot
Syntax boot -T system:blade[x]
Description (JCS management module CLI) Perform an immediate reset and restart of a specified
Routing Engine (blade).
Options -T system:blade[x]—Specify the Routing Engine to boot. Replace x with the Routing
Engine slot number (1 through 12).

Level
Related • power on page 224

Documentation
List of Sample Output boot on page 210
boot system> boot –T system:blade[10]

OK

Chapter 16: Summary of JCS Management Module Monitoring Commands
clearlog
Syntax clearlog -T system:mm[x]
Description (JCS management module CLI) Clear the JCS management module event log to remove
existing events.
Options -T system:mm[x]—Specify the management module as the target of the command.


Level
Related • Clearing the Event Log on page 202

Documentation
List of Sample Output clearlog on page 211
The command prompt changes to reflect the new command target.
clearlog system> clearlog –T system:mm[1]

OK

displaylog
Syntax displaylog -T system:mm[x] <-a> <-date date-filter> <-sev severity-filter> <-src

source-filter>
Description (JCS management module CLI) Display the JCS management module event log entries.
Options -T system:mm[x]—Specify the management module as the target of the command.

-a—(Optional) Display all entries in the JCS management module event log. By default,
the displaylog command displays only the first five entries in the log.
-date date-filter—(Optional) Display all entries in the JCS management module event
log that meet the date filter criteria. Replace date-filter with a list of dates in mm/dd/yy
format. Use the pipe symbol (|) to separate dates in the list. For example, specify the a
-date 03/17/2008|03/18/2008 filter to show all events in the log that occurred on March
17, 2008 and March 18, 2008.
-sev severity-filter—(Optional) Display all entries in the JCS management module event
log that meet the severity filter criteria. Replace severity-filter with a list of severities. Use
the pipe symbol (|) to separate severities in the list. Severities you can specify include:
• I—information
• E—error
• W—warning
For example, you can specify a -sev E|W filter to show all error and warning events in the
log.
-src source-filter—(Optional) Display all entries in the JCS management module event
log that meet the source filter criteria. Replace source-filter with a list of event sources.
Use the pipe symbol (|) to separate sources in the list. Sources you can specify include:
• blade_x—Routing Engine (blade). Replace x with a value of 01 through 12.
• blower-x—JCS fan (blower). Replace x with a value of 1 through 4.
• mm_x—JCS management module. Replace x with a value of 1 or 2.
• mt_x—JCS media tray. Replace x with a value of 1 or 2.
• power_x—JCS power supply. Replace x with a value of 1 through 4.
• switch_x—JCS switch module. Replace x with a value of 1 or 2.

Level

Related • Displaying the Event Log on page 202

Documentation
• clearlog on page 211
List of Sample Output displaylog (All Entries) on page 213

displaylog (Filter by Severity) on page 213
Output Fields Table 24 on page 213 lists the output fields for the displaylog command. Output fields are
Table 24: displaylog Output Fields

Index Number Log entry number. The most recent entries have the lowest numbers.
Entry Type Type of log entry. Log entries can be informational (I), warnings
(W), or errors (E).
System System where the entry occurred; for example, Blade_03 (Routing
Engine in slot 3).
Date and Time Date and time the entry was logged.
Message Message associated with the log entry.
displaylog (All Entries) system> displaylog –T system:mm[1] -a

1 I Audit 01/28/08 19:47:01 Remote logoff successful for user 'kmarkham'
3 I SERVPROC 01/27/08 19:45:57 Login ID:''USERID' CLI telnet authenticated.
5 I SERVPROC 01/27/08 19:41:54 Login ID:''USERID' from WEB browser.
9 I SERVPROC 01/27/08 19:41:48 Ethernet[1] configured to do 100Mb/Full Duplex.
12 I SERVPROC 01/27/08 19:41:48 Ethernet[0] configured to do Auto Speed/Auto.
14 I SERVPROC 01/27/08 19:41:48 Management Module Network Initialization.
15 I SERVPROC 01/27/08 19:41:46 ENET[1] IP-Cfg:HstName=MM00096BCA0C81.
displaylog (Filter by system> displaylog –T system:mm[1] -sev E

Severity) 1 E SERVPROC 01/27/08 19:42:58 Failure reading I2C device. Check bus 4.

fuelg
Syntax fuelg -T system:mm[x] <domain> <-qm (off | on)>
Description (JCS management module CLI) Display or configure power domain information for power
supplies on the JCS1200 platform.
domain—(Optional) Display information for a specific power domain. Replace domain

with pd1 (power domain 1) or pd2 (power domain 2). By default, power domain information
is displayed for both power domains.
The JCS1200 platform has two power domains. Power domain 1 supports all JCS modules
and slots (bays) 1 through 6. Power domain 1 uses power supply modules 1 and 2. Power
domain 2 supports slots 7 through 12 and uses power supply modules 3 and 4.
-qm (on | off)—(Optional) Specify a thermal event response (quiet mode):
• off—Fans will increase speed to provide additional cooling.
• on—Fans will remain at fixed speed. Power is throttled (for components that support
power throttling) to reduce power consumption and heat.
Required Privilege supervisor (configure)

Level operator (display)
Related • Displaying Power Domain Information on page 203

Documentation
List of Sample Output fuelg (Display) on page 215

fuelg (Configure) on page 215
Output Fields Table 25 on page 214 lists the output fields for the fuelg command. Output fields are listed
Table 25: fuelg Output Fields

Domain Number Status information for the power domain (power domain 1 or power
domain 2).
Bay x Bay (slot) number and power value (in watts) for the power supply.
Power Budget Total amount of power (in watts) allocated to the domain.
Reserved Power Amount of power (in watts) held in reserve.

Table 25: fuelg Output Fields (continued)

Remaining Power Amount of power (in watts) available to the domain (power budget
– reserved power = remaining power).
Power in Use Amount of power (in watts) currently being used by the power
supplies in the domain.
fuelg (Display) system> fuelg –T system:mm[1]

Power Domain 1
— — — — — — — —
Modules:
Bay 1: 2000
Bay 2: 2000
Power Budget: 3200
Reserved Power: 400
Power in Use: 400
Power Domain 2
— — — — — — — —
Modules:
Bay 3: 1800
Bay 4: 1800
Power Budget: 2880
Reserved Power: 0
Power in Use: 0
fuelg (Configure) system> fuelg –T system:mm[1] -qm off

OK

health
Syntax health -T target<-l depth> <-f>
Description (JCS management module CLI) Display the current health status of a device on the
JCS1200 platform.
• system:switch[x]—JCS switch module. Replace x with a value of 1 or 2.
• system:power[x]—JCS power supply. Replace x with a value of 1 through 4.
• system:blower[x]—JCS fan (blower). Replace x with a value of 1 through 4.
-l depth—(Optional) Display health status for a hierarchy of devices (starting with the
device specified as the command target). Replace depth with one of the following values:
• 2 | all | a—Health status for the full hierarchy of devices (starting at the command target
level). You can enter a as an abbreviation for all.
• 1—Health status for the command target only.
-f—(Optional) Display health status and active alerts for the device specified as the
command target.

Level
Related • Displaying System Component Status on page 204

Documentation
List of Sample Output health (All) on page 216

health (Routing Engine) on page 217
health (with Alerts) on page 217
health (All) system> health -l a

mm[1]: OK
mm[2]: OK
blade[1]: OK
blade[2]: OK
blade[3]: OK
blade[4]: OK
blade[5]: Minor
blade[6]: OK
power[1]: OK
power[2]: OK

power[3]: OK
power[4]: OK
blower[1]: OK
blower[2]: OK
blower[3]: OK
blower[4]: OK
switch[1]: OK
switch[2]: OK
health (Routing system> health -T system:blade[5]

Engine) blade[5]: Minor
health (with Alerts) system> health -l a -f

system: Major
blade[5]: Minor
5V over voltage
CPU1 temperature warning
power[2]: Minor
5V over voltage
switch[1]: Major
temperature fault

history
Syntax history
<!n>
Description (JCS management module CLI) Display the last eight commands entered. You can use
this list to reenter commands. To reenter a command, use the history command to display
a list of recent commands, then type an exclamation point (!) followed by the number
of the command you wish to reenter.
Options !n—(Optional) Reenter a command from the history list. Replace n with a value of 0
through 7 to indicate the number of the command you wish to reenter.

Level

Documentation
List of Sample Output history (Listing) on page 218

history (Reentering a Command) on page 218
history (Listing) system:mm[1]> history
0 dns
1 dns —on
2 dns
3 dns —i1 192.168.70.29
4 dns
5 dns —i1 192.168.70.29 —on
6 dns
7 history
history (Reentering a system:mm[1]> !2

Command)
Enabled
-i1 192.168.70.29
-12 0.0.0.0
-i3 0.0.0.0

info
Syntax info -T target
Description (JCS management module CLI) Display information about JCS hardware components
and component configuration.
Options -T target—Specify a command target to display information about a specific hardware

component. You can only display information for one target at a time. Valid targets for
this command include:
• system:blade[x]—Specify a Routing Engine as the command target. Replace x with

the Routing Engine slot number (1 through 12).
• system:blower[x]—Specify a JCS fan module as the command target. Replace x with

the fan module number (1 through 4).
• system:mm[x]—Specify a JCS management module as the command target. Replace

• system:mt[x]—Specify a JCS media tray as the command target. Replace x with the
media tray number (1 or 2).
• system:mux[x]—Specify a JCS MUX card as the command target. Replace x with the
MUX card number (1 or 2).
• system:power[x]—Specify a JCS power module as the command target. Replace x

with the power module number (1 through 4).
• system:switch[x]—Specify a JCS switch module as the command target. Replace x

with the switch module number (1 or 2).
• system:tap—Specify the JCS alarm panel as the command target.

Level
Related • Displaying Vital Product Data on page 200

Documentation
List of Sample Output info (System) on page 220

info (Management Module) on page 221
info (Routing Engine) on page 221
Output Fields Table 26 on page 220 lists the output fields for the info command. Output fields are listed

Table 26: info Output Fields

UUID Universal unique identifier. This hexadecimal number is generated

automatically and uniquely identifies the hardware component on
the network.
Manufacturer (system keyword only) JCS chassis serial number.
Manufacturer ID Manufacturer's ID. ID number assigned to the hardware component

manufacturer.
Product Code Product code assigned to the hardware component.
Serial Number Serial number assigned to the hardware.
Part No. (system keyword only) JCS chassis part number.
Component Serial Number (system keyword only) JCS midplane serial number.
CLEI Common Language Equipment Identification (industry standard

used to identify telecommunications equipment).
AMM Firmware (JCS Management Module only) Build ID, filename, release date,
and revision number of the firmware installed on the JCS
management module.
AMM Slots (system keyword only) Number of JCS management module slots.
Blade Slots (system keyword only) Number of Routing Engine (blade) slots.
I/O Module Slots (system keyword only) Number of I/O module slots.
Power Module Slots (system keyword only) Number of power module slots.
Blower Slots (system keyword only) Number of fan (blower) slots.
Media Tray Slots (system keyword only) Number of media tray slots.
info (System) system> info –T system
UUID: 597A 6B81 C99F 9DE7 A3D4 52F9 95D1

Product code: System Enclosure/CHAS-BP-JCS1200–S
Serial number: 02
Part no.: 740-025747
CLEI: Not Available
AMM slots: 2
Blade slots: 12
I/O Module slots: 10

Power Module slots: 4

Blower slots: 4
Media Tray slots: 2
info (Management system> info –T system:mm[1]

Module)
Name: bcgmm1
UUID: 369C 7EB6 4067 11DC AAAE 0014 5EDF 924E
Product code: JCS Management Module
Serial number: O2
Part no.: 740-023172
Component serial no.: JX002
CLEI: Not Available
AMM firmware
Build ID: BPEO34E
File name: CNETCMUS.PKT
Rel date: 11-20-07
Rev: 34
...
info (Routing Engine) system> info –T system:blade[6]
Name: bcgcpu1
UUID: 7393 CA1C 00C3 3A97 AC4C 6EE7 608B CA0D
Product code: 4 X86 CPU Blade Server/JCS Routing Engine
Serial number: 02
Part no.: 740-023157
CLEI: Not Available
MAC Address 1: 00:1A:64:32:E4:D8
MAC Address 2: 00:1A:64:32:E4:DA
BIOS
Build ID: LJE104BUS
Rel date: 12/11/2007
Rev: 1.00
Diagnostics
Build ID: BCYT24AUS
Rel date: 08/27/2007
Rev: 1.04
Blade sys. mgmt. proc.
Build ID: BCBT42B
Rev: 1.11
Local Control
KVM: Yes
Media Tray: Yes
SCOD: Unknown
Power On Time: 5 days 20 hours 35 min 12 secs
Number of Boots: 3

list
Syntax list -T target <-l depth>
Description (JCS management module CLI) List devices on the JCS1200 platform. This information
is useful for determining how many Routing Engines and JCS management modules are
installed and which JCS management module is primary.
Options -T target—Specify a command target. Valid targets for this command include:

• system:blower[x]—Specify a JCS fan (blower) as the command target.

• system:power[x]—Specify a JCS power module as the command target. Replace x

with the power module number (1 through 4).

with the switch number (1 or 2).
If no command target is specified, all devices on the JCS1200 platform are listed.
-l depth—(Optional) List a hierarchy of devices (starting with the device specified as the
command target). Replace depth with one of the following values:
• 2 | all | a—List the full hierarchy of devices (starting at the command target level). You
can enter a as an abbreviation for all.
• 1—List the command target only.

Level
Related • Displaying a List of Components on page 205

Documentation
List of Sample Output list (All) on page 222
list (All) system> list -l a
mm[1] primary
mm[2] standby
power[1]
power[2]
power[3]
power[4]

blower[1]
blower[2]
blower[3]
blower[4]
switch[1]
switch[2]
blade[1] bcgcpu1
sp
cpu[1]
blade[3] bcgcpu3
sp
cpu[1]
blade[4] bcgcpu4
sp
cpu[1]
blade[5] bcgcpu5
sp
cpu[1]
blade[6] bcgcpu6
sp
cpu[1]
mt[1]
mt[2]
tap
mux[1]
mux[2]

power
Syntax power -T target (-on | -off | -cycle | -state)
Description (JCS management module CLI) Power on or power off a specified Routing Engine (blade)
or JCS switch module. Alternatively, display the power setting for a specified Routing
Engine or switch module.
Options -T target—Specify the target of the power command. Valid targets for this command are:


-on—Turn on the specified Routing Engine or JCS switch module.
-off—Turn off the specified Routing Engine or JCS switch module.
-cycle—Cycle power for the specified Routing Engine or JCS switch module. If the Routing
Engine or JCS switch module is off, it will turn on. If the Routing Engine or JCS switch
module is on, it will turn off.
-state—Display the current power state (on or off) for the specified Routing Engine or
JCS switch module.

Level
Related • reset on page 227

Documentation
List of Sample Output power (On) on page 224

power (Cycle) on page 224
power (State) on page 224
power (On) system> power –T system:switch[1] —on
OK
power (Cycle) system> power –T system:switch[1] —cycle
Off
power (State) system> power –T system:blade[3] —state
On


read
Syntax read -config chassis -T system:mm[x]
Description (JCS management module CLI) Restore the JCS management module configuration
from an image previously saved to the JCS chassis with the write command. This
command is useful for restoring a backup copy of the JCS management module
configuration.
Options -config chassis—Specify the location within the chassis from which the configuration is
restored.
-T system:mm[x]—Specify the management module as the target of the command (the

configuration to be saved). Replace x with a value of 1 or 2.
-config file (-i, -l, -p)—Specify the location outside the chassis and the name of the file
from which the configuration is restored.
-i—Specify the IP address of the TFTP server where the configuration file is located.
-l—Specify the file name of the configuration file to read(the default filename is asm.cfg).
-p—Specify the quote-delimited passphrase that is required when saving to a file with
encryption enabled (passphrases have a maximum of 1600 chars).

Level
Related • write on page 233

Documentation
List of Sample Output read on page 226
read system> read —config chassis –T system:mm[1]

OK
Configuration restore from the chassis was successful.
Restart the MM for the new settings to take effect.
When you enter this command, the amm.cfg file will be loaded from the TFTP server
that corresponds with the IP address you entered.
system> read -T mm[1] -config file -i 172.17.59.183 -l amm.cfg

reset
Syntax reset -T target
Description (JCS management module CLI) Reset a specified Routing Engine (blade), JCS switch
module, or JCS management module.
Options -T target—Specify the target of the reset command. Valid targets for this command are:




Level

Documentation
List of Sample Output reset (Switch) on page 227
reset (Switch) system> reset –T system:switch[2]

OK

shutdown
Syntax shutdown -f -T system:blade[x]
Description (JCS management module CLI) Shut down the operating system on the Routing Engine
(blade).
Options -T system:blade[x]—Specify a Routing Engine as the target of the command (the Routing
Engine to be shut down). Replace x with a value of 1 through 12.
-f—Force the operating system on the Routing Engine to shut down.

Level

Documentation
List of Sample Output shutdown on page 228
shutdown system> shutdown -f -T system:blade[6]

OK

temps
Syntax temps -T target
Description (JCS1200 platform only) Show temperature information (in degrees Fahrenheit) for
components in the JCS chassis. This information is useful for viewing current temperature
values and temperature threshold settings.
Options -T target—Specify the target of the temps command. Valid targets for this command are:




Level
Related • Displaying Temperature Information on page 206

Documentation
List of Sample Output temps (Routing Engine) on page 229

temps (JCS Management Module) on page 230
Output Fields Table 27 on page 229 lists the output fields for the temps command. Output fields are
Table 27: temps Output Fields

Value Current temperature (in degrees Fahrenheit) of the component.
Warning Temperature at which a warning message occurs.
Reset Temperature at which the component will reset.
Hysteresis The amount the temperature must decrease below the Warning
threshold before the warning is cleared.
temps (Routing system> temps -T system:blade[3]

Engine) Component Value Warning Reset Hysteresis
CPU1 38.00 85.00 95.00 (7.00)
CPU2 35.00 85.00 95.00 (7.00)

temps (JCS system> temps -T system:mm[2]

Management Module) Component Value Warning Reset Hysteresis
MM Ambient 43.00 60.00 55.00 (5.00)

volts
Syntax volts -T target
Description (JCS1200 platform only) Show voltage information for components in the JCS chassis.
This information is useful for viewing current voltage values and voltage threshold settings.
Options -T target—Specify the target of the volts command. Valid targets for this command are:




Level
Related • Displaying Voltage Information on page 207

Documentation
List of Sample Output volts (JCS Management Module) on page 231

volts (Routing Engine) on page 232
Output Fields Table 28 on page 231 lists the output fields for the volts command. Output fields are listed
Table 28: volts Output Fields

Source Total voltage available from the voltage source.
Value Current voltage of the component.
Warning Voltage at which a warning message occurs.
Reset Voltage at which the component will reset.
Hysteresis The amount the voltage must decrease below the Warning threshold
before the warning is cleared.
volts (JCS system> volts -T system:mm[1]

Management Module)
Source Value Warning Reset Hysteresis
+5v +4.84 (+4.50,+5.25) (+4.85,+5.15) (+0.35,+0.10)
+3.3v +3.26 (+3.00,+3.47) (+3.20,+3.40) (+0.20,+0.07)

+12v +12.03 (+10.80,+12.60) (+11.64,+12.36) (+0.84,+0.24)

–5v —4.90 (-5.50,–4.75) (-5.15,-4.85) (+0.35,+0.10)
+2.5v +2.48 (+2.25,+2.63) (+2.42,+2.58) (+0.17,+0.05)
+1.8v +1.76 (+1.62,+1.89) (+1.74,+1.86) (+0.12,+0.03)
volts (Routing Engine) system> volts -T system:blade[5]
Source Value Warning

1.8 V Sense +1.79 (+1.61,+1.97)
1.8VSB Sense +1.83 (+1.61,+1.97)
12V Sense +12.33 (+10.79,+13.21)
12VSB Sense +12.30 (+10.74,+13.19)
3.3V Sense +3.31 (+2.96,+3.62)
5V Sense +5.06 (+4.39,+5.48)

write
Syntax write -config chassis -T system:mm[x]
Description (JCS management module CLI) Save the management module configuration to the
chassis of the JCS1200 platform (in the midplane NVRAM). This command is useful for
creating a backup copy of the JCS management module configuration.
Options -config chassis—Specify the location within the chassis where the configuration is saved.
-T system:mm[x]—Specify the JCS management module as the target of the command

(the configuration to be saved). Replace x with a value of 1 or 2.
-config file (-i, -l, -p)—Specify the name of the configuration file and location where it is
saved outside the chassis.
-i—Specify the IP address of TFTP server to save the configuration file to.
-l—Specify an optional filename to save the configuration file as (the default filename
is asm.cfg).
-p—Specify the quote-delimited passphrase that is required when saving to a file with
encryption enabled (passphrases have a maximum of 1600 chars).

Level
Related • read on page 226

Documentation
List of Sample Output write on page 233
write system> write —config chassis –T system:mm[1]
OK
Configuration settings were successfully saved to the chassis.
When you enter this command, the configuration file will be named “amm.cfg” and saved
on the TFTP server at 172.17.59.183.
system> write -T mm[1] -config file -i 172.17.59.183 -l amm.cfg


PART 7
Managing RSDs and PSDs

• Managing the Junos OS on page 237


CHAPTER 17
Managing the Junos OS

• Displaying Hardware Information on page 238
• Displaying Configured PSDs on page 241
• Displaying Routing Engine Information on page 242
• Displaying Ethernet Switch Statistics on page 244
• Displaying Shared Interface Information on page 245
• Displaying Inter-PSD Forwarding Information on page 249
Logging In to a PSD from the RSD
As a Root System Domain (RSD) administrator, if you have the appropriate access
privileges, you can log in to a Protected System Domain (PSD) from the Junos OS
command-line interface (CLI) on the RSD:
user@rsd> request routing-engine login (psd n| rsd) (re0 | re1)
The PSD being accessed must be specified under the RSD configuration.
In the following example, the RSD administrator logs in to the master Routing Engine on
PSD1:
{master}
user@rsd> request routing-engine login psd 1 re0

€login: regress
Password:
--- JUNOS 9.1-20080321.0 built 2008-03-21 05:43:06 UTC

% cli
user@psd1>

Documentation

Junos OS Verification Tasks
Table 29 on page 238 lists tasks that are commonly used to verify information that is
specific to RSDs and PSDs.
Table 29: Commands Used to Verify PSD and RSD Status

Hardware ownership Display information about “Displaying Hardware Information”

hardware that is owned by the RSD, on page 238
owned by the PSD, or shared by
both.
Configured PSDs Display PSDs configured under the “Displaying Configured PSDs” on
RSD. page 241
Routing Engine information Display Routing Engine information. “Displaying Routing Engine
Information” on page 242
Ethernet switch statistics Display information about the “Displaying Ethernet Switch
receive and transmit packets Statistics” on page 244
traveling between PSDs and the
respective RSD.
Shared interfaces Display information about shared “Displaying Shared Interface

interfaces. Information” on page 245

Documentation
• JCS Management Module Verification Tasks on page 199
Displaying Hardware Information

Purpose On the RSD, you can use the show chassis hardware command to display all hardware
on the T Series router (without reference to which FPCs belong to a particular PSD).
On the PSD, you can display information about the Routing Engines, FPCs, and PICs that
are assigned to the PSD and about hardware that is shared with the RSD, such as Switch
Interface Boards (SIBs), the Switch Processor Mezzanine Board (SPMB), Power Entry
Modules (PEMs), and fans.
Action Display hardware information using the show chassis hardware command.
On the RSD The following example provides output from the show chassis hardware command issued
from the RSD.
user@rsd> show chassis hardware

Chapter 17: Managing the Junos OS
Hardware inventory:
Chassis S19068 T640
Routing Engine 1
CPU REV 05 710-010169 HX8637 FPC CPU-Enhanced
PIC 0 REV 05 750-007141 HG2427 10x 1GE(LAN), 1000 BASE
Xcvr 1 REV 01 740-011613 P9F15ZN SFP-SX

Xcvr 2 REV 01 740-011613 P9F11CC SFP-SX
Xcvr 3 REV 01 740-011613 P9F1AM1 SFP-SX
PIC 1 REV 01 750-004695 HD5978 1x Tunnel
PIC 2 REV 03 750-003336 HJ9956 4x OC-48 SONET, SMSR
FPC 1 REV 02 710-005553 HJ9012 FPC Type 2
CPU REV 06 710-001726 HF6882 FPC CPU
PIC 0 REV 03 750-001900 AA9622 1x OC-48 SONET, SMIR
PIC 1 REV 02 750-007219 AZ1337 2x OC-12 ATM-II IQ, MM
MMB 1 REV 01 710-005555 AZ2106 MMB-288mbit
Xcvr 2 REV 01 740-011782 P86218N SFP-SX
Xcvr 3 REV 01 740-011613 P8E2SSW SFP-SX
PIC 1 REV 11 750-007745 CH6343 4x OC-3 SONET, SMIR
CPU REV 06 710-001726 HB1916 FPC CPU
PIC 0 REV 02 750-002510 BD5129 2x G/E, 1000 BASE-SX
PIC 2 REV 13 750-001901 HB4004 4x OC-12 SONET, SMIR
PIC 3 REV 07 750-003737 HW5514 4x G/E, 1000 BASE-SX
FPC 5 REV 01 710-010233 HM4187 E-FPC Type 1
CPU REV 01 710-010169 HS9939 FPC CPU-Enhanced
PIC 0 REV 04 750-001894 HA9485 1x G/E, 1000 BASE-SX
PIC 1 REV 08 750-001072 AB1688 1x G/E, 1000 BASE-SX
PIC 2 REV 03 750-000603 AC2769 4x OC-3 SONET, SMIR

PIC 3 REV 21 750-005634 WD3292 1x CHOC12 IQ SONET, SMIR
MMB 1 REV 01 710-010171 HR0833 MMB-288mbit

CPU REV 05 710-010169 JE4403 FPC CPU-Enhanced
PIC 1 REV 07 750-001900 AT1593 1x OC-48 SONET, SMSR
PIC 2 REV 08 750-012063 CY3670 2x G/E IQ, 1000 BASE
Xcvr 1 REV 01 740-011782 P8Q25X3 SFP-SX
MMB 1 REV 04 710-010171 JC1211 MMB-5M3-288mbit
FPC 7 REV 05 710-010157 HR5838 E-FPC Type 2
CPU REV 01 710-010169 HN3431 FPC CPU-Enhanced
PIC 0 REV 07 750-010618 WE2402 4x G/E SFP, 1000 BASE
Xcvr 0 REV 01 740-011613 P8E2VZ7 SFP-SX
Xcvr 1 0 NON-JNPR AM06333AW4 SFP-SX
Xcvr 2 REV 01 740-011782 P9M0TSP SFP-SX
Xcvr 3 REV 01 740-011613 P9F11Y0 SFP-SX
PIC 3 REV 11 750-001901 HC4722 4x OC-12 SONET, SMIR
MMB 1 REV 01 710-010171 HN6495 MMB-288mbit
SIB 0 REV 05 750-005486 HV8445 SIB-I8-F16
SIB 1 REV 05 750-005486 HW2650 SIB-I8-F16
SIB 2 REV 05 750-005486 HW7041 SIB-I8-F16
SIB 3 REV 05 750-005486 HV4274 SIB-I8-F16
SIB 4 REV 05 750-005486 HV8464 SIB-I8-F16
On the PSD The following example provides output from the show chassis hardware command issued
from a PSD.

rsd-re0:
--------------------------------------------------------------------------
Hardware inventory:
Chassis S19068 T640
Routing Engine 1
FPC 1 REV 02 710-005553 HJ9012 FPC Type 2
CPU REV 06 710-001726 HF6882 FPC CPU
PIC 1 REV 02 750-007219 AZ1337 2x OC-12 ATM-II IQ, MM
MMB 1 REV 01 710-005555 AZ2106 MMB-288mbit


Xcvr 2 REV 01 740-011782 P86218N SFP-SX
Xcvr 3 REV 01 740-011613 P8E2SSW SFP-SX
PIC 1 REV 11 750-007745 CH6343 4x OC-3 SONET, SMIR
CPU REV 06 710-001726 HB1916 FPC CPU
PIC 0 REV 02 750-002510 BD5129 2x G/E, 1000 BASE-SX
PIC 3 REV 07 750-003737 HW5514 4x G/E, 1000 BASE-SX
SIB 0 REV 05 750-005486 HV8445 SIB-I8-F16
SIB 1 REV 05 750-005486 HW2650 SIB-I8-F16
SIB 2 REV 05 750-005486 HW7041 SIB-I8-F16
SIB 3 REV 05 750-005486 HV4274 SIB-I8-F16
SIB 4 REV 05 750-005486 HV8464 SIB-I8-F16
psd1-re0:
--------------------------------------------------------------------------
Hardware inventory:
Meaning On the RSD, information about all the FPCs in the chassis (which are located in slots 1,
2, and 4 through 7) is displayed.
On the PSD, at the beginning of the output, the rsd-re0 field displays all of the information
pertaining to the components on the T Series router that are assigned to or shared by
the PSD. For example, only information about the FPCs in slots 1, 2, and 4 is displayed.
At the end of the output, the psd1-re0: field provides information about the JCS1200
chassis and the Routing Engines assigned to PSD1.

Documentation
Displaying Configured PSDs

Purpose The RSD administrator can use the show chassis psd command to view which PSDs are
configured within the RSD.

Action From the RSD, issue the show chassis psd command as shown in the following example:
{master}
user@rsd> show chassis psd

Meaning Two PSDs are configured under the RSD: PSD1 and PSD2. Both are online.

Documentation
Displaying Routing Engine Information

Purpose Display information about the Routing Engines that are part of the RSD or PSD.
Action Display information about the Routing Engines that are part of the RSD or PSD using the
show chassis routing-engine command.
On the RSD When the show chassis routing-engine command is issued on the RSD, the Slot field
indicates the slot on the T Series router that holds the Routing Engine. In the following
example, the master Routing Engine is in slot 0, whereas the backup Routing Engine is
in slot 1.
user@rsd1> show chassis routing-engine

Slot 0:
Temperature 58 degrees C / 136 degrees F
CPU temperature 69 degrees C / 156 degrees F
DRAM 14336 MB
CPU utilization:
User 0 percent
Kernel 2 percent
Interrupt 0 percent
Idle 97 percent
Model RE-A-2000
Serial ID 1000688682
Start time 2008-08-20 12:03:50 PDT
Last reboot reason Router rebooted after a normal shutdown.
0.89 0.21 0.07
Slot 1:
Temperature 55 degrees C / 131 degrees F
CPU temperature 63 degrees C / 145 degrees F
DRAM 14336 MB
CPU utilization:
User 0 percent

Kernel 0 percent
Interrupt 0 percent
Idle 99 percent
Model RE-A-2000
Serial ID 1000688746
Start time 2008-08-07 18:37:53 PDT
Last reboot reason 0x1:power cycle/failure
On the PSD When the show chassis routing-engine command is issued on the PSD, the Physical Slot
field indicates the slot on the JCS platform that holds the Routing Engine. In the following
example, psd2 owns the Routing Engines in slots 5 and 6 in the JCS chassis. The master
Routing Engine is in slot 6, whereas the backup Routing Engine is in slot 5.

Slot 0:
Physical Slot 6
DRAM 13312 MB
CPU utilization:
User 0 percent
Kernel 0 percent
Interrupt 0 percent
Idle 99 percent
Start time 2008-03-13 06:36:07 PDT
Slot 1:
Physical Slot 5
DRAM 13312 MB
CPU utilization:
User 0 percent
Kernel 0 percent
Interrupt 1 percent
Idle 99 percent
Start time 2008-03-12 23:39:21 PDT
0.00 0.00 0.00

Documentation

Displaying Ethernet Switch Statistics

Purpose On the PSD, display information about receive and transmit packets traveling between
the RSD and the PSDs configured under it.
Action Display information about receive and transmit packets traveling between all PSDs and
the RSD using the show chassis ethernet-switch command. In the following sample
output:
• INT6 provides the internal connection between the master Routing Engine in slot 6
and the JCS switch module.
• EXT1 provides the connection between each JCS switch module (switch[1] and
switch[2]) and the RSD.
• EXT6 provides the connection between each JCS switch module (switch[1] and
switch[2]) and the management ports on each Routing Engine in the JCS chassis.
user@psd2>show chassis ethernet-switch statistics

Tx Discards 0
TX Errors 0
RX Discards 5555
RX Errors 0
Tx Discards 0
TX Errors 0
RX Discards 9
RX Errors 54
TX Octets 642418689
Tx Discards 0
TX Errors 0


RX Discards 9452
RX Errors 96
Tx Discards 0
TX Errors 0
RX Octets 394133602
RX Discards 6331
RX Errors 0
Tx Discards 0
TX Errors 0
RX Octets 590077798
RX Discards 10
RX Errors 38
TX Octets 90557831
Tx Discards 0
TX Errors 2
RX Errors 3081169
Related • Connections Between JCS1200 and T Series Chassis on page 11

Documentation
Displaying Shared Interface Information

Purpose Display information about shared interfaces.

Action Using the show interfaces so-fpc/pic/slot or show interfaces ge-fpc/pic/slot command,
display logical interfaces configured on a shared physical interface.
The following fields in the output from the command display information about shared
interfaces:
• Shared-interface—Located under the Physical interface: section of the output, this field
indicates whether the routing domain is the owner or non-owner of the shared interface.
If the routing domain is the RSD, the value is Owner. If the routing domain is a PSD
under the RSD, the value is Non-owner.
• Shared interface—Located under the Logical interface: section of the output, this section
includes these fields:
• shared with—(RSD only) Provides the identity of the PSD that owns the shared
interface; for example, psd3.
• peer interface—(PSD only) Lists the logical tunnel interface that peers with the logical
interface; for example, ut-2/1/0.2.
• tunnel token—Specifies the receive (RX) and transmit (TX) tunnel tokens. For
example, Rx: 5.519, Tx: 13.514.
NOTE: When you issue this command on the PSD for SONET interfaces, the
following information about the physical interface is not provided:
• Media status
• Frame Relay LMI counters
• SONET mode
On the RSD (SONET In the following sample output, rsd1 is the owner of the physical SONET interface so-7/2/0
Interface) and the logical SONET interface so-7/2/0.0 is shared by psd5.
user@rsd1> show interfaces so-7/2/0

Physical interface: so-7/2/0, Enabled, Physical link is Down
Link-level type: Frame-Relay, MTU: 4474, Clocking: Internal, SONET mode,
Speed: OC192, Loopback: None, FCS: 16, Payload scrambler: Enabled
Device flags : Present Running Down
Interface flags: Hardware-Down Point-To-Point SNMP-Traps Internal: 0x4000
LMI: Input: 0 (never), Output: 0 (never)
DTE statistics:
Enquiries sent : 0
Full enquiries sent : 0
Enquiry responses received : 0
Full enquiry responses received : 0
DCE statistics:
Enquiries received : 0
Full enquiries received : 0

Enquiry responses sent : 0

Full enquiry responses sent : 0
Common statistics:
Unknown messages received : 0
Asynchronous updates received : 0
Out-of-sequence packets received : 0
Keepalive responses timedout : 0
Last flapped : 2008-08-11 10:51:51 PDT (1w1d 04:47 ago)
SONET alarms : LOL, PLL
SONET defects : LOL, PLL, LOF, SEF, AIS-L, AIS-P

Shared interface:
Shared with: psd5
Input packets : 0
Output packets: 0
DLCI 700
Flags: Active
Input packets : 0
Output packets: 0
DLCI statistics:
On the PSD (SONET The following sample output shows that so-0/3/0 is not owned by the PSD. The logical
Interface) SONET interface so-0/3/0.0 is configured on a shared physical interface and ut-1/0/0.0
is its peer tunnel interface.


Shared interface:
Input packets : 9
Output packets: 10
DLCI 16
Flags: Active


Input packets : 9
Output packets: 10
DLCI statistics:
On the RSD (Gigabit In the following sample output, rsd1 is the owner of the physical Gigabit Ethernet interface
Ethernet Interface) so-7/2/0, and the logical Gigabit interface so-7/2/0.0 is shared by psd5.
user@rsd1> show interfaces ge-7/2/0


Shared-interface:
Shared with: psd5
Input packets : 0
Output packets: 0
Flags: None
On the PSD (Gigabit The following sample output shows that ge-0/3/0 is not owned by the PSD. The logical
Ethernet Interface) SONET interface ge-0/3/0.0 is configured on a shared physical interface and ut-1/0/0.0
is its peer tunnel interface.

Physical interface: ge-0/3/0 Enabled, Physical link is Down
Link-level type: Ethernet, MTU: 1518, Speed: 1000mbps, BPDU Error: None,
Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
Current address: 00:17:cb:25:48:40, Hardware address: 00:17:cb:25:48:40

Flags: Link-Layer-Down Device-Down SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.101 ]
Encapsulation: ENET2
Shared-interface:
Tunnel token: Rx: 14.538
Input packets : 13
Output Filters: filter-safari
Protocol inet6, MTU: 1500

Flags: None
Destination: 1000::173:16:0:0/96, Local: 1000::173:16:254:1
Addresses, Flags: Dest-route-down Is-Preferred
Destination: fe80::/64, Local: fe80::217:cb00:6525:4840
Flags: None

Documentation
Displaying Inter-PSD Forwarding Information

Purpose Display information about inter-PSD forwarding.
Action Using the show interfaces xt-fpc/pic/slot command, display logical interfaces configured
on the cross-connect interface. In the following example, the interface type is
Inter-PSD-tunnel and there is one logical interface (xt-5/0/0.1).
user@psd2> show interfaces xt-5/0/0

Physical interface: xt-5/0/0, Enabled, Physical link is Up
Type: Inter-PSD-tunnel, Link-level type: Inter-PSD-tunnel, MTU: Unlimited,
Speed: 12800mbps
Interface flags: Point-To-Point SNMP-Traps
Link type : Full-Duplex
Link flags : None
Physical info : 13
Logical interface xt-5/0/0.1 (Index 71) (SNMP ifIndex 645)

Flags: Point-To-Point SNMP-Traps 0x4000 DLCI 1 Encapsulation: FR-NLPID
Input packets : 0
Protocol inet, MTU: Unlimited
Destination: 10.0.0.2, Local: 10.0.0.1

Related • Configuring Inter-PSD Forwarding on a PSD on page 108

Documentation

PART 8
Appendix
• Troubleshooting on page 253
• Glossary on page 255


APPENDIX A
Troubleshooting
• Troubleshooting a Routing Engine on the JCS1200 Platform on page 253

• Restarting a Routing Engine on the JCS1200 Platform on page 254
Troubleshooting a Routing Engine on the JCS1200 Platform

Problem You cannot run the Junos OS on a Routing Engine on the JCS1200 platform and you
cannot reload the software using the Junos OS CLI.
Solution Manually load the Junos OS on the Routing Engine in the JCS chassis using the media
tray.
NOTE: This procedure requires that you issue commands on the JCS
management module CLI and to interactively respond to prompts from the
Junos OS through a console port session on the Routing Engine.
CAUTION: When you manually reload the Junos OS, the hardware disk and
CompactFlash card are erased.
To manually load the Junos OS on a specific Routing Engine in the JCS chassis:
1. Obtain the Junos OS package from the Juniper Networks support Web site and transfer
the software onto a USB device. For more information, contact your Juniper Networks
support representative.
2. Insert the USB device with the Junos OS into either USB port on the media tray on the
JCS chassis.
3. To select the Routing Engine, either press the CD button on the Routing Engine or
issue the following command using the JCS management module CLI. In this example,
the Routing Engine to be reloaded is in slot 1 on the JCS chassis.
system> mt -b 1

4. To restart the Routing Engine and begin loading the software, issue the following
command:
system> reset -T blade[1]
5. Type y and press Enter when the system issues the following prompt during the console
session on the Routing Engine:
WARNING: The installation will erase the contents of your disks. Do you
wish to continue (y/n)?
6. When the system issues the following prompt on the console port session:
Eject the installation media and Hit [Enter] to reboot?
a. Using the JCS management module, issue the following command to deselect the
media tray:
system> mt -b 0
b. On the console port session on the Routing Engine, press Enter to reboot the system.
7. When the system has rebooted, log in as root with no password:
Amnesiac (ttyd0)
Login: root
8. You can now load an existing configuration file onto the Routing Engine or configure
the system with basic system properties.
Related • Configuring a PSD with a Single Routing Engine on page 87

Documentation
Restarting a Routing Engine on the JCS1200 Platform

Problem A Routing Engine on the JCS1200 Platform is not responding.
Solution Manually restart the Routing Engine.
• From the PSD, you can use the restart chassis-control command (or the restart
jcs-control command) in the Junos OS CLI to restart the Routing Engine. For example:
user@host> restart chassis-control gracefully
• From the JCS management module, you can use the reset command in the JCS
management module CLI to restart the Routing Engine. For example:
system> reset -T blade[1]

Glossary
B
blade bay data (BBD) 60-byte text string stored in the JCS management module NVRAM that conveys configuration
information to the Routing Engines (blades) in the JCS chassis.
F
Flexible PIC Interface concentrator on which PICs are mounted. An FPC is inserted into a slot in a Juniper
Concentrator (FPC) Networks router. See also PIC.
I
inter-PSD forwarding A configuration that enables PSDs on the JCS1200 platform to communicate on a peer-to-peer
basis without requiring external links. Inter-PSD forwarding is achieved by using tunnel PICs
that reside on each PSD. The PSDs communicate over logical interfaces configured on the
tunnel PICs.
J
JCS management Chassis management hardware and software included used to access and configure the
module (MM) Juniper Control System (JCS) platform.
JCS switch module Hardware device that connects Routing Engines in the Juniper Control System (JCS) chassis
to a Juniper Networks router and controls traffic between the two devices. For redundancy,
the JCS chassis can include two JCS switch modules.
Juniper Control System OEM blade server customized to work with Juniper Networks routers. The JCS chassis holds
(JCS) up to 12 single Routing Engines (or 6 redundant Routing Engine pairs). The JCS1200 chassis
connects to up to three T Series routers, enabling the control plane and forwarding plane of
a single interconnected platform to be scaled independently.
P
PIC Physical Interface Card. A network interface-specific card that can be installed on an FPC in
the router.
Protected System One or more Flexible PIC Concentrators (FPCs) on a Juniper Networks router matched with a
Domain (PSD) Routing Engine (or redundant pair) on the JCS1200 platform to form a secure, virtual hardware
router.

R
Root System Domain A pair of redundant Routing Engines on a Juniper Networks router connected to the switch
(RSD) fabric on the Juniper Control System (JCS) platform. The configuration on the Routing Engines
on a single Juniper Networks router provides the RSD identification and the configuration of
up to eight Protected System Domains (PSDs).
S
shared interface A physical interface that is owned by the Root System Domain (RSD) on which logical interfaces
can be shared by multiple Protected System Domains (PSDs). Each individual logical interface
is assigned to a different PSD. On the PSD, each assigned logical interface is configured and
peered with an uplink tunnel interface (ut-fpc/pic/slot), which transports packets between
the PSD and the shared interface on the RSD.

PART 9
Indexes
• Index on page 259
• Index of Statements and Commands on page 265


Index
clearlog command.................................................................211
Symbols usage guidelines..........................................................202
-h shortcut for CLI help.........................................................25 cli command.....................................................................87, 89
-T option clock command.......................................................................59
JCS management module CLI..................................26 usage guidelines.............................................................43
? shortcut for CLI help...........................................................25 command targets
[edit chassis system domains] hierarchy......................83 defined...............................................................................25
[edit interfaces] hierarchy..........................................93, 107 for JCS1200 platform....................................................26
commit command.................................................................88
A commit synchronize command........................................90
access privileges committing configuration changes.........................88, 90
PSD.....................................................................................20 config command....................................................................60
RSD.......................................................................................19 usage guidelines
accessing blade name..............................................................52
JCS1200 platform...........................................................23 system information..............................................43
RSD........................................................................................4 configure command.......................................................87, 89
adding public key for SSH...................................................46 contact information, configuring......................................43
address statement.................................................................99 control-plane-bandwidth-percent statement...........113
alertentries command..........................................................54 usage guidelines............................................................84
usage guidelines.............................................................44 control-slot-numbers statement.....................................114
apply-groups statement.....................................................90 usage guidelines.............................................................85
control-system-id statement............................................115
B usage guidelines............................................................84
backing up a configuration...........................................89, 91 CoS
backup router IP address, configuring....................88, 90 shared interfaces.........................................................104
backup-router statement............................................88, 90 customer support.................................................................xxiii
bandwidth allocation, PSDs...............................................84 contacting JTAC............................................................xxiii
baydata command................................................................56
usage guidelines.............................................................52 D
blade bay data data-link connection identifier See DLCI
configuring.........................................................................51 default command target for JCS management
format requirements......................................................51 module....................................................................................25
blade name, configuring.......................................................52 default configuration
boot command......................................................................210 restoring on JCS management module................40
description statement..........................................................115
C usage guidelines............................................................84
CIP port (Connector Interface Panel)...............................11 displaylog command............................................................212
class of service See CoS usage guidelines..................................................46, 203
clear command.......................................................................58 DLCI..............................................................................................95
usage guidelines............................................................40

dlci statement graceful Routing Engine switchover

shared interfaces overview.............................................................................27
PSD............................................................................98 graceful Routing Engine switchover,
RSD............................................................................96 configuring............................................................................90
DNS server IP address, configuring...........................88, 91
documentation H
comments on................................................................xxiii hardware components
domain name, configuring...........................................87, 90 JCS1200 platform............................................................21
domain-name statement............................................87, 90 health command...................................................................216
usage guidelines..........................................................204
E help command........................................................................64
encapsulation frame-relay statement usage guidelines.............................................................24
shared interfaces history command..................................................................218
RSD.............................................................................95 host key for SSH, generating..............................................46
entering Junos OS configuration mode..................87, 89 host-name statement...................................................87, 90
env command..........................................................................62 hostname, configuring..................................................87, 90
usage guidelines.............................................................26
Ethernet interface I
configuring on JCS management module...........40 icons defined, notice............................................................xxiii
configuring on JCS switch module...........................41 ifconfig command
Ethernet management interfaces JCS management module..........................................65
configuring on PSD...............................................88, 90 JCS switch module........................................................67
Ethernet switch statistics, displaying.............................191 usage guidelines......................................................40, 41
event log, clearing................................................................202 info command........................................................................219
event log, displaying............................................................203 usage guidelines..........................................................200
exit command..................................................................63, 88 inter-PSD forwarding
exiting Junos OS configuration mode.............................88 configuring
external LAN connections....................................................12 PSD...........................................................................108
defined..................................................................................8
F interface-shared-with statement....................................116
family statement....................................................................98 usage guidelines............................................................96
fan modules, description......................................................23 interfaces statement (Gigabit Ethernet)
firewall filters, on shared interfaces...............................102 shared interfaces
Flexible PIC Concentrators See FPCs RSD.............................................................................95
FPCs interfaces statement (management ports)........88, 90
assigning to a PSD........................................................84 interfaces statement (SONET)
fpcs statement........................................................................116 shared interfaces
usage guidelines............................................................84 PSD.............................................................................97
Frame Relay encapsulation RSD.............................................................................95
shared interfaces interfaces statement (uplink tunnel)
RSD.............................................................................95 shared interfaces
fuelg command......................................................................214 PSD............................................................................99
usage guidelines..........................................................203 interfaces statement (XFP)
fxp0 interface, configuring..........................................88, 90 shared interfaces
fxp1 interface, configuring...........................................88, 90 RSD.............................................................................95
internal LAN connections......................................................12
G
generating host key for SSH...............................................46 J
JCS administration view.........................................................17

Index
JCS management module L

blade bay data, configuring.........................................51 list command...............................................................205, 222
CLI loopback interface address, configuring.......................90
overview....................................................................23
syntax conventions...............................................25 M
configuring........................................................................33 management interfaces, configuring......................88, 90
contact information, configuring.............................43 management tasks
default configuration, restoring................................40 JCS1200 platform........................................................199
description........................................................................22 PSD.....................................................................................20
Ethernet interface, configuring.................................40 RSD.......................................................................................19
NTP server, configuring................................................42 manually loading Junos OS .............................................253
SNMP community, configuring.................................44 manuals
SNMP monitored alerts, configuring......................45 comments on................................................................xxiii
SNMP trap alert recipients, configuring................44 maximum transmission unit size See MTU size
SNMP traps, configuring.............................................43 media tray
SSH copying Junos OS............................................................71
host key, generating.............................................46 description........................................................................22
public key, adding.................................................46 manually loading Junos OS.....................................253
system name, configuring..........................................43 monalerts command............................................................69
time zone, configuring..................................................43 usage guidelines.............................................................45
user accounts, configuring..........................................42 mt command.............................................................................71
verification tasks..........................................................199 MTU size.....................................................................................95
JCS media tray See media tray
JCS switch module N
configuration scripts.....................................................26 name-server statement................................................88, 91
configuring........................................................................47 network consolidation
description........................................................................22 configuration example................................................177
Ethernet interface, configuring..................................41 described............................................................................13
JCS users network interface
operator..............................................................................18 configuring on JCS management module...........40
supervisor..........................................................................18 ntp command...........................................................................72
JCS1200 platform usage guidelines.............................................................42
default hardware configuration.................................21 NTP server
hardware components..................................................21 JCS management module, configuring.................42
managing........................................................................199 JCS switch module, configuring................................47
software components..................................................23
Juniper Networks JCS1200 Control System See O
JCS1200 operator security role.............................................................42
Junos OS
copying to the Routing Engine on JCS P
peer-interface statement.....................................98, 99, 117
chassis.............................................................................71
peer-psd statement...............................................................117
loading, manually........................................................253
PEMs, shared hardware.................................................19, 20
PSD configuration..........................................................87
power command..................................................................224
RSD configuration.....................................................4, 84
Power Entry Modules See PEMs
Junos OS CLI
power information, displaying.........................................203
interfaces hierarchy..............................................93, 107
power supply modules, description.................................22
system domains hierarchy.........................................83
Protected System Domains See PSDs

protected-system-domains statement........................118 S
usage guidelines............................................................84 shared interfaces
PSD administration view......................................................19 benefits...............................................................................13
psd statement concepts..............................................................................6
usage guidelines............................................................84 configuring
PSDs CoS...........................................................................104
basic properties, configuring firewall filters.........................................................102
redundant Routing Engines..............................89 on the PSD...............................................................97
single Routing Engine..........................................87 on the RSD...............................................................95
benefits...............................................................................13 task overview..........................................................94
configuring........................................................................84 defined..................................................................................5
defined..................................................................................5 matching RSD and PSD parameters
displaying configured PSDs............................188, 242 DLCIs..........................................................................95
displaying hardware for.............................................189 Frame Relay encapsulation..............................95
displaying information.................................................20 logical unit numbers............................................95
Ethernet switch statistics, displaying....................191 MTU size...................................................................95
management tasks.......................................................20 VLAN IDs..................................................................95
VLAN tagging..........................................................95
R supported PICs..................................................................7
read command......................................................................226 supported platforms........................................................7
redundancy, configuring......................................................90 traffic flow...........................................................................6
request routing-engine login command......................237 tunnel PICs..........................................................................7
request system snapshot command.......................89, 91 shared-interface statement...............................................119
reset command.....................................................................227 usage guidelines............................................................98
restoring default configuration show chassis ethernet-switch command..................244
JCS management module.........................................40 show chassis ethernet-switch statistics
root password, configuring...........................................88, 91 command.............................................................................191
Root System Domain See RSD show chassis hardware command...............................238
root-authentication statement..................................88, 91 example...........................................................................189
root-domain-id statement.................................................119 show chassis psd command............................................242
usage guidelines............................................................84 example...........................................................................188
route reflection show chassis routing-engine command.....................242
defined..................................................................................8 example...........................................................................190
examples..........................................................................157 show interfaces (Gigabit Ethernet)...............................245
Routing Engines show interfaces (SONET/SDH)......................................245
blade data, configuring.................................................51 shutdown command..........................................................228
blade name, configuring..............................................52 SIBs, shared hardware...................................................19, 20
redundancy, configuring.............................................90 snmp command......................................................................74
RSD usage guidelines.............................................................44
configuring........................................................................84 SNMP community
defined..................................................................................4 configuring on JCS management module............44
management tasks........................................................19 configuring on JCS switch module...........................47
managing PSDs...........................................................238 SNMP monitored alerts, configuring...............................45
operational mode command options.................238 SNMP trap alert recipients
system information, displaying..................................19 configuring on JCS switch module...................44, 47
RSD administration view......................................................18 SNMP traps
configuring on JCS management module............43
configuring on JCS switch module...........................47

Index
software components VLAN tagging

JCS1200 platform...........................................................23 shared interfaces
SPMB, shared hardware................................................19, 20 RSD.............................................................................95
SSH vlan-tagging statement
adding public key...........................................................46 shared interfaces
configuring access.........................................................45 RSD.............................................................................95
sshcfg command.............................................................46, 76 voltage information, displaying.......................................207
starting Junos OS CLI.....................................................87, 89 volts command.............................................................207, 231
supervisor security role.........................................................42
support, technical See technical support W
Switch Interface Boards See SIBs write command.....................................................................233
Switch Processor Mezzanine Board See SPMB
system component list, displaying................................205
system component status, displaying.........................204
system connections.................................................................11
system name, configuring...................................................43
system views
defined.................................................................................17
JCS users
command targets..................................................18
login permissions...................................................18
PSD.......................................................................................19
RSD......................................................................................18
system-domains statement.............................................120
T
T-CBs (T Series Control Boards)........................................11
target path for JCS modules...............................................26
technical support
contacting JTAC............................................................xxiii
temperature information, displaying............................206
temps command.......................................................206, 229
time zone, configuring...........................................................43
troubleshooting a Routing Engine.................................253
U
unit statement
shared interfaces
PSD............................................................................98
RSD............................................................................96
user accounts, configuring..................................................42
users command.......................................................................78
JCS management module.........................................46
usage guidelines.............................................................42
V
virtual LAN identifier See VLAN ID
vital product data, displaying .........................................200
VLAN ID......................................................................................95


Index of Statements and Commands
A I
alertentries command..........................................................54 ifconfig command
apply-groups statement.....................................................90 JCS management module..........................................65
JCS switch module........................................................67
B info command........................................................................219
backup-router statement............................................88, 90 interface-shared-with statement....................................116
baydata command................................................................56 interfaces statement (management ports)........88, 90
boot command......................................................................210
L
C list command...............................................................205, 222
clear command.......................................................................58
clearlog command.................................................................211 M
cli command.....................................................................87, 89 monalerts command............................................................69
clock command.......................................................................59 mt command.............................................................................71
commit command.................................................................88
commit synchronize command........................................90 N
config command....................................................................60 name-server statement................................................88, 91
configure command.......................................................87, 89 ntp command...........................................................................72
control-plane-bandwidth-percent statement...........113
control-slot-numbers statement.....................................114 P
control-system-id statement............................................115 peer-interface statement.....................................98, 99, 117
peer-psd statement...............................................................117
D power command..................................................................224
description statement..........................................................115 protected-system-domains statement........................118
displaylog command............................................................212
domain-name statement............................................87, 90 R
read command......................................................................226
E request routing-engine login command......................237
env command..........................................................................62 request system snapshot command.......................89, 91
exit command..................................................................63, 88 reset command.....................................................................227
root-authentication statement..................................88, 91
F root-domain-id statement.................................................119
fpcs statement........................................................................116
fuelg command......................................................................214 S
shared-interface statement...............................................119
H show chassis ethernet-switch command..................244
health command...................................................................216 show chassis ethernet-switch statistics
help command........................................................................64 command.............................................................................191
history command..................................................................218 show chassis hardware command...............................238
host-name statement...................................................87, 90 show chassis psd command............................................242

show chassis routing-engine command.....................242

show interfaces (SONET/SDH)......................................245
shutdown command..........................................................228
snmp command......................................................................74
sshcfg command.............................................................46, 76
system-domains statement.............................................120
T
temps command.......................................................206, 229
U
users command.......................................................................78
V
volts command.............................................................207, 231
W
write command.....................................................................233

Config Guide PSD

Uploaded by

Copyright:

Available Formats

Config Guide PSD

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Config Guide PSD

Uploaded by

Copyright:

Available Formats

®

Copyright © 2011, Juniper Networks, Inc.

YEAR 2000 NOTICE

ii Copyright © 2011, Juniper Networks, Inc.

Copyright © 2011, Juniper Networks, Inc. iii

iv Copyright © 2011, Juniper Networks, Inc.

Copyright © 2011, Juniper Networks, Inc. v

Part 1 Product Overview

Part 2 Configuration Overview

Part 3 Configuring the JCS1200 Platform

Part 4 Configuring the Junos OS

Part 5 Configuration Examples

Part 6 Managing the JCS1200 Platform

Part 7 Managing RSDs and PSDs

Copyright © 2011, Juniper Networks, Inc. vii

viii Copyright © 2011, Juniper Networks, Inc.

Part 1 Product Overview

Copyright © 2011, Juniper Networks, Inc. ix

PSD Administration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Part 2 Configuration Overview

Part 3 Configuring the JCS1200 Platform

x Copyright © 2011, Juniper Networks, Inc.

Configuring the System Name and Contact Information . . . . . . . . . . . . . . . . 43

Part 4 Configuring the Junos OS

Copyright © 2011, Juniper Networks, Inc. xi

Configuring Firewall Filters on Shared Interfaces . . . . . . . . . . . . . . . . . . . . . . 102

Part 5 Configuration Examples

Part 6 Managing the JCS1200 Platform

xii Copyright © 2011, Juniper Networks, Inc.

Part 7 Managing RSDs and PSDs

Copyright © 2011, Juniper Networks, Inc. xiii

xiv Copyright © 2011, Juniper Networks, Inc.

Part 4 Configuring the Junos OS

Part 5 Configuration Examples

Copyright © 2011, Juniper Networks, Inc. xv

xvi Copyright © 2011, Juniper Networks, Inc.

Part 1 Product Overview

Part 3 Configuring the JCS1200 Platform

Part 4 Configuring the Junos OS

Part 5 Configuration Examples

Copyright © 2011, Juniper Networks, Inc. xvii

Table 22: Chassis Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Part 6 Managing the JCS1200 Platform

Part 7 Managing RSDs and PSDs

xviii Copyright © 2011, Juniper Networks, Inc.

• JUNOS Documentation and Release Notes on page xix

JUNOS Documentation and Release Notes

For a list of related JUNOS documentation, see

Copyright © 2011, Juniper Networks, Inc. xix

The Junos OS running on a pair of redundant Routing Engines on a T Series router is

• Border Gateway Protocol (BGP)

• Distance Vector Multicast Routing Protocol (DVMRP)

• Intermediate System-to-Intermediate System (IS-IS)

• Internet Control Message Protocol (ICMP) router discovery

• Internet Group Management Protocol (IGMP)

• Multiprotocol Label Switching (MPLS)

• Open Shortest Path First (OSPF)

• Protocol-Independent Multicast (PIM)