Juniper JUNOSE 11.2.X IP SERVICES, JUNOSE 11.2.X Configuration Manual

Download

JunosE™ Software for E Series™ Broadband Services Routers

IP Services Configuration Guide

Release

11.2.x

Published: 2010-06-29

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 Services Configuration Guide

Writing: Subash Babu Asokan, Mark Barnard, Bruce Gillham, Sarah Lesway-Ball, Brian Wesley Simmons, Fran Singer, Namrata Mehta Editing: Benjamin Mann Illustration: Nathaniel Woodward Cover Design: Edmonds Design

Revision History July 2010—FRS JunosE 11.2.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.

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 oran 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 applicablefeesand the limitations andrestrictions set forthherein, Juniper grantsto 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 marks on or in any copyof the Softwareor anyproduct 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

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

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 ofconfidentiality 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 ofJuniper 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 nameas if it were Juniper. In addition, certain third party software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL

at http://www.gnu.org/licenses/lgpl.html .

15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related documentation is and will be in the English language)).

Abbreviated Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Part 1 Chapters

Chapter 1 Configuring Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2 Configuring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Chapter 3 Configuring J-Flow Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 4 Configuring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Chapter 5 Configuring IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 6 Configuring Dynamic IPSec Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Chapter 7 Configuring ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Chapter 8 Configuring Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Chapter 9 Configuring IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Chapter 10 Configuring Dynamic IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Chapter 11 IP Reassembly for Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Chapter 12 Securing L2TP and IP Tunnels with IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Chapter 13 Configuring the Mobile IP Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Part 2 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

JunosE 11.2.x IP Services Configuration Guide

Table of Contents

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

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

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

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

Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

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

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvi

Part 1 Chapters

Chapter 1 Configuring Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

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

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Route Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Route Map Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Multiple Values in a Match Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Negating Match Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Matching a Community List Exactly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Removing Community Lists from a Route Map . . . . . . . . . . . . . . . . . . . . . . . . . 8

Matching a Policy List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Redistributing Access Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Setting Multicast Bandwidths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Match Policy Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Filtering Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Configuration Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Configuration Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Configuration Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Filtering AS Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Configuration Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Using Access Lists in a Route Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Configuration Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Using Access Lists for PIM Join Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Clearing Access List Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Creating Table Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Using the Null Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Prefix Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Using a Prefix List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

JunosE 11.2.x IP Services Configuration Guide

Prefix Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Community Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Using Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Managing the Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Troubleshooting Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Monitoring Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 2 Configuring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

NAT Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Network and Address Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Understanding Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Address Assignment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Order of Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

PPTP and GRE Tunneling Through NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Packet Discard Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Configuring a NAT License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Limiting Translation Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Specifying Inside and Outside Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Defining Static Address Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Using a Prefix Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Extended Community Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

AS-path Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Community Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Community Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Metacharacters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Using Metacharacters as Literal Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Regular Expression Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Traditional NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Basic NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

NAPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Bidirectional NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Twice NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Inside Local Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Inside Global Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Outside Local Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Outside Global Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Inside Source Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Outside Source Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Static Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Dynamic Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Inside-to-Outside Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Outside-to-Inside Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Creating Static Inside Source Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Creating Static Outside Source Translations . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Table of Contents

Defining Dynamic Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Creating Access List Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Defining Address Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Defining Dynamic Translation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Creating Dynamic Inside Source Translation Rules . . . . . . . . . . . . . . . . . 74

Creating Dynamic Outside Source Translation Rules . . . . . . . . . . . . . . . . 74

Defining Translation Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Clearing Dynamic Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

NAT Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

NAPT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Bidirectional NAT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Twice NAT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Cross-VRF Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Tunnel Configuration Through NAT Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Clients on an Inside Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Clients on an Outside Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

GRE Flows Through NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Monitoring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Displaying the NAT License Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Displaying Translation Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Displaying Translation Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Displaying Address Pool Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Displaying Inside and Outside Rule Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 3 Configuring J-Flow Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Interface Sampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Aggregation Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Flow Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Main Flow Cache Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Cache Flow Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Aging Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Operation with NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Operation with High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Before You Configure J-Flow Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Configuring Flow-Based Statistics Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Enabling Flow-Based Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Enabling Flow-Based Statistics on an Interface . . . . . . . . . . . . . . . . . . . . . . . 95

Defining a Sampling Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Setting Cache Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Defining Aging Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Specifying the Activity Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Specifying the Inactivity Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Specifying Flow Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Configuring Aggregation Flow Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Monitoring J-Flow Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Clearing J-Flow Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

J-Flow show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

JunosE 11.2.x IP Services Configuration Guide

Chapter 4 Configuring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Bidirectional Forwarding Detection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

BFD Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

BFD References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Configuring a BFD License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

BFD Version Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Configuring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Managing BFD Adaptive Timer Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Clearing BFD Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Monitoring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Chapter 5 Configuring IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

IPSec Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

IKE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

How BFD Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Negotiation of the BFD Liveness Detection Interval . . . . . . . . . . . . . . . . . . . 108

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Viewing BFD Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

IPSec Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Secure IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

RFC 2401 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

IPSec Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Security Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Manual Versus Signaled Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Operational Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Transport Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Inbound and Outbound SAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Transform Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Other Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

IP Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

ESP Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

AH Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

IPSec Maximums Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

DPD and IPSec Tunnel Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Tunnel Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Main Mode and Aggressive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Aggressive Mode Negotiations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

IKE Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Hash Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Authentication Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Diffie-Hellman Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Table of Contents

IKE SA Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Generating Private and Public Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Configuring an IPSec License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Configuring IPSec Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Creating an IPSec Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Configuring DPD and IPSec Tunnel Failover . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Defining an IKE Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Refreshing SAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Enabling Notification of Invalid Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Configuration Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Monitoring IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Chapter 6 Configuring Dynamic IPSec Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Dynamic Connection Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Dynamic Connection Teardown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Dynamic IPSec Subscriber Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Inherited Subscriber Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Using IPSec Tunnel Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Relocating Tunnel Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Creating an IPSec Tunnel Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Configuring IPSec Tunnel Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Limiting Interface Instantiations on Each Profile . . . . . . . . . . . . . . . . . . . . . . 174

Specifying IKE Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Setting the IKE Local Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Setting the IKE Peer Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Appending a Domain Suffix to a Username . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Overriding IPSec Local and Peer Identities for SA Negotiations . . . . . . . . . . 176

Specifying an IP Profile for IP Interface Instantiations . . . . . . . . . . . . . . . . . . 176

Defining the Server IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Specifying Local Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Defining IPSec Security Association Lifetime Parameters . . . . . . . . . . . . . . . 178

Defining User Reauthentication Protocol Values . . . . . . . . . . . . . . . . . . . . . . 178

Specifying IPSec Security Association Transforms . . . . . . . . . . . . . . . . . . . . 179

Specifying IPSec Security Association PFS and DH Group Parameters . . . . 179

Defining the Tunnel MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Defining IKE Policy Rules for IPSec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Specifying a Virtual Router for an IKE Policy Rule . . . . . . . . . . . . . . . . . . . . . 180

Defining Aggressive Mode for an IKE Policy Rule . . . . . . . . . . . . . . . . . . . . . . 181

JunosE 11.2.x IP Services Configuration Guide

Monitoring IPSec Tunnel Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 7 Configuring ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Configuring ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Configuring ANCP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Configuring ANCP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Configuring Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Configuring ANCP for QoS Adaptive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Triggering ANCP Line Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Adjusting the Data Rate Reported by ANCP for DSL Lines . . . . . . . . . . . . . . . . . . 194

Configuring Transactional Multicast for IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Triggering ANCP OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Monitoring ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Chapter 8 Configuring Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

IKE Authentication with Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Access Topology Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Line Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Transactional Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Retrieval of DSL Line Rate Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Learning the Partition ID from an Access Node . . . . . . . . . . . . . . . . . . . . . . . 187

Creating a Listening TCP Socket for ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Accessing L2C Configuration Mode for ANCP . . . . . . . . . . . . . . . . . . . . . . . . 188

Defining the ANCP Session Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Learning the Access Node Partition ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Accessing L2C Neighbor Configuration Mode for ANCP . . . . . . . . . . . . . . . . 190

Defining an ANCP Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Limiting Discovery Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Clearing ANCP Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Creating an IGMP Session for ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

ANCP IGMP Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Complete Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Digital Certificate Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Signature Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Generating Public/Private Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Obtaining a Root CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Obtaining a Public Key Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Offline Certificate Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Online Certificate Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Authenticating the Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Verifying CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Table of Contents

File Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Certificate Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

IKE Authentication Using Public Keys Without Digital Certificates . . . . . . . . . . . . 212

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Public Key Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Configuring Digital Certificates Using the Offline Method . . . . . . . . . . . . . . . . . . . 213

Configuring Digital Certificates Using the Online Method . . . . . . . . . . . . . . . . . . . 219

Configuring Peer Public Keys Without Digital Certificates . . . . . . . . . . . . . . . . . . 224

Monitoring Digital Certificates and Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Chapter 9 Configuring IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

GRE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

DVMRP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

ERX7xx Models, ERX14xx Models, and the ERX310 Router . . . . . . . . . . 238

E120 Router and E320 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Redundancy and Tunnel Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Configuring IP Tunnels to Forward IP Frames . . . . . . . . . . . . . . . . . . . . . . . . 243

Preventing Recursive Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Creating Multicast VPNs Using GRE Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 244

Monitoring IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Chapter 10 Configuring Dynamic IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Dynamic IP Tunnel Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Data MDT for Multicast VPNs and Dynamic IP Tunnels . . . . . . . . . . . . . . . . 252

Mobile IP and Dynamic IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Combining Dynamic and Static IP Tunnels in the Same Chassis . . . . . . . . . 253

Changing and Removing Existing Dynamic IP Tunnels . . . . . . . . . . . . . . . . . 253

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

ERX7xx Models, ERX14xx Models, and the ERX310 Router . . . . . . . . . . 254

E120 Router and E320 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Redundancy and Tunnel Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Configuring a Destination Profile for Dynamic IP Tunnels . . . . . . . . . . . . . . . . . . 255

Modifying the Default Destination Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Modifying the Configuration of the Default Destination Profile . . . . . . . 256

Configuring a Destination Profile for GRE Tunnels . . . . . . . . . . . . . . . . . . . . 256

Creating a Destination Profile for DVMRP Tunnels . . . . . . . . . . . . . . . . . . . . 256

Monitoring Dynamic IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

JunosE 11.2.x IP Services Configuration Guide

Chapter 11 IP Reassembly for Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Configuring IP Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Monitoring IP Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Chapter 12 Securing L2TP and IP Tunnels with IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

L2TP/IPSec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

GRE/IPSec and DVMRP/IPSec Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Configuring IPSec Transport Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Monitoring DVMRP/IPSec, GRE/IPSec, and L2TP/IPSec Tunnels . . . . . . . . . . . . 294

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

ERX7xx Models, ERX14xx Models, and the ERX310 Router . . . . . . . . . . 270

E120 Router and E320 Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Setting Statistics Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Displaying Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Tunnel Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

IPSec Secured-Tunnel Maximums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Setting Up the Secure L2TP Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

L2TP with IPSec Control and Data Frames . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Compatibility and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Client Software Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Interactions with NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Interaction Between IPSec and PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

LNS Change of Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

Group Preshared Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

NAT Passthrough Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

How NAT-T Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

UDP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

NAT Keepalive Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Configuring and Monitoring NAT-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Single-Shot Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Configuration Tasks for Client PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Configuration Tasks for E Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Enabling IPSec Support for L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Configuring NAT-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

Configuring Single-Shot Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Setting Up the Secure GRE or DVMRP Connection . . . . . . . . . . . . . . . . . . . . 288

Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Enabling IPSec Support for GRE and DVMRP Tunnels . . . . . . . . . . . . . . . . . 289

System Event Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

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

Table of Contents

Chapter 13 Configuring the Mobile IP Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Mobile IP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Mobile IP Agent Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Mobile IP Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Home Address Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Subscriber Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Mobile IP Routing and Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Mobile IP Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Mobile IP References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Before You Configure the Mobile IP Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . 307

Configuring the Mobile IP Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Monitoring the Mobile IP Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Part 2 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

JunosE 11.2.x IP Services Configuration Guide

List of Figures

Part 1 Chapters

Chapter 1 Configuring Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 1: Applying Route Maps to Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 2: Filtering with Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Figure 3: Filtering with AS-Path Access Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 4: Route Map Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 5: Community Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter 2 Configuring NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 6: NAPT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Figure 7: Bidirectional NAT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Figure 8: Twice NAT Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Figure 9: Cross-VRF Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Figure 10: PPTP Tunnels on an Inside Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Figure 11: PPTP Tunnels on an Outside Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Chapter 5 Configuring IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Figure 12: IPSec Tunneling Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Figure 13: IPSec Tunneling Packet Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . 124

Figure 14: IPSec Security Parameters in Relation to the Secure IP Interface . . . . 125

Figure 15: Customer A's Corporate Frame Relay Network . . . . . . . . . . . . . . . . . . . 153

Figure 16: ISP-X Uses ERX Routers to Connect Corporate Offices over the

Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Figure 17: Connecting Customers Who Use Similar Address Schemes . . . . . . . . 156

Chapter 7 Configuring ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Figure 18: Using ANCP with an Access Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Chapter 9 Configuring IP Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Figure 19: IP Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Figure 20: Transport and Tunnel Networks Using Different Routing Protocols . . 244

Chapter 11 IP Reassembly for Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Figure 21: Tunneling Through an IP Network That Fragments Packets . . . . . . . . 270

Chapter 12 Securing L2TP and IP Tunnels with IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Figure 22: L2TP with IPSec Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Figure 23: L2TP/IPSec Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Figure 24: L2TP Control Frame Encapsulated by IPSec . . . . . . . . . . . . . . . . . . . . 279

Figure 25: L2TP Data Frame Encapsulated by IPSec . . . . . . . . . . . . . . . . . . . . . . 279

Figure 26: L2TP Control Frame with NAT-T UDP Encapsulation . . . . . . . . . . . . . 281

Figure 27: L2TP Data Frame with NAT-T UDP Encapsulation . . . . . . . . . . . . . . . 282

JunosE 11.2.x IP Services Configuration Guide

Figure 28: IKE Packet with NAT-T UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . 282

Figure 29: GRE/IPSec Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

List of Tables

About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

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

Part 1 Chapters

Chapter 1 Configuring Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Table 3: Match and Set Policy Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Table 4: Action Based on Well-Known Community Membership . . . . . . . . . . . . . . 37

Table 5: Supported Regular Expression Metacharacters . . . . . . . . . . . . . . . . . . . . 43

Table 6: Sample Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 4 Configuring BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Table 7: Determining BFD Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Chapter 5 Configuring IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Table 8: IPSec Terms and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Table 9: Security Parameters Used on Secure IP Interfaces . . . . . . . . . . . . . . . . . 124

Table 10: Security Parameters per IPSec Policy Type . . . . . . . . . . . . . . . . . . . . . . 126

Table 11: Supported Transforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Table 12: Supported Security Transform Combinations . . . . . . . . . . . . . . . . . . . . . 131

Table 13: Initiator Proposals and Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Chapter 8 Configuring Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Table 14: Digital Certificate Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 205

Table 15: Outcome of IKE Phase 1 Negotiations . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Table 16: File Extensions (Offline Configuration) . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Chapter 12 Securing L2TP and IP Tunnels with IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Table 17: Configuration and Monitoring Tasks for NAT-T . . . . . . . . . . . . . . . . . . . 283

Table 18: Differences in Handling Timeout Periods for L2TP/IPSec Tunnels . . . . 284

JunosE 11.2.x IP Services Configuration Guide

About the Documentation

•

E Series and JunosE Documentation and Release Notes on page xxiii

•

Audience on page xxiii

•

E Series and JunosE Text and Syntax Conventions on page xxiii

•

Obtaining Documentation on page xxv

•

Documentation Feedback on page xxv

•

Requesting Technical Support on page xxv

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 xxiv defines notice icons used in this documentation.

JunosE 11.2.x IP Services Configuration Guide

Table 1: Notice Icons

Table 2 on page xxiv 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

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,

JunosE 11.2.x IP Services 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 product serialnumber, use ourSerial Number Entitlement (SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC

You can open a case with JTAC on the Web or by telephone.

•

Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .

•

Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, see

http://www.juniper.net/support/requesting-support.html .

PART 1

Chapters

•

Configuring Routing Policy on page 3

•

Configuring NAT on page 61

•

Configuring J-Flow Statistics on page 91

•

Configuring BFD on page 107

•

Configuring IPSec on page 119

•

Configuring Dynamic IPSec Subscribers on page 169

•

Configuring ANCP on page 185

•

Configuring Digital Certificates on page 205

•

Configuring IP Tunnels on page 237

•

Configuring Dynamic IP Tunnels on page 251

•

IP Reassembly for Tunnels on page 269

•

Securing L2TP and IP Tunnels with IPSec on page 275

•

Configuring the Mobile IP Home Agent on page 303

JunosE 11.2.x IP Services Configuration Guide

CHAPTER 1

Configuring Routing Policy

This chapter provides information about configuringrouting policyfor your E Series router. It describes routingpolicy configuration in general as itmight beused withvarious routing protocols,such as Border Gateway Protocol (BGP), Intermediate Systemto Intermediate System (IS-IS), Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).

This chapter contains the following sections:

•

Overview on page 3

•

Platform Considerations on page 4

•

References on page 4

•

Route Maps on page 4

•

Match Policy Lists on page 19

•

Access Lists on page 20

•

Using the Null Interface on page 32

•

Prefix Lists on page 32

•

Prefix Trees on page 35

•

Community Lists on page 37

•

Using Regular Expressions on page 42

•

Managing the Routing Table on page 47

•

Troubleshooting Routing Policy on page 47

•

Monitoring Routing Policy on page 48

Overview

Routing policy determines howthe system handles the routes it receives from and sends to neighboring routers. In many cases, routing policy consists of the following:

•

Filtering routes

•

Accepting certain routes

•

Accepting and modifying other routes

JunosE 11.2.x IP Services Configuration Guide

•

Rejecting some routes

•

Determining the routing protocol used to distribute the routes

You can think of routing policy as a way to control the flow of routes into and out of the router.

The decision about which routes to accept from and advertise to various neighbors has an important impact on the traffic that crosses a network. Routing policy is used to enforce business agreements between two or more Internet service providers (ISPs) concerning the amount and type of traffic that is allowed to pass between them.

You can use one or more of the following mechanisms to configure routing policy:

•

“Route Maps” on page 4

•

“Match Policy Lists” on page 19

•

“Access Lists” on page 20

•

“Prefix Lists” on page 32

•

“Prefix Trees” on page 35

•

“Community Lists” on page 37

Platform Considerations

Configuring routing policies is supported on all E Series routers.

For information about the modules supported on E Series routers:

•

See the ERXModuleGuide for modulessupportedon ERX7xx models,ERX14xx models, and the Juniper Networks ERX310 Broadband Services Router.

•

See the E120 and E320 Module Guide for modules supported on the Juniper Networks E120 and E320 Broadband Services Routers.

References

For more information about the protocols discussed in this chapter, see their respective chapters in this guide and other guides within the JunosE documentation set, and to the References sections within those chapters.

Route Maps

You can useroutemaps to control and modify routing information and todefine conditions for redistributing routes between routing domains. Youcan applyroute maps to inbound, outbound, or redistribution routes. A routemap consists ofmatch clauses and set clauses.

Match clauses specify the attribute values that determine whether a route matches the route map. Aroute that has thesame attribute valuespasses the match condition. Routes that pass all the match conditions match the route map. You issue match commands to define the match conditions for a route map. You can specify the match conditions in

Chapter 1: Configuring Routing Policy

any order. If you do not specify any match conditions in a route map, that route map matches all routes.

Set clauses definehow the attributes are modifiedfor matching routes. The set conditions apply only to routes that pass all the match conditions (or a route map with no match conditions). When a route passes all the match conditions, the router software applies all set conditions. You issue set commands to define the set conditions for a route map.

You assign a unique string called the map tag to identify each route map. You can have multiple instances of a route map, where each instance consists of a different group of clauses. Each instance is identified by a sequence number. When you apply a route map, the routing protocol evaluates routes against the instance of the route map with the lowest sequence number. If the routes pass all the match conditions specified in the lowest-numbered instance, and if all set commands are successfully applied, no other instance of the route map is considered. However, any routes that do not pass all the match conditions are evaluated against the next instanceof the route map. For example, suppose you create two instances of route map boston5, one with sequence number 10 and one with sequence number 25. When you apply boston5, routes are evaluated first against instance 10; any that do not match are evaluated against instance 25.

When you apply a route map, you specify the permit or deny keyword:

•

If you specify the permit keyword, routes that match the route map are accepted, forwarded, or redistributed. Routes that do not match the route map are rejected or blocked.

•

If you specify the deny keyword, routes that match the route map are rejected or blocked. Routes that do not match the route map are accepted, forwarded, or redistributed.

A route map must have at least one match clause or oneset clause. If you have no match clauses, all routes match the route map, and the set conditions apply to all routes. If you have no set clauses, no action is taken other than that specified by the permit or deny keyword.

Route Map Configuration Example

Consider the network structure shown in Figure 1 on page 6. Suppose you do not want router Boston to receive any routes that originate in or pass through router Chicago.

JunosE 11.2.x IP Services Configuration Guide

Figure 1: Applying Route Maps to Routes

You can use a route map to filter routes based on the autonomous system (AS) path to accomplish this goal. Use the following commands to configure router NY:

host1(config)#router bgp 293 host1(config-router)#network 192.168.5.0 mask 255.255.255.0 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.2.2.2 remote-as 873 host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 route-map block1 out host1(config-router)#exit host1(config)#ip as-path access-list boston deny _32_ host1(config)#route-map block1 deny 1 host1(config-route-map)#match as-path boston

Multiple Values in a Match Entry

You can specify more than one value in each match entry of a route map by using any of the following match commands:

match ipv6 next-hopmatch as-path

match ipv6 route-sourcematch community

match levelmatch distance

match metricmatch extcommunity-list

match policy-listmatch ip address

match route-typematch ip next-hop

match tagmatch ipv6 address

A clause with multiple values matches a route that has any of the values; that is, the multiple values are logical ORed.

You can also issue successive match commands to add new values to a route map entry for any of the commands listed above.

This method is equivalent to issuing the following single command:

You cannot specify multiple values for the match metric-type command, because it has only two acceptable values, which are mutually exclusive. Specifying both values has the same effect as not specifying a metric type at all; specifying the same value more than once has no meaning.

Negating Match Clauses

Chapter 1: Configuring Routing Policy

host1(config-route-map)#match ip address lisbon madrid host1(config-route-map)#match as-path 10 20 30

host1(config-route-map)#match ip address boston host1(config-route-map)#match ip address newyork

host1(config-route-map)#match ip address boston newyork

If you specify a value when you negate a match command configured in a route map, only that value for the match entry is deleted. The routing software deletes the entire match entry only if the entry contains no other values. In some earlier releases, any value specified witha no match command was ignored, and theentire match entry was deleted. This change applies to all match commands configured in a route map.

For example, consider the following match entry to route map miami:

host1(config)#ip community-list corporate5 permit 32 463 21 host1(config)#ip community-list dade2 permit 41 53 22 host1(config)#route-map miami permit 1 host1(config-route-map)#match community corporate5 dade2 host1(config-route-map)#exit host1(config)#exit host1#show route-map route-map miami, permit, sequence 10 Match clauses: match community corporate5 dade2

In earlier releases, issuing a command like the following to remove a community (see “Community Lists” on page 37) not specified in the entry deleted the whole entry, but now nothing happens:

host1(config-route-map)#no match community southbeach host1(config-route-map)#exit host1(config)#exit host1#show route-map route-map miami, permit, sequence 10 Match clauses: match community corporate5 dade2

If you instead issue the following commands, the specified value is deleted:

host1(config-route-map)#no match community dade2

JunosE 11.2.x IP Services Configuration Guide

host1(config-route-map)#exit host1(config)#exit host1#show route-map route-map miami, permit, sequence 10 Match clauses: match community corporate5

Issue either of the following commands to delete the entire match community entry:

host1(config-route-map)#no match community host1(config-route-map)#no match community corporate5 dade2

Matching a Community List Exactly

You can use the exact-match keyword for the match community command to specify that a match exists only for the exact community numbers specified in the community list. The exact-match keyword applies only to a standard community list—that is, one not specified by a regular expression. You cannot use the exact-match keyword with a community list that is specified by a regular expression.

Consider the following example:

host1(config)#ip community-list 1 permit 100 200 300 host1(config)#exit host1#show ip community-list Community standard list 1 permit 0:100 0:200 0:300 host1(config)#route-map example1 permit 10 host1(config-route-map)#match community 1 exact-match host1(config)#exit host1#show route-map example1 route-map example, permit, sequence 10 Match clauses: community (community-list filter): 1 exact-match

The route map example1 permits a route only if the route contains community 100 and community 200 and community 300 and no additional communities.

If you do not specify the exact-match option, the route map also permits a match on a route that contains additional communities. For example, a route that contains communities 100, 200, 300, 400, and 450 matches.

Removing Community Lists from a Route Map

You can use the set comm-list delete command to remove the specified community list from routes matching the route map, provided that you created the community list with a single community number per list entry. For example, you cannot remove the community lists 231:10 and 231:20 with theset comm-list deletecommand if youcreated them with the following command:

host1(config)#ip community list 1 permit 231:10 231:20

You can, however, remove the listswith theset comm-list delete command if you created them separately with the following commands:

host1(config)#ip community list 1 permit 231:10

host1(config)#ip community list 1 permit 231:20

Matching a Policy List

You can use the match policy-list command to reference a policy list within the route map. Policy lists are like route maps, but they contain only match clauses and no set clauses. Youcan createa policylist tocontain a group of match clauses once, referencing the list in any number of route maps and avoiding the task of having to reenter the match clauses separately into each route map.

For more information about creating IP policy lists, see “Match Policy Lists” on page 19.

Redistributing Access Routes

Access-internal routes, such as DHCP and AAA/PPP host routes, are host routes to directly connected clients. Access routes, also known as AAA framed routes, are sourced by AAA.

The following example shows how you might redistribute access-internal routes and access routes by matching on a tag:

Chapter 1: Configuring Routing Policy

1. Configure route map tagtest to match tag 30.

host1(config)#route-map tagtest host1(config-route-map)#match tag 30

2. Configure redistribution into BGP of the access-internal routes and access routes

with route map tagtest.

host1(config)#router bgp 405 host1(config-router)#redistribute access route-map tagtest host1(config-router)#redistribute access-internal route-map tagtest

Setting Multicast Bandwidths

You can use the set admission-bandwidth command to set a multicast bandwidth for admission control. Admission control is performed for the join and mapped interface when the OIF is added to the mroute.

You can use the set qos-bandwidth command to set a multicast bandwidth for QoS control. The QoS adjustment is made to the join interface when the OIF is added to the mroute.

NOTE: Both the admission bandwidth and QoS bandwidth are a constant bit rate.

For more information about multicast admission control or QoS adjustment, see

Configuring IPv4 Multicastor chapter Configuring IPv6 Multicast in JunosE Multicast Routing Configuration Guide.

match as-path

• Use to match an AS-path access list.

• The implemented weight is based on the first matched AS path.

JunosE 11.2.x IP Services Configuration Guide

• Example

host1(config-route-map)#match as-path pathlist5

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match as-path.

match community

• Use to match a community list.

• This command supports inbound and outbound route maps.

• Example

host1(config-route-map)#match community comm5

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match community.

match distance

match extcommunity

• Use to match any routes being redistributed out of the routing table that have the

specified administrative distance.

• Distance is used to determine the relative preference between routes to the same

prefix in order to pick the best route to that prefix in the routing table. Distance has no meaning in any other circumstance, and any attempt to match distance fails.

• Example

host1(config-route-map)#match distance 25

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match distance.

• Use to match an extended community list in a route map.

• You can specify one or more extended community list names in a match clause. If you

specify more than one extended community list, the lists are logically ORed.

• Example

host1(config-route-map)#match extcommunity topeka10

• Use the no version to remove the match clause from a route map or a specified value

from the match clause.

• See match extcommunity.

match ip address

match ip next-hop

Chapter 1: Configuring Routing Policy

• Use to match any route that has a destination network number that is permitted by

an access list, a prefix list, or a prefix tree, or that performs policy routing on packets.

• Example

host1(config-route-map)#match ip address prefix-tree boston

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match ip address.

• Use to match any routes that have a next-hop router address passed by the specified

access list, prefix list, or prefix tree.

• Example

host1(config-route-map)#match ip next-hop 5 acl_192_54_24_1

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

match ipv6 address

match ipv6 next-hop

• See match ip next-hop.

• Use to match any routes that have a destination network number address that is

permitted by the specified prefix list.

• Example

host1(config-route-map)#match ipv6 address prefix-list boston

• Use the no version to delete all address match clauses from a route map unless you

specify a prefix list, in which case only that prefix list match is removed from the route map.

• See match ipv6 address.

• Use to match any routes that have a next-hop router address passed by the specified

prefix list.

• Example

host1(config-route-map)#match ipv6 next-hop prefix-list next1

• Use the no version to delete all next-hop match clauses from a route map unless you

specify a prefix list, in which case only that prefix list match is removed from the route map.

• See match ipv6 next-hop.

match ipv6 route-source

JunosE 11.2.x IP Services Configuration Guide

• Use to match any routes that are advertised from addresses containedin the specified

prefix list.

• Example

host1(config-route-map)#match ipv6 route-source prefix-list source

• Use the no version to delete all route-source match clauses from a route map unless

you specify a prefix list, in which case only that prefix list match is removed from the route map.

• See match ipv6 route-source.

match level

• Use to match routes for the specified level.

• Example

host1(config-route-map)#match level level-1

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

match metric

match metric-type

match policy-list

• See match level.

• Use to match a route for the specified metric value.

• Example

host1(config-route-map)#match metric 10

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match metric.

• Use to match a route for the specified metric type.

• Example

host1(config-route-map)#match metric-type external

• Use the no version to delete the match clause from a route map.

• See match metric-type.

• Use to reference a policy list that has the specified name.

• Example

host1(config-route-map)#match policy-list list1

• Use the no version to remove the match clause from a route map.

• See match policy-list.

match route-type

• Use to match a route for the specified route type.

• Example

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match route-type.

match-set summary prefix-tree

• Use to specify the prefix tree that summarizes routes for a particular route map.

• Use the ip prefix-tree command to set theconditions of the prefix tree, including which

routes to summarize and how many bits of the network address to preserve.

• Example

Chapter 1: Configuring Routing Policy

host1(config-route-map)#match route-type level-1

host1(config-route-map)#match-set summary prefix-tree boston

match tag

route-map

• Use the no version to disable the use of the prefix tree by the route map.

• See match-set summary prefix-tree.

• Use to match the tag value of the destination routing protocol.

• Example

host1(config)#route-map 1 host1(config-route-map)#match tag 25

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match tag.

• Use to define the conditions for redistributing routes from one routing protocol to

another, and for filtering or modifying updates sent to or received from peers.

• Each route-map command has a list of match and set commands associated with it.

That is, the route map itself consists of a set of clauses; each clause (also called an entry) consists of a match or set command:

• match commands specifythe match criteria, theconditions under which redistribution

is allowed for the current route map.

• set commands specify the set actions, the redistribution actions to perform if the

criteria enforced by the match commands is met.

• You can specify match and set clauses to modify attributes of redistributed routes.

• Use route maps when you want to have detailed control over how routes are

redistributed between routing processes.

JunosE 11.2.x IP Services Configuration Guide

• You specify the destination routing protocol with the router command.

• You specify the source routing protocol with the redistribute command.

• Example

host1(config)#route-map nyc1 permit 10 host1(config-route-map)#match ip address list1 host1(config-route-map)#set metric-type internal

• Use the no version to delete the route map.

• See route-map.

set as-path prepend

• Use to modify an AS path for BGP routes by prepending one or more AS numbers or a

list of AS numbers to the path list.

• The only global BGP metric available to influence the best path selection is the AS

path length. By varying the length of the AS path, a BGP device can influence the best path selection by a peer farther away.

set automatic-tag

set comm-list delete

• Example

host1(config-route-map)#set as-path prepend list list10

• Use the no version to delete the set clause from a route map.

• See set as-path prepend.

• Use to automatically compute the tag value of the destination routing protocol.

• Example

host1(config-route-map)#set automatic-tag

• Use the no version to delete the set clause from a route map.

• See set automatic-tag.

• Use to remove communities specified by the community list from the community

attribute of routes that match the route map.

• You can use this command to delete communities only if the community list was

created with a single community per list entry, as the following sample configuration for router host1 shows:

host1(config)#ip community-list 1 permit 231:10 host1(config)#ip community-list 1 permit 231:20 host1(config)#router bgp 45 host1(config-router)#neighbor 10.6.2.5 remote-as 5 host1(config-router)#neighbor 10.6.2.5 route-map indelete in host1(config-router)#route-map indelete permit 10 host1(config-route-map)#set comm-list 1 delete

set community

Chapter 1: Configuring Routing Policy

Router host1 receivesthe same route from 10.6.2.5 and applies the indelete route map. BGP compares each list entry with the community attribute. A match is found for the list entry231:10, andthis community is deleted fromthe community attribute. Similarly, a match is found for the list entry of 231:20, and this community is deleted from the community attribute.

• Example

host1(config-route-map)#set comm-list 1 delete

• Use the no version to delete the set clause from a route map.

• See set comm-list delete.

• Use to set the community attribute in BGP updates.

• You can specify a community list number in the range 1–4294967295, or in the new

community format of AA:NN, or one of the following well-known communities:

• local-asr—Prevents advertisement outside the local AS

set dampening

• no-advertise—Prevents advertisement to any peer

• no-export—Prevents advertisement beyond the BGP confederation boundary

• Alternatively, you can use the list keyword to specify the name of a community list

that you previously created with the ip community-list command.

• Example

host1(config-route-map)#set community no-advertise

• Use the none keyword to remove the community attribute from a route.

• Use the no version to delete the set clause from a route map.

• See set community.

• Use to enable BGP route flap dampening only on routes that pass the match clauses

of, and are redistributed by, a particular route map.

• BGP creates a dampening parameter block for each unique set of dampening

parameters—such as suppress threshold, reuse threshold, and so on—used by BGP. For example, if you have a route map that sets the dampening parameters to one set of values for some routes and to another set of values for the remaining routes, BGP uses and stores two dampening parameter blocks, one for each set.

• Example

host1(config-route-map)#set dampening 5 1000 1500 45 15

• Use the no version to delete the set clause from a route map.

• See set dampening.

set distance

JunosE 11.2.x IP Services Configuration Guide

• Use to set the administrative distance on routes being installed into the routing table

that match the route map.

• Distance establishespreferencebetween routes to the same prefix to identify the best

route to that prefix. Setting distance in any other circumstance has no effect.

• Example

host1(config-route-map)#set distance 5

• Use the no version to delete the set clause from a route map.

• See set distance.

set extcommunity

• Use to set the extended community attributes in a route map for BGP updates.

• You can specify a site-of-origin (soo) extended community and a route target (rt)

extended community at the same time in a set clause without overwriting the other.

• Example

host1(config-route-map)#set extcommunity rt 10.10.10.2:325

set ip next-hop

set ipv6 next-hop

• Use the no version to delete the set clause from a route map.

• See set extcommunity.

• Use to set the next hop attribute of a route that matches a route map.

• You can specify an IP address or an interface as the next hop.

• Use the peer-address keyword to have the following effect:

• On outbound route maps, disables the next-hop calculation by setting the next hop

to the IP address of the BGP device

• On inbound route maps, overrides any third-party next-hop configuration by setting

the next hop to the IP address of the peer

• Example

host1(config-route-map)#set ip next-hop 192.56.32.1

• Use the no version to delete the set clause from a route map.

• See set ip next-hop.

• Use to set the next hop attribute of a route that matches a route map.

• You can specify an IPv6 address or an interface as the next hop.

• Example

host1(config-route-map)#set ipv6 next-hop 1::1

set level

set local-preference

Chapter 1: Configuring Routing Policy

• Use the no version to delete the set clause from a route map.

• See set ipv6 next-hop.

• Use to specify where to import routes when all of a route map's match criteria are met.

• Example

host1(config-route-map)#set level level-2

• Use the no version to delete the set clause from a route map.

• See set level.

• Use to specify a preference value for the AS path.

• Example

host1(config-route-map)#set local-preference 200

set metric

• Use the no version to delete the set clause from a route map.

• See set local-preference.

• Use to set the metric value (for BGP, the MED) for a route.

• To establish an absolute metric, do not enter a plus or minus sign before the metric

value.

• Example

host1(config-route-map)#set metric 10

• To establish a relative metric, specify a plus or minus sign immediately preceding the

metric value. The value is addedto or subtracted from themetric ofany routes matching the route map. The relative metric value range is 0–4294967295.

• Example

host1(config-route-map)#set metric -25

• You cannot use both an absolute metric and a relative metric within the same route

map sequence. Setting either metric overrides any previously configured value.

• Use the no version to delete the set clause from a route map.

• See set metric.

set metric-type

• Use to set the metric type for a route.

• For BGP, this command affects BGP behavior only in outbound route maps and has

no effect on other types of route maps. Ifthe route map containsboth aset metric-type and a set metric clause, the set metric clause takes precedence. If you specify the internal metric type in a BGPoutbound route map, BGPsets theMED ofthe advertised

JunosE 11.2.x IP Services Configuration Guide

routes to the IGP cost of the next hop of the advertised route. If the cost of the next hop changes, BGP is not forced to readvertise the route.

• For BGP, you can specify the following metrics:

• external—Reverts to the normal BGP rules for propagating the MED; this is the BGP

default

• internal—Sets the MED of a received route that is being propagated to an external

peer equal to the IGP cost of the indirect next hop

• For IS-IS, you can specify the following metrics:

• external—Considers only the metric of the route itself is considered for comparison

• internal—Considers both the metric of the route and the cost to the router that

advertised the route are considered for comparison; this is the IS-IS default

• For OSPF, you can specify the following metrics:

• 1—Sets the cost of the external routes so that it is equal to the sum of all internal

costs and the external cost

set origin

set route-class

• 2—Sets the cost of the external routes so that it is equal to the external cost alone;

this is the OSPF default

• Example

host1(config-route-map)#set metric-type internal

• Use the no version to delete the set clause from a route map.

• See set metric-type.

• Use to set the BGP origin of the advertised route.

• Example

host1(config-route-map)#set origin egp

• Use the no version to delete the set clause from a route map.

• See set origin.

• Use to set the route class value. The route-class attribute enables you to associate a

route class with incoming packets based on the destination or source address of the packet. For example, you can associate different route classes with different VPN services, while using the route classes to classify packets for quality of service (QoS).

• Example

host1(config-route-map)#set route-class 50

• Use the no version to delete the set clause from a route map.

• See set route-class.

set route-type

set tag

Chapter 1: Configuring Routing Policy

• Use to set the routes of the specified type (internal, internal-intra, internal-inter, or

external).

• Example

host1(config-route-map)#set route-type internal

• Use the no version to delete the set clause from a route map.

• See set route-type.

• Use to set the tag value of the destination routing protocol.

• Example

host1(config-route-map)#set tag 23

• Use the no version to delete the set clause from a route map.

• See set tag.

set weight

Match Policy Lists

• Use to specify the BGP weight for the routing table.

• The weights assigned withthe set weight command ina route map overridethe weights

assigned using the neighbor weight and neighbor filter-list weight commands.

• Example

host1(config-route-map)#set weight 200

• Use the no version to delete the set clause from a route map.

• See set weight.

Match policy lists are very similar to route maps. However, unlike route maps, match policy lists can contain only match clauses and no set clauses.

You create match policy lists and then reference those lists within route maps. Because matchpolicy lists sharethe same match clauses with route maps, theyfunction the same way, and you can use the same match commands when you create your match policy lists.

NOTE: For descriptions of all route map match clauses, see “Route Maps” on page 4

As in route maps, the match clauses in match policy lists contain permit and deny statements. When you reference a match policy list within a route map, the route map

JunosE 11.2.x IP Services Configuration Guide

evaluates and processes each match clause and permits or denies routes based on the match policy list configuration.

When you configure match policy lists, keep the following in mind:

•

A route map evaluates and processes all match statements within any match policy list that it references.

•

You can configure multiple match policy lists within a route map, and you can evaluate each match policy list by using a logical AND or a logical OR.

•

You can reference match policy lists within a route map that also uses separate match and set statements (that is, the statements are not part of the match policy list).

•

All match policy lists within a route map match on the incoming attribute only.

ip match-policy-list

• Use to create an IP match policy list and launch the match policy list configuration

mode.

• Example

Access Lists

Filtering Prefixes

host1(config)#ip match-policy-list host1(config-match-policy-list)#

• Use the no version to delete the match policy list.

• See ip match-policy-list.

An access list is a sequential collection of permit and deny conditions that you can use to filter inbound or outbound routes. You can use different kinds of access lists to filter routes based on either the prefix or the AS path.

To filter routes based on the prefix, you can do any of the following:

•

Define an access list with the access-list or ipv6 access-list command, and apply the list to routes received from or passed to a neighbor with the neighbor distribute-list command.

•

Define aprefix list withthe ipprefix-list command, and apply thelist toroutes received from or passed to a neighbor with the neighbor prefix-list command.

•

Define a prefix tree with the ip prefix-tree command, and apply the list to routes received from or passed to a neighbor with the neighbor prefix-tree command.

The router compares each route's prefix against the conditions in the list or tree, one-by-one. If the first match is for a permit condition, the route is accepted or passed. If the first match is for a deny condition, the route is rejected or blocked. The order of conditions is critical because testing stops with the first match. If no conditions match, the router rejects or blocks the address; that is, the last action of any list is an implicit

Chapter 1: Configuring Routing Policy

deny condition for all routes. The implicit rule is displayed by showaccess-list and show config commands.

You cannot selectively place conditions in or remove conditions from anaccess list, prefix list, or prefix tree. You can insert a new condition only at the end of a list or tree.

Configuration Example 1

The following example shows how the implicit deny condition appears:

host1(config)#access-list 1 permit 10.10.10.1 0.0.0.255 host1(config)#access-list 2 permit 10.25.25.1 0.0.0.255 host1(config)#access-list 3 permit any any host1(config)#show access-list IP Access List 1: permit ip 10.10.10.1 0.0.0.255 any deny ip any any IP Access List 2: permit ip 10.25.25.1 0.0.0.255 any deny ip any any IP Access List 3: permit ip any any

The implicit deny rule does not appear in the display for access list 3, because any prefix matches access list 3.

Configuration Example 2

The following example demonstrates how to use a route map and an access list to redistribute static routes to IS-IS.

1. Configure three static routes.

host1(config)#ip route 20.20.20.0 255.255.255.0 192.168.1.0 host1(config)#ip route 20.20.21.0 255.255.255.0 192.168.2.0 host1(config)#ip route 20.21.0.0 255.255.255.0 192.168.30.0

2. Configure an access list, fltra, that filters routes 20.20.20.0/24 and 20.20.21.0/24.

host1(config)#access-list fltra permit 20.20.0.0 0.0.255.255

3. Configure route map 1 to match access list fltra, and apply an internal metric type.

host1(config)#route-map 1 host1(config-route-map)#match ip address fltra host1(config-route-map)#set metric-type internal

4. Configure redistribution into IS-IS of the static routes with route map 1.

host1(config)#router isis testnet host1(config-router)#redistribute static route-map 1

5. Verify the effect of the redistribution (the two static routes matching the route map

are redistributed as level 2 internal routes).

host1#show isis database detail l2 IS-IS Level-2 Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL

0000.0000.6666.00-00 0x000002B7 0x3E1F 1198 0/0/0 Area Address: 47.0005.80FF.F800.0000.0001.0001

JunosE 11.2.x IP Services Configuration Guide

NLPID: 0xcc IP Address: 192.168.1.105 Metric: 10 IS 0000.0000.6666.01 Metric: 10 IS 0000.0000.3333.00 Metric: 10 IS 0000.0000.7777.00 Metric: 30 IP 20.20.20.0 255.255.255.0 Metric: 30 IP 20.20.21.0 255.255.255.0

Configuration Example 3

The following example demonstrates how to use an access list to filter routes advertised to a BGP device. Consider the network structure in Figure 2 on page 22.

Figure 2: Filtering with Access Lists

Filtering AS Paths

The following commands configure router Boston to apply access list reject1 to routes inbound from router SanJose. Access list reject1 rejects routes matching 172.24.160.0/19.

host1(config)#router bgp 17 host1(config-router)#neighbor 10.5.5.4 remote-as 873 host1(config-router)#neighbor 10.5.5.4 distribute-list reject1 in host1(config-router)#exit host1(config)#access-list reject1 permit 172.24.48.0 0.0.255 host1(config)#access-list reject1 deny 172.24.160.0 0.0.0.255 host1(config)#access-list reject1 permit 172.24.24.0 0.0.0.255

You can use a filter list to filter incoming and outgoing routes based on the value of the AS-path attribute. Whenever a BGP route passes through an AS, BGP prepends its AS number to the AS-path attribute. The AS-path attribute is the list of ASs that a route has passed through to reach a destination.

To filterroutes based onthe AS path, definethe access list withthe ipas-path access-list command, and apply the list to routes received from or passed to a neighbor with the neighbor filter-list command. AS-path access lists use regular expressions to describe the AS path to be matched. A regular expression uses special characters—often referred to as metacharacters—to define a pattern that is compared with an input string. For a full discussion of regular expressions, with examples of how to use them, see “Using Regular Expressions” on page 42.

Chapter 1: Configuring Routing Policy

The router compares each route's AS path with each condition in the access list. If the first match is for a permit condition, the route is accepted or passed. If the first match is for a deny condition, the route is rejected or blocked. The order of conditions is critical because testing stops with the first match. If no conditions match, the router rejects or blocks the route; that is, the last action of any list is an implicit deny condition for all routes.

You cannot selectively place conditions in or remove conditions from an AS-path access list. You can insert a new condition only at the end of an AS-path access list.

Configuration Example 1

Consider the network structure in Figure 3 on page 23.

Suppose you want router London to behave in the following way:

•

Accept routes originated in AS 621 only if they pass directly to router London.

•

Accept routes originated in AS 11 only if they pass directly to router London.

•

Forward routes from AS 282 to AS 435 only if they pass through either AS 621 or AS 11, but not both AS 621 and AS 11.

Figure 3: Filtering with AS-Path Access Lists

The following commands configure router London to apply filters based on AS path to routes received from router Berlin and router Paris and to routes forwarded to router Madrid.

host1(config)#router bgp 47 host1(config-router)#neighbor 10.2.9.2 remote-as 621 host1(config-router)#neighbor 10.2.9.2 filter-list 1 in host1(config-router)#neighbor 10.2.8.2 remote-as 11 host1(config-router)#neighbor 10.2.8.2 filter-list 2 in host1(config-router)#neighbor 10.2.7.2 remote-as 435 host1(config-router)#neighbor 10.2.7.2 filter-list 3 out host1(config-router)#exit host1(config)#ip as-path access-list 1 deny ^11 host1(config)#ip as-path access-list 1 permit .* host1(config)#ip as-path access-list 2 deny ^621

JunosE 11.2.x IP Services Configuration Guide

host1(config)#ip as-path access-list 2 permit .* host1(config)#ip as-path access-list 3 deny [621 11] host1(config)#ip as-path access-list 3 permit .*

AS-path access list 1 is applied to routes that router London receives from router Paris. Router London rejects routes with the AS path 11 621 or 11 282 621.

AS-path access list 2 is applied to routes that router London receives from router Berlin. Router London rejects routes with the AS path 621 11 or 621 282 11.

Router London accepts routes with the AS path 282 11, 282 621, 282 621 11, or 282 11 621. However, it applies AS-path access list 3 to routes it forwards to router Madrid, and filters out routes with the AS path 282 621 11 or 282 11 621.

Using Access Lists in a Route Map

You can use a route map instead of the neighbor filter-list command to apply access lists for filtering routes.

Configuration Example 1

In Figure 4 on page 24, a route map is used to determine the weight for routes learned by router Chicago.

Figure 4: Route Map Filtering

Accesslist 1 permits any route whose AS-path attribute includes 32 or 837. This condition permits routes that originate in (or pass through from elsewhere) AS 32 or AS 837. When these routes are advertised through AS 451 and AS 17 to router Chicago, instance 1 of route map 1 matches such routes and sets their weight to 25, overriding the neighbor weight set for updates received from 10.2.2.4.

Access list 2 permits any route whose AS-path attribute indicates that it originates in AS

74. When these routes are advertised through AS 837 and AS 32 to router Chicago, instance 1 of route map 2 matches such routes and sets their weight to 175, overriding the neighbor weight set for updates received from 10.5.5.2.

The following example configures router Chicago:

Chapter 1: Configuring Routing Policy

host1(config)#router bgp 293 host1(config-router)#network 192.168.5.0 mask 255.255.255.0 host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 weight 150 host1(config-router)#neighbor 10.2.2.4 route-map 1 in host1(config-router)#exit host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.5.5.2 weight 50 host1(config-router)#neighbor 10.5.5.2 route-map 2 in host1(config)#route-map 1 permit 1 host1(config-route-map)#match as-path 1 host1(config-route-map)#set weight 25 host1(config-route-map)#exit host1(config)#ip as-path access-list 1 permit [ 32 837 ] host1(config)#route-map 2 permit 1 host1(config-route-map)#match as-path 2 host1(config-route-map)#set weight 175 host1(config-route-map)#exit host1(config)#ip as-path access-list 2 permit [ 74 ]

The result of this configuration is that router Chicago prefers routes learned through router Boston (weight 150) over routes learned through router NY (weight 50), except that:

access-list

•

Router Chicago prefers routes learned via router NY that passed through AS 837 or AS 32 (weight 50) over the same routes learned via router Boston (weight 25 according to route map 1).

•

Router Chicago prefers routes originating in AS 74 learned via router NY that passed through AS 837 and AS 32 (weight 175 according to route map 2) over the same routes learned via router Boston (weight 150).

• Use to define an IP access list to permit or deny routes based on the prefix.

• Each access list is a set of permit or deny conditions for routes based on matching a

route's prefix.

• A zero in the wildcard mask means that the corresponding bit in the address must be

exactlymatchedby the route. Aone inthe wildcard maskmeans that thecorresponding bit in the address does not have to be matched by the route.

• Use the neighbor distribute-list command to apply the access list to routes received

from or forwarded to a neighbor.

• Use the log keyword to log an Info event in the ipAccessList log whenever an access

list rule is matched.

• Example

host1(config)#access-list bronze permit ip host any 228.0.0.0 0.0.0.255

JunosE 11.2.x IP Services Configuration Guide

• Use the noversion to delete an IP access list (no other options specified),the specified

entry in the access list, or the log for the specified access list or entry (by specifying the log keyword).

• See access-list.

default-information originate

• Use to enable RIP, OSPF, or BGP to advertise a default route (0.0.0.0/0) that exists

in the IP routing table.

• If you specify the always option for OSPF, OSPF generates a default route, if it does

not exist in the IP routing table and advertises it.

• Use to generate a default route to an IS-IS domain.

• Example

host1(config-router)#default-information originate

• Use the no version to disable advertisement of the default route.

• See default-information originate.

ip as-path access-list

• Use to define an AS-path access list to permit or deny routes based on the AS path.

• Each access list is a set of permit or deny conditions for routes based on matching a

route's AS path to a regular expression. If the regular expression matches the representation of the AS path of the route as an ASCII string, the permit or deny condition applies. The AS path does not contain the local AS number.

• The AS path allows substring matching. For example, theregularexpression20 matches

AS path = 20 and AS path = 100 200 300, because 20 is a substring of each path. To disable substring matching and constrain matching to only the specified attribute string, place theunderscore (_) metacharacter on both sidesof the string; for example, _20_.

• Use the neighbor filter-list command to apply the AS-path access list. You can apply

access-list filters to inbound and outbound BGP routes. You can assign weights to routes matching the AS-path access list.

• Example

host1(config)#ip as-path access-list 1 permit ^\(

• Use the no version to remove the AS-path access list; all entries that belong to this list

are removed.

• See ip as-path access-list.

ipv6 access-list

• Use to define an IPv6 access list to permit or deny routes based on the prefix.

• Each access list is a set of permit or deny conditions for routes based on matching a

route's prefix.

neighbor distribute-list

Chapter 1: Configuring Routing Policy

• Use the neighbor distribute-list command to apply the access list to routes received

from or forwarded to a neighbor.

• Use the log keyword to log an Info event in the ipAccessList log whenever an access

list rule is matched.

• Example

host1(config)#ipv6 access-list bronze deny 1::1/16 any

• Use the no version to delete an IPv6 access list (no other options specified), the

specified entry in the access list, or the log for the specified access list or entry (by specifying the log keyword).

• See ipv6 access-list.

• Use to filter routes to selected prefixes as specified in an access list. Distribute lists are

applied only to external peers.

• Use the in keyword to apply the list to inbound routes (inbound policy). Use the out

keyword to apply the list to outbound routes (outbound policy).

neighbor filter-list

• Besides using distribute lists to filter BGP advertisements, you can do the following:

• Use AS-path filters with the ip as-path access-list and the neighbor filter-list

commands

• Use route map filters with the route-map and the neighbor route-map commands

• Example

host1:vr1(config-router)#neighbor group1 distribute-list list1 in

• Use the no version to disassociate the access list from a neighbor.

• See neighbor distribute-list.

• Use to assign an AS-path access list to matching inbound or outbound routes.

• Use the in keyword to apply the list to inbound routes (inbound policy). Use the out

keyword to apply the list to outbound routes (outbound policy).

• You can specify an optional weight value with the weight keyword to assign a relative

importance to incoming routes that match the AS-path access list.

• Access list values can be in the range 0–65535.

• Example

host1:vr1(config-router)#neighbor group2 filter-list list2 out

• Use the no version to disassociate the access list from a neighbor.

• See neighbor filter-list.

neighbor prefix-list

JunosE 11.2.x IP Services Configuration Guide

• Use to assign an inbound or outbound prefix list.

• If you specify a BGP peer group by using the peer-group-name argument, all the

members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.

• Use the in keyword to assign the prefix list to incoming routes (inbound policy)

• Use the out keyword to assign the prefix list to outgoing routes (outbound policy); you

cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy

• Example

host1(config-router)#neighbor 192.168.1.158 prefix-list seoul19 in

• Use the no version to remove the prefix list.

• See neighbor prefix-list.

neighbor prefix-tree

• Use to assign an inbound or outbound prefix tree.

redistribute

• If you specify a BGP peer group by using the peer-group-name argument, all the

members of the peer group inherit the characteristic configured with this command unless it is overridden for a specific peer.

• Use the in keyword to assign the prefix tree to incoming routes (inbound policy)

• Use the out keyword to assign the prefix tree to outgoing routes (outbound policy);

you cannot configure a member of a peer group to override the inherited peer group characteristic for outbound policy

• Example

host1(config-router)#neighbor 192.168.1.158 prefix-tree newyork out

• Use the no version to remove the prefix tree.

• See neighbor prefix-tree.

• Use to redistribute routes from one routing domain to another routing domain.

• Example

host1(config)#router bgp 100 host1(config-router)#neighbor 192.56.10.2 remote-as 200 host1(config-router)#redistribute static host1(config-router)#exit host1(config)#ip route 155.30.0.0 0.0.255.255

• Use the no version to end redistribution of information.

• See redistribute.

Using Access Lists for PIM Join Filters

You can apply access lists to PIM sparse mode interfaces along with the ip pim join-filter or ipv6 pim join-filter command to use the access lists as PIM sparse mode join filters.

To configure PIM join filters:

1. Create the various access list services you want to use with the PIM join filter

command.

host1(config)#! create bronze service host1(config)#! - restrict SSM channels to 232.0.1/24 only host1(config)#access-list bronze permit ip host any 228.0.0.0 0.0.0.255 host1(config)#access-list bronze permit ip host 1.1.1.1 232.0.1.0 0.0.0.255 host1(config)#access-list bronze permit ip host 2.2.2.2 232.0.1.0 0.0.0.255 host1(config)# host1(config)#! create silver service host1(config)#! - bronze service + new channels 232.0.2/24 host1(config)#access-list silver permit ip host any 228.0.0.0 0.0.0.255 host1(config)#access-list silver permit ip host 1.1.1.1 232.0.1.0 0.0.0.255 host1(config)#access-list silver permit ip host 2.2.2.2 232.0.1.0 0.0.0.255 host1(config)#access-list silver permit ip host 1.1.1.1 232.0.2.0 0.0.0.255 host1(config)#access-list silver permit ip host 2.2.2.2 232.0.2.0 0.0.0.255 host1(config)# host1(config)#! create gold service host1(config)#! - silver service + new channels 232.0.3/24 host1(config)#access-list gold permit ip host any 228.0.0.0 0.0.0.255 host1(config)#access-list gold permit ip host 1.1.1.1 232.0.1.0 0.0.0.255 host1(config)#access-list gold permit ip host 2.2.2.2 232.0.1.0 0.0.0.255 host1(config)#access-list gold permit ip host 1.1.1.1 232.0.2.0 0.0.0.255 host1(config)#access-list gold permit ip host 2.2.2.2 232.0.2.0 0.0.0.255 host1(config)#access-list gold permit ip host 1.1.1.1 232.0.3.0 0.0.0.255 host1(config)#access-list gold permit ip host 2.2.2.2 232.0.3.0 0.0.0.255

Chapter 1: Configuring Routing Policy

For additional information about how to create access lists, see “Access Lists” on page 20 .

2. Enable IP multicast routing.

host1(config)#ip multicast-routing

3. Enable PIM source-specific multicast router.

host1(config)#ip pim ssm

4. Identify the default PIM join filter.

host1(config)#ip pim join-filter bronze

5. Enable PIM sparse mode on a subinterface.

host1(config)#interface atm 3/0.101 host1(config-if)#ip address 101.0.0.1 255.255.255.255 host1(config-if)#ip pim sparse-mode

This interface (and any other PIM interface to which you do not specifically assign an access list filter) uses the default (bronze) join filter.

6. Enable PIM sparse mode on another subinterface and assign the silver join filter.

JunosE 11.2.x IP Services Configuration Guide

host1(config-if)#interface atm 3/0.102 host1(config-if)#ip address 102.0.0.1 255.255.255.255 host1(config-if)#ip pim sparse-mode host1(config-if)#ip pim join-filter silver

7. Enable PIM sparse mode on another subinterface and assign the gold join filter.

host1(config-if)#interface atm 3/0.103 host1(config-if)#ip address 103.0.0.1 255.255.255.255 host1(config-if)#ip pim sparse-mode host1(config-if)#ip pim join-filter gold

For information about the ip pim join-filter command, see Configuring PIM for IPv4 Multicast in JunosE Multicast Routing Configuration Guide. For information about the ipv6 pim join-filter command, see Configuring PIM for IPv6 Multicast in JunosE Multicast Routing Configuration Guide.

Clearing Access List Counters

Use theclearaccess-listor clear ipv6 access-list commands to clear access list counters.

clear access-list

clear ipv6 access-list

Creating Table Maps

• Use to clear all access list counters or access list counters in the specified access list.

• Example 1

host1#clear access-list list1

• Example 2

host1#clear ipv6 access-list list2

• There is no no version.

• See clear access-list.

• See clear ipv6 access-list.

For static routes and access routes, you can configure and apply a table map that filters routes before an access list adds them to the routing table. For static routes, you can use the ip static-route table-map or ipv6 static-route table-map command. For access routes, you can use the ip access-route table-map or ipv6 access-route table-map command.

Use these commands when triggering on the policy values listed in Table 3 on page 30.

Table 3: Match and Set Policy Values

SetMatch

metricip address

distancemetric

Chapter 1: Configuring Routing Policy

Table 3: Match and Set Policy Values (continued)

SetMatch

tagdistance

tag

For example,you can configure an accesslist androute map tofilter, based on IP address, any routes that appear in the routing table:

host1(config)#ip access-route table-map just10net host1(config)#access-list permit10 permit 10.0.0.0 0.255.255.255 host1(config)#access-list permit10 deny any host1(config)#route-map just10net host1(config-route-map)#match ip address permit10

Using the same name for both the table map and the route map creates an association specifying (inthis case) that only IPaddresses that match the access listcriterion appear in the routing table.

ip access-route table-map

ipv6 access-route table-map

• Use to filter access routes before an access list adds them to the routing table.

• Example 1

• Example 2

• Use the no version to delete the table map.

• See ip access-route table-map.

• See ipv6 access-route table-map.

ip static-route table-map

ipv6 static-route table-map

• Use to filter static routes before adding them to the routing table.

• Example 1

• Example 2

host1(config)#ip access-route table-map just10net

host1(config)#ipv6 access-route table-map map2

host1(config)#ip static-route table-map map3

host1(config)#ipv6 static-route table-map map4

• Use the no version to delete the table map.

• See ip static-route table-map.

• See ipv6 static-route table-map.

JunosE 11.2.x IP Services Configuration Guide

Using the Null Interface

You can useaccesscontrol lists tofilterundesired traffic. Anotherway to handle undesired traffic is tosend itto the null interface. The router automaticallycreates thenull interface, which is always up, cannot be deleted, and acts as a data sink. In other words, the null interface cannot forward or receive traffic. However, the CLI does allow you to access the null interface.

The E Series router creates the null interface by default; you do not have to manually create it. You can direct traffic to the null interface by specifying the null 0 keywords instead of a next-hop or destination address when you configure routes.

interface null

• Use to access the null interface.

• The null interface is a data sink; it does not accept or forward traffic.

• Although you can access the null interface, you cannot configure any values for it or

delete it.

ip route

Prefix Lists

• Example

host1(config)#interface null 0 host1(config-if)#

• There is no no version.

• See interface null.

• Use to configure a static route and redirect traffic from it to the null interface.

• Example

host1(config-if)#ip route 10.10.20.5 null 0

• Use the no version to remove the static route.

• See ip route.

A prefix list is a sequential collection of permit and deny conditions that apply to IP or IPv6 addresses. Like an access list, the router tests addresses one by one against the conditions ina prefix list.The first match determines whether therouter accepts or rejects the address. Because the router stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the router rejects the address. An empty prefix list results in an automatic permit of the tested address.

Unlike access lists, the prefix list specifies a base IP or IPv6 address and a length (the number of bits applied to the base to determine the network prefix). The tested address is matched against the prefix.

Using a Prefix List

clear ip prefix-list

Chapter 1: Configuring Routing Policy

Use theip prefix-list command to definean IPprefix list, or the ipv6prefix-list command to define an IPv6 prefix list. The prefix-list keyword with either the match { ip | ipv6 } address or match { ip | ipv6 } next-hop commands enables you to add a clause to a route map.

The following example creates a prefix list that permits routes with a prefix length up to 24 in the 151.0.0.0/8 network:

host1(config)#ip prefix-list abc permit 151.0.0.0/8 le 24

• Use to clear all hit counts in the prefix lists or the specified entry from the specified

prefix list. (The router increments the hit count by 1 each time an entry matches.)

• Example

host1#clear ip prefix-list abc

• There is no no version.

clear ipv6 prefix-list

ip prefix-list

ipv6 prefix-list

• See clear ip prefix-list.

• Use toclear all hit counts inthe IPv6prefix lists orthe specifiedentry from thespecified

prefix list. (The router increments the hit count by 1 each time an entry matches.)

• Example

host1#clear ipv6 prefix-list abc

• There is no no version.

• See clear ipv6 prefix-list.

• Use to create a prefix list for route filtering and to specify a list entry—a deny or permit

clause for a network address—to the prefix list. Use to add entries to prefix lists.

• The prefix list name can be up to 32 characters long.

• Specify the position of each entry in the list with the seq (sequence) keyword. If you

do not specify a sequence number, the router uses the value of the last sequence number plus 5.

• Use the ge and le keywords to specify a range of network prefixes. These keywords

have the following values:

• prefix length < ge <= 32

• prefix length < le <= ge

• If you do not specify either the ge or le keyword, an exact match is expected.

JunosE 11.2.x IP Services Configuration Guide

• Example 1—IPv4; exact match required; the router permits only a route with a prefix

length of 8 and a network address of 151.0.0.0.

host1(config)#ip prefix-list abc permit 151.0.0.0/8

• Example 2—IPv6; exact match required; the router permits only a route with a prefix

length of 8 and a network address of 1:0:0:0:0:0:0:5.

host1(config)#ipv6 prefix-list abc permit 1::5/8

• Use the no version to remove the specified prefix list or the specified list entry.

• See ip prefix-list.

• See ipv6 prefix-list.

match ip address

• Use to specify an access list or use with the prefix-listor prefix-treekeyword to match

routes that have a destination network number address that is permitted by any specified access list, prefix list, or prefix tree.

• Example

match ipv6 address

match ip next-hop

host1(config-route-map)#match ip address prefix-list abc

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match ip address.

• Use tomatchany route that hasa destination network number addressthat is permitted

by the specified access list or prefix list.

• Example

host1(config-route-map)#match ipv6 address prefix-list boston

• Use the no version to delete all address match clauses from a route map unless you

specify an access list or prefix list, in which case only the list match is removed from the route map.

• See match ipv6 address.

• Use with the prefix-list keyword to match routes that have a next-hop router address

passed by the specified access lists, prefix lists, or prefix trees.

• Example

host1(config-route-map)#match ip next-hop prefix-list abc

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match ip next-hop.

match ipv6 next-hop

Prefix Trees

Chapter 1: Configuring Routing Policy

• Use to match any routes that have a next-hop router address passed by the specified

access list or prefix list.

• Example

host1(config-route-map)#match ipv6 next-hop prefix-list next1

• Use the no version to delete all next-hop match clauses from a route map unless you

specify an access list or prefix list, in which case the router removes only the list match from the route map.

• See match ipv6 next-hop.

A prefix tree is a nonsequential collection of permit and deny conditions that apply to IP addresses. Like a prefix list, the prefix tree specifies a base IP address and a length, the number of bits applied to the base to determine the network prefix. The tested address is matched against the prefix. The prefix tree also enables route summarization.

Using a Prefix Tree

clear ip prefix-tree

However, the prefix tree does not match addresses one by one in sequence against the listed conditions. The router performs a binary search against the tree structure of the entries. Ifthe tested address is lessthan aparticular entry, it branches one way to another test pair; if it is greater than the entry, it branches the other way to another mutually exclusive test pair. The router stops testing conditions when it finds the best match. If no conditions match, the router rejects the address. An empty prefix tree results in an automatic permit of the tested address.

The prefix tree provides a faster search method and matches the test address more closely than either the access list or the prefix list.

Use the ip prefix-tree command to define an IP prefix tree. Use the prefix-tree keyword with the match ip address or match ip next-hop commands to add a clause to a route map. Use the match-set summary prefix-tree command to specify the prefix tree that summarizes routes for a particular route map.

The following example creates a prefix tree that permits routes with a prefix length of 24 or larger in the 10.10.2.0/24 network:

host1(config)#ip prefix-tree xyz permit 10.10.2.0/24

• Use to clear all hit counts in the prefix trees or the specified entry from the specified

prefix tree. (The router increments the hit count by 1 each time an entry matches.)

• Example

host1#clear ip prefix-tree xyz

• There is no no version.

• See clear ip prefix-tree.

JunosE 11.2.x IP Services Configuration Guide

ip prefix-tree

• Use tocreatea prefix tree for bestroute filtering; specifies atree entry—a deny or permit

clause for a network address.

• The prefix tree name can be up to 32 characters long.

• Example

host1(config)#ip prefix-tree boston42 permit 10.10.2.0/24

• Use the no version to remove the specified prefix tree or the specified tree entry.

• See ip prefix-tree.

match ip address

• Use with the prefix-tree keyword to match routes that have a destination network

number address that is permitted by the prefix tree.

• Example

host1(config-route-map)#match ip address prefix-tree xyz

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match ip address.

match ip next-hop

• Use with the prefix-tree keyword to match routes that have a next-hop router address

passed by the specified prefix tree.

• Example

• Use the no version to delete the match clause from a route map or a specified value

from the match clause.

• See match ip next-hop.

match-set summary prefix-tree

• Use to specify the prefix tree that summarizes routes for a particular route map.

• Use the ip prefix-tree command to set theconditions of the prefix tree,including which

routes to summarize and how many bits of the network address to preserve.

• Example

host1(config-route-map)#match ip next-hop prefix-tree xyz

host1(config-route-map)#match-set summary prefix-tree dog3

• Use the no version to disable use of the prefix tree by the route map.

• See match-set summary prefix-tree.

Community Lists

Chapter 1: Configuring Routing Policy

A community isa logical group of prefixes that share some commonattribute. Community members can reside on different networks and in different autonomous systems. BGP enables you to define the community to which a prefix belongs. A prefix can belong to more than one community. The community attribute lists the communities to which a prefix belongs.

You can usecommunities to simplifyrouting policies byconfiguring the routinginformation that a BGP device can accept, prefer, or distribute to other neighbors according to community membership. When a route is learned, advertised, or redistributed, a BGP device can set,append, or modify the communityof aroute.When routes are aggregated, the resulting BGP update contains a community attribute that contains all communities from all of the aggregated routes (if the aggregate is an AS-set aggregate).

Several well-known communities are predefined. Table 4 on page 37 describes how a BGP device handles a route based on the setting of its community attribute.

Table 4: Action Based on Well-Known Community Membership

BGP Device ActionWell-Known Community

no-export

no-export-subconfed)

internet

In addition to the well-known communities, you can define local-use communities, also known as private communities or general communities. These communities serve as a convenient way to categorize groups of routes to facilitate the use of routing policies. The community attribute consists of four octets, but it is common practice to designate communities in the AA:NN format. The autonomous system number (AA) comprises the higher two octets, and the community number (NN) comprises the lower two octets. Both are expressed as decimal numbers. For example, if a prefix in AS 23 belongs to community 411, the attribute could be expressed as 23:411. Use the ip bgp-community new-format command to specify that the show commands display communities in this format. You can also use a regular expression to specify the community attribute.

Does not advertise the route beyond the BGP confederation boundary

Does not advertise the route to any peers, IBGP, or EBGPno-advertise

Does not advertise the route to any external peerslocal-as (also known as

Advertises this route to the Internet community; by default, all prefixes are members of the Internet community

Use the set community command in route maps to configure the community attributes. You can add one or more communities to the attribute, or you can use the list keyword to add a list of communities to the attribute. By default, the community attribute is not sent to BGP peers. To sendthe community attribute to a neighbor, use the neighbor send community command.

JunosE 11.2.x IP Services Configuration Guide

A communitylist is a sequential collection of permit and deny conditions.Each condition describes the community number to be matched. If you issued the ip bgp-community new-format command, the community number is in AA:NN format; otherwise, it is in decimal format (the hexadecimal octets converted to decimal).

The router tests the communityattributeof aroute against each condition ina community list. The first match determines whether the router accepts (the route is permitted) or rejects (the routeis denied)a route that hasthe specifiedcommunity. Because the router stops testing conditions after the first match, the order of the conditions is critical. If no conditions match, the router rejects the route.

Consider the network structure shown in Figure 5 on page 38.

Figure 5: Community Lists

Suppose you want router Albany to setmetricsfor routes that itforwardstorouterBoston based on the communities to which the routes belong. You can create community lists and filter the routes with a route map that matches on the community list. The following example configures router Albany:

host1(config)#router bgp 293 host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.2.2.1 remote-as 451 host1(config-router)#neighbor 10.2.2.4 remote-as 17 host1(config-router)#neighbor 10.2.2.4 route-map commtrc out host1(config-router)#exit host1(config)#route-map commtrc permit 1 host1(config-route-map)#match community 1 host1(config-route-map)#set metric 20 host1(config-route-map)#exit host1(config)#route-map commtrc permit 2 host1(config-route-map)#match community 2 host1(config-route-map)#set metric 75 host1(config-route-map)#exit host1(config)#route-map commtrc permit 3 host1(config-route-map)#match community 3 host1(config-route-map)#set metric 85

host1(config-route-map)#exit host1(config)#ip community-list 1 permit 25 host1(config)#ip community-list 2 permit 62 host1(config)#ip community-list 3 permit internet

Community list 1 comprises routes with a community of 25; their metric is set to 20. Community list 2 comprises routes with a community of 62; their metric is set to 75. Community 3 catches all remaining routes by matching the Internet community; their metric is set to 85.

ip bgp-community new-format

• Use to specify that communities must be displayed in AA:NN format, where AA is a

number that identifies the autonomous system and NN is a number that identifies the community within the autonomous system.

• Example

• Use the no version to restore the default display.

Chapter 1: Configuring Routing Policy

host1(config)#ip bgp-community new-format

ip community-list

• See ip bgp-community new-format.

• Use to create a community list for BGP and control access to it.

• The list name can be up to 32 characters long.

• A route can belong to any number of communities, so a community list can have many

entries comprising many communities.

• You can specify one or more community values when you create a community list. A

clause in a route map that includes a list that has more than one value matches only a route that has all of the values; that is, the multiple values are logical ANDed.

• You can specify community values with a number or a regular expression.

• Example

host1(config)#ip community-list 1 permit 100:2 100:3 100:4 host1(config)#route-map marengo permit 10 host1(config-route-map)#match community 1

A route matches this community list only if it belongs to at least all three communities in community list 1: communities 100:2, 100:3, and 100:4.

• Use the no version to remove the specified community list, including all list entries.

• See ip community-list.

neighbor send-community

• Use to specify that a community attribute be sent to a BGP neighbor.

• If you specify a BGP peer group by using the peer-group-name argument, all the

members of the peer group inherit the characteristic configured with this command.

• Example

JunosE 11.2.x IP Services Configuration Guide

host1:vr1(config-router)#neighbor 192.3.4.5 send-community standard

• Use the no version to specify that common attributes not be sent to a BGP neighbor.

• See neighbor send-community.

set community

• Use to set the community attribute in BGP updates.

• You can specify a community list number in the range 1–4294967295, or in the new

community format of AA:NN, or you can specify one of the following well-known communities:

• local-as—Prevents advertisement outside the local AS

• no-advertise—Prevents advertisement to any peer

• no-export—Prevents advertisement beyond the BGP confederation boundary

• Alternatively, you can use the list keyword to specify the name of a community list

that you previously created with the ip community-list command.

• You can use this command with inbound, outbound, and redistribution route maps.

• Use the none keyword to remove the community attribute from a route.

• Example

host1(config)#route-map 1 host1(config-route-map)#set community no-advertise

• Use the no version to remove the set clause from a route map.

• See set community.

Extended Community Lists

The router supportsthe BGPextendedcommunity attribute defined in Internet draft BGP ExtendedCommunities Attribute— draft-ietf-idr-bgp-ext-communities-07.txt (February 2004 expiration). This attribute enables thedefinition ofa type ofIP extended community and extended community list unrelated to the community list that uses regular expressions.

NOTE: IETF drafts are valid for only six months from the date of issuance. They must

be considered as works in progress. For the latest drafts, please see the IETF Web site at http://www.ietf.org.

BGP devices can use the extended community attribute to control routes much like they use the community attribute to determine routes that they accept, reject, or redistribute. A BGP device can append the extended community attribute to a route that does not have the attribute before it advertises the route. For routes that do have the attribute, BGP can modify the attribute.

ip extcommunity-list

Chapter 1: Configuring Routing Policy

• Use to create an extended community list for BGP and control access to it.

• A route can belong to any number of communities, so an extended community list can

have many entries comprising many communities.

• You can specify one or more community values when you create an extended

community list. A clause in a route map that includes a list that has more than one value matches only a route that has all of the values; that is, the multiple values are logical ANDed.

• Use the rt keyword to specify a route target community, which consists of one or more

routers that can receive a set of routes advertised by BGP that carry the extended community attribute.

• Use the soo keyword to specify a site-of-origin community, which consists of one or

more routers that inject into BGP a set of routes that carry the extended community attribute.

• Example

host1(config)#ip extcommunity-list boston1 permit rt 100:2 rt 100:3 rt 100:4 host1(config)#route-map marengo permit 10 host1(config-route-map)#match extcommunity boston1

match extcommunity

set extcommunity

A route matches this community list only if it belongs to at least all three communities in extended community list boston1: communities 100:2, 100:3, and 100:4.

• Use the no version to remove a single extended community list entry if you specify the

permit or deny keyword and a path expression. Otherwise, the router removes the

entire community list.

• See ip extcommunity-list.

• Use to match an extended community list in a route map.

• You can specify one or more extended community list names in a match clause. If you

specify more than one extended community list, the lists are logically ORed.

• Example

host1(config-route-map)#match extcommunity topeka10

• Use the no version to remove the match clause from a route map or a specified value

from the match clause.

• See match extcommunity.

• Use to set the extended community attributes in a route map for BGP updates.

• Use the rt keyword to specify a route target community, which consists of one or more

routers that can receive a set of routes advertised by BGP that carry the extended community attribute.

JunosE 11.2.x IP Services Configuration Guide

• Use the soo keyword to specify a site-of-origin community, which consists of one or

more routers that inject into BGP a set of routes that carry the extended community attribute.

• You can specify both a route target community and a site-of-origin community at the

same time in a set clause without them overwriting each other.

• Example

host1(config)#route-map 1 host1(config-route-map)#set extcommunity rt 10.10.10.2:325

• Use the no version to remove the set clause from the route map.

• See set extcommunity.

show ip extcommunity-list

Use to display information about a specific extended community list or all extended

•

community lists.

• Example

host1#show ip extcommunity-list IP Extended Community List dresden1: permit soo 10.10.10.10:15 IP Extended Community List bonn: deny rt 12:12

• See show ip extcommunity-list.

Using Regular Expressions

You can use regular expressions when you define AS-path access lists and community lists to more easily filter routes. A regular expression uses special characters—often referred to as metacharacters—to define a pattern that is compared with an input string.

AS-path Lists

For an AS-path access list, the input string is the AS path of the routes to which the list is applied with the route-map or neighbor filter-list commands. If the AS path matches the regular expression in the access list, the route matches the access list.

Example The following commands apply access list 1 to routes inbound from BGP peer 10.5.5.2.

Accesslist 1 usesa regular expressiontodeny routes thatoriginatein autonomous system

32.

host1(config-router)#neighbor 10.5.5.2 remote-as 32 host1(config-router)#neighbor 10.5.5.2 filter-list 1 in host1(config-router)#exit host1(config)#ip as-path access-list 1 deny 32$

Community Lists

Example The following commands apply route map 5 to routes forwarded to BGP peer 10.5.5.4.

Community Numbers

Chapter 1: Configuring Routing Policy

For a community list, the input string is the community attribute of the routes to which the list is applied using a route-map command. If the community attribute matches the regular expression in the community list, the route matches the community list.

Route map 5 uses a regular expression to match community numbers ending with 305, setting the weight of matching routes to 150.

host1(config-router)#neighbor 10.5.5.4 remote-as 425 host1(config-router)#neighbor 10.5.5.4 route-map 5 out host1(config-router)#exit host1(config)#route-map 5 permit 10 host1(config-route-map)#match community 305$ host1(config-route-map)#set weight 150

When you use a regular expression to match a community number, use the appropriate formatfor the communitynumber inthe community list. Ifyou issue the ip bgp-community new-format command, the community number has the format AA:NN where AA is a number that identifies the autonomous system, and NN is a number that identifies the community within the autonomous system. Otherwise, the community number is an integer in the range 1–4294967295.

Metacharacters

Each regular expression consists of one or more metacharacters and zero or more complete or partial AS or community numbers. Table 5 on page 43 describes the metacharacters supported for regular expression pattern-matching.

Table 5: Supported Regular Expression Metacharacters

DescriptionMetacharacter

Matches the beginning of the input string.

Alternatively, when used as the first character within brackets—[^ ]—matches any number except the ones specified within the brackets.

Matches the end of the input string.$

Matches any single character, including white space..

Matches zero or more sequences of the immediately previous character or pattern.

Matches one or more sequences of the immediately previous character or pattern.

Matcheszeroor onesequenceof theimmediately previouscharacter orpattern.?

JunosE 11.2.x IP Services Configuration Guide

Table 5: Supported Regular Expression Metacharacters (continued)

DescriptionMetacharacter

()

_ (underscore)

Specifies patterns for multiple use when followed by one of the multiplier metacharacters: asterisk (*), plus sign (+), or question mark (?).

Matches any enclosed character; specifies a range of single characters.[ ]

Used within brackets to specify a range of AS or community numbers.– (hyphen)

Matches a^, a $, a comma, a space, a {,or a }. Placed on either side of astring to specify a literal and disallow substring matching. Numerals enclosed by underscorescan be preceded orfollowed by anyof the characters listed above.

Matches characters on either side of the metacharacter; logical OR.|

Using Metacharacters as Literal Tokens

You can remove thespecial meaning of a metacharacter by preceding it with a backslash (\). Sucha construction denotes that themetacharacter isnot treatedas ametacharacter for that regular expression. It is simply a character or token with no special meaning, just as a numeral has no special meaning. The backslash applies only to the character immediately following it in the regular expression.

On an E Series router, you are likely to use the backslash only for the parentheses characters, ( or ). BGP indicates a segment of an AS path that is of type AS-confed-set or AS-confed-seq by enclosing that segment with parentheses.

Example The following AS-path access list uses a regular expression to match routes that have

an AS-path attribute that begins with any AS-confed-set or AS-confed-seq:

host1(config)#ip as-path access-list 1 permit ^\(

The following AS-path access list uses a regular expression to match routes that have an AS-path attribute that ends with any AS-confed-set or AS-confed-seq:

host1(config)#ip as-path access-list 1 permit \)$

The following AS-path access list uses a regular expression to match routes that have an AS-path attribute that includes the specific AS-confed-set or AS-confed-seq, (100

200):

host1(config)#ip as-path access-list 1 permit $100 200$

Regular Expression Examples

Table 6 on page 45 lists some representative regular expressions that you might use in an AS-path access list or community list, along with sample attribute values that match or do not match the regular expression.

Table 6: Sample Regular Expressions

Chapter 1: Configuring Routing Policy

Regular Expression

1.9

Matched AS-Path or Community Attribute

Begins with 12^12

Includes any numeral except 1 or 2[^12]

Ends with 305305$

Includes any one character followed by the numeral 5

Includes a sequenceof three characters, where thefirst characteris numeral 1and the third character is numeral 9

Example

12 23 4212 629 121245 19

but not 58 12 7

44 73 465 69 8

but not 1145 1912 2 49

89 611 305305 42 30519 1305 6666:305

89 611 3533 252 12 998 600:500

179 35 2433 252 129 48 2129 14600:2129 321:94

42*

1(37)*

42+

1(37)+

Includes any character; matches all AS paths and community lists

Includes a number that has a numeral 4 followed by zero or more instances of the numeral 2

Includes a sequence that has a numeral 1 followed by zero or more instances of the pattern 37

Includes a number that has a numeral 4 immediately followed by one or more instances of the numeral 2

Includes a sequence that has a numeral 1 immediately followed by one or more instances of the pattern 37

67 42 51314 33 252 422 483142 4 339 7831422

137 42 211373737 29 4 1

but not 4 3737 78

67 42 2133 252 422 48

but not 4 329 78

1373737 29 44 37137 78 137 42 21

but not 4 372 2121 37 5 1 456 881

JunosE 11.2.x IP Services Configuration Guide

Table 6: Sample Regular Expressions (continued)

Regular Expression

42?

1(37)?

7..

^7..

^7..$

Matched AS-Path or Community Attribute

Includes a number that has a numeral 4 followed by zero or only one instance of the numeral 2

Includes a sequence that has a numeral 1 followed by zero or only one instance of the pattern 37

Includes a sequenceof three characters, where the first character is numeral 7

Includes a number in the range 700 – 799

Consists only of a number in the range 700 – 799

Example

67 42 714 359 78

but not 33 252 422 48

137 42 2153 612 49 1

but not 4 13737 78

600 700 10025 7771

In thefollowing examples, the three characters are 7, space, 8: 307 800 6127 888 999

6127 723 999 700 100 600

but not 25 7771307 800

723 700

but not 25 7771307 800 6127 723 999700 100 600

^$22 431$

{41 19}

101 102 | 103 105

Includes any of the numerals 6, 2, or 1[621]

Includes any number in the range 0–9[0-9]

(AS-pathattributeonly)Begins withthe AS-confed-set or AS-confed-seq (22

431)

(AS-path attribute only) Includes the AS-set or AS-seq {41 19}

Includes either sequence 101 102 or sequence 103 105

60 4334 545 92 200710 86 53

The regular expression [162] has the same results.

(22 431) 102(22 431) 55 76

but not 43 (22 431) 522 431 59

{41 19} 53 76 {41 19} 17 255 {41 19}

but not 3 41 19 41 19 532

43 101 102 5103 105 22

but not 19 102 101102 103

Chapter 1: Configuring Routing Policy

Table 6: Sample Regular Expressions (continued)

Regular Expression

_200_

For information about using AS-path access lists, see “Access Lists” on page 20. For information about using community lists, see “Community Lists” on page 37.

Managing the Routing Table

You can clear all routes from the IP routing table, and then enable the owning protocols—BGP, OSPF, RIP—to reinstall the routes.

clear ip routes

• Use to clear all routing entries or a specified entry from the IP routing table.

Matched AS-Path or Community Attribute

Includes the number 200 (as opposed to the pattern consisting of numeral 2, numeral 0, numeral 0)

Our implementation of regular expressions is not literal. Substring matching is enabled by default. Specifying 200(no underscores) results in a match on 200 and on 2005. The underscore metacharacter disables substring matching.

Example

33 200 422 48^200$ ^200 500$

but not 33 20 422 48 51 2005

• Example

host1#clear ip routes

• There is no no version.

• See clear ip routes.

ip refresh-route

• Use toreinstall routes removedfrom theIP routing table by theclearip route command.

• Example

host1#ip refresh-route

• There is no no version.

• See ip refresh-route.

Troubleshooting Routing Policy

You can turn on debugging for routing policy by issuing the log severity debug ipRoutePolicy command from Global Configuration mode. You can specify different

levels of severity for ipRoutePolicy. For more information about using log commands for troubleshooting, see Managing the System in JunosE System Basics Configuration Guide.

JunosE 11.2.x IP Services Configuration Guide

Monitoring Routing Policy

You can monitor the following aspects of routing policy using show commands:

CommandsTo Display

Access lists

show access-list show ip as-path access-list show ipv6 access-list

show ip community-listCommunity lists

show ip match-policy-listPolicy lists

show ip prefix-listPrefix lists

show ip prefix-treePrefix trees

show ip protocolsProtocols

show ip redistributeRedistribution policies

show ip routeRoutes

show route-mapRoute maps

show ip route slot 5 192.168.5.4Interfaces and next hops

show ip staticStatic routes

show ip trafficTraffic

You can use theoutput filtering feature of the show command to include or exclude lines of output based on a text string that you specify. For details, see Command Line Interface in JunosE System Basics Configuration Guide.

show access-list

show ipv6 access-list

• Use to display information about access lists.

• The displayed information includes the instances of each access list.

• Use the detail keyword to display the automatically assigned element ID for each

access list entry. Only rules that you explicitly create have element IDs.

• Example 1

host1#show access-list IP Access List 1: permit ip host 172.31.192.217 any permit ip 12.40.0.0 0.0.0.3 any

show ip as-path-access-list

Chapter 1: Configuring Routing Policy

deny ip any any IP Access List 2: permit ip 172.19.0.0 0.0.255.255 any deny ip 0.0.0.0 255.255.255.255 any IP Access List 10: permit ip any any IP Access List 11: deny ip any any

• Example 2

host1#show access-list detail IP Access List 1: 1: permit ip host 172.31.192.217 any 2: permit ip 12.40.0.0 0.0.0.3 any deny ip any any

• See show access-list.

• See show ipv6 access-list.

show ip community-list

Use to display information about AS-path access lists.•

• Example

host1#show ip as-path-access-list AS Path Access List 1: permit .* AS Path Access List 2: deny .* AS Path Access List 3: permit _109_ deny .* AS Path Access List 4: permit _109$ deny .* AS Path Access List 10: deny _109$ permit ^108_ deny .*

• See show ip as-path-access-list.

• Use to display community list information.

• Display varies based on whether you issued the ip bgp community new-format

command.

• Example 1—If you did not issue the ip bgp community new-format command, the

display appears as follows:

host1#show ip community-list Community List 1: permit 81200109 permit 81200110 permit 81200108 Community List 2:

JunosE 11.2.x IP Services Configuration Guide

deny 81200109 permit 81200110 permit 81200108 Community List 4: permit local-as Community List 5: permit no-advertise Community List 6: permit no-export Community List 7: permit internet

• Example 2—If you did issue the ip bgp community new-format command, the display

appears as follows:

host1#show ip community-list Community List 1: permit 1239:1005 permit 1239:1006 permit 1239:1004 Community List 2: deny 1239:1005 permit 1239:1006 permit 1239:1004 Community List 4: permit local-as Community List 5: permit no-advertise Community List 6: permit no-export Community List 7: permit internet

show ip match-policy-list

show ip prefix-list

• See show ip community-list.

Use to display configured policy lists.•

• Example

host1#show ip match-policy-list match-policy-list list1, permit Match clauses: match access-list addrList1 match distance 100

• See show ip match-policy-list.

• Use to display information about the prefix lists currently configured on the router.

• Use the summary keyword to display abbreviated information about prefix lists.

• Example 1

host1#show ip prefix-list Prefix-list with the last deletion/insertion: def ip prefix-list name abc: 4 entries seq 5 permit 192.168.0.0/16 le 24

show ip prefix-tree

Chapter 1: Configuring Routing Policy

seq 10 permit 192.178.0.0/16 le 24 seq 15 deny 195.178.0.0/16 le 24 seq 20 deny 195.178.0.0/16 le 32 ip prefix-list name def: 1 entries seq 5 deny 192.170.0.0/16

• Example 2

host1#show ip prefix-list summary Total memory used for prefix-list: 310 bytes Prefix-list with the last deletion/insertion: def ip prefix-list name abc: count: 4, range entries: 4, sequences: 5-20 ip prefix-list name def: count: 1, range entries: 0, sequences: 5-5

• See show ip prefix-list.

• Use to display information about the prefix trees currently configured on the router.

• Use the summary keyword to display abbreviated information about prefix trees.

• Example 1

host1#show ip prefix-tree Prefix-tree with the last deletion/insertion: t_abc5 ip prefix-tree name t_abc1: 1 entries permit 108.243.0.0/16 ip prefix-tree name t_abc2: 3 entries permit 101.10.254.0/24 permit 102.10.248.0/21 permit 103.10.192.0/18 permit 108.109.0.0/16 permit 108.109.241.0/24 ip prefix-tree name t_abc3: 1 entries deny 108.0.0.0/8

• Example 2

host1#show ip prefix-tree summary Total memory used for prefix-tree: 860 bytes Prefix-tree with the last deletion/insertion: t_abc5 ip prefix-tree name t_abc1: count: 1 ip prefix-tree name t_abc2: count: 5 ip prefix-tree name t_abc3: count: 1

• See show ip prefix-tree.

show ip protocols

• Use to display detailed information about the protocols currently configured on the

router.

• Use the summary keyword to display only a list of the configured protocols.

JunosE 11.2.x IP Services Configuration Guide

• For field descriptions, see the show commands for the individual routing protocols in

their respective Configuration Guide chapters.

• Example

host1#show ip protocols Routing Protocol is “ bgp 1”

Default local preference is 100 IGP synchronization is enabled Always compare MED is disabled Router flap damping is disabled Administrative Distance: external 20 internal 200 local 200 Neighbor(s): No neighbors are configured Routing for Networks:

Routing Protocol is “ ospf 255” with Router ID 100.100.100.1 Distance is 110

Address Summarization: None Routing for Networks:

show ip redistribute

Routing Protocol is “ rip” Router Administrative State: enable System version RIP1: send = 1, receive = 1 or 2 Update interval: 30 seconds Invalid after: 180 seconds hold down time: 120 seconds flushed interval: 300 seconds Filter applied to outgoing route update is not set Filter applied to incoming route update is not set No global route map Distance is 120 Interface Tx Rx Auth

Routing for Networks:

10.2.1.0/255.255.255.0

• See show ip protocols.

• Use to display configured route redistribution policy.

• Field descriptions

• To—Protocol into which routes are distributed

• From—Protocol from which routes are distributed

• status—Redistribution status

• route map number—Number of the route map

• Example

show ip route

Chapter 1: Configuring Routing Policy

host1#show ip redistribute To ospf, From static is enabled with route map 4 To ospf, From connected is enabled with route map 3

• See show ip redistribute.

• Use to display the current state of the routing table, including routes that are not used

for forwarding.

• Youcan display allroutes, a specific route, all routesbeginning witha specifiedaddress,

routes for a particular protocol (BGP, IS-IS, OSPF, or RIP), locally connected routes, internal control routes, static routes, or summary counters for the routing table.

• Field descriptions

• Prefix—IP address prefix

• Length—Prefix length

• Type—Protocol type

• Next Hop—IP address of the next hop

• Dist—Distance metric for the route

• Met—Number of hops

• Intf—Interface type and interface specifier

• Example 1

host1#show ip route Protocol/Route type codes: I1- ISIS level 1, I2- ISIS level2, I- route type intra, IA- route type inter, E- route type external, i- metric type internal, e- metric type external, O- OSPF, E1- external type 1, E2- external type2, N1- NSSA external type1, N2- NSSA external type2

Prefix/Length Type Next Hop Dist/Met Intf

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

172.16.2.0/24 Bgp 192.168.1.102 20/1 fastEthernet0/0

10.10.0.112/32 Static 192.168.1.1 1/1 fastEthernet0/0

10.1.1.0/24 Connect 10.1.1.1 0/1 atm3/0.100

• Example 2

host1#show ip route static Protocol/Route type codes: I1- ISIS level 1, I2- ISIS level2, I- route type intra, IA- route type inter, E- route type external, i- metric type internal, e- metric type external, O- OSPF, E1- external type 1, E2- external type2, N1- NSSA external type1, N2- NSSA external type2

Prefix/Length Type Next Hop Dist/Met Intf

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

10.10.0.112/32 Static 192.168.1.1 1/1 fastEthernet0/0

JunosE 11.2.x IP Services Configuration Guide

• Example 3

host1#show ip route summary Unicast routes: 8 total routes, 576 bytes in route entries 0 isis routes 0 rip routes 3 static routes 2 connected routes 1 bgp routes 0 ospf routes 2 other internal routes 0 access routes 0 internally created access host routes

Last route added/deleted: 2::4/128 by BGP At MON FEB 04 2008 14:18:25 UTC

Unicast routes used only for Multicast RPF check: 0 total routes, 0 bytes in route entries 0 isis routes 0 rip routes 0 static routes 0 connected routes 0 bgp routes 0 ospf routes 0 other internal routes 0 access routes 0 internally created access host routes 0 mbgp routes 0 dvmrp routes

show ip route slot

Last route added/deleted: null by Invalid At MON FEB 04 2008 14:18:04 UTC

MPLS tunnel routes (not used for forwarding): 3 total routes, 216 bytes in route entries 1 bgp tunnel routes 1 ldp tunnel routes 1 rsvp tunnel routes

Last route added/deleted: 2::4/128 by BGP Tunnel At MON FEB 04 2008 14:18:26 UTC

• See show ip route.

Use to display the interface and next hop for an IP address in the routing table of a line

•

module specified by the slot it occupies.

• slotNumber—Number of the slot that contains the line module for which the

information is displayed

• ipAddress—IP address to look up in the routing table

• Field descriptions

• IP address—Address that is reachable through the interface

Chapter 1: Configuring Routing Policy

• Interface—Interface type and specifier associated with the IP address; displays “

Local Interface” if a special interface index is present in the routing table for special IP addresses, such as broadcast addresses

• Next Hop—Next hopto reach theIP address; displays“ ---”if no next hopis associated

with the IP address

• Example 1

host1#show ip route slot 6 10.10.0.231 IP address Interface Next Hop

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

10.10.0.231 fastEthernet 6/0 10.10.0.231

• Example 2

host1#show ip route slot 9 90.248.1.2 IP address Interface Next Hop

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

90.248.1.2 serial9/23:2 ---

• Example 3

host1#show ip route slot 9 90.249.255.255 IP address Interface Next Hop

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

90.249.255.255 Local Interface ---

show ip static

• See show ip route slot.

• Use to display the status of static routes in the routing table.

• You can specify an optional IP mask that filters specific routes.

• Field descriptions

• Prefix—IP address prefix

• Length—Prefix length

• Next Hop—IP address of the next hop

• Met—Number of hops

• Dist—Administrative distance or weight assigned to the route

• Tag—Tag value assigned to the route

• Intf—Interface type and interface specifier

• Example

host1#show ip static Prefix/Length Next Hop: Met: Dist: Tag: Intf:

10.2.0.0/24 192.168.1.1 1 1 0 ethernet6/0

JunosE 11.2.x IP Services Configuration Guide

10.2.1.0/24 192.168.1.1 1 1 1 ethernet6/0

172.31.1.48/32 172.18.2.2 1 1 0 atm5/1.1

• See show ip static.

show ip traffic

• Use to display statistics about IP traffic.

• Field descriptions

• IP Statistics Rcvd:

• Router Id—Router ID number

• total—Number of frames received

• local destination—Frames with this router as their destination

• hdr errors—Number of packets received that contain header errors

• addr errors—Number of packets received that contain addressing errors

• unkn proto—Number of packets received that contain unknown protocols

• discards—Number of discarded packets

• IP Statistics Frags:

• reassembled—Number of reassembled packets

• reasm timed out—Number of reassembled packets that timed out

• reasm req—Number of requests for reassembly

• reasm fails—Number of reassembly failures

• frag ok—Number of fragmented packets reassembled successfully

• frag fail—Number of fragmented packets reassembled unsuccessfully

• frag creates—Number of packets created by fragmentation

• IP Statistics Sent:

• forwarded—Number of packets forwarded

• generated—Number of packets generated

• out disc—Number of outbound packets discarded

• no routes—Number of packets that could not be routed

• routing discards—Number ofpacketsthat could not be routed that were discarded

• IP Statistics Route:

Chapter 1: Configuring Routing Policy

• routes in table—Number of routes in the routing table

• timestamp req—Number of requests for a timestamp

• timestamp rpy—Number of replies to timestamp requests

• addr mask req—Number of address mask requests

• addr mask rpy—Number of address mask replies

• ICMP Statistics Rcvd:

• total—Total number of ICMP packets received

• errors—Number of error packets received

• dst unreach—Number of packets received with destination unreachable

• time exceed—Number of packets received with time-to-live exceeded

• param probs—Number of packets received with parameter errors

• src quench—Number of source quench packets received

• redirects—Number of receive packet redirects received

• echo req—Number of echo request (ping) packets received

• echo rpy—Number of echo replies received

• timestamp req—Number of requests for a timestamp received

• timestamp rpy—Number of replies of timestamp requests received

• addr mask req—Number of mask requests received

• addr mask rpy—Number of mask replies received

• ICMP Statistics Sent:

• total—Total number of ICMP packets sent

• errors—Number of error packets sent

• dest unreach—Number of packets sent with destination unreachable

• time excd—Number of packets sent with time-to-live exceeded

• param prob—Number of packets sent with parameter errors

• src quench—Number of source quench packets sent

• redirects—Number of send packet redirects sent

• echo req—Number of echo request (ping) packets sent

• echo rpy—Number of echo replies sent

JunosE 11.2.x IP Services Configuration Guide

• timestamp req—Number of requests for a timestamp sent

• timestamp rpy—Number of replies to timestamp requests sent

• addr mask req—Number of address mask requests sent

• addr mask rpy—Number of address mask replies sent

• UDP Statistics Rcvd:

• total—Total number of UDP packets received

• checksum—Number of checksum error packets received

• no port—Numberof packets received for whichno application listener was listening

on the destination port

• UDP Statistics Sent:

• total—Total number of UDP packets sent

• errors—Number of error packets sent

• TCP Global Statistics Connections:

• attempted—Number of outgoing TCP connections attempted

• accepted—Number of incoming TCP connections accepted

• established—Number of TCP connections established

• dropped—Number of TCP connections dropped

• closed—Number of TCP connections closed

• TCP Global Statistics Rcvd:

• total pkts—Total number of TCP packets received

• in-sequence pkts—Number of packets received in sequence

• bytes—Number of bytes received

• chksum err pkts—Number of checksum error packets received

• authentication err pkts—Number of authentication error packets received

• bad offset pkts—Number of packets received with bad offsets

• short pkts—Number of short packets received

• duplicate pkts—Number of duplicate packets received

• out of order pkts—Number of packets received out of order

• TCP Global Statistics Sent:

• total pkts—Total number of TCP packets sent

• data pkts—Number of data packets sent

• bytes—Number of bytes sent

• retransmitted pkts—Number of packets retransmitted

• retransmitted bytes—Number of retransmitted bytes

• OSPF Statistics—Not supported for this version of the router

• IGMP Statistics—Not supported for this version of the router

• ARP Statistics—Not supported for this version of the router

• Example

host1#show ip traffic IP statistics: Router Id: 172.31.192.217 Rcvd: 97833 total, 171059 local destination 0 hdr errors, 0 addr errors 167 unkn proto, 0 discards Frags: 4 reassembled, 30 reasm timed out, 8 reasm req 0 reasm fails, 145 frag ok, 0 frag fail 290 frag creates Sent: 15 forwarded, 25144 generated, 0 out disc 0 no routes,0 routing discards Route: 57680 routes in table 0 timestamp req, 0 timestamp rpy 0 addr mask req, 0 addr mask rpy

Chapter 1: Configuring Routing Policy

ICMP statistics: Rcvd: 561 total, 0 errors, 15 dst unreach 0 time exceed, 0 param probs, 0 src quench 0 redirects, 0 echo req, 0 echo rpy 0 timestamp req, 0 timestamp rpy 0 addr mask req, 0 addr mask rpy Sent: 0 total, 0 errors, 0 dest unreach 0 time excd, 0 param prob, 0 src quench 0 redirects, 0 echo req, 0 echo rpy

UDP Statistics: Rcvd: 93326 total, 0 checksum errors, 90610 no port Sent: 0 total, 0 errors

TCP Global Statistics: Connections: 7358 attempted, 4 accepted, 7362 established 0 dropped, 14718 closed Rcvd: 75889 total pkts, 53591 in-sequence pkts, 3120283 bytes 0 chksum err pkts, 0 authentication err pkts, 0 bad offset 0 short pkts, 0 duplicate pkts, 0 out of order pkts Sent: 82318 total pkts, 44381 data pkts, 656321 bytes 34 retransmitted pkts, 487 retransmitted bytes

OSPF Statistics:

IGMP Statistics:

JunosE 11.2.x IP Services Configuration Guide

ARP Statistics:

• See show ip traffic.

show route-map

• Use to display the configured route maps.

• The displayed information includes the instances of each access list such as match

and set commands.

• Example

host1(config)#route-map 1 permit 10 host1(config-route-map)#match community 44 host1(config-route-map)#set local-pref 400 host1(config-route-map)#exit host1(config)#exit host1#show route-map 1 route-map 1, permit, sequence 10 Match clauses: match community 44 Set clauses: set local-pref 400

• See show route-map.

CHAPTER 2

Configuring NAT

This chapter describes how to configure Network Address Translation (NAT) on your ERX router; it contains the following sections:

•

Overview on page 61

•

Platform Considerations on page 62

•

References on page 62

•

NAT Configurations on page 63

•

Network and Address Terms on page 64

•

Understanding Address Translation on page 65

•

Address Assignment Methods on page 66

•

Order of Operations on page 66

•

PPTP and GRE Tunneling Through NAT on page 67

•

Packet Discard Rules on page 68

•

Before You Begin on page 68

•

Configuring a NAT License on page 68

•

Limiting Translation Entries on page 69

•

Specifying Inside and Outside Interfaces on page 69

•

Defining Static Address Translations on page 69

•

Defining Dynamic Translations on page 71

•

Clearing Dynamic Translations on page 76

•

NAT Configuration Examples on page 76

•

Tunnel Configuration Through NAT Examples on page 83

•

GRE Flows Through NAT on page 84

•

Monitoring NAT on page 84

Overview

The Internet faces the challenges of conserving IP address space while continuing to provide scalability in routing. Network Address Translation (NAT) helps address these challengesby allowing the conservation of registered IP addresses withinprivatenetworks and simplifying IP addressing management tasks through a form of transparent routing.

JunosE 11.2.x IP Services Configuration Guide

NAT enables you to translate IP addresses between two address realms (for example, between an intranet network that uses private, not publicly routable addresses and the Internet, or betweentwooverlapping,privatenetworks).When incoming traffic is received, the IP addresses are translated back for delivery within the private network.

Using NAT at the edge of your intranet provides the following advantages:

•

Allows unregistered private addresses to connect to the Internet by translating those addresses into globally registered IP addresses

•

Increases network privacy by hiding internal IP addresses from external networks

Platform Considerations

For information about modules that support NAT on ERX14xx models, ERX7xx models, and the 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 NAT.

Module Requirements

References

NOTE: The E120 and E320 Broadband Services Routers do not support configuration of NAT.

To configure NAT on ERX7xx models, ERX14xx models, and the ERX310 router, you must install a Service Module (SM). For information about installing modules in E Series Broadband Services Routers, see the ERX Hardware Guide.

Unlike other line modules, SMs do not pair with corresponding I/O modules that contain ingress and egress ports. Instead, they receive data from and transmit data to other line modules with access to ingress and egress ports on their own associated I/O modules.

For a list of the modules that support NAT, see ERX Module Guide, Appendix A, Module Protocol Support.

For more information about NAT, consult the following resources:

•

RFC 2663-IP Network Address Translator (NAT) Terminology and Considerations (August 1999)

•

RFC 2694-DNS extensions to Network Address Translators (DNS_ALG) (September

1999)

•

RFC 2993-Architecture Implications of NAT (November 2000)

NAT Configurations

Traditional NAT

Chapter 2: Configuring NAT

•

RFC 3022-Traditional IPNetwork Address Translator(Traditional NAT) (January 2001)

•

RFC 3027-Protocol Complications with the IP Network Address Translator (January

2001)

You can configure NAT in several different ways. Each of the following configuration methods provides a solution for different configuration requirements:

•

Traditional NAT

•

Bidirectional NAT

•

Twice NAT

Traditional NAT is the most common method of using address translation. Its primary use is translating private addresses to legal addresses for use in an external network. When configured for dynamicoperation,hosts withina privatenetwork can initiate access to the external(public) network, but external nodeson theoutside network cannot initiate access to the private network.

Addresses on the private network and public network must not overlap. Also, route destination advertisements onthe publicnetwork (for example,the Internet) can appear within theinside network, butthe NAT router doesnot propagateadvertisements of local routes that reference private addresses out to the public network.

There are two types of traditional NAT—basic NAT and NAPT.

Basic NAT

Basic NAT provides translation for IP addresses only (called a simple translation) and places the mapping into a NAT table. In other words, for packets outbound from the private network, the NAT router translates the source IP address and related fields (for example, IP, TCP, UDP, and ICMP header checksums). For inbound packets, the NAT router translates the destination IP address (and related checksums) for entries that it finds in its translation table.

CAUTION: Although NAT is the simplest translation method, it is the least secure. By

not including port or external host information in the translation, basic NAT allows access to any port of the private host by any external host.

NAPT

Network Address Port Translation (NAPT) extends the level of translation beyond that of basic NAT; it modifies both the IP address and the transport identifier (for example, the TCP or UDP port number, or the ICMP query identifier) and places the mapping into the translation table (this entry is called an extended translation). This method can translate the addressesand transport identifiers ofmany private hosts into afewexternal

JunosE 11.2.x IP Services Configuration Guide

addresses and transport identifiers, to make efficient use of globally registered IP addresses.

Similar to basic NAT, for outbound packetsNAPT translatesthe source IPaddress, source transport identifier, and related checksum fields. For inbound packets NAPT translates the destination IP address, destination transport identifier, and checksum fields.

Bidirectional NAT

Bidirectional (or two-way) NAT adds support to basic NAT for theDomain Name System (DNS) so public hosts can initiate sessions into the private network, usually to reach servers intended for public access.

When anoutside host attempts to resolvethe nameof aninside hoston aprivatenetwork, the NAT router intercepts the DNS reply and installs an address translation to allow the outside host to reach the inside host by using a public address. When the outside host initiatesa connection withthe insidehost onthe privatenetwork, the NAT routertranslates that public destinationaddress to theprivateaddressof theinside hostand, on thereturn path, replaces the source address with the advertised public address.

You might need to perform some additional configuration to allow public access from the Internet to a DNS server that resides in the private domain. (See “Bidirectional NAT Example” on page 78.)

The same address space requirements and routing restrictions apply to bidirectional NAT that weredescribed for traditional NAT. The difference between these twomethods is that the DNS exchange might create entries within the translation table.

Twice NAT

In twice NAT, both the source and destination addresses are subject to translation as packets traverse the NAT router in either direction. For example, you would use twice NAT if you are connecting two networks in which all or some addresses in one network overlap addresses in another network, whether the network is private or public.

Network and Address Terms

The NAT implementation defines an address realm as either inside or outside, with the router that is running NAT acting as the defining boundary between the two realms.

From a NAT perspective, an inside network is the local portion of a network that uses private,not publicly routable IP addresses that you want to translate. An outside network is the public portion of a network that uses legitimate, publicly routable IP addresses to which you want private hosts to connect.

The addresses that are translated by NAT between address realms are labeled as inside or outside, and as local or global. When reading the terms in the following sections, keep the following definitions in mind:

•

The terms inside and outside refer to the host that the address is associated with.

•

The terms local and global refer to the network on which the address appears.

Inside Local Addresses

The inside local address is a configured IP address that is assigned to a host on the inside network. Addresses may be globally unique (not requiring translation), allocated from the private address space defined in RFC 1918, or officially allocated to some other organization.

Inside Global Addresses

The inside global address is the translated IP address of an inside host as seen by an outside host and network. Addresses may be allocated from a globally unique address space (often provided by the ISP,if theinside address isconnectedto theglobal Internet).

Outside Local Addresses

The outside local address is the translated IP address of an outside host as it appears to the insidenetwork. Addressesmay begloballyunique (notrequiring translation),allocated from the private address space defined in RFC 1918, or officially allocated to some other organization.

Chapter 2: Configuring NAT

Outside Global Addresses

The outside global address is the configured, publicly routable IP address assigned to a host on the outside network.

Understanding Address Translation

Address translation can occur one of two ways: inside or outside source translation.

Inside Source Translation

Inside source translation is the most commonly used NAT configuration. When an inside host sends a packet to the outside network, the NAT router translates the source information(either thesourceaddress or the source address/port pair)and, in the inbound direction, restores the original information (this time operating on thedestination address or address/port pair).

For outbound traffic, the NAT router translates the inside local address (or address/port) into the inside global address (or address/port), either through a statically defined translation or dynamically created translation. For inbound traffic, a translation must be found to revert the inside global address (or address/port) into the inside local address (or address/port), or the packet is not routed into the inside network.

NOTE: Dynamic inside source translations are established by outbound traffic.

You use inside source translation in traditional and bidirectional NAT configurations.

Outside Source Translation

Outside source translation is used inNAT configurations only when addresses ofexternal hosts might create a conflict on the private network. This complementary translation

JunosE 11.2.x IP Services Configuration Guide

process is performed on the opposite addressing fields in the IP packet. When an outside host sends a packet to the inside network, the NAT router translates the source information (either the source address or the source address/port pair) and, in the outbound direction, restores the original information (this time operating on the destination address or address/port pair).

For inboundtraffic, the NAT routertranslates the outside global address (or address/port) into the outside local address (or address/port), either through a statically defined translation or dynamically created translation. For outbound traffic, a translation must be found to revert the outside local address (or address/port) into the outside global address (or address/port), or the packet is not routed into the outside network.

NOTE: Dynamic outside source translations are established by inbound traffic.

You use outside source translation along with inside source translation to configure twice NAT.

Address Assignment Methods

NAT uses one of two methods to assign a translated IP address: static translation or dynamic translation.

Static Translations

You enter static translations as direct configuration settingsthat remain inthe translation table until you remove them. You use static translations when you must initiate connections from both the inside and outside interfaces, or when the translation is not subject to change.

Dynamic Translations

Dynamic translationsuse access list rules,to determine whetherto apply NAT to incoming traffic, and NAT address pools, from which a NAT translation can obtain IP addresses. You use dynamic translation when you want the NAT router to initiate and manage address translation and session flows between address realms on demand.

Order of Operations

This section describes the order of operations for both inside-to-outside and outside-to-inside translation.

Inside-to-Outside Translation

Inside-to-outside translation occurs in the following order:

1. Inside (privately addressed) trafficenters the router onan interface marked as inside.

2. A route lookup is performed.

3. If the next interface is marked as outside, the router sends the traffic to the server

module.

4. The server module performs the appropriate translation.

5. The router forwards the packet to the appropriate egress line module.

6. The line module sends thepacket as outbound traffic using a globally unique source

address (inside sourcetranslation),destinationaddress (outside source translation), and ports (NAPT).

Outside-to-Inside Translation

Outside-to-inside translation occurs in the following order:

1. Traffic from the outside, public domain enters the router.

2. All traffic from an interface that is marked outside, whether or not it requires NAT, is

sent to the server module.

3. The server module searches for an associated NAT match.

4. If the server module:

•

Finds a NAT match, and the destination interface is marked as inside, the server module performs the appropriate translation and sends the packet to the appropriate destination.

Chapter 2: Configuring NAT

•

Does not find a NAT match, and the destination interface is marked as inside, the server module drops the packet.

•

Does not find a NAT match, and the destination interface is not marked as inside, the server module processes the packet normally for its destination.

PPTP and GRE Tunneling Through NAT

You can configure NAT traversal support for GRE flows using simple translations (Basic NAT). Because PPTP uses an enhanced GRE encapsulation for the PPP payload, configuring for GRE flows also supports NAT traversal for PPTP tunnels.

NOTE: Neither port translation (NAPT) nor Firewall traversal for GRE packets is

supported for GRE flows.

When configured, the following types of translations are supported for GRE and PPTP tunnels:

•

Inside source static simple translations (inbound and outbound)

•

Outside source static simple translations (inbound and outbound)

•

Inside source dynamic simple translations (inbound and outbound)

•

Outside source dynamic simple translations (inbound and outbound)

•

Combinations of the preceding translations (for example, twice NAT)

JunosE 11.2.x IP Services Configuration Guide

Packet Discard Rules

For all supported types of traffic (TCP, UDP, ICMP, and GRE), NAT discards packets in the following cases:

•

When the translation table is full (that is, no more entries can be added).

•

When the address pool is exhausted for outbound packets with inside source dynamic translation.

•

When no match can be found for the destination addresses of inbound packets.

•

When the address pool is exhausted for inbound packets with outside source dynamic translation.

In addition, NAT discards GRE packets under the following conditions:

•

When the GRE packets match an NAPT rule.

•

When Firewall is functioning.

Before You Begin

You can configure certain IP interfaces to participate in Network Address Translation. This chapter discusses how to configure NAT to function for certain IP interfaces. For information about general IP interface configuration, see Configuring IP in JunosE IP, IPv6, and IGP Configuration Guide.

Configuring a NAT License

You must configure a NAT license before you can use any NAT commands on the ERX router.

license nat

• Use to specify a NAT license.

• Purchase a NAT license to allow NAT configuration on the ERX router.

NOTE: Acquire the license from Juniper Networks Customer Services and Support or from your Juniper Networks sales representative.

• Example

host1(config)#license nat license-value

• Use the no version to disable the license.

• See license nat.

Limiting Translation Entries

You can configure the maximum number of dynamic translation entries that the translation table contains in global configuration mode for a given virtual router.

ip nat translation max-entries

• Use tospecify themaximum numberof dynamictranslation entriesthat the translation

table can contain in global configuration mode for the given virtual router.

• Example

host:VR1 (config-if) #ip nat translation max-entries 1000

• Use the no version to remove the configured limit and return the maximum number of

translation entries to the default, which is no enforced limit, as capacity allows.

• See ip nat translation max-entries.

Specifying Inside and Outside Interfaces

Chapter 2: Configuring NAT

You must mark interfaces that participate in NAT translation as residing on the inside or the outside network.

CAUTION: Only packets routed between an inside and an outside interface are subject

to translation.

You can unmark an interface by using the no version of this command.

ip nat

• Use to mark an IP interface as participating in NAT translation.

• Use the keyword (inside or outside) to specify the side of the network on which the

interface resides.

• Example

host (config-if) # ip nat inside

• Use the no version to unmark the interface (the default) so that it does not participate

in NAT translation.

• See ip nat.

Defining Static Address Translations

Static address translation establishes aone-to-one mappingbetween a localand global address or local and global address/port pair. When you specify a static address translation or address/port pair translation, you issue commands to indicate how the translation is applied, along with more specific variables that further define the type of translation.

JunosE 11.2.x IP Services Configuration Guide

CAUTION: You must mark interfaces that participate in NATtranslation as on the inside

or the outside network. See “Specifying Inside and Outside Interfaces” on page 69 for details.

Creating Static Inside Source Translations

You use the ip nat inside source static command to create static translations from a local IP address to a global IP address, and to untranslate the destination address when a packet returns from the outside network to the inside network. When you configure traditional NAT (both basic NAT and NAPT), you only need to use this command alone. However, when you configure twice NAT, you must also use “ip nat outside source static” on page 70 .

The ip nat inside source static command creates a simple (IP address only) or extended (IP address, port,and protocol) entry in the translation table that maps thetwo addresses.

ip nat inside source static

• Use to create static translations for a source address (or address/port pair) when

routing a packet from the inside network to the outside network, and to untranslate the destination address (or address/port pair) when a packet returns from the outside network to the inside network.

• A static translation created with the ip nat inside source static command enables any

outside host to contact the inside host by using the inside global address of the inside host. A static translation can be used by traffic that is initiated in either direction

• Example 1—Simple address translation

host (config) # ip nat inside source static 10.1.2.3 171.69.68.10

• Example 2—Extended address/port translation

host (config) # ip nat inside source static tcp 10.1.2.3 15 171.69.68.10 30

• Use the no version to remove the static translationand purge the associated translations

from the translation table.

• See ip nat inside source static.

Creating Static Outside Source Translations

Less commonly used, outsidesourcetranslationenablesyou to set uptranslation between two non-unique or not publicly routable networks (for example, two separate networks that use overlapping IP address blocks).

ip nat outside source static

• Use to translate the source address when routing a packet from the outside network

to theinside network, andto untranslate the destination address when a packet travels from the inside network to the outside network.

• Creates a simple (IP address only) or extended (IP address, protocol, and port) entry

in the translation table that maps the two addresses.

• A static translation created with the ip nat outside source static command enables

any inside host to contact the outside host by using the outside local address of the outside host.A static translation can beused bytrafficthat isinitiatedin either direction.

• Example 1—Simple address translation

host (config) # ip nat outside source static 171.69.68.10 10.1.2.3

• Example 2—Extended address/port translation

host (config) # ip nat outside source static tcp 171.69.68.10 56 10.1.2.3 24

• Use the no version to remove the static translationand purge the associated translations

from the translation table.

• See ip nat outside source static.

Defining Dynamic Translations

Dynamic translations use access list rules, to determine whether or not to apply NAT to incoming traffic, and NAT address pools, from which a NAT translation can allocate IP addresses. You use dynamic translation when you want the NAT router to initiate and manage address translation and session flows between address realms on demand.

Chapter 2: Configuring NAT

To configure dynamic translations:

•

Define any access list rules that the NAT router uses to decide which packets need translation.

•

Define an address pool from which the NAT router obtains addresses.

•

Define inside and outside source translation rules for the NAT router to create NAT translations.

•

Mark interfaces as inside or outside.

•

(Optional) Modify any translation timeout values.

Creating Access List Rules

Before you create a dynamic translation, create the access list rules that you plan to apply to the translation. For information about configuring access lists, see “Configuring Routing Policy” on page 3.

The router evaluates multiple commands for the same access list in the order they were created. An undefined access list implicitly contains arule to permit any. A defined access list implicitly ends with a rule to deny any.

NOTE: The access lists do not filter any packets; they determine whether the packet

requires translation.

You use the access-list command to create an access list.

access-list

JunosE 11.2.x IP Services Configuration Guide

• Use to define an IP access list to permit or deny translation based on the addresses in

the packets.

• Each access list is a set of permit or deny conditions for routes that are candidates for

translation (that is, moving from the inside network to the outside network).

• A zeroin thewildcardmask means that theroutemust exactlymatch the corresponding

bit in the address. A one in the wildcard mask means that the route does not have to match the corresponding bit in the address.

• Use the log keyword to log an Info event in the ipAccessList log whenever matching

an access list rule.

• Example

host1(config)#access-list bronze permit ip host any 228.0.0.0 0.0.0.255

• Use the no version to delete the access list (by not specifying any other options), the

specified entry in the access list, or the log for the specified access list or entry (by specifying the log keyword).

• See access-list.

Defining Address Pools

Before you can configure dynamic translation, create an address pool. An address pool is agroup of IP addresses from whichthe NAT router obtains anaddress when dynamically creating a new translation. You can create address pools with either a single range or multiple, nonoverlapping ranges.

When you create a single range, you specify the starting and ending IP addresses for the range in the root ip nat pool command. However, when you create multiple, nonoverlapping ranges, you omit the optional starting and ending IP addresses in the root ip nat pool command; this launches the IP NAT Pool Configuration (config-ipnat-pool) mode.

The config-ipnat-pool modeuses an addresscommand to specifya range ofIP addresses. You can repeat this command to create multiple, nonoverlapping ranges.

When you create or edit address pools, keep the following in mind:

•

Starting and ending IP addresses for the specified range are inclusive and must reside on the same subnet.

Address ranges are verified against other ranges in the specified pool to exclude range overlaps. Additional verification occurs when the pool is associated with a translation rule and the router can determine whether the rule is inside or outside.

You cannot change the network mask if configured ranges already exist.

•

The network mask (or prefix length) is used to recognize host addresses that end in either all zeros or all ones. These addresses are reserved as broadcast addresses and

address

ip nat pool

Chapter 2: Configuring NAT

are not allocated from an address pool, even if they are included in an address pool range.

•

You cannot remove an address pool if the pool is part of a translation rule or if any of the ranges within the pool are still in use. You must issue the clear ip nat translation command to clear any ranges before you can remove the pool to which they apply.

• Use to specify a range of IP addresses in config-ipnat-pool mode; you can repeat the

address command to create multiple ranges.

• Example

host (config-ipnat-pool)#address 171.69.40.110 171.69.40.115

• Use the no version to remove the range for the current address pool.

• See address.

• Use to create address pools.

• Example 1—Creating a single, continuous range

host (config) #ip nat pool singlerange 171.69.40.1 171.69.40.100prefix-length 30

• Example 2—Creating multiple, discontinuous ranges

host (config) #ip nat pool multiplerange prefix-length 30 host (config-ipnat-pool)#address 171.69.40.110 171.69.40.112 host (config-ipnat-pool)#address 171.69.40.118 171.69.40.120 host (config-ipnat-pool)#exit

• Use the no version to remove the address range.

• See ip nat pool.

Defining Dynamic Translation Rules

You can use the CLI to define dynamic translation rules for inside and outside sources.

CAUTION: You must mark interfaces that participate in NAT translation as on the inside

or the outside network. See “Specifying Inside and Outside Interfaces” on page 69 for details.

You can create a dynamic translation rule to configure inside source or outside source translation. If the NAT router cannot locate a matching entry in its translation database for a given packet, it evaluates the access list of all applicable dynamic translation rules (inside source translation rules foroutbound packets and outside source translation rules for inbound packets) against the packet. If an access list permits translation, the NAT router tries to allocate an address from the associated address pool to install a new translation.

When you create dynamic translation rules, keep the following in mind:

JunosE 11.2.x IP Services Configuration Guide

•

You can associatea listwith onepool atany given time. Associating alist witha different pool replaces the previous association.

•

The optional overload keyword for inside source translation specifies that the router employ NAPT.

•

You can configure dynamic NAPT for insidesourcetranslationonly;you cannot configure dynamic NAPT for outside source translation.

•

When no match occurs for any dynamic translation rule, the NAT router does not translate the packet.

•

When an address pool is empty, the NAT router drops the packet.

•

Access lists and pools do not have to exist when you are defining dynamic translation rules; you may create them after you define the dynamic translations.

Creating Dynamic Inside Source Translation Rules

Use the ip nat inside source list command to create a dynamic inside source translation rule. This command creates a translation rule that:

ip nat inside source list

•

Translates insidelocal source addresses to insideglobal addresses when packets from the inside network are routed to the outside network

•

Translates outside local source addresses to outside global addresses when packets from the outside network are routed to the inside network.

•

Use theoverloadkeyword to specify thatthe translation create NAPT entries(protocol, port, and address) in the NAT table.

The no version of this command removes the dynamic translation rule, but does not remove any previously created translations (resulting from the rule evaluation) from the translation table. To remove active translations from the translation table, see “Clearing Dynamic Translations” on page 76.

• Use to create dynamic translation rules that specify when to create a translation for

a source address whenrouting apacketfrom theinside network to theoutside network.

• Example

host (config) #ip nat inside source list translation1 pool pool1

• Use the overload keyword to specify that the translation create extended entries

(protocol, port, and address) in the translation table for NAPT.

• Use the no version to remove the dynamic translation rule; this command does not

remove any dynamic translations from the translation table.

• See ip nat inside source list.

Creating Dynamic Outside Source Translation Rules

Use theip nat outside source list command to createa dynamicoutside source translation rule. This command dynamically translates outside global source addresses to outside local addresses when packets are routed from the outside network to the inside network

Juniper JUNOSE 11.2.X IP SERVICES, JUNOSE 11.2.X Configuration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual