Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - IP-IPV6-IGP CONFIGURATION GUIDE 2010-10-31, JUNOSE 11.3 Configuration Manual

Download

Page 1

JunosE™ Software for E Series™ Broadband Services Routers

IP, IPv6, and IGP Configuration Guide

Release

11.3.x

Published: 2010-10-01

Page 2

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net

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.

JunosE™ Software for E Series™ Broadband Services Routers IP, IPv6, and IGP Configuration Guide

Writing: Mark Barnard, Bruce Gillham, Sarah Lesway-Ball, Brian Wesley Simmons, Fran Singer, Sairam Venugopalan, Pallavi Madhusudhan, Namrata Mehta Editing: Benjamin Mann, Alana Calapai Illustration: Nathaniel Woodward Cover Design: Edmonds Design

Revision History October 2010 —FRS JunosE 11.3.x

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.

Page 3

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 THISAGREEMENT. IF YOU DO NOTOR CANNOT AGREE TO THE TERMSCONTAINED 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 principaloffice is locatedoutside the Americas) (such applicable entity beingreferred to herein as“Juniper”), and (ii)the person ororganizationthat originally purchased from Juniperor 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 applicablefees and the limitations andrestrictions set forthherein, Junipergrants 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 limitstoCustomer’suse ofthe Software.Such limitsmay restrict use toa maximum number of seats, registeredendpoints, 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 anyform, to anythird party; (d)removeany proprietary notices, labels,or markson 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 thesecondhandmarket;(f) use any‘locked’ orkey-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

Page 4

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 commercialefforts to maintain the Software and associated documentation in confidence, which at a minimum includes restrictingaccess to the Software to Customer employees and contractors havinga 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 statementthataccompaniesthe Software (the “Warranty Statement”). Nothing inthis Agreement shallgive rise to anyobligation tosupport 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 ORPROCUREMENT OFSUBSTITUTE GOODSOR SERVICES,OR FORANYSPECIAL,INDIRECT, ORCONSEQUENTIALDAMAGES ARISING OUTOF THIS AGREEMENT,THE SOFTWARE,OR ANY JUNIPEROR JUNIPER-SUPPLIED SOFTWARE. IN NOEVENT 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.

Page 5

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 embeddedin 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 shallhave theright to enforce this Agreement in its own name as if itwere 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)).

Page 6

Page 7

Abbreviated Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Part 1 Internet Protocol

Chapter 1 Configuring IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Configuring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 3 Configuring Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Part 2 Internet Protocol Routing

Chapter 4 Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Chapter 5 Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 6 Configuring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Part 3 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Page 8

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Page 9

Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

E Series and JunosE Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . xxi

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

E Series and JunosE Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . xxi

Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Part 1 Internet Protocol

Chapter 1 Configuring IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

IP Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

IP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Moving Data Between Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Routing Datagrams to Remote Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Fragmenting and Reassembling Datagrams . . . . . . . . . . . . . . . . . . . . . . . 4

IP Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Network Interface Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Internet Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

IP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Physical and Logical Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Internet Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Subnetwork Mask Format Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Subnet Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Classless Addressing with CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Adding and Deleting Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Adding a Primary Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Deleting a Primary Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Adding a Secondary (Multinet) Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Deleting a Secondary Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

ip address Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Indirect Next-Hop Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Before You Configure IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Page 10

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Creating a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Assigning a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

How ARP Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

MAC Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Broadcast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Broadcast Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Routing Information Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Setting the Administrative Distance for a Route . . . . . . . . . . . . . . . . . . . . . . . 27

Setting the Metric for a Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Routing Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Identifying a Router Within an Autonomous System . . . . . . . . . . . . . . . . . . . 28

Establishing a Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Configuring Static Routes with Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . 29

Verifying Next Hops for Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Setting Up Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Setting Up an Unnumbered Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Adding a Host Route to a Peer on a PPP Interface . . . . . . . . . . . . . . . . . . . . . 39

Enabling Source Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Enabling Source Address Validation Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Defining TCP Maximum Segment Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Setting MSS for TCP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Configuring IP Path MTU Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Shutting Down an IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Removing the IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Clearing IP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Clearing IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Setting a Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Disabling Forwarding of Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Enabling Forwarding of Source-Routed Packets . . . . . . . . . . . . . . . . . . . . . . . 45

Forcing an Interface to Appear Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Specifying a Debounce Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Adding a Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Enabling Link Status Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Configuring the Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Configuring Equal-Cost Multipath Load Sharing . . . . . . . . . . . . . . . . . . . . . . . 48

How BFD Next-Hop Verification Works . . . . . . . . . . . . . . . . . . . . . . . . . . 30

BFD Next Hop Verification Configuration Example . . . . . . . . . . . . . . . . . . 31

How RTR Next-Hop Verification Works . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

RTR Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Configuring RTR Next-Hop Verification . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Enabling PMTU Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Limiting PMTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Specifying Black Hole Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Defining Maximum Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Round-Robin Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Fast Reroute Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Page 11

Table of Contents

Setting a TTL Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Protecting Against TCP RST or SYN DoS Attacks . . . . . . . . . . . . . . . . . . . . . . 50

Preventing TCP PAWS Timestamp DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . 50

Protecting Against TCP Out of Order DoS Attacks . . . . . . . . . . . . . . . . . . . . . . 51

Limiting Buffers per Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Limiting Buffers per Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Limiting Buffers per Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Distributing Routing Table Updates to Line Modules . . . . . . . . . . . . . . . . . . . 53

IP Tunnel Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Shared IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Configuring Shared IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Moving IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

IP Shared Interface Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Subscriber Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Internet Control Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

ICMP Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Specifying a Source Address for ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 59

Reachability Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Response Time Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Configuring the Probe Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Configuring Optional Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Capturing Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Collecting History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Setting the Receiving Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Setting Reaction Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Scheduling the Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Shutting Down the Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Monitoring RTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Monitoring IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Establishing a Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

IP show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Chapter 2 Configuring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

IPv6 Packet Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

IPv4 and IPv6 Header Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Standard IPv6 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Extension Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Address Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Address Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Address Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

ICMP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

IPv6 Tunnel Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Indirect Next Hop Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Page 12

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Before You Configure IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Configuring an IPv6 License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Creating an IPv6 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Assigning a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Enabling Source Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Establishing a Static Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Specifying an IPv6 Hop Count Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Managing IPv6 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Configuring Shared IPv6 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Adding a Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

IPv6 TCP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Setting MSS for TCP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Configuring Path MTU Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Protecting Against TCP RST or SYN DoS Attacks . . . . . . . . . . . . . . . . . . . . . . 141

Preventing TCP PAWS Timestamp DoS Attacks . . . . . . . . . . . . . . . . . . . . . . 142

Protecting Against TCP Out of Order DoS Attacks . . . . . . . . . . . . . . . . . . . . 143

Configuring Equal-Cost Multipath Load Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Hashed Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Fast Reroute Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Removing an IPv6 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Clearing IPv6 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Creating Static IPv6 Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Clearing Dynamic IPv6 Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Monitoring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Establishing a Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

IPv6 show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 3 Configuring Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Before You Configure Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Configuring Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Using IPv6 Profiles and RADIUS to Configure Neighbor Discovery Route

Configuring Proxy Neighbor Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Configuring Duplicate Address Detection Attempts . . . . . . . . . . . . . . . . . . . . . . . 197

Monitoring Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Enabling PMTU Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Limiting PMTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Specifying Black Hole Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Limiting Buffers per Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Limiting Buffers per Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Limiting Buffers per Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Defining Maximum Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

IPv6 Profile-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

RADIUS-Based Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Page 13

Table of Contents

Part 2 Internet Protocol Routing

Chapter 4 Configuring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

RIP Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

RIP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Route Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Subnet Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Route Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Split Horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Equal-Cost Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Applying Route Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Before You Run RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Relationship Between address and network Commands . . . . . . . . . . . . . . 208

Enabling RIP on Dynamic IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Clearing Dynamic RIP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Using RIP Routes for Multicast RPF Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Configuring the BFD Protocol for RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Remote Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Monitoring RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapter 5 Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

OSPF Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Intra-area, Interarea, and External Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Routing Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Virtual Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Opaque LSAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Route Leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Equal-Cost Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

OSPF MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Interacting with Other Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Implementing OSPF for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Understanding the OSPFv3 Difference . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Supported LSA Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Unsupported OSPF Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

OSPF Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Page 14

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Starting OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Enabling OSPFv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Enabling OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Creating a Range of OSPF Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Creating a Single OSPFv2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Specifying an OSPF Router ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Aggregating OSPF Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

Configuring OSPF Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

address Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

ip ospf and ipv6 ospf Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Comparison Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Precedence of Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Configuring OSPF Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Optimizing the Cost to Reach a Range of OSPF Routers Within an Area . . . . . . 263

Configuring Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Authentication Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Configuring the BFD Protocol for OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Configuring Additional Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Methods for Calculating OSPF Interface Cost . . . . . . . . . . . . . . . . . . . . . . . . 280

Default Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Configuring OSPF for NBMA Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Configuring OSPF for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Using OSPF Routes for Multicast RPF Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

OSPF and BGP/MPLS VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Remote Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Remote Neighbors and Sham Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Configuring OSPF Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Disabling and Reenabling Incremental SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Configuring OSPF Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Neighbor Uptime Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Monitoring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

debug Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Chapter 6 Configuring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

IS-IS Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

ISO Network Layer Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Dynamic Hostname Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

Level 1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Level 2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

Simple Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

HMAC MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

MD5 Authentication Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

Specifying MD5 Start and Stop Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Halting MD5 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Managing and Replacing MD5 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Page 15

Table of Contents

Enabling and Disabling Authentication of CSNPs and PSNPs . . . . . . . 324

Extensions for Traffic Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Integrated IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Equal-Cost Multipath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Static PPP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Route Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Route Tag Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Route Tag Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

Setting Route Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Using Route Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Unsupported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Table Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

How Graceful Restart Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

IS-IS for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Before You Run IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Enabling IS-IS for IP Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Summary Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Enabling and Configuring IS-IS for IPv6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 335

Summary Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Configuring IS-IS Interface-Specific Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 337

Configuring Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Configuring Link-State Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

Configuring a Reference Bandwidth to Set a Default Metric . . . . . . . . . . . . 338

Setting the CSNP Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Configuring Hello Packet Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

Padding IS-IS Hello Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Configuring LSP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

Setting the Designated Router Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Configuring Passive Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

Configuring Adjacency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Configuring Route Tags for IS-IS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Configuring Point-to-Point-over-LAN Circuits . . . . . . . . . . . . . . . . . . . . . . . 346

Summary Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Configuring Global IS-IS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Setting Authentication Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Configuring Authentication of CSNPs and PSNPs . . . . . . . . . . . . . . . . . . . . 349

Configuring Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

Redistributing Routes Between Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Controlling Granularity of Routing Information . . . . . . . . . . . . . . . . . . . . . . . 354

Configuring a Global Default Metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Configuring Metric Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Setting the Administrative Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Configuring Default Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Page 16

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Setting Router Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Summarizing Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Avoiding Transient Black Holes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Ignoring LSP Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Logging Adjacency State Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Configuring LSP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Specifying the SPF Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

Defining the SPF Route Calculation Level . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

Setting CLNS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Setting the Maximum Parallel Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Configuring a Virtual Multiaccess Network . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Configuring Table Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Configuring Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Summary Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Configuring IS-IS for MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Using IS-IS Routes for Multicast RPF Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

Configuring the BFD Protocol for IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

Disabling the IS-IS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

Monitoring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Monitoring IS-IS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

Displaying CLNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Waiting for BGP Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Example Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

Suppression for IS-IS Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Part 3 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

Page 17

List of Figures

Part 1 Internet Protocol

Chapter 1 Configuring IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 1: TCP/IP Conceptual Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Figure 2: IP Address Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 3: Basic Network Masking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 4: Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 5: Routing With and Without CIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 6: Direct Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 7: Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 8: Sample ARP Process—1 through 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 9: Sample ARP Process—4 and 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 10: Routers in a Small Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Figure 11: Static Routes with Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Figure 12: Sample Configuration for Next-Hop Verification . . . . . . . . . . . . . . . . . . 33

Chapter 2 Configuring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Figure 13: IPv4 and IPv6 Header Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Figure 14: Direct Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Figure 15: Indirect Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Part 2 Internet Protocol Routing

Chapter 5 Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Figure 16: OSPF Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Figure 17: Optimizing OSPF Area Aggregate Costs . . . . . . . . . . . . . . . . . . . . . . . . 264

Chapter 6 Configuring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Figure 18: Overview of IS-IS Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Figure 19: Packet Flow Between Routers With and Without Authentication

Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Figure 20: Example of Level 1 and Level 2 Routing . . . . . . . . . . . . . . . . . . . . . . . . 353

Figure 21: Transit Router Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Page 18

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Page 19

List of Tables

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Part 1 Internet Protocol

Chapter 1 Configuring IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Table 3: Routing Table for Router NY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Table 4: Routing Table for Router LA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Table 5: Default Administrative Distances for Route Sources . . . . . . . . . . . . . . . . . 27

Table 6: Next-Hop Verification Results for Sample Configuration . . . . . . . . . . . . . 33

Table 7: Probe Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 2 Configuring IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Table 8: Compressed IPv6 Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Part 2 Internet Protocol Routing

Chapter 5 Configuring OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Table 9: OSPF-Related Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Table 10: Routing Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Table 11: Additional Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Table 12: Methods and Precedence for Calculating OSPF Interface Cost . . . . . . 280

Chapter 6 Configuring IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

Table 13: IS-IS Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Table 14: Configuration Tasks for Setting IS-IS Route Tags . . . . . . . . . . . . . . . . . . 327

Table 15: IS-IS Graceful Restart Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

Page 20

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Page 21

About the Documentation

•

E Series and JunosE Documentation and Release Notes on page xxi

•

Audience on page xxi

•

E Series and JunosE Text and Syntax Conventions on page xxi

•

Obtaining Documentation on page xxiii

•

Documentation Feedback on page xxiii

•

Requesting Technical Support on page xxiii

E Series and JunosE Documentation and Release Notes

For a list of related JunosE documentation, see

http://www.juniper.net/techpubs/software/index.html .

If the information in the latest release notes differs from the information in the documentation, follow the JunosE 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/.

Audience

This guide is intended for experienced system and network specialists working with Juniper Networks E SeriesBroadband Services Routers in an Internet access environment.

E Series and JunosE Text and Syntax Conventions

Table 1 on page xxii defines notice icons used in this documentation.

Page 22

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Table 1: Notice Icons

Table 2 on page xxii defines text and syntax conventions that we use throughout the E Series and JunosE documentation.

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardware damage.Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Table 2: Text and Syntax Conventions

Representscommandsand keywordsin text.Bold text like this

Fixed-width text like this

Italic text like this

Plus sign (+) linking key names

Syntax Conventions in the Command Reference Guide

Representsinformationas displayedon your terminal’s screen.

•

Emphasizes words.

•

Identifies variables.

•

Identifies chapter, appendix, and book names.

keys simultaneously.

ExamplesDescriptionConvention

•

Issue the clock source command.

•

Specify the keyword exp-msg.

host1(config)#traffic class low-loss1Represents text that the user must type.Bold text like this

host1#show ip ospf 2

Routing Process OSPF 2 with Router ID 5.5.0.250

Router is an Area Border Router (ABR)

•

There are two levels of access: user and privileged.

•

clusterId, ipAddress.

•

Appendix A, System Specifications

Press Ctrl + b.Indicates that you must press two or more

terminal lengthRepresents keywords.Plain text like this

mask, accessListNameRepresents variables.Italic text like this

Page 23

Table 2: Text and Syntax Conventions (continued)

About the Documentation

ExamplesDescriptionConvention

| (pipe symbol)

or variable to the left or to the right of this symbol. (The keyword or variable can be either optional or required.)

[ ]* (brackets and asterisk)

that can be entered more than once.

Represent required keywords or variables.{ } (braces)

Obtaining Documentation

To obtain the most current version of all Juniper Networks technical documentation, see the Technical Documentation page on the Juniper Networks Web site at

http://www.juniper.net/.

To download complete sets of technical documentation to create your own documentation CD-ROMs or DVD-ROMs, see the Portable Libraries page at

http://www.juniper.net/techpubs/resources/index.html

diagnostic | lineRepresents a choice to select one keyword

[ internal | external ]Represent optional keywords or variables.[ ] (brackets)

[ level1 | level2 | l1 ]*Represent optional keywords or variables

{ permit | deny } { in | out }

{ clusterId | ipAddress }

Copies of the Management Information Bases (MIBs) for a particular software release are available for download in the software image bundle from the Juniper Networks Web site athttp://www.juniper.net/.

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation to better meet your needs. 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

Requesting Technical Support

Technical productsupport isavailable through theJuniper NetworksTechnical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

Page 24

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

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/ .

•

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 verifyservice entitlement by productserial number,use ourSerialNumber 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 .

Page 25

PART 1

Internet Protocol

•

Configuring IP on page 3

•

Configuring IPv6 on page 121

•

Configuring Neighbor Discovery on page 189

Page 26

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Page 27

CHAPTER 1

Configuring IP

This chapter describes how to configure Internet Protocol (IP) routing on your E Series router.

•

Overview on page 3

•

Platform Considerations on page 5

•

References on page 6

•

IP Features on page 6

•

IP Addressing on page 7

•

Indirect Next-Hop Support on page 12

•

Before You Configure IP on page 13

•

Creating a Profile on page 14

•

Address Resolution Protocol on page 17

•

Broadcast Addressing on page 22

•

Fragmentation on page 24

•

IP Routing on page 25

•

Shared IP Interfaces on page 54

•

Internet Control Message Protocol on page 57

•

Reachability Commands on page 59

•

Response Time Reporter on page 62

•

Monitoring IP on page 76

Overview

TCP/IP isa suite ofdatacommunicationsprotocols.Two of the more important protocols in the suite are the Transmission Control Protocol (TCP) and the Internet Protocol (IP).

IP provides the basicpacketdelivery service for allTCP/IP networks. IP is aconnectionless protocol, which means that it does not exchange control information to establish an end-to-end connection before transmitting data. A connection-oriented protocol exchanges control information with the remote computer to verify that it is ready to receive data before sending it.

Page 28

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

IP relies on protocols in other layers to establish the connection if connection-oriented services are required and to provide error detection and error recovery. IP is sometimes called an unreliable protocol, because it contains no error detection or recovery code.

IP Packets

A packet is a block of data that carries with it the information necessary to deliver it to a destination address. A packet-switching network uses the addressing information in the packets to switch packets from one physical network to another, moving them toward their finaldestination. Each packet travels the network independently of anyother packet. The datagram is the packet format defined by IP.

IP Functions

Some of the functions IP performs include:

•

Moving data between the network access layer and the host-to-host transport layer

•

Routing datagrams to remote hosts

•

Fragmenting and reassembling datagrams

Moving Data Between Layers

When IP receives a datagram that is addressed to the local host, it must pass the data portion of the datagram to the correct host-to-host transport layer protocol. IP uses the protocol number in the datagram header to select the transport layer protocol. Each host-to-host transport layer protocol has a unique protocol number that identifies it to IP.

Routing Datagrams to Remote Hosts

Internet gateways are commonly referred to as IP routers because they use IP to route packets between networks. In traditional TCP/IP terms, there are only two types of network devices: gateways and hosts. Gateways forward packets between networks, and hosts do not. However, if a host is connected to more than one network (called a multihomed host), it can forward packets between the networks. When a multihomed host forwards packets, it acts like any other gateway and is considered to be a gateway.

Fragmenting and Reassembling Datagrams

As a datagram is routed through different networks,it may be necessary for the IPmodule in a gateway to divide the datagram into smaller pieces. A datagram received from one network may be too large to be transmitted in a single packet on a different network. This condition occurs only when a gateway interconnects dissimilar physical networks.

Each type of network has a maximum transmission unit (MTU) that determines the largest packet it can transfer. If the datagram received from one network is longer than the other network’s MTU, it is necessary to divide the datagram into smaller fragments for transmission in a process called fragmentation. See “Fragmentation” on page 24.

IP Layering

TCP/IP is organized into four conceptual layers (as shown in Figure 1 on page 5).

Page 29

Chapter 1: Configuring IP

Figure 1: TCP/IP Conceptual Layers

Network Interface Layer

The network interface layer is the lowest level of the TCP/IP protocol stack. It is responsible for transmitting datagrams over the physical medium to their final destinations.

Internet Layer

The Internet layeris thesecond level ofthe TCP/IPprotocolstack. Itprovideshost-to-host communication.In thislayer, packetsare encapsulatedinto datagrams, routing algorithms are run, and the datagram is passed to the network interface layer for transmission on the attached network.

Transport Layer

The transport layer is the third level of the TCP/IP protocol stack. It is responsible for providing communication between applications residing in different hosts. By placing identifying information in the datagram (such as socket information), the transport layer enables process-to-process communication.

The transport layer provides either a reliable transport service (TCP) or an unreliable service (User Data Protocol). In a reliable delivery service, the destination station acknowledges the receipt of a datagram.

Application Layer

The application layer is the fourth and highest level of the TCP/IP protocol stack. Some applications that run in this layer are:

•

Telnet

•

File Transfer Protocol (FTP)

•

Simple Mail Transfer Protocol (SMTP)

•

Simple Network Management Protocol (SNMP)

•

Domain Name System (DNS)

Platform Considerations

For information about modules that support IP on the ERX7xx models, ERX14xx models, and the Juniper Networks ERX310 Broadband Services Router:

•

See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.

•

See ERX Module Guide, Appendix A, Module Protocol Support for information about the modules that support IP.

Page 30

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

For information about modules that support IP on the Juniper Networks E120 and E320 Broadband Services Routers:

•

See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module specifications.

•

See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information about the modules that support IP.

References

For more information about IP, consult the following resources:

•

RFC 768—User Datagram Protocol (August 1980)

•

RFC 791—Internet ProtocolDARPA InternetProgramProtocol Specification(September

1981)

•

RFC 792—Internet Control Message Protocol (September 1981)

•

RFC 793—Transmission Control Protocol (September 1981)

IP Features

•

RFC 854—Telnet Protocol Specification (May 1983)

•

RFC 919—Broadcasting Internet Datagrams (October 1984)

•

RFC 922—Broadcasting Internet Datagrams in thePresenceof Subnets (October 1984)

•

RFC 950—Internet Standard Subnetting Procedure (August 1985)

•

RFC 1112—Host Extensions for IP Multicasting (August 1989)

•

RFC 1122—Requirements for Internet Hosts—Communication Layers (October 1989)

•

RFC 1812—Requirements for IP Version 4 Routers (June 1995)

•

RFC 3419—Textual Conventions for Transport Addresses (December 2002)

•

JunosE Release Notes, Appendix A, System Maximums—Refer to the Release Notes corresponding to your software release for information about maximum values.

The E Series router supports the following IP features:

•

Internet Control Message Protocol (ICMP)

•

Traceroute

•

User Datagram Protocol (UDP)

•

Transmission Control Protocol (TCP)

•

Classless interdomain routing (CIDR)

•

Maximum transmission unit (MTU)

•

Support for simultaneous multiple logical IP stacks on the same router

Page 31

Chapter 1: Configuring IP

•

Flexible IP address assignment to support any portion of a physical interface (for example,a channelor circuit),exactly onephysical interface,or multilink PPP interfaces

•

Packet segmentation and reassembly

•

Loose source routing to specify the IP route

•

Strict source routing to specify the IP route for each hop

•

Record route to track the route taken

•

Internet timestamp

•

Broadcast addressing, both limited broadcast and directed broadcast

•

Support for 32,000 discrete,simultaneous IP interfaces per router to supportthousands of logical connections

•

Capability of detectingand reporting changes inthe upor downstateof anyIP interface

•

IP policy support. See JunosE IP Services Configuration Guide, for more information about policy configuration.

•

Indirect next hops

•

IP tunnel routing tables

IP Addressing

This section provides an overview of IP addressing in general and includes a discussion of CIDR, which your router fully supports.

Physical and Logical Addresses

Physical node addressesare used at thenetwork access layer to identify physicaldevices in a network. For example, each Ethernet controller comes from the manufacturer with a physical address, called a MAC address.

IP implements a system of logical host addresses called IP addresses. The IP addresses are used by the internetwork and higher layers to identify devices and to perform internetwork routing. The Address Resolution Protocol (ARP) enables IP to identify the physical (MAC) address that matches a given IP address. You can use ARP only on Ethernet and bridged IP 1483 interfaces.

IP is used by all protocols in the layers above and below it to deliver data. This means that all TCP/IP data flows through IP when it is sent and received, regardless of its final destination.

Internet Addresses

Internet addressing uses a32-bit address field. The bits inthis address field arenumbered 0 to 31. The 32-bit address field consists of two parts: a network number and a host number whose boundaries are defined based on the class of IP address. Hosts attached to the same network must share a common prefix designating their network number.

Page 32

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Four types of IP classes lend themselves to different network configurations, depending on the desired ratio of networks to hosts. Figure 2 on page 8 shows the format of IP address classes.

Figure 2: IP Address Classes

•

Class A—The leading bit is set to 0, a 7-bit number, and a 24-bit local host address. Up to 125 class A networks can be defined, with up to 16,777,214 hosts per network.

•

Class B—The two highest-order bits are set to 1 and 0, a 14-bit network number, and a 16-bit local host address. Up to 16,382 class B networks can be defined, with up to 65,534 hosts per network.

•

Class C—The three leading bits are set to 1, 1, and 0, a 21-bit network number, and an 8-bit local host address. Up to 2,097,152 class C networks can be defined, with up to 254 hosts per network.

•

Class D—The four highest-order bits are set to 1,1, 1,and 0. Class Dis used asa multicast address.

Subnetwork Mask Format Options

Most commandsallow you to specify IPv4 subnetwork masks inone of two ways: dotted decimal or prefix length notation.

NOTE: Protocol commands that use a reverse mask format (for example,

RIP) cannot use the prefix notation format. Use the CLI help to verify if a command supports the /N prefix notation.

Dotted decimal notationexpresses IP addressesand masks in dotted quads - four octets separated by dots (A.B.C.D). In this format, each octet in the address or mask is represented as a decimal number and the dots are used as octet separators.

For example, an IP address and subnetwork mask in dotted decimal notation would appear as follows:

10.10.24.6 255.255.0.0

Prefix length notation (often called network prefix format) allows for more efficient allocation of IP addresses than the old Class A, B, and C address scheme. The prefix

Page 33

Subnet Addressing

Chapter 1: Configuring IP

length is the number of leftmost contiguous bits equal to 1 in the subnetwork mask. This format appears immediately following the dotted decimal IP address using a /N format.

NOTE: You can issue the network prefix with or without a space between

the IP address and the network prefix (/N).

For example,the sameIP address andsubnetwork mask mentioned above wouldappear as follows using /N format:

10.10.24.6/16 or

10.10.24.6 /16

The following sections describe each subnetwork mask addressing method in more detail.

A subnet is a subset of a class A, B, or C network. Subnets cannot be used with class D (multicast) addresses.

A network mask is used to separate the network information from the host information about an IP address. Figure 3 on page 9 shows the network mask 255.0.0.0 applied to network 10.0.0.0. The mask in binary notation is a series of 1s followed by a series of contiguous 0s. The 1s represent the network number; the 0s represent the host number. The sample address splits the IP address 10.0.0.1 into a network portion of 10 and a host portion of 0.0.1.

NOTE: The router supports a 31-bit mask on point-to-point links. This means

that the IP address 1.2.3.4 255.255.255.254 is valid. A point-to-point link in which only one end supports the use of 31-bit prefixes may not operate correctly.

Figure 3: Basic Network Masking

Classes A, B, and C have the following natural masks, which define the network and host portions of each class:

•

Class A natural mask 255.0.0.

•

Class B natural mask 255.255.0.0

•

Class C natural mask 255.255.255.0

Page 34

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

The use of masks can dividenetworksinto subnetworks by extending the network portion of the address into the host portion. Subnetting increases the number of subnetworks and reduces the number of hosts.

For example, a network of the form 10.0.0.0 accommodates one physical segment with about 16 million hosts on it. Figure 4 on page 10 shows how the mask 255.255.0.0. is applied to network 10.0.0.0. The mask divides the IP address 10.0.0.1 into a network portion of 10, a subnet portion of 0, and a host portion of 0.1. The mask has borrowed a portion of the host space and has applied it to the network space. The network space of the class 10 has increased from a single network 10.0.0.0 to 256 subnetworks, ranging from 10.0.0.0 to 10.255.0.0. This process decreases the number of hosts per subnet from 16,777,216 to 65,536.

Figure 4: Subnetting

Classless Addressing with CIDR

Classless interdomain routing (CIDR) is a systemof addressing that improves the scaling factor of routing in the Internet. CIDR does not use an implicit mask based on the class of network. In CIDR, an IP network is represented by a prefix, which is an IP address and an indication of the leftmost contiguous significant bits within this address.

For example, without CIDR, the class C network address 192.56.0.0 would be an illegal address. With CIDR, the address becomes valid with the notation: 192.56.0.0/16. The /16 indicates that 16 bits of mask are being used (counting from the far left). This would be similar to an address 198.32.0.0. with a mask of 255.255.0.0.

A network is called a supernet when the prefix boundary contains fewer bits than the network’s natural mask. For example, a class C network 192.56.10.0 has a natural mask of 255.255.255.0. The representation 192.56.0.0/16 has a shorter mask than the natural mask (16 is less than 24), so it is a supernet.

Figure 5 on page 11 shows how CIDR can reduce the number of entries globally in Internet routing tables. A service provider has a group of customers with class C addresses that begin with 192.56. Despite this relationship, the service provider announces each of the networks individually into the global Internet routing mesh.

Page 35

Figure 5: Routing With and Without CIDR

Adding and Deleting Addresses

This section provides information about adding or deleting IP addresses.

Chapter 1: Configuring IP

Multinetting is adding more than one IP address to an IP interface—that is, a primary address and one or more secondary addresses.

To makean interface unnumbered,see “Setting Upan Unnumbered Interface” onpage 38.

Adding a Primary Address

•

The primary address must be the first address added to the interface.

•

Adding a new primary address overwrites the existing primary address.

•

You can change a secondary address to be the primary address on an interface only via SNMP.

•

An unnumbered address is always the primaryaddress; adding anunnumbered address, therefore, overwrites any other numbered address.

Deleting a Primary Address

•

You must always remove the primary address from an interface last.

•

You cannot delete the primary address if the interface still has assigned secondary addresses.

Adding a Secondary (Multinet) Address

•

You cannot add a secondary address until you add the primary address.

•

You cannot add a secondary address to bridged Ethernet interfaces.

•

You cannot change a primary address to a secondary address.

•

An interface can have multiple secondary addresses.

Page 36

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Deleting a Secondary Address

•

You must delete secondary addresses before deleting the primary address.

ip address Command

Use the following command to add addresses to or delete addresses from an interface:

ip address

• Use to add a primary address or to add secondary addresses to an interface.

• To add multiple addresses to a single IP interface, use the secondary keyword.

(Remember, if you add an address using the ip address command and do not include the secondary keyword, the new address becomes the primary address.)

• You can specify the subnetwork mask value in either dotted decimal or prefix length

notation.

• Example—Adds a primary address (192.168.2.77) and two secondary addresses

(172.31.7.22 and 10.8.7.22); the Fast Ethernet interface now has addresses in three networks.

host1(config)#interface fastEthernet 0/0 host1(config-if)#ip address 192.168.2.77 255.255.255.0 host1(config-if)#ip address 172.31.7.22 255.255.255.0 secondary host1(config-if)#ip address 10.8.7.22 255.255.255.0 secondary

• Use the no version to remove an IP address. If you remove a primary IP address, IP

processing is disabled on the interface.

• See ip address

Indirect Next-Hop Support

The router uses indirect next hops to promote faster network convergence (for example, in BGP networks) by decreasing the number of routing table changes required when a change in the network topology occurs.

Direct next-hops point routes in the routing table toward individual, direct next-hop connections. (See Figure 6 on page 13.)

NOTE: You can use this command in Interface Configuration mode,

Subinterface Configuration mode, or Profile Configuration mode.

Page 37

Chapter 1: Configuring IP

Figure 6: Direct Next Hops

Indirect next hops enable multiple routes in the routing table to point to a single next hop, thereby accelerating convergence. (See Figure 7 on page 13.)

NOTE: Indirect next hops are not limited to any number of levels. In other

words, an indirect next hop can point to a direct next hop or another indirect next hop.

Figure 7: Indirect Next Hops

By using indirect next hops, if a topology change occurs in the network, only the indirect next hop ismodified in therouting table, decreasingthe number of statechanges required to achieve convergence.

Before You Configure IP

Before you configure IP, created lower-layer interfaces over which IP traffic flows.

For example, to configure an ATM interface:

host1(config)#interface atm 1/0 host1(config-if)#atm sonet stm-1 host1(config-if)#no loopback host1(config-if)#atm clock internal chassis host1(config-if)#interface atm 1/0.10 host1(config-if)#atm pvc 10 0 20 aal5snap

Refer to the appropriate chapters for information about configuring a specific type of interface.

Page 38

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

NOTE: If you choose to configure VRRP, we recommend that you complete

all IP address configurations before you configure VRRP. See JunosE Services Availability Configuration Guide, for additional information.

Creating a Profile

You can configure an IP interface dynamically by creating a profile. A profile is a set of characteristics that acts as a pattern that can be dynamically assigned to an IP interface. You can manage a large number of IP interfaces efficiently by creating a profile with a specific set ofcharacteristics.In addition,you can create a profileto assign an IP interface to a virtual router.

A profile can contain one or more of the following characteristics:

•

access-route—Enables the creation of host access routes on an interface

•

address—Configures an IP address on an interface

•

auto-configure—Configures the interface for auto-configure mode

•

auto-detect—Configures the interface for auto-detect mode

•

directed-broadcast—Enables directed broadcast forwarding

•

filter-options-all—Enables filtering of packets with IP options on an interface

•

igmp—Configures an IGMP interface

•

ignore-df-bit—Specifies that the don’t-fragment bit is ignored

•

inactivity-timer—Configures inactivity time for IP interfaces

•

inspection—Associates an inspection list to the interface for firewalling

•

mtu—Configures the maximum transmission unit for a network

•

nat—Configures the interface as inside or outside for Network Address Translation (NAT)

•

policy—Assigns a policy to the ingress or egress of an interface

•

redirects—Enables transmission of ICMP redirect messages

•

route-maps—Configures the interface for route-map processing

•

source address validation—Verifies that a packet has been sent from a valid source address

•

tcp adjust-mss—Adjusts maximum packet sizes on TCP connections when path MTU detection is not sufficient

•

unnumbered—Configures IP on this interface without a specific address

•

virtual-router—Specifies a virtual router to which interfaces created by this profile will be attached

Page 39

ip access-routes

ip address

Chapter 1: Configuring IP

Use the profile command from Global Configuration mode to create or edit a profile. See JunosE Link Layer Configuration Guide for information about creating profiles and on other characteristics that can be applied to the profile.

host1(config)#profile acton host1(config-profile)#ip virtual-router warf host1(config-profile)#ip unnumbered atm 3/0

• Use to enable an access route in a profile.

• Example

host1(config)#profile foo host1(config-profile)#ip access-routes

• Use the no version to remove the access route.

• See ip access-routes

ip directed-broadcast

ip mtu

• Use to assign an IP address to a profile.

• You must first specify the layer 2 encapsulation before you can set the IP address for

serial interfaces.

• Example

host1(config-if)#ip address 192.56.32.2 255.255.255.0

• Use the no version to remove the IP address assigned to the profile.

• See ip address

• Use to enable a directed broadcast address in a profile.

• Example

host1(config-if)#ip directed-broadcast

• Use the no version to remove the directed broadcast address from the profile.

• See ip directed-broadcast

• Use to assign the MTU size sent on an IP interface.

• Example

host1(config-if)#ip mtu 5000

• Use the no version to remove the assignment from the profile.

• See ip mtu

ip redirects

Page 40

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use to enable the sending of redirect messages if the software is forced to resend a

packet through the same interface on which it was received.

• Example

host1(config-if)#ip redirects

• Use the no version to remove the assignment from the profile.

• See ip redirects

ip tcp adjust-mss

• Use tomodify themaximum segment size(MSS) for TCP SYNpacketstravelingthrough

the interface. The router compares the MSS value of incoming or outgoing packets against the MSS adjustment value. For any packet that contains an MSS value larger than theMSS adjustment value, the routerreplaces theMSS option with the configured adjustment value. If the packet does not contain an MSS value, the router assumes a value of 536 for the packet MSS on which to base the comparison.

ip unnumbered

NOTE: The purpose behind using MSS is to alleviate problems with Path MTU Discovery (PMTUD) and resulting “black hole” detection issues. (See RFC 2923, “TCP Problems with Path MTU Discovery,” for additional information about the “black hole” scenario.)

• Example

host1(config-if)#ip tcp adjust-mss 5000

• Use the no version to remove the MSS assignment from the profile.

• See ip tcp adjust-mss

• Use to specify the numbered interface with which dynamic unnumbered interfaces

created with the profile are associated.

• You can specify an unnumbered interface using RADIUS instead of using the ip

unnumbered command in a profile.

• Example

host1(config-profile)#ip unnumbered fastEthernet 0/0

• Use the no version to remove the assignment from the profile.

• See ip unnumbered

ip virtual-router

• Use to assign a virtual router to a profile.

• You can configure a virtual router using RADIUS instead of adding one to the profile

by using the ip virtual-router command.

• Example

Page 41

profile

Assigning a Profile

Chapter 1: Configuring IP

host1(config-profile)#ip virtual-router VR1

• Use the no version to remove the virtual router assignment.

• See ip virtual-router

• Use to create a profile.

• You specify a profile name with up to 80 characters.

• Example

host1(config)#profile foo

• Use the no version to remove a profile.

• See profile

To assign a profile to an interface, use the profile command from Interface mode.

profile

• Use to assign a profile to a PPP interface. The profile configuration is used to

dynamically create an upper IP interface.

• Example

host1(config-if)#interface serial 2/1 host1(config-if)#encapsulation ppp host1(config-if)#profile acton

• Use the no version to remove the assignment from the interface.

• See profile

Address Resolution Protocol

Sending IP packets on a multiaccess network requires mapping from an IP address to a MAC address (the physical or hardware address).

In an Ethernet environment, Address Resolution Protocol (ARP) is used to map a MAC address to an IP address. ARP dynamically binds the IP address (the logical address) to the correct MAC address. Before IP unicast packets can be sent, ARP discovers the MAC address used by the Ethernet interface where the IP address is configured.

Hosts that use ARP maintain a cache of discovered Internet-to-Ethernet address mappings to minimize the number of ARP broadcast messages. To keep the cache from growing too large, an entry is removed if it is not used within a certain period of time. Before sending a packet, the host searches its cache for Internet-to-Ethernet address mapping. If the mapping is not found, the host sends an ARP request.

Page 42

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

NOTE: For information about MAC address validation, see “MAC Address

Validation” on page 21.

How ARP Works

Figure 8 on page 18 and Figure 9 on page 19 show how ARP works where host 1 sends an IP packet to host 2 on a different subnet. To complete this transmission, host 1 needs the MAC address of router 1, to be used as the forwarding gateway.

A typical scenario is:

1. Host 1 broadcasts an ARP request to all devices on subnet 1, composed by a query

with the IP address of router 1. The IP address of router 1 is needed because host 2 is on a different subnet.

2. All devices on subnet 1 compare their IP address with the enclosed IP address sent

by host 1.

3. Having the matching IP address, router 1 sends an ARP response, which includes its

MAC address, to host 1.

Figure 8: Sample ARP Process—1 through 3

4. Host 1 transmits the IP packet to layer 3 DA (host 2) using router 1’s MAC address.

5. Router 1 forwards IP packet to host 2. Router 1 might send an ARP request to identify

the MAC of host 2. (See Figure 9 on page 19.)

Page 43

Chapter 1: Configuring IP

Figure 9: Sample ARP Process—4 and 5

ARP forces all receiving hosts to compare their IP addresses with the IP address of the ARP request. So if host 1 sends another IP packet to host 2, host 1 searches its ARP table for the router 1 MAC address.

arp

arp spoof-check

If thedefaultrouter/gatewaybecomes unavailable, thenall therouting/packet forwarding to remote destinations ceases. Usually, manual intervention is required to restore connectivity, even though alternative paths may beavailable. Alternatively, Virtual Router Redundancy Protocol (VRRP) may be used to prevent loss of connectivity. See JunosE IP Services Configuration Guide.

Use to add a static (permanent) entry in the ARP cache.•

• To add a static entry in the ARP cache, specify the ipAddress, interfaceType and

interfaceSpecifier (as indicated in Interface Types and Specifiers in JunosE Command Reference Guide ), and an optional MAC address

• You can issue this command only for Fast Ethernet interfaces, Gigabit Ethernet

interfaces, 10-Gigabit Ethernet interfaces, and bridged Ethernet interfaces configured over ATM 1483.

• Example

host1(config)#arp 192.56.20.1 gig 2/0 0090.1a00.0170

• Use the no version to remove an entry from the ARP cache.

• See arp

• Use toconfigure the router to checkfor spoofed ARPpacketsreceivedon anIP interface.

• By default, E Series routers check all received ARP packets for spoofing and process

only those ARP packets whose source IP address is outside the range of the network mask. ARP packets with a source IP address of 0.0.0.0 and the router IP address as

Page 44

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

the destination address are dropped because the router identifies them as spoofed packets.

• In networks with digital subscriber line access multiplexers (DSLAMs), even if you

configure the router to check for spoofed ARP packets, DSLAMs perform this task instead of the router. If you disable checking for spoofed ARP packets on the router in such networks, DSLAMs forward the received packets to the router for processing. You can, therefore, configure the router accordingly, depending on the way in which you want spoof-checking to be performed.

• You cannot configure ARP spoof-checking on interfaces that do do support ARP, such

as loopback interfaces and ATM point-to-point PVCs.

• If you disable checking for spoofed ARP packets, all packets received by the router are

processed.

• You can reenable checking for spoofed ARP packets on an interface at any time by

using the arp spoof-check command after disabling it.

• Example—Showshow to disable spoof-checking for ARPpacketsreceived on a Gigabit

Ethernet interface and then reenable it.

arp timeout

host1(config-if)#interface gigabitEthernet 1/1 host1(config-if)#no arp spoof-check host1(config-if)#arp spoof-check

• Use the no version to disable checking for spoofed ARP packets received on a major

IP interface or an IP subinterface.

• See arp spoof-check.

• Use to specify how long an entry remains in the ARP cache.

• You can issue this command only for Fast Ethernet interfaces, Gigabit Ethernet

interfaces, 10-Gigabit Ethernet interfaces, and bridged Ethernet interfaces configured over ATM 1483.

• The default value is 21,600 seconds (6 hours). Use the show config command to

display the current value.

• If you specify a timeout of 0 seconds, entries are never cleared from the ARP cache.

• Example

host1(config-if)#arp timeout 8000

• Use the no version to restore the default value.

• See arp timeout

clear arp

• Use to clear dynamic entries from the ARP cache.

• To clear a particular entry, specify all of the following:

Page 45

ip proxy-arp

Chapter 1: Configuring IP

• ipAddress—IP address infour-partdotted-decimal format corresponding to thelocal

data link address

• interfaceType—Interface type; seeInterfaceTypes and Specifiers in JunosE Command

Reference Guide

• interfaceSpecifier—Particular interface; format varies according to interface type;

see Interface Types and Specifiers in JunosE Command Reference Guide

• To clear all dynamic ARP entries, specify an asterisk (*).

• Example

host1#clear arp

• There is no no version.

• See clear arp

• Use to enable proxy ARP on an Ethernet or bridge1483 interface.

• Proxy ARP is enabled by default.

• Example

• Use the no version to disable proxy ARP on the interface.

• See ip proxy-arp

MAC Address Validation

MAC address validation is a verification process performed on each incoming packet to prevent spoofing on IP Ethernet-based interfaces, including bridged Ethernet interfaces. When an incoming packet arrives on a layer 2 interface, the validation table is used to compare the packet’s source IP address with its MAC address. If the MAC address and IP address match, the packet is forwarded; if it does not match, the packet is dropped.

MAC address validation on the E Series router can be accomplished in two ways:

•

host1(config-if)#ip proxy-arp unrestricted

NOTE: MAC address validation for bridged Ethernet interfaces is supported only on OC12 ATM line modules on ERX routers and on OC3/OC12 ATM IOAs on the E120 and E320 routers.

You can statically configure it on a physical interface via the arp validate command

•

You can enable DHCP to perform the function independently and dynamically. See JunosE Link Layer Configuration Guide .

The arp validate command adds the IP-MAC address pair to the validation table maintained on the physical interface.

Page 46

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

If the validation is added statically via the CLI, the IP address–MAC address pairs are stored in NVS. The entries are used for MAC validation only if MAC validation is enabled on the interface via the ip mac-validate command.

CAUTION: When you configurean interface using the arp validate command,

you cannot overwrite the ARP values that were added by DHCP.

You can enable or disable MAC address validation on a per interface basis by issuing the

ip mac-validate command. See JunosE Physical Layer Configuration Guide or JunosE Link Layer Configuration Guide for information.

A dynamic IP subscriber interface inherits the MAC address validation state (enabled or disabled) configured for its parent static primary IP interface. See Configuring Subscriber Interfaces in the JunosE Broadband Access Configuration Guide for information.

arp validate

• Use to add IP address–MAC address validation pairs. When validation is enabled, all

packets with the source IP address received on this IP interface are validated against the IP-MAC entries.

• To add a validation pair, specify one of the following:

• ipAddress and macAddress of the interface

• ipAddress, interfaceType and interfaceSpecifier (as indicated in Interface Types and

Specifiers in JunosE Command Reference Guide ), and an optional MAC address

• You can issue this command only for an IP Ethernet-based interface.

• For subscriber interface configurations, the IP address–MAC address pair must have

a matching source prefixthat already exists onthe subscriberinterface. Ifthe matching source prefix does not exist, the IP–MAC address pair is rejected. See Configuring Subscriber Interfaces in the JunosE Broadband AccessConfiguration Guide for information about using subscriber interfaces.

• Example 1—Packets originating fromhost 192.56.20.1 and validated at Gigabit Ethernet

interface with the MAC address 0090.1a00.0170

host1(config)#arp 192.56.20.1 gig 2/0 0090.1a00.0170 validate

• Example 2—Subscriber interface MAC address validation enabled

host1(config)#arp 192.168.32.0 ip subsc1 000.0001.8100

• Use the no version to remove an entry from the ARP cache.

• See arp

Broadcast Addressing

A broadcast is a data packet destined for all hosts on a particular physical network. Network hosts recognize broadcasts by special addresses.

Page 47

Chapter 1: Configuring IP

The router supports the following kinds of broadcast types:

•

Limited broadcast—A packet is sent to a specific network or series of networks. A limited broadcast address includesthe network or subnet fields. In a limited broadcast packet destined for a local network, the network identifier portion and host identifier portion of the destination address is either all ones (255.255.255.255) or all zeros (0.0.0.0).

•

Flooded broadcast—A packet is sent to every network.

•

Directed broadcast—A packet is sent to a specific destination address where only the host portion of the IP address is either all ones or all zeros (such as 192.20.255.255 or

190.20.0.0).

Several early IP implementations do not use the current broadcast address standard. Instead, they use the old standard, which calls for all zeros instead of all ones to indicate broadcast addresses. Many of these implementations do not recognize a broadcast address of all ones and fail to respond to the broadcast correctly. Others forward broadcasts of all ones, which causes a serious network overload known as a broadcast storm. Implementations that exhibit these problems include systems based on versions of BSD UNIX before version 4.3.

Broadcast Tasks

ip broadcast-address

ip directed-broadcast

Routers provide some protection from broadcast storms by limiting their extent to the local cable. Bridges (including intelligent bridges), because they are layer 2 devices, forward broadcasts to all network segments, thus propagating all broadcast storms.

The best solution to the broadcast storm is to use a single broadcast address scheme on a network. Most IP implementations allow the network manager to set the address to be used as the broadcast address. Many implementations of IP, including the one on your router, can accept and interpret all possible forms of broadcast addresses.

You can use two broadcast-related IP commands to perform broadcast-related tasks.

• Use to broadcast to all addresses in the host portion of an IP address.

• You specify an IP address to set the broadcast address.

• Example

host1(config-if)#ip broadcast-address 255.255.255.255

• Use the no version to restore the default IP broadcast address.

• See ip broadcast-address

• Use to enable translation of directed broadcasts to physical broadcasts.

• Example

host1(config-if)#ip directed-broadcast

Page 48

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use the no version to disable the function.

• See ip directed-broadcast

Fragmentation

Fragmentation is the process of segmenting a large IP datagram into several smaller pieces. Fragmentation is required whenIP musttransmit a large packet through anetwork that transmits smaller packets, or when the MTU size of the other network is smaller.

By default, the router does not fragment the packet if the don’t-fragment bit (DF bit) is set in the IP header. You can specify that the router not consider the DF bit before determining whether to fragment a packet.

NOTE: Lower-layer protocols can also set the MTU value. If MTU values set

in lower layers differ from the one set at the IP layer, the router always uses the MTU lower-layer value.

ip ignore-df-bit

ip mtu

• Use to force the router to ignore the DF bit if it is set in the IP packet header for packets

on an interface.

• Example

host1(config-if)#ip ignore-df-bit

• Use the no version to restore the default behavior,which isto consider the DF bit before

fragmentation.

• See ip ignore-df-bit

• Use to set the MTU size of IP packets sent on an interface.

• The range is 128–10240.

• Do not configure bothMLPPP fragmentation (with the ppp fragmentation command)

and IP fragmentation of L2TP packets (with the ip mtu command) on the same interface. Instead, you must choose only one of the fragmentation configurations by setting it to the necessary value and set the other fragmentation configuration to the maximum allowable value.

• Example

host1(config-if)#ip mtu 1000

• Use the no version to restore the default MTU size.

• See ip mtu

Page 49

IP Routing

The Internet is a large collection of hosts that communicate with each other and use routers as intermediate packet switches.

Routers forward a packet through the interconnected system of networks and routers until the packet reaches a router that is attached to the same network as the destination host. The router delivers the packet to the specified host on its local network.

Routing Information Tables

A router makes forwarding decisions based on the information that is contained in its routing table. Routers announce and receive route information to and from other routers. They build tables of routes based on the collected information about all the best paths to all the destinations they know how to reach.

Each configured protocol has one or more local routing tables, sometimes referred to as a routing information base (RIB). This table is a database local to the protocol that contains all the routes known by that protocol to the prefixes in the table. For example, OSPF might have four different routes to 10.23.40.5.32. Only one of these routes is the best route to that prefix known to OSPF, but all four routes are in the OSPF local routing table.

Chapter 1: Configuring IP

The global routing table is a database maintained by IP on the SRP module. It contains at most one route per protocol to each prefix in the table. Eachof these routes is the best route known by a given protocol to get to that prefix. The IP routing table does not, for example, have two OSPF routes to 10.5.11.0/24; it will have only one (if any) OSPF route to that prefix. It might also have a BGP route to the prefix, and a RIP route to the prefix, but no more than one route to a prefix per protocol.

IP compares the administrative distances for the routes to each prefix and selects the overall best routeregardless of protocol. The best route to 10.5.11.0/24 might be via IS-IS. The best route to 192.168.0.0/16 might be via EBGP, and so on. These selected overall best routes to each prefix are used to create the forwarding table. The forwarding table is pushedto each line module. The line modules usetheir local instance of the forwarding table to forward the packets that theyreceive. Whenthe global IP routingtable is updated, so are the forwarding tables on the line modules.

Figure 10 on page 26 illustrates a very simple network composed of three networks and two routers. The hosts that are attached to each network are not shown, because each router makes its forwarding decisions based on the network number and not on the address of each individual host. The router uses ARP to find the physical address that corresponds to theInternet address forany host orrouter on networks directly connected to it.

Page 50

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Figure 10: Routers in a Small Network

Table 3 on page 26 and Table 4 on page 26 represent information from the routing tables for routers NY and LA. Each routing table contains one entry for each route for each protocol or route type. Each routing table entry includes the following information:

•

The destination IP network address.

•

The IP address of the next-hop router.

•

The type of network, such as static, directly connected, or the particular protocol.

•

An administrative distance that is used to select the least-cost route among multiple routes to the same destination network. The least-cost (best) route is placed in the forwarding table. The administrative distance is not included in the forwarding table.

•

A metric that is used by protocols to which the route is redistributed to select the least-cost route among multiple routes to the same destination network. The metric is not used to determine the best route to be placed in the forwardingtable. The metric is also not listed in the forwarding table.

Table 3: Routing Table for Router NY

Destination Network

Next-Hop Router

Route Type

Administrative Distance

Metric

00connected10.1.0.110.1.0.0/16

10110OSPF10.5.0.310.2.0.0/16

10115IS-IS10.5.0.310.2.0.0/16

1520EBGP10.5.0.310.2.0.0/16

5120RIP10.5.0.310.2.0.0/16

00connected10.5.0.210.5.0.0/30

Table 4: Routing Table for Router LA

Destination Network

Next-Hop Router

Route Type

Administrative Distance

Metric

01static10.5.0.210.1.0.0/16

10110OSPF10.5.0.210.1.0.0/16

Page 51

Table 4: Routing Table for Router LA (continued)

Chapter 1: Configuring IP

Destination Network

Next-Hop Router

Setting the Administrative Distance for a Route

The administrative distance is an integer that is associated with each route known to a router. The distance represents how reliable the source of the route is considered to be. A lower value is preferred over a higher value. An administrative distance of 255 indicates no confidence in thesource; routes with this distance are notinstalledin therouting table.

Table 5 on page 27 lists the default distance for each type of source from which a route can be learned.

Table 5: Default Administrative Distances for Route Sources

Route Type

Default DistanceRoute Source

0Connected interface

Administrative Distance

Metric

4120RIP10.5.0.210.1.0.0/16

00connected10.2.0.110.2.0.0/16

00connected10.5.0.310.5.0.0/30

1Static route

2Internal access route

3Access route

20External BGP

110OSPF

115IS-IS

120RIP

200Internal BGP

255Unknown

If the IP routing table contains several routes to the same prefix—for example, an OSPF route and a RIP route—the route with the lowest administrative distance is used for forwarding.

To set the administrative distance for BGProutes,see JunosEBGP and MPLS Configuration Guide.

Page 52

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

To set the administrative distance for RIP, IS-IS, and OSPF, use the following distance commands in Router Configuration mode.

distance

• Use to set an administrative distance for RIP or OSPF routes in the range 0–255.

• For RIP routes, the default value is 120.

• For OSPF routes, the default value is 110.

• Example

host1(config)#router rip host1(config-router)#distance 100

• Use the no version to restore the default value.

• See distance

distance ip

• Use to set the administrative distance for IS-IS routes in the range 1–255.

• Example

host1(config)#router isis host1(config-router)#distance 80 ip

• Use the no version to restore the default value of 115.

• See distance ip

Setting the Metric for a Route

For information about how to set a metric for a route, see JunosE IP Services Configuration Guide as well as the individual routing protocol chapters in the JunosE BGP and MPLS Configuration Guide , and in this guide.

Routing Operations

Routers keep track of next-hop information that enables a data packet to reach its destination through the network. A router that doesnot have a direct physical connection to the destination checks its routing table and forwards packets to another next-hop router that is closer to that destination. This process continues until the packet reaches its final destination.

Identifying a Router Within an Autonomous System

The router ID is commonly one of the router’s defined IP addresses. Although the router ID is, by convention, formatted as an IP address, it is not required to be a configured address of the router. If you do not use the ip router-id command to assign a router ID, the router uses one of its configured IP addresses as the router ID.

ip router-id

Page 53

• Use to assign a router ID—a unique identifier that IP routing protocols use to identify

the router within an autonomous system.

• Example

host1(config)#ip router-id 192.32.15.23

• Use the no version to remove the router ID assignment.

• See ip router-id

Establishing a Static Route

You can set a destination to receive and send traffic by a specific route through the network.

ip route

• Use to establish a static route.

• Example

host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1

Chapter 1: Configuring IP

• Use the no version to remove a static route from the routing table.

• See ip route

Configuring Static Routes with Indirect Next Hops

You can configurestatic routes where next hops are not on directly connected interfaces. Such a route is usable, and appears in the route table, only if another route in the route table can resolve the next hop.

The resolving route can be either statically created or dynamically learned by a routing protocol (like RIP, BGP, OSPF, and so on).

NOTE: When configuring this type of static route, the route that resolves the

next hop must have an administrative distance value that is better (lower) than the distance of the static route you want to resolve.

Figure 11: Static Routes with Indirect Next Hops

On the Boston router in the network shown in Figure 11 on page 29:

Page 54

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

1. Configure a static route to 10.2.0.0/16 with a next hop of 10.5.0.2 (which is not directly

connected) and an administrative distance of 254 (which is worse [higher] than the default administrative distance for static routes [1]).

host1(config)#ip route 10.2.0.0 255.255.0.0 10.5.0.2 254

2. Configure anotherstatic route that resolves10.5.0.2and uses thedefaultadministrative

distance.

host1(config)#ip route 10.5.0.0 255.255.255.252 10.1.0.2 [ 1 ]

A static route to 10.2.0.0 is added to the route table with a next hop of 10.1.0.2 (on the directly connected Ethernet interface).

NOTE: The previous example shows the default administrative distance

value, 1, to illustrate the difference between the two static route commands. However, you do not have to enter this value when issuing the command.

NOTE: A dynamically learned route can also resolve indirect next hops, as long as the administrative distance value of the learned route is better (lower) than the static route whose next hop is being resolved.

Verifying Next Hops for Static Routes

You can configure either Bidirectional Forwarding Detection (BFD) or Response Time Reporter (RTR) probes to further control when a static route is installed in the routing table. Using either BFD or RTR, static route installation is based on two factors: whether the next hop to the specified destination is resolved, and whether an IP service running above the static route application is currently available.

Next-hop verification is useful for static route configurations in which the layer 2 and layer 3 interfaces are up and the next hop to the specified destination is available, but the IP services that run above the static route are currently unavailable. When the upper-layer IP services are unavailable, the router does not install the static route in its routing table.

How BFD Next-Hop Verification Works

Static routes on E Series routers can use Bidirectional Forwarding Detection (BFD) to verify the availability of the next hop and obtain the state of the IP service. For additional information about BFD, see JunosE IP Services Configuration Guide.

If you specify the bfd-liveness-detection keywords with a minimum receive interval, minimum transmit interval, or multiplierwhen youissue the ip route command toestablish a static route, the router verifies the next-hop status and installs the static route in the routing table under the following conditions:

Page 55

Chapter 1: Configuring IP

•

You configure the static routes with the actual next hop address and not just interface details.

•

The BFD protocol is operational on both ends of the verification.

•

The next hop is adjacent to the router (that is, only one hop away).

NOTE: BFD next-hop verification does not currently function in a multi-hop

configuration.

•

The next hop to the specified IP destination address is resolved.

You can further control the installation of static routes by specifying the last-resort keyword, which is valid when you use the bfd-liveness-detection keywords in the ip route command. The last-resort keyword instructs the router to install the static route in the routing table even if the specified BFD operation is unreachable, provided that no other static route to the same network prefix is available.

The static route is removed from the routing table if the next hop is no longer reachable and reinstalled when the route becomes reachable again.

BFD Next Hop Verification Configuration Example

To enable BFD next hop verification between two adjacent peers, you configure each peer as follows:

1. Configure peer A with the next hop address of peer B along with the desired intervals

and keyword options.

host1(config)#ip route 192.1.1.0 255.255.255.0 192.1.2.1 verify bfd-liveness-detection

minimum-interval 500 multiplier 3 last-resort

2. Configure peer B with the next hop address of peer A along with the desired intervals

and keyword options.

host1(config)#ip route 192.1.2.1 255.255.255.0 192.1.1.0 verify bfd-liveness-detection

minimum-interval 300 multiplier 3

ip route verify bfd-liveness-detection

• Use to enable BFD on a static route.

• Use the minimum-interval keyword to specify a value in the range 100–65535

milliseconds. This keyword defines both the minimum receive interval and minimum transmit interval using the same value.

• Use the minimum-receive-interval keyword to specify a minimum receive interval

value in the range 100–65535 milliseconds.

• Use the minimum-transmit-interval keyword to specify a minimum transmit interval

value in the range 100–65535 milliseconds.

• Use the multiplier keyword to specify a multiplier number in the range 1–255.

• Optionally, you can include the last-resort keyword when you use the verify

bfd-liveness-detection keywords to instruct the router to install the static route in the

Page 56

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

routing table even if the specified BFD operation is currently unreachable, provided that no other static route to the same network prefix is available.

• Change parameters at any time without stopping or restarting the existing session;

BFD automatically adjusts to the new parameter value. However, no changes to BFD parameters take place until the values resynchronize with each BFD peer.

• Example 1—Next hop address and last resort

host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1 verify

bfd-liveness-detection minimum-interval 800 multiplier 2 last-resort

• Example 2—Next hop address and interface

host1(config)#ip route 192.56.15.24 255.255.255.0 192.66.0.2 fast 6/0 verify

bfd-liveness-detection

• Example 3—Next hop address with different receive and transmit intervals

host1(config)#ip route 192.56.15.23 255.255.255.0 192.66.0.1 verify

bfd-liveness-detection minimum-receive-interval 800 minimum-transmit-interval 300 multiplier 2 last-resort

• Use the no version to remove the staticroute from therouting table and therebyremove

BFD from that static route.

• See ip route

How RTR Next-Hop Verification Works

Staticrouteson ESeries routers can useResponse Time Reporter (RTR) probes configured as echo (ping) types to verify the availability of the next hop and obtain the state of the IP service. For more information about using RTR, see “Response Time Reporter” on page 62.

If you specify the verify rtr keywords with an RTR operation number when you issue the ip route command to establish a static route, the router verifies the next-hop status and installs the static route in the routing table only if both of the following conditions are met:

•

The next hop to the specified IP destination address is resolved.

•

The specified RTR operation is currently reachable.

You can further control the installation of static routes by specifying the last-resort keyword, which is valid only whenyou use the verify rtr keywords in the ip route command. The last-resort keyword instructs the router to install the static route in the routing table even if the specified RTR operation is unreachable, provided that no other static route to the same network prefix is available.

Although the configuration example in the next section uses Fast Ethernet interfaces, E Series routers support next-hop verification on any type of lower-layer interface.

RTR Configuration Example

Figure 12 on page 33shows a sampleconfiguration that illustrates thenext-hop verification feature. In this example, two Fast Ethernet interfaces are configured between a remote

Page 57

Chapter 1: Configuring IP

system and an E Series router: Fast Ethernet interface 4/0 and Fast Ethernet interface 4/1. At any given time, only one of these interfaces forwards IP traffic, even though the associated layer 2 interfaces may be up concurrently.

On theE Series router, Fast Ethernet interfaces 4/0 and 4/1 areconfiguredas unnumbered IP interfaces. In addition, each interface has an RTR probe configured as an echo type that sends requestsover the interface to determine its availability. RTR 10sends requests over Fast Ethernet interface 4/0, and RTR 11 sends requests over Fast Ethernet interface 4/1.

In this example, both RTR 10 and RTR 11 use the IP address of the remote system (10.1.1.2) as the target address. When you configure multiple RTR entries to use the same target address, you must set the receive-interface attribute to specify the interface on which the probe expects to receive responses. (See Step 4c in the next section, “Configuring RTR Next-Hop Verification” on page 34.) This action enables the router to map incoming responses to the proper RTR entry, even when multiple RTR entries have the same target address.

Figure 12: Sample Configuration for Next-Hop Verification

The ip route command is issued for each interface with the verify rtr and last-resort keywords to establish the necessary static routes. (See Steps 6 and 7 in the next section, “Configuring RTR Next-Hop Verification” on page 34.) This command causes the results described in Table 6 on page 33, based on the status of the associated RTR operations.

Table 6: Next-Hop Verification Results for Sample Configuration

ResultsRTR 11 StatusRTR 10 Status

UpUp

DownUp

UpDown

The router installs an equal-cost multipath (ECMP) route to 10.1.1.2 in therouting table, using Fast Ethernet interfaces 4/0 and 4/ 1 as the next hops.

The router installs a route to 10.1.1.2, using Fast Ethernet interface 4/0 as the next hop.

The router installs a route to 10.1.1.2, using Fast Ethernet interface 4/1 as the next hop.

Page 58

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Table 6: Next-Hop Verification Results for Sample Configuration

(continued)

ResultsRTR 11 StatusRTR 10 Status

DownDown

Although both RTRoperations aredown, thelast-resort keyword instructs the router to install an ECMP route to 10.1.1.2, using Fast Ethernet interfaces 4/0 and 4/1 as the next hops.

When all of the RTR operations associated with your static routes are down, you can control which route is installed in therouting table by includingthe last-resort keyword in the ip route verify rtr command only for the route that you want to install.

The next section, “Configuring RTR Next-Hop Verification” on page 34, provides instructions for configuring the example shown in Figure 12 on page 33.

Configuring RTR Next-Hop Verification

To configure the next-hop verification example shown in Figure 12 on page 33:

1. Configure a loopback interface, and assign an IP address and mask to the interface.

host1(config)#interface loopback 0 host1(config-if)#ip address 10.1.1.1 255.255.255.255 host1(config-if)#exit

2. Configure Fast Ethernet port 4/0 with an unnumbered primary IP interface associated

with the loopback interface configured in Step 1.

host1(config)#interface fastEthernet 4/0 host1(config-if)#ip unnumbered loopback 0 host1(config-if)#exit

3. Repeat Step 2 for Fast Ethernet port 4/1.

host1(config)#interface fastEthernet 4/1 host1(config-if)#ip unnumbered loopback 0 host1(config-if)#exit

4. Define probe RTR 10 for Fast Ethernet interface 4/0.

a. Assign anoperationnumber to theRTR probe, andaccessRTR Configurationmode.

For information, see “Configuring the Probe Type” on page 63.

host1(config)#rtr 10 host1(config-rtr)#

b. Configure the RTR probe as an echo type, and set the IP destination address and

source interface.

You must configure the RTR probe as an echo type to use next-hop verification. For information, see “Configuring the Probe Type” on page 63.

host1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.2

source fastEthernet 4/0

c. Specify the interface on which the RTR probe expects to receive responses.

Page 59

Chapter 1: Configuring IP

You must set the receive-interface attribute when multiple RTR operations use the same target address. For information, see “Setting the Receiving Interface” on page 67.

host1(config-rtr)#receive-interface fastEthernet 4/0

d. (Optional) Configure optional probe characteristics, such as the frequency and

samples-of-historykept. For information, see“ConfiguringOptional Characteristics” on page 64.

host1(config-rtr)#frequency 1 host1(config-rtr)#samples-of-history-kept 0

e. Exit RTR Configuration mode.

host1(config-rtr)#exit

f. Enable the probe to react to the test-failure event and the test-completion event.

You must configure both the test-failure and test-completion reaction conditions to use next-hop verification. For information, see “Setting Reaction Conditions” on page 68.

host1(config)#rtr reaction-configuration 10 test-failure 3 host1(config)#rtr reaction-configuration 10 test-completion

g. Schedule the probe operation. For information, see “Scheduling the Probe” on

page 69.

host1(config)#rtr schedule 10 life 3 host1(config)#rtr schedule 10 restart-time 1 host1(config)#rtr schedule 10 start now

5. Repeat Step 4 to define RTR 11 for Fast Ethernet interface 4/ 1.

host1(config)#rtr 11 host1(config-rtr)#type echo protocol ipIcmpEcho 10.1.1.2

source fastEthernet 4/1

host1(config-rtr)#receive-interface fastEthernet 4/1 host1(config-rtr)#frequency 1 host1(config-rtr)#samples-of-history-kept 0 host1(config-rtr)#exit host1(config)#rtr reaction-configuration 11 test-failure 3 host1(config)#rtr reaction-configuration 11 test-completion host1(config)#rtr schedule 11 life 3 host1(config)#rtr schedule 11 restart-time 1 host1(config)#rtr schedule 11 start now

6. Establish a static route associated with RTR 10.

This command creates a static route and installs it in the routing table only if RTR 10 is currently reachable or if no other static route to IP destination address 10.1.1.2 is usable.

host1(config)#ip route 10.1.1.2 255.255.255.255 10.1.1.2 fastEthernet 4/0 verify rtr 10

7. Establish a static route associated with RTR 11.

last-resort

Page 60

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

This command creates a static route and installs it in the routing table only if RTR 11 is currently reachable or if no other static route to IP destination address 10.1.1.2 is usable.

host1(config)#ip route 10.1.1.2 255.255.255.255 10.1.1.2 fastEthernet 4/1 verify rtr 11

last-resort

When both RTR 10 and RTR 11 are unreachable, you can control which static route is installed in the routing table by including the last-resort keyword in the ip route verify rtr command only for the route that you want to install.

interface fastEthernet

• Use to select a Fast Ethernet (FE) interface on a line module or an SRP module.

• Example

NOTE: For detailedinformation about the commands for configuring RTR probes, see “Response Time Reporter” on page 62.

interface loopback

host1(config)#interface fastEthernet 1/0

• Use the no version to remove IP from an interface or subinterface. You must issue the

no version fromthe highestleveldown; you cannotremovean interface or a subinterface

if the one above it still exists.

NOTE: For more details on use of this command, see the syntax description

in the JunosE Command Reference Guide.

• See interface fastEthernet

• Use to access and configure a loopback interface.

• You can use a loopback interface to provide a stable IP address that can minimize the

impact if a physical interface goes down.

• Example

host1(config)#interface loopback 10 host1(config-if)#ip address 100.20.32.1 255.255.255.255

• You cannot shutdown a loopback interface.

BEST PRACTICE: We recommend that you configure a 32-bit subnet mask for the loopback interface. For example, if you configure a loopback interfacewith the IP address and mask as 1.1.1.1/16, the 1.1.0.0/16 route entry is entered on the line module and all traffic destined to the to 1.1.0.0/16 subnet is forwarded to the SRP module by the line module. Although the SRP module responds only to traffic destined to the 1.1.1.1 subnet and

Page 61

ip address

Chapter 1: Configuring IP

discards traffic to all other host IP addresses within that subnet (1.1.1.1/16), if no specific or longer route entry is found or if the SRP module receives too much traffic from subnets other than 1.1.1.1, the CPU utilization on the SRP module reaches the saturation level.

If you use a subnet mask other than a /32 mask for the IP address configured on the loopback interface, traffic from the entire subnet is routed to the loopback interface. Therefore, that subnet cannot be routed through any other interface on the router,unless a more specific route points to another interface.

• Use the no version to delete the loopback interface.

• See interface loopback

• Use to set an IP address for an interface or a subinterface.

ip route verify rtr

• Specify the layer 2 encapsulation before you set the IP address.

• Example

host1(config-subif)#ip address 192.0.2.50 255.255.255.0

• Use the no version to remove the IPaddress or todisable IP processing onthe interface.

• See ip address

• Use to establish a static route and associate it with a configured RTR operation.

• Use the verifyrtr keywords to instruct the router to install the static route in the routing

table only if the next hop to the specified destination address is resolved and if the specified RTR operation is currently reachable. When you use the verify rtr keywords, you must also specify the number of the associated RTR operation.

• Optionally, you can include the last-resort keyword when you use the verify rtr

keywords to instruct the router to install the static route in the routing table even if the specified RTR operation is currently unreachable, provided that no other static route to the same network prefix is available.

• Example

host1(config)#ip route 10.1.1.5 255.255.255.0 10.1.1.5 fastEthernet 1/0 verify rtr 5

last-resort

• Use the no version to remove a static route from the routing table.

• See ip route

ip unnumbered

Page 62

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use to configure an unnumbered IP interface.

• This command enables IP processing on an interface without assigning an explicit IP

address to the interface.

• You must specify an interface location, which is the identifier of another interface on

which the router has an assigned IP address. This interface cannot be another unnumbered interface.

• Example 1

host1(config-if)#ip unnumbered fastEthernet 3/0

• Example 2

host1(config-if)#ip unnumbered loopback 10

• Use the no version to disable IP processing on the interface.

• See ip unnumbered

Setting Up Default Routes

A router examines its routing table to find a path for each packet. If the router cannot locate a route, it must discard the packet. You can set up a default route usingthe special address: 0.0.0.0. If the router cannot locate a path to a destination network and a default route is defined, the router forwards the packet to the default router. For example:

host1(config)#ip route 0.0.0.0 0.0.0.0 192.56.21.3

Default routes are typically used to reduce the size of the routing table. Routing is simplified because the router can test for a few local networks or use the default route. However, a disadvantage of default routes is the possible creation of multiple paths and routing loops.

Setting Up an Unnumbered Interface

An unnumbered interface does not have an IP address assigned to it. Unnumbered interfaces are often usedin point-to-point connections where an IP addressis notrequired.

ip unnumbered

• Use to set up an unnumbered interface.

• This command enables IP processing on an interface without assigning an explicit IP

address to the interface.

• You supply an interface location, which is the type and number of another interface

on which the router has an assigned IP address. This interface cannot be another unnumbered interface.

• Example

host1(config-if)#ip unnumbered fastEthernet 0/0

• Use the no version to disable IP processing on an interface.

• See ip unnumbered

Page 63

Adding a Host Route to a Peer on a PPP Interface

You can enable the ability to create host access routes on a PPP interface. This feature is useful in B-RAS applications.

ip access-routes

• Use to enable the ability to create host access routes on a PPP interface.

• Example

host1(config-if)#ip access-routes

• Use the no version to disable this feature.

• See ip access-routes

Enabling Source Address Validation

Sourceaddress validation verifies that a packet has been sentfrom avalid source address. When a packet arrives on an interface, the router performs a routing table lookup using the source address. The result from the routing table lookup is an interface to which packets destined for that address are routed. This interface must match the interface on which the packet arrived. If it does not match, the router drops the packet.

Chapter 1: Configuring IP

ip sa-validate

• Use to enable source address validation.

• Example

host1(config-if)#ip sa-validate

• Use the no version to disable source address validation.

• See ip sa-validate

Enabling Source Address Validation Traps

The ip sa-validate trap-enable command enables the generation of traps for source address validation failure.

NOTE: To fully enable source address validation traps, you must also enable

the IP trap categorywith the snmp-server trap enable command. See JunosE System Basics Configuration Guide for more information.

ip sa-validate trap-enable

• Use toenable the generation of traps for source address validation failureon therouter.

• You can specify a VRF context for which you want to enable trap validation for source

address validation.

• Example

Page 64

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

host1(config)#ip sa-validate trap-enable

• Use the no version to disable the generation of source address validation failure traps

on the router.

• See ip sa-validate trap-enable

Defining TCP Maximum Segment Size

The ip tcp adjust-mss command enables you to modify the TCP maximum segment size (MSS) for TCP sessions.

When defined, the router modifies the maximum segment size (MSS) for TCP SYN packets traveling through the interface. The modification occurs only for packets that contain values smaller than the adjusted MSS value. When the packet does not contain an MSSfield value, the routerassumes an MSSvalue of 536 and makesany modifications accordingly.

NOTE: Implementation of the MSS value is identical for both ingress and

egress interface traffic. That is, the router uses the same MSS value when adjusting inbound or outbound TCP traffic.

ip tcp adjust-mss

• Use tomodify themaximum segment size(MSS) for TCP SYNpacketstravelingthrough

the interface. The router compares the MSS value of incoming or outgoing packets against the adjusted MSS setting and replaces smaller values that it detects in any packets with the larger setting. If the packet does not contain an MSS value, the router assumes a value of 536 for the packet MSS on which to base the comparison.

NOTE: The purpose behind using MSS is to alleviate problems with Path

Discovery (PMTUD) and resulting “ black hole” detection issues. (See RFC 2923, “ TCPProblemswith Path MTU Discovery,” for additional information about the “ black hole” scenario.)

• Example

host1(config-if)#ip tcp adjust-mss 1000

• Use the no version to remove the MSS assignment from the profile.

• See ip tcp adjust-mss

Setting MSS for TCP Connections

MSS is used by TCP to define the maximum amount of data that a TCP interface can accept in any single packet (or segment size). The MSS value is typically negotiated during connection establishment and is not renegotiated.

Page 65

tcp mss

Chapter 1: Configuring IP

By default, the router uses an MSS value of 536 bytes and the advertised MSS is derived from theMTU of the transmittinginterface. However, you can use the tcp mss command to set the MSS for TCP advertisements.

• Use to specify the MSS value for TCP to advertise.

NOTE: The MSS value is equal to the MTU value minus the IP and TCP headers, so the MSS value is generally 40 bytes less than the MTU.

• Use the vrfName variable to specify a VRF to which you want to assign the TCP MSS

value.

• Example

host1(config-if)#tcp mss 1000

• Use the no version to remove the MSS value so that the router uses the advertised

MSS derived from the MTU of the output interface.

• See tcp mss

Configuring IP Path MTU Discovery

IP hosts transmit large amounts of data to other hosts using a series of IP datagrams. To best use resources, increase performance, and avoid difficult reassembly, hosts try to send datagrams that are as large aspossible without requiringfragmentationanywhere along the path from the source to the destination. This datagram size is referred to as the path MTU (PMTU), and it is equal to the smallest MTU for each hop in the path.

Path MTU discovery is the process of discovering the PMTU value and using that value when transmitting TCP packets in datagrams.

Enabling PMTU Discovery

Use the tcp path-mtu-discovery command to enable PMTU discovery on the active virtual router.

tcp path-mtu-discovery

• Use to enable and configure path MTU discovery on the virtual router.

• Issue the command without any keywords to enable path MTU discovery.

• Issue the age-timer keyword to setthe time(minutes) that TCP waits before attempting

to increase the path MTU after receiving an ICMP Too Big message or after previously increasing the PMTU successfully (minutes2). The range of these two timers is 1–30 minutes. The timer defaults to 10 minutes.

• Issue the age-timer infinite keyword to disable PMTU aging functions.

• Example 1—Enables path MTU discovery

host1:VR1(config)#tcp path-mtu-discovery

Page 66

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Example 2—Sets path MTU discovery age timers differently

host1:VR1(config)#tcp path-mtu-discovery age-timer 20 15

• Example 3—Sets path MTU discovery age timers to the same value

(5 minutes)

host1:VR1(config)#tcp path-mtu-discovery age-timer 5

• Example 4—Disables path MTU discovery age timers

host1:VR1(config)#tcp path-mtu-discovery age-timer infinite

• Use the noversion witha keyword to return the valueto itsdefault. Issue the noversion

without any keywords to disable path MTU discovery on the virtual router.

• See tcp path-mtu-discovery

Limiting PMTU

You can limitcalculatedPMTU values within a range by using the tcp path-mtu-discovery max-mtu and tcp path-mtu-discovery min-mtu commands. When specifying PMTU

limits, keep the following in mind:

•

If a PMTU discovery value is lower than the configured minimum MTU setting, PMTU discovery is disabled for that connection.

•

If a PMTU discovery value is larger than the configured maximum MTU setting, the configured maximum MTU setting is used.

•

The maximum MTU setting must be greater than the minimum MTU setting.

tcp path-mtu-discovery max-mtu

• Use to limit the maximum MTU size used for the path MTU.

• Example

host1:VR1(config)#tcp path-mtu-discovery max-mtu 512

• Use the no version to remove any limitation so that the virtual router uses the path

MTU discovery value.

• See tcp path-mtu-discovery

tcp path-mtu-discovery min-mtu

• Use to specify the minimumMTU valueused for the path MTU.If the discovered PMTU

value is less than the minimum setting, path MTU discovery is disabled for this connection.

• Example

host1:VR1(config)#tcp path-mtu-discovery min-mtu 255

• Use the no version to remove any limitationso that thevirtual router uses the discovered

path MTU value.

• See tcp path-mtu-discovery

Page 67

Specifying Black Hole Thresholds

A black hole threshold is a limit to the number of times a virtual router can retransmit identical sequences ofdatagramsbeforethe retransmissions are identifiedas a problem.

Some domains mightbe configurednot to generatecertain ICMP messages (like an ICMP destination unreachable message) or to filter all ICMP messages. Under these conditions, the source of oversized ICMP packets never learns that it is sending oversized packets. The device continues sending oversized packets that never get through. This behavior is often referred to as a black hole.

tcp path-mtu-discovery black-hole-detect-threshold

• Use to specify the minimumMTU valueused for the path MTU.If the discovered PMTU

value is less than the minimum setting, path MTU discovery is disabled for this connection.

• Example

host1:VR1(config)#tcp path-mtu-discovery black-hole-detect-threshold 200

Chapter 1: Configuring IP

• Use the no version to disable black hole threshold detection.

• See tcp path-mtu-discovery

Shutting Down an IP Interface

You can disable an interface to the router at the IP level without removing it.

ip shutdown

• Use to shut down an IP interface.

• Example

host1(config-if)#ip shutdown

• Use the no version to restart the interface.

• See ip shutdown

Removing the IP Configuration

You can remove the IP configuration from an interface or subinterface.

no ip interface

Use to remove the IP configuration from an interface or subinterface and disable IP

•

processing on the interface.

• Example

host1(config-if)#no ip interface

• See no ip interface

Page 68

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Clearing IP Routes

The router enables you to clear the specified routing entries from the routing table. You must specify the IP address prefix and the mask of the IP address prefix to clear specific routes. You can later reinstall the routes you have cleared.

clear ip routes

• Use toclear specified IP routes according to an IP prefixor aVPN routingand forwarding

(VRF) table.

• Use an asterisk (*) to clear all dynamic routes from the routing table.

• Example

host1#clear ip routes *

• There is no no version.

• See clear ip routes

ip refresh-route

Clearing IP Interfaces

clear ip interface

Setting a Baseline

• Use to enable the owning protocols (BGP, IS-IS, OSPF) to reinstall routes removed

from the IP routing table by the clear ip routes command.

• Example

host1#ip refresh-route

• There is no no version.

• See ip refresh-route

The router enables you to clear the counters on one or more specified IP interfaces.

• Use to clear a specified IP interface.

• Example

host1#clear ip interface pos 2/0

• There is no no version.

• See clear ip interface

The router enables you to set a baseline for statistics on an IP interface.

baseline ip interface

• Use to set a baseline for a specified IP interface.

• Example

Page 69

host1#baseline ip interface pos 2/0

• There is no no version.

• See baseline ip interface

Disabling Forwarding of Packets

The router enables you to disable forwarding of packets on an SRP Ethernet interface.

ip disable-forwarding

• Use to disable forwarding of packets on the SRP Ethernet interface.

• The purpose of this command is to maintain router performance by maximizing the

CPU time available for routing protocols. Although you can allow data forwarding on the SRP Ethernet interface, router performance will be affected.

• You see an error message if you try to set this command for interfaces other than the

SRP Ethernet interface.

• Example

Chapter 1: Configuring IP

host1(config-if)#ip disable-forwarding

• Use the no version to enable forwarding of packets on the interface.

• See ip disable-forwarding

Enabling Forwarding of Source-Routed Packets

IP packets are normally routed according to the destination address they contain based on the routing table at each hop through a path. The originator or source of the source-routed packets specifies the path (the series of hops) that the packets must traverse; the source makes the routing decisions. The source can specify either of the following types of source routing:

•

Strict-source routing specifies every hop that the packet must traverse. The specified path consists of adjacent hops. The source generates an ICMP error if the exact path cannot be followed. For example, for a path going from source router A to router B to router C to router D, router A specifies a strict-source route as B, C, D.

•

Loose-source routing specifies a set of hops that the packet must traverse, but not necessarilyeveryhop inthe path. That is, thespecified hopsdo not haveto be adjacent. For example, for a path going from source router A to router B to router C to router D, router A specifies a loose-source route as B, D or C, D, or B, C, D.

ip source-route

• Use to enable forwarding of source-routed packets in a VR or VRF.

• Forwarding is disabled by default in all VRs.

• Example

host1(config)#ip source-route

Page 70

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use the no version to disable forwarding of source-routed packets on the VR or VRF.

• See ip source-route

Forcing an Interface to Appear Up

The router enables you to force an IP interface to appear as if it is up, regardless of the state of the lower layers.

ip alwaysup

• Use to force an IP interface to appear as up regardless of the state of lower layers.

• This command reduces route topology changes when the network attached to this

link is single-homed.

• Example

host1(config-if)#ip alwaysup

• Use the no version to make the interface appear in the current state.

• See ip alwaysup

Specifying a Debounce Time

You can set a debounce time that requires an IP interface to be in a given state—for example, up or down—for the specified time before the state is reported. This feature preventsa linkthat briefly goes upor down from causing anunnecessarytopologychange, for example by causing an interface down condition. However, note that increasing the debounce time increases the latency of updating the routing table to reflect an up or down change, and the latency of routing protocols propagating the state change.

ip debounce-time

• Use to set the interval in milliseconds for which an interface must maintain a given

state before the state change is reported.

• Example

host1(config)#ip debounce-time 5000

• Use the no version to remove the debounce time requirement.

• See ip debounce-time

Adding a Description

The router enables you to add a text description or an alias to a static IP interface or subinterface. Adding a description helps you identify the interface and keep track of interface connections. If no IP interface currently exists, then a static IP interface is automatically created on the current layer 2 interface and the description is applied to that static IP interface. You cannot assign a profile to a layer 2 interface that has a static interface configured above it.

Page 71

ip description

Chapter 1: Configuring IP

NOTE: The ip description command is replacing the description command

to assign a description to a static IP interface.

• Use to assign a text description or an alias to an IP interface or subinterface.

• The description or alias can be a maximum of 256 characters.

• Use the show ip interface command to display the text description.

• Example 1

host1(config-if)#ip description canada01 ip interface

• Example 2

host1(config-subif)#ip description montreal011 ip subinterface

• Use the no version to remove the text description or alias.

• See ip description

Enabling Link Status Traps

The router enables you to enable link status traps on an interface.

snmp trap ip link-status

• Use to enable link status traps on an interface.

• Example

host1(config-if)#snmp trap ip link-status

• Use the no version to disable link status traps on an interface.

• See snmp trap ip link-status

Configuring the Speed

The router enables you to set the speed of an IP interface.

ip speed

• Use to set the speed of the interface in bits per second.

• By default, the speed is determined from a lower-layer interface.

• Example

host1(config-if)#ip speed 1000

• Use the no version to set the speed to the default, 0.

• See ip speed

Page 72

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

Configuring Equal-Cost Multipath Load Sharing

Equal-cost multipath (ECMP)sets are formed whenthe router finds routing table entries for the same destination with equal cost. The router then balances traffic across these sets of equal-cost paths by using one of two ECMP modes—hashed (the default) or round-robin.

Hashed mode uses hashing of source and destination addresses to determine which of the available paths in the ECMP set to use. Hashed mode is the default ECMP mode of operation.

Defining Maximum Paths

You can add routing table entries manually (as static routes), or they are formed as routers discover their neighbors and exchange routing tables (via OSPF, BGP, and other routing protocols).

The maximum paths command controls the maximum number of parallel routes that the routing protocol (BGP, IS-IS, OSPF, or RIP) can support.

ip multipath round-robin

Round-Robin Mode

Round-robin mode distributes packets equally among the available paths in the ECMP set.

If all the ECMP links are configured for the ip multipath round-robin command and their next hops are direct next hops, the round-robin mode uses the random algorithm for traffic distribution.

In round-robin mode, if a packet uses a path, the next packet can choose the same path or the previous path, or the next pathbased on the random value generated.The random algorithm does not guarantee equal distribution of the packets among the ECMP links.

• Use to specify round-robin as the mode for ECMP load sharing on an interface.

• ECMP uses the round-robin mode when you have configured all interfaces in the set

to round-robin. Otherwise,ECMP defaults to hashed modebecause round-robin mode can cause reordering of packets. Youmust explicitly ensure that the possiblereordering is acceptable on all the member interfaces by setting them to round-robin mode.

• If one of the ECMP next hops is an indirect next hop, ECMP uses hashed mode load

balancing.

• Example

host1(config)#virtual-router router_0 host1:router_0(config)#interface serial 4/0:1/22.22 host1:router_0(config-subif)#ip multipath round-robin host1:router_0(config-subif)#exit

• Use the no version to set the ECMP mode to the default, hashed.

• See ip multipath round-robin

Page 73

maximum-paths

Chapter 1: Configuring IP

• Use to control the maximum number of parallel routes that the routing protocol

supports.

• The maximum number of routes can be in the range 1–16 for BGP, IS-IS, OSPF, or RIP.

• Example

host1(config-router)#maximum-paths 2

• Use the no version to restore the default value, 1 for BGP or 4 for IS-IS, OSPF, or RIP.

• See maximum-paths

Fast Reroute Protection

If a link goes down, ECMP uses fast reroute protection to shift packet forwarding to use operational links, thereby decreasing packet loss. Fast reroute protection updates ECMP sets for the interface without having to wait for the route table update process. When the next route table update occurs, a new ECMP set can be added with fewer links or the route might point to a single next hop.

Setting a TTL Value

ip ttl

CAUTION: To provide ECMP fast reroute functionality in the event of an interface failure, the members of an equal cost multipath must be resolved to corresponding interfaces. If the member is an indirect next hop, the interface is obtained by using the forwarding equivalence class (FEC) to which the member points. This method of resolving members occurs only if the FEC, pointed to by the indirect next hop, is either an interface or a direct next hop.

An indirect next hop member is not resolved to an interface if it points to another indirect next hop or to an equal cost multipath. ECMP fast reroute functionality is not available if any interfaces that correspond to unresolved indirect next hop members go down.

If you modify an indirect next hop member to point to a different FEC (that is, a different interface, direct next hop, indirect next hop, or ECMP), the indirect next hop member is not resolved for the new changes.

You can use the ip ttl command to set the TTL (time-to-live) field in the IP header for all IP operations. The TTL specifies a hop count. This configured TTL value can be overridden by other commands that specify a TTL.

• Use to set a default value for the IP header TTL field for all IP operations.

• Example

host1(config)#ip ttl 255

Page 74

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use the no version to restore the default value, 127.

• See ip ttl

Protecting Against TCP RST or SYN DoS Attacks

You can use the tcp ack-rst-and-syn command to help protect the router from denial of service (DoS) attacks.

Normally, when it receives an RST or SYN message, TCP attempts to shut down the TCP connection. This action is expected under normal conditions, but someone maliciously generating valid RST or SYN messages can cause problems for TCP and the network as a whole.

When you enable the tcp ack-rst-and-syn command, the router challenges any RST or SYN messages that it receives by sending an ACK message back to the expected source of the message. The source reacts in one of the following ways:

•

If the source did send the RST or SYN message, it recognizes the ACK message to be spurious and resends another RST or SYN message. The second RST or SYN message causes the router to shut down the connection.

•

If the source did not send the RST or SYN message, the source accepts the ACK message as partof anexisting connection. Asa result, the source does notsend another RST or SYN message and the router does not shut down the connection.

NOTE: Enabling this command slightly modifies the way TCP processes

RST or SYN messages to ensure that they are genuine.

tcp ack-rst-and-syn

• Use to help protect the router from TCP RST and SYN denial of service attacks.

• Example

host1(config)#tcp ack-rst-and-syn

• Use the no version to disable this protection.

• See tcp ack-rst-and-syn

Preventing TCP PAWS Timestamp DoS Attacks

The TCP Protect Against Wrapped Sequence (PAWS) number option works by including the TCP timestamp option in all TCP headers to help validate the packet sequence number.

Normally, in PAWS packets that have the timestamps option enabled, hosts use an internal timer tocompare the valueof thetimestamp associatedwith incoming segments against the last valid timestamp the host recorded. If the segment timestamp is larger than the value of thelast valid timestamp, and the sequence number is less thanthe last

Page 75

Chapter 1: Configuring IP

acknowledgement sent, the host updates its internal timer with the new timestamp and passes the segment on for further processing.

If the host detects a segment timestamp that is smaller than the value of the last valid timestamp or the sequence number is greater than the last acknowledgement sent, the host rejects the segment.

A remote attacker can potentially determine the source and destination ports and IP addresses of both hosts that are engaged in an active connection. With this information, the attacker might be able to inject a specially crafted segment into the connection that contains a fabricated timestamp value. When thehost receives this fabricated timestamp, it changes its internal timer value to match. If this timestamp value is larger than subsequent timestamp values from valid incoming segments, the host determines the incoming segments as being too old and discards them. The flow of data between hosts eventually stops, resulting in a denial of service condition.

Use the tcp paws-disable command to disable PAWS processing.

NOTE: Disabling PAWS does not disable other processing related to the TCP

timestamp option. This means that even though you disable PAWS, a fabricated timestamp that already exists in the network can still pollute the database and result in a successful DoS attack. Enabling PAWS resets the saved timestamp state for all connections in the virtual router and stops any existing attack.

tcp paws-disable

• Use to disable the Protect Against Wrapped Sequence (PAWS) number option in TCP

segments.

• You can specify a VRF context for which you want PAWS disabled.

• Example

host1(config)#tcp paws-disable

• Use the no version to restore PAWS processing (the default mode).

• See tcp paws-disable

Protecting Against TCP Out of Order DoS Attacks

You can use the group of tcp resequence-buffers commands to help protect the router from TCP out-of-order DoS attacks.

TCP guarantees that applications receive data in order. This means that TCP buffers any out-of-order packets it receives until ordered delivery can occur. To prevent buffers from consuming too many resources, TCP limits the amount of data it accepts to the number of data bytes that the receiver is willing to receive and buffer.

TCPdoes not takeinto account the buffering schemethatthe receiveruses. If the receiver uses a fixed-size receive buffer (that is, buffering all packets) regardless of length, a

Page 76

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

packet that contains only one databytemight consumemany data bytes of bufferspace, but only one byte of TCP space.

Under these conditions, an attacker can send a large number of 1-byte packets to an E Series router in which each packet is buffered, consuming an entire packet buffer and eventually consuming a large amount of resources.

To defend against this sort of attack, you can set defaults and limits on the number of outstanding buffers on reordering queues. You can configure these defaults and limits on a per-router, per-virtual router, or per-connection basis.

Limiting Buffers per Router

The tcp resequence-buffers global-maximum command enables you tolimit the number of outstanding buffers on the entire router.

tcp resequence-buffers global-maximum

• Use to specify a router-wide maximum number of buffers that resequencing queues

can contain.

• Specify a value of zero (0) to turn off the limit.

• Example

host1(config)#tcp resequence-buffers global-maximum

• Use the no version to revert the global maximum buffer value to its default, 1000

buffers.

• See tcp resequence-buffers global-maximum

Limiting Buffers per Virtual Router

The tcp resequence-buffers default-vr-maximum command and tcp resequence-buffers vr-maximum command enable you to limit the number of

outstanding buffers on existing or newly established virtual routers.

tcp resequence-buffers default-vr-maximum

• Use to specify the default buffer limit assigned to all virtual routers when the virtual

router is established.

• Specify a value of zero (0) to turn off the limit assignment.

• Example

host1(config)#tcp resequence-buffers default-vr-maximum 200

• Use the no version to revert the virtual router maximum valueto its default, 100 buffers.

• See tcp resequence-buffers default-vr-maximum

tcp resequence-buffers vr-maximum

• Use to define the maximum number of buffers that the current or specified virtual

router can use.

• Specify a value of zero (0) to turn off the limit assignment.

Page 77

• Example

host1(config)#tcp resequence-buffers vr-maximum

• Use the no version to revert the virtual router maximum valueto its default, 100 buffers.

• See tcp resequence-buffers vr-maximum

Limiting Buffers per Connection

The tcp resequence-buffers connection-maximum command and tcp resequence-buffers default-connection-maximum command enable you to limit the

number of outstanding buffers on existing or newly established connections.

tcp resequence-buffers connection-maximum

• Use to define the maximum number of buffers that connections on the current or

specified virtual router can use.

• Specify a value of zero (0) to turn off the connection maximum.

• Example

Chapter 1: Configuring IP

host1(config)#tcp resequence-buffers connection-maximum 50

• Use the no version to revert the connection maximum value to its default, 10 buffers.

• See tcp resequence-buffers connection-maximum

cp resequence-buffers default-connection-maximum

• Use to specify the default buffer limit assigned to all TCP connections on a virtual

router unless a specific limit is set for the VR in which the connection is established.

• Specify a value of zero (0) buffers to turn off the default limit.

• Example

host1(config)#tcp resequence-buffers default-connection-maximum 100

• Use the no version to revert the connection maximum value to its default, 10 buffers.

• See tcp resequence-buffers default-connection-maximum

Distributing Routing Table Updates to Line Modules

You can configure the forwarding table hold-down time allotted after a routing table change for the accumulation of additional updates and the subsequent distribution of the set of routing table changes to the line modules.

forwarding-table route-holddown

• Use to enhance SRP performance by increasing the hold-down time allotted for

accumulating and distributing sets of routing table changes to the line modules.

• A higher timer value can enhance SRP performance, but it can also delay the

implementationof routingtable changes onthe linemodules. Be aware ofthe possible effecton network performance before you reconfigure the forwarding table hold-down timer.

Page 78

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Setting the hold-down timer to zero (0) distributes an update after each change to

the routing table, which can degrade SRP performance.

• Example

host1(config)#forwarding-table route-holddown 15

• Use the no version to set the hold-down timer to the default value, 3 seconds.

• See forwarding-table route-holddown

IP Tunnel Routing Table

The IP tunnel routing tables include IPv4 routes that point only to tunnels, such as MPLS tunnels. The tunnel routing table is not used for forwarding. Instead, protocols resolve next hops by looking up the routes that point to tunnels. The routes in the tunnel routing table cannot be redistributed. See JunosE BGP and MPLS Configuration Guide for more information.

Shared IP Interfaces

You can create multiple shared IP interfaces over the same layer 2 logical interface—for example, atm 5/3.101—enabling more than one IP interface to share the same logical resources. You can configure one or more shared IP interfaces. Data sent over shared interfaces uses the same layer 2 interface. You can configure shared interfaces as you would unshared IP interfaces. Each shared interface has its own statistics.

Some layer 2 interfaces require a primary IP interface to negotiate certain IP parameters—for example, IPCP for PPP, ARP for Ethernet, and Inverse ARP for Frame Relay. If you do not configure a primary IP interface in such cases, the layer 2 interface cannot become operationally up.

A primary IP interface is the default interface for receiving data that arrives on the layer 2 interface. If you configure shared IP interfaces for the same layer 2 interface as your primary IP interface, by default data received on the layer 2 interface is received on the virtual router corresponding to the primary IP interface. A primary IP interface and all of its shared IP interfaces have the same interface location. You can configure a shared IP interface to receive data on the same layer 2 interface as a primary IP interface. You can delete primary and shared IP interfaces independently of each other.

You can create a primary IP interface as you do any other IP interface, as shown in the following example:

host1(config)#virtual-router vr-a:vrf-2 host1:vr-a:vrf-2:(config)#interface atm 5/3.101 host1:vr-a:vrf-2:(config-if)#ip address 10.1.1.1 255.255.255.255 host1:vr-a:vrf-2:(config-if)#exit

You do not have to configure a primary IP interface if you do not need one as described above. In the absence of a primary interface, you can still configure shared IP interfaces; however, in this scenario, data received on the layer 2 interface is discarded.

You cannot create shared IP interfaces for the following kinds of interface:

Page 79

•

IP floating interfaces (IP interfaces that stack over MPLS stacked tunnels)

•

Loopback interfaces

•

Null interfaces

For information about configuring shared IP interfaces to receive data on the same layer 2 interface as a primary IP interface, see JunosE Broadband Access Configuration Guide.

Configuring Shared IP Interfaces

To share IP interfaces:

1. Create a layer 2 interface.

host1(config)#interface atm 5/3 host1(config-if)#interface atm 5/3.101

2. (Optional) Create a primary IP interface.

host1(config-if)#ip address 10.1.1.1 255.255.255.255 host1(config-if)#exit

Chapter 1: Configuring IP

interface ip

3. Create the shared IP interface.

host1(config)#interface ip si0

4. Associate the shared IP interface with the layer 2 interface by one of the following

methods:

•

Statically

host1(config-if)#ip share-interface atm 5/3.101

•

Dynamically

host1:vr-a:vrf-1(config-if)#ip share-nexthop 10.0.0.1

5. To fully configure the shared interface, assign an address (or make the interface

unnumbered).

host1(config-if)#ip address 2.2.2.2 255.0.0.0

• Use to create an IP interface for interface sharing.

• Use the specified name to refer to the shared IP interface; you cannot use the layer 2

interface to refer to them, because the shared interface can be moved.

• Example

host1(config)#interface ip si0

• Use the no version to delete the IP interface.

• See interface ip

ip share-interface

Page 80

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use to specify the layer 2 interface used by a shared IP interface. The command fails

if the layer 2 interface does not yet exist. The command is not supported (that is, it fails) if you use an RSVP tunnel (for example, tunnel mpls:1) to identify the layer 2 interface.

• If you issue this command on a shared IP interface, you cannot issue the ip

share-nexthop command for the interface.

• After creating the shared IP interface, you can configure it as you do any other IP

interface.

• The shared interface is operationally up when the layer 2 interface is operationally up.

• Youcan createoperational shared IPinterfaces inthe absence of a primary IP interface.

• Example

host1(config-if)#ip share-interface atm 5/3.101

• Use the no version to remove the association between the layer 2 interface and the

shared IP interface. You can delete shared and primary IP interfaces independently.

• See ip share-interface

ip share-nexthop

• Use to specify that the shared IP interface dynamically tracks a next hop. If the next

hop changes, the shared IP interface moves to the new layer 2 interface associated with the IP interface toward the new next hop.

• If you issue this command on a shared IP interface, you cannot issue the ip

share-interface command for the interface.

• If you issue this command on a shared IP interface, the shared interface cannot

dynamically track the next hop for the specified destination if the next-hop IP address is resolvable over MPLS.

• If you specify a virtual router, the command fails if the VR does not already exist. If you

do not specify a VR, the current VR is assumed.

• After creating the shared IP interface, you can configure it as you do any other IP

interface.

• The shared interface is operationally up when the layer 2 interface associated with the

specified next hop is operationally up. However, if the layer 2 interfaced associated with the specified next hop is an MPLS next hop (for example, an RSVP or LDP tunnel), the shared interface remains operationally down.

• Use the no version to halt tracking of the next hop.

• See ip share-nexthop

Moving IP Interfaces

You can move an IP shared interface from one layer 2 interface to another by issuing the ip share-interface command tospecify adifferentlayer2 interface. Moving an IP interface

Page 81

does not affect interface statistics, packets forwarded through the interface, or policies attached to the IP interface.

Example The following commands create shared interface si0 on the layer 2 interface atm5/3.101:

host1(config)#virtual-router vr-a:vrf-1 host1:vr-a:vrf-1(config)#interface ip si0 host1:vr-a:vrf-1(config-if)#ip share-interface atm 5/3.101 host1:vr-a:vrf-1(config-if)#exit

The following commands move shared interface si0 to the layer 2 interface atm5/3.201:

host1:vr-a:vrf-1(config)#interface ip si0 host1:vr-a:vrf-1(config-if)#ip share-interface atm 5/3.201

IP Shared Interface Statistics

Each sharedinterface has its own statistics. Packets transmitted on a shared IP interface are always counted only in the shared IP interface.

Subscriber Interfaces

Chapter 1: Configuring IP

A subscriber interface is an extension of a shared IP interface. Shared IP interfaces are unidirectional—theycan transmit but not receive traffic. In contrast, subscriber interfaces are bidirectional—they can both receive and transmit traffic.

For details about configuring and using subscriber interfaces, see JunosE Broadband Access Configuration Guide.

Internet Control Message Protocol

IP was not designed to provide reliable delivery service. The higher-layer protocols that operate as clients of IP implement their own reliability procedures if reliable communications are required.

Internet Control Message Protocol (ICMP) provides a mechanism that enables a router or destination host to report an error in data traffic processing to the original source of the packet. ICMP messages provide feedback about problems that occur in the communication environment.

ICMP messages are sent only when errors occur in either the processing of an unfragmented data packet or the first fragment of a fragmented data packet.

ICMP messages are encapsulated as part of the data portion of an IP data packet and are routed like any other IP data packets. Thus, there is no guarantee to the sender of an ICMP message that the message will be delivered to its destination.

The router supports ICMP redirects. When a packet enters an IP interface and exits the same interface, the router may send an ICMP message to the originator of the packet. This message notifies the originator that a better gateway exists to the assigned destination address.

With the ip redirects command (used in Interface Configuration mode) you can enable or disable ICMP redirects. This attribute is enabled by default. If it is enabled on the IP

Page 82

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

interface and if the internal ICMP redirect queue is not full, the router sends an ICMP redirect packet to the originator. When the originator receives the ICMP redirect notification, the originator determines whether to start using the better gateway.

ICMP Tasks

You can enable the following ICMP features:

•

ICMP Router Discovery Protocol (IRDP)

•

ICMP netmask reply

•

Sending of IP redirects

•

Generation of ICMP unreachable messages

ip irdp

• Use to enable IRDP processing on an interface.

• Example

host1(config-if)#ip irdp

ip mask-reply

ip redirects

ip unreachables

• Use the no version to disable the function.

• See ip irdp

• Use to enable ICMP netmask reply.

• Example

host1(config-if)#ip mask-reply

• Use the no version to disable the function.

• See ip mask-reply

• Use to enable the sendingof redirect messages ifsoftware is forced to resend a packet

through the same interface on which it was received.

• Example

host1(config-if)#ip redirects

• Use the no version to disable the sending of redirect messages.

• See ip redirects

• Use to enable the generation of an ICMP unreachable message when a packet is

received that the router cannot deliver.

• Example

host1(config-if)#ip unreachables

Page 83

• Use the no version to disable the function.

• See ip unreachables

Specifying a Source Address for ICMP Messages

By default, ICMP uses the IP address of the outgoing interface as the source IP address for the ICMP message. However, you can use the ip icmp update-source command to instruct ICMP to use an already configured interface or a specified IP address, as the source address of the ICMP message.

For example, you can specify that ICMP use Fast Ethernet interface 1 in slot 0 as the source for any messages that it sends:

host1(config)#ip icmp update-source fastEthernet 0/1

You must use an already configured interface or an existing IP address when using the ip icmp update-source command. Also, you cannot specify a multicast address when using this command.

Chapter 1: Configuring IP

ip icmp update-source

• Use to define an update source address for all ICMP messages that the E Series router

generates from the specified interface.

• Example

host1(config)#ip icmp update-source 192.35.42.1

• Use the no version to disable the function.

• See ip icmp update-source

Reachability Commands

Use the ping and traceroute commands to determine reachability of destinations in the network.

•

Use theping command tosend an ICMP or ICMPv6 echo request packet. In thefollowing example, the request packet is sent to IP address 192.35.42.1, with a packet count of 10 and a timeout value of 10 seconds:

host1#ping 192.35.42.1 10 timeout 10

•

Use the traceroute command to discover routes that router packets follow when travelingto theirdestination. Inthe following example,the trace destination IP address is 192.56.20.1, the maximum number of hops of the trace is 20, and the timeout value is 10 seconds:

host1#traceroute 192.56.20.1 20 timeout 10

ping

• Use to send an ICMPor ICMPv6 echo request packet to the IP address that youspecify.

• You can specify a VRF context.

Page 84

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use the source interface keywords to specify a source interface other than the one

from which the probe originates.

• Use the source address keywords to specify a source IP address other than the one

from which the probe originates.

• You can specify the following options:

• packetCount—Numberof packetsto send tothe destination IP address.If you specify

a zero (0), echo requests packets are sent indefinitely.

• data-pattern—Sets the type of bits contained in the packet to all ones, all zeros, a

random mixture of ones and zeros, or a specific hexadecimal data pattern that can range from 0x0–0xFFFFFFFF. The default is all zeros.

• data-size—Sets the number of bytes comprising the IP packet and reflected in the

IP header in the range 0–64000; the default is 100 bytes.

• extended header attributes—Set the following:

• A value to be set in the type of service (ToS) byte, in the range 0–255, to support

quality of service (QoS) offerings

• Don’t-fragment bit to prevent IP from fragmenting the packet if it is too long for

the MTU of a given link; if the nonfragmented packet cannot be delivered, it is discarded.

• Strict-source or loose-source routing, including the IP address of the hops the

packetsmust traverse.For loose-source-route, you specifysome orall ofthe hops, but they do not have to be adjacent. For strict-source-route, you must specify every adjacent hop through which the packet must traverse.

• The IP addresses tobe recorded for a specified number of routersthat thepackets

traverse.

• The time that a packet traverses a router to be recorded for a specified number

of routers.

• An interface type and specifier of a destination address on the router that is

connected for external loopback by means of a cable or plug that loops Tx to Rx. The command succeeds only if the specified interface is connected for external loopback and the encapsulation type is ATM, Frame Relay, HDLC, or PPP. The command does not work for Ethernet or VLAN encapsulations.

• The traffic class value to match in the Traffic Class field of each packet (IPv6 only)

• The flow label value to match in the Flow Label field of each packet (IPv6 only)

• sweep-interval—Specifies the change in the size of subsequent ping packets while

sweeping across a range of sizes. For example, you can configure the sweep interval to sweep across the range of packets from 100 bytes to 1000 bytes in increments equal to the sweep interval. By default the router increments packets by one byte; for example, it sends 100, 101, 102, 103, ... 1000. If the sweep interval is 5, the router sends 100, 105, 110, 115, ... 1000.

Page 85

Chapter 1: Configuring IP

• sweep-sizes—Enables you to vary the sizes of the echo packets being sent. This

capability is useful for determining the minimum sizes of the MTUs configured on the nodes along the path to the destination address. Determining the minimum size reduces packet fragmentation, which contributes to performance problems. The default is not to sweep (all packets are the same size).

• timeout—Sets the number of seconds to wait for an ICMP echo reply packet before

the connection attempt times out.

• ttl—Sets the time-to-live hop count in the range 1–255; the default is 32.

• The following characters can appear in the display after issuing the ping command:

• !—Reply received

• .—Timed out while waiting for a reply

• ?—Unknown packet type

• A—Address mask request message

• a—Address mask reply message

• D—Router discovery advertisement message

• d—Router discovery request message

• H—Host unreachable

• I—Information request message

• i—Information reply message

• L—TTL expired message

• M—Could not fragment, DF bit set

• m—Parameter problem message

• N—Network unreachable

• P—Protocol unreachable

• Q—Source quench

• r—Redirect message

• T—Timestamp request message

• t —Timestamp reply message

• U—Destination unreachable

• Example

host1(config)#interface serial 5/2:1/1 host1(config-if)#ip address 172.16.1.1 255.255.255.0

Page 86

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

host1(config-if)#exit host1#ping 172.16.1.1 extended interface serial 5/2:1/1

• There is no no version.

• See ping

traceroute

• Use todiscoverthe routes that router packets follow when traveling to their destination.

• You can specify:

• A VRF context

• Destination IP or IPv6 address

• Source interface for each of the transmitted packets

• Source address for each of the transmitted packets

• Maximum number of hops of the trace and a timeout value

• Size of theIP packets (not the ICMP payload) in the range 0–64000 bytes sent with

the traceroute command. Including a size might helplocate any MTU problems that exist between your router and a particular device.

• Extended IP header attributes, including the ToS byte (IP only), whether to set the

DF bit for the transmitted packets (IP only), the traffic class (IPv6 only), and flow label (IPv6 only).

• You can also force transmission of the packets on a specified interface regardless of

what the IP address lookup indicates.

• Example

host1#traceroute 172.20.13.1 20 timeout 10

• There is no no version.

• See traceroute

Response Time Reporter

The Response Time Reporter (RTR) feature enables you to monitor network performance and resources by measuring response times and the availability of your network devices.

RTR configuration is associated with a specific virtual router, distinct from any other virtual router.

Configuration Tasks

To configure RTR:

1. Configure the probe type—an echo probe or a path echo probe.

2. (Optional) Configure probe characteristics:

Page 87

•

frequency

•

hops-of-statistics-kept (path echo)

•

max-response-failure (path echo)

•

operations-per-hop (path echo)

•

owner

•

receive-interface

•

request-data-size

•

samples-of-history-kept

•

tag

•

timeout (echo)

•

tos

Chapter 1: Configuring IP

3. (Optional) Set reaction conditions.

4. Schedule the probe.

5. (Optional) Capture statistics and collect error information.

6. (Optional) Collect history.

Configuring the Probe Type

To begin configuring RTR, enter RTR Configuration mode and configure the probe type—either an echo probe or a path echo probe.

rtr

• Use to configure an RTR probe and to enter RTR Configuration mode.

• Example

host1(config)#rtr 1

• Use the no version to delete all configuration information for an RTR probe.

• See rtr

NOTE: You cannot set any of these characteristics until you have set the probe type. The default values of these characteristics depend on the type of the entry.

type

Use to set an echo or path echo probe:•

• echo—Limited to end-to-end RTR operations; corresponds to SNMP ping

Page 88

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• pathEcho—Finds a path to the destination and echoes each device in the path;

corresponds to SNMP traceroute

• You must specify this value before any other.

• If you change the type for an existing RTR entry, all values are reset, including the

administrative status. There is no default value.

• More than one RTR entry can become active, provided each entry’s target address is

unique.

• If you configure multiple RTR entries to use the same target address, you must issue

the receive-interface command to specify the interface on which the RTR probe expects to receive responses. (For information, see “Setting the Receiving Interface” on page 67.)

• If you use a target address already configured for another RTR entry that is active, the

test will not run if both entriesare in the same virtual router. If they are in distinct virtual routers, however, there is no restriction.

• Example

host1(config-rtr)#type echo protocol ipIcmpEcho 10.10.0.9

• Use the no version to remove the type configured for the probe.

• See type

Configuring Optional Characteristics

In addition to configuring the probe’s type, you can configure the probe characteristics presented in Table 7 on page 64.

Table 7: Probe Characteristics

DescriptionCharacteristic

Time between tests (in seconds)frequency

Hops per path for which statistics are gatheredhops-of-statistics-kept

Maximum number of consecutive failuresmax-response-failure

Number of probes per hopoperations-per-hop

Owner of the probeowner

Interfaceon which theprobe expectsto receiveresponsesreceive-interface

Request’s payload sizerequest-data-size

Maximum number of history samplessamples-of-history-kept

User-defined tagtag

Page 89

frequency

operations-per-hop

Chapter 1: Configuring IP

Table 7: Probe Characteristics (continued)

DescriptionCharacteristic

Probe timeout (in milliseconds)timeout

A value for the TOS bytetos

• Use to set the rate (in seconds) that the RTR probe uses to start a response time

operation.

• Example

host1(config-rtr)#frequency 90

• Use the no version to return to the default value, 60 seconds.

• See frequency

owner

request-data-size

• Use to set the number of RTR probe operations sent to a given hop.

• You can apply this option only to a pathEcho type.

• Example

host1(config-rtr)#operations-per-hop 5

• Use the no version to return to the default, 3.

• See operations-per-hop

• Use to identify the owner of the probe.

• If the SNMP agent is the owner of the probe, the owner’s name can begin with agent.

• Example

host1(config-rtr)#owner 192.10.27.6 rtc.boston.com 555.1212

• Use the no version to return to the default, no owner.

• See owner

• Use to set the protocol data size, in bytes, in the request packet.

• Example

host1(config-rtr)#request-data-size 20

• Use the no version to return to the default value, 1 byte.

• See request-data-size

tag

Page 90

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use to set an identifier for the probe.

• Example

host1(config-rtr)#tag westford

• Use the no version to return to the default, no tag.

• See tag

timeout

• Use to set the time (in milliseconds) that the probe waits for a response.

• You can apply this option only to an echo type.

• Do not set the value for timeout to more than the value set for frequency. If you do, the

timeout value is ignored.

• If you set the timeout to 0, no timeout is set.

• Example

host1(config-rtr)#timeout 3000

tos

hops-of-statistics-kept

• Use the no version to return to the default value, 5000 milliseconds.

• See timeout

• Use to set the type of service (ToS) byte in the probe’s IP header.

• Example

host1(config-rtr)#tos 16

• Use the no version to return to the default value, 0. The default applies to both the

echo and pathEcho types.

• See tos

Capturing Statistics

The primary objective of RTR is to collect statistics and information about network performance. You can control the number and type of statistics collected.

• Use to set the number of hops per path for which statistics are collected.

• When the number of hops reaches the specified number (that is, size), no additional

statistical information about the path is stored.

• This option applies only to pathEcho entries.

• To turn off this feature, set the value to 0.

• Example

host1(config-rtr)#hops-of-statistics-kept 5

Page 91

max-response-failure

Chapter 1: Configuring IP

• Use the no version to set the default, 16 hops.

• See hops-of-statistics-kept

• Use toset themaximum number of consecutive failures to respond to aprobe’srequest.

• When the maximum number is reached, the test stops.

• This option applies only to pathEcho entries.

• To turn off this feature, set the value to 0.

• Example

host1(config-rtr)#max-response-failure 2

• Use the no version to set the default, 5 consecutive failures.

• See max-response-failure

Collecting History

samples-of-history-kept

RTR can collect data samples for a given probe. These samples are referred to as history data. When RTRcollectshistory, it refers to tests. Atest is the lifetime ofa probeoperation.

• Use to set the maximum number of entries in the history table for each RTR probe.

• This command enables you to control the number of samples saved in the history

table.

• If you set the number of samples to 0, no samples are kept.

• Because collecting historyincreases memory usage, do so only when thereis a problem

in your network.

• Example

host1(config-rtr)#samples-of-history-kept 5

• Use the no version to set the default, 16 hops for pathEcho type, 1 hop for echo type.

• See samples-of-history-kept

Setting the Receiving Interface

When you configure multiple RTR entries to use the same target address, you must issue the receive-interface command toset the interface on which the probe expects to receive responses. This action enables the router to map incoming responses to the proper RTR entry, even when multiple RTR entries have the same target address.

receive-interface

• Use to specify the interface on which the RTR probe expects to receive responses.

• You must set this attribute when multiple RTR entries are configured to use the same

target address.

Page 92

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Example

host1(config-rtr)#receive-interface fastEthernet 3/0

• Use the no version to restore the default value, which is to receive a response on any

interface.

• See receive-interface

Setting Reaction Conditions

You can set the RTR probe to react to events that take place and to send notifications about these events.

NOTE: The only no version for all the rtr reaction-configuration commands

is no rtr reaction-configuration rtrIndex. Use the no version to clear all traps. This works for all the options.

rtr reaction-configuration action-type

• Use to specify the type of actions to occur depending on the events controlled by RTR.

• The default is to take the traps of enabled events.

• Example

host1(config)#rtr reaction-configuration 1 action-type trapOnly

• There is no no version.

• See rtr reaction-configuration action-type

rtr reaction-configuration operation-failure

• Use to enable the operation-failure reaction.

• The operation-failure event istriggeredwhen anumber ofconsecutiveprobe operations

are not received or when they are received after a timeout.

• Example

host1(config)#rtr reaction-configuration 1 operation-failure 3

• There is no no version.

• See rtr reaction-configuration operation-failure

rtr reaction-configuration path-change

• Use to enable the path-change reaction.

• The path-change event is triggered when a change is detected in the hop table. At

most, there can be one such event per test.

• Example

host1(config)#rtr reaction-configuration 1 path-change

Page 93

• There is no no version.

• See rtr reaction-configuration path-change

rtr reaction-configuration test-completion

• Use to enable test-completion reaction.

• The test-completion event is triggered when a test is completed successfully.

• For echo, a successful test means that all probes were sent.

• For pathEcho, a successful test means that the destination was reached at least

once.

• At most, there can be one such event per test.

• Example

host1(config)#rtr reaction-configuration 1 test-completion

• There is no no version.

• See rtr reaction-configuration test-completion

Chapter 1: Configuring IP

rtr reaction-configuration test-failure

• Use to enable test-failure reaction.

• The test-failureevent is triggeredwhen atest fails. Failure is determinedin thefollowing

ways:

• If Echo, this event is triggered after testFailureValue probes are either not received

or are received after a timeout.

• If PathEcho, this event is triggered when the test ends and no responses arereceived

from the destination.

• At most, there can be one such event per test.

• Example

host1(config)#rtr reaction-configuration 1 test-failure

• There is no no version.

• See rtr reaction-configuration test-failure

Scheduling the Probe

When you have configured the RTR probe, you must schedule the operation to begin collecting statistics and other information about problems that may arise.

rtr schedule

• Use to create an RTR schedule.

• Example

host1(config)#rtr schedule 5

Page 94

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• Use the no version to stop the test. The noversion stops the probe operation by putting

it in the pending state. The no version also resets the restart-time attribute and the life attribute.

• See rtr schedule

rtr schedule life

• Use to schedule the test’s length.

• Life is a value that depends on the type of the RTR entry; it is not a length of time.

• If the type is echo, life relates to the number of probes sent until a test finishes.

• If the type is pathEcho, life relates to the maximum number of hops used by the

traceRoute trap.

• Example

host1(config)#rtr schedule 5 life 1800

• Use the no version to stop the test. The noversion stops the probe operation by putting

it in the pending state. The no version also resets the life attribute.

• See rtr schedule life

rtr schedule restart-time

• Use to specify a restart time, in seconds, after which a test is restarted.

• Example

• Use the no version to stop the test. The noversion stops the probe operation by putting

it in the pending state. The no version also resets the restart-time attribute.

• See rtr schedule restart-time

rtr schedule start-time

• Use to schedule a test’s starting time (now or pending).

• Example

• Use the no version to stop the test. The noversion stops the probe operation by putting

it in the default state, pending.

• See rtr schedule start-time

Shutting Down the Probe

host1(config)#rtr schedule 5 restart-time 15

host1(config)#rtr schedule 5 start-time now

You can shut down the RTR probe operation.

rtr reset

Page 95

Monitoring RTR

Chapter 1: Configuring IP

• Use to shut down the RTR, stop all probe operations, and clear the RTR configuration

for the given virtual router.

NOTE: Werecommendthat you use this command onlyin extremely serious

situations, such as problems with the configurations of a number of probe operations.

• Example

host1(config)#rtr reset

• Use the no version to negate the reset operation.

• See rtr reset

You can monitor RTR by displaying status and configuration information.

show rtr application

• Use to display global information about RTR.

• Field descriptions

• Example

• See show rtr application

show rtr collection-statistics

• Use to display statistical information for a particular probe operation or for all

• Field descriptions

• numberOfEntries—Number of RTR entries according to type

• entriesEnabled—RTR entries with administrative status enabled

• entriesActive—RTR entries with operational status enabled

host1#show rtr application

numberOfEntries entriesEnabled entriesActive

------------------ ----------------- --------------echo 1 1 1 pathEcho 1 1 1 total 2 2 2

operations.

• rtrIndex—Index number of the RTR probe

• operationsSent—Number of probe operations sent

• operationsRecvd—Number of probe operations received

• lastGoodResponse—Time when last valid probe operation was received

Page 96

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

• operStatus—Operational status of the probe: enabled, disabled

• minRtt—Minimum round-trip time in milliseconds

• maxRtt—Maximum round-trip time in milliseconds

• avgRtt—Average round-trip time in milliseconds

• rttSumSqr—Sum of the square of all round-trip times in milliseconds

• testAttempts—Number of times the test ran

• testSuccesses—Number of times the test ran successfully

• currentHop—Current hop (TTL) used in the test

• currentOperation—Current probe operation index sent to the hop

• Example

host1#show rtr collection-statistics

show rtr configuration

Echo Entries:

rtrIndex operationsSent operationsRcvd lastGoodResponse

---------- -------------- -------------- --------------- 1 5208 5187 08/30/2000 05:09

rtrIndex operStatus minRtt maxRtt avgRtt rttSumSqr

---------- ---------- ------ ------ ------ -------- 1 enabled 0 1785 3 7109208

PathEcho Entries:

rtrIndex testAttempts testSuccesses lastGoodResponse

---------- ------------ ------------- --------------- 2 156 156 08/30/2000 05:09

rtrIndex operStatus currentHop currentOperation

---------- ---------- ---------- --------------- 2 enabled 2 4

• See show rtr collection-statistics

• Use to display the configuration for a particular probe or for all probes.

• Field descriptions

• rtrIndex—Index number of the RTR probe

• type—Probe type: echo, pathEcho

• targetAddress—Address of the probe’s target

• reqSize—Protocol data size in the request packet

• freq—Rate in seconds that the RTR probe uses to start a response time operation

• life—Length of the test

Page 97

Chapter 1: Configuring IP

• source—Interface from which the probe is sent

• restartTime—Restart time of the test in seconds

• owner—Owner of the probe

• samples—Maximum number of entries saved in the history table for this RTR probe

• admin—Administrative status of the probe: enabled, disabled

• tos—Setting of the type of service (ToS) byte in the probe’s IP header

• reactionConfiguration—RTR reactions that are configured for the probe

• receiveInterface—Type and specifier of the interface on which the probe expects to

receive responses; this field is blank if the optional receive-interface characteristic is not configured

• operFail—Operationfailure event istriggeredwhen this number of consecutive probe

operations is not received or when the operations are received after a timeout

• testFail—Test failure event is triggered when this number of probe operations is not

received or when the operations are received after a timeout

• timeout—Time in milliseconds that the probe waits for a response

• tag—Identifier configured for the probe

• operPerHop—Number of RTR probe operations sent to a given hop

• maxFail—Maximum number of consecutive failures to respond to a probe’s request.

When the maximum number is reached, the test stops. Applies only to pathEcho entries.

• hopKpt—Number of hops per path for which statistics are collected. When this

number is reached, no additional statistical information about the path is stored. Applies only to pathEcho entries.

• Example

host1#show rtr configuration rtrIndex type targetAddress reqSize freq life

------- -------- ------------ ------ ------ ---- 1 echo 10.5.0.200 1 1 20 2 pathEcho 10.5.0.11 1 1 30

rtrIndex source restartTime owner

---------- ------------------ ----------- ---------- 1 fastEthernet0/0 10 2 60

rtrIndex samples admin tos reactionConfiguration

---------- ------- -------- --- ------------------------ 1 5 enabled 0 2 5 enabled 0

Page 98

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

rtrIndex receiveInterface

---------- --------------- 1 fastEthernet0/0

rtrIndex operFail testFail timeout tag

---------- -------- -------- ------- ------ 1 1 1 10000

rtrIndex operPerHop maxFail hopKpt tag

---------- ---------- ------- ------ ------ 2 5 3 16

• See show rtr configuration

show rtr history

• Use to display history (data samples) for a particular probe or for all probes.

• Field descriptions

• rtrIndex—Index number of the RTR probe

• operation—Index number of the probe operation

• rtt—Round-trip time in milliseconds

• statusDescription

• concurrentLimitFail—Target already being used by another rtrIndex

• ifInactiveToTarget—Interface used to reach target is not operational

• invalidHostAddress—Target address is not supported

• noRouteToTarget—Target address is not reachable

• responseReceived—Probe operation replied by target

• requestTimedOut—Probe operation not replied to by target or reply received after

timeout

• unknownDestAddress—Target address is invalid

• unableToResolveName—Target address could not be looked up

• timeStamp—Date and time when the RTR entry was created

• test—Index number of the pathEcho test

• hop—Index number of the hop count

• operation—Index number of the probe operation

• address—Address of router at the hop

• Example

host1#show rtr history Echo Entries:

Page 99

Chapter 1: Configuring IP

rtrIndex operation rtt statusDescription timeStamp

-------- --------- --- ----------------- -------- 1 5476 0 responseReceived 08/30/2000 05:17 1 5477 0 responseReceived 08/30/2000 05:17 1 5478 0 responseReceived 08/30/2000 05:17 1 5479 0 responseReceived 08/30/2000 05:17 1 5480 0 responseReceived 08/30/2000 05:17

PathEcho Entries:

rtrIndex test hop operation rtt statusDescription

---------- ------ ---- --------- ------ ---------------- 2 165 3 5 0 responseReceived 2 165 3 1 0 responseReceived 2 165 3 2 0 responseReceived 2 165 3 3 0 responseReceived 2 165 3 4 0 responseReceived

rtrIndex test hop operation timeStamp address

---------- ------ ---- --------- ---------------- ------- 2 165 3 5 08/30/2000 20:39 10.5.0.11 2 165 3 1 08/30/2000 20:40 10.5.0.11 2 165 3 2 08/30/2000 20:40 10.5.0.11 2 165 3 3 08/30/2000 20:40 10.5.0.11 2 165 3 4 08/30/2000 20:40 10.5.0.11

show rtr hops

• See show rtr history

• Use to display RTR hops information.

• Field descriptions

• rtrIndex—Index number of the RTR probe

• hop—Index number of the hop count

• address—Address of the router at the hop

• minRtt—Minimum round-trip time in milliseconds

• maxRtt—Maximum round-trip time in milliseconds

• avgRtt—Average round-trip time in milliseconds

• rttSumSqr—Sum of the square of all round-trip times in milliseconds

• operationsSent—Number of probe operations sent

• operationsRcvd—Number of probe operations received

• lastGoodResponse—Time when last valid probe operation was received

• Example

host1#show rtr hops

rtrIndex hop address minRtt maxRtt avgRtt rttSumSqr

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

Page 100

JunosE 11.3.x IP, IPv6, and IGP Configuration Guide

2 1 192.168.1.1 1 276 1 955363 2 2 10.2.0.3 0 1109 2 10094451

rtrIndex hop operationsSent operationsRcvd lastGoodResponse

-------- --- -------------- -------------- ----------- 2 1 36985 36838 09/18/2000 20:20 2 2 30717 21494 09/18/2000 20:20

• See show rtr hops

show rtr operational-state

• Use to display RTR operational information.

• Field descriptions

• rtrIndex—Index number of the RTR probe

• type—Type of RTR probe: echo, pathEcho

• entryStatus—If the entry was created via the SNMP DISMAN MIB, the row may be

partially constructed; if that is the case, the CLI displays notReady as the entry’s status

Monitoring IP

System Event Logs

• adminStatus—Derived from the rtr schedule start-time command; if the option is

now, the status is enabled; if the option is pending, the status is disabled

• operStatus—Enabled only if entryStatus and adminStatus are enabled and the test

is running; operStatus remains enabled if the test finishes and restart time is not 0

• Example

host1#show rtr operational-state rtrIndex type entryStatus adminStatus operStatus

---------- -------- ----------- ----------- --------- 1 echo active enabled enabled 2 pathEcho active enabled enabled

• See show rtr operational-state

This section explains how to set a statistics baseline and use the show commands to view your IP configuration and monitor IP interfaces and statistics.

To troubleshoot and monitor IP, use the following system event logs:

•

ipAccessList—IP access list matching

•

ipEngine—IP chassis manager

•

ipGeneral— IP general information

•

ipIfCreator—IP interface creator events

Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - IP-IPV6-IGP CONFIGURATION GUIDE 2010-10-31, JUNOSE 11.3 Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual